Expert JS React Developers for TUI wanted. Join Ciklum and get a $4000 sign-on bonus!
×Закрыть

Технический долг: как развязать гордиев узел

Меня зовут Иван Шевеленко, я Team Lead в Luxoft. В IT уже 20 лет, а в отношениях с вычислительной техникой я еще со школы. Поэтому решил поделиться с вами видением темы приоритизации технического долга.

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

Иллюстрация Алины Самолюк

Краткое описание

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

Один из эпичных примеров технического долга на продакшене — инцидент с контроллером дроссельной заслонки Toyota Camry: 80 тысяч нарушений отраслевого стандарта, 11 тысяч глобальных переменных. Цена вопроса — человеческая жизнь, миллиарды долларов судебных расходов. Детальнее можно почитать здесь.

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

Категоричность

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

Безопасность — это «фильтр», который позволяет приложению или системе реагировать заданным образом на взаимодействие из внешнего мира.

Производительность — это выполнение юзкейса за минимально возможные расходы вычислительной мощности.

Интеграционные категории — каким именно образом построено взаимодействие компонентов приложения.

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

Технический долг и точка зрения

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

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

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

Технический аспект вопроса

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

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

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

Например, в одном продукте определение версии строилось по формуле A × 100 + B × 10 + C. Как видно, B и C не могло превышать 9, чтобы не повлиять на другой разряд. И был риск, что однажды это произойдет и будет горе. Но по факту эта проблема ни разу не проявилась, хотя волновала.

Менеджерский аспект вопроса

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

Нужно понимать, что нездоровая атмосфера внутри команды влияет на всех разработчиков, а значит является мультипликатором для возникновения проблем. Из-за неумения или нежелания договариваться в системе могут появиться некачественные решения или даже «закладки» (неофициальный backdoor). Следовательно, менеджер должен уметь определять уровень комфорта, при этом держать нос по ветру, чтобы своевременно смягчить или решить возникшие проблемы.

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

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

Как решать проблему долга

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

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

Чтобы правильно регистрировать этот долг, лучше разбить его на источники возникновения, например:

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

В то же время это должен быть не формальный процесс, а рабочий инструмент команды. Обслуживание и администрирование долга выглядит как рутина, но что-то можно автоматизировать. К примеру, проверка версий может быть автоматизирована скриптами мониторинга, а на чтение Release Notes/Change log/CVE (Common Vulnerabilities and Exposures) надо выделять отдельное время специалиста. Этого инженера выбирает команда, и менеджмент должен быть согласен с расходами на подобную работу.

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

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

А что верхи?

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

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

Риски

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

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

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

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

Резюме

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

  • Сделайте удобным инструмент для отслеживания использующихся версий и версий сторонних продуктов, которые есть в вашем решении.
  • Отслеживайте инциденты безопасности по вашему продукту и по продуктам, которые используете. Старайтесь заказывать независимый аудит безопасности.
  • Разделите четко зоны ответственности: кто отвечает за администрирование проблемы и за ее решение. Четкая граница позволит избежать лишней работы.
  • Обсудите работу с техдолгом, проанализируйте затраты ресурсов на это.
  • Договоритесь о формате долговой книги, как она выглядит для инженеров, как для менеджеров, а как для заказчиков и спонсоров.
  • Менеджер должен уметь аргументированно вести диалог по техдолгу как с исполнителями, так и заказчиком.
  • Обсуждайте регулярно долги, оценивайте риски и их серьезность. Помните: лучше профосмотр, чем операция.
👍НравитсяПонравилось4
В избранноеВ избранном1
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: Soundcloud | Google Podcast | YouTube


19 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Ниочем. Почему примеры тех.долга взяты не из опыта? В вашей компании нет такого?
Определение и причины тех.долга — если кратко и грубо, то в корне неверные. Ощущение, что автору поручили накатать статью на доу на заданную тему и он как мог справлялся с задачей.
Хотя о чем говорить если брак производства (рассмотренный пример тойоты) автор приводит как пример технического долга.

Разве не люди виноваты в том, что возникают проблемы? Или вы отрицаете, что виновник — человек? Уверен у вас есть своя точка зрения, не могли бы вы ей поделиться в двух словах? Мне честно интересно узнать, если ваш ответ не изменит мою точку зрения, то расширять кругозор всегда полезно.

Люди конечно виноваты. Подробности популярно изложены в монологе агента Смита в 1ой матрице.

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

Если интересно, то вот мои мысли — nikolaj-sarry.info/...​icheskij-dolg-na-proekte

отлично изложено, спасибо, буду цитировать! :)

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

Если кратко и грубо, это результат работы некомпетентных людей.

Ніт. Бувають ситуації, коли ми свідомо йдемо на ті чи інші рішення, які стають технічним боргом. Хіба це говорить щось про те, що люди некомпетентні? Це радше говорить про те, що була ситуація в котрій з певних причин потрібно було прийняти таке рішення. Не більше.

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

Дякую за статтю, але не зовсім згоден з визначенням, що технічний борг — це завжди результат роботи некомпетентних фахівців (розробників або менеджерів).
Не забувайте, що в розробці продукту є три складові — Якість, Ціна і Час виконання. Тому ідеальної якості ніколи не може бути. Їм досить часто жертвують на догоду ціни або часу.
Ще один нюанс — так як ми працюємо по Agile методології, то вимоги можуть часто змінюватися, а це при фіксованій ціні/часу знову ж впливає на якість.
Звичайно, я з вами згоден, що іноді технічний борг виникає й через недостатній досвід/кваліфікацію розробників. Але це все-таки одна з причин, і на мою думку, не ключова.

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

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

Знову ж — чия некомпетентність?
З яких це пір розробники самі вибирають, що робити? Будь-який sprint/backlog надходить в роботу тільки після схвалення представників замовника.
Якщо замовник скаже — у нас немає на це грошей/часу, а розробник все одно буде чогось там фіксити, ось це і є некомпетентність та непрофесіоналізм.

Что такое технический долг? Если кратко и грубо, это результат работы некомпетентных людей.

очень уж кратко и грубо, что названа не главная причина появления технического долга.

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

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

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

слово элегантное может много чего значить.

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

элегантное и минимальное — это из идеального мира, как по мне.

Начиная от низкого качества описанных задач и заканчивая прессингом и стрессом перед каждым релизом

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

В быстро меняющемся мире невозможно создать совершенный продукт.

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

Как решать проблему долга

так как-то и решают.

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

Главный и существенный риск — скатиться в легаси и растерять экспертизу по продукту.

любой продукт после первой выкатки в прод — становится легаси. потому что он — он находится в эксплуатации. убрать этот риск — это просто никогда не выкатывать продукт в прод.

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

именно потому что массово отсутствует второе — уход ведущих разработчиков с проекта — тот еще удар по яйцам проекту.

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

и ни доки, ни комментариев в коде после них. потому что «Хороший код не требует комментариев!»

Рецепта, как сделать хорошо, нет. Но можно создать резюме,

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

Прочитав. Нічого не зрозумів.

Что такое технический долг? Если кратко и грубо, это результат работы некомпетентных людей.

Занадто вже коротко та грубо. Може бути 100500 причин виникнення технічного боргу і часто це не некомпетентність людей, а зовнішні обставини. 10 років назад компілятор не підтримував фічу Х, і довелося писати ось так. Сказали зробити швидке рішення, бо треба «прямо зараз», воно протрималось рік, а далі не змасштабувалося. Зовнішній компонент/бібліотека став deprecated. З’явилося краще рішення, але його не відразу помітили. Тощо.

Окрім того, з визначення «результат роботи некомпетентних людей» випливає, що з поточною командою технічний борг не побореш (вони ж некомпетентні!), а якщо найняти нових, компетентних, то боргу не стане (спойлер: стане).

Найкращий підхід до боротьби з технічним боргом — це як до чистки зубів чи ранкової зарядки. Просто треба робити. Сьогодні. Завтра. Вчора. Хочеться, не хочеться, є час, нема часу. Треба і все. Потроху, але регулярно. «Лупайте сю скалу! Нехай ні жар, ні холод. Не спинить вас!...» і далі по тексту.

А разве у меня не так написано в конце, что надо решать эти проблемы систематически, и оценивать риски? Очевидно, что технический долг может возникнуть только потому, что время прошло, мир поменялся.А поменялись ли люди? Развивались ли они паралельно? Можно ли оставаться компетентным специалистом без развития самого себя, и не вкладывать потом эти знания в продукт, с которым работаешь? А если другой специалист в команде видит технические проблемы, но не может донести их выше — является ли он компетентным?

Скільки відкритих питань!

А поменялись ли люди?

Звичайно. Правда, може бути, що в гіршу сторону :)

Можно ли оставаться компетентным специалистом без развития самого себя

Не можна, по визначенню терміну «компетентність».

и не вкладывать потом эти знания в продукт, с которым работаешь

Легко. Брак мотивації, часу, лінь, інші проєкти тощо.

А если другой специалист в команде видит технические проблемы, но не может донести их выше — является ли он компетентным?

Донесення проблем «нагору» — не проблема. Про технічний борг всі знають. Його видно, ну бо ось він. Проблема у виділенні часу на роботу з ним — я ось про це писав. Звичайна схема «замовник не дає часу на технічний борг, бо треба пиляти нові фічі. PM не дає часу на технічний борг, бо треба задовольнити замовника. Програміст не займається боргом, бо робить тільки те, що сказав PM». А повинно бути «Програміст виділяє певний час на борг, бо і сам розуміє його важливість і PM виділив час. І так далі аж до замовника»

Все гладко на бумаге, да забыли про овраги...
Тут много параметров, которые надо свести вместе. Воля платить за это, воля решать это инженерам и со стороны менеджмента отвечать за эту оркестровку. Но... в реалиях нашего IT в большинстве случаев это не работает. Просто потому, чтобы быстрее закрыть таск. А потом в один прекрасный момент это превращается в эффект «разбитых окон». И уже никто не знает, как выходить из этой ситуации. The end of story...

Цей момент в житті програмного продукту, насправді є найцікавішим. Коли проект настільки заліз в технічний борг, що подальший розвиток його є майже неможливим, тобто занадто дорогим та непередбачуваним з точки зору часу розробки нових фіч та/або фіксу старих/створення нових багов. Саме в цей момент хтось має прийняти рішення, чи є сенс намагатися суттєво зменьшити наявний технічний борг в існуючому продукті, чи варто його кинути комусь на підтримку, та розпочати розвивати новий продукт з нуля. Інколи буває так, що якщо правильно діагнозувати одну-дві-три головні проблеми продукту та знайти прийнятні способи їх вирішення, продукт можна розвивати далі. Треба тільки поміняти ставлення до технічного боргу. Дійсно змінити, а не просто декларувати зміну. Насправді, це завжди питання компетенції та взаємної довіри розробників, менеджерів та стейкходлерів. Інколи звісно ефект розбитих вікон може привести до втрати бізнесу, але так відбувається не завжди. Майже ніколи не пізно почати зменьшувати технічний борг, звісно це коштує грошей та вимагає певних компетенцій, але інколи виявляється набагато дешевшою опцією за розробку нового продукта з нуля. :)

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

Я саме таку роботу зараз роблю. Прикріпляю ручку до валізи. Тобто, знищую потроху технічний борг, який залишився від кількох попередніх команд в процесі розробких нових фіч. На милицях там вже нічого не можна було встромити. У грудні поза того року, коли я взяв цей проект, там більшість пошукових запитів не відпрацьовували за 30 секунд та крешилися по таймауту. :) Це не рахуючи того, що ніхто не розумів, як працює розсилка імейлів та багатьох інших веселих пригод, включаючи «кастомізований» DI и виконання кожного запита на БД в окремому контексті. Врешті решт вдалося потроху все це диво привести більш-меньш до ладу, незважаючи на те, що клієнт взагалі не розуміє, що таке технічний борг, та перші десь пів року намагався прискорити розробку вимагаючи найняти більше людей. Майже в кожну фічу (навіть найменьшу) доводилося пхати цілу купу рефакторинга в естімейт. По-іншому ніяк не виходило. Зара вже трохи полегше.

Подписаться на комментарии