Формула технического долга, или Почему «получается так, как есть»
Коллеги, посмотрите на видео. Если этот человек вам не знаком, представлю, это Бронислав Виногродский, известный китаист, мыслитель и писатель, чьи переводы древних текстов заставляют по-новому взглянуть на привычные вещи. Этот отрывок я случайно увидела у своего учителя учителя йоги в канале, и не смогла пройти мимо.
Слова Бронислава меня тронули. Это не просто философия или житейская мудрость. В его словах самая точная модель жизненного цикла большинства ИТ-проектов и первопричина 99% багов.
Как ИТ-руководитель, я вижу в этих словах готовую формулу накопления технического долга. Давайте разложим ее на знакомые нам составляющие на примере реальной задачи.
1. «Думаешь одно» — Запрос от бизнеса
Коммерческий директор приходит с идеей:
«Мне нужен интерактивный дашборд, чтобы в реальном времени видеть эффективность каждого менеджера по продажам. Хочу видеть динамику по KPI, воронку и прогноз выполнения плана на квартал. Все на одном экране, чтобы мотивировать команду!»
Это идеальная картина мира. Видение, которое должно привести к росту продаж.
2. «Говоришь другое» — Техническое задание
Бизнес-аналитик переводит это видение в ТЗ. И тут начинаются нюансы.
«“Реальное время” — это обновление данных каждый час, так как ETL-процесс запускается по расписанию. “Прогноз” для V1 сделаем на основе линейной регрессии, без сложных моделей. А “все на одном экране” разобьем на три вкладки, иначе интерфейс будет перегружен».
Это уже не чистая идея, а ее интерпретация, зафиксированная в Jira и Confluence.
3. «Делаешь третье» — Код и реализация
Разработчик берет задачу. Он выясняет, что API для получения данных по сделкам работает медленно. Чтобы уложиться в дедлайн, он добавляет кэширование, из-за которого данные фактически обновляются раз в два часа. А ключевой показатель из старой CRM приходится забирать через «костыльную» интеграцию, написанную наспех.
«API отдает данные с задержкой, пока поставим кэш. С интеграцией потом разберемся, главное — успеть к релизу».
И вот тут важно: такие костыли возникают не просто так, а как раз из-за жёстких сроков. Когда реализации дают мало времени, приходится жертвовать архитектурой и качеством ради дедлайна.
4. «Получается так, как есть» — Продукт на продакшене
В итоге отдел продаж получает дашборд. Данные в нем двухчасовой давности, а в первый день нового месяца интеграция со старой CRM падает, и виджет с ключевым KPI показывает ошибку.
Коммерческий директор недоволен, что дашборд «не в реальном времени», а команда разработки срочно пишет хотфиксы, вместо того чтобы работать над новыми задачами.
Как этот замкнутый круг можно разорвать?
Вот пять ключевых процессов, которые реально работают для синхронизации ожиданий и результатов:
- Совместное формирование требований. Обсуждайте цели с командой и фиксируйте договоренности на общем для всех языке.
- Регулярные демонстрации и пользовательская приемка (UAT). Показывайте прогресс бизнесу, давайте заказчику тестировать итоги — до финального релиза.
- Code Review и автоматизированное тестирование (CI/CD, автотесты). Проверяйте качество, автоматизируйте проверки, чтобы баги не превращались в «недокументированные возможности».
- Эффективное управление изменениями и приоритетами. Все изменения — согласованы, приоритеты актуальны и прозрачны для всех.
- Ретроспективы и совместное улучшение процессов. Анализируйте ошибки с командой, внедряйте корректировки не «по факту», а осознанно и превентивно.
Хотелось бы здесь отметить, что мотивация в ИТ часто строится на «кнуте» за срыв сроков и «прянике» за сданную задачу. А что это значит — что важно сдать проект и подписать акт приемки. А то что результат будет соответствовать требованиям заказчика — второстепенно.
Моя позиция — процессы должны работать честно и открыто, тогда шансы на то, что результат совпадет с ожиданиями, резко возрастают.
Если хотите, чтобы проект стал источником гордости, а не источником мемов — ставьте честность, взаимодействие, прозрачность и совместный контроль в основу вашей работы.