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

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

Начнем с главного: как понять, что у вас вообще есть проблемы с техдолгом? Я выявил для себя некоторые симптомы, речь о которых пойдет ниже.

Симптомы техдолга

Для начала давайте разберемся в определениях и поймём, что я подразумеваю под техдолгом. Техдолг — любые технические особенности системы, которые тормозят развитие продукта и замедляют скорость решения задач.

Здесь важно упомянуть, что помимо технического долга я выделяю два вида долгов: процессные, возникающие когда вы не адаптируете процессы под меняющуюся реальность, и человеческие, накопленные из-за недостаточно качественной работы с людьми. И, на мой взгляд, не бывает ситуации, когда в команде присутствует только один вид долга. Обычно один долг всегда порождает другой.

Поэтому перечисленные ниже симптомы могут быть вызваны различными причинами. Я лишь указываю на то, что такие симптомы могут свидетельствовать о проблемах с техдолгом. 

1. Невозможно дать оценку задачам

Вы часто слышите или сами говорите фразы: «Это надо идти код смотреть!», «Тут всё не так просто», «Ну, чтобы это оценить, это надо сделать». 

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

2. Задачи делаются долго

Возможно, вам повезло, вы таки смогли оценить задачу или, что ещё лучше, взяли в работу без оценки. Но вот беда — разработка никак не заканчивается! Мердж-реквесты гоняются кругами между ревьюером и разработчиком, а потом между разработчиком и тестировщиком, а потом между релизом и откатом. В общем, заходят в разработку и никогда не выходят.

Иногда бывает наоборот: сделали быстро, а потом сидим и боимся выкатывать, потому что нет тестов, и мы не уверены в надежности и качестве своего решения. Разработчики начинают жить по принципу «как бы чего не вышло». 

Может быть и так, что задача не наворачивает круги между этапами разработки, а честно выстаивается на каждом из них в количестве месяцев, достаточном для выдержки вина достойного качества. Причины могут быть разными: от отсутствия возможности локальной отладки до запутанной кодовой базы, в которой без того самого вина не разберешься.

3. Качество сервиса деградирует

Даже если вы не задумывались о системном измерении уровня качества, вы можете замечать его падение. Растет число факапов, решение инцидентов и разбор багов занимают значительную часть времени команды. При этом самих багов и проблем, конечно, тоже становится заметно больше.

4. В коде есть неблагополучные районы

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

5. Понятно только одному

Помимо «неблагополучных» районов есть и «заброшенные». В них ориентируется только один человек. Обычно это тот, кто дольше всех в работает в проекте и кто всё это когда-то однажды и придумал. Новые люди понять и разобраться не могут или не хотят. Вы знаете про такие места и с ужасом представляете себе день, когда человек-басфактор уйдет из команды. 

6. Длительный онбординг

Вам трудно нанимать новых людей. И нет, дело не в деньгах. Просто погружение новичка в контекст системы сравнимо по сложности с получением высшего образования. Новый разработчик очень долго не может выйти в плюс по производительности. На его вопросы о том, «почему вот это так сделано», вам приходится неловко смеяться. А на любое его предложение об улучшениях у вас есть ответ, что последний, кто попытался такие улучшения внести, уволился после этого упражнения.

Сюда же относятся случаи, когда любая операция новичка сложнее коммита происходит под присмотром наставника («сейчас я тебе покажу, как у нас релизить!»). Можно решить, что дело в отсутствии документации, но бывает и так, что простые операции, про которые и подумать нельзя, что они должны быть задокументированы, на поверку оказываются сложными и требующими подробнейших инструкций.

7. Разработчики уходят

Вы замечаете, что все больше людей стали покидать команду. Новые люди надолго не задерживаются, «старички» тоже рано или поздно устают от кучи накопившихся проблем. Разработчики, которые пытаются что-то менять, не справляются со сложностью взятой на себя задачи, выгорают и покидают вас.

*8. Вами недовольны в отделе качества

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

С чего начать работу над техдолгом

Надеюсь, вы не узнали себя в перечисленных симптомах. Но если и узнали, то это не катастрофа. Просто настало то самое время разобраться с техдолгом. Понятая проблема — уже наполовину решенная проблема. 

0. Привлекайте внешнего человека

Это важный совет, который я прочувствовал на себе. Чтобы провести аудит, лучше всего постараться привлечь внешнего человека. Иначе не видно, что на самом деле у вас не так и почему.

Когда долго работаешь в команде, взгляд может замылиться. К каким-то проблемам можно сильно привыкнуть, но для внешнего наблюдателя они будут очевидны. В то время как вам они могут казаться старыми добрыми «особенностями».

Как найти такого внешнего аудитора? Зависит от того, как все устроено у вас в компании. Например, у нас в Контуре матричная структура управления, есть функциональный руководитель, и именно к нему с такими вопросами и ходят. Если вы не тимлид, а разработчик, то в первую очередь поговорите с тимлидом. Может, он уже занимается этим вопросом.

Возможно, нового человека привлечь не получится, особенно если у вас сложный онбординг, и вы понимаете, что даже если новый человек придет, то он еще полгода ничего не будет понимать в происходящем. Тогда можно попробовать самому стать таким внешним человеком — уходите на стажировку в другую команду (да, в Контуре ещё и так можно сделать), желательно, где всё получше, чем у вас. Даже если не получше, то с другим техдолгом. Вещи, которые сделаны у вас плохо, у них сделаны хорошо и наоборот. Так вы посмотрите на других, отвлечетесь от своего контекста, вернетесь свою команду и посмотрите на свои проблемы свежим взглядом. 

Теперь перейдем к конкретным шагам аудита, которые зарекомендовали себя на практике. 

1. Обратитесь к best practices других команд

Например, у нас best practices собраны в «Инженерном пути», где описаны технологические принципы, инженерная культура предъявляемые к приложениям требования. Есть практические гайды и примеры, как надо проектировать типовые сервисы.

«Инженерный путь» появился сравнительно недавно. И когда его еще не было, я любил заглядывать на wiki-страничку с best practices от отдела качества разработки. Уверен, что похожий документ или база знаний есть во многих компаниях. Если их нет — это повод создать.

2. Изучите труды предшественников

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

Вы можете всё это найти, систематизировать и вписать в текущую общую картину.

Например, в одном из проектов, в который я пришел, меня ждал многообещающий файл Readme.md, в котором автор перед уходом из команды подробно изложил, какие доработки требуются в системе.

3. Изучите динамику качества

Мы обсуждали проблему падения качества сервиса из-за накопленного техдолга. Можно попробовать найти какие-то объективные артефакты, что это не просто «раньше трава была зеленее», а сейчас действительно стало не так, как раньше. 

Возможно, вы измеряете SLO или ваша команда пишет постмортемы. У нас эта культура довольно неплохо развита. 

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

Поговорите с теми, кто долго в команде. Есть шанс, что они вспомнят именно объективные критерии того, почему раньше было лучше. Также важно измерить общее настроение в команде, ведь если проблемы есть, люди захотят рассказать о них.

4. Проведите интервью с различными ролями

Узнав общее настроение команды, можно углубиться и проинтервьюировать разные роли, выяснить, какие у кого есть проблемы, так или иначе связанные с технической составляющей. Чем больше ролей сможете опросить, тем лучше. 

Понятно, что мы, инженеры, чаще всего интроверты и разговаривать не любим. Поэтому стоит поговорить хотя бы с максимально смежными с вами людьми — это менеджер разработки, аналитик и тестировщик. Они вам расскажут много интересного:

• Скорее всего, менеджер будет недоволен тем, как задачи едут. Тогда следует покапать, какие есть технические ограничения, почему задачи по конвейеру идут медленно.

• Аналитику может не хватать каких-то данных, чаще всего данных с боевой, на которые хотелось бы посмотреть. Зачастую аналитические инструменты можно довольно дешево создать и решить проблемы аналитиков.

• Тестировщики могут сильно страдать от неправильных, неудобных инженерных решений. Я уже писал о том, что часто задачи невозможно протестировать. Стоит выяснить, какие существуют технические ограничения в процессе тестирования и предложить способ их устранить. Тут всё зависит сугубо от вашего сервиса и от ваших сценариев тестирования.

5. Загляните в дежурство

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

Можно посмотреть, какие куски системы чаще всего ломаются. Таким образом можно найти те самые «неблагополучные районы». 

И самое главное, задайте себе вопрос: «А что можно было бы делать без участия разработчика?». Ведь дежурство отвлекает разработчика от выплаты техдолга!

6. Почувствуйте на себе

Последний, но важный шаг — это сделать несколько задач самому. Я предлагаю делать это в последнюю очередь, чтобы на предыдущих шагах иметь менее предвзятый взгляд на происходящее. 

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

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

Накопали кучу проблем. Что дальше?

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

1. Поставьте себе технические цели

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

Чтобы приоритезировать получившиеся цели их бывает полезно кластеризовать. Так вы найдете сонаправленные цели, а также поймете, как та или иная цель связана с конечным результатом, что позволит осознанно расставить приоритеты.

2. Сформируйте бэклог

Тут без откровений, просто используем базовые принципы работы с большими задачами:

• для каждой цели составляем дорожную карту, состоящую из логических этапов

• каждый этап декомпозируем в конкретные (лучше атомарные) задачи

• оцениваем получившиеся задачи и этапы 

3. Поговорите с менеджером разработки

Теперь, когда у вас есть цель и план по её достижению, самое время поговорить с руководителем. Расскажите о проблемах и предлагаемых решениях, расскажите сколько это будет стоить. Имеется ввиду оценка задач, которую давали на предыдущих этапах; речь не про деньги, конечно. 

Менеджер со своей стороны провалидирует, правда ли предложенные цели решают заявленные проблемы, и насколько вообще целесообразно с указанными проблемами разбираться. Надеюсь, вы не из тех инженеров, которые выдумывают проблемы просто ради того, чтобы втащить новую интересную технологию в продукт. Но всё же трезвая оценка и взгляд со стороны ещё никому не повредили. 

После того как вы превратили менеджера в своего единомышленника, вы можете договориться с ним о дальнейших шагах, в которых теоретически он должен смыслить больше вас:

• как презентовать цели бизнес-заказчикам

• как вписаться со своими задачами в общий поток

4. Презентуйте цели команде

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

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

5. Найдите драйверов цели

Если ваш проект достаточно большой, вы быстро убедитесь, что отвечать за все технические цели одному неэффективно, а порой и невозможно. Происходит расфокус, динамика продвижения быстро снижается до околонулевой.

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

6. Контролируйте прогресс

Отслеживайте продвижение по целям: проводите контрольные точки, общайтесь с драйверами целей. Не организуете процесс — почти гарантированно не выполните цели, и больше вам никто ресурс на выплату техдолга не выделит.

Помимо первичной цели в моей команде контрольные точки несут дополнительные функции:

• демонстрируем команде динамику работы

• убеждаемся, что идем в правильном направлении

• презентуем новые технические цели

• корректируем планы

7. Сохраняйте прозрачность

Помимо контрольных точек важно рассказывать о ключевых изменениях всем заинтересованным. Тут всё зависит от того, как у вас устроены каналы коммуникации. У нас важные новости про технические изменения и нововведения постят в чаты, а также в отдельный новостной канал.

Что может пойти не так

Путь выплаты техдолга может быть довольно тернист, и проблемы могут поджидать повсюду. Я просто перечислю, что встречалось в моей практике, а искать решение этих проблем — домашнее задание для читателя:

• Квоту на техдолг выделили, но она не соблюдается

• «Драйвер» бросил задачу

• Делаем задачи слишком медленно

• Мы пошли не туда (приняли неверные технические решения и т.п.)

• Разработчики не зажглись идеей

• Нет согласия по решению

Надеюсь, вы с такими проблемами не встретитесь, а если встретитесь, то обязательно найдете для них решение или обходной путь.

Успешной выплаты техдолга!