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

Технический долг: путь к апокалипсису или новой стабильности

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

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

2. Быстро меняющиеся требования Agile на то и agile, чтобы быстро реагировать на изменения и отвечать сиюминутным требованиям ситуации. В результате копятся "временные" решения, которые будут вызывать недоумение в будущем.

3. Недостаток документации Самый спорный тезис Agile-манифеста: "Работающий продукт важнее исчерпывающей документации" часто воспринимается как: "Нам документация сейчас вообще ни к чему!". Сколько продлится это "сейчас" - неизвестно никому. Что в свою очередь приводит к накоплению кода, сложного для поддержки и модернизации.

Для обеспечения долгосрочной стабильности продукта технический долг нужно ликвидировать. Но как это делать, если Бизнес вам говорит: "Эти работы не несут никакой ценности!" или "Ну мы же жили с этим раньше и ничего!"?

Как "продать" бизнесу ликвидацию технического долга На моей практике у вас есть всего три варианта: 1. Договориться объяснив последствия Объясните, откуда взялся технический долг, какими жертвами дался быстрый выход в прод, как увеличиваются риски стабильности и коммерческой эффективности продукта без замены элегантных конструкций на нормальные решения. Также объясните, что устранение технического долга приведет к оптимизации времени и ресурсов для поставки новой ценности в будущем. Когда не получится, переходите к пункту 2.

2. Прямые угрозы "Если мы не оптимизируем код запросов в БД на поиске завтра, то послезавтра, с учетом роста запросов в поиск, он перестанет работать совсем. Серверные мощности не справляются с ростом. Денег на железки вы нам не даёте, штош, поживём как-то без поиска." Жестокий, жесткий, но действенный способ отрезвить горячие головы, которые считают, что если работает, то и трогать не надо. Однако перед тем как подобное заявить, не забудьте запастись циферками и графиками. Потому что горячие головы моментально эскалируют ситуацию на уровень, где без циферок вас даже слушать не станут. На моём опыте — самый эффективный способ.

3. Ложь во имя спасения Максимально спорный, но тоже действенный вариант. Можно воспользоваться последней нештатной ситуацией с продуктом и возложить всю ответственность на неустранённый технический долг. Скорее всего это будет не совсем ложь и доля правды в этом будет, но пользоваться этим способом я точно не рекомендую.

И ещё одна рекомендация: не выпрашивайте технологические спринты/итерации, за них Бизнес спросит втройне. Договаривайтесь о резерве ресурсов на систематическую работу с техдолгом. Штука в том, что долг есть всегда и за 1 спринт/итерацию его не ликвидировать.

Повышайте стабильность ваших продуктов и пусть аптайм ваших сервисов будет вечным! И не забудьте написать нам в комментарии, что надо сразу делать нормально, чтобы смысла в этом посте вообще не было!

В заключение, хочу поздравить всех с наступающим Новым Годом и пожелать успехов в вашей профессиональной деятельности! Сил вам, энергии и до встречи в 2025!

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