Правило 18. Рефакторинг нуждается в пиаре

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

И этот план уже на критическом пути, так как доработки уже упёрлись в потолок — предновогодний сезон, на время которого все доработки останавливаются, а «бизнес-критичные» задачи продолжают поступать. И, конечно, когда встаёт вопрос, чем пожертвовать — очередной «бизнес-критичной» задачей, которую делают уже второй год, или отложить непонятную задачу со сложным названием (то ли рефакторинг, то ли рефакторинг) на следующий год, — выбор, как правило, не в пользу рефакторинга.

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

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

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

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

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

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

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

Ситуация резко меняется, когда тихую и рутинную жизнь нарушает какой-то кризис.

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

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

Для среднестатистического менеджера это звучит как известная арабская притча о том, как Ходжа Насреддин обещал научить осла читать.

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

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

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

Тема рефакторинга должна постоянно мозолить глаза, она должна пугать страшными перспективами: что всё сломается, остановится, замедлится и так далее. Каждый раз, отодвигая рефакторинг, именно бизнес должен принимать риски, а не ИТ. Получайте письменные подтверждения принятия рисков, желательно через корпоративную почту или трекер задач, если такой используется вместе с бизнесом.

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

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

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

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

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