Что такое технический долг – все в ИТ-отрасли знают. Если кто-то не знает, то на хабре или даже в Википедии вполне прилично все описано, не вижу смысла дублировать. Но если ответ на вопрос «что это» обсуждается повсюду, то ответ на «а как им управлять» найти куда сложнее.
Что делаем мы у себя в компании для контроля технического долга (не для всех проектов, но там, где применимо):
- Мы регулярно оцениваем объем долга. Есть критерии, которые позволяют отнести его в зеленую (все ок, работе не угрожает, даже если разработчикам не нравится), желтую (угроза задержки дальнейшей реализации функционала системы, если все оставить как есть) или красную зону (если не исправить, дальнейшая работа будет сорвана точно).
- Мы включаем работу по исправлению для красных и желтых зон в список ближайших работ с высоким приоритетом. Несмотря на попытки разработчиков слегка тут сманипулировать РМом-неудавшимся программистом, важно отделять от «угрожает когда-нибудь» (тогда и делать будем когда-нибудь) от «нельзя сделать этот кусок в следующем спринте, потому что…» (делать будем тоже в следующем, без вариантов), а иначе это будет только полировка и ничего больше.
- Мы не преследуем цели сделать «идеальное» решение, если долг висит, но не мешает – пусть висит. Это как задолженность по ЖКХ – противно, периодически о себе напоминает, но жизнь сильно не портит.
- Мы делаем все, чтобы прототип уничтожался после согласования, чтобы избежать покушения бизнеса на работу с ним или попыток сделать что-то на его основе. Лучше сразу от такого искушения избавляться, если нужно – то самыми радикальными средствами.
- Все элементы технического долга логируются в бэклоге и иногда, в качестве мотивации, могут реализовываться вне указанного сценария (просто потому, что очень хочется разработчику, но с моего согласования). Идеологически это нехорошо (мы тратим ресурс на не-бизнес задачу), но практически – мотивация такая же часть управления проектом, как и согласование объема работ, и я считаю такую небольшую манипуляцию нормальной пока она не превышает 5-10% от запланированной бизнес-работы.
Если надо – я доношу это до руководителя и заказчика. Для визуализации, кстати, хорошо работает инфографика (вот тут я рассказывала о бесплатных инструментах, которые я использую). Еще часто помогает аналогия с финансовым долгом (чем больше долг, тем больше проценты по нему, и тем большие ресурсы мы тратим на погашение этих процентов, а не на создание новой ценности для себя).
Коллеги иногда используют еще разбивку долга по областям в соответствии с диаграммой ниже, но я ленюсь, особенных выгод в этом не вижу.
Система неидеальна (а с точки зрения разработчиков – вообще бардак-бардак), но для меня как для РМа – работает, позволяя обеспечить приемлемое качество планирования без большого количества неприятных сюрпризов. Для тех, кто хочет очень глубоко вникнуть в тему – вот тут есть отличное интервью на тему технического долга (но длинное, имейте ввиду).
Добавить комментарий