НОВОСТИ [Из песочницы] C чего начинается псевдо-Scrum в аутсорсинге (немного теории и Case Study)

[Alvaros]

… в любом явлении есть малозаметные составляющие, которые, тем не менее, сильно влияют на его суть.

Из Википедии​

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 (смешанный подход к управлению проектами).