Стена технического долга: наглядная альтернатива багтрекеру

Автор Алексей Морозов

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

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

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

Так что проблема не в техническом долге как таковом; проблема в неуправляемом техническом долге. Финансовый директор любой компании точно знает, сколько денег компания должна и кому; у него для этого есть таблицы, квартальные отчёты, план платежей. Более того, у него должен быть план, как в случае чего рефинансировать кредит. Но если спросить CTO, насколько большой у него технический долг, он скорее всего ответит: «Ну… не скажу точно, вряд ли мало».

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

Стену выбрали, что дальше?

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

Сделайте стену заметной

Используйте стену в том же помещении, в котором команда работает. Убедитесь, что её всем видно. Напишите сверху большими буквами «СТЕНА ТЕХДОЛГА» и нарисуйте пафосное лого. Убедитесь, что неподалёку есть стикеры и маркеры. Выглядеть должно примерно вот так:

Создайте привычку

Каждый раз, когда вы программируете:

1. Обращайте внимание, над чем приходится долго думать? Что делает код нечитаемым или усложняет поиск багов? Что стоило бы получше задокументировать и/или протестировать? Любой обнаруженный техдолг отправляется на стену. Полный отчёт на стикер не влезет, но главное, чтобы написанное потом можно было понять.
2. Сколько времени ушло впустую из-за этой проблемы? Договоритесь об обозначениях (например по одной метке на каждые полдня). Интуитивность здесь важнее точности.
3. Сколько времени уйдёт на то, чтобы это пофиксить? Отметьте на том же стикере.
4. Если есть идеи, опишите возможное решение. Или занесите его в трекер и напишите на стикере issue ID.
5. Приклейте стикер на стену.
6. Если там уже есть стикер с этой проблемой — вместо этого добавьте на него своё потраченное время.

И не забывайте добавлять стикеры, когда сами создаёте техдолг. Стыдиться тут нечего: технический долг — это не преступление, а просто кредит. Если, конечно, не пытаться набрать кредитов и исчезнуть — вот это как раз было бы преступлением.

Обсуждайте проблемы

С ростом стены люди могут начать нервничать, и это нормально. Долг существовал и до этого; теперь он просто становится заметнее.

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

Если кто-то добавляет новый стикер — может быть, проблему можно решить прямо сейчас? Если нет, то пусть висит. Есть подозрение, что проблема больше никогда не всплывёт? Тоже пусть висит, а там будет видно. Главное, что проблема теперь известна и по ней собирается статистика.

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

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

Передайте управление менеджерам

А вот тут происходит магия. Поскольку стена техдолга бросается в глаза, менеджмент начинает её замечать. Если вдруг не начинает — нарисуйте пару значков € или $ жирным красным маркером. Деньги они точно заметят, а уж упущенные деньги тем более.

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

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

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

Советы и подводные камни

• Не начинайте с полного аудита всего имеющегося технического долга. На это уйдёт как минимум несколько дней, но проблема не в этом. Аудит всего кода — это масштабный проект, а масштабные проекты без прямой выгоды обычно делаются «уже после майских» или «когда зарелизим X и Y», или как там в вашей компании принято говорить «никогда». Стикер, прилепленный сегодня, сегодня же и начинает приносить пользу. А там, глядишь, и до аудита дело дойдёт.
• Без отметок о потраченном времени все разговоры о техдолге превращаются в обмен личными мнениями. Проблемы добавляются только тогда, когда кто-то на них действительно наткнулся и потратил время впустую. Стена — это количественный индикатор техдолга, а не коллекция сомнительного кода.
• Если код вам не нравится, но и не мешает — то это не технический долг, а просто вам не нравится код. Да, он уродливый. Нет, это не проблема. И наоборот: если код прекрасен, но его надо разбирать три часа — это техдолг.
• Это должна быть реальная физическая стена. Может возникнуть соблазн убрать весь долг куда-нибудь в багтрекер, но метрики имеют смысл только когда на них кто-то смотрит. Средний менеджер в багтрекер разве что заглядывает иногда, а стена у него прямо перед глазами.

Заключение

Автор рассказывает, что после его поста 2013 года один стартап решил создать у себя в офисе стену техдолга. Вот только это был очень маленький стартап в очень маленьком офисе, поэтому все стены уже были заняты бизнес-планами и мокапами приложения. Поэтому они решили клеить стикеры прямо на окно. Логика примерно такая: когда в офисе становится слишком темно — пора рефакторить. Шутки шутками, но они действительно разрывались между перфекционизмом и желанием зарелизиться как можно быстрее. Учёт технического долга помог им достичь равновесия, и вскоре они запустились. С тех пор множество компаний, которые успешно использовали стены техдолга. Может быть, и вам пригодится.