… в любом явлении есть малозаметные составляющие, которые, тем не менее, сильно влияют на его суть.Agile «захватил» мир информационных технологий? Или многие уже успели разочароваться? Почему?
Из Википедии
Потому что, даже если философия и подходы Agile (Scrum) к управлению совершенно не подходят конкретному проекту, команды все равно желают быть в мейнстриме, «быть Agile». И получают псевдо-Agile и глубокое разочарование в майндсете и одном из его инструментов — фреймворке Scrum.
Первая ошибка таких команд мне видится в непонимании отличия
проектов с итеративной моделью жизненного цикла (с инкрементным наращиванием функционала продукта или без него), реализуемых по схеме финансового взаимодействия Fixed Price/Fixed Budget и, чаще всего, ориентированных на управление фиксированными характеристиками проекта, от проектов с адаптивной (гибкой, Agile) моделью жизненного цикла (которая в свою очередь является разновидностью вышеназванной итеративной инкрементной модели жизненного цикла), ориентированных всегда на управление изменениями.
Т.е. помимо предиктивной (Waterfall) и адаптивной (Agile) моделей жизненных циклов (ЖЦ) существуют еще итеративные инкрементные (разновидностью которых, как было уже сказано, и являются адаптивные) ЖЦ. Это первый ключевой нюанс. Такая классификация моделей ЖЦ приводится в PMBOK. Сейчас я ссылаюсь на пятую версию руководства. Шестая версия претерпела некоторые изменения и, на мой взгляд, стала менее информативна на этот счет.
Названная схема финансового взаимодействия Fixed Price/Fixed Budget — это второй ключевой нюанс. Хотя, допускаю, что можно разрабатывать продукты итеративно (с поставками или без) и не по Agile, и без фиксации бюджета. Например, некоммерческие продукты, разрабатываемые с «чистого листа» (Green-Field Projects) для собственных нужд. Но речь идет про аутсорсинг. Поэтому момент со схемой финансового взаимодействия важен.
В первом типе проектов — акцент на контроле фиксированных характеристик проекта. Fixed Price — первостепенная схема финансового взаимодействия в аутсорсинге. Заказчик платит за итеративную (поэтапную) реализацию объема функционала, т.е. за реализацию заранее как-то определенного и оцененного на этапе продаж (или Discovery) содержания продукта (Product Scope) или работ (Work Breakdown Structure). Изменения допустимы и не влекут за собой серьезных последствий (в отличие от Waterfall). Но они анализируются на целесообразность (в процессах управления Change Requests/Enhancment Requests и лояльностью заказчика). В случае утверждения требуют пересмотра и согласования вновь установленных проектных параметров. Инкременты (поставки) по результатам итераций могут как быть, когда заказчик, например, хочет видеть наглядно ход работ, давать обратную связь, постепенно внедрять новый функционал, так и нет.
Часто случающийся в таких проектах переход к схеме Time and Material — это переход к более доверительным отношениям с заказчиком, в том числе и с целью оптимизации трудозатрат менеджера на составление планов итераций и отчетов. Но этот переход не всегда значит то, что проект приобретает черты Agile. Особенно, если в приоритете управления по-прежнему остался контроль проектных параметров, а не изменений. В противном случае, должен быть проведен тщательный анализ, результатом которого может стать изменение подхода к управлению проектом и инструментов для его реализации.
Во втором типе проектов — акцент на управлении изменениями. Основополагающий принцип управления изменениями, заложенный в том числе и во фреймворке Scrum, — это принцип эмпиризма. Заказчик в аутсорсинге или продуктовая компания, если речь идет о продуктовой разработке, платят, помимо реализации Product Scope, в том числе и за эксперимент (эмпирику) и изменения. Или даже возможно за отрицательный результат. Решение в отношении дальнейшего существования инкремента может быть отрицательным (все или часть наработок могут быть выброшены), но ценным в отношении приобретаемого опыта, на основании которого и происходят дальнейшее совершенствование и, возможно, новые эксперименты. С точки зрения здравого смысла ни о каких строго фиксированных планах, бюджетах, сроках в таких условиях неопределенности Product Scope не может идти и речи.
В частном случае, как вариант, можно зафиксировать бюджет на тестирование гипотез. При полном его расходовании остановиться на том, что получилось, сделать соответствующие выводы по результатам. А в общем — вопрос совместимости Scrum и Fixed Price/Fixed Budget непрост и требует анализа множества нюансов и конкретных ситуаций для рассмотрения целесообразности и способов их совмещения.
Если заказчик в аустсорсинге не готов платить в том числе и за эксперимент, и за изменения (переработку функционала), к тому же требует зафиксировать содержание, бюджет, сроки, о каком Scrum может идти речь? На мой взгляд, понимание такого нюанса на этапе планирования проекта и выбора подхода к управлению исключает ряд проектных сложностей и последующие выводы о нежизнеспособности Agile.
Примерный список контрольных вопросов для ситуационного анализа
- На что ориентирован проект (управление фиксированными характеристиками проекта или изменениями)?
- Каковы ключевые черты проекта: реализация функционала по плану (последовательное, итерационное, инкрементное, с поставками или без и т.д.) с контролем расходования бюджета, тестирование гипотезы (MVP) или эмпирическое (инкрементное) наращивание функционала с/без контроля бюджета, с/без жесткой фиксации характеристик проекта?
- Имеют место эксперименты (в том числе и с отрицательными результатами), понимает ли это заказчик и готов ли платить за них?
- Каков ЖЦ проекта?
- Определена ли схема финансового взаимодействия?
- Насколько определен Product Scope и запланирована его реализация? и т.д.
Case Study по выбору подхода к управлению проектом: приложение для организации пассажирских перевозок для мобильных платформ
В пунктах ниже указаны лишь ключевые моменты для практической иллюстрации вышеизложенной теории. Названия существующих приложений опущены. Исчерпывающий стратегический и проектный анализ, а также полный список, формирующий основные выводы, не приводятся.
1. Имитация оценки условий и целесообразности разработки в начале 2000-ых годов.
Ключевые моменты: фаза Discovery заканчивается с одним из основных выводов — инвестиции в разработку нецелесообразны. Степень развития технологий не способствует реализации идеи.
2. Имитация оценки условий и целесообразности разработки в 2008-2010 годах.
Ключевые моменты: Product Scope не определен (в последующем алгоритмы построения маршрутов, ценообразования, и в целом функционал, многократно изменялись в зависимости от вновь возникающих условий), ниша пассажирских перевозок сформирована за счет диспетчерских служб такси, аналогов нет, высокая степень рисков и неопределенности. Целесообразно остановить выбор на инструментах для управления проектом продуктовой разработки (с привлечением инвестиций, например) с адаптивной моделью жизненного цикла, ориентированных на управление изменениями. Целесообразным также на начальном этапе является тестирование гипотезы (MVP).
3. Имитация оценки условий и целесообразности разработки в наши дни.
Ключевые моменты: Product Scope с первостепенным функционалом определен (по сути разрабатываемое приложение – реплика уже существующих), ниша пассажирских перевозок сформирована, высокая конкуренция, кризис. Фаза Discovery на сегодняшний день может закончиться с одним из основных выводов: инвестиции в разработку нецелесообразны. Но, если все же находятся аргументы за разработку продукта, то проект, например, может быть реализован (в том числе и аутсорсинговой компанией) по итеративной модели жизненного цикла с инкрементным наращиванием функционала продукта и поставками версий продукта на рынок услуг. В отношении поиска и тестирования идей по продвижению продукта, исходя из общего конкурентного анализа и анализа недостатков приложений конкурентов и т.д. могут быть использованы адаптивная модель жизненного цикла и фреймворк Scrum (смешанный подход к управлению проектами).
