3 практики управления ИТ-проектами и разработкой: Проектный треугольник, Agile итерации и ФФФ
В мире ИТ-разработки выбор правильного подхода к управлению проектом часто определяет, будет ли продукт успешен или превратится в бесконечный черновик с сорванными дедлайнами и перерасходом бюджета.
Сегодня поговорим о ключевых моделях: Agile, классическом проектном треугольнике (iron triangle) и принципе ФФФ (Fix Time, Fix Budget, Flex Scope). Разберём, когда и в каких условиях каждый из них работает лучше всего, опираясь на модель Кеневина (Cynefin).
Вводные: основные концепции
Проектные треугольники (Iron Triangle)
Проектный треугольник — хорошая базовая модель для простых и предсказуемых проектов, где требования понятны заранее, среда стабильна, а результат можно достаточно точно описать до старта.
Классическая модель:
- Scope (Охват / Требования) — что именно нужно сделать.
- Time (Сроки) — когда.
- Cost (Бюджет / Ресурсы) или Quality (Качество).
Идея в том, что одновременно жёстко зафиксировать все три вершины почти невозможно. Если фиксируем scope и сроки — растёт бюджет или падает качество. Если фиксируем бюджет и сроки — приходится сокращать scope. Поэтому треугольник полезен как язык trade-off'ов: он помогает заранее договориться, какая вершина проекта действительно фиксированная, а какая может двигаться.
В простых и повторяемых проектах — например, типовом внедрении, миграции по известному сценарию или разработке понятной функциональности — такой подход даёт предсказуемость. Здесь можно заранее составить план, оценить объём работ и управлять проектом через контроль сроков, бюджета и требований.
Agile итерации
Agile — это семейство итеративных подходов (Scrum, Kanban, XP и др.). Основные черты:
- Короткие итерации (спринты) — обычно 1–4 недели, реже месяцы.
- Регулярные поставки рабочего продукта.
- Гибкость к изменениям требований.
- Бюджет и планирование часто тоже итеративные (time & material или фиксированные спринты с корректировкой).
Agile отлично справляется с неопределённостью, фокусом на ценности для пользователя и быстрым получением обратной связи.
Вместо попытки детально зафиксировать весь scope в начале Agile предлагает короткие итерации, регулярные поставки рабочего результата, постоянную приоритизацию, проверку гипотез на пользователях или рынке и адаптацию плана по мере накопления знаний.
То есть Agile не отменяет проектный треугольник, а меняет способ управления им. Время часто фиксируется итерациями, бюджет считается через команду и длительность работы, а scope становится гибким и пересматривается по мере обучения.
ФФФ (Fix Time, Fix Budget, Flex Scope)
ФФФ можно рассматривать как попытку сделать практичный гибрид между классическим проектным управлением и Agile.
С одной стороны, ФФФ сохраняет управленческую дисциплину:
- фиксируем сроки;
- фиксируем бюджет;
- не жертвуем качеством.
С другой стороны, ФФФ принимает Agile-логику неопределённости: если реальность меняется, флексить безопаснее всего именно scope. Не нужно бесконечно двигать дедлайн или раздувать бюджет — лучше вовремя убрать менее важные функции, запустить рабочий продукт и продолжить развитие итерациями.
Проект — это не доставка ящика апельсинов, а экспедиция Колумба. План — идеальная линия, но реальность полна неожиданностей. Поэтому ФФФ особенно полезен там, где бизнесу нужна предсказуемость по срокам и бюджету, но продуктовая часть остаётся живой и требует адаптации.
Подробнее: https://bureau.ru/about/fff/
Когда что лучше применять: взгляд через модель Кеневина (Cynefin)
Модель Кеневина помогает определять природу проблемы и выбирать подходящий стиль управления. Она делит контекст на домены: Простой (Clear/Obvious), Сложный (Complicated), Комплексный (Complex) и Хаотичный (Chaotic).
- Простой домен (Clear): Причина и следствие очевидны, повторяемые задачи, стабильные требования.Лучше всего: Waterfall или чётко спланированный фиксированный проект.Здесь проектный треугольник работает "в лоб" — можно зафиксировать всё. ФФФ избыточен, Agile тоже (слишком много overhead на итерации). Пример: внедрение стандартной CRM с минимальной кастомизацией.
- Сложный домен (Complicated): Причина и следствие понятны экспертам, но требуют анализа. Много зависимостей.Хорошо: Гибрид (Waterfall + элементы Agile) или Kanban.Проектный треугольник помогает управлять trade-off'ами. ФФФ может применяться, если важны жёсткие дедлайны (например, запуск к определённой дате события). Agile даёт преимущество в прозрачности.
- Комплексный домен (Complex): Причина и следствие проявляются только постфактум. Высокая неопределённость, инновации, меняющиеся требования рынка/пользователей.Идеально:Agile (особенно Канбан).Здесь ФФФ становится мощным дополнением: фиксированные время/бюджет заставляют регулярно приоритизировать и флексить scope, а итерации Agile обеспечивают быструю обратную связь. Классический треугольник "ломается" — лучше не пытаться зафиксировать scope заранее.
- Хаотичный домен (Chaotic): Полная неразбериха, кризис.Подход: Действовать быстро, экспериментировать, наводить порядок.Agile с очень короткими циклами + элементы ФФФ (жёсткие временные боксы). Главное — стабилизировать ситуацию, а не пытаться построить идеальный план.
Переход между доменами: Многие проекты начинаются в Complex, а по мере накопления знаний переходят в Complicated. Хороший менеджер постоянно "sense-makes" (осмысливает) контекст и корректирует подход.
Выводы
Нет универсального "лучшего" подхода — есть контекст.
- Если проект в простом/сложном домене с чёткими и предсказуемыми требованиями — классический треугольник + Waterfall или гибрид даст предсказуемость.
- В комплексном мире современного ИТ (а таких большинство) Agile + ФФФ — мощная комбинация: итерации обеспечивают адаптивность, а фиксация времени и бюджета — дисциплину и своевременный запуск.
- Главное правило ФФФ остаётся актуальным почти всегда: лучше запустить чуть меньше функций, но вовремя и качественно, чем бесконечно полировать "идеальный" продукт, который выйдет слишком поздно.
Успешное управление — это не про жёсткое следование методологии, а про понимание природы проекта и готовность "флексить" там, где это безопаснее всего (обычно в scope).