Архив недели @anton_yalyshev
Понедельник
Всем новогодний привет! Надеюсь, праздники продолжаются и смена деятельности заряжает вас позитивной энергией =)
С вами Антон Ялышев - я из JetBrains, второй год занимаюсь продуктовой стороной поддержки языка Kotlin в средах для разработки софта IntelliJ IDEA и Android Studio.
Каких тем я планирую коснуться:
пн - дам свой взгляд на принципы, благодаря которым наша компания и её продукты ценятся
вт - поговорю о специфике продакт менеджмента в ней
ср - попробуем подытожить - что такое продакт и что такое менеджмент в инженерной компании
чт - личные наблюдения о том что помогает сохранять мотивацию и боевой настрой в условиях ультра-многозадачности
пт - развитие продуктового майндсета в команде - это сейчас моя задача №1 - сам в ней разбираюсь и очень надеюсь на ваш фидбэк =)
сб - оставляю пока день без темы
вс - о миссии и вижене - опыт их прояснения, формирования и транслирования
Поехали, друзья! В первом треде познакомлю вас с JetBrains. Компания была основана 2000-м году в Праге. И, кстати, по сей день является Чешской, хотя конечно, корни у неё российские.
Дело в том, что когда-то в далёких и лихих 90-х, когда бывшие советские и новые русские граждане учились делать бизнес как могли, в Питере открылся филиал американской компании TogetherSoft, специализирующейся на modelling dev. tools (UML и иже с ним).
Это было оч. крутое место для выпускников тех. вузов, по началу офис рос и процветал. Но всё оказалось не так просто, и в кризис конца 90-х руководство решило перевезти core-команду (около 50-ти человек) в Европу, а именно, в Прагу.
Будучи разработчиком тулов для разработчиков ты хорошо понимаешь свои потребности и чувствуешь чего тебе не хватает. Топовое IDE на тот момент не сильно отличалось от Ноутпада++ с приаттаченными компилятором и дебаггером.
У инженеров возникало много действительно крутых идей, реализовать которые было проблемно из-за сложной структуры менеджмента и сложившейся продуктовой линейки.
В итоге, трое ребят, в скором будущем - основатели JetBrains, решили сделать собственный тул для автоматического ренэйма элементов кода. Вижен на тот момент был ясный - софт должен максимально освобождать разработчика от рутинной работы, давая силы на интеллектуальное творчество
Вторым решением был движок для поиска использования элементов в коде. Вскоре это всё сложилось в единую IDE - IntelliJ IDEA - продукт гораздо более "умный", чем существующие на тот момент решения. К слову, в феврале продукт празднует своё 20-летие 🎂
Как и водится на рынке, спустя год IBM выпускает аналогичную IDE под именем Eclipse. Основное отличие - она бесплатна. Вложения оправдываются целью - разработка на разных языках под платформы IBM. Для JetBrains это первый серьёзный конкурент.
Ответным решением стала диверсификация - во-первых инструментов редактирования кода, во-вторых стали разрабатываться продукты для смежных с написанием кода задач - билд-сервер, таск-треккер, другие collaborative dev. tool, и, ни много ни мало свой язык программирования - Kotlin.
Это позволило оставаться компании на плаву. Но ни одно из продуктов не был принципиально новым в своей нише. Главной задачей стало - выбиваться в лидеры. Единого мнения о том, как это получалось нет, поэтому попробую здесь сформировать своё:
1/4 Культура: открытые, доверительные и дружеские отношения, ощущение тусовки единомышленников, что компания создана для сотрудников (в противоположность работы на дядю) и многое другое мотивируют давать лучшее что человек может
2/4 Наука и образование: слаборазвитый на тот момент отечественный hightech рынок обуславливал отсутствие "заказа" для ВУЗов, выпускавших сильных специалистов. Создание и поддержка научных центров при ВУЗах дало студентам лучшее представление о реальных задачах в индустрии.
Ребята получали больше практики, некоторые из них продолжали. проф. деятельность в JB. Важно отметить, что одним из самым лимитирующих факторов в hightech рынках являются люди, способные и желающие решать сложные задачи, стоящие перед продуктами.
3/4 Дог-фудинг: главный принцип внутри компании - использовать свои продукты для разработки продуктов, на сколько это возможно. Спроси меня каким я вижу идеальный мир - я бы распространил этот принцип на все производства и соц. учреждения где это применимо 😄
4/4 Плоская орг. структура: в таких условиях большая иерархия не требовалась, её и не создавали. JB по сей день - инженерная компания, где менеджмент является, скорее, сервисом. Это интересная тема, и завтра мы в неё погрузимся чуть глубже.
Деление на вышеперечисленные принципы на самом деле условно - они пересекаются и являются частью друг друга. Такая вот картина 🙂
Завтра поговорим о специфике продуктовой деятельности внутри компании. Хорошего дня!
@produnderhood Eclipse разве не в тоже время стал умным?
Примерно, спустя год. У коллег было много эмоций, когда фичи IJ Идеи вскоре появлялись в Эклипсе. Но мы тоже что-то заимствовали, и заимствуем по сей день. Руководство вообще положительно относилось к обмену знаниями, т.к. по итогу оба продукта становились лучше для пользователей twitter.com/50megatonn/sta…
Вторник
@produnderhood Плоская структура очень плохо работает когда в компании больше 50 сотрудников. Было бы очень интересно узнать как вам, с точки зрения менеджера, в такой структуре работается.
Да, в т.ч. об это буду говорить сегодня/завтра 🙂 В JB сейчас 1000+ сотрудников, 28 выпущенных продуктов. Менеджменту действительно стало уделяться больше внимания чем раньше, но не за счёт вытягивания структуры twitter.com/_beargummy/sta…
@produnderhood Помню как в 2006 году отправил резюме в jetbrains, в ответ получил что-то вроде что jetbrains интересны только выпускники спбгу, лэти - не подходил тогда, сейчас что-то поменялось или все так же только спбгу?
Да конечно поменялось, как и само время в принципе - доступность образования и StackOverflow, образно говоря 😁, возросшая ценность навыков разобраться и сориентироваться и т.д.
Есть какой-то топ универов из которых приходят, но он точно не компанией формируется 🙂 twitter.com/ivanksk1/statu…
Привет! Сегодня будем говорить о развитии продуктологии внутри JetBrains.
Долгое время, отдельная роль продакта просто не требовалась - каждый разработчик, условно говоря, был продактом. Писали решения для себя, валидировали об коллег, слушали пользователей и хорошо их понимали.
Первые вопросы начали появляться когда мы стали заходить на территории, в которых сами пользователями не являемся. Помогала развитая коммуникация с кастомерами и вообще комьюнити как таковое.
Для большинства продуктов в начале развития было ясно, какие фичи несут основную ценность. Далее вариантов развития становилось больше, а ясность в том, что делать следующим падала. Таким образом, потребность в продакт менеджменте формировали требования к продукту и приоритезация
Продакт менеджмент стал полноценной ролью, ищущей ответы на эти вопросы и берущей во внимание другие продуктовые аспекты наших решений, которых раньше касались скорее по случаю, и где могли находиться точки дальнейшего роста. (речь идёт о периоде примерно 2010 - 2015 годах)
По сути, продуктовые стратегии, количественное представление поведения пользователей, аналитика и качественные исследования вышли уже из этих вопросов как естественная потребность.
А, собственно, продуктовая работа - это итеративное прояснения вопросов о продукте, пользователях и стратегии, а так же упорядочивание и представление этих знаний команде.
Занятный факт, что у команды продуктовые вопросы сами по себе возникают не так часто как ты можешь ожидать.
И это нормально - как часто люди в принципе себя дополнительно спрашивают - почему я делаю именно это, какова перспектива такого выбора? А какие ещё есть варианты? К чему в итоге я хочу прийти? И т.д.
Иными словами, это в том числе свежий, беспристрастный, общий и в частностях взгляд на продукт, который мы вместе с командой формируем. Он порождает вопросы, в т.ч. описанные выше, на которые мы потом пытаемся ответить.
Здесь может видеться как-бы обратное движение по классическому на сегодняшний день процессу создания продуктов.
А компания же в целом - это сбалансированное сочетание, образно говоря, учёных которые пытаются заработать деньги на своих изобретениях, и бизнеса, который ищет что именно нужно и просит изобрести. И один из ключевых здесь навыков менеджмента - чувствовать баланс и сочетать
Такая вот картина 🙂 Интересно будет знать ваше мнение, чего может быть здесь не хватает. А от коллег, кто внедрял/развивал продуктологию в компаниях с уже устоявшимися линейками продуктов - схоже ли это с вашим опытом.
Завтра предлагаю чуть оторваться от конкретного кейса компании и попробовать общими словами определить продакт менеджмент в инженерной компании.
Среда
Всем привет! Сегодня буду делиться наблюдениями из индустрии про то, такое продакт- и что такое менеджмент в инженерной компании.
Что такое инженерная компания. 😁 Здесь, в это понятие я вкладываю следующее - продуктовые решения преимущественно принимаются инженерами разрабатывающими продукт, или занимающимися менеджментом.
Причём я верю, что это могут быть случаи
- где основатели сами разработали свой продукт, который взлетел, и впоследствии строящие структуры вокруг по мере необходимости;
- где предприниматель загорелся идеей и организовал группу с определённой культурой, которая идею воплотила
В любом случае, со временем задач по поиску путей дальнейшего развития и по поддержке того, что есть, становится больше. И требования к качеству продуктовых решений из-за роста становится выше. Приходит на помощь фулл-тайм роль продакт менеджера.
В чём тогда заключается продуктология и в чём - менеджмент? В скоуп продуктологии я бы включил:
1/5: итеративное прояснение что ценно и важно для пользователей - классика;
2/5: работа с партнёрами, комьюнити;
3/5: обзор рынка, анализ конкурентов;
4/5: развитие продуктового майндсета команды проекта (куда могут входить разработчики, дизайнеры, тестировщики и другие, если они действительно её часть, а не обособлены в сервис).
По сути, первые три пункта - это поиск ответов на вопросы или проверка гипотез о продукте и точках его роста, которые продакт генерирует вместе с командой проекта.
5/5: если компания выпускает более одного продукта, то, вероятно, внутренняя организация имеет хоть сколько-то сервисный характер, и подразделения маркетинга, продаж и т.д. охватывают (оказывают сервис) группам продуктов. Задача продакта - наилучшим образом настроить с ними связь
Таким образом, продуктовая роль, ранее бывшая у команды разработки и/или руководства распределяется на разработку и продакта, а роль стейкхолдера идёт в руководство компании.
Что тогда в данном случае менеджмент:
1/3: Установление связей: что для начала важно сделать продакту - установить доверительный контакт, построить отношения с командой разработки, сервисными командами и стейкхолдерами, а так же пользователями, комьюнити и партнёрами.
Что друг от друга ожидать, чем друг другу помочь, и в каком порядке. В каком-то смысле мы разворачиваем небольшие исследования в направлениях от продукта к каждой из сторон и выясняем боли и потребности всех причастных.
2/3: В сетевой орг. структуре нет общей иерархии постановки задач - продакт не руководит командой разработки или продаж, и задачи ставят во всех направлениях.
И здесь менеджмент - это в первую очередь менеджмент задач, своих и относящихся к себе (их систематизация, построение процессов, создание продуктовой команды и их делегирование).
3/3: развитие продуктового майндсета. Продакт - главный ответственный за адаптацию и развитие продуктологических практик внутри компании.
Вчера как-то в тему вышла статья на хабре про описание внутреннего устройства инженерной компании Valve (habr.com/ru/post/536196/), где, кмк, применяются или могли бы иметь место принципы продуктового менеджмента о которых я пишу здесь.
Менеджмент из единой классической структуры уходит, как-бы в мета-структуру, передавая свою продуктовую экспертизу команде, адаптирую и совместное развивая наилучшим образом. К привычным задачам добавляются новые, дико-интересные челленджи 🔥
На этом пока всё 🙂 Завтра планирую завершить эту тему разговором о развитии майндсета команды. Хорошего вечера!
Четверг
(в перерыве с хаккерских аттак) Привет! Сегодня расскажу о моём взгляде на развитие продуктового майндсета команды (с учётом меня в т.ч.), и что в повседневной практике работает, а что неоч.
Почему я решил отдельно раскрыть эту тему:
- вижу в ней большой потенциал масштабирования деятельности продакта
- не вижу как можно иначе в компаниях с высоким уровнем свободы принятия продуктовых решений
Пара слов о том как это не получалось в начале:
- Ошибкой раз было моё решение, разобравшись в теме, вписываться в обсуждения вопросов, рассказывать о решениях с позиции продуктологии. Это могло решить именно те вопросы, но дальше пользы не несло и к майндсету отношения не имело
Иными словами, тоскание вёдер заместо строителства трубопровода.
Ошибкой два было находить слабые места в принятии продуктовых решений внутри команды и пытаться их исправить новыми договорённостями. Новые методы слабее старых привычек, и если это не решало боль именно участника договорённости, то договорённость редко когда длилась долго.
Рабочий вариант был рядом - иди и общайся 😄 разговаривай с коллегами о сложных/проблемных местах в их работе - у нас общие цели, мы команда. Свобода принятия решение создаёт множество вопросов и непоняток. И в т.ч. их решение и есть наша совместная задача.
Вообще здесь есть два параллельных направления: знания самой дисциплины и их применение в нужный момент.
Делиться знаниями не сложно - это например презентации, рассказы о своих исследования и результатах. Добиться чтобы знания повышали качество ежедневно принимаемых решений каждым человеком - более интересное дело 🙂
Все мы знаем, что у каждого есть своя репрезентация этого мира (карта), построенная из индивидуального опыта. Принимая решение человек выбирает наилучший вариант в рамках имеющейся карты.
И если эту карту представить как в т.ч. набор ассоциаций вопрос -> ответ, то развитие майндсета - это изменение и дополнение этих ассоциаций.
Рабочий же, на мой взгляд, путь - это открытые вопросы, которые мы друг другу задаём при обсуждении общих целей и непоняток на 1-1 созвонах. Они запускают внутренний поиск и дополняют карту его результатами.
Таким органичным образом, объединяя экспертизы свою и собеседника, формируется общее множество понятий, как расширение карты каждого. Формируется не быстро, каждый строит дорогу со своей стороны.
На это тоже можно влиять:
1/3 сначала добиться взаимопонимание по ключевым словам - что мы вкладываем одинаковый в них смысл
2/3 помнить, что спор - это ситуация когда люди не просто не соглашаются по теме, а именно не соглашаются друг с другом, осуществляя взаимный наезд; и работать в сторону понимания позиции собеседника.
3/3 по минимуму бросаться оценочными суждениями, т.к. они могут не попасть в карту коллеги
Челленджить друг друга на решения и гипотезы заметно проще, и, кажется, результативнее уже в пространстве общих понятий и взглядов.
По итогу это получается небольшой шаг от построения процессов и управления продуктовыми задачами в сторону сетевого взаимодействия. 🤜🤛
Пятница
@produnderhood Так, а нужно как-то пытаться создать "общую карту"? Как стимулировать людей расширять свои "карты"? И надо ли?
Я за то, чтоб это естественным образом происходило. Упрощенный пример - репортят в чью-то систему в 10 раз больше фича-реквестов чем человек может дать, спрашивают за них, написывают. Есть смысл, как случай выпадет, узнать - беспокоит ли это оунера системы. twitter.com/xiexed/status/…
Если нет - то скорее всего я узнаю что-то новое и полезное. Если да - побрейнштормим, найдём решение из совместного опыта.
А поделитесь своим топ-материалом по стратегии 🎮 Книги, статьи, видосы, что угодно
От себя назову Эдварда Люттвака:
"Стратегия. Логика войны и мира" - разбирает манёвры войн 20-го века на разных уровнях, выводя закономерности
"Cтратегия византийской империи" - в рамках тех же законов описывает как Восточная Римская империя почти на 1000 лет пережила Западную
Хэй, как праздники проходят?
Вспомнил ещё топ-2 - Франсуа Жюльен - французский философ, провёл сравнительное исследование китайской и европейской стратегической мысли. Основные труды:
- Трактат об эффективности
- Путь к цели: в обход или напрямик
Суббота
Привет! Предлагаю сегодня делиться мыслями о том, в чём секрет энергии кота Бориса 😼
Другими словами, что помогает сохранять мотивацию и боевой настрой в условиях ультра-многозадачности.
Тема не редкая, но раз решения, скорее, индивидуальны, то я за то, чтоб пробовать новое и развивать что нашёл для себя 🙂
В моём, например, случае это скорее про убеждения. Их сложнее принять, но в дальнейшем как-то проще получается - они сами строят поведение, реакции и эмоции
1/3 Итак, заклинание Первое: Я являюсь причиной всех следствий в моей жизни. Конечно не буквально, но как жизненная позиция прям вытягивает, когда возникают плохие эмоции или какая-то стрёмная ситуация.
Становится прям интересно - как я вообще здесь оказался. Включается внутренний исследователь и жизнь кажется лучше 😎
2/3 Заклинание Два: причина и следствие - поменяйтесь! По сути, обобщение первого. Например, про те же эмоции: я испытываю эмоцию не в результате событий извне, а конструирую события таким образом, чтобы испытать привычную эмоцию.
И если не ок, то опять - как часто это вообще происходит, какие договорённости привели меня сюда, техника 5-ти почему и др. =) Или ещё пример: супруг(а) регулярно проводит мало времени с семьёй, из-за завала на работе. 💼 Завал на работе - навожу порядок дома
Иными словами, что происходит - то и цель. Крайне полезная позиция. Применяется экологично, с наилучшими побуждениями.
3/3 В дополнение к прошлому - умный решает проблемы который мудрый не создаёт. 🎓
Если я нахожу себя в решении проблем - то полезно подумать - а как вообще эти проблемы ко мне пришли
Если я не в настроении и уставший сотворил какую-то дичь, то тема не в том, чтобы держать себя в руках, а в том, чтобы до плохого настроения себя не доводить. Я здесь кто в конце концов, причина или следствие?
Делитесь своими мыслями, приёмами и лайфхаками. Тема, кажется, будет актуальной всегда 🙂
Воскресенье
Привет! Сегодня хочу поделиться находкой, пришедшей во время работы по формулированию mission statement'а.
Прежде было много слов про JetBrains в целом, но работаю я конкретно в проекте Котлин. Это полноценный самостоятельный проект внутри JB. В ноябре 2020 года отмечал 10-летний юбилей от первого коммита. В проекте трудятся чуть более 100 человек.
Продуктовый вижен Котлина зрел пока в JB развивали IDE под Java и другие языки. Копилась экспертиза в области языков программирования, и неизбежно наступил момент когда мы решили написать свой - прагматичный язык для индустрии (и нас самих), агрегирующий накопленные знания.
Несколько месяцев назад во время очередного рефреша вижена, и пересмотра продуктовой стратегии, мы решили в первый раз на уровне всего проекта ответить на вопрос о миссии.
В принципе, все эти годы проект шёл вперёд и без сформированного стейтмента, его вели люди с боевым духом и горящими глазами. У коллег внутри был ответ о миссии, у каждого свой, и задача была скорее в том, чтоб его получить и агрегировать.
Зачем, мы стали этим заниматься:
- на текущем масштабе стала заметно проявляться разность во взглядах команд проекта на общее направление движения. Одним mission statement это не решить, но всё же шаг в эту сторону
- это хорошая проверка на culture-fit при хайринге в обе стороны
- при дальнейшем онбординге пришедшему иногда проще идти на контакт с коллегами из-за ощущения общего дела - опять же, на нашем масштабе эта потребность стала чувствоваться
- раскрытие вижена, помогающее в его дальнейших использованиях
Мы сформировали исследовательскую группу и скрипт для интервью с коллегами по проекту, где каждый рассказывал бы, что им движет, что мотивирует в работе над проектом и ради чего, на его/её взгляд, здесь вся работа происходит.
Решили опросить не всех 100+ коллег, но остановиться, когда ответы стабильно начали совпадать с высказанным ранее. Хотелось, конечно, продолжать, если б не время - многим, и нам самим, было приятно на время оторваться от конкретных задач и поговорить о таких общих и важных вещах.
Как результат получили стандартную канву, обработав которую нужно было дать несколько формулировок на итоговое суждение команде. Обрабатывать решили по-отдельности, для более разнообразного итогового списка.
В моём случае получилось три кластера, характеризующие нашу деятельность как:
- расширение во все области, становление там лучшими, захват мира 🙂
- принести удовольствие пользователям, сделать их счастливыми
- совершенствование продукта как явления и процесса его применения
Разбираясь с этим дальше, мне вспомнился труд Виктора Франкла "Воля к смыслу".
В нём, если кратко, Ницшеанская "Воля в власти" и Фрейдистский принцип удовольствия рассматриваются как производные по отношению к изначальной "Воле к смыслу" - базовой движущей силе человека.
Удовольствие - следствие реализации смысла; власть (лучший перевод - могущество) - предпосылка для его реализации.
Получается естественным образом интервьюируемые коллеги по проекту охватили все эти три понятия, и, кажется, стало ясным вокруг которого следует фокусироваться.
Сейчас вариации mission statement'а проходят командное ревью, наверное уже кто-то из моих коллег в последствии поделится результатом. Но что интересного было найдено - это работы В. Франкла, в частности, "Воля к смыслу", помогающие при работе над Виженом, Миссией и Ценностями.
На этом всё, если кто-то уже с этими работами знаком - дайте знать, насколько по вашему они актуальны для формирования вышеназванных артефактов организации 🙂
Всем привет! Сегодня буду делиться наблюдениями из индустрии про то, такое продакт- и что такое менеджмент в инженерной компании.
Моя неделя подходит к концу, спасибо всем! Кратко о том, что было:
история JetBrains и её принципы: twitter.com/produnderhood/…
развитие продуктологии внутри JetBrains twitter.com/produnderhood/…
о продакте и менеджменте в инженерных компаниях twitter.com/produnderhood/…
Привет! Сегодня хочу поделиться находкой, пришедшей во время работы по формулированию mission statement'а.
развитие продуктового майндсета в команде twitter.com/produnderhood/…
книжечки по стратегии twitter.com/produnderhood/…
о мотивации и убеждениях twitter.com/produnderhood/…
про mission statement twitter.com/produnderhood/…
На связи: @anton_yalyshev
Желаю бодрой недели, пока!
