Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом
Влюбой продуктовой компании с Agile‑подходом существует множество вызовов, связанных с управлением потоком идей и задач. Когда нет четкой системы отбора идей и приоритизации, команды могут столкнуться с дублированием работы, перегрузкой и хаосом в процессе разработки. Это приводит к тому, что новые идеи попадают в команду спонтанно, без достаточной проработки и согласованности между стейкхолдерами, что в итоге влияет на то что делается много работы которая не приносит должного эффекта.
Кейс одной компании
В одной из компаний, с которой я работал, проблема заключалась в том, что много сырых идей попадало в команды без качественного процесса Discovery, который бы позволял проанализировать задачи с точки зрения ценности. Также не было единой площадки для обсуждения и выбора задач, и любой стейкхолдер мог внести задачу в работу, даже если она была недостаточно проработана или не являлась приоритетной. Это приводило к тому, что инициатива часто оказывалась «срочной», минуя основные процессы, и двигала уже запланированные задачи. Стейкхолдеры не имели единого инструмента для синхронизации своих идей и координации с продакт‑менеджерами.
Первый шаг: общие встречи для выбора задач
Первым шагом на пути решения проблемы стало введение регулярных встреч со всеми стейкхолдерами и продакт‑менеджерами, на которых обсуждались идеи и выбирались те, которые должны были попасть в работу. Мы внедрили принцип вытягивающей системы: как только две задачи завершались командой, две новые идеи могли войти в работу. Это позволило синхронизировать действия всех участников процесса и улучшить контроль над приоритетами.
Для приоритизации задач мы начали использовать методику RICE (Reach, Impact, Confidence, Effort). Этот инструмент помог оценивать идеи более объективно, основываясь на данных, а не на субъективных мнениях. Однако данное решение не решало проблемы проработки идей перед их попаданием в команду. Встречи позволяли упорядочить задачи, но процесс Discovery оставался слабым, решения о выборе задач принимались на основе минимальных данных.
Второй шаг: создание системного Discovery процесса
Чтобы справиться с вызовом недостаточной проработки идей, мы приступили к организации процесса Discovery, который стал следующим ключевым этапом. Мы создали специальную площадку для обсуждения идей, на которой все стейкхолдеры могли представить свои предложения на дальнейшую проработку. Для того чтобы сделать процесс систематизированным и осознанным, каждая идея должна была быть подготовлена по определенным критериям:
Для какого клиента или сегмента пользователей эта идея?
Какую задачу или проблему клиента решает предложенная идея?
На какие метрики повлияет внедрение этой идеи?
Подтверждающие материалы, доказывающие жизнеспособность идеи.
Было установлено ограничение на количество идей, которые мог предложить каждый стейкхолдер — не более одной или двух за встречу. Это стимулировало более тщательную подготовку к презентации идеи и снижало вероятность внесения в работу незначимых или плохо проработанных предложений.
На встречах каждый стейкхолдер имел три минуты для защиты своей идеи, поясняя её ценность согласно указанным критериям. Если идея не проходила защиту или не была подготовлена должным образом, она откладывалась или полностью исключалась из рассмотрения. Это помогло устранить из процесса неподготовленные или низкоприоритетные идеи.
Третий шаг: проведение Discovery спринтов
После питчинга и приоритизации идей наступал следующий этап — Discovery спринт. В каждом спринте команда фокусировалась на исследовании одной или нескольких приоритизированных идей, чтобы определить их жизнеспособность. Ключевым элементом каждого спринта стала его цель, которая задавала фокус команде. В спринтах участвовали продакт‑менеджеры, аналитики, дизайнеры и исследователи, которые в течение двух недель проверяли гипотезы, проводили кастомер‑девелопмент интервью с пользователями и оценивали экономику идеи.
Основной задачей Discovery спринта было не просто проверить техническую возможность реализации идеи, но и оценить, насколько она соответствует потребностям пользователей и может ли она повлиять на бизнес‑метрики. Важно было подтвердить или опровергнуть гипотезы, которые стояли за идеей. Мы внедрили четкое definition of ready для каждой идеи — критерии, которые должны были быть выполнены, чтобы считать идею происследованной.
В конце каждого спринта проводился обзор результатов, на котором продакт‑менеджеры вместе с командой делали выводы о релевантности идей и решали, стоит ли брать их в работу или отказаться. Иногда возникала необходимость дополнительного спринта для глубокой проработки идей.
Четвертый шаг: визуализация процесса и управление задачами
Для лучшего контроля и координации процесса мы внедрили визуализацию работы в Таск‑трекере. Мы создали доску, где по каждому продукту была своя колонка (swimlane), и каждая идея проходила через все стадии: от питчинга до финальной оценки. Такая визуализация позволила нам видеть весь процесс целиком и контролировать поток идей в соответствии с производительностью команд.
Важным аспектом использования доски стало ограничение на количество идей, поступающих в команды. Это помогло выровнять поток задач под возможности разработки и избежать перегрузок. Визуализация также стала мощным инструментом коммуникации между стейкхолдерами и командами, позволяя всем видеть текущее состояние процесса.
Результаты и выводы
В результате внедрения системного Discovery процесса мы смогли значительно улучшить качество принимаемых решений и снизить количество задач, которые попадали в команду без должной проработки. Это не только повысило продуктивность команд, но и улучшило взаимодействие между стейкхолдерами, сделав процесс более прозрачным и предсказуемым.
Систематизация и визуализация процесса Discovery оказалась крайне эффективной. Это позволило нам не только улучшить работу команд, но и обеспечить более предсказуемые результаты для бизнеса. Регулярное проведение питчингов, контроль за количеством задач и четкие критерии готовности идеи сделали процесс разработки более управляемым и эффективным.
Если понравилась статья, приглашаю в свой телеграмм канал, где пишу еще больше полезной информации о построении эффективных процессов.
Больше актуальных навыков по управлению разработкой вы можете получить в рамках практических онлайн-курсов от экспертов отрасли.
