«Вредный» технический долг

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

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

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

Отсутствие взаимодействия и процесса

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

Отсутствие единого стандарта

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

Неправильная структура

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

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

Отсутствие опыта

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

Отсутствие владельца

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

Устаревание информации

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

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

Александр Кузовлев
Телеграм-канал @aheadofthepack