Способ улучшения управления техническим долгом

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

Почему мы не относимся серьезно к техническому долгу? Вопрос немалый.

Глобальный технический долг был оценен Gartner в 500 миллиардов долларов в 2010 году и, по прогнозам, к 2015 году составит 1 триллион долларов.

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

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

Существует ряд широко используемых сегодня фреймворков и методологий Agile. Но мы не должны ошибочно принимать гибкость за неписаное правило, позволяющее накапливать технический долг до тех пор, пока его негде будет спрятать. Филипп Крухтен, доктор философии, пишет, что многие agile-команды, похоже, считают, что они полностью защищены от технических долгов. Хотя итерации дают возможность своевременно возместить задолженность, часто происходит обратное . Часто Agile неправильно понимают как движущуюся так быстро, что у нас нет времени подумать о стоимости, связанной с нашими решениями.

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

  1. Мы не видим и недостаточно знаем о негативном влиянии технического долга на заботу.
  2. Технический долг сложно «обнаружить».
  3. У нас нет времени, чтобы понять, во что обходятся наши «ярлыки» (например, совместная разработка достаточно хорошего решения, чтобы просто выполнить работу на сегодня, не думая о завтрашнем дне)

Но что, если мы сделаем неудачи ИТ-проектов более заметными? Что, если бы мы могли нарисовать картину возможных будущих результатов? Будем ли мы более прилежными в доставке программного обеспечения и технологических продуктов?

Начисление технической задолженности

Каждый взлом, обход, плохой фрагмент кода создает технический долг - Бен Стопфорд

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

Уорд Каннингем разработал метафору технического долга (официально - технический долг), чтобы помочь нам задуматься о проблеме плохой разработки программного обеспечения:

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

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

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

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

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

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

Последствия технического долга

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

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

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

Влияние на боевой дух команды

Дэвид Лариби объяснил, что помимо очевидного экономического спада, технический долг несет реальную психологическую цену. . . этот психологический эффект сказывается на моральном духе команды . Например, менеджеры по продукту, дизайнеры и бизнес-аналитики теряют мотивацию и / или разочаровываются из-за того, что они постоянно проектируют и тестируют новые функции, которые никогда не начинают разрабатываться, потому что появляется непрерывный поток высокоприоритетной работы. В результате они становятся пессимистичными в отношении своего вклада.

Влияние на производительность

John Elm описывает код, который не поддерживается должным образом, по своей природе более хрупкий. Следовательно, разработчикам нужно тратить больше времени на диагностику и устранение проблем, а не на реализацию улучшений, о которых кричат ​​клиенты и бизнес. Кроме того, пообщавшись с несколькими разработчиками, все они предпочитают работать над крутыми вещами (например, создавать новые функции, экспериментировать с новыми технологиями, создавать прототипы новой концепции и т. Д.), А не рутинным задачам рефакторинга или устранению неожиданных дефектов.

Влияние на качество продукции

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

Воздействие на риск проекта

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

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

Визуализация и информирование о техническом долге

Если мы этого не видим, значит… не существует.

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

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

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

Представьте себе среду, в которой инвестор видит, сколько долга можно получить, выбрав «ярлык» для принятия тактического решения? Или что заинтересованная сторона понимает, во что это может стоить бизнесу времени и денег, если он / она хочет, чтобы команда двигалась быстрее? Что, если бы мы могли смоделировать серию сокращений на основе стратегического бизнес-решения, чтобы увидеть, сколько это может стоить, прежде чем мы примем решение? Что, если бы инвестор мог видеть, сколько было «заимствовано» от имени инвестора, чтобы сократить путь в прошлом квартале для выполнения стратегического решения? Эти данные не только позволяют каждому прийти к общему пониманию, но и дают убедительные доказательства, которые можно использовать для принятия действительно обоснованного решения, особенно в быстро меняющейся среде, где у нас просто нет времени каждый раз вычислять эти цифры.

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

Решение проблемы технического долга

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

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

«Каждое действие, которое мы предпринимаем, имеет последствия, иногда лучше подумать о последствиях, прежде чем мы начнем действовать», - Пкарпиц

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

Бланкетные заявления

Технический долг опасен, когда используется в качестве общего заявления, чтобы оправдать, почему что-то не может быть сделано или является более сложным, чем необходимо. Разработчики и члены продуктовой группы часто делают такие заявления, но это не помогает другим сторонам по-настоящему понять последствия и то, как нам будет хуже в различных ситуациях . Я предлагаю также учитывать контекст, цель и предполагаемые решения при решении проблемы технического долга. Например, если мы не можем сформулировать, как нам будет лучше / хуже, если мы решим конкретную часть технического долга, должны ли мы тратить на это время и действительно ли это долг?

Метрики тщеславия

Измерение количества дефектов, количества активных ветвей, времени сборки,% покрытия кода и т. Д. - это начало, но чего это помогает нам достичь? Что это нам говорит? Какие решения мы можем принять с его помощью? Сведение количества дефектов к минимуму - это хорошо, но как узнать, какое количество дефектов - это хорошо. Количество дефектов также, вероятно, будет зависеть от размера вашего программного обеспечения и размера вашей команды. Точно так же и с количеством активных веток. Что касается% покрытия кода, можно утверждать, что чем выше покрытие, тем лучше. Но мы могли бы обеспечить покрытие кода на 90%, но, по опыту, часть тестов может быть написана некорректно, что лишает нас цели тестирования. Между тем, ваше покрытие по-прежнему составляет 90%. В любом случае, я думаю, вы уловили суть. Чтобы по-настоящему измерить технический долг, нам нужно понимать контекст, цель и, что наиболее важно, решения, которые мы надеемся принять с использованием данных.

Обратите внимание, что мы упоминали ранее, что не весь технический долг является плохим (например, технический долг, который быстро погашается в краткосрочной перспективе). Следовательно, измерение технического долга и данных, связанных с ним, должно быть более сложным, чем простой подсчет. Продолжение следует в отдельной статье.

Неоднозначные методы

Существующие методы решения проблемы технического долга - это только начало, но есть еще много возможностей для улучшения. Возьмем, к примеру, матрицы решений. Они часто используются для определения приоритетов тех вопросов долга, которые необходимо решить в будущей итерации. Однако обширные академические исследования объясняют низкое качество использования матрицы рисков из-за крайних ошибок округления (также называемых сжатие диапазона), несоответствий и двусмысленности. Это ничем не отличается от матрицы решений, если не хуже, из-за дополнительной неоднозначности (например, срочно, несрочно, важно, не важно). Двусмысленность скрывает проблемы, а не способствует отсутствию информации, - говорит Хаббард.

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

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

Производительность - король

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

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

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

«Каждое решение имеет последствия». - Дэймон Даррелл

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

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

  • Во сколько обходится вашему бизнесу технический долг?
  • Как узнать, что технический долг вышел из-под контроля?
  • Перевешивают ли прибыль убытки от технического долга?
  • При возникновении технического долга по стратегическим и / или тактическим причинам, вы выплачиваете достаточно быстро, чтобы дать вам хоть какой-то шанс получить прибыль по нашему долгу?
  • Каков коэффициент долга в вашей системе?
  • По какой ставке начисляется технический долг?
  • Каков уровень воздействия технического долга на вашу команду?

Если вы хотите узнать больше о том, как улучшить управление техническим долгом, свяжитесь с нами по адресу [email protected].

Что-то узнал? Нажмите 👏, чтобы сказать «спасибо!» и помогите другим найти эту статью.

Удерживайте кнопку хлопка, если вам понравился контент!

Хлопайте 30 раз!