Технический долг: как развязать гордиев узел
Меня зовут Иван Шевеленко, я Team Lead в Luxoft. В IT уже 20 лет, а в отношениях с вычислительной техникой я еще со школы. Поэтому решил поделиться с вами видением темы приоритизации технического долга.
Думаю, статья будет интересна как менеджерам, так и инженерам разного уровня «сеньорности». Возможно, материал пригодится и другим специалистам, по крайней мере я задумывал его полезным для всех.
Иллюстрация Алины Самолюк
Краткое описание
Что такое технический долг? Если кратко и грубо, это результат работы некомпетентных людей. Некомпетентность менеджеров или инженеров, повлекшая за собой нарастание технического долга, может быть осознанной или неосознанной. Долг иногда создает специалист целенаправленно, под чутким руководством менеджера или самостоятельно.
Один из эпичных примеров технического долга на продакшене — инцидент с контроллером дроссельной заслонки Toyota Camry: 80 тысяч нарушений отраслевого стандарта, 11 тысяч глобальных переменных. Цена вопроса — человеческая жизнь, миллиарды долларов судебных расходов. Детальнее можно почитать здесь.
Для покрытия технического долга надо ресурсы — деньги, время и знания.
Категоричность
Для того чтобы контекст был понятнее, наведу сразу ряд категорий для технического долга.
Безопасность — это «фильтр», который позволяет приложению или системе реагировать заданным образом на взаимодействие из внешнего мира.
Производительность — это выполнение юзкейса за минимально возможные расходы вычислительной мощности.
Интеграционные категории — каким именно образом построено взаимодействие компонентов приложения.
Пользовательские категории — так как задача любого приложения улучшить жизнь человека, то оно должно быть удобным в использовании.
Технический долг и точка зрения
Нужно выбрать точку, с которой рассматривать технический долг. Это важный момент, ведь мнения у членов команды могут отличаться. К примеру, разрабатываемое ПО будет работать исключительно в физически изолированной системе. А значит, его надо рассматривать с точки зрения этой системы и ставить потребности системы в области безопасности во главу угла.
Скорее всего, гораздо важнее анализировать вопросы производительности и юзабилити. Наверное, все помнят медленные и неудобные мультимедиасистемы автомобилей
Приложения, работающие с чувствительными данными в глубоких интеграциях и обеспечивающие взаимодействие в разных средах и системах, должны в первую очередь быть защищены.
Технический аспект вопроса
Любую техническую задачу можно решить бесконечным количеством способов. Чем больше у разработчика опыта, тем лучше он думает наперед, тем более элегантное решение у него выходит за минимальное количество времени.
Результат — меньше «квадратно-гнездовых» решений. Мало того, опытный инженер может научить менее опытного, объяснить, как улучшить то или иное решение, указать, где есть потенциальные проблемы.
Каждое «квадратно-гнездовое» решение — это потенциальная опасность в будущем: утечка памяти, неправильное преобразование типов, потеря данных и так далее. Однако стоит учитывать, что потенциальные проблемы не всегда становятся реальными. Они могут пройти через всю жизнь продукта и так ни разу не проявиться.
Например, в одном продукте определение версии строилось по формуле A × 100 + B × 10 + C. Как видно, B и C не могло превышать 9, чтобы не повлиять на другой разряд. И был риск, что однажды это произойдет и будет горе. Но по факту эта проблема ни разу не проявилась, хотя волновала.
Менеджерский аспект вопроса
Процессы, в которых работают люди, влияют на них непосредственно. Начиная от низкого качества описанных задач и заканчивая прессингом и стрессом перед каждым релизом. Если технические специалисты отвечают за продукт, то менеджеры — за комфорт работы инженеров. Низкий уровень компетенции и вовлеченности менеджера в трудности разработки продукта и стремление исключительно понравиться спонсору или инвестору, скорее всего, приведут к проблемам в будущем и потребуют «дорогостоящего лечения».
Нужно понимать, что нездоровая атмосфера внутри команды влияет на всех разработчиков, а значит является мультипликатором для возникновения проблем. Из-за неумения или нежелания договариваться в системе могут появиться некачественные решения или даже «закладки» (неофициальный backdoor). Следовательно, менеджер должен уметь определять уровень комфорта, при этом держать нос по ветру, чтобы своевременно смягчить или решить возникшие проблемы.
Многие из вас, наверное, сталкивались с ситуацией, когда менеджер избегает решать проблемы и в лучшем случае просто устраивает общий митинг, где накал страстей только раззадоривает оппонентов и доводит их до полного истощения. Проблема осталась, но ушла под ковер, потому что все устали. До следующего раза. С точки зрения менеджера, если о проблеме больше не говорят, значит она решена.
Как показывает мой опыт, хороший менеджер в таких дискуссиях должен создать план решения проблемы, а не самостоятельно решать ее. Если командам не удается договориться, то менеджеру могут помочь фасилитационные практики либо он может делегировать эту работу скрам-мастеру.
Как решать проблему долга
В быстро меняющемся мире невозможно создать совершенный продукт. Команда должна принять, что нет идеальных продуктов, есть недоанализированные. Какими бы умными и талантливыми ни были члены команды, проблема может возникнуть всегда. Наглядный пример — катастрофа шаттла «Челленджер» (когда космический челнок разрушился в результате взрыва внешнего топливного бака на
Процесс решения долга — это в первую очередь регистрация всех существующих проблем. Потенциальные проблемы регистрировать также необходимо, даже самые невероятные. Это поможет в поиске элегантных решений.
Чтобы правильно регистрировать этот долг, лучше разбить его на источники возникновения, например:
- версии используемых библиотек и приложений;
- проблемы с безопасностью;
- ошибки архитектуры;
- потенциальные места улучшения кода;
- предупреждения компиляторов, интерпретаторов и платформ выполнения.
В то же время это должен быть не формальный процесс, а рабочий инструмент команды. Обслуживание и администрирование долга выглядит как рутина, но что-то можно автоматизировать. К примеру, проверка версий может быть автоматизирована скриптами мониторинга, а на чтение Release Notes/Change log/CVE (Common Vulnerabilities and Exposures) надо выделять отдельное время специалиста. Этого инженера выбирает команда, и менеджмент должен быть согласен с расходами на подобную работу.
Создавая задачи для обычного процесса разработки, стоит ориентироваться на «долговую книгу». Закрытие долга может выглядеть как дефект или фича: зависимо от того, как договорятся в команде или как хочет заказчик. Возможно, размер долга существенно важен для продаж продукта.
Техдолг требует систематической коммуникации. Это может быть частью коммуникации во время бэклог-груминга, или для этого организовывают отдельный процесс. Самое главное — пересматривать долг и уточнять серьезность проблем регулярно. Ведь это тоже часть продукта и она уже работает.
А что верхи?
В мире товарно-денежных отношений везде, где есть деньги, есть ответственность. И невозможность выполнить взятые на себя обязательства, риски и явные проблемы должны быть обозначены и обсуждены. Долговая книга — это не только инструмент команды. Это обратная сторона медали продукта: с одной стороны его успех, с другой — это колосс на глиняных ногах.
Этот документ должен быть доступен для спонсоров, инвесторов и всех руководителей — и тех, кто платит, и тех, кто несет ответственность. В каком формате предоставлять информацию — вопрос уже к менеджеру. Ведь приоритеты для разработки могут спускать сверху, а значит, заказчики должны быть проинформированы, что должно быть закрыто в продукте, кроме их желаний. В любом случае двухсторонний обмен информацией по продукту всегда полезен.
Риски
Главный и существенный риск — скатиться в легаси и растерять экспертизу по продукту. Мало кто хочет ковыряться в непонятном коде, неявных взаимосвязях и разбирать best practices прошлого. Обычно проблемы начинаются с финансов, что выражается в соотношении новых фич к дефектам.
В момент, когда поддержка начинает преобладать — люди, создавшие продукт, начинают уходить, как и те, кто поддерживал процессы. С уходом специалистов, особенно ключевых, новую ответственность часто никто не хочет на себя брать. Или никто не понимает, что и как лучше надо сделать.
Со временем данная долговая книга становится артефактом прошлого. И поскольку с ней никто не работает, может казаться, что продукт совершенный и все долги закрыли. Для верхов это может быть сигналом, что продукт обрел идеальность. А на самом деле люди, которые сейчас на проекте, не занимаются техническим долгом, а закрывают только внезапные потребности.
Накопленный технический долг и менеджерская слепота приводят к появлению конкурентов на рынке, противостоянию и даже поражению. Каноничный пример нерешенной проблемы технического долга — война токов. Если коротко, то Томас Эдисон не мог решить проблему передачи энергии на дальние расстояния. А Джордж Вестингауз смог, несмотря на черный пиар Эдисона.
Резюме
Рецепта, как сделать хорошо, нет. Но можно создать резюме, которое в этом поможет и уж точно не навредит. Если вы болеете за свой продукт и хотите его развивать, обратите внимание на рекомендации ниже, но помните, они не являются единственно верными (ведь вы всегда можете подстроиться, создав свои):
- Сделайте удобным инструмент для отслеживания использующихся версий и версий сторонних продуктов, которые есть в вашем решении.
- Отслеживайте инциденты безопасности по вашему продукту и по продуктам, которые используете. Старайтесь заказывать независимый аудит безопасности.
- Разделите четко зоны ответственности: кто отвечает за администрирование проблемы и за ее решение. Четкая граница позволит избежать лишней работы.
- Обсудите работу с техдолгом, проанализируйте затраты ресурсов на это.
- Договоритесь о формате долговой книги, как она выглядит для инженеров, как для менеджеров, а как для заказчиков и спонсоров.
- Менеджер должен уметь аргументированно вести диалог по техдолгу как с исполнителями, так и заказчиком.
- Обсуждайте регулярно долги, оценивайте риски и их серьезность. Помните: лучше профосмотр, чем операция.
