Важность
Проработав более 10 в компаниях различного размера, я сталкивался с изрядной долей технологического долга различного уровня: старые легаси системы, бизнес-логика на уровне БД, сервисы, написаные одним из разработчиков, чтобы попробовать новую технологию, потом уволившегося и никто кроме него не знал как работать с этой технологией.
Хотя сегодня, это может выглядеть ужасно, но в свое время они могли послужить важным катализатором для запуска и продвижения продукта. На самом деле, технический долг, возможно, является неизбежным злом: если растущая компания не берет на себя некоторую долю заемных средств, то, скорее всего, она работает не так быстро, как должна была бы. Однако по мере того, как компания начинает набирать обороты, наступает переломный момент, когда становится важно начать уделять приоритетное внимание техническому долгу.
Обычно это время наступает, когда ваш бизнес начинает масштабироваться, а ранее принятые решения ради экономии времени начинают становиться узким местом для новой работы. Но тогда возникает вопрос, как мы расставляем приоритеты по выплате части долга, который мы накопили, когда он конкурирует с нашей пропускной способностью для создания новых функций?
Исследование долга
Сначала мы хотим составить карту ландшафта. Наша цель - понять систему и то, как ее отдельные компоненты связаны друг с другом. Она не должна быть слишком подробной, но должна содержать достаточно конкретики, чтобы мы могли начать изучать ее части с точки зрения того, как компоненты поддерживают рабочий процесс нашего продукта. Например, если мы можем ответить на вопрос: "Является ли это узким местом?", то мы на правильном пути.
Некоторые части этой карты могут потребовать дополнительного внимания, чтобы понять, какие части конкретного компонента вызывают у нас проблемы. Например, масштабируется ли модель данных с нашей системой или проблема заключается в самой технологии базы данных? Изучите болевые точки и поймите не только симптом, но и основную причину: Мы выбрали наивную модель данных, которая не работает в масштабе.
Часто бывает полезно организовать это упражнение с привлечением людей из более широкого круга команд. Попросите нескольких представителей от каждой команды задокументировать различные болевые точки и проблемы, особенно те, которые являются тематическими или возникают неоднократно. Соберите все это в обзор ландшафта задолженности.
Процентные ставки
Как только мы получили представление о ландшафте и о том, где в нем мы испытываем боль, пришло время выполнить следующее упражнение. Перечислите каждую часть долга. Возможно, вы выявили хрупкие отношения между двумя службами - запишите это. Пройдитесь по своей целостной системе и задокументируйте каждый недостаток. Цель здесь состоит в том, чтобы пока не приписывать значение, а быть всеобъемлющим.
Теперь, имея полный список ваших технических долгов, пройдитесь по каждому из них и ответьте на следующие вопросы:
- Если мы решим ничего не делать, станет ли эта проблема хуже, останется ли она прежней или улучшится?
- Если она ухудшится, то как быстро она ухудшится?
- Если она останется прежней, насколько сильно она нарушает работу сегодня?
- Если она улучшится, то в какой момент она улучшится настолько, что перестанет быть помехой?
- Является ли эта часть системы активной или неактивной - создаем ли мы на ней новые функции сегодня или она находится в режиме обслуживания?
- Если она неактивна, то сколько времени тратится на обслуживание в каждом инженерном цикле?
- Если она активна, обратите на это внимание: вы строите на фундаменте, который может быть нестабильным.
Ответы на эти вопросы помогают нам сформировать рубрику для оценки технического долга и затем могут быть использованы в качестве ключевого вклада в определение приоритетов наряду с другой работой, такой как создание новых функций.
Здесь нет универсального подхода, поэтому вам придется решить, как именно вы хотите взвесить эти критерии. Однако в качестве высокоуровневого руководства вы, как правило, захотите расставить приоритеты для тех вещей, которые становятся хуже и над которыми вы активно работаете. Эти вещи, как правило, похожи на высокие процентные ставки по кредитной карте. В то время как вещи, которые не деградируют быстро и не являются частью активно развивающейся системы, являются более здоровой формой долга. Для вещей, находящихся где-то между ними, потребуется более тщательное балансирование в зависимости от конкретных обстоятельств вашей компании.
Еще одна удивительная вещь, которую вы можете обнаружить при выполнении этого упражнения, заключается в том, что есть даже несколько пунктов, которые, по сути, являются самовосстанавливающимися. Они почти наверняка не требуют внимания, но все же важно понимать, как они влияют на скорость разработки продукта. Преимущество выявления таких вещей заключается в том, что вы можете знать, что их следует отложить в приоритет в пользу более дорогостоящих вещей, перечисленных выше.
Оставаясь платежеспособным
Важно отметить, что леверидж - это мощный инструмент. Технический долг - это один из видов рычага, и большинство стартапов если не нуждаются в нем, то хотят его получить. Поэтому цель данной концепции - обеспечить более структурированный взгляд на этот долг, чтобы мы могли определить "хороший" и "плохой" долг и решить, как действовать в его устранении.
Хотя универсально правильного ответа нет, мы, как правило, хотим сделать приоритетными статьи с высокой процентной ставкой и можем продолжать использовать статьи с более низкой процентной ставкой, если они не слишком мешают нам.
В конечном итоге главное здесь - использовать подобные фреймворки, чтобы оставаться платежеспособными в плане нашей кодовой базы и рабочего процесса продукта. С помощью таких инструментов мы можем избежать банкротства (в прямом и переносном смысле).