Проверка гипотез. Часть 1 — скорость разработки
Коллеги недавно прислали в чат фотографию, где одной из команд вручают приз за 299 проверенных гипотез за год.
И вот после таких фотографий в чате всегда наступает неловкое молчание и попытка переложить свой результат на эту шкалу, где 299 — это полный восторг.
Давайте вспомним математику 3 класса и сделаем несколько вычислений. 299 гипотез делим на 12 месяцев получаем 24,9166666667.
Стоооооп! Некрасивые числа. Давайте округлим до 300 и сделаем допущение, что ребята работали в спринтах по 2 недели, тогда цифры получатся классными.
300/24 = 12,5 гипотез в спринт
Ого!!! — скажут некоторые
Нифига… — скажут продакты
Проверять — не значит делать. Обычно, лишь 1 гипотеза из 10 реально работает, а то и меньше. Поэтому 12,5 надо смело делить на 10.
1,25 гипотезы в спринт
Вот! Это уже похожий результат, кажется не так много, но на самом деле много. Быстрые команды, которые мне удавалось видеть, делают более-менее средние фичи (не просто покрасить кнопку) за 20–30 дней (Lead Time). Берем время от старта разработки до релиза. Это еще без этапа Discovery.
Скорость команды на этапе реализации — действительно важный параметр в уравнении вашего успеха, но не основной.
Обязательно следите за Lead Time в команде, если вы этого еще не делаете. Это очень легко и быстро (если вы используете Jira):
Открываем Jira в Google Chrome
Ставим расширение Scope 360
Заходим на доску нашей команды (или всех команд)
Жмем кнопку Analyze Flow в верхней панели
Переходим на вкладку Lead Times
Настраиваем от какого статуса до какого будем мерить Lead Time и смотрим на результат
Мериться значениями нужно на 80 перцентиле
Еще можно создать разные фильтры для разных задачек. Делать это нужно в настройке вашей доски, а не в инструменте расширения
Пишем в комментарии какой Lead Time для задачек типа Story с момента старта разработки и до релиза в прод получился у вас. У меня вот получилось 33 дня
Ну что? Теперь 1,5 гипотезы в спринт это много или мало? Если ребятам действительно удается выпускать фичи в команде в 2 раза быстрее чем нам, то они большие молодцы. Правда, мы не знаем сколько команд проверяли эти 299 гипотез. Может их там было 10, история умалчивает. Кстати, хороший Lead Time и Backlog из качественных задач может стать отличным аргументом для масштабирования команд. Когда вы зарабатываете деньги, а ваш Backlog растет быстрее, чем вы его закрываете и, при этом, Lead Time не пол года, то смело формируйте еще одну команду, только не вздумайте расширять текущую — это плохой паттерн и с высокой вероятностью вы станете только медленнее.
Lead Time — это все очень здорово, но где брать качественный backlog? И вот здесь как раз и кроется настоящая работа PO. Наша задача подкидывать команде качественный backlog с проверенными гипотезами, с подсчитанной экономикой и более-менее гарантированным результатом.
В году около 250 рабочих дней
300/250 = 1,2 1,2 гипотезы в день вам надо проверять, чтобы 1 из 10 оказалось успешной и вы принесли ее в команду!
Ну как? Сколько гипотез проверяете вы?
Про то как проверять больше, что нужно проверять, а что не обязательно и будет вторая часть, где мы с вами постараемся посчитать и выбрать оптимальные пути проверки гипотез, а так же мои мысли на этот счет.
Если хотите узнать более подробно про процессы и скорость в Лиге Ставок, то вот статья про процессные метрики
