Привет!
Я продуктовый разработчик, но так было не всегда. Лет 5 назад я впервые услышал фразу «продуктовая разработка», но я тогда не совсем понимал, что это значит. Мне говорят — вот у нас продукт, ну а я пишу код и пишу, чего такого-то. Есть ТЗ — и славно, нет ТЗ — как говорится, и результат будет ХЗ
Но это на самом деле своего рода проектный подход. Вот есть у вас ТЗ, а за ним — много тяжелой, усердной работы. Люди упорно гребут, в голове у них только код. Потом проект закончился, все молодцы.
Потом что-то поменялось в моей работе — ТЗ не стало. Это такой следующий шажок. Вот мы в продукте работаем, а теперь у нас еще и ТЗ нет. И что делать? Началось осознание того, что происходит.
Во-первых, продукт не имеет четкого начала и конца. Нет каких-то границ. Вот в проекте у нас были границы. Например, количество функций, которые нужно сделать, количество разработчиков, которые работают над проектом, дедлайны всякие, когда проект должен закончиться. У продукта же таких границ нет, он живёт, и его надо развивать.
Приходит к нам бизнес и говорит — давайте экономить. Конкретно на SMS и на платежной форме. Мы соглашаемся. У нас так вышло, что в тот момент наша команда знала продукт лучше, чем владелец продукта, так бывает. Мы знали особенные кейсы, мы знали, что мы где-то лишних SMS немного тратим. А значит, примерно знали, где можно что поделать.
Так что мы взяли спринт на анализ, и за этот спринт мы не написали ни строчки кода. Вообще.
Зато мы много общались, много обсуждали, брейнштормили, накидывали гипотезы, оценивали их, предлагали, что можно сделать. Мы находили сценарии, где отправляются лишние смски, прикидывали, сколько этих SMS лишних мы отправляем. Мы же знаем стоимость одной SMS и, соответственно, знаем, сколько мы можем сэкономить. И по каждому сценарию примерно прикидывали, сколько будет стоить всё это сделать.
Затем мы из этих задач выстроили роадмап. В начало поставили такие низковисящие фрукты, которые легко сделать и которые дают явный эффект. А в конец — задачки посложнее, у одних из них эффект был послабее, а у других — более заметный.
Например, вот задачка совсем простая. Есть пользователи, которые в настройках поставили галочку «логиниться только по паролю». А мы им зачем-то предлагаем логиниться по SMS. И они зачем-то эти SMS отправляют. Потом они вводят SMS, а потом они еще вводят пароль, хотя SMS можно было не вводить вообще. И пофиксить этот сценарий — это просто, что мы первым делом и сделали.
А вот посложнее задачка — перевести все SMS на пуши. Задачка достаточно грандиозная, у нас до сих пор идут работы, чтобы зафиналить этот перевод, потому что там много рефакторингов было, и мы написали много новых микросервисов и новые хранилки.
Это я все к чему.
Вот мы написали роадмап, декомпозировали его, прикинули, составили план для каждой задачки, стали делать. Планомерно каждый спринт делали какую-то задачку, которая часть SMS срубала. И смотрели в реалтайме прямо на график, как меняется количество SMS. Мы видели, что продукт экономит. Прямо на глазах. Экономит — значит зарабатывает. Вот я смотрю на график и понимаю, что мы окупились в этот же спринт. Это очень круто по бизнес-эффекту. И понимаю, что мы как команда полезные. Мы окупаемся.
И еще на будущее вперед. Это же долгоиграющая штука, мы же теперь каждый месяц экономим много-много SMS. Меня лично это ощутимо мотивирует. И я очень рад осознавать, что я полезный.
У этого подхода (когда разработчика пускают на ранний этап) есть несколько плюсов и для бизнеса, и для самих разработчиков.
Я начну с плюса для бизнеса. Разработчик может предложить решение по принципу Парето. То есть за 20% времени можно сделать 80% бизнес-эффекта, и бизнесу это в большинстве случаев ОК. Можно на раннем этапе привлечь разработчика и ограничить какое-то количество функциональности, чтобы сделать ни больше и ни меньше.
Разработчик, допустим, такой вот грамотный парень, бизнес-ориентированный, который понимает, зачем, что, как внутри рефакторить, он может предложить такой рефакторинг, который откроет портал в инженерный рай и оттуда начнут сыпаться фичи. Сами.
То есть не просто там кодить какие-то технически упоротые вещи, а именно сделать рефакторинг ради бизнеса. Ну мы так открыли портал в инженерный рай и оттуда насыпалось на форму оплаты несколько новых фич. Среди них — новый способ оплаты, да еще и пару багов пофиксили одним рефакторингом.
А ещё разработчик может на раннем этапе оценить стоимость разработки задачи. Понятно, что если это какая-то нереальная вещь, у нее сомнительный бизнес-эффект, ее можно дальше не прорабатывать и не собирать для нее какие-то бизнес-требования, а просто отложить и пойти дальше, что-то более приоритетное взять.
Разработчик, у которого есть знание доменной области и знание SQL, может посчитать количество SMS, которые отправляются в месяц по какому-то сценарию. И исходя из этого количества SMS можно понять, сколько денег эта задача принесет. То есть бизнес-эффект тоже можно оценивать с помощью разработчика. Причём для этого не нужен какой-то отдельный аналитик. Понятно, что разработчик это сделает с какой-то погрешностью, но все-таки это возможно.
Обычно у фронтендеров такой майндсет и такая насмотренность, что они могут набросать макет. А если этот человек в офисе, то он может этот макет людям показывать и проводить коридорное тестирование. Тоже плюс.
Самый главный пункт, на мой взгляд, это когда мы в команде задачу сами придумали, когда мы ее сами декомпозировали, предоценили, потом мы ее взяли делать, потом мы ее довели до продакшена и еще собрали постоценку (в идеале). Тут есть ощущение, что вот это моя фича, это наша задача, она становится частичкой нас. И отсюда большая мотивация, чтобы задачу протащить через все этапы, чтобы везде ее сопроводить, и в конце концов понять — была ли твоя работа полезной.
Отсюда следует первый плюс для разработчика — это дополнительная мотивация. Как я и сказал, когда я задачу прорабатываю, я с ней сближаюсь и хочу ее делать. И другие задачи я тоже хочу делать. Это работает сильнее, чем зарплаты и прочее. Вот просто хотеть делать задачи, чтобы чувствовать себя полезным.
Следующее — это прокачка скиллов. И хард-скиллы типа SQL, и софт-скиллы. Некоторым разработчикам сложно выйти из команды, чтобы пойти куда-то там наружу с другой командой договариваться. И вот это очень хороший толчок к развитию этого навыка.
Отдельным пунктом я вынес прокачку бизнес-мышления. Это очень важный навык для продуктового разработчика и не только. В принципе, если вы хотите основать стартап или занять ведущую роль в стартапе или в Big Tech компании, то понимать бизнес, понимать, как это работает на всех этапах, это прямо обязательно. И продуктовая разработка такого плана, когда ты задачу сам придумываешь и сам предоцениваешь, она заметно способствует тому, чтобы прокачаться в бизнес-мышлении.
Следующий пункт — нетворкинг. Когда человек идет из команды с кем-то общаться — с инфобезопасниками, с юристами, еще кем-то внешним — он приходит к людям, знакомится с ними. И в следующий раз, когда он к ним приходит, они знают, зачем он пришел и что ему надо, и многие вопросы решаются гораздо легче.
Ещё один пункт, я уже говорил про мотивацию, но есть еще мотивация другая. Когда приносишь больше пользы продукту, можно рассчитывать на взаимность. Когда есть реальный измеримый в деньгах эффект от твоей работы, можно рассчитывать и на какой-то быстрый хороший карьерный рост, на какую-то хорошую зарплату, и вот эта внутренняя мотивация — это тоже такое вознаграждение.
И последний пункт. Просто нравится. Попробуйте, может, вам тоже понравится.
Мы в команде начинаем с того, что придумываем, а заканчиваем тем, что выкатываем в прод. А это же новые зоны ответственности, мы их раньше не брали на себя, и надо сделать это более качественно.И я тут не только про отсутствие багов, а больше про качественную предоценку и подготовку задач. У нас для того, чтобы сделать качественно, есть инструменты.
По сути, это чеклисты. Я рекомендую эти инструменты, даже если у вас не скрам, не аджайл, если вы вот это все ненавидите. Инструменты скрамовские, но вы можете их применять, даже если у вас вотерфолл — они просто помогут. Это не какие-то ограничители, это шпаргалки.
Вот есть шпаргалка для проработки задачи. Definition of Ready for sprint. Этот чеклист мы писали сами.
Это шпаргалка, но это не барьер. Мы можем на него посмотреть и подумать, что по задачке можно еще поделать предварительно, чтобы ее успеть в спринте. Но если владелец продукта говорит — надо, мы соглашаемся, мы ее возьмем, но мы ни на что не коммитимся.
То есть с большой вероятностью там вскроется какая-то неизвестность в спринте, которая нас затормозит, и мы что-то не сможем. Увы, такое бывает. Но не барьер, это важно.
А вот Definition of done — это барьер. Что такое Definition of done?
Бывает же, что программист говорит: — Я сделал.
А у него спрашивают: — Что ты сделал?
Отвечает: — Я код написал.
Если программист говорит, что он написал код, это даже не всегда значит, что он его отладил. Но для бизнеса нет никакой ценности от написанного кода. Просто написанного кода. Потому что нужно еще отладить, поревьювить, поправить после ревью, оттестировать, вывести в продакшен, обвесить мониторингом и собрать постоценку. Это в идеале.
DoD — чеклист, который позволяет договориться, когда говорить “Сделано” по задаче. Про DoD я сказал, что это барьер. Почему барьер? Потому что мы договорились с бизнесом, что мы продукт поддерживаем вот на таком уровне качества, не ниже. Этот чеклист — он про фиксацию уровня качества. Не Definition of Done команды, не Definition of Done компонента, а Definition of Done всего продукта.
И если мы что-то по Definition of Done, не успели за спринт сделать — печальная ситуация, но бывает. То мы берем эту несделанную работу и кладем ее в бэклог. И продакту нужно понимать, что есть некоторая несделанная работа, техдолг. Что ее придется потом когда-то сделать. А если ее не делать, она нас в будущем затормозит.
Мы все делаем сами. И чеклисты мы сами составляли, и процессы мы можем сами двигать как-то, если видим потребности, мы сами прорабатываем задачу, мы сами катим ее в продакшн, мы сами собираем постоценку.
Через это мы получаем некоторые профиты. Пять лет назад я не особо задумывался, пишу код и пишу. Это когда ты приходишь, в 9 утра начинаешь писать код, в 6 вечера можешь закончить и уйти домой.
Потом что-то менялось, и в какой-то момент пришло осознание — то как мы работаем, то зачем мы на работу приходим, оно очень сильно влияет на качество нашей жизни в целом.
На ментальное здоровье, на физическое здоровье, на отношение с близкими. Мы на работе проводим 80% времени. И очень важно то, как мы на работе кайфуем.
Я вам очень советую задуматься о ваших рабочих процессах и попробовать взять на себя больше ответственности по задачам. Вы можете попросить об этом своих тимлидов и менеджеров. А если вы сами тимлиды, то вы можете эту ответственность ребятам дать.
habr.com
Я продуктовый разработчик, но так было не всегда. Лет 5 назад я впервые услышал фразу «продуктовая разработка», но я тогда не совсем понимал, что это значит. Мне говорят — вот у нас продукт, ну а я пишу код и пишу, чего такого-то. Есть ТЗ — и славно, нет ТЗ — как говорится, и результат будет ХЗ
Но это на самом деле своего рода проектный подход. Вот есть у вас ТЗ, а за ним — много тяжелой, усердной работы. Люди упорно гребут, в голове у них только код. Потом проект закончился, все молодцы.
Потом что-то поменялось в моей работе — ТЗ не стало. Это такой следующий шажок. Вот мы в продукте работаем, а теперь у нас еще и ТЗ нет. И что делать? Началось осознание того, что происходит.
Во-первых, продукт не имеет четкого начала и конца. Нет каких-то границ. Вот в проекте у нас были границы. Например, количество функций, которые нужно сделать, количество разработчиков, которые работают над проектом, дедлайны всякие, когда проект должен закончиться. У продукта же таких границ нет, он живёт, и его надо развивать.
Приходит к нам бизнес и говорит — давайте экономить. Конкретно на SMS и на платежной форме. Мы соглашаемся. У нас так вышло, что в тот момент наша команда знала продукт лучше, чем владелец продукта, так бывает. Мы знали особенные кейсы, мы знали, что мы где-то лишних SMS немного тратим. А значит, примерно знали, где можно что поделать.
Так что мы взяли спринт на анализ, и за этот спринт мы не написали ни строчки кода. Вообще.
Зато мы много общались, много обсуждали, брейнштормили, накидывали гипотезы, оценивали их, предлагали, что можно сделать. Мы находили сценарии, где отправляются лишние смски, прикидывали, сколько этих SMS лишних мы отправляем. Мы же знаем стоимость одной SMS и, соответственно, знаем, сколько мы можем сэкономить. И по каждому сценарию примерно прикидывали, сколько будет стоить всё это сделать.
Затем мы из этих задач выстроили роадмап. В начало поставили такие низковисящие фрукты, которые легко сделать и которые дают явный эффект. А в конец — задачки посложнее, у одних из них эффект был послабее, а у других — более заметный.
Примеры задач
Например, вот задачка совсем простая. Есть пользователи, которые в настройках поставили галочку «логиниться только по паролю». А мы им зачем-то предлагаем логиниться по SMS. И они зачем-то эти SMS отправляют. Потом они вводят SMS, а потом они еще вводят пароль, хотя SMS можно было не вводить вообще. И пофиксить этот сценарий — это просто, что мы первым делом и сделали.
А вот посложнее задачка — перевести все SMS на пуши. Задачка достаточно грандиозная, у нас до сих пор идут работы, чтобы зафиналить этот перевод, потому что там много рефакторингов было, и мы написали много новых микросервисов и новые хранилки.
Это я все к чему.
Вот мы написали роадмап, декомпозировали его, прикинули, составили план для каждой задачки, стали делать. Планомерно каждый спринт делали какую-то задачку, которая часть SMS срубала. И смотрели в реалтайме прямо на график, как меняется количество SMS. Мы видели, что продукт экономит. Прямо на глазах. Экономит — значит зарабатывает. Вот я смотрю на график и понимаю, что мы окупились в этот же спринт. Это очень круто по бизнес-эффекту. И понимаю, что мы как команда полезные. Мы окупаемся.
И еще на будущее вперед. Это же долгоиграющая штука, мы же теперь каждый месяц экономим много-много SMS. Меня лично это ощутимо мотивирует. И я очень рад осознавать, что я полезный.
Плюсы подхода
У этого подхода (когда разработчика пускают на ранний этап) есть несколько плюсов и для бизнеса, и для самих разработчиков.
Я начну с плюса для бизнеса. Разработчик может предложить решение по принципу Парето. То есть за 20% времени можно сделать 80% бизнес-эффекта, и бизнесу это в большинстве случаев ОК. Можно на раннем этапе привлечь разработчика и ограничить какое-то количество функциональности, чтобы сделать ни больше и ни меньше.
Разработчик, допустим, такой вот грамотный парень, бизнес-ориентированный, который понимает, зачем, что, как внутри рефакторить, он может предложить такой рефакторинг, который откроет портал в инженерный рай и оттуда начнут сыпаться фичи. Сами.
То есть не просто там кодить какие-то технически упоротые вещи, а именно сделать рефакторинг ради бизнеса. Ну мы так открыли портал в инженерный рай и оттуда насыпалось на форму оплаты несколько новых фич. Среди них — новый способ оплаты, да еще и пару багов пофиксили одним рефакторингом.
А ещё разработчик может на раннем этапе оценить стоимость разработки задачи. Понятно, что если это какая-то нереальная вещь, у нее сомнительный бизнес-эффект, ее можно дальше не прорабатывать и не собирать для нее какие-то бизнес-требования, а просто отложить и пойти дальше, что-то более приоритетное взять.
Разработчик, у которого есть знание доменной области и знание SQL, может посчитать количество SMS, которые отправляются в месяц по какому-то сценарию. И исходя из этого количества SMS можно понять, сколько денег эта задача принесет. То есть бизнес-эффект тоже можно оценивать с помощью разработчика. Причём для этого не нужен какой-то отдельный аналитик. Понятно, что разработчик это сделает с какой-то погрешностью, но все-таки это возможно.
Обычно у фронтендеров такой майндсет и такая насмотренность, что они могут набросать макет. А если этот человек в офисе, то он может этот макет людям показывать и проводить коридорное тестирование. Тоже плюс.
Самый главный пункт, на мой взгляд, это когда мы в команде задачу сами придумали, когда мы ее сами декомпозировали, предоценили, потом мы ее взяли делать, потом мы ее довели до продакшена и еще собрали постоценку (в идеале). Тут есть ощущение, что вот это моя фича, это наша задача, она становится частичкой нас. И отсюда большая мотивация, чтобы задачу протащить через все этапы, чтобы везде ее сопроводить, и в конце концов понять — была ли твоя работа полезной.
Отсюда следует первый плюс для разработчика — это дополнительная мотивация. Как я и сказал, когда я задачу прорабатываю, я с ней сближаюсь и хочу ее делать. И другие задачи я тоже хочу делать. Это работает сильнее, чем зарплаты и прочее. Вот просто хотеть делать задачи, чтобы чувствовать себя полезным.
Следующее — это прокачка скиллов. И хард-скиллы типа SQL, и софт-скиллы. Некоторым разработчикам сложно выйти из команды, чтобы пойти куда-то там наружу с другой командой договариваться. И вот это очень хороший толчок к развитию этого навыка.
Отдельным пунктом я вынес прокачку бизнес-мышления. Это очень важный навык для продуктового разработчика и не только. В принципе, если вы хотите основать стартап или занять ведущую роль в стартапе или в Big Tech компании, то понимать бизнес, понимать, как это работает на всех этапах, это прямо обязательно. И продуктовая разработка такого плана, когда ты задачу сам придумываешь и сам предоцениваешь, она заметно способствует тому, чтобы прокачаться в бизнес-мышлении.
Следующий пункт — нетворкинг. Когда человек идет из команды с кем-то общаться — с инфобезопасниками, с юристами, еще кем-то внешним — он приходит к людям, знакомится с ними. И в следующий раз, когда он к ним приходит, они знают, зачем он пришел и что ему надо, и многие вопросы решаются гораздо легче.
Ещё один пункт, я уже говорил про мотивацию, но есть еще мотивация другая. Когда приносишь больше пользы продукту, можно рассчитывать на взаимность. Когда есть реальный измеримый в деньгах эффект от твоей работы, можно рассчитывать и на какой-то быстрый хороший карьерный рост, на какую-то хорошую зарплату, и вот эта внутренняя мотивация — это тоже такое вознаграждение.
И последний пункт. Просто нравится. Попробуйте, может, вам тоже понравится.
Но есть нюансы
Мы в команде начинаем с того, что придумываем, а заканчиваем тем, что выкатываем в прод. А это же новые зоны ответственности, мы их раньше не брали на себя, и надо сделать это более качественно.И я тут не только про отсутствие багов, а больше про качественную предоценку и подготовку задач. У нас для того, чтобы сделать качественно, есть инструменты.
По сути, это чеклисты. Я рекомендую эти инструменты, даже если у вас не скрам, не аджайл, если вы вот это все ненавидите. Инструменты скрамовские, но вы можете их применять, даже если у вас вотерфолл — они просто помогут. Это не какие-то ограничители, это шпаргалки.
Вот есть шпаргалка для проработки задачи. Definition of Ready for sprint. Этот чеклист мы писали сами.
Это шпаргалка, но это не барьер. Мы можем на него посмотреть и подумать, что по задачке можно еще поделать предварительно, чтобы ее успеть в спринте. Но если владелец продукта говорит — надо, мы соглашаемся, мы ее возьмем, но мы ни на что не коммитимся.
То есть с большой вероятностью там вскроется какая-то неизвестность в спринте, которая нас затормозит, и мы что-то не сможем. Увы, такое бывает. Но не барьер, это важно.
А вот Definition of done — это барьер. Что такое Definition of done?
Бывает же, что программист говорит: — Я сделал.
А у него спрашивают: — Что ты сделал?
Отвечает: — Я код написал.
Если программист говорит, что он написал код, это даже не всегда значит, что он его отладил. Но для бизнеса нет никакой ценности от написанного кода. Просто написанного кода. Потому что нужно еще отладить, поревьювить, поправить после ревью, оттестировать, вывести в продакшен, обвесить мониторингом и собрать постоценку. Это в идеале.
DoD — чеклист, который позволяет договориться, когда говорить “Сделано” по задаче. Про DoD я сказал, что это барьер. Почему барьер? Потому что мы договорились с бизнесом, что мы продукт поддерживаем вот на таком уровне качества, не ниже. Этот чеклист — он про фиксацию уровня качества. Не Definition of Done команды, не Definition of Done компонента, а Definition of Done всего продукта.
И если мы что-то по Definition of Done, не успели за спринт сделать — печальная ситуация, но бывает. То мы берем эту несделанную работу и кладем ее в бэклог. И продакту нужно понимать, что есть некоторая несделанная работа, техдолг. Что ее придется потом когда-то сделать. А если ее не делать, она нас в будущем затормозит.
Мы все делаем сами. И чеклисты мы сами составляли, и процессы мы можем сами двигать как-то, если видим потребности, мы сами прорабатываем задачу, мы сами катим ее в продакшн, мы сами собираем постоценку.
Через это мы получаем некоторые профиты. Пять лет назад я не особо задумывался, пишу код и пишу. Это когда ты приходишь, в 9 утра начинаешь писать код, в 6 вечера можешь закончить и уйти домой.
Потом что-то менялось, и в какой-то момент пришло осознание — то как мы работаем, то зачем мы на работу приходим, оно очень сильно влияет на качество нашей жизни в целом.
На ментальное здоровье, на физическое здоровье, на отношение с близкими. Мы на работе проводим 80% времени. И очень важно то, как мы на работе кайфуем.
Я вам очень советую задуматься о ваших рабочих процессах и попробовать взять на себя больше ответственности по задачам. Вы можете попросить об этом своих тимлидов и менеджеров. А если вы сами тимлиды, то вы можете эту ответственность ребятам дать.
Продуктовый подход — польза и для бизнеса, и для разработчика
Привет! Я продуктовый разработчик, но так было не всегда. Лет 5 назад я впервые услышал фразу «продуктовая разработка», но я тогда не совсем понимал, что это значит. Мне говорят — вот у нас продукт,...
habr.com