Discovery и Delivery: когда исследования бесценны. Конспект подкаста Kanban Talks
Рассказываем, что такое Discovery и Delivery в современных компаниях и как их выстраивание помогает улучшать процесс создания продуктов
Об авторе и госте подкаста Kanban Talks
Алекс Цыбульник — аккредитованный Канбан-коуч Kanban University (KCP), автор и ведущий подкаста Kanban Talks.
Гость подкаста — Егор Ткачев, Agile-coach, Канбан-тренер, эксперт в OKR и масштабировании Agile по SAFe®.
Что такое Time to market, Discovery и Delivery в компаниях
Time to market — это время от идеи до полной готовности продукта и его выпуска на рынок. Time to market представляет всю цепочку создания определенной ценности, которую можно разделить на левую и правую части точкой принятия обязательств.
Левая часть Discovery — это исследование ценности. Сюда может входить формулирование и уточнение концепции, внесение и анализ предложений, проверка гипотез, приоритизация задач. По итогам этого этапа утвержденные предложения попадают в список требований (бэклог), согласно которому и будет разрабатываться продукт.
Правую часть цепочки представляет Delivery, на котором происходит разработка продукта по оформленному бэклогу.
Зачем нужно выстраивать Discovery
Количество ваших идей, гипотез и опционов всегда будет больше, чем ваша пропускная способность. Discovery помогает вам отсеивать то, на что вам не стоит тратить время и ресурсы.
Если руководитель видит возможность для создания инновационного продукта (принципиально нового или усовершенствованного), он может сразу же начать процесс его разработки, отказавшись от этапа исследований. Однако такой подход может привести к потерям, например:
- перегрузке и несбалансированной нагрузке. Команда требует определенных расходов на оплату труда и времени на производство. Как уже упоминали выше, количество опционов всегда будет больше, чем возможность производственной системы. Поэтому руководители стремятся получить за свои деньги как можно больше результата в максимально сжатые сроки и пропускают Discovery. Но если не уделить время анализу целесообразности задач и распределению нагрузки, то команда просто выгорит от большого количества работы без должного вознаграждения;
- деятельности, не приносящей пользу для продукта и клиента. При оценке результатов работы руководство и команда нередко приходят к выводу, что часть работы можно было не выполнять. Предварительное исследование оптимальной реализации идеи помогло бы заметно сэкономить ресурсы бизнеса и улучшить конечный продукт.
При исследованиях необходимо получить как можно больше информации от клиента и рынка, на который мы выводим продукт, а также любой другой информации, помогающей принять решения по разработке. Так результат будет максимально соответствовать ожиданиям клиента.
Приведем простой пример — строительство дома. Заказчику нужен частный жилой дом, и он нанимает бригаду строителей, озвучив только, что в доме должно быть 4 этажа. Строители незамедлительно приступают к работе. В середине процесса заказчик понимает, что ему потребуется и подвал.
Если бы сначала была разработана концепция дома с чертежами и оценкой всех пожеланий нанимателя, снизился бы и риск сложных и дорогостоящих исправлений.
Если всё же становится необходимо переделать работу даже при наличии Discovery, то мы запускаем новые исследования. Их цель — выяснить, как можно внести в продукт нужные корректировки на данном этапе работы с минимальными затратами.
С чего начать построение Discovery: критерии Definition of Ready
Для эффективного построения Discovery в компании мы проходим следующие действия:
1. Изучаем бэклог и выясняем, как он наполнялся. Как правило, задачи исходят от заказчиков, тимлидов, руководителей.
2. Берем любую задачу и уточняем у команды, каковы их действия при ее получении. Некоторые Scrum-команды берут задачу в работу до анализа и неизбежно тратят время спринта на аналитику.
3. Собираемся с командой и проговариваем всю цепочку выполнения задачи в обратном порядке — от результата до бэклога. В ряде случаев выясняется, что команду не устраивает вид задач, в котором они попадают в бэклог.
4. Уточняем, как должны выглядеть задачи, чтобы команда сразу брала их в работу и выполняла как можно быстрее. Это позволит выработать критерии готовности задач к разработке (критерии Definition of Ready) и ускорить работу.
5. На основании критериев Definition of Ready совместно с продакт-менеджером дорабатываем этап Discovery. Например, вносим критерий ценности задачи от заказчиков, который помогает ранжировать всю работу по приоритету выполнения.
6. Далее команда делит крупные задачи на более простые части (grooming или PBR) и сортирует их по легкости выполнения и ценности (сортировка по скоринговой модели WSJF).
В результате формируется основа Discovery для продукта: бэклог становится более упорядоченным, а команда занимается более ценной и легкой работой.
Дополнительно можно регулярно проводить встречи с командой, добавляя важные для продукта или процесса критерии.
Критерии отказа от задач
Одновременно с Definition of Ready прописываются критерии, по которым задачи полностью убираются из работы. Это экономит ресурсы компаний, защищает сотрудников от выгорания и сокращает этап Delivery за счет выполнения только важных задач.
При этом в основе таких критериев должны находиться конкретные цифры и метрики, помогающие заметить бессмысленные задачи. Выбор метрик зависит от специфики бизнеса и этапа развития компании. Например, для начинающих компаний может быть важно количество новых клиентов, а для более опытных —ROI (Return On Investment, коэффициент окупаемости инвестиций).
Скоринговые модели и триажирование для приоритизации задач
При общении с заказчиками опытный менеджер проекта руководствуется определенными критериями, по которым происходит отсев задач по методу триажа.
Триаж — изначально медицинский термин. Это метод работы специалистов в отделениях неотложной помощи.
В условиях высокой нагрузки отделение может не успевать уделить одинаковое внимание всем пациентам. Тогда проводится триажирование: дежурный принимает решение помогать пациенту сейчас, позже или не помогать вовсе, проводя быструю оценку его состояния.
Метод появился во времена Крымской войны и Гражданской войны в США (1850-1860-е гг.). Ввиду высокой смертности врачам приходилось принимать решение о помощи как можно более оперативно, чтобы спасти тех, кому еще можно было помочь. Так врачи стали делить пациентов на три группы:
- Срочно — нужно помочь прямо сейчас, чтобы спасти жизнь.
- Позже — помочь необходимо, но состояние человека позволяет сделать это чуть позже.
- Не помогать — в помощи нет смысла, так как пациента не спасти или ранения слишком легкие и помощь смогут оказать не в полевом госпитале.
Триаж эффективен и сейчас при планировании работы, позволяя немедленно брать в работу то, что требует срочного внимания и не тратить время на то, что может подождать. Подробнее о триажировании в Канбан-системе можно прочитать здесь.
Однако триажа зачастую недостаточно для принятия решения о работе, которую нужно делать. Непосредственно перед попаданием в бэклог задачи стоит сортировать по скоринговой модели.
Скоринговая модель в IT — это математический инструмент для приоритизации задач по их ценности для конечного результата. Существует несколько моделей, основанных на различных критериях и подходящих для разных продуктов. Одна из них — модель WSJF (Weighted Shortest Job First).
Идея модели WSJF в том, что самый высокий приоритет должен быть у самой простой и ценной для продукта работы. По итогу применения WSJF мы получаем список задач, ранжированный в порядке убывания простоты выполнения и влияния на конечный результат.
Скоринговая модель WSJF состоит из следующих элементов:
• Cost of delay (User-Business Value + Time Criticality + Risk Reduction or Opportunity Enablement) — техническая сложность выполнения задачи. В нее входят:
• User-Business Value (ценность для бизнеса) — оценка пользы задачи для бизнеса,
• Time Criticality (критичность срока) — насколько срочно выполнить задачу,
• Risk Reduction (фактор риска) — изучение рисков и способов их устранения,
• Opportunity Enablement (фактор возможностей) — число потенциальных возможностей;
• Job size (затраты ресурсов) — трудовые ресурсы, время на работу, расходы на внештатных специалистов.
Представим, что мы задумали сделать анимированный снег на нашем сайте. Оцениваем эту задачу по критериям WSJF:
• польза для бизнеса. Задача не принесет практической пользы, поэтому оцениваем ее в 0 баллов;
• критичность срока. Важно успеть сделать снег не позднее Нового Года. Оценим задачу по срочности выполнения в рамках 5-балльной шкалы на 2;
• фактор риска. С потенциальными рисками задача не связана, поэтому 0;
• фактор возможностей. Перспектив для бизнеса анимированный снег также не принесет — 0.
Далее команда рассчитывает, сколько времени потребуется на эту работу. Предположим, 5 часов. Тогда 2/5 = 0,4 балла. В сравнении с остальными стоящими перед командой задачами, создание анимированного снега на сайте вероятнее всего уйдет далеко вниз в списке приоритетности.
Модель WSJF подходит для расстановки приоритетов и в небольших, и в многозадачных бэклогах.
Что делать, если взглядов на ценность работы несколько
Если несколько заказчиков расходятся во мнениях о ценности и приоритетах работы, то существует несколько вариантов выхода из ситуации. Самый простой — предоставить им самостоятельно договориться между собой о критериях ценности задач.
Другое решение — выделение ресурсов команды под отделы в разном объеме. Например, отделу внешнеэкономической деятельности назначаем 60% ресурсов, тогда как административно-хозяйственному отделу — 10%. Приоритет расставлен по важности отделов для бизнеса. Если отделу АХО понадобятся ресурсы разработки, они смогут воспользоваться 10% от текущих возможностей команды.
Как преодолеть сопротивление при построении Discovery
В компаниях может возникать сопротивление, затрудняющее построение Discovery. Идея может считаться долгой в реализации, дорогостоящей и бессмысленной.
Как правило, консультанты приглашаются в компанию для построения этапа поставки ценности — Delivery. Проведя диагностику, специалист может определить продолжительность этого этапа и, исходя из этого, обсудить результаты с руководством.
Например, в одной реально существующей компании этап Delivery занимал 3 месяца. Однако руководитель сообщил, что стандартная продолжительность Time to market — 2 года. Так стало понятно, что всё время, предшествующее трем месяцам фактической разработки, занимает подготовка задач к попаданию в бэклог. Такой срок исследований говорит, что Discovery в компании не формализован.
Существует и такой подход, как создание потребности. Обычно команда точно знает, сколько времени задачи ждут выполнения на каждом этапе минимум и максимум. Собрав эти 3 цифры, уточняем у заказчика реальный срок Time to market — время от взятия идеи в работу до поставки готового продукта.
Вычитая из Time to market время на реальное выполнение задач, получаем неформализованный Discovery. Если этот период в разы больше периода Delivery, заказчик может спросить, почему так происходит. Этот момент — отличная точка внесения предложения по построению и отладке Discovery.
Когда Discovery переходит в Delivery
Точкой перехода этапа исследований на этап разработки продукта в Scrum-командах выступает бэклог. При использовании Канбан-метода такой точкой является точка принятия обязательств — момент, когда команда берет на себя обязательства по задачам. Но случается, что у команды и заказчика разное мнение о том, когда этот момент наступает.
В таких случаях важно проговорить со всеми участниками, в какой момент команда берет на себя ответственность за выполнение работы. До этого момента этап Delivery не считается начатым.
Фиксация точки принятия обязательств упрощает работу команды — становится понятно, с какого момента начинается ее ответственность. С другой стороны, заказчики могут оценить, сколько времени займет работа от точки принятия обязательств до полного выполнения задачи и получения качественного продукта.
Компонентные и end-to-end команды
Если над продуктом работает несколько команд, то точек принятия обязательств может быть несколько. В таких случаях говорят о компонентных командах, отвечающих не за весь процесс создания ценности, а только за его часть. При передаче задач между компонентными командами работа может простаивать, а информация теряться.
Чтобы этого избежать, стоит попытаться создавать end-to-end команды.
End-to-end команды — команды, куда входит большинство специалистов, работающих над продуктом. В них могут входить, например, аналитик, продакт-менеджер, маркетолог, разработчики и менеджер службы заботы о клиентах.
Благодаря таким командам снимается необходимость в передаче работы, устраняется риск потери данных, а задачи не ждут подолгу.
В ряде случаев некоторых специалистов невозможно включить в end-to-end команду. Ими могут стать специалисты, работающие сразу для нескольких командах и достаточно загруженные, чтобы отдавать силы только одному отделу.
В таких случаях есть два пути решения:
- Ресурсы таких специалистов распределяются для каждой команды, где они необходимы.
- Один из участников команды обучается навыкам у таких специалистов, чтобы использовать полученные скиллы внутри своей команды.
Что почитать и у кого поучиться по теме
Книга «Essential Upstream Kanban» от Патрика Стюарта поможет углубиться в тему Discovery в компаниях и применить полученные знания к бизнес-процессам, которыми вы управляете. В книге описано, как упорядочивать идеи и держать их в необходимом количестве в любой момент без перегрузки сотрудников.
Также изучить построение Discovery можно на курсах экспертов. Например:
• Дмитрий Кустов — Agile Coach и LeanStartUp-практик с опытом работы в ИТ и в производственной сфере. Эксперт в реализации продуктового подхода.
• Алексей Пименов — аккредитованный тренер Kanban University, преподаватель международного консорциума ICAgile. Тренер и консультант по темам Kanban Method и Business Agility.
Любой продвинутый курс владельца продуктов также может дать ценную информацию по теме исследований в процессе создания ценностей.
Выводы
Попробуйте формализовать Discovery в своей компании — вполне возможно, вы не только столкнетесь с неожиданными открытиями в области разработки продуктов, но и улучшите результаты вашего бизнеса.
Если вам понравился этот материал, можете послушать другие выпуски подкаста «Kanban Talks» или почитать наши конспекты подкаста: