Недавно редакция банка сделала очередной подход к оценке задач. Расскажу, что из этого вышло.

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

Попробовали новую систему оценки

Редакция работает по гибридной методологии scrumban. Для оценки сложности и трудоемкости задач в гибких методологиях используются условные единицы Story Points (стори поинты или просто стори).

Для удобства оценки 1 стори поинт равен 15 минутам работы над задачей. Сюда входит редактура, согласование, уточнение брифа, созвоны и любые другие обсуждения задачи со стейкхолдерами.

Мы попробовали технику «трех точек» — ставим задаче три оценки в стори поинтах: оптимистичная оценка (О), приближенная к реальности (R), пессимистичная (Р). Все складываем и делим на 3. Например, надо написать пуш:

О — 2 R — 4 P — 6

Это значит, что в идеальных условиях редактор (О) напишет пуш за 30 минут: примерно 5–15 минут на изучение брифа и написание без дополнительных вопросов, 3–5 минут на ревью, 5–10 минут на отработку и внесение комментариев, а заказчик принимает текст без вопросов.

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

В пессимистичную (Р) оценку заложили, что в задаче все пошло не так: сначала долго уточняли бриф, потом переписывали на ревью, а в конце пришлось созваниваться с заказчиком на полчаса и выдумывать велосипед, потому что текст не решает продуктовую проблему. Возились 1,5 часа.

В среднем получается 4 стори поинтов или 1 час чистой работы.

Что влияет на оценку

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

✅ Формат и количество коммуникаций — пуш пишется быстрее, чем лендинг; лендинг пишется быстрее флоу в приложении

✅ Старый или новый продукт, его сложность; количество условий для акции; ограничения продукта, если это экран в приложении; уровень неопределенности в задаче или типовое решение

✅ Сложность согласования с отдельными командами, количество ЛПРов, историю отношений и другие человеческие факторы

Что пошло не так

Пока нам не удалось внедрить оценку на постоянной основе, вот основные сложности:

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

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

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

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

#процессы