Лет пять назад написал текстик, не помню по какому поводу. Но он мне все еще нравится.

Мне нравится наблюдать за людьми…
Вот идешь ты по улице, навстречу тебе бежит пацан, лет 7-8. И метрах в пяти от тебя он резго, как уткнувшись в стену, останавливается. И тело вроде еще, по инерции продолжает бежать вперед, а голова уже вертится, то ли разыскивая знакомого взрослого, то ли выбирая следующую точку, к которой толкает неугомонная энергия бурлящая внутри. И лицо такое шкодное-шкодное…

Мне нравится наблюдать за людьми…
Вот идешь ты по улице, навстречу тебе идет девушка, молодая, красивая, наряженная, даже не идет, а плывет. И проплывая мимо тебя, чуть замедляет шаг, позволяя тебе оценить и восхититься, окутывая тебя запахами и впечатлениями. И проплывает мимо, уплывая вдаль, оставляя тебя в состоянии, как у боксера после нокдауна, на счете 8. Только и можешь говорить, что у тебя все ок, и головой мотать, пытаясь восстановить пульс и осознание себя в здесь и сейчас…

Мне нравится наблюдать за людьми…
Вот идешь ты по офису, а на встречу тебе продакт менеджер, бодрый, с блеском в глазах, в глазах, где на заднем плане, за этим блеском, проносятся миллионы идей и целей, наносящих непоправимое улучшение и причиняя невыносимую пользу. Этот менеджер останавливается перед тобой, начинает размахивать руками, вываливает на тебя все свои мысли, знания, фантазии и идеи. А ты стоишь, в руке чашка кофе, который остывает потихоньку, улыбаешься и немного ностальгируешь. А потом просишь прислать все почтой, и удаляешься в туман, оставляя собеседника в недоумении и с выраженным чувством недосказанности…

Мне нравится наблюдать за людьми…

О правилах

У каждого человека есть свои правила, эдакий набор, по которому он живет. Причем, у большинства людей эти правила делятся на те, которые относятся к рабочему времени и на те, которые относятся к нерабочему. Иногда совпадает, иногда нет, но…

Я вот хочу рассказать о том, какие правила и принципы в работе есть у меня. Как бы это смешно не прозвучало. И попробую рассказать почему это так.

1 Люди во главе угла. Или, как модно говорить сейчас people first
Так и хочется спросить, сфигали. Я же не HR. попробую аргументировать. Многие, если не все компании декларируют найм «правильной, сильной команды». И у многих даже получается. Но. Нанять сильных людей - это даже не половина дела. Это в лучшем случае треть или четверть. Нанять, обучить, сделать из индивидуальностей команду, сделать так, что бы эта команда работала эффективно, и, не потерять людей в момент времени. И это задача не HR, это задача руководителя. И тут прямо масса мест, где можно облажаться. Можно нанять неправильных людей, можно не смочь сделать из них команду, можно не понимать, что сломалось у конкретного человека, и как ему можно помочь, что бы он вновь оказался «в ресурсе». Можно задушить движение вперед через переусложненные или неэффективные процессы. Можно не уволить токсика, который оказался в коллективе. Можно не развивать людей. Можно делать много разных прикольных штук, которые приведут к тому, что все усилия пойдут одним местом. Но современная технологическая индустрия, как я писал выше, уже перестала быть уделом одиночек. Это командная работа. Которая, в том числе зависит уже от индивидуальностей и силы каждого конкретного человека, включая руководителя. Ну и про кадровый голод помним. И про сроки пользы помним.
Кстати, срок пользы - прикольная тема. Вот, уволился у вас инженер. Пока вы его наймете, пока обучите, пока новый сотрудник поймет и разберется как тут у вас все устроено…и я сейчас не только про IT ландшафт или правила написания кода. Я еще и про процессы, коллег.. Глядишь, полгода и прошло.
2 Никто не умер
Мы все совершаем ошибки. И, на мой взгляд, невероятная ошибка наказывать за ошибку, простите за тавтологию, если это не привело к каким-то катастрофическим последствиям. Отдельно важно убедиться, что это было разовое действо, и из ситуации был вынесен урок. Или, другими словами, процесс обучения прошел успешно. Опять же, по опыту, набив шишку на себе, эффективность обучения повышается.
То есть - проблему идентифицировали, ошибку отработали, проблему закрыли, опыт аккумулировали. И пошли дальше.
3 Я начальник - ты эксперт.
Со мной можно и нужно спорить. Я в силу широкого кругозора, насмотренности, не являюсь экспертом в дофига чем. Поэтому во многих вещах я могу принимать решения исходя из опыта, ощущения прекрасного или того, что в английском языке называется common sense. И я при этом могу быть неправ. Или могу предлагать неоптимальное решение. Всегда признателен если мне на это укажут. Не надо занимать позицию «мама сказала в бидоне». Можно и нужно спорить, аргументировать. В спорах рождается истина. Любой человек может о чем-то не подумать.
4 Результат превыше процесса. Или Gettin’ shit done.
За исключением случаев, когда результат достигается с нарушением законодательства, регуляторных правил или за счет нарушения информационной безопасности.
5 Не обещай, если не можешь исполнить. Или, как вариант, «пообщал - сделай»
Когда ты отвечаешь за свои слова, отношение к ним тоже становится другим в твоей команде, да и у смежников. Карма имеет обыкновение накапливаться. Многократно сталкивался с ситуацией, когда сказанное «Да, сделаем», или «я обещаю» приводило к тому, что не смотря на все должности и регалии, слова человека, который несколько раз обещал, но не сделал, начинали восприниматься как что-то несерьезное. Ну, типа, опять пообщал.
Вместо этого что-нибудь типа «я сделаю все возможное для того, что бы это случилось, но обещать не могу» уже будет показывать, что ты (1) обещаешь приложить максимум усилий, но (2) зуб не даешь, что все получится.
Тут есть конечно ловушка, что если ты всегда обещаешь прикладывать максимум усилий без гарантии - тебя тоже могут начать считать пустобрехом. Поэтому надо периодически брать на себя обязательства, конечно.

Пример из жизни. Однажды, на большом срочном и тяжелом проекте, я пообещал одному из своих ребят премию за овертайм и важность проекта. И не смог ее выбить из компании. Так бывает. Корпоративные правила - они такие. Там тоже есть люди, которые, например, пообщали, например, бюджет экономить. Окей. Пришлось выплатить из своих.
Заодно, нельзя не отметить, это правило хорошо коррелирует с 1. Потому, что большая часть обещаний руководителя, направлены, в том числе, в сторону команды. А люди, как мы помним, first.

Продолжение следует...

Работа работа, перейди на Федота

Пробовал порассуждать тут на тему работы. Осознал.

Так вот. Я осознал следующее. Для меня составляющее работы мечты следующие:
1 Команда, частью которой я являюсь. За 30 лет, что я работаю в айтишечке, мне везло трижды. Что я называю везет, спросите вы? Спрашивали - отвечаю. Люди, с которыми я работал, остались в моей жизни. Остались и продолжают в ней быть, даже в тех случаях, когда нас раскидало в разные части этого земного шарика. Мне тут подсказывают, что это уровень культуры внутри компании, ну может и да. Качество людей? Наверное так.
2 Влияние на окружающее пространство. То, что я делаю, должно приносить пользу. Не компании и не бизнесу, который эта компания ведет. То есть, это конечно тоже было бы замечательно, но не обязательно. Должна быть польза вынесенная наружу. Некое «благо», или как говорят американцы - greater good
3 Эта работа должна приносить достаточный доход. Меркантильно, но честно. Я понимаю, что в современном мире быть меркантильным кю скорее грешновато, но у нас все-таки общество потребления. А потребление требует определенных затрат.
4 Там должна быть возможность учиться новому, и люди, у которых это можно делать. И люди, у которых хочется это делать
5 Баланс ответственности и полномочий. Компания должна делегировать не только ответственность, но и давать тебе инструментарий, чтобы ты мог эту ответственность нести. Например, полномочия.
6 Честность в отношениях между компанией и сотрудниками. Сюда включается много что. Для меня это прежде всего прозрачная обратная связь с руководством, понятные и не меняющиеся ежемесячно правила игры. Открытость коммуникаций.
7 Логичность действий. Когда я говорю про логичность, опять же, я говорю про то, что то, что мы делаем, смысл нашей работы и прикладываемых усилий последователен и небессмысленен. И в тех случаях, когда мы меняем вектор движения, это подчинено логике, а не желанию ЛПР. И эта логика доносится с необходимыми объяснениями.
8 Право на спор. Я в своем предыдущем посте писал, что я с большим уважением отношусь к коллегам которые со мной не согласны и если они считают, что я делаю что-то не так, они аргументировано доносят свою позицию до меня. Так вот, когда я говорю про право на спор, я имею ввиду, что мне будет комфортно работать с руководителем, который придерживается такого-же принципа.

А что вы имеете ввиду, когда говорите про работу мечты? Напишите в комментах, если вам не влом, например.

Не делайте так больше - часть 1

Проблема в том, что меня не учили управлять людьми. И строить команды не учили. Пришлось набивать шишки, иногда учиться на примере старших товарищей, иногда на собственных болях. Иногда принимать правильные решения, иногда нет. 
Поэтому, то, что я сегодня вам расскажу, это не учебник по управлению, это опыт. Тут обычно приводится шутка про то, что “В какой-то момент ты думаешь, что вот оно счастье, потом приглядываешься - ан нет, опять опыт”. Вот это как раз про меня. 


Часть первая, поучительная. 
Поучительная не в том смысле, что в ней я предлагаю поучиться тому, как не надо делать, наоборот, я планирую поучать. 
Про работу со знанием. 

И начать, на самом деле я хочу с тех вопросов, которые возникают со стороны команды в адрес руководителя, и, одновременно, служат признаком того, что не все в порядке с распространением знания.
Классические вопросы от сотрудника
1 Что мне нужно сделать, чтобы получить повышение (какой у меня следующий шаг в карьере)
2 Когда мне повысят зарплату? Что мне надо сделать, для этого
3 Как я работаю на фоне других коллег? На их уровне или хуже
4 А можно мне интересную задачу
5 Какой результат моего труда, какую пользу я наношу?

Если посмотреть, на то, как в корпоративной среде распространяются знания, то мы увидим довольно интересную картинку. Точка возникновения знания может располагаться либо на самом верху пищевой цепочки, либо в самом ее низу. 
Вы спросите, а где располагается “сферический менеджер в вакууме” в этой картине мира. А он располагается по центру. То есть, если оперировать терминологией той индустрии, в которой я имею счастье работать, на позиции ретранслятора. 
Знание, как и любой сигнал, имеет обыкновение рассеиваться, проходя расстояние. И если мы говорим про работу со знанием, то роль менеджера как раз состоит в том, чтобы поймать знание, пока оно не рассеялось, придать ему новой силы, и распространить дальше. 
Тут есть важный нюанс. Нельзя знание искажать в процессе передачи. Люди, существа довольно сложные, игра в испорченный телефон у нас в детстве у всех была. Всегда есть желание что-либо добавить к информации, или что-либо из нее убрать, как несущественное. 
Не надо так делать.

Не делайте так больше - часть 2

Когда меня спрашивают, чем я и моя команда занимаемся на работе, я обычно говорю, что превращаем информацию в знание. 
Существует несколько способов превращения информации в знания:
• сравнение— когда информация  сравнивается с другой информацией;
• последствия — когда выясняется, какие решения и действия могут быть приняты в результате использования данной информации;
• связи— когда определяют, как соотносится данная часть информации и знаний с другими частями;
Когда мы говорим о трансляции знания, на самом деле цепочка чуть сложнее, чем кажется на первый взгляд. 
Давайте рассмотрим простой частный случай “Знание-информация-знание”.

Персонифицируя этот частный случай, например в линейку Директор-менеджер-аналитик.

Директор вызывает к себе менеджера и говорит ему: По моим данным, продажи у конкурентов идут лучше чем у нас. Разберитесь, что у нас идет не так. 
Это знание. 

Менеджер идет к аналитику и заявляет ему: Директор утверждает, что у нас продажи хуже чем у конкурентов. Так ли это? И если да, то почему?
Это информация

Аналитик владея информацией, что по мнению директора наши продажи выглядят так себе, начинает сравнивать информацию из доступных источников, получая подтвержденный ответ на запрос менеджера. 
Превращая информацию в знание. 

Пример довольно теоретический, на практике все по другому. 
Давайте пройдем первый шаг. Что, по вашему мнению, не так с ним. На каком моменте знание превратилось в информацию?

А знание превратилось в информацию в тот момент, когда менеджер не выяснил детали. Для того, чтобы передать аналитику знание, в том же формате, в котором оно было в голове у директора, надо это знание оттуда достать. Типа вопросы позадавать. A’la уважаемый Иван Иванович, а расскажите, на основании чего вы говорите, что у нас продажи хуже. Нет, я в целом не оспариваю это утверждение, но для того, чтобы копать, надо понимать куда. И еще, полезным кусочком этого самого знания будет, например горизонт, когда у нас продажи стали хуже. Это на этой неделе, в прошлом месяце, или за первый квартал, например. 

Одна из больших проблем менеджеров заключается в том, что они боятся признать, что они что-то могут не знать. Ребята, за незнание не расстреливают, по крайней мере пока.  И вместо того, чтобы задать вопросы, уточнить, дополнить пазл недостающими элементами эти прекрасные люди говорят “Ага”, и бегут исполнять. Зачастую додумывая ту информацию, которую постеснялись спросить. Или вообще беря на себя роль передаточного звена. “Я не я и лошадь не моя”.

Второе замечание, на которое хочется обратить внимание в приведенном примере, это смена коннотации при передаче информации. Помните, я раньше говорил про искажение информации. Вот это оно. 

Как можно интерпретировать замену вектора вопроса. Изначально вопрос звучал “Конкуренты стали продавать лучше” то есть базовая интерпретация скорее всего будет похожа на “Там нашли серебряную пулю, которую мы не видим”. В измененном виде это читается как “Наши продажи упали, что пошло не так”. И, как вариант, мы получим от аналитика ответ не на тот вопрос, который был изначально. 

И это простая ситуация. Где всего три действующих лица и два звена передачи. На самом деле там есть еще обратное движение, когда отчет от аналитика едет к директору, но его мы рассматривать не будем. Аналитики они обычно очень хорошо работают с формулировками, и там все будет либо очень хорошо, либо никто ничего не поймет. В зависимости от того, какую цель себе аналитик ставил.

Не делайте так больше - часть 3

Так вот, возвращаясь к работе со знанием. 
Я для себя сформулировал следующие принципы
1 Задавай вопросы, пока не сложится картинка
2 Не переформулируй
3 Не занимайся интерпретацией, пока тебя не попросят
4 Будь готов отвечать на вопросы (см. п.1)
5 Не меняй вектор подачи
И этот алгоритм отлично применим к тому случаю (в том числе) когда знание возникает внизу. И это обычно знание о проблемах. Так получилось, что проблемы в целом лучше видны с этого ракурса. 
Давайте попробуем предположить, какие проблемы обычно попадают в топ3 в среднестатистической технологической компании.
Ну, если брать инженерный состав и выражаться их языком, то это будет выглядеть наверное так
1 Заказчик идиот (тут можно вместо слова Заказчик подставить * менеджер)
2 Это не будет работать
3 Я ухожу
На самом деле, по формальным признакам, это конечно не знание, это информация. И для того, что бы с этим что то сделать, например превратить в знание, нам помогут все те же шаги.
Мы начали с того, что признаком недостатка знания у сотрудника является определенный список вопросов. И какие же классические вопросы со стороны руководителя характерны для этой-же ситуации. 
Классические вопросы от руководителя 
1 Что нам для решения задачи надо сделать…
2 Когда будет готово...
3 Почему ты решил уйти?

Ладно, выше была лирика, а теперь поговорим о прикладных вещах. Раньше, когда вы были специалистом, вы знали только свои задачи и на вас давили только ваши дедлайны. Теперь вы знаете о задачах всей команды, дедлайны нависают с нескольких проектов, и еще при всем при этом надо заниматься взаимодействием людей в коллективе. 
Но как бы вы ни планировали свои задачи в течение рабочего дня, время конечно. Поэтому вы никогда и ни за что не сможете сделать все за всех. Так что ключ к управлению вашим временем — это делегирование.
В целом правильное делегирование задач — это, наверное, самая сложная история, с которой сталкиваются начинающие управленцы. Мало кто от природы обладает навыком распределять задачи, но этот навык очень важный и его можно довольно быстро приобрести.
Мне больше нравится подходить к теме делегирования не в формате хороших советов, а «от обратного», разбирая неудачные кейсы.
Почему у многих не получается делегировать задачи? С точки зрения руководителя бывают две ключевые отговорки:
1 Я вот передам задачу, а он мне столько вопросов задаст, что проще сделать самому.
2 Что ни поручи — все равно сделают хуже, чем я! А мне потом переделывать
Первый вопрос, который надо задать себе в этом случае, является ли задача разовой или типовой. Если задача ну совсем экзотическая, то, возможно, не стоит тратить время на обучение и быстрее все сделать самому. Но если задача типовая и сотрудник с вами надолго, точно стоит один раз потратить время на обучение. Дальше, надо убедиться, что задача по силам тому человеку, которому вы хотите ее поручить и что вы четко оговорили сроки и критерии выполнения.

Не делайте так больше - часть 4

И тут мы обратно возвращаемся к управлению знаниями
Отчего возникают вопросы?
• Есть опциональность решения
• Нет образа результата
• Непонятен контекст
• Не хватает компетенций
И если с последней частью мы ничего сделать не можем, ну, во всяком случае быстро, и тут имеет смысл подумать о другой кандидатуре, то с первыми тремя пунктами мы можем провести подготовительную работу, и, как вариант, если ответы на вопросы у нас уже есть, то поделиться ими, а если нет то либо подготовиться, и потом поделиться, либо попробовать найти ответы на задаваемые вопросы вместе.
Вопросы возникают еще и потому, что вы могли плохо объяснить детали задачи. Понятно, что если вы поручили задачу эксперту, он, скорее всего, сам справится. И то, скорее всего сначала скушает вам мозг уточняющими вопросами. А вот средних и младших сотрудников плохо поставленная задача может выбить из колеи. Человек не может понять, какие условия более важны, а какие менее, и боится упустить важное. Обратите внимание на то, насколько подробно и точно вы описываете поручения. Четко обозначьте сроки, разбейте задачу на части, если она слишком большая, определите понятные для вас и для сотрудника критерии выполнения.
Бывают случаи, когда оба условия выполнены, задача понятна и сотрудник точно умеет делать порученное, но почему-то все равно возвращается с вопросами. Это означает, что человек по какой-то причине боится брать на себя ответственность. Причины могут быть разные. Например, он банально не уверен в себе. Ему кажется, что он не может сам принимать верные решения и все, что он сделает самостоятельно, будет так себе. В этом случае надо в какой-то момент вежливо перестать отвечать на вопросы и сказать: «Решай сам, ты все умеешь». Со временем человек привыкает и страх новичка проходит. Это позитивная причина для лишних вопросов.

Перейдем ко второму препятствию делегированию — ситуации, когда вы думаете, что все сделаете лучше всех и незачем поручать задачи кому-то еще. 
У меня в голове для этого есть несколько возможных причин. 
Лень. Даже не так. В условиях когда нет идеального исполнителя для задачи, вы подкоркой понимаете, что вам придется потратить свой ресурс для того, чтобы объяснить что именно надо сделать, как, зачем, да и вообще, какой результат должен получится.И это займет едва ли не больше времени, чем сделать самому.
Перфекционизм. И в мозгу свербит: зачем мне передавать дело кому-то, кто все сделает не идеально? Я уже выполнял задачи подобного рода, у меня есть все составляющие понимания и скиллов, для того, чтобы сделать задачу. Придется проходить несколько итераций… Тут важно понимать, что в современном мире перфекционизм оправдан только в некоторых специфических областях, большую часть бизнес-задач можно и нужно выполнять «достаточно хорошо» и не стремиться к идеалу. И опять же, если не передавать задачи, так самостоятельно и придется все делать.
Здесь надо поработать над собой и научиться жить в не идеальном, но зато производительном мире. Вам надо принять то, что силами команды вы сможете сделать гораздо больше, пусть выполнение задач будет и не столь совершенным, к какому вы привыкли.

Третья, и в моем случае очень важная история, она про “надоело работать языком и power point-ом, хочется руками что то поделать, а то разучусь и мхом порасту”. А потом останется только накрыться простыней и ползти на кладбище. И, ну так у меня в голове все это устроено, эта история является той самой причиной, которая может послужить валидным оправданием к “сделай сам”.

Не делайте так больше - часть 5

Чуть расширяя терминологию, хочется сказать, что есть едва уловимая разница между понятиями «передать задачу» и «передать ответственность». Делегирование учит нас, как передавать задачи. Но хотя задачу выполняете не вы, ответственность за нее все равно может почти целиком лежать на вас. Причем как за провал, так и за успех. Иными словами, если проект «взлетел», кому-то полагаются лавры, и в случае простого делегирования вы можете присвоить все заслуги (подумайте, как при этом будут чувствовать себя исполнители). Если мы нацелены на выращивание в команде руководителей или просто хороших специалистов, надо учиться вместе с делегированием перекладывать и ответственность за результат. Во-первых, это хороший мотиватор и признак доверия. Ведь мы хотим, чтобы людям нравилось выполнять сложные задачи и решать проблемы самостоятельно, потому что в случае успеха они смогут удостоиться благодарности или награды за проделанную работу. Какие условия важно соблюдать:
• Человек должен быть вправе сам, без вашего участия, принимать важные решения при выполнении задачи.
• Вы публично оговариваете ответственность человека за работу.
• Вы уважаете его право принимать решения и понимаете, что не все может быть по-вашему, если при этом результат соответствует базовым критериям.
• Вы публично признаете вклад работника в решение задачи.
• Вы признаете его право на ошибку.
Тут важная история. Про право на ошибку. Люди ошибаются, это факт. И люди боятся этого. Люди выбирают консервативный путь решения задачи как раз потому, что в осознании возможности совершить ошибку они придумывают себе последствия. Придумывают, потому, что не знают ответа на вопрос, что произойдет в тот момент, когда и если они эту ошибку сделают. И задача руководителя в тот момент, когда вы делегируете задачу, когда отдаете ответственность за ее выполнение своим коллегам, работать со знанием, оставляя меньше пространства домыслам.

Суммируя все вышесказанное. Знание - это то, что пронизывает в целом взаимоотношения в команде, в компании, напрямую влияя на эффективность работы, на ТТМ. Знание - это то, что позволяет компании бежать в одном направлении, не теряя точку фокуса. И, наконец, знание - это то, что создает нормальную, рабочую атмосферу, не оставляя места фантазиям и домыслам.
На самом деле работа со знанием и делегирование это всего две грани многогранника под названием командное взаимодействие, но они важны, и важны прежде всего тем, что это точка начала. Начала команды. В тот момент, когда вы не замыкаете знание только на себя, распространяя его внутри команды, вы позволяете всем вокруг осознать, что в настоящий момент является точкой фокуса, точкой приложения усилий для группы индивидуумов, как ее не назови. И делегирование, только грамотное, осознанное, а не “на тебе задачку”, это отличный инструмент и для роста людей, и для распространения этого самого знания.

Простите за много букв

Ой, я тут нашел в загашнике классный артефакт из прошлого. Однажды я договорился с нетологией, что мы сделаем совместную программу Рамблера и Нетологии по управлению продуктами. И прекрасная Катя Текунова при посильном участии меня и Ксюши Аникеевой сделала на мой взгляд шикарный lineup того, что из себя представляет профессия продакта, из чего она состоит и чему надо учить будущих экспертов по управлению продуктами.

PS - мы даже такой курс сделали. Было клево.

Запостить сюда этот лайнап?
Пишите в комментах.

- Что общего между 20 сентября 2011 и 18 декабря 2024?

- запуск yandex.com.tr :)

Когда мы делали курс по управлению продуктом для Нетологии, мы формировали его следующим образом:

Часть 1
• Цикл создания продукта. Навыки и качества продакт-менеджера. Как выглядит идеальный продакт. Уровни продактов и типы продактов (совмещение). Откуда приходят в продакты. Типичный день из жизни продакта 
• Как применяется знание рынка в продукте. Способы поиска и обработки информации. Конкурентный анализ, методы и процессы. Мониторинг отзывов. Исследование продукта. Использование продукта. Наблюдение за обновлениями. Стратегия конкурента
• Сегментирование аудитории. Определение ключевых потребностей сегментов. Построение сценариев удовлетворения потребностей.
• Основы работы с инструментами User Stories и Job Stories/Jobs-to-be-done.Применение этих инструментов при создании продукта. Создание story map.
• Что такое профили пользователей. Зачем нужны профили пользователей. Как создавать профили. Как применять при создании продуктов.
• Основы Customer Development - Понимание проблем пользователя — один из самых важных моментов при создании нового продукта и совершенствовании старого. Как понять проблемы и боль пользователя и улучшить продукт именно для него? Способы проверки идеи на любой стадии жизни проекта: от момента зарождения до реализации готовой системы. Методы исследования и проверки гипотез. 
• Глубинные интервью: в чем особенность; зачем нужны продукту; методология проведения интервью. Как систематизировать и применять полученные данные? Примеры опросов и их применение
• Фокус Группы - В чем особенность. Зачем нужны продукту. Как проводятся. Как систематизировать данные. Как применять. Инструменты. Примеры опросов и их применение.
• UX тесты и usability - Формулирование гипотез на тестирование. Сбор требований к респондентам. Создание сценария для юзабилити-тестирования. Проведение тестирования. Анализ полученных данных.
• Customer Experience - Понимание своего пользователя — чем он живет и как справляется с задачами, в которых мы хотим помочь, — ключевой навык менеджера продукта. Карты клиентского опыта помогают “упаковать” это знание, делиться им с командой и использовать как источник продуктовых решений. Как это работает, будем разбирать на примере customer journey map и service blueprint.
• Что такое дизайн-мышление. Как генерировать сильные бизнес-идеи. Как находить инсайты и строить на их основе бизнес-гипотезы. Как применять дизайн-мышление для проверки идей. Как системно применять дизайн-мышление в бизнесе
• Управление ценностью продукта - Отличие продукта без ценности от продукта с ценностью. Как узнать ценность продукта и донести её до клиента. Как создать ценность на основе потребностей клиента. Как формировать product-market fit: целевая аудитория — проблема — решение.
• Обзор базовых моделей монетизации и их примеры, обзор основных KPI. Поведенческая экономика: как повысить средний чек, как повысить конверсии в платящих, как заставить пользователя вернуться
• Экономика продукта - unit экономика, PL, финансовые метрики и способы работы с ними, бюджетирование
• Работа над MVP. Проверка гипотез минимальными затратами. Удаление лишнего. Поиск баланса между фичами и жизнеспособностью. Метрики. Процесс.

Часть 2
• Приёмы и трюки для увеличения конверсий. Growth hacking
• Вовлечение - Онбординг. Поддержка пользователей и обучение команды саппорта. Настройка способов сбора обратной связи. Багфиксинг. Обучение пользователя пользованию продукта. Мотивация пользователя на дальнейшее использование продукта, возврат в сервис.
• Какие бывают документы в жизни продакта, зачем они нужны и как они помогают: описание продукта. Чеклисты (какие бывают и что в них входит). Дашборды. Карты user flow. Карты экранов. Прототипы. Карточки персон.
• Как ТЗ влияет на результат продакта (эффективность продукта и скорость). Принципы создания технического задания. Состав ТЗ, что необходимо, а чем можно пренебречь. Согласование ТЗ и его изменений. 
• Управление продуктом в гибких методологиях (Скрам, Канбан и пр.) Управление продуктом в классических методологиях. Lean-подходы к управлению проектами и продуктами.
• Стратегия развития продукта - Что такое стратегия. Зачем нужна стратегия. Как выстроить стратегию развития продукта. Можно ли менять стратегию? Как использовать продуктовую стратегию в применении к разработке продукта.
• Что такое дорожная карта, зачем и всегда ли она нужна. Как создавать roadmap в условиях быстро меняющегося рынка, внешних зависимостей и гибких методологий. От стратегии к тактике: от роадмапа к продуктовому плану и плану разработки.
• Формирование бэклога: поиск, формализация и проверка идей. Техники приоритезации.
• Какие метрики бывают. Как метрики помогают управлять продуктом. Чем измерять поведение пользователей. Обзор инструментов web и mobile.
• Когда и зачем нужны внутренние системы аналитки. Какие данные необходимо собирать самостоятельно. Как и где хранить данные. Как с ними работать. Кто для этого нужен. Какие инструменты визуализации данных бывают.
• Метрики - LTV. Воронки продаж. Возвращаемость, Удержание. Период принятия решения. Время на сайте, глубина просмотра. Конверсии. Типы трафика и их влияние на метрики, Как придумывать лучшие идеи на основе воронки, когорт, ретеншна, логов. 
• Системный подход к AB тестам — как его провести. Хаки, позволяющие выжать из ABT максимум. Где брать вдохновение для экспериментов. Культура экспериментов и влияние на продукт
• Метрики мобильной аналитики. Инструменты мобильной аналитики. Когорты и сегменты пользователей мобильных устройств.
• Взаимодействие с членами продуктовой команды - Типы личностей и взаимодействие с ними. Управление конфликтами, Лидерство и мотивация
• Результат работы дизайнера (макеты, прототипы, гайдлайны). Особенности работы с дизайнерами (как выстраивать коммуникацию и доносить задачи). Типы дизайнеров, зоны ответственности. Процессы в дизайне (авторский надзор, установочные встречи, следование гайдам и пр.). Принципы создания гайдов, польза и вред гайдов.
• Особенности работы с привлеченным трафиком. Особенность продукта в маркетинговых мероприятиях. Продукт и бренд.
• Донесение ценности до пользователей. Рассказ про новые продукты. О чем говорить, о чем нет. Продуктовые Инфоповоды. PR
• Взаимодействие с заказчиками (руководство, маркетинг), Как правильно доносить идею, презентовать результат.
• Собеседование на менеджера продукта. Как вас будут нанимать, взгляд со стороны нанимающего менеджера. Ожидания, реальность, примеры.

Мне до сих пор эта программа кажется хорошо и правильно выстроенной (мы на нее грохнули дофига времени)

Не благодарите

Однажды я придумал пирамиду мотивации, теперь всем про нее рассказываю.
Ну как придумал. Посмотрел назад и написал 🙂
- Сначала, на старте своей профессиональной деятельности, человеку интересно найти свою работу. Доказать, прежде всего себе, что он интересен как специалист.
- Второй ступенью, хочется денег. Денег для того, чтобы обеспечивать свои потребности. И еще немного сверху, а потом еще немного на сбережения и излишества.
- Затем хочется признания. Доска почета, общественное мнение.
- Четвертой ступенью мотивации идет карьера. Причем как в сравнении с другими (Вася директор, а я нет), так и для самоуважения.
- Пятой ступенью идет новые знания, новые отрасли. Такой вызов себе - я уже добился успеха и денег тут, смогу ли я показать себя где-то еще.
- Шестой ступенью идут новые знания - тут я уже все знаю, умею. Пойду, добавлю себе ценности в смежных областях.
- Седьмая ступень - учить других. Я не просто достиг, знаю и умею. Я научил других, они тоже достигли, знают и умеют.

Переход на каждую следующую ступень не убирает остальные из мотивации - просто уменьшает их вес.

На правах не рекламы, но личных рекомендаций.
Мне очень нравится книга, которую написала Марина Перескокова - «Мама, я тимлид». Нравится настолько, что я, в какой-то новый год, всем своим лидам положил ее под елочку.

Короче, если вы работаете в IT, видите свое развитие как раз в управленческую вертикаль, или наоборот, недавно стали руководителем, прочитайте книгу. Ну и заодно насладитесь прекрасными иллюстрациями Кирилла Анастасина (@komikaki).

Авиарезультаты 2024 года

114 дней не в Москве (в прошлом году 112)
40 перелетов (в прошлом году 41)
Самый короткий перелет - 272 мили (в прошлом году 316 миль)
Самый длинный перелет - 2 309 миль (в прошлом году 1753 мили)