Как развить продуктовое мышление у команды разработки
В основном разработчики считают своей работой «написание кода», «добавление фич» или даже «закрытие задач в Jira» — иными словами, думают, что им платят за то, что они пишут код, а не за то, что этот код приносит деньги и пользу компании.
Долгое время в нашей компании мы думали, что такой подход является нормой. Задача фронт-офиса и продактов — общаться с пользователями и понимать, как и куда развивать продукт. Задача разработчиков — писать код. Всё стройно и понятно, роли распределены. Но в какой-то момент такой подход начал себя изживать и его пришлось пересмотреть.
В чем проблема:
- Разрыв контекста. Разработчики не понимают, что внезапный, и, по их мнению, не очень важный баг, который вылез на демо у sales-менеджера — это серьезная проблема, а не просто очередной дефект в беклоге.
- Команда разработки не думает о пользователях. Если не думать о пользователе, уронить продакшн на пару часов из-за кривой миграции — это просто уронить продакшн, а не три сорванных мероприятия у менеджеров, которые рассчитывали на то, что продукт будет стабильно работать.
- Процессы не соответствуют уровню развития продукта. В какой-то момент качество и стабильность фичей становится важнее скорости доставки кода.
Решение:
Если коротко, ключом к решению проблем, перечисленным выше, является переход мышления команды разработки от «код ради кода» к «код ради целей бизнеса», который подразумевает, что каждый сотрудник должен помнить: он часть бизнеса и продукта.
Это и называется «продуктовым» или «бизнесовым» мышлением: понимание того, что главная задача — развивать работу компании и улучшать продукт. Такая установка означает, что разработчик должен:
- знать продукт и его предметную область;
- понимать, кто пользуется продуктом;
- разбираться в метриках продукта;
- знать, в какую сторону растёт продукт и бизнес;
- понимать, что делают другие команды в компании.
Зачем это бизнесу:
Бизнес получает вовлеченную команду, которая лучше перформит.
- когда разработчики понимают, как и кто пользуется продуктом, они могут выбирать более правильные архитектурные решения;
- product owner получает возможность советоваться с командой в вопросах реализации функционала;
- проактивность возрастает. Когда команда понимает, что код — только часть ее работы, она начинает больше вовлекаться в то, чтобы генерировать и предлагать улучшения, которые не касаются кода напрямую;
- полезные вопросы. Команда разработки начинает задавать продактам правильные, но неудобные вопрос из серии: «а где доказательства, что эта фича поможет нам вырастить ключевую метрику?». Это заставляет менеджмент заранее готовиться к таким вопросам просчитывать рентабельность предполагаемых решений.
Зачем это разработчикам
…или немного марксизма:
Маркс много писал об отчуждении. Отчуждение — это отрыв рабочего от результатов его труда и процесса производства. Человек работает, но не чувствует никакой связи с конечным продуктом своей деятельности: изо дня в день он завинчивает один и тот же болт на конвейере и не ощущает, что создаёт что-то большое, ведь его работа мала и однообразна. Он не видит смысла в работе — вся его деятельность сводится к провороту одного болта.
Экономическая часть проблемы, о которой писал Маркс, современных разработчиков затрагивает в меньшей степени: они имеют гораздо более высокий уровень дохода чем рабочие на заводах времен Маркса, а вот психологическая — очень даже: разработчики нередко не понимают смысл своего труда, не видят, как совершаемые ими действия влияют на продукт в целом. Если ваша работа сводится к выполнению потока задач из jira, если вы не знаете, зачем выполняется та или иная задача, а каждый новый день на работе такой же, как предыдущий, подумайте: сильно ли вы отличаетесь от того рабочего на заводе?
Продуктовое мышление и ощущение причастности заставляет команду разработки больше ценить и гордиться продуктом, а значит, чувствовать важность и смысл своей работы.
Что мы делали в VL
Как только мы осознали, что оторванность производства от бизнеса — это проблема, мы пошли её решать. Обсудили с менеджерами, собрали кейсы коллег из других компаний, привлекли HR отдел и организовали общий брейншторм. В итоге появились следующие нововведения:
- Начали приглашать разработчиков на кастдевы и демо. Просто афишируем в чате и зовем тех, кто хочет присутствовать. Ребята охотно отзываются.
- Начали проводить демо команды фронт-офиса/дискавери каждый месяц. Они, как и команда разработки, раз в спринт рассказывают, какая работа была проделана.
- По понедельникам весь фронт-офис приходит на митинг разработчиков, по пятницам — вся разработка на митинг фронт-офиса. Это помогает разным командам быть в контексте того, что происходит в другом кусочке продукта.
- Внедрили общие продуктовые метрики для команды разработки и продаж, регулярно обращаемся к ним на митингах, это помогает сохранять фокус внимания на том, что важно.
- Периодически проводим мероприятие, которое называется «Обратная связь от пользователя». Это встреча, на которую приходит обычный пользователь продукта и любой член команды может задать любой вопрос про его опыт использования продукта. Пользователь, в свою очередь, рассказывает что хорошо, а что можно улучшить.
- Начали вводить культуру клиентоцентричности. Фича больше не считается сделанной, если работает через раз, или если у нас нет уверенности, что она не отвалится через спринт.
Нам предстоит еще много работать в этом направлении, но первые шаги положены — это не может не радовать.
Почему этот путь — правильный?
Единая парадигма продуктового мышления помогает разным частям продукта быть более целостными. Это вызывает меньше рассинхронизации, а значит, меньше конфликтов. Всем понятны приоритеты и цели бизнеса, при этом бизнесу более понятны технические ограничения. Как итог: все счастливы и работают продуктивнее.