Как не управлять техническим долгом
Определение технического долга
Технический долг — это работа, выполненная в прошлом, которая при рассмотрении с сегодняшней точки зрения создаёт проблемы с функциональностью, стабильностью или скоростью.
В этом разделе мы рассмотрим 4 основных предположения, которые приводят к неправильному управлению техническим долгом:
- ☠️ Предположение №1: Технический долг = плохо
- 🕸️ Предположение №2: Весь технический долг = сложная работа
- 📈 Предположение №3: Технический долг ≠ продуктовая работа
- 👨👨👧👦 Предположение №4: Личная боль = организационная боль
☠️ Предположение №1: Технический долг = плохо
Нет сомнений в том, что у технического долга плохая репутация. Одна из проблем, связанных с борьбой с техническим долгом, заключается в том, что тип технического долга, с которым вы сталкиваетесь, может сильно различаться — небольшое развёртывание эксперимента может быть безобидным по своей природе, но редизайн продукта может быть сложным из-за зависимостей от нескольких служб. Несмотря на это, большинство технических долгов классифицируется в едином сегменте «плохих» или «обременительных» из-за неизвестности.
Чтобы противостоять предположению «технический долг = плохо»:
- Не стоит классифицировать весь технический долг в единую категорию «плохого». Это делает его однообразным и не побуждает к приоритизации исправления, потому что это всё (на первый взгляд) одна и та же проблема. Лучше разделить категорию технического долга, назвав и измерив боль, чтобы каждый проект имел свои особенности и возможность быть рассмотренным.
- Часть технического долга полезно иметь, и каждой команде нужен технический долг. Это необходимо, потому что это указывает на то, что команда не слепо сосредоточена на борьбе с техническим долгом, но также делает акцент на основных бизнес-направлениях (например, разработка нового продукта, эксперименты, поддержка партнёрства и т. д.). Каждая успешная компания масштабировала свой бизнес, накапливая долги. Приоритизация технических решений над бизнес-решениями часто означает, что организация не увидит своего роста.
🕸️ Предположение №2: Весь технический долг = сложная работа
Как и в случае с любой сложной работой, есть несколько способов справиться со сложностью. В случае с техническим долгом есть способы подойти к определённой и неопределённой работе.
ОПРЕДЕЛЁННАЯ = работа имеет чёткое начало и конец.
- Путь к концу может быть безболезненным или трудным (в зависимости от типа и размера технического долга), но есть явное завершение и способ его достичь.
- Всякий раз, когда технический долг можно определить, это предположение опровергается.
НЕОПРЕДЕЛЁННАЯ = у работы есть начало, но конец неясен.
- С этим сложнее справиться и управлять ожиданиями, по сравнению с «в коробке» определённым техническим долгом.
- Как подробно обсуждается в программе Reforge «Масштабирование продуктовой доставки», в таких ситуациях вполне возможно перейти к более определённому, менее сложному состоянию, перенаправив определённую работу вперёд.
- Работа, которую можно перенаправить, включает в себя: определение проблемы, определение всех потенциальных решений на высоком уровне и выяснение того, как и когда фактически внести исправление или реализовать.
- Например, команда может установить промежуточные этапы, чтобы уменьшить сложность технического долга. Или команда может перейти от неопределённого к определённому, имея доступ к дополнительной исторической информации или тратя время на создание предложения по решению работы.
📈 Предположение №3: Технический долг ≠ продуктовая работа
Организации чётко понимают, как продуктовая работа, которую они выполняют, продвигает показатели компании — они связывают каждый эксперимент, функцию или редизайн с основными бизнес-целями или улучшениями OKR. Этот уровень ясности обычно отсутствует в отношении технического долга, и поэтому он неправильно отделяется от продуктовой работы.
Чтобы противостоять предположению «технический долг ≠ продуктовая работа»:
- Даже если конкретная область технического долга напрямую не связана с показателями, подумайте в широком смысле о том, какие пользовательские или продуктовые аспекты она может помочь в будущем.
- Выделяя время на проверку того, что бизнес-лиды и технические лиды находятся на одной волне, можно облегчить понимание того, почему команде необходимо заботиться об этой работе.
👨👨👧👦 Предположение №4: Личная боль = организационная боль
Инженеры или другие лица, близкие к техническому долгу, регулярно повторяют, что этот кусок технического долга для них лично болезненный. Они могут бороться во время контроля качества вокруг определённых кусков доисторического кода или вообще захотеть уволиться, потому что команда слишком долго полностью не принимает новый язык программирования. Сотрудник может чувствовать, что это становится концом света для него, в то время как остальная часть организации, вероятно, не чувствует такой же боли (если они вообще это замечают).
Чтобы противостоять предположению «личная боль = организационная боль»:
- Когда кто-то приходит с высокой приоритетной областью технического долга, найдите минутку, чтобы оценить, является ли это индивидуальной или организационной болевой точкой. Обычно организационные болевые точки напрямую влияют на клиента или бизнес каким-то образом.
- Подумайте с точки зрения человека, у которого больше организационного контекста, чем у вас. Вы даже можете представить больную точку другому человеку в команде. Если ваша индивидуальная перспектива удержится в более широких контекстах, продолжайте выносить её с поддержкой от других затронутых коллег и команд.
6 типов технического долга
Технический долг часто попадает под один огромный зонтичный термин, который включает в себя всё: от задержек в скорости до уязвимостей в системе безопасности, рефакторинга и многого другого. Вместо зонтичного термина нужно понимать различные типы технического долга, чтобы использовать его как стратегический рычаг. Эта классификация поможет людям в организации лучше понять, какой тип технического долга у них есть, и что с ним связано, вместо того чтобы говорить об «техническом долге» неопределённо.
6 ключевых типов технического долга, с которыми сталкиваются команды:
- Долг по обслуживанию
- Долг по эффективности разработчиков
- Долг по стабильности
- Долг по безопасности
- Технический продуктовый долг
- Долг по принятию решений
Обратите внимание, что часть технического долга может относиться более чем к одной категории, что делает её потенциально более важной для решения.
Долг по обслуживанию
Что это такое = когда команды не успевают за обновлениями технической работы. Это включает в себя не удаление мёртвого кода в нужное время после запуска эксперимента / развёртывания функции / отмены события, обновление библиотек, комментирование фрагментов кода для контекста и документирование решений по реализации.
Пример долга по обслуживанию…
- Не очистка кода за несколько месяцев для эксперимента по созданию учётной записи «войти через Spotify».
- Приводит к тому, что новый инженер включает в свой технический объём и документацию по планированию функции учётной записи «войти через Spotify», поскольку он полагал, что эксперимент был запущен.
- На самом деле у эксперимента были отрицательные результаты, и у команды не было времени, чтобы очистить свой код, потому что им нужно было перейти к новому эксперименту.
- Новый инженер разочарован тем, что (а) никто не подсказал ему, что это долг по обслуживанию через мёртвый код, когда он начал расследование, и (б) в команде нет процессов для очистки или хотя бы для обозначения кода, который нужно удалить.
Долг по эффективности разработчиков
Что это такое = когда в компаниях нет нужных тестов, мониторинга и/или оповещения о продукте. Это распространённый тип долга, когда инженерные рабочие процессы крайне неэффективны, время развёртывания и сборки может занимать несколько часов или дней, а у разработчиков нет инструментов, которые позволили бы им обнаруживать технические проблемы до их выхода в продакшн.
Пример долга по эффективности разработчиков…
- В организации, которая выросла с 15 до 50 инженеров за год, тщательные тесты и оповещения не были внедрены для нового опыта покупок, поскольку за последние шесть месяцев было проведено множество экспериментов в этой области.
- Поэтому есть как минимум 2–3 релиза, в которых обнаруживаются ошибки, и команде приходится быстро их исправлять, поскольку они приоритезированы как ошибки высокой серьёзности.
- Команда, отвечающая за поток покупок, затем выделяет время для добавления надлежащего тестирования критически важного для бизнеса потока и оповещения о постановке.
Долг по стабильности
Что это такое = когда организация накапливает различные виды технического долга, что затем влияет на стабильность их инфраструктуры. Это приводит к сценариям, когда вместо проактивного управления по вызову приходится реактивно управлять по вызову, привлекая экспертов по предметной области или, по сути, косвенно вовлекая всю команду.
Пример долга по стабильности…
- В мобильном (iOS/Android) приложении команда приоритизирует iOS намного выше, чем Android, поскольку в инженерной команде больше разработчиков iOS.
- В результате Android-приложение лишено фундаментальных рекомендаций по продукту в отношении критически важных для бизнеса потоков (и соответствующих тестов, которые должны быть на месте), а также имеет код «криптонита» вокруг начальных функций, разработанных сторонним вендором.
- Это приводит к тому, что приложение для Android аварийно завершает работу для пользователей, пытающихся получить доступ к старым функциям. В конце концов, продукт получает плохие отзывы в Google Play Store за ненадёжное качество и частые сбои.
Долг по безопасности
Что это такое = когда в технологическом стеке есть проблемы, которые делают компанию уязвимой для угроз безопасности, таких как подбор паролей, утечки данных или конкуренты, знающие, как собирать конфиденциальную информацию.
Пример долга по безопасности…
- Утечка данных происходит, когда компания не может исправить известную уязвимость из-за сбоев во внутренних процессах и не выделяет достаточно времени для обновлений. Это приводит к тому, что личные данные тысяч или миллионов клиентов оказываются в открытом доступе.
- Это происходит постоянно в результате незначительных событий без имён компаний и крупных утечек, таких как Equifax в 2017 году (затронуло более 140 миллионов человек).
Технический продуктовый долг
Что это такое = когда есть видимое негативное влияние на продукт. Эта работа наиболее проста и убедительна для решения, поскольку она имеет очевидное влияние на пользователей и обращена наружу, поэтому любая команда в организации может увидеть последствия для клиентов и продаж/доходов.
Пример технического продуктового долга…
- Когда пользователю требуется заметно больше нескольких секунд для выполнения определённого действия в продукте.
- Хотя это может быть вызвано лежащим в основе долгом по эффективности разработчиков, долгом по стабильности или долгом по обслуживанию, это достаточно очевидно, чтобы повлиять на основной опыт работы с продуктом.
Долг по принятию решений
Что это такое = когда было принято прошлое техническое решение, которое было X% неправильным или имело некоторые компромиссы по объёму, времени или ресурсам, и теперь команда платит за это решение. Это наиболее распространённая форма технического долга.
Пример долга по принятию решений =
- Команда изначально решает использовать стороннего поставщика для проведения экспериментов на своём веб-сайте. После нескольких лет звёздного роста продукт теперь имеет миллионы уникальных посетителей в день.
- В результате инженерные, данные и продуктовые команды сталкиваются с трудностями при проведении одновременных сложных экспериментов, поскольку поставщик не может легко поддержать то, как команда хочет продвигаться в трафике, сегментации аудитории и исключениях.
- В этой ситуации есть долг по принятию решений, потому что команда приняла компромиссное решение об использовании поставщика экспериментов вместо того, чтобы построить собственный инструмент для экспериментов. Это, вероятно, было правильным решением в то время, но теперь имеет последствия в понимании потребностей аудитории и трафика в отношении экспериментов.
Определение размера технического долга: острый и системный
Как только вы поймёте тип технического долга, который вы возьмёте на себя, вам нужно будет определить его стоимость, чтобы вы могли сравнить её с возвратом, который вы получите.
Существует спектр размера технического долга, от острого до системного:
Острый технический долг
- Относительно небольшой размер технического долга.
- Пример: чтобы выпустить новую функцию, команда пропустила некоторые события, мониторинг, реализацию на менее используемой платформе/браузере и т. д. Команда может легко внести обновления, и работа может быть выполнена быстро (<1 день, если нет других блокировщиков).
Системный технический долг
- Относительно большой или огромный размер технического долга.
- Пример: технический директор/учредитель принял решение о продукте (и косвенно о технологиях) 5 лет назад, и команда с тех пор борется с его последствиями. Изменение этого решения потребует изменения тенденций, которые команда приняла за последние годы. Это может принимать форму решений о настройке основного продукта, ключевых инвестициях в функции или пользовательском опыте и результирующей архитектуре дизайна/технологий. Команда не может легко решить эту проблему с техническим долгом, и работа может занять от месяцев до лет.
Пример острого > системного: долг по эффективности разработчиков
Обратите внимание, что каждый тип технического долга может быть оценён по шкале от острого до системного. Чтобы проиллюстрировать, с долгом по эффективности разработчиков…
Острый долг по эффективности разработчиков
- Инженер не написал тесты Selenium для эксперимента MVP по реферальной программе, который доступен только для 10% пользователей продукта.
- Они не написали тесты, потому что вся команда взяла на себя обязательство провести ручное регрессионное тестирование функции перед запуском эксперимента.
- Инженер позже тратит несколько часов на добавление тестов, пока готовится следующий раунд эксперимента с рефералами.
Системный долг по эффективности разработчиков
- Поскольку команда разработчиков на ранней стадии не формализовала практики по тестированию и оповещению, они чувствуют боль через несколько лет экспоненциального роста продукта. Каждый день у них есть как минимум несколько инцидентов в продакшене, которые влияют на их пользователей, а их показатель NPS снижается месяц за месяцем.
- Добавление всех тестов и оповещений невозможно за одну ночь, пока команда балансирует новую разработку. Поэтому технические руководители выстраивают последовательность: сначала создать руководящие принципы по тестированию и оповещению, затем применить эти принципы к критически важным областям и функциям (P1) в этом квартале, затем к P2 областям в следующем квартале и к P3 областям в следующем квартале.
- К концу года, или через 7–9 месяцев, во всех областях продукта будут действовать единые принципы тестирования и оповещения, основанные на недавно установленных руководящих принципах. Поэтому количество ежедневных/еженедельных инцидентов должно уменьшиться, а настроения клиентов должны начать улучшаться по мере решения проблем P1 (а затем P2, P3).
Стратегический приоритизация технического долга
До сих пор мы рассматривали предположения, классификации и размеры в отношении технического долга. Как только вы поймёте эти вещи, вы сможете принять стратегическое решение в более широком контексте ваших продуктовых решений.
Гибкость в приоритизации технического долга
Ключ к стратегическому видению технического долга вращается вокруг понимания того, когда нужно увеличить или уменьшить масштаб приоритизации технического долга по сравнению с другой продуктовой разработкой.
Чтобы правильно управлять техническим долгом, рассмотрите следующие векторы:
- Уверенность — какова вероятность того, что это приведёт к серьёзной проблеме для команды?
- Время — когда эта проблема станет актуальной?
- Влияние на пользователя — приведёт ли невыполнение этой задачи к проблемам со скоростью или качеством, которые повлияют на пользовательский опыт?
- Последовательность — помешает ли это команде достичь важных целей?
- Накопленный долг — сколько долгов вы уже решили накопить?
Каждый вектор должен быть классифицирован по шкале от низкого до высокого приоритета:
- Уверенность — где на шкале от низкой к высокой вероятность того, что эта часть технического долга приведёт к серьёзной проблеме?
- Время — когда на шкале от не срочно до срочно эта часть технического долга станет проблемой?
- Влияние на пользователя — где на шкале от низкого к высокому невыполнение этой части технического долга приведёт к проблемам со скоростью или качеством, которые повлияют на пользовательский опыт?
- Последовательность — где на шкале от минимального воздействия до блокирующего воздействия эта часть технического долга помешает команде достичь важных целей?
- Накопленный долг — где на шкале от минимального до значительного накопленный технический долг?
Исходя из того, где часть технического долга находится в комплексной шкале (показанной на визуале ниже), легче понять, как стратегически использовать технический долг по сравнению с другими инициативами компании:
- Необходимо ли решить системный технический долг как можно скорее, поскольку существует высокая вероятность возникновения значительной проблемы?
- Лучше ли временно решить проблему, чтобы заняться другими, потенциально более важными задачами?
- Можно ли отложить решение этой части технического долга до более подходящего времени, особенно когда приоритетом являются другие инициативы компании/команды?
В визуале выше видно, что необходимо решить системный технический долг как можно скорее, поскольку существует высокая вероятность возникновения значительной проблемы, проблема станет актуальной в ближайшее время, долг сильно повлияет на достижение поставленных целей, и уже накоплено значительное количество долгов.
- Если некоторые векторы — скажем, влияние на пользователя и последовательность — были меньше и находились слева, то можно было бы временно решить проблему с помощью быстрого решения или обходного пути на несколько месяцев.
- Если ещё больше векторов — скажем, время, влияние на пользователя и последовательность — были бы меньше и находились слева, то, вероятно, было бы целесообразно отложить эту область технического долга до подходящего времени в будущем.
В каждой ситуации (решить, временно решить, отложить) важно критически оценить часть технического долга, рассматривая каждый вектор и шкалу от низкого до высокого приоритета. Оценка технического долга таким образом позволяет команде принять наилучшее стратегическое решение о том, как действовать по сравнению с другими инициативами компании.
Ваш стратегический портфель технического долга, основанный на стадии роста компании
Ещё один способ стратегически подойти к техническому долгу — это составить свой портфель технического долга, основанный на типе технического долга в зависимости от размера организации.
Здесь, в Reforge, мы классифицируем компании по мере их прохождения через четыре стадии роста на S-образной кривой:
- Траектория = нижняя часть S-образной кривой, до достижения соответствия продукта рынку. Линейные, немасштабируемые усилия для запуска двигателя роста.
- Перелом = изгиб S-образной кривой, чёткие сигналы соответствия продукта рынку в небольших масштабах. Переход от немасштабируемых к масштабируемым циклам роста.
- Масштаб = стадия гиперроста компании. Оптимизация основных циклов роста. Удвоение ставок на то, что работает.
- Расширение = приближение к верхней части S-образной кривой, начинается насыщение. Нужно подумать о расширении PMF и перезапуске процесса с нуля или добавлении нового цикла роста.
Связанный с S-кривой, каждый тип технического долга должен быть сбалансирован соответствующим образом в зависимости от стадии роста организации.
Некоторые ключевые моменты, на которые следует обратить внимание на каждой стадии роста:
Траектория
- Помните, что это до достижения соответствия продукта рынку.
- На этом этапе ваша команда должна принимать инженерные решения в пользу скорости, а не точности, стабильности, процессов и т. д. — отсюда большой объём долга по эффективности разработчиков.
- Это обычно означает выбор предвзятого полнофункционального фреймворка, такого как Django, Rails или PHP, и разработка с высокой скоростью, особенно поскольку подавляющее большинство ранних продуктов представляют собой грубые приложения и нуждаются в хорошей интеграции с веб-сайтами и мобильными устройствами.
Перелом
- Это когда появляются признаки соответствия продукта рынку и продукт переходит в масштабируемые циклы роста.
- Здесь команда осознаёт, что некоторые процессы необходимы (так что долг по эффективности разработчиков начинает решаться) и всё ещё определяет наилучшие способы балансировки внутренних процессов и пользовательского опыта, отсюда рост технического продуктового долга.
Масштаб
- Это период гиперроста для компании.
- В этой фазе технический продуктовый долг и долг по эффективности разработчиков начинают уменьшаться/стабилизироваться в результате поиска лучших внутренних практик и баланса в отношении процессов и пользовательского опыта.
- Здесь также растёт долг по безопасности, обслуживанию и принятию решений в результате очень быстрого роста и невозможности реально успевать за обновлениями безопасности, уборкой и «исправлением» прошлых решений.
- Масштабирование также является этапом, когда происходит больше всего изменений и исправлений в тестовой автоматизации, системах развёртывания, мониторинге и оповещении, логировании и инструментарии, миграциях, тестировании и постановке, а также ETL.
Расширение
- Это этап, на котором начинается насыщение. На этом этапе бизнес более зрелый.
- Долг по обслуживанию и принятию решений продолжает расти в результате количества исторического кода и решений, принятых ранее.
- Долг по эффективности разработчиков начинает расти снова, поскольку команда ищет новые возможности для роста (вне рамок существующего продукта и роста на сегодняшний день).
- Технический продуктовый долг, долг по безопасности и стабильности уравновешиваются после предыдущего интенсивного периода масштабирования.
Стартовые советы по управлению портфелем технического долга
Управляя портфелем технического долга в процессе роста компании, необходимо обратить особое внимание на несколько ключевых областей: процессы, инструменты, спринты и дорожные карты. Ниже приведены краткие рекомендации для каждой области, когда вы хотите уменьшить объём одного типа технического долга, чтобы сбалансировать его за счёт принятия другого типа технического долга по мере развития компании с течением времени.
Процессы для сокращения создания технического долга
Хотя стратегически целесообразно накапливать технический долг, бывают случаи, когда имело бы смысл предотвратить создание технического долга с помощью внедрения процессов.
- Это особенно актуально на стадиях роста компании «Перелом» и «Масштаб», когда долг по эффективности разработчиков должен уменьшаться по мере присоединения к команде новых инженеров.
- Некоторые примеры таких процессов включают в себя код/PR-обзоры, стандарты мониторинга, проверки качества, технические/дизайнерские обзоры.
Инструменты, предотвращающие формирование определённых видов долга
- Подобно процессам, описанным выше, существуют также случаи, когда инвестиции в основополагающие инструменты предотвратят формирование некоторых видов долгов.
- Это особенно важно на этапе «Масштаб» развития организации, чтобы иметь более унифицированные методы для предотвращения проблем с безопасностью (долг по безопасности), предотвращения ошибок, которые могут повлиять на пользовательский опыт (технический продуктовый долг), и обеспечения согласованности кода (долг по эффективности разработчиков).
- Некоторые примеры таких инструментов включают в себя линтеры и конвейеры CI/CD.
Спринтовая работа для реактивного и острого технического долга
- По мере того как организация достигает масштаба, когда у неё больше установленных обязанностей по вызову, спринт по вызову должен быть потрачен на устранение пожаров (цель вызова) или на реактивную работу, связанную с техническим долгом (во время простоев от вызова).
- Это позволяет организации продвигаться вперёд по острым вопросам технического долга и фактически предпринимать действия на основе текущих/прошлых инцидентов через команду по вызову.
- Предоставление возможности тем, кто отвечает за вызов, работать над этой реактивной работой, особенно важно на этапах «Масштаб» и «Расширение» роста, поскольку решение острых вопросов технического долга позволит другим командам создавать новые функции/продукты и брать на себя дополнительные долги.
Дорожная карта для проактивного и системного технического долга
- В отличие от использования времени по вызову для реактивного острого технического долга, включение технического долга в дорожные карты должно использоваться для долгов, требующих значительной корректировки дорожной карты и работы между командами.
- Примеры того, когда технический долг следует включать в дорожные карты, включают предложения о крупной переработке, редизайне системы данных для основной функции продукта, используемой клиентами, определение и внедрение оповещений о критических путях, миграцию с одной платформы доходов/платежей на другую и другие области, которые могут занять месяцы для успешного внедрения.