Почему Discovery и Delivery не помогут вам контролировать команду, когда нужны кардинальные изменения

И почему третий — не всегда лишний

В 2005 году был сформулирован подход разработки двумя треками, Discovery и Delivery, — и в рамках отдельных итераций разработку стали вести параллельно по каждому из них. Это позволило быстрее проверять востребованность изменений пользователями и корректировать направление развития.

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

Что такое разработка двумя треками — кратко

В случае с двумя треками разработка продукта или фичи ведется как бы в рамках двух параллельных процессов:

Когда мы говорим о том, что оба процесса идут параллельно, мы слегка лукавим. На самом деле, сущностно работа по ним ведется в последовательном режиме, но очень маленькими итерациями, а сами процессы иногда ведутся в один и тот же момент времени. Схематично это выглядит так:

→ Постановка требований (Discovery),

→ Поставка изменений (Delivery),

→ Анализ результатов и постановка требований (Discovery),

→ Поставка изменений (Delivery),

→ Анализ результатов и постановка требований (Discovery)

→ и т. д.

Такой подход позволяет не “заказывать” разработку фичи, а максимально приблизить и сам процесс разработки, и инженеров к контексту, в котором находится конечный пользователя.

Зачем нужен третий трек?

В теории подход разработки двумя треками звучит как максимально эффективное решение. Однако в реальности теория упирается в ограничения.

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

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

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

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

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

Представим ситуацию. Разработчикам прилетает задача доработать процесс оформления заказа для оптовых клиентов: добавить туда опцию “начать собирать заказ только после оплаты”. Сейчас все заказы собирают сразу, в результате некоторые лежат на складе неделями, а более востребованные наоборот не успевают укомплектовать к приходу покупателя.

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

Проблема в том, что текущий способ — на самом деле, реализованная возможность оплачивать заказ при получении. Осталось только добавить опцию с оплатой при оформлении — а такой функционал уже реализован для остальных клиентов, его не нужно “изобретать”, достаточно взять готовое решение. В результате у людей появляется выбор, когда именно им удобно оплатить, у работников склада — понимание, какие заказы в приоритете, а у разработчиков — возможность перейти к работе над другими проектами. Да, в моменте это решение требует больше временных затрат на изучение проблемы, но в долгосрочной перспективе оно гораздо эффективнее — как для клиентов, так и для компании; на него не требуется инвестиций и времени разработчиков.

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

Что собой представляет третий трек?

В трехтрековом подходе к двум уже известным нам трекам добавляется третий. Получается такое разбиение: Исследование, Проектирование, Поставка. Или Learning, Problem Solving, Execution. Или Discovery, Design, Delivery — остановимся именно на этом варианте.

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

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

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

Добавление третьего трека выносит анализ проблемы на отдельный уровень, Discovery, он перестает оцениваться временными затратами, а на первый план выходит эффект для бизнеса или влияние на удобство пользователя. Поиск и описание решения же становится прерогативой этапа Design, эффективность которого все еще можно оценить в рамках стандартных метрик: временных и финансовых затрат. Благодаря этому появляется контролируемость и предсказуемость.

То есть теперь Discovery — детально исследует проблему, Design — ищет варианты ее решения, Delivery — решает. В итоге получается комплексный взгляд, а у каждой из команд появляется больше ресурсов.

Если вернуться к примеру с перееданием:

Разница налицо.

В чем плюсы трехтрекового подхода?

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

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

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

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

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

Поэтому остается решать проблему масштабирования за счет увеличения глубины исследования. Добавление третьего трека позволяет в процессе аналитики сразу объединить массу проблем в одну. Когда разработчики находят для нее решение, число входящих запросов резко падает. То есть, при том же объеме работы и том же количестве ресурсов, результат становится куда более заметным. Условно, вместо того, чтобы постепенно решать 100 простых проблем, можно потратить больше времени и решить одну сложную, избавившись сразу от 1000 проблем в будущем.

Так, например, с помощью трехтрекового подхода в “Леруа Мерлен” удалось объединить опыт онлайна и оффлайна. Исторически проблемы в обоих каналах различались лишь на словах, а по сути были одним и тем же — однако из-за недостаточного глубокого Discovery увидеть это было невозможно. Благодаря объединению затраты на изменения сократились более чем на 40% — а в перспективе экономия будет еще существеннее.

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

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

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