Менеджмент для продвинутых: Case Study и Check List по выбору подхода (адаптивного vs итеративного инкрементного) к проекту

«Дьявол в деталях» или Case Study по выбору подхода к управлению проектом и проведению бизнес-анализа

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

1. Имитация оценки условий и целесообразности разработки в начале 2000-ых годов.

Ключевые моменты: фаза Discovery заканчивается с одним из основных выводов — инвестиции в разработку нецелесообразны. Степень развития технологий не способствует реализации идеи.

2. Имитация оценки условий и целесообразности разработки в 2008-2010 годах.

Ключевые моменты: Product Scope не определен и не может быть определен (в последующем, как показала практика, алгоритмы построения маршрутов, ценообразования, и в целом функционал, многократно изменялись в зависимости от вновь возникающих условий), ниша пассажирских перевозок сформирована за счет диспетчерских служб такси, аналогов нет, высокая степень рисков и неопределенности. Целесообразно остановить выбор на инструментах для управления проектом продуктовой разработки (с привлечением инвестиций, например) с адаптивной моделью жизненного цикла, ориентированных на управление изменениями. Целесообразным также на начальном этапе является тестирование гипотезы (MVP).

Задача со звездочкой!

Возможно ли заключение аутсорсингового контракта по схеме Fixed Price для такого рода результатов стратегического анализа (п. 2) условий старта проекта?

3. Имитация оценки условий и целесообразности разработки в наши дни.

Ключевые моменты: Product Scope с первостепенным функционалом определен (по сути разрабатываемое приложение – реплика уже существующих), ниша пассажирских перевозок сформирована, высокая конкуренция, кризис. Фаза Discovery на сегодняшний день может закончиться с одним из основных выводов: инвестиции в разработку нецелесообразны. Но, если все же находятся аргументы за разработку продукта, то проект, например, может быть реализован (в том числе и аутсорсинговой компанией) по итеративной модели жизненного цикла с инкрементным наращиванием функционала продукта и поставками версий продукта на рынок услуг (с четко формализованными процессами Product Scope Elicitation на фазах Pre-Sale или Discovery и Change Management). В отношении поиска и тестирования идей по продвижению продукта, исходя из общего конкурентного анализа и анализа недостатков приложений конкурентов и т.д. могут быть использованы адаптивная модель жизненного цикла и фреймворк Scrum (смешанный подход к управлению проектом).

Задача со звездочкой!

Допустимо ли использовать фреймворк Scrum в аутсорсинговых проектах с зафиксированными характеристиками, такими как, например, Product Scope (п. 3) и т.д. (контракт Fixed Price)?

Совмещение Scrum и Fixed Price в аутсорсинговых проектах стало краеугольным камнем вопроса качества предоставляемых услуг, успешного завершения проектов и поставки продукта, создающего ценность для бизнеса и его потребителей в запланированные сроки и без перерасходования бюджета (или с минимизацией рисков). Теорию по данному Case Study см. в статьях данного ресурса по тегу «Менеджмент для продвинутых».

Примерный список контрольных вопросов (Check List) для ситуационного анализа и выбора подхода

  • На что ориентирован проект (управление фиксированными характеристиками проекта или изменениями)? Возможно ли определить их и зафиксировать (например, Product Scope, см. ситуации из Case Study)?
  • Каковы ключевые черты проекта: реализация функционала по плану (последовательное, итерационное, инкрементное, с поставками или без и т.д.) с контролем расходования бюджета, тестирование гипотезы (MVP) или эмпирическое (инкрементное) наращивание функционала с/без контроля бюджета, с/без жесткой фиксации характеристик проекта?
  • Имеют место эксперименты (в том числе и с отрицательными результатами), понимает ли это заказчик и готов ли платить за них?
  • Каков ЖЦ проекта?
  • Определена ли схема финансового взаимодействия?
  • Насколько определен (прозрачен) Product Scope и запланирована его реализация?
  • Насколько может быть формализованы и осуществлены процессы Product Scope Elicitation и Change Management?
  • И т.д.

Ответы на «Задачи со звездочкой» поста и Ваши размышления можно оставить в комментариях. Я обязательно дам обратную связь. К данному посту они будут открыты непродолжительное время.

Для дальнейшего развития ресурса выберите, пожалуйста, варианты ответов в формах ниже и нажмите кнопки «Vote». Спасибо!

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s