Введение
Как инженер DevOps и облачный архитектор, я уверен, что эта история откликнется у многих моих коллег. Будучи сторонником Agile и человеком, видевшим пользу итеративной разработки и принципов гибкой методологии, я всё же не застрахован от давления классического проектного управления. Вместе с проектной доставкой часто приходят привычные вопросы: Какой дедлайн? Когда это будет готово? Можно ли показать что-то уже сейчас, чтобы продемонстрировать прогресс?
Не секрет, что проектные менеджеры предпочитают видеть линейное продвижение проекта без глубокого понимания всей сложности происходящего «за кулисами». Я говорил об этом раньше: гибрид waterfall и Agile порождает много проблем. Жёсткие оценки, сроки и приоритеты — лишь симптомы такого несправедливого и несбалансированного подхода.
Главный вопрос здесь: «Когда это будет сделано?» против «Что мы можем поставить в течение ближайших двух недель?». Проекты часто воспринимаются как линейные: есть начало, конец и запуск. На практике же два проекта никогда не бывают одинаковыми, интеграции всегда уникальны, а неопределённость неизбежна. Agile это признаёт. Вместо фиксации объёма и даты, Agile определяет успех как предсказуемую доставку ценности небольшими итерациями. Это особенно важно в платформенной инженерии, где большая часть реального прогресса остаётся невидимой для сторонних наблюдателей.
Основное противоречие: разные определения прогресса
Оно особенно заметно, когда сталкиваются платформенные команды и команды приложений:
- Платформенный взгляд: прогресс — это управление, автоматизация пайплайнов, модульность, устойчивость и безопасность. Даже если ещё нет развернутого приложения, фундамент обеспечивает более быстрое и безопасное развитие в будущем.
- Взгляд приложений: прогресс — это ресурсы, которые можно «увидеть» (виртуальная сеть, хранилище). Если ресурс появился в консоли, значит работа движется.
Оба взгляда логичны — просто у них разные горизонты ценности. Но без правильной рамки проектные менеджеры часто обесценивают «невидимую» работу, считая её отсутствием движения.
Почему возникает рассинхрон
- Разные горизонты ценности: приложения ориентированы на краткосрочную отдачу, платформы — на долгосрочную устойчивость.
- Невидимые элементы: пайплайны, управление и версионирование сложно продемонстрировать, хотя они критичны.
- Несовпадение стимулов: менеджеров оценивают по вехам приложений, а не по зрелости платформы.
Результат? Создаются модули заранее, показывается «видимый» прогресс — но позже это приводит к переделкам и удвоенной стоимости.
Цена «делаем, потому что можем»
Пример: создать Terraform-модуль для сети за месяцы до того, как появится лендинг-зона. На бумаге — прогресс. На деле — модуль простаивает. Когда он действительно понадобится, требования уже изменились — приходится переделывать или выбрасывать.
Это классический муда по Lean — перепроизводство и ненужные запасы. В ИТ и инфраструктуре это выглядит так:
- модули, созданные слишком рано,
- скрипты без потребителей,
- развернутые, но неиспользуемые окружения.
Это не прогресс — это замаскированный технический долг.
Agile-принципы в действии
Agile предлагает выход:
- Just-in-time delivery: создавать ближе к моменту использования, чтобы работа отражала реальные требования.
- Избегать потерь: не тратить усилия на артефакты, которые нельзя проверить или применить.
- Приоритизировать энэйблеры: рассматривать платформенные элементы как полноценные задачи бэклога, а не «фоновую работу».
Исследования подтверждают это. Отчёт Standish Group CHAOS показывает: проекты с итеративными методами (Scrum, Kanban) достигают в 3 раза более высоких показателей успеха, чем традиционные. Lean-аналитика говорит, что до 20–30% усилий в ИТ уходит на переделки из-за преждевременной или несогласованной работы. Agile не идеален, но он минимизирует этот waste, перестраивая фокус с дедлайнов на итерации ценности.
Как сократить разрыв: практические шаги
Чтобы совместить интересы менеджеров и приоритеты платформы, можно:
- Сделать энэйблеры видимыми
Пайплайны, политики, версионирование должны быть отдельными задачами в бэклоге. - Перевести ценность платформы на язык приложений
Пайплайны → быстрое подключение новых приложений.
Версионирование → безопасное использование модулей.
Политики → меньше блокировок на финальных проверках. - Показывать инкрементальные результаты
Пайплайн, разворачивающий простой ресурс.
Политика, блокирующая некорректное развёртывание.
Эти «малые шаги» дают менеджерам видимый прогресс. - Балансировать видимость и суть
Иногда стоит отдать лёгкий, «демонстрационный» результат, продолжая строить фундамент. - Показать цену переделок
Преждевременные задачи = потраченный бюджет и риски для графика. Такой язык понятен PM.
Выводы кейса
Приоритизация в Agile — это не «что можно сделать первым», а «что создаст ценность в нужное время».
- Видимый прогресс ≠ реальная ценность.
- Ценность часто невидима на ранних стадиях.
Когда платформенная работа признаётся ценностью, а не накладными расходами, доставка становится устойчивой. Agile не убирает дедлайны, а заменяет жёсткие рамки проекта на предсказуемую итеративную доставку ценности.
Заключение
В ИТ и облачной инженерии открытие — это не фаза, а постоянный процесс. Объём никогда не фиксирован, зависимости меняются, интеграции уникальны. Поэтому Agile куда лучше подходит для продуктовой разработки, чем для традиционных проектов.
Переформулируя вопрос с «Когда всё будет готово?» на «Что можно поставить в ближайшие две недели?», мы перестаём гнаться за искусственными сроками и начинаем строить предсказуемость, качество и устойчивость команды.
Именно в этом суть приоритизации по-Agile — и путь к созданию платформ и приложений, которые действительно работают.