Бэклог мечты и разбитое корыто
В рамках годового планирования, мы часто скатываемся до споров, как лучше адаптировать текущую методику приоритизации, чтобы учесть все возможные развилки. У задачи эффект на сто миллионов, разработка на две недели. Берём! Потом выясняется: миллионы посчитали за пять лет, две недели нужны только на код, а интеграцию должна сделать команда, у которой до декабря всё занято. Красиво приоритизировали. На мой взгляд, баланс начинается с нескольких договорённостей, и как ни странно тут ничего нового. 🤡
Сравниваем на одинаковых условиях. Эффект за один период, с понятной вероятностью и объяснением, откуда он возьмётся. Дополнительная прибыль, сэкономленное время и предотвращённые потери требуют разных расчётов. Освободившиеся часы ещё надо суметь использовать. В затраты включаем исследование, зависимости, внедрение и поддержку. Иначе победит задача с самым оптимистичным автором оценки. У него ещё и презентация обычно лучше.🤣
Договариваемся о квотах на мощность команды. Если техдолг каждый раз соревнуется с новой продажей, его легко откладывать до первого серьёзного сбоя. Я бы заранее выделял место для обязательных изменений, надёжности и техдолга, клиентского опыта и развития продукта. Но квота сама по себе ничего не оправдывает: • регуляторке нужны подтверждённый срок и минимально достаточный объём; • техдолгу нужно объяснение, какие сбои, расходы или задержки он создаёт; • улучшению опыта нужна конкретная боль и метрика, которая должна измениться. Доли стоит пересматривать под ситуацию. А если срочная задача съела чужую квоту, честно фиксировать, что именно мы отложили. Бесплатной срочности не бывает.
Оставляем себе возможность ошибиться недорого. Чем туманнее эффект и дороже реализация, тем полезнее сначала проверить самое рискованное предположение. До старта договориться, когда посмотрим на результат и при каких условиях остановимся. А если приоритизация уже подвела? Пересчитать оставшиеся затраты и ожидаемый эффект с сегодняшнего дня. Потраченный бюджет не делает продолжение выгодным. Иногда разумнее сузить решение, иногда закрыть его совсем. И разобрать, где ошиблись: в спросе, оценке работ, зависимостях или самом обещании эффекта. Иначе на следующем планировании просто поменяем формулу и повторим всё с новым названием. Самая дорогая задача в бэклоге вполне может называться «ну мы же уже начали».🫡
