Исключая тех, кому повезло быть богатыми, большинство людей занимают деньги, когда начинают свой первый бизнес. И они надеются, что эти инвестиции себя оправдают. Это пример того, как долг может быть хорошей штукой.
То же самое относится к техническому долгу. Бесчисленное множество статей в интернете рассказывают, как от него избавиться или хотя бы уменьшить. Все эти статьи показывают технический долг каким-то монстром, которого надо избегать. А если не получилось – то бороться изо всех сил.
Я приветствую технический долг в своей работе. Очевидно, что в общем случае не очень хорошо, когда вы кому-то должны. Но иногда долг может быть наименьшим из доступных зол. Доказать это очень просто – если бы технический долг был настолько страшен, то его никогда бы не было у крупных компаний (примечание переводчика: так себе аргументация, если честно).
В этом посте я хочу показать, насколько технический долг похож на обычный кредит, взятый на развитие бизнеса. И что нужно учитывать, принимая решение: брать такой кредит или не брать.
Что такое технический долг?
При разработке программ постоянно приходится балансировать между скоростью разработки и качеством того, что получается. Чтобы релиз случился вовремя, зачастую приходится жертвовать качеством разработки, используя «костыли» и «хаки». Исправление этого обычно переносят на будущие релизы – что, собственно, и называют «техническим долгом».
Технический долг возникает по многим причинам. Заказчики разработки могут больше фокусироваться на сроках и функциональности, нежели на исправлении старых проблем и создании надежного фундамента для дальнейшей разработки. В вырожденных случаях заказчики вообще игнорируют эти вещи, требуя от команды только «фичей в срок».
В конечном итоге, технический долг приводит к проблемам у пользователей, которые постепенно прекращают пользоваться продуктом. А игнорирование технического долга как разработчиками, так и менеджерами только способствует его накоплению.
Когда брать технический долг
Понимание того, когда необходимо сделать релиз за счет технического долга – это и искусство, и наука.
При взятии кредита одна из самых важных вещей – это процентная ставка. Очевидно, что брать кредит у акулы-ростовщика с высоким процентом является не самой лучшей идеей.
То же самое относится и к техническому долгу. Вам необходимо понять, какой именно «процент» вы будете по нему платить, основываясь на изложенных ниже правилах и здравом смысле. В большинстве случаев технический долг — это очень неплохая штука, – до тех пор, пока выплачиваемые каждый месяц проценты находятся в рамках разумного.
Для вычисления «процентной ставки» технического долга я предлагаю следующие приемы:
— Является ли код частью основной функциональности вашего продукта? Если да, то технический долг может иметь очень высокую цену. К примеру, наша команда Logz.io без проблем берет технический долг при разработки внутренних консолей управления или изотерической функциональности для единичных клиентов. Но мы прикладываем все усилия, чтобы не иметь технического долга в нашей основной функциональности: обработке логов и аналитике.
— Сложности в будущем? Как технический долг отразится на последующую разработку? Какое влияние он окажет на смежную функциональность и задачи? Если разрабатываемые функции являются периферийными и не планируются к активному использованию в ближайшие месяцы, то технический долг может принести пользу и освободить время разработчиков для работы надо основным продуктом.
— Цена последующего устранения «костылей»? Очень часто исправление «заплаток» может требовать сложного апгрейда между версиями, потери обратной совместимости или вкладывания значительных сил в рефакторинг кода. Это означает, что в таких случаях «процентная ставка» будет очень высока.
— Влияние на клиентов? Какое влияние окажут использованные «костыли» и «заплатки» на ваших пользователей? Если они приведут к появлению багов раз в месяц – насколько это будут неприятные баги и что будут делать ваши пользователи в случае их появления?
Не бойтесь технического долга
Технический долг – это то, с чем нам приходится сталкиваться время от времени. И все сводится к вопросу, который экономисты формулируют как «цена возможности», то есть для того, чтобы сделать «X» нужно вначале сделать «Y».
Если ваша команда потратит день на исправление «заплаток» и «костылей», то этот день не будет потрачен на разработку новой функциональности. Точено так же, день работы над новыми фичами не будет потрачен на исправление старых багов.
Посмотрите на картину разработки с высоты руководства компании. Каждый доллар, который потрачен на разработку, уже не потратить на маркетинг, административные расходы и другие нужные для бизнеса вещи. То же самое работает в обратную сторону. Решения принимаются на основе приоритетов, и технический долг в большинстве случаев имеет низкий приоритет.
Приведу аналогию из мира финансов. Предположим, у компании есть обычный, не технический долг в миллион рублей. И выручка в размере полутора миллионов в месяц. Нужно ли компании сразу же выплатить весь долг? Конечно нет. Ведь оставшейся половины миллиона не хватит на выплату зарплат, аренды и других нужных вещей.
Правильным решением будет постепенная выплата долга. До тех пор, пока прибыль растет быстрее, чем выплаты по долгу, он не является чем-то плохим. Он является инвестированием.
Я приветствую технический долг, потому что он показывает, что мы растем как компания: релизим новые фичи и продукты, которые помогают нашим клиентам работать с логами. Если команда разработки тратит слишком много времени на исправление незначительных «костылей», то это приносит не пользу, а риск стагнации.
Ничто не совершенно – особенно в разработке программ. Я прекрасно понимаю, что разработчики гордятся своей работой и хотят видеть безглючный софт, но стараюсь смотреть на картину целиком и учитывать нужды не только разработки, но и компании (примечание переводчика: в большинстве случаев программисты хотят домой и пива, но, возможно, в кремниевой долине немного не так).
Приходит время, когда мы уменьшаем технический долг. Но это не настолько важно, как об этом думают большинство программистов. В будущем я продолжу это обсуждение и расскажу о лучших приемах для уменьшения технического долго – но не раньше, чем это будет необходимо.
Примечание переводчика: также рекомендую прочитать одну из статей нашего технического евангелиста, посвященную техническому долгу. У него все описано в чуть более мрачных тонах, видимо, не везло человеку на стартапы с хорошим
финансированием.
Автор: Voximplant
