Роадмаппинг здорового человека

"Roadmaps should be lists of questions, not lists of features"

Парадоксальную вещь напишу. Если вы время от времени думаете: “а запишу-ка я себе заново вот самые срочные доработки/улучшения в продукте, которые вот нужно сделать совсем в следующем спринте”, и у вас получится список на 6 месяцев - значит, все хорошо. Ну в самом деле. Это значит, что вы думаете о вечном (зачеркнуто) о важном, и знаете чего от вас ждут пользователи/бизнес. И главное, у вас есть простор для полезных упражнений по приоритезации. Ограничения ресурсов есть везде - будь вы стартап, энтерпрайз с миллионами долларов дохода, или Google.

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

Одна из самых полезных вещей, которые быстро можно сделать (кроме сортировки по принципу business value vs. оценка времени на разработку, конечно) - это:
1. Взять свой роадмап на период (квартал, полгода, год, просто набор самых важных фич которые вам “очень нужно” произвести)
2. Убрать из него таймлайн и любые привязки ко времени (комитменты, запросы от клиентов, обещания стейкхолдерам..)
3. По каждому эпику/истории/фиче задать себе один из двух вопросов (на выбор, с чем вам в данный момент комфортнее работать):
* Зачем мы это делаем? Как это облегчит жизнь нашему пользователю (клиенту, сейлзам, CSM, - но первично все же юзеру)?
* Если мы реализуем эту фичу в самом офигезно идеальном виде, как мы об этом узнаем? (подсказка: метрики).

Поскольку с “зачем” нам все же проще (специфика, в которую здесь вдаваться не буду), мы по каждому эпику написали список метрик, по которым мы явно можем отследить влияние (impact) нашей работы на жизнь живых пользователей. Например, уменьшится количество инцидентов/обращений по этому блоку функционала, увеличится количество создаваемых сущностей в этом разделе, снизится время на онбординг новых пользователей, снизятся затраты на поддержку вот этой фичи, увеличится доход с вот этого типа лицензий и т.д. У вас это могут быть метрики, характерные вашему продукту и бизнесу.

Самое главное - они легко рождаются в процессе таких размышлений. Сам процесс выглядит незатейливо: если у вас есть продуктовая команда, возьмите список фич и каждый отдельно выпишите по ним на стикеры свои метрики/признаки. Потом сравните ваши идеи, объедините их в кластеры, обсудите. Итоги впишите в документ (Confluence, GoogleDoc..).

Что интересно - на первый взгляд это мало связано с приоритетами, но на самом деле нет. Как только вы думаете о метриках, вы автоматически начинаете думать о пользовательском поведении и его изменении в результате вашей работы. Это очень тонкий момент, и очень продуктивный способ начать думать именно в таком ключе (не говоря уже о том, что вы получаете субпродукт в виде метрик, по которым можете впоследствии отслеживать эффективность/целесообразность внедрения функционала и улучшений (все же вы могли ошибаться, и это тоже бывает: build-measure-learn цикл никто не отменял).

Как только вы начинаете думать о поведении пользователей, вы можете увидеть новые способы удовлетворить их потребности, или же несколько фич, направленные на решение одной и той же проблемы. В последнем случае вы можете от чего-то отказаться, или напротив - объединить несколько эпиков в один и сэкономить на оверхэдах в виде кик-офф презентаций, сдаче эпиков по Definition of Done, нагрзочному тестированию и т.п. Последний вариант звучит не очень lean, но вы можете быть уже далеко позади стадии поиска product-market fit, и искать способы оптимизации.

Пост, который меня вдохновил вспомнить об этом полезном занятии как раз перед каникулами: https://medium.com/@jboogie/roadmaps-are-linear-software-projects-arent-e50fb142036f

Желаю вам продуктивного подведения итогов и разумного взвешенного планирования - с вашими пользователями в уме 😉