Любой проект, который призван зарабатывать для организации деньги рано или поздно обрастает техдолгом — решениями, которые в идеальном мире, где время бесконечно, никогда бы не родились на свет. Однако есть задачи, есть сроки, и иногда приходится идти на компромиссы с бизнес-заказчиком. Но даже если взаимопонимание с бизнесом всеобъемлющее, а продукт разрабатывают первоклассные специалисты, техдолг появится всё равно. Просто по той причине что технологии устаревают (особенно в мире фронтенда), меняются и некогда прекрасный проект начинает попахивать нафталином и требовать внимания.
С техническим долгом нужно работать. Но для этого сперва придется заручиться поддержкой со стороны бизнеса. Он должен выделить время и человеческий ресурс на эти задачи. Стратегия ваших действий зависит от того, насколько заказчик понимает те боли, которые несет с собой техдолг и те преимущества, которые даст систематическая работа над ним.
Бизнес понимает ценность работы над техдолгом
Такое бывает, когда проектом руководит бывший «технарь» или менеджер, который завалил 1-2 проекта по причине того, что команда разработки вязла в собственной кодовой базе. Если ваше руководство готово добровольно выделить вам время на такие задачи, вам невероятно повезло. Это редкость. Цените. Благодарите.
Однако так как ветер может смениться, стоит закрепить договоренности в письменном виде. Заключать договор с подписями не нужно, но в документе с правилами разработки можно прописать правило, например о том, что «80% времени команды выделяется на бизнес-фичи, 20% — на технический долг».
Естественно, необходимо гибко подходить к установленным договоренностям. Даже если они прописаны в конфлюенсе. Есть время собирать камни, есть время их разбрасывать. Так же и с техдолгом — в «горячие» периоды перечень грешков проекта будет пухнуть, во времена затишья — пустеть.
Подытожу тем, что в такой ситуации у вас есть все возможности построить системную работу на техдолгом. Не упустите их.
Бизнесу нужно доказывать ценность работы над техдолгом
Самая частая ситуация. Бизнес с одной стороны не имеет ничего против того что вы день-другой поковыряетесь с кодом без очевидного эффекта на прибыльность, но с другой стороны не понимает почему за это он должен платить из собственного бюджета. Поэтому ничего кроме того, чтобы доказывать и объяснять команде не остается.
Загвоздка только в том, что команда разработки и руководства проекта по-умолчанию разговаривают на разных языках. Но разговаривают об одном и том же. Разработка видит красоту проекта в простоте, лаконичности и сокращении времени на поиск багов, бизнес — в скорости, и низкой стоимости доставки стабильных фичей до пользователя.
Задача — перевести с одного языка на другой. И только.
Разберемся на примере. Допустим, на главной странице некого банковского сервиса есть виджет с рекомендуемыми продуктами, который генерирует дополнительные продажи. Вы видите как его код зарастает тиной и чувствуете что настало время просить время на его рефакторинг.
Самый неподходящий способ — объяснять технические детали. Они не интересны никому, кроме команды разработки. Иначе говоря, если вы придете и скажете что написанные на jQuery анимации в этом виджете живут рядом c анимациями на react-spring, что затрудняет внесение изменений, и увеличивает приплод багов, то это мало впечатлит владельца ресурса.
Чуть лучше будет сказать, что рефакторинг необходим для того, чтобы в будущем обеспечить стабильность и скорость доставки новых фичей в этот безусловно важный для бизнеса продукт, снизить стоимость его поддержки и разработки, и из двух решений которые выполняют одну и ту же задачу оставить одно. Это уже разговор на общем языке.
Идеальный спич будет включать в себя чуть больше интересной бизнесу конкретики и чуть меньше технических деталей. По моему мнению, месседж может звучать примерно так
«Сейчас из-за сложности кода мы тратим 80% времени на поддержку и исправление багов в этом виджете и только 20% — на его улучшение. Рефакторинг займет около спринта и позволит нам радикально изменить это соотношение. Мы сможем постоянно запускать A/B-тесты новых предложений, быстро добавлять персональные условия или оперативно реагировать на изменения рынка. Инвестируя в скорость итераций, мы получим рост конверсии по этому каналу продаж. Без этого есть риск серьезно отстать от конкурентов, которые уже сейчас релизятся чаще нас»
Если подобный разговор не приведет к тому, что вам выделят спринт на рефакторинг, вам может пригодиться заключительный раздел поста.
Бизнес против работы над техдолгом
Самая сложная ситуация, когда бизнес «саботирует» работу над техническими задачами без объективных причин. Здесь можно действовать лишь одним из тех вариантов, которые диктует нам самая древняя часть мозга — бей, беги или замри.
Выбрав замирание, вы просто миритесь с тем что происходит и наблюдаете за тем, как ваше детище, продукт ваших рук, вязнет в неэффективных технических решениях. За тем, как снижается скорость разработки, повышается риск выгорания у команды. И вы «горите» вместе с ними. Словом, это точно не выход.
Побег — крайняя мера. Бросить проект, оставить своих парней сражаться с щупальцами спагетти-кода без вас, уйти в другое тепленькое место вы успеете всегда, это дело не хитрое.
Я всё-таки предлагаю «бить». И делать это придется по-партизански. Как хороший партизан знает свой лес, вы должны знать свой проект и его слабые места. И если это так, то вот что вы можете делать:
- Договоритесь, что при оценке сложности задачи, будете закладывать в неё и время на рефакторинг.
- Действуйте по нетленному принципу бойскаута — оставляйте код после себя чище чем он был до вас, то есть «нашли проблему — молча поправили» (если вы применили первый пункт, то время на это у вас заложено).
- Если видите проблемный код, который при некоторых условиях может порождать ошибки, заводите задачи именно как баги.
- Рассказывайте о дополнительно проделанной работе и полученных от этого результатах. Это повысит вероятность того, что отношение бизнеса к «техничке» изменится. Не всю же дорогу «партизанить»
Завершая пост скажу, что техдолг может появиться и когда мы решаем «срезать углы», и случайно, по неопытности или недосмотру автора кода. Однако исчезает он только когда над ним ведется осознанная и структурированная работа.
