В соседнем чатике разгорелась дискуссия, как планировать техдолг.

Загвоздка вот в чем: задачи по техдолгу сложно защитить перед стейкхолдерами, так как а) они позволяют экономить в будущем, а не зарабатывать, б) не закрывают напрямую проблемы юзеров.

Но быстрорастущие продукты не могут избежать техдолга — он помогает командам двигаться быстрее. Вопрос в том, как его контролировать, чтобы он не парализовал разработку.

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

Принесла вам табличку из Reforge с предложением, как можно приоритизировать задачи тех долга.

❤️ Где возникает техдолг? 1. Внеплановые задачи 2. Временные решения 3. Устаревающие технологии 4. Незапланированная работа Важно не просто снижать долг, а управлять им, выбирая, когда и сколько закрывать.

❤️Как приоритизировать? 1. Уверенность – насколько велика вероятность проблемы? 2. Время – как скоро проблема станет критичным? 3. Влияние – ухудшит ли проблема опыт пользователей? 4. Последовательность – мешает ли развитию продукта? 5. Накопленный долг – не тормозит ли он команду?