Продуктовый Подход – Преимущества Как Для Бизнеса, Так И Для Разработчика

Привет! Я разработчик продукта, но так было не всегда.

Лет 5 назад я впервые услышал словосочетание «разработка продукта», но тогда не совсем понял, что оно означает. Мне говорят, что у нас есть продукт, а я пишу код и пишу что-то в этом роде.

Есть ТЗ - и приятно, нет ТЗ - как говорится, и результат будет ХЗ Но на самом деле это своего рода проектный подход. У вас есть техническое задание, а за ним стоит большая кропотливая работа.

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

Потом что-то изменилось в моей работе — исчезли технические характеристики.

Это следующий шаг.

Вот мы работаем над продуктом, и сейчас у нас даже нет технического задания.

И что же мне делать? Началось осознание происходящего.

Во-первых, у продукта нет четкого начала и конца.

Нет никаких границ.

Здесь, в проекте, у нас были границы.

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

Продукт не имеет таких границ, он живет, и его нужно развивать.

К нам приходят бизнесмены и говорят – давайте экономить.

Конкретно по СМС и по форме оплаты.

Мы согласны.

Так получилось, что в тот момент наша команда знала продукт лучше, чем владелец продукта, такое бывает. Мы знали особые случаи, знали, что куда-то тратим немного лишних СМС.

Это значит, что они примерно знали, где и что делать.

Итак, мы взяли спринт на анализ и за этот спринт не написали ни строчки кода.

Совсем.

Но мы много общались, много обсуждали, проводили мозговые штурмы, выдвигали гипотезы, оценивали их и предлагали, что можно сделать.

Мы обнаружили сценарии, в которых отправлялись дополнительные SMS-сообщения, и выяснили, сколько дополнительных SMS-сообщений мы отправляли.

Мы знаем стоимость одного SMS и, соответственно, знаем, сколько можно сэкономить.

И по каждому сценарию примерно прикинули, сколько будет стоить все это сделать.

Затем из этих задач мы построили дорожную карту.

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

Примеры задач

Например, вот очень простая задача.

Есть пользователи, которые в своих настройках установили галочку «вход только по паролю».

А мы им почему-то предлагаем авторизоваться по СМС.

И они почему-то отправляют эти смс.

Потом вводят СМС, а потом еще и пароль вводят, хотя СМС можно было вообще не вводить.

И исправление этого сценария — это то, что мы сделали в первую очередь.

Но более сложная задача — перевести все СМС на push-уведомления.

Задача достаточно амбициозная, мы до сих пор работаем над доработкой этого перевода, потому что было много рефакторингов, и мы написали много новых микросервисов и новых репозиториев.

Это все, о чем я говорю.

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

Каждый спринт мы систематически выполняли какое-то задание, которое сокращало часть СМС.

И смотрели в режиме реального времени прямо на график, чтобы увидеть, как менялось количество СМС.

Мы увидели, что продукт экономит деньги.

Прямо на наших глазах.

«Кономитс» означает, что он зарабатывает. Вот я смотрю на график и понимаю, что мы окупились в одном спринте.

Это очень крутой бизнес-эффект. И я понимаю, что мы как команда полезны.

Мы окупаемся.

И на будущее вперед. Это вещь долговечная, мы теперь сохраняем много-много СМС каждый месяц.

Лично меня это мотивирует. И мне очень приятно знать, что я полезен.

Плюсы подхода

Такой подход (когда разработчика допускают на ранней стадии) имеет ряд преимуществ как для бизнеса, так и для самих разработчиков.

Начну с позитива для бизнеса.

Разработчик может предложить решение, используя принцип Парето.

То есть за 20% времени можно добиться 80% бизнес-эффекта, и в большинстве случаев для бизнеса это нормально.

Вы можете привлечь разработчика на раннем этапе и ограничить определенный объем функциональности, чтобы он не делал ни больше, ни меньше.

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

Сами.

То есть речь идет не просто о кодировании каких-то технически сложных вещей, а о том, чтобы сделать рефакторинг ради бизнеса.

Что ж, мы открыли портал в инженерный рай, и оттуда в форму оплаты добавилось несколько новых функций.

Среди них — новый способ оплаты, и даже за один рефакторинг исправили пару ошибок.

Разработчик также может оценить стоимость разработки задачи на ранней стадии.

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

И по этому количеству СМС можно понять, сколько денег принесет это задание.

То есть бизнес-эффект тоже можно оценить с помощью разработчика.

Более того, для этого не требуется отдельный аналитик.

Понятно, что разработчик сделает это с некоторой ошибкой, но это все же возможно.

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

Тоже плюс.

Самый важный момент, на мой взгляд, это когда мы в команде сами придумали задачу, когда сами ее декомпозировали, заранее прикинули, потом взяли на себя ее сделать, потом довели до производства и Также собрал пост-оценку (в идеале).

Есть ощущение, что это моя особенность, это наша задача, это становится частью нас.

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

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

Я также хочу выполнять другие задачи.

Это работает сильнее, чем зарплаты и так далее.

Вы просто хотите выполнять задачи, чтобы чувствовать себя полезными.

Следующее, что вам нужно сделать, это прокачать свои навыки.

Как сложные навыки, такие как SQL, так и мягкие навыки.

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

И это очень хороший стимул для развития этого навыка.

Отдельно я сказал о совершенствовании бизнес-мышления.

Это очень важный навык для разработчика продукта и не только.

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

А разработка продукта такого плана, когда ты сам придумываешь проблему и сам ее оцениваешь, это существенно способствует совершенствованию твоего бизнес-мышления.

Следующий момент – это сеть.

Когда человек выходит из команды для общения с кем-то — со специалистами по информационной безопасности, с юристами, с кем-то еще внешним — он приходит к людям, знакомится с ними.

И в следующий раз, когда он придет к ним, они знают, зачем он пришел и что ему нужно, и многие вопросы решаются гораздо проще.

Еще один момент, я уже говорил о мотивации, но есть и другая мотивация.

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

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

И последний пункт. Как.

Попробуйте, возможно, вам тоже понравится.

Но есть нюансы

Как команда, мы начинаем с того, что придумываем, и заканчиваем внедрением этого в производство.

И это новые зоны ответственности, мы их раньше не брали, и нам нужно делать это лучше.

И я говорю не просто об отсутствии багов, а больше о качественной предварительной оценке и подготовке заданий.

У нас есть инструменты, чтобы сделать это хорошо.

По сути, это чек-листы.

Я рекомендую эти инструменты, даже если вы не используете Scrum, не используйте Agile, даже если вы все это ненавидите.

Инструменты — это инструменты Scrum, но вы можете использовать их, даже если у вас есть водопад — они просто помогут. Это не какие-то ограничения, это шпаргалки.

Вот шпаргалка для выполнения задания.

Определение готовности к спринту .

Этот чек-лист мы написали сами.

Продуктовый подход – преимущества как для бизнеса, так и для разработчика

Это шпаргалка, но это не барьер.

Мы можем заранее посмотреть на нее и подумать, что еще мы можем сделать с проблемой, чтобы завершить ее в спринте.

Но если владелец продукта говорит «да», мы соглашаемся, примем, но ни на что не обязуемся.

То есть с большой вероятностью в спринте выяснится какая-то неизвестность, которая нас замедлит, и мы не сможем что-то сделать.

Увы, такое случается.

Но не преграда, это важно.

И здесь Определение готового является барьером.

Что такое определение «сделано»? Бывает, что программист говорит: «Я сделал это».

И они его спрашивают: «Что ты сделалЭ» Ответы: - Я написал код. Если программист говорит, что он написал код, это не всегда означает, что он его отладил.

Но написанный код не имеет никакой коммерческой ценности.

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

Это идеально.

DoD — это контрольный список, который позволяет вам договориться, когда сказать «Готово» по задаче.

Я сказал о Министерстве обороны, что это барьер.

Почему барьер? Потому что мы договорились с бизнесом, что поддерживаем продукт на этом уровне качества, не ниже.

Этот контрольный список посвящен фиксации уровня качества.

Не определение готовности команды, не определение готовности компонента, а определение готовности всего продукта.

Продуктовый подход – преимущества как для бизнеса, так и для разработчика

И если мы не успели что-то сделать по Definition of Done за спринт, это печальная ситуация, но такое случается.

Затем мы берем эту невыполненную работу и кладем ее в бэклог.

И продукту нужно понимать, что есть какая-то незавершенная работа, технический долг.

Что это придется сделать позже.

И если мы этого не сделаем, это замедлит нас в будущем.

Мы делаем все сами.

И чек-листы мы сделали сами, и можем сами как-то двигать процессы, если видим потребности, сами прорабатываем задачу, сами закатываем ее в производство, сами собираем пост-оценку.

Благодаря этому мы получаем некоторую прибыль.

Пять лет назад я особо не задумывался о написании кода и писательстве.

Это когда ты приходишь, начинаешь писать код в 9 утра, а можешь закончить в 6 вечера и пойти домой.

Потом что-то изменилось, и в какой-то момент пришло осознание – то, как мы работаем, зачем приходим на работу, это очень сильно влияет на качество нашей жизни в целом.

Для психического здоровья, для физического здоровья, для отношений с близкими.

На работе мы проводим 80% времени.

И то, как мы получаем удовольствие от работы, очень важно.

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

Вы можете спросить об этом своих руководителей и менеджеров.

А если вы сами тимлиды, то можете передать эту ответственность ребятам.

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

ТГ-канал «Разработчик продукта» .

Теги: #Карьера в IT-индустрии #Управление разработкой #разработка #Управление продуктом #agile #бизнес #продуктовый подход