Обзор отчета, на который я наткнулся в блоге Хенни Портмана.

Отчет называется «CHAOS 2020: Beyond Infinity», и судя по всему — это последний отчет группы такого формата.

Факторы успешности

Основными факторами успешности (Factors of success) в версии 2020 являются хороший спонсор, хорошая команда и «хорошее место». На самом деле это мета-факторы, внутри которых по десятку более мелких принципов:

Картинка из поста Хенни Портмана

Хороший спонсор (The Good Sponsor)
Душа проекта (так и пишут!) и обязательное условие для существования проекта. Спонсор существует на стороне заказчика проекта или выгодополучателя проектных результатов, его задача — предоставлять необходимые ресурсы и поддержку проекту и проектной команде. Спонсор отвечает за выделение бюджета и других ресурсов, контроль исполнения проекта, соответствие проектных целей стратегическим задачам компании-заказчика. Спонсор у команды проекта может быть всего один — но поскольку это роль, следует понимать, что представлен спонсор может быть целой группой людей.

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

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

Хорошая команда (The Good Team)
Команда — это производители проектного результата. ПМ, разработчики, инженеры по требованиям, служба контроля качества, и так далее. Команда должна быть маленькой (см. предыдущий пост), работать по аджайлу, быть профессиональной и в выборе метода, и в прикладных вопросах.

Хорошее место (The Good Place)
Под «хорошим местом» подразумевается «человеческое пространство», в котором существует проект. Это — все люди, которые так или иначе касаются проекта в процессе его жизни и при этом не являются частью команды или спонсором. Задача компании — улучшать навыки тех, кто представляет собой это «хорошее место», чтобы проекты в компании имели больший шанс на успех.

Из трех факторов самым простым в управлении считается спонсор, на втором месте — команда, на третьем — «хорошее место». Decision latency находится в ведении спонсора и «места».

Развенчанные мифы

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

Хенни приводит в пример четыре мифа, в которые пора перестать верить:

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

Эпилог

Это такой пункт в отчете — The Epilogue. В нем рассматривается история проектных подходов в разработке софта в четырех периодах:

1. «Дикий Запад» (1960-80) — методик нет или все изобретают свои, проекты ведутся «как-то».
2. «Водопад» (1980-2000) — выполнение перечня работ с разбивкой на явные последовательные фазы, строго по порядку.
3. «Эджайл» (2000 и скоро закончится) — проекты разбиваются на маленькие управляемые кусочки, фокус на гибкость и возможность поменять ход разработки в любой момент.
4. «Бесконечный поток» (Infinite Flow Period) — еще не начался, но уже вот-вот. Продлится тоже около 20 лет.

Метод потока подразумевает отказ от проектов в принципе. Новые фичи и функции в виде описаний запускаются в некий «конвейер разработки», на выходе из которого — продуктовые инкременты в готовом виде. Проектов и сопутствующих им ролей больше нет — ни проектных менеджеров, ни требований в привычном виде, ни стори поинтов, ни планирований с релизами. Разработка из «development» превращается в «manufacturing». Если раньше проект был бутылкой воды, то в режиме потока вода просто льется из крана.

Утверждается, что подобная организация работы позволит сократить до 90% накладных расходов при сохранении результата.

Идея смелая и очевидная, но если по чесноку — даже аджайл не везде еще прижился. Такой подход, с краном вместо ящика бутылок, могут потянуть гранды вроде Амазона (35 тыс. разработчиков) или молодые компании, начинающие с нуля и живущие без легаси.

Видео CHAOS 2020: Beyond Infinity

Есть еще вот такое ↑ видео трехлетней давности, там один из участников Standish Group Ганс Малдер раскрывает некоторые детали из отчета. Приведу пару моментов.

Аджайл круче водопада

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

Move fast

Good Decision Latency — это когда решения принимаются быстро, а Poor — когда долго, было в прошлом отчете. Разница поразительная : быстрые решения в десять раз уменьшают вероятность зафейлить проект и почти в четыре раза увеличивают вероятность успешно завершить проект.

Сколько стоят задержки принятия решений

Разница в накладных расходах на принятие решений у команд с High-скиллом и Poor-скиллом примерно десятикратная.