Представим, вы отвечаете за разработку какого-то продукта. В процессе думания, чтения книг, исследования пользователей и прочей, осознанной и бессознательной деятельности, у вас появляются идеи. К ним добавляются идеи команды, стейкхолдеров... Да кто только не считает своим долгом рассказать вам, как надо развивать продукт.

Допустим, вы всё это записываете в одно место и называете его «бэклог». И однажды хотите, наконец, понять, что же делать в первую очередь. Ответить на этот вопрос поможет приоритизация.

Главное в приоритизации бэклога что? Правильно, чтобы никто не ушёл обиженным. Это особенно актуально в наше время, когда любой занюханный стажёр считает, что факта рождения и умения складывать предложения из слов уже достаточно, чтобы к твоему мнению прислушивались. Скоринг бэклога в том числе помогает решить эту проблему. Хотя основная задача скоринга это, конечно, ускорение time to market. То есть отгружать как можно больше ценности пользователям за как можно меньшее время.

В процессе онтогенеза я пробовал разные форматы ведения бэклога и различные модели скоринга. В итоге пришёл к описанной ниже. Для ведения и скоринга бэклога хватает таблицы в Google Docs и знания математики в объеме начальной школы.

Название идеи

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

Ожидаемый результат

Кратко записываем, что ожидаем получить в результате. Может являться критерием приёмки задачи. Результат должен содержать ценность, которую получает пользователь. Например, «После создания, но до начала сборки пользователь может добавить товары в заказ». Если время потратили, а пользователь это не получил, следовательно задача не сделана. Кстати, есть хороший пост, объясняющий разницу между «сделал» и «делал». Рекомендую прочитать и скинуть команде.

Основная гипотеза

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

Скоринг

Как выше писал, я использовал разные модели, в том числе придуманные мною самим. В итоге остановился на ICE. Эта модель выглядит наиболее интуитивно ясной и геометрически прозрачной, если слегка скорректировать значения. В классическом варианте Impact, Confidence и Effort выставляются по шкале от 1 до 10. Это выглядит субъективно и часто являлось причиной конфликта между мной и стейкхолдерами. В самом деле, как объяснить, чем Impact 3 отличается от 4?

Однажды столкнулся с альтернативной логикой выставления значений, которую сейчас и использую.

Impact

Для определения влияния на бизнес, составляем справочник. За единицу берём значение 1% от значений основных продуктовых метрик. Затем высчитываем соответствующие значения Impact от 0,1 до 10.

Оценивая идею, выбираем соответствующее значение. Метрику берём из основной гипотезы. Если попадаем в интервал, выбираем его нижнее значение. Допустим, мы ожидаем, что внедрение фичи увеличит Метрику 3 на 100. Значение попадает в интервал [90; 105]. Следовательно, Impact равняется 0,6.

NB! Не забывайте обновлять значения Impact в процессе развития продукта.

Confidence

По аналогии с Impact составляем справочник, в котором Confidence = 0,01 соответствует вашему личному мнению. Далее устанавливаем значения  для других источников, откуда приходит подтверждение идеи.

Значения Confidence суммируются и, как и другие параметры, могут уточняться по мере появления новой информации.

Confidence на самом деле так и остаётся субъективной метрикой. Если вы видите сомнение в глазах коллег, рекомендую откалибровать значения, а так же скорректировать список источников. Для калибровки создайте опрос в том же Google Form и попросите указать во сколько раз люди доверяют тому или иному источнику, относительно собственного мнения. После опроса презентуйте результаты, возьмите среднее или медиану и не тратьте своё время на бессмысленные споры. Потому что здесь как на олимпиаде среди мудаков. Даже если вы побеждаете, то всё равно остаётесь мудаком.

Effort

С Effort проще всего. Пишите туда ожидаемое время разработки в часах, днях или неделях. Абсолютно не важно в чём, главное везде использовать одну единицу измерения.

Не пытайтесь вычислить точное время разработки. Помните, целью любого измерения является снижение неопределенности. Кстати, если еще не прочитали книгу Дугласа Хаббарда «Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе», пойдите и сделайте это.

Если хочется большей точности, примените PERT. Я использую упрощенную формулу, в которой в качестве средней оценки беру минимальное. В этом случае конечное значение Effort высчитывается следующим образом:

t(прогнозируемое) = (t(min) + 4*t(min) + t(max))/6

, где t(min) минимальное время на реализацию, t(max) максимальное.

Периодически просите техлида выставлять значения и будет вам счастье. А если еще учтёте, что занимаясь интеллектуальным трудом, человек тратит на работу максимум 80% рабочего времени, то дополнительно повысите точность попадания в сроки.

Кстати, если заинтересовались PERT, посмотрите учебное видео про управление проектами в СССР. Таки да, там тоже были проекты и ими управляли :)

Ссылка на трекер

Последнее поле содержит ссылку на задачу в трекере. В нём хранится подробное описание идеи, дизайн, ссылки на исследования и т.п.

Заключение

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

P.S. Cкачать шаблон бэклога можно здесь.