Зачем разработчику знать о продакт-менеджменте?

Привет! Меня зовут Константин Берлинский, я разработчик в БКС. Некоторое время назад я прошел курс продакт-менеджеров. Детальнее об этом можно прочитать здесь. Но сейчас не об этом. А о том, чем знания о продакт-менеджменте и стартапах полезны разработчику в корпорации даже если он не планирует создавать свой продукт или становиться продактом.

Итак, из чего состоял курс, что было на его 24-х занятиях и почему это полезно разработчику, а не только будущему продакту.

Было: Суть продукта. Жизненный цикл. Задачи менеджера продуктов. Продукт vs проект.

Полезно: Для разработчика крайне важно знать продукт, который он делает. За это тупо больше платят. Конечно, можно прикинуться чайником. Строго следовать ТЗ и не делать ничего сверх того, что прописано в спеке. Заворачивать все доп хотелки клиента и не приступать к работе пока техлид не пропишет в тикете все детали вплоть до ширины отступов на UI. Но, сюрприз-сюрприз, с таким подходом вам никогда не подняться выше уровня Middle developer. Есть программисты, которые гордятся своим неумением общаться с командой и клиентом. Конечно, есть исключения. Но если вы не Шелдон Купер в IT, лучше включить эмпатию и разобраться как устроен продукт, кто в нём участвует, чем они занимаются, что для них важно и почему. В одном из проектов клиент стал писать кипятком от счастья, когда на список фич, которые надо сделать, я спросил о приоритетах. А затем предложил поменять их, т.к. одни задачи блокировали другие. А некоторые были некорректно сформулированы, из-за чего возникли бы ошибки в бизнес-процессе. А самый большой фейл я совершил когда сделал большой рефакторинг без согласования с клиентом, т.к. наш ПМ и ПМ клиента были в отпуске. Клиент отказался за это платить, т.к. это не несло business-value продукту.

Было: Определение гипотезы. Постановка целей по SMART. HADI-циклы.

Полезно: «Кто не знает, в какую гавань ему плыть, для того не бывает попутного ветра» — сказал Луций Анней Сенека, наставник Нерона, но любим мы его совсем не за это. Гипотезы — это про приоритеты. Что делать сначала, что позже, а что никогда. Приоритеты влияют на скорость проекта. Скорость — на попадание в сроки. От сроков сдачи проекта зависят зарплаты, премии и прочие плюшки. Это как в тетрисе. Есть 20 фигур, которые за минуту нужно уложить в стакан. Фигуры все разные. Их площадь (число квадратиков в каждом) известна. Суммируем площадь — они должны легко влезать впритык друг к другу, даже место остается. Но… не влезают. Потому-что, сюрприз, они влезут если их укладывать в правильном порядке. Поэтому опытный разработчик делает задачи в таком порядке, чтобы максимально не тормозить работу коллег. Если нужно сделать Web API — сначала договаривается об интерфейсе и делает заглушки методов, чтобы фронтендеры могли вызывать API, а потом дорабатывает тело методов. Если занимается БД, то как можно быстрее заводит таблицы, чтобы их могли использовать на бэке, а вьюшки, индексы и прочую обвязку делает позже. Если пишет документ, то выкладывает драфт для ознакомления ASAP, а не публикует за 5 минут до дидлайна, как ему кажется, на 100% идеальный документ.

Было: Командообразование. Agile. Kanban.

Полезно: Это must have скилы для программистов и не только. Современные ИТ-продукты делаются командами. Не умеешь работать в команде — добро пожаловать за борт в увлекательный мир фриланса. Трудно представить себе разработчика, который не слышал про гибкие методологии. Все эти скрам-митинги, эстимейты, ретроспективы, роли в команде, GTD/Zero inbox, статусы тикетов в Jira/Redmine и прочий GitFlow.

Было: Обзор реальных продуктовых задач. Презентации кейсов участников.

Полезно: Казалось бы. Зачем программисту знать, как решали вопрос низкой рекламной конверсии, повышения среднего чека или виральности привлечения клиентов? Простой ответ. Problem solving skills — навыки решения проблем. То, на что молятся рекрутеры последние лет 10 и что встречается в каждой второй вакансии в США / ЕС. Чужой опыт никогда не бывает лишним. После озвучивания проблемы лектор предложил обсудить, как участники курса решили бы ее. Включать мозги и учиться на чужом опыте никогда не бывает лишним.

Было: Оценка рынка и анализ конкурентов.

Полезно: Неочевидные для программиста знания. Таблицы со списком фич, SWOT-анализ, TAM/PAM размеры рынка — зачем это? Да вроде и незачем пока в проекте вы не решаете вопрос о выборе технологического стека. Или думаете, что необходимо немедленно переходить на самые свежие версии библиотек как только они вышли (нет). Или решаете, в какой университет поступить. Или на каком языке писать свои первые проекты. Короче, принимаете стратегическое решение, которое определит вашу судьбу на годы вперед. C# или Java? Angular или React? MSSQL или Oracle? App store или Google Play? Native mobapps или QT/Xamarin? Visual studio, WebStorm или Visual studio code? Мне до сих пор стыдно за кейс с одним заказчиком. Он искал подрядчиков на разработку с нуля крупной ERP-системы. Наша компания предложила ему команду и стек — Silverlight. За 1.5 года мы сделали продукт и тут Microsoft объявил, что перестаёт поддерживать Silverlight. Фаталити! Готовую, отлаженную систему можно выкинуть на помойку. Только на разработку клиент потратил 10 чел * 18 мес * среднемесячную оплату с учетом налогов, скажем 3 тыс $ = 540 тыс $. Пол-ляма псу под хвост! А если добавить недополученную прибыль с учетом разработки новой системы (компания в год зарабатывает ~ 10 млрд евро), представим ущерб от принятого решения. Вопрос касается не только ИТ. Блондинки или брюнетки? Купить квартиру или арендовать? Жить в городе или в пригороде? Пойти голосовать или поехать на дачу? В какой компании работать? Переезжать в столицу или оставаться в родном городе?

Было: Методы описания ЦА. Сегментация.

Полезно: Открою страшный секрет. Ни один клиент в мире не платит программисту за то, что ему просто нравится смотреть, как тот стучит по клаве, гуглит стековерфлоу, пьет кофе, обсуждает с коллегами принципы полиморфизма и подаёт умные реплики на конференс-коллах. Клиент платит за решение своих проблем. Поэтому знать и уважать своего клиента стоит как минимум за то, что он платит вам деньги. Без клиента вы просто бесплатно пишете приложения для удовольствия. Такое милое домашнее хобби, вроде собирания марок или выжигания на дереве.

Было: Customer development (исследование клиентов через проблемные интервью).

Полезно: Вроде предыдущее занятие было о клиенте. Зачем ещё одно? Надо Федя, надо! Здесь речь об интервью. С клиентом нужно разговаривать. И это мало кто умеет делать. Не давить своим мнением, не подсказывать ответы, спрашивать о прошлом, а не о будущем, узнавать конкретные цифры, а не пожелания, прояснять неопределенности, иметь план беседы и фиксировать договоренности, больше слушать, меньше говорить. По кастдеву ничего лучше книги Роба Фицпатрика «Спроси маму» ещё не написано. И у меня даже есть рецензия на неё. Внезапно, говорить в формате кастдева можно не только с клиентом, но и с коллегами.

Было: Поиск респондентов. Формулирование вопросов. Customer Development на практике.

Полезно: Чтобы стать хорошим интервьюером, к сожалению, ещё и надо проводить интервью. Я прекрасно говорю на английском, со всеми герундиями, могу распознать сленг и подражать любому акценту, зажигательно шучу и понимаю тончайшие нюансы языка. Но это в голове. На практике это звучит так: «Икскьюзми. Вериз эээ ниарест шоп? Шоп виз продуктс? Чип нот, блин как дорогой, а, точно, экспенсив!». Теория без практики не работает. Очень травмирующий для психики любого программиста-хикки опыт — поиск респондентов для интервью. Get out of the building и прочие дела. Физически сложно себя заставить вхолодную позвонить в незнакомую компанию и попросить об интервью или предложить услугу. Или на улице спросить о чём-то. Но что не убивает, делает нас сильней. Телефонный звонок вас не убьёт. Главное не звонить во время дождя и не прятаться под деревьями.

Было: Интервью, опросы, фокус-группы, эксперты, вебвизор, тайный покупатель, А/Б-тесты.

Полезно: Для того, чтобы принять решение, нужны аргументы. Для аргументов нужны факты. Факты основываются на цифрах. Цифры получаются в результате исследований. Разные виды исследований одного и того же дают более реалистичную картину. Почему это нужно разработчику? Мы живём в очень жестоком мире. Уже нельзя, как в каких-нибудь семидесятых, зайти к шефу и попросить выделить $152 млрд для высадки на Луне чисто позырить, хотя и в телескоп всё прекрасно видно. Если предлагаешь рефакторинг, лучше в цифрах показать профит от него. Например, ускорение запросов к БД в X-раз, уменьшение дублирования кода и ускорение внесения изменений или фикса в Y-раз. Покупку решарпера — обосновать ускорением кодинга в Z-раз. Бесплатную пиццу по пятницам — улучшением командного духа в 100500+ раз.

Было: Метод 6 шляп, Уолта Диснея, глупой коровы, обратной генерации, фокальных объектов, ТРИЗ.

Полезно: Моё любимое занятие. Как сказал один умный человек: «Программирование — это изобретение по требованию». В ИТ без этого никуда. Сколько уже раз сталкивался с казалось бы неразрешимой проблемой, а после озарения находил изящное решение. Как выяснилось, народ придумал кучу способов стимуляции креатива. Рабочий способ — объяснить проблему коллеге, попросить совет и в процессе обсуждения найти пару-тройку альтернатив. Нужно больше общаться. Хорошо «переспать» с мыслью и наутро подсознание находит решение или же заняться физической активностью (плаванием) и в процессе размышлять об идее.

Было: Составление ЦП. Lean Canvas, Value Proposition Canvas.

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

Было: Виды и построение бизнес-моделей. Business Model Canvas. Монетизация продукта.

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

Было: Роадмап. Диаграмма Ганта. Стратегия. Release Plan. Product Backlog. Development Backlog.

Полезно: Эта скорее для техлида и проектного менеджера. Функциональность релизов, дидлайны и майлстоуны, риски, учёт имеющихся ресурсов, загрузка людей и планы по завоеванию мира.

Было: Виды MVP (Минимально жизнеспособный продукт). AIDA и 4U при создании лендинга.

Полезно: Для продакт-менеджмента суть MVP в создании прототипа продукта для проверки спроса быстро и дёшево. Как это относится к разработке? Дело в том, что программистам ставятся задачи, но часто не конкретизируется как именно эти задачи должны быть решены. Поэтому хороший разработчик старается экономить ресурсы и делать задачу минимальными усилиями, т.к. приоритеты могут поменяться, а дидлайн никто не отменял. Если сказано сделать редактируемую таблицу данных, то не стоит делать контрол, который будет уметь отображать любые виды данных включая пивот-режим, функционал Excel и выгрузку данных в любые форматы. Принципы YAGNI, KISS и грех преждевременной оптимизации именно об этом. И никогда, слышите, никогда не делайте в одном тикете задачу и большой рефакторинг! (плачет).

Было: Теория ограничений. Узкие места.

Полезно: Вот это прям ТОП при оптимизации скорости работы программы. Для продактов речь шла об оптимизации самой узкой части воронки. Для айтишника зачастую необходимо увеличить скорость отклика — загрузку страницы, формирование отчёта, выгрузку файлов. Для SQL есть план запроса, кэширование и другие техники оптимизации. Всегда стоит улучшать самое узкое место в системе. А для этого нужно замерять этапы процесса, логировать тайминг и принимать решения на основе цифр, а не ощущений вида «перепишу с LINQ на хранимку вроде должно помочь».

Было: Построение и использование Customer Journey Map.

Полезно: Признаюсь. Программировать — прикольно, писать документацию — скучно. Посередине лежит проектирование интерфейсов (UX, не путать с UI). Это скорее прикольно, чем скучно. Набросать в Визио интерфейсы, продумать сценарии использования, прописать бизнес-правила. Если хотите вырасти из разраба в лида, ПМа, аналитика, продакта или архитектора, лучше освоить эту технику. Я уже не говорю, что зачастую требования к ПО поставлены достаточно размыто, а то и без макетов UI вообще. Поэтому спроектировать самому сразу приличный интерфейс, своевременно разрешить логические нестыковки в бизнес-логике здорово сэкономит время и отразится на удовлетворённости вашей работой.

Было: Сценарии. Основы UX. Landing page. CJM.

Полезно: Здесь была практика UX. Оказывается, я отстал от жизни. Веб-страницы народ давно верстает в Tilda, Figma и, прости господи, Тинькофф. А диаграммы и UX-прототипы делают не в Visio, а в Google Drawings, Draw.io и LucidChart. Для основ правильного дизайна (отступы, визуальные блоки, шрифты, акценты) мне понравилась книга Влад В. Головач «Дизайн пользовательского интерфейса: искусство мыть слона». По ссылке вторая версия, я читал первую, она лучше.

Было: Ключевые метрики, настройка, сбор.

Полезно: Принимать решения на основе данных — полезная штука. Data is the new black, Data-Driven Decision-Making и все такое. В классных ИТ-компаниях разработчики привыкают всё измерять и оперировать кучей данных — результатами запуска тестов, деплоя на сервер, проверками качества кода, прогрессом закрытия тасок в Jira и прочими.

Было: Собственно, Unit-экономика.

Полезно: Суперполезная тема для продактов. Зарабатывать на продаже единицы товара вы должны больше (в 3+ раз), чем тратить на производство той же единицы. Какой можно привести аналог для разработчиков? Не знаю. Всё-таки, программисту ставят задачу сделать функционал уложившись в квадрат скоуп-сроки-деньги-качество. Сколько же та или иная фича принесёт денег в сравнении с затратами на её производство определяется продактом и выставленными им приоритетами задач.

Было: Методология запуска продукта. Генерация продуктовых улучшений.

Полезно: Опыт всегда полезен, а опыт работы в кровавом энтерпрайзе полезен вдвойне. Есть такое мнение, что фрилансеров-одиночек не очень любят привлекать к работе корпорации, особенно для высоконагруженных легаси-систем. Дело даже не в NDA, неумении работать в команде, неудобстве удалённого общения и какие там ещё есть типовые проблемы с аутсорсом. Просто в живой системе есть нюансы, о которых фрилансер может и не задумываться. От бюрократии до совместимости интеграций и удобного временного окна для развёртывания. Не говоря уже о проблеме обновления БД в реалтайме, версионности API и пр.

Было: Механика оценки продуктовых решений.

Полезно: Это было продолжение предыдущего занятия. Только с уклоном в интенсивную практику, генерацию гипотез, назначение задач и отслеживание результатов. Короче, операционка. Для хорошего разработчика здесь было бы полезно понять, что работа никуда не убежит. Задач, которые нужно сделать вчера, приходит по паре штук в день. Одна из них появится в момент, когда уходишь с работы и напоследок проверяешь почту. Что важен work-life баланс. Что бывают моменты когда надо просто взять и сделать невзирая на время суток. Но не менее важно не погрязнуть в рутине и не выгореть за пару месяцев. Что можно задержаться на работе на 4-6 часа сверх нормы, но это означает, что на следующий день производительность труда будет в лучшем случае 50-70%, поэтому постоянные переработки бессмысленны.

Было: Методы MVP - приоритизации, I.C.E / RICE, Binary - приоритизации, периоду окупаемости.

Полезно: Хорошая тема, т.к. разработчикам постоянно приходится давать оценки трудоёмкости задач. Это не так просто как кажется. Постепенно можно навостриться делать более-менее адекватные эстимейты чтобы не облажаться больше, чем на 20%. Но обычно такие цифры не нравятся ПМу. Это сложно, т.к. есть взаимозависимые задачи, фактор знакомства с конкретным участком кода и/или технологией, прессингом ПМа для снижения сроков, т.к. «он раньше был разрабом и помнит, что это просто», размытой спекой (обожаю, когда в процессе разработки аналитик дописывает новые пункты), субъективным мнением «UI выглядит ОК или надо доработать», желанием не выглядеть глупо по сравнению с остальными и поэтому резко снизить свою оценку, давлением коллег, спущенной сверху рекомендацией «мы уже подписали договор с клиентом на точную сумму и сроки» и др.

Было: Типы презентаций. Советы по выступлению. Тестовые прогоны докладов.

Полезно: Опять же. Если вы не планируете расти выше Middle-разработчика, пропускайте этот пункт. Для остальных, да и для собственного развития, не будет лишним научиться подготовить доклад, зажечь аудиторию, не посыпаться от каверзных вопросов, конструктивно обсудить тему и защитить свою точку зрения или изменить её не впадая в крайности УК РФ в виде нанесения тяжких телесных повреждений идеологическим противникам.

Было: Боевое выступление перед аудиторией.

Полезно: Ну и, собственно, живое выступление. Можно долго готовиться, вылизывать презу, брать уроки ораторского искусства и актёрского мастерства. Но после первого удара в челюсть (выхода на сцену) всё это вылетает из головы. Не знаю, почему в крупных ИТ-компаниях выступают на конференциях или хотя-бы пишут статьи в профильные издания от силы пара человек. При том, что это здорово прокачивает способность формулировать мысли, личный бренд докладчика, развивает ИТ-коммьюнити, а компаниям неплохо экономит затраты на PR и HR.

Как ещё разработчик можно перестать быть просто кодером UI-формочек для доступа к БД и проникнуться продуктовым мышлением?

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

Во-вторых, или может, это манифест для первого пункта — «Бизнес в стиле фанк». Избранные цитаты из книги можно прочитать здесь. Что я люблю в таких текстах — они написаны как религиозное откровение. Максимально размыто, доступно, за всё хорошее, против всего плохого. Это не недостаток, а наоборот, достоинство. Каждый кто прочтёт задумается и сделает свои выводы.

И, наконец, недавний тренд на корпоративные инновации. Хакатоны, пилоты со стартапами, развитие внутреннего предпринимательства, стратегия цифровой трансформации, Lean, Customer development и Design Thinking. По теме есть прекрасная схема от Disruptive.vc:

Уверен, никакого секрета я не открыл. Чем больше знаешь — тем лучше. Пусть даже и многие знания — многие печали. На тимбилдинге в ресторане с клиентом из UK наш техлид показал фокус с коробком спичек. Он положил его на край стола, ударил снизу и подбросил в воздух и той же рукой зажёг спичку о него. Клиент был так впечатлён, что оплатил счёт всей команды, от пива до морских гадов. А один из ПМов так здорово шутил, что стендапы и ретро превращались в камеди клаб в лучшие годы. Можно даже сказать, что навыки продакт-менеджера не только не будут лишними для разработчика, но и любые навыки вообще играют положительную роль в работе, дело лишь в их правильном применении. Поэтому, давайте учиться, не останавливаться в развитии и получать удовольствие от работы!