Почему вся команда должна сокращать технический долг

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

Обсудим, кто еще из IT-специалистов поможет оптимизировать работу с техдолгом.

Почему вся команда должна сокращать технический долг

Влияние технического долга на продукт и бизнес

Снижение качества продукта
Накопленные проблемы в коде и устаревшие компоненты приводят к ошибкам — функциональность и надежность программы снижаются.

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

Ограничения масштабируемости
Неэффективный код ставит развитие продукта на паузу — бизнес теряет возможность расшириться и теряет клиентов.

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

Ухудшение пользовательского опыта
Постоянные ошибки в функционале продукта отрицательно влияют на репутацию бренда и удовлетворенность клиентов.

Какие специалисты могут управлять техдолгом

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

Итак, кто в команде и чем может повлиять на устранение некорректных архитектурных решений:

Руководители
Должны анализировать текущие процессы, чтобы выявить слабые места и возможности для оптимизации. После — определять, какие ресурсы потребуются для устранения технического долга. Это может включать в себя выделение бюджета, найм дополнительных сотрудников или перераспределение персонала. В помощь — система CodeAche, которая помогает отслеживать эффективность работы, контролировать команду, мониторить качество и сложность кода. В скором времени выйдет релиз с функционалом для аналитики процессов разработки: скорость, частота доставки кода и участие в код ревью.

<i>Интерфейс CodeAche</i>
Интерфейс CodeAche

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

Продукт-оунеры
В статье Product Coalition говорится, что только команда разработки может определить момент появления техдолга и, если он возникает, то ответственность за устранение накопленных проблем в коде лежит на продуктологе. Специалисту нужно проводить ретроспективы, демонстрации и фиксировать проблемы. Через определенные промежутки времени — предоставлять команде возможность делать рефакторинг. Конечно, это может потребовать отмены приоритетных задач от руководства, но продукт-оунер должен управлять этим процессом и осведомлять бизнес.

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

Катя, продукт-оунер в Цифровые Привычки.

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

<i>Интерфейс CodeAche</i>
Интерфейс CodeAche

Архитекторы ПО
Специалистам нужно проводить тщательный анализ кодовой базы и инфраструктуры системы, чтобы выявить слабые места и устаревшие компоненты. После — предлагать программистам лучшие практики и стандарты разработки, такие как Continuous Integration или Continuous Deployment, а также современные и подходящие инструменты.

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

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

Лена, тестировщик в Цифровые Привычки.

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

Заинтересованные стороны бизнеса
Стейкхолдерам в долгосрочной перспективе следует зарезервировать время для работы с техдолгом. В период спада они должны быть готовы немного замедлиться и позволить специалистам потратить усилия на рефакторинг.

P.S. Роль, которую нельзя исключать — пользователи
Сообщения об ошибках и проблемах в использовании продукта помогают разработчикам понять, какие аспекты нуждаются в улучшении.

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

44
2 комментария

продукт-оунерамВот из зис? Кэн ю спик рашн плиз?

Ответить

Смотря какой fabric смотря сколько details 😎

1
Ответить