Продолжаю про техдолг. Напомню, что анализ от CodeScene и Stripe показал: неэффективная работа команд разработки приводит к потерям в $300 миллиардов глобального ВВП ежегодно, а незапланированная работа занимает 23–42% времени разработчиков.

Как же решить эту проблему или хотя бы снизить влияние техдолга на качество и скорость разработки?

— Самый частый ответ, который я слышу от моих уважаемых коллег, когда речь заходит о запуске новой функциональности в существующем продукте — «нужно всё переписать». Если идти по этому пути, то нас ждёт минимум 6 месяцев переписывания, затем ещё пара месяцев исправления багов и отсутствие уверенности в том, что стало лучше. А ещё интереснее становится, когда новый разработчик приходит в команду и говорит: «нужно всё переписать». Тут я всегда вспоминаю про врачей — каждый следующий пытается как-то принизить выводы предыдущего.

— Второй подход — выделить 10–15% времени в каждом спринте на работу с техдолгом. Это компромиссное решение: вроде бы и разработчики довольны, что у них есть время на оптимизацию кода, и продакт не чувствует сильного давления. Но такой подход показывает, что команда не синхронизирована и не движется к общим бизнес-целям.

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

— Лучший же подход — это обоснование от технической команды, как конкретный рефакторинг повлияет на бизнес-цели компании:

• Сократится time-to-market.
• Уменьшится количество багов после релиза.
• Улучшится восприятие качества продукта со стороны пользователей.

В этом случае действия команды не только направлены на достижение общих целей компании, но и позволяют продакт-менеджеру сравнить эффект от устранения техдолга с реализацией новых возможностей. Это может привести к решению полностью посвятить спринт техническим задачам, а не разработке новой функциональности.

Выводы:

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