Алло, алло! Это техдолг, не кладите трубку!
Наткнулась на занятное исследование про управление техническим долгом. Там команды попробовали новый подход: они не просто складывали долги в отдельный список «потом когда-нибудь», а ввели для этого структурированный шаблон.
Они стали играть в техдолг по-взрослому: 🔘 у каждого долга появилась карточка с обязательными полями (описание, где проявляется, риск, кто владелец), 🔘 карточки собирались в отдельный дашборд, связанный с бэклогом, 🔘 на ретро и планированиях техдолг обсуждался так же, как и новые фичи.
Эффект оказался заметный: 🔘 долг перестал быть «абстрактным монстром из будущего» и стал понятной задачей, 🔘 его начали обсуждать и приоритизировать наравне с фичами, 🔘 команды осознаннее планировали спринты и честнее говорили про риски.
У нас так пока не работает. Чаще всего технический долг в головах команды, охраняется семью замками, и о нём вспоминают только тогда, когда уже «горит». Для продакта это превращается в сюрприз – и не из приятных.
Хорошее напоминание, что долг должен быть видимым и обсуждаемым, иначе он всегда будет проигрывать «новым классным задачам», пока однажды не станет пожаром.
Ещё бы было неплохо на него тоже эффекты показывать, например, сколько денег/CR и тд мы можем потерять, если не сделаем воооот ту задачку из комнаты страхов, а то аргументов маловато.
Как у вас дела с техдолгом?
· 03.10.2025
В малых/средних проектах тех долг копится из-за сложности выбить бюджеты. Костыляется, пока это чудовище не упадет. Я старалась хотя бы критические моменты решать раз в квартал. Полностью на 100% чтобы одна такая задача была выполнена раз в 3 месяца. Тогда и по деньгам оптимально и разраб не демотивирован. Конечно, помогало еще заранее знать вектор развития продукта, что планируют, что уже начинают внедрять и с какими подрядчиками коммуницировать. Тогда это позволяет заранее начать вычищать «сухую листву», чтобы предотвратить пожары. И клиент доволен, что заранее соломку подстелили и мы рады - легче работать.
Мне очень помог открытый диалог с разработчиками. Они, увидев мою нейтральную по отношению к ним позицию, переставали воспринимать меня как нападающего и агрессивного пма и легко рассказывали о проблемах проекта или чем грозит быстрая реализация конкретной задачи. Это очень меня выручало. Иногда быстро и «на скорую руку» сделать было решением клиента, я объясняла эту позицию разрабу, многим это не нравилось: «как так, результат моего труда и некачественный?!». Всё решалось диалогом и пониманием. Ну а следила +- за тех долгом с помощью технической документации и дневник проекта, которые мы вели с командами) тогда всегда известно где проблема, почему она есть, как это работает и какие варианты решения/обхода. За тех докой я следила как цербер, вот тех дока была одним из немногих моих не прогибаемых блоков работы, где я не давала спуску.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён