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

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

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

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

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

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

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

#PG_education
В соседнем чатике разгорелась дискуссия, как планировать техдолг | Сетка — новая социальная сеть от hh.ru
repost

59

input message

напишите коммент

еще контент в этом сообществе

еще контент в этом соообществе

войдите, чтобы увидеть

и подписаться на интересных профи

в приложении больше возможностей

пока в веб-версии есть не всё — мы вовсю работаем над ней

сетка — cоциальная сеть для нетворкинга от hh.ru

пересекайтесь с теми, кто повлияет на ваш профессиональный путь