Почему мы убили половину продуктового бэклога и стали выпускать быстрее
В какой-то момент наш продуктовый бэклог распух до двухсот с лишним задач. Каждая выглядела «важной», каждую кто-то лоббировал, и мы честно пытались всё это делать. Релизы становились всё реже, а ощущение прогресса — всё слабее. Полгода назад мы убили примерно половину бэклога за один присест. Парадоксально, но именно после этого мы стали выпускать быстрее и спокойнее. Рассказываю, как и почему.
Откуда вообще берётся раздутый бэклог
Бэклог растёт, потому что добавить задачу ничего не стоит. Кто-то на созвоне сказал «а давайте ещё вот это» — и оно осело в таск-трекере. Заказчик попросил — записали. Сами придумали на воодушевлении — записали. В итоге бэклог превращается не в план, а в свалку идей, по которой невозможно ориентироваться. И главное — он создаёт ложное чувство, что у тебя «всё под контролем, просто рук не хватает». На самом деле не хватает не рук, а решений о том, чего НЕ делать.
Что мы сделали
1. Признали, что задача в бэклоге старше трёх месяцев — это уже не задача, а артефакт. Если за квартал до неё не дошли руки, значит, она не настолько важна, как казалось в момент записи. Всё, что лежало нетронутым дольше трёх месяцев, мы вынесли в отдельный архив. Не удалили навсегда — просто убрали с глаз. За полгода оттуда вернули три задачи. Три из сотни. Остальные девяносто семь никому не понадобились.
2. Ввели одно простое правило для новых задач: у каждой должна быть гипотеза. Не «сделать фильтр по дате», а «мы считаем, что фильтр по дате уменьшит число обращений в поддержку на тему поиска заказов». Если гипотезу сформулировать не получается — задача не проходит. Это отсекло огромный пласт фич «потому что у конкурента есть» и «потому что выглядело бы круто».
3. Перестали оценивать задачи по трудозатратам и начали — по тому, что будет, если мы её НЕ сделаем. Большинство задач при таком вопросе оказываются безобидными: не сделаем — ничего страшного не случится. А вот те немногие, где «не сделаем — потеряем клиентов / деньги / данные», и есть реальный приоритет. Этот вопрос отсортировал бэклог за пару часов лучше, чем все наши прошлые системы скоринга.
Что изменилось
Самое неожиданное — скорость. Казалось бы, мы не стали работать быстрее физически. Но когда из поля зрения исчезли сто пятьдесят «может быть когда-нибудь» задач, команда перестала тратить силы на постоянную переоценку приоритетов. Раньше половина планёрки уходила на спор, что важнее. Теперь спорить почти не о чем: в работе только то, у чего есть внятная гипотеза и цена бездействия.
Второе — стало проще говорить «нет». Когда у тебя есть явный критерий (гипотеза + цена бездействия), отказ перестаёт быть личным конфликтом. Это не «мне не нравится твоя идея», а «эта задача не проходит по критерию, давай сформулируем гипотезу». Холодный механизм снимает эмоции.
Чего я бы остерёгся
Не превращайте чистку бэклога в новый ритуал, который сам по себе пожирает время. Мы делаем ревизию раз в квартал, за один час, по простым правилам. Если на наведение порядка в задачах уходит больше, чем на сами задачи, вы просто заменили одну форму прокрастинации другой.
И не путайте «убить задачу» с «задача плохая». Большинство выброшенных идей были нормальными. Просто нормальная идея и идея, которую стоит делать именно сейчас, — это очень разные вещи. Бэклог должен быть списком решений, а не списком всего, что в принципе можно сделать.
Если у вас бэклог давно перевалил за сотню задач и вы к нему боитесь подходить — попробуйте простой тест: пройдитесь по верхним двадцати и к каждой задайте вопрос «что будет, если мы это НЕ сделаем». Подозреваю, половину вы закроете сразу.
А как вы решаете, что НЕ делать? Интересно, кто какими критериями пользуется.