Почему технический долг — это хорошо

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

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

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

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

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


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

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

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



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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Comments 21

    +5
    Вот вроде неплохо, но эти ваши примечания переводчика, да еще и красным выделенные, чтобы не дай Б-же не пропустил ни одну умную мысль (особенно про программистов, которые хотят домой и пива), бесят неимоверно.
      0
      Если бесят — значит уберу. Статьи переводят чтобы их читали, так что если что-то не нравится — смело пишите, обсудим. Коллеги уже с красным цветом заголовков нарвались, судя по всему красный цвет мало кому нравится :)
        +1
        А вам нравится читать чужой текст с красными кусками?
          +3
          Можете примечания курсивом выделить — так будет нагляднее и не будет красного текста.
        +3
        Интересная аналогия с финансовыми долгами. Но в финансовой сфере есть критерии, когда бизнес устойчив, а когда он в "красной зоне" — они привязаны к процентной доле заемных средств от оборотных. Возникает вопрос: а в случае технического долга, какой максимальный процент от объема функциональности можно себе позволить?

        Это вопрос к читателям и комментаторам. Вы как-либо оцениваете объем технического долга? Есть ли какой-то "потолок" по техническому долгу в вашей команде?
          +7
          Технический долг — как спящий в организме рак. Если он достигает критической массы, может прорасти в соседние области — тогда архитектура будет задета и покривеет, а следом за ней пойдут нестабильные, плохоуловимые и очень неприятные баги. Поэтому его объем лучше держать под контролем.
            +9
            Технический долг выгоден — может быть все развалится и тогда его можно будет не отдавать.
              0
              Мне кажется, банкротство ООО (или западного LLC) работает похожим образом. Если все провалилось — это проблемы банка, а не директора или основателя компании.
              +10
              Дико извиняюсь, но мало что в этом мире раздражает меня так же, как графики без подписанных осей.
              Или это просто картинка для привлечения внимания?

              image
                0
                Да, это она. Взята из оригинальной статьи.
                  +3
                  https://xkcd.com/833/
                +7
                Есть такой бизнес — взять кредит, обналичить и не отдавать:
                1) увеличивать технический долг любыми путями, обещаниями и тд
                2) перестать отдавать
                3) совсем отказаться выделять время (несколько раз)
                4) подождать пока от дефолта по техническому долгу разбегутся все, кто о нём знает
                5) набрать новую команду
                6) goto 1
                  +7
                  Пожалуй, переформулирую в двух предложениях:
                  C долгом нет особой проблемы, пока он нормально обслуживается.
                  Долг страшен не долгом, а дефолтом.
                • UFO just landed and posted this here
                    0
                    Почему? Потому что это плохо?)
                      +10
                      Потому что его отсутствие — это хорошо.
                    +7
                    Хех. Аналогия, действительно, забавная.
                    Можно закредититься так, что дальнейшая работа потеряет смысл из-за возвратов процентов, то есть цена поддержки будет зашкаливать.
                    Но можно брать кредиты в разумной мере, чтобы поддержать cash flow.
                    А можно набрать кредитов и объявить себя совсем банкротом, угробив контракт. В абсолюте — просто взять деньги и не построить ничего вообще.
                    Что касается материализации технического кредита, надо думать.
                    Например, процент по кредиту выставить пропорциональным масштабированию проекта — чем перспективнее развивается проект, тем выше растёт стоимость однажды взятого долга.
                    В таком случае кредит стоит держать в сумме, не большей, чем требуется для выживания проекта, то есть в размере потенциально реального кассового разрыва, а уничтожать костыли с яростью, пропорциональной мании величия.
                      +1
                      Love is...Технический долг это:

                      — Технически, вы должны мне эту фичу еще вчера. А ваши баги это не наше дело.
                        +4
                        Однажды мы писали проект, в котором заказчик — бывший программист. Там не было технического долга. Мы писали его красиво и элегантно. Писали 3 года, а потом у заказчика кончились деньги и проект умер, так и не родившись. Не говоря уж о том, что пока мы его писали, появилась куча конкурентов и даже если бы мы выпустились, то еще не факт, что выдержали бы конкурентную борьбу.

                        Теперь мы пилим проект, где заказчик чистый менеджер. Через полгода зарелизились, через 3 месяца вышли на безубыточность. Проект — костыли-велосипеды, переписан полностью дважды. Рефакторим и сейчас. НО! Проект приносит прибыль владельцу и обеспечивает кучу его сайд-проектов.

                        И что лучше???

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

                        Теперь я точно знаю, что если у меня есть выбор: зарелизиться завтра с костылями или через месяц с паттернами, юнит-тестами, блекджеком и шлюхами, то я выберу первое, потому что мой проект будет жить и приносить доход. А на этот доход я найму еще программистов, которые покроют его тестами и сделают красивый код. Но потом… Если захочу...
                          +1
                          Вася и Петя одновременно начали писать один и тот же продукт.
                          Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
                          А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
                          Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
                          Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
                          У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
                          В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
                          bash.im/quote/420672
                          +2
                          Вместо тысячи слов

                          https://habrastorage.org/files/675/b55/ada/675b55adacd34bd4b7ebd45edba25c78.jpeg

                          Only users with full accounts can post comments. Log in, please.