Как заставить руководство проникнуться техническим долгом

Автор оригинала: Nicolas Carlo
  • Перевод

«Руководство не даёт мне заняться рефакторингом legacy-кода!» Знакомая ситуация? Раздражает жутко. Большинство разработчиков рано или поздно сталкивается лбами с менеджером, который совершенно не заинтересован в том, чтобы совершенствовать уже готовое. То нужно реализовать что-то новое, то срочно потушить пожар, то исправить какой-то баг… В общем, причина отложить рефакторинг запущенной кодовой базы у них всегда найдётся.

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

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

Менеджеры – не программисты


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

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

Пять аргументов, которые вы можете привести


1) «Рефакторинг поможет снизить волатильность предельных издержек на единицу функциональности ПО»

Это точная цитата из замечательного выступления Дж. Б. Рейнсберга на конференции на тему «Экономика в разработке ПО». Стойте, не уходите! Всё, что здесь сказано, вам прекрасно известно, просто оно сформулировано в абстрактно-заумном духе.

Пойдём по порядку:

  • «Рефакторинг поможет снизить…» — пока что всё нормально
  • «…волатильность…» — иными словами, непредсказуемость
  • «…предельных издержек…» — то есть сколько ресурса потребует производство ещё одной дополнительной единицы
  • «…на единицу функциональности ПО» — она же фича, имеющая ценность для бизнеса. Ура! Ценность для бизнеса – это как раз то, что нам нужно.

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

2) «За последние месяц 63% ресурса разработки ушло на исправление проблем с качеством продукта»

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

Вот несколько метрик, на которые вы можете обратить внимание:

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

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

Как-то я присутствовал на post-mortem бага, которого можно было бы избежать, если бы была проведена проверка типов данных. Код писался на JavaScript. Как раз в то время в компании велись споры о том, стоит ли переходить на TypeScript.

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

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

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

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

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

4) «Если инвестировать 10% рабочего времени в качество кода, текучесть кадров существенно снизится».

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

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

А теперь давайте зададимся вопросом: во что компании обходится замена уволившегося разработчика? Нового специалиста нужно найти, провести через процесс найма, ввести в курс дела. Это требует вложений, занимает время и затормаживает всю команду. Руководство однозначно предпочло бы не заниматься подобными перестановками каждый год. Поэтому снижение текучести может стать серьёзным аргументом. А сам факт наличия плана по устранению технического долга сразу даст всей команде +100 к мотивации.

5) «Если вложить 20% ресурса в рефакторинг, FRT сократится вдвое и для производительности разработчиков ROI будет положительным»

FRT – это время отклика, важная метрика для пользовательской поддержки. Бизнес стремится к тому, чтобы клиенты были всем довольны.

Здесь мы проделываем следующее:

  • Выбираем метрики, которые имеют большой вес в техподдержке;
  • Находим пару проблем, которые возникают регулярно и требуют вмешательства разработчиков;
  • Предлагаем план по сокращению числа обращений в техподдержку за счёт устранения исходной причины.
  • Если проблемы такого рода разрешатся, разработчиков реже будут привлекать к задачам, связанным с поддержкой пользователей. То есть у них освободится больше времени, чем было затрачено на рефакторинг, а значит, вложение окупится – тот самый положительный ROI.

В конечном счёте, решать им


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

Проводите рефакторинг по ходу дела

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

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

Исправляете баг? Потратьте лишний час на написание автоматического теста. Готовитесь выкатывать новую фичу? Потратьте лишний день, чтобы подчистить код. День изо дня старайтесь, чтобы изменения происходили безболезненно. Через несколько месяцев вы заметите, что эта привычка оказала огромное влияние на вашу производительность. А знаете почему? Потому что рефакторинг помогает снизить волатильность предельных издержек на единицу функциональности ПО.
Productivity Inside
Для старательного нет ничего невозможного

Комментарии 14

    +4

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

      –1
      Вы немного забыли, что тут ситуация несимметричная: разработка в 90% компаний такой же обслуживающий персонал экономики предприятия, как уборщица или, там, токарь. Экономика и менеджмент могут сколько угодно не знать язык программистов и быть деспотами и самодурами, а на мороз без премий пойдет программист, а не наоборот
        0
        Ну это скорее советы насчет того, как правильно пытаться объяснить, что есть техдолг. Будем честны, далеко не все имеют даже минимальное представление о том, как происходит разработка ПО.
        0
        Очень важная статья на самом деле. Программисты для того, чтобы расти, нужно понимать и экономику и менеджмент, чтобы уметь правильно взаимодействовать.
          0
          Я думаю не нужно никого заставлять проникаться техническим долгом, тем более руководство.

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

          А доказывать что-то некомпетентному руководителю это непродуктивно.
            0
            И я тоже не понимаю, зачем заставлять проникаться? Об этом можно разок подсказать. Не слушают — и черт с ними, т.к. это проблемы управления фирмы, есть отдельные ответственные за эту работу люди.
            Для 99% программеров по найму лучшая стратегия — это раз в 2-3 года менять место работы с повышением в з/п. А вот решать какие-то проблемы бизнеса, о которых он не просил — это нарываться на обвинения, что вы вместо работы развлекаетесь. Рискованная стратегия и без видимых выгод.
              0
              Так, ладно, а зачем тогда вообще писать качественный код? Тогда можно писать любой код, за который не уволят, или который на заметят, или не заметят в эти 2-3 года.

              И второй вопрос — какая мотивация работы у программиста?
                0
                Так, ладно, а зачем тогда вообще писать качественный код?

                Это довольно скользкий термин. Думаю, даже в пределах одной фирмы понятие качественного кода будет расходиться.
                С одной стороны есть минимальный уровень, который требует бизнес — он как правило чем-то описан.
                С другой — есть личные предпочтения разработчика — его чувство прекрасного, желание показать себя перед коллегами, в том числе и будущими.
                С максимальной стороны качественный код тоже обычно ограничен бизнесом, т.к. он не очень то хочет тратить на него деньги. А «качественный код» — это обычно «потратим больше времени сейчас, чтобы меньше тратить потом».
                — Очень круто, когда все эти 3 находятся в одной точке. Я думаю, что чаще всего «писать качественный код» — это о личных предпочтениях разработчика. Отсюда и такие проблемы при объяснении бизнесу.
                  0
                  Тогда можно писать любой код, за который не уволят, или который на заметят, или не заметят в эти 2-3 года.

                  да, можно. «за который не уволят» — так это и нужно бизнесу обычно — минимально рабочий вариант в пределах оговоренного и при этом за минимальные затраты. «или который не заметят» — это больше к воровству и вопросу морали.
                0
                Ну смотрите, у меня все работает а я хочу кнопку. Вместо этого вы предлагаете мне потратить деньги непонятно на что. Попробуйте доказать мне, что я ошибаюсь но не используйте никаких технических терминов.
                  +1
                  15 лет оутсорса — борьба с техдолгом только «за свой счет». Где-то в свободное от работы время, где-то сознательно превышал оценки на разработку, чтоб в оставшееся время порефакторить, где-то пытался новичков к этому делу приспособить, покуда от них менеджмент пользы не ждет.
                  Официально — никаким языком не воспринимают.
                    0
                    Статья не «открывает Америку», но структурирует и детализирует на самом деле актуальную тему, поэтому "+"
                      0

                      Пффф… А можно построить digital factory и колбасить без тех.долга. Слабо?
                      Но! Стоит разделять тех.долг и рефакторинг архитектурных\технических решений в случае изменения требований.

                        +2
                        «Руководство не даёт мне заняться рефакторингом legacy-кода!»

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

                        И даже когда пытаешься им объяснять, какие преимущества даёт опрятный код

                        И получается, что вы абсолютно бессильны что-то сделать с техническим долгом, который всё копится и копится.

                        За рефакторинг никто платить не будет. Положение выглядит безнадёжным.

                        Как на счёт такой стратегии?:
                        Не говорить руководству про технический долг и рефакторинг… чтоб они даже слов таких не знали.

                        Просто каждый раз при оценке абсолютно любой(!) задачи закладывать в озвученные сроки ещё ~200% времени. Т.е. когда просят добавить кнопочку — не бить себя в грудь и говорить что это плёвое дело на пару часов. А с покер-фейсом говорить что эта кнопочка займёт два дня (даже если там работы на пару часов).

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

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

                        P.S. заметил что некоторые разрабы сами склонны занижать сроки, особенно публично… типа та что там делать… делов на пять минут. Толи повыпендриваться, толи страх показаться некомпетентными. Вместо того, чтобы наоборот нармально запаса заложить для подстраховки.

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

                        Самое читаемое