Почему классические проекты и Agile проваливаются?

Из практического опыта работы с крупными компаниями.

Классический проектный подход

Теория

• Проект разработан по лучшим практикам
• Учтены все требования заинтересованных сторон
• Риски выявлены и проработаны
• План и бюджет утверждены
• Руководитель проекта отвечает за результат

Ожидания

• Проект выполнен в срок и бюджет
• Результат соответствует ожиданиям

Реальность

• Сбор требований: каждый лоббирует своё
• Требования формулируются «по максимуму»
• Руководитель проекта становится «крайним»
• Сроки срываются, даже с буферами
• Результат не совпадает с ожиданиями

Итог

• Выход на рынок — медленно, рынок теряется
• Затраты — высокие
• Риски — средние
• Ожидания — провалены

Гибкий продуктовый подход (Agile)

Теория

• Фокус на ценности и скорости поставки
• Готовность к изменениям
• Регулярная обратная связь
• Кросс-функциональные, мотивированные T-shaped команды

Ожидания

• Сильная команда профессионалов быстро выпускает продукт
• Продукт полезен, безопасен и надёжен

Реальность

• Профессионалов мало, дополняем новичками
• Кросс-функциональность формальная: bus-factor=1
• Вместо команды — группа I-shaped специалистов
• Итерации есть, но клиент результат видит редко
• Архитектура и документация слабые, приходится переделывать
• Безопасность не встроена, ИБ блокирует релизы

Итог

• Выход на рынок — медленно, рынок теряется
• Затраты — высокие
• Риски — высокие
• Ожидания — провалены

Причины

Выбор метода управления

Рассинхронизация между

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

Критерий	Классический проектный метод	Гибкий (Agile, Scrum)	Реальность
Характер задачи	Заранее известные требования, высокая сложность реализации	Требования неопределённые, продукт формируется через гипотезы	Требования заданы частично («что» делать), но не всегда ясно «зачем»
Изменчивость требований	Минимальная, фиксированный scope	Высокая, изменения встроены в процесс	Изменения есть, входят в противоречие с обязательствами
Неопределённость	Низкая: цель и путь известны	Высокая: путь ищется в процессе	Средняя: цель известна частично, путь не всегда прозрачен
Состав команды	Профи нужных компетенций, собраны «под проект»	Сильные мотивированные специалисты, кросс-функциональная команда	Разнородный состав (junior–senior), навыки далеки от «идеальных»
Культура работы	Дисциплина, регламенты, отчётность	Самоорганизация, доверие, открытая коммуникация	Слабая командность, чаще группа людей, чем «команда»
Автономность	Высокая: команда делает всё сама	Обязательная: без этого agile не работает	Низкая: зависимость от других подразделений и систем
Метод управления	Контроль сверху, план и распределение задач	Фасилитация, лидерство, совместный поиск решений	«Гибрид»: контроль сверху + “имитация Agile” снизу
Ожидания заказчика	Сделать по плану, в срок и бюджет	Дать работающий продукт под меняющиеся потребности	«Сделайте быстрее и дешевле» без гибкости и ресурсов
Сильные стороны	Управляемость, предсказуемость при стабильных условиях	Адаптивность, скорость поиска решений, вовлечённость	Масштаб, ресурсы, формальная структура
Слабые стороны	Не выдерживает высокой неопределённости	Не работает без зрелой культуры и автономности	Рассинхронизация между задачей, персоналом и методом

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

Рассинхронизация в целях и показателях

Каждое из заинтересованных лиц

• отвечает за свой участок
• имеет свои цели и показатели успеха (KPI, OKR)
• мотивировано на эффективное решение своих задач

Правильные инструменты

Каждый из участников использует свои правильные инструменты, специализированные, для решения своей задачи.

• Аналитики описывают процессы в BPMN, сложно, красиво, но бизнес-заказчики часто не понимают и половину этих схем
• Архитекторы и разработчики описывают сложные UML-диаграммы, но ИБ не видит там ответов на свои вопросы
• ИБ формулирует цели и требования безопасности, которые непонятны остальным участникам
• и так далее…

Каждый “эксперт” старается “правильно” сделать свою работу, чтобы укрепить свою “экспертность”.

Однако это приводит к потере коммуникации с другими участниками процесса.

Итог - много красивых, но по сути бесполезных документов и огромных затрат на их создание и поддержание.

Где выход?

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