Очень часто затыком в развитии становится не отсутствие технических задач, а то, что на них не выделяют ресурсы.
С точки зрения бизнеса это логично. Зачем делать непонятный рефакторинг, если можно запилить ещё одну фичу, продать её клиентам и заработать денег? Бизнес не хочет тратить ресурсы на что попало. Он хочет понимать пользу.
Поэтому техническую задачу мало найти и описать. Её ещё нужно продать. Проще говоря, чётко ответить на вопрос: а нахрена вообще это делать?
Перевести проблему на язык бизнеса
Аргументы вроде «тут говнокод» малоубедительны. Бизнес не знает, что такое говнокод, зато знает, что такое деньги. Разговор стоит строить вокруг наблюдаемых последствий:
- в этом куске кода постоянно появляются баги;
- даже простая задача в компоненте съедает много времени;
- медленный код ухудшает клиентский опыт;
- ручное тестирование стало узким местом и задерживает релизы;
- устаревшее решение мешает выпустить нужную функцию.
Затем проблему можно связать с метриками: количеством багов, временем выхода изменения, загрузкой QA, частотой сбоев или потерей клиентов. Продавать нужно не рефакторинг, а изменение этих показателей.
Пример из практики
Однажды в моей команде тестирование стало узким местом. Разработчики быстро делали фичи, но их не удавалось так же быстро выпускать. Я договорился с руководством, что разработчики помогут разгрузить тестировщиков автотестами.
Критичные сценарии покрыли автотестами, тестировщикам стало проще управлять задачами, а скорость релизов выросла. Для бизнеса ценность оказалась понятна: мы стали быстрее доносить изменения до клиентов.
Сделать техдолг осязаемым
Даже проданный техдолг легко снова утопить в бэклоге. Поэтому я придерживаюсь ещё трёх правил:
- Техдолг должен жить в таск-трекере, а не только в
TODOв коде. - Описание задачи должно отвечать на три вопроса: в чём проблема, на что она влияет и как должно стать.
- Большие задачи нужно разбивать на подзадачи, чтобы их можно было постепенно встраивать в план.
Не каждую техническую задачу нужно делать немедленно. Но если команда не может объяснить цену откладывания, у бизнеса нет причин отдавать этой работе приоритет.