Разделяй delivery и discovery как ниндзя

Должен ли быть продукт отделен от разработки? Кто руководит командой разработчиков — продакт или тимлид? А разработчики вообще входят в продуктовую команду или нет?

Привет!

Сегодня я расскажу о том, как, на мой взгляд, устроено эффективное взаимодействие разработчиков и команды продуктового исследования — то есть delivery и discovery внутри продуктовой компании.

Я не раз слышала от разных людей идею, что «продукт должен быть отделен от разработки».

Так проще и понятнее.

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

Потом вышла «Психбольница в руках пациентов» и другие книги, которые предлагали при проектировании систем опираться на потребности клиента. Этот процесс начался более 20 лет назад. Появились исследователи, которые снабжали менеджеров проектов вводными о нуждах аудитории. Менеджеры — главные, разработка и исследование — исполнители.

Со временем стало понятно, что эффективнее, если исследования не делаются «на заказ», а сами включены в целеполагание. Появилась профессия менеджера продукта, который не исполняет волю начальства, а с помощью ресурсов исследования сам определяет выгодное для бизнеса направление. Но человеческая психика инертна и любит цепляться за понятные структуры. И получается, что теперь менеджер продукта в компании аналитика и дизайнера решают судьбы бизнеса, а разработка исполняет их волю. Discovery-команда — главная, разработчики — исполнители.

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

Бывает, что вызывает желание воскликнуть «давайте отделим продукт от разработки» то, что люди, которых вы наняли на продуктовые позиции, занимаются, в основном, проджект-менеджементом. Инстинктивно хочется отнять у них разработчиков, чтобы они наконец занялись discovery.

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

Project- и product-менеджер — это разные профессии, для них нужны разные квалификации, и проблема не решается механическим разделением команды.

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

В такой компании вы рано или поздно услышите фразу в духе «А давайте вообще уберем продактов из приоритизации задач». Я вот один раз слышала, и дело здесь не в наличии у продактов ресурса разработки.

Даже если оставленные без разработчиков менеджеры попробуют начать discovery-процессы — они будут сталкиваться с конкурирющими приоритетами от более влиятельных лиц компании. В такой ситуации у нормального продакта только два пути: тихо рулить разработкой, воплощать спущенные сверху приоритеты и превращаться в проджекта, либо если разработку у такого продакта отобрать — поделать исследования, накопать кучу интересных инсайтов, убрать их в стол, уйти в глубокую депрессию, выгореть и сменить работу.

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

Допустим, тем не менее, вы оказались в компании, где есть два отдела: в одном царит атмосфера экспериментов с концептами и проверками гипотез, а в другом — классическая стройка с прорабом и каменщиками. Во главе первой группы — продакт-менеджер или СРО, во главе второй — тимлид, проджект или СТО. Что на самом деле происходит под капотом этого разделения?

Медленный Time to Market.
Между двумя группами людей должны сложиться какие-то процессы. Результаты работы одних должны быть переданы другим для дальнейшей работы. Внутри каждой из групп может быть полный аджайл, но очень сложно синхронизировать работу двух разных отделов, а не выстраивать этапы друг за другом. Чаще всего в таких ситуациях сначала идет этап исследований и прототипов, потом готовится ТЗ, потом идет реализация. Но у разработки есть свои планы. Сколько придется ждать старта разработки? А что, если на один отдел разработки претендуют несколько продуктово-исследовательских команд? Лаг между исследованием и разработкой практически неизбежен.

Бюрократизация.
У меня был один знакомый архитектор, который на полном серьезе пытался внедрить такой подход: исследовательская команда должна подготовить настолько проработанное ТЗ и функциональные требования ДО передачи в разработку, чтобы "разработчики в идеале не разу не обратились к продакту с вопросами до релиза".

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

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

ТЗ, которое готовила discovery команда, она должна была защитить на комитете разработчиков, которые после защиты выкатывают правки и уточнения, и итерации продолжаются, пока разработчики не будут удовлетворены. Но даже после согласования в работу ТЗ будет взято не раньше начала следующего спринта. Не успели получить апрув — ждете спринт.

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

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

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

Момент релиза, и все что происходит позже — это и есть самая главная проверка гипотезы о том, что настоящий продукт подходит настоящей аудитории. И поскольку ставки максимально высоки, после релиза две команды должны постоянно работать вместе: discovery смотрит на метрики и фидбек, delivery быстро итерирует с правками. В момент релиза работа не заканчивается, а, фактически, начинается. Но если это две команды с разными планами и командирами — засинхронизироваться в этом месте бывает очень сложно.

Плохие условия для проверки гипотез.
Для показа респондентам лучше сделать быстрое MVP, чем прототип в Figma. Лучше собрать новый элемент некрасиво на коленке и раскатить на 5% аудитории, чем спрашивать в интервью нужен он или нет. Но если у вашей discovery команды нет доступа к рукам разработчиков — все проверки гипотез будут очень условными.

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

Размытие ответственности.
Если product-менеджер не руководит разработкой — он становится руководителем отдела исследований. Если релиз не вышел в срок — кто виноват? Если в проде много багов — чья это проблема? Если то, что вышло в прод, сильно отличается от концепта — кто исправляет? В парадигме двух разных команды кажется, что тимлид или СТО.

Но руководитель продукта — это человек, ответственный за финальный результат, и за все элементы, которые этот финальный результат формируют. А, значит, и за команду разработки. Если команду разработки у него отнять — ответственность за результат становится номинальной.

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

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

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

В общем, отдельные команды — это довольно безрадостная картина.

Понятие «продуктовая культура» на первый взгляд таит в себе противоречие:

Включать в discovery всех? Но разработчики не умеют кастдевить и не хотят этого делать! А исследователи не кодят. Как разрешить это противоречие?

Действительно, в продуктовой команде есть специалисты, которые скорее вовлечены в процесс поиска и генерации ценности, а есть те, кто скорее эту ценность воплощают. Но разработчиков необходимо вовлекать в процессы discovery, а продактов, дизайнеров и исследователей — в delivery.

Воспользовавшись принципом Парето, можно описать это так.

80% времени разработчики пишут код, 20% времени они:

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

80% времени discovery-команда занимается поиском ценности, 20% времени она:

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

Не все разработчики готовы вовлекаться в discovery-процесс. Лучше всего уже на этапе собеседований прямо рассказывать о том, что у вас разработчики не только кодят. Если вы внедряете эти принципы в сложившиеся команды, кому-то они придутся не по нраву. Но, по опыту, большая часть разработчиков с энтузиазмом вовлекается в discovery, потому что всем нравится видеть, как используется их продукт и иметь немного власти над его будущим.

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

На самом деле, у некоторых специалистов может быть даже три босса: продакт, тимлид и старший специалист в его компетенции. Например, у дизайнера — Head of design. Но этот человек больше занимается развитием специалистов и внедрением новых технологий и методологий, нежели процессом создания продуктов.

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

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

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

Тимлид и продакт вместе планируют спринты, релизят и вместе следят за жизнью продукта. На всех этапах создания фичи все члены команды максимально синхронизированы и решают вопросы в течение минут, а не дней. Это и есть главный компонент улучшения time to market.

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

Delivery — это способ достижения целей внутри команды.
Вся команда живет в одном ритме спринта. К концу спринта все члены команды должны добежать до осязаемых результатов и презентовать их на демо. Разработчики — до кода в проде, исследователи — до новых знаний о своих клиентах.

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

Разделение — в максимальной интеграции.

#productmanagement #delivery #discovery #scrum #projectmanagement