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

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

Я приветствую технический долг в своей работе. Очевидно, что в общем случае не очень хорошо, когда вы кому-то должны. Но иногда долг может быть наименьшим из доступных зол. Доказать это очень просто – если бы технический долг был настолько страшен, то его никогда бы не было у крупных компаний (примечание переводчика: так себе аргументация, если честно).

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

Что такое технический долг?

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

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

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

Когда брать технический долг

Понимание того, когда необходимо сделать релиз за счет технического долга – это и искусство, и наука.

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

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

Для вычисления «процентной ставки» технического долга я предлагаю следующие приемы:

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

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

— Цена последующего устранения «костылей»? Очень часто исправление «заплаток» может требовать сложного апгрейда между версиями, потери обратной совместимости или вкладывания значительных сил в рефакторинг кода. Это означает, что в таких случаях «процентная ставка» будет очень высока.

— Влияние на клиентов? Какое влияние окажут использованные «костыли» и «заплатки» на ваших пользователей? Если они приведут к появлению багов раз в месяц – насколько это будут неприятные баги и что будут делать ваши пользователи в случае их появления?

Не бойтесь технического долга

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

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

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

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

Правильным решением будет постепенная выплата долга. До тех пор, пока прибыль растет быстрее, чем выплаты по долгу, он не является чем-то плохим. Он является инвестированием.

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

Ничто не совершенно – особенно в разработке программ. Я прекрасно понимаю, что разработчики гордятся своей работой и хотят видеть безглючный софт, но стараюсь смотреть на картину целиком и учитывать нужды не только разработки, но и компании (примечание переводчика: в большинстве случаев программисты хотят домой и пива, но, возможно, в кремниевой долине немного не так).

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

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