В целом система идеальна.... для того, чтобы регулярно выписывать счета Заказчику, за потраченное время и делать его счастливым каждые две недели. Однако, что же делать если заказчик очень-очень хочет работать с Вами, но очень-очень не хочет платить постоянно, а хочет заплатить один раз, и получить продукт точно вовремя? Другими словами, вместо модели "время-деньги" он хочет сделать проект по фиксированной цене. Возможно ли такое?

Решения

Есть несколько решений

1. Использовать внутри гибкие методологии, XP, SCRUM а снаружи отчитываться в рамках контракта по фиксированной цене.

2. Полностью делать проект по водопадной модели: исследуем-исследуем, делаем-делаем, пытаемся сдать.

3. Используем итеративную модель в рамках которой выполняем мини-проекты с контролем всего проекта методом критической цепи.

Рассмотрим каждый вариант детальнее

Вариант арбуза

Использовать внутри гибкие методологии, XP, SCRUM а снаружи отчитываться в рамках контракта по фиксированной цене.

Плюсы:

  • Вы можете всем говорить, что работаете по модной Agile методологии.
  • Все в команде поддерживают направление движение.

Минусы

  • Заказчик, про ваши старания не знает.
  • Затраты на TDD и парную работу где-то потеряются
  • Вы видите только ожидаемую дату завершения проекта, а не степень отставания проекта от графика.

Использование такого варианта не самая хорошая идея, это похоже на ведение двойной бухгалтерии.

Вариант водопада

Полностью делать проект по водопадной модели: исследуем-исследуем, делаем-делаем, пытаемся сдать.

Плюсы:

  • Вы сможете сделать идеальную архитектуру продукта
  • Можно контролировать расписания проекта на основе анализа отклонений от базового плана.

Минусы

  • Клиент может получить совсем не то что хотел, ведь он узнает о результате только в самом конце.

Такой вариант годится только для коротких проектов. Ибо на длинных повышаются риски связанные с непопаданием в ожидания заказчика.

Вариант "Надежный SCRUM"

Используем итеративную модель в рамках которой выполняем мини-проекты с контролем всего проекта методом критической цепи. Выполнение спринтов Scrum, в рамках критической цепи делает Scrum надежным (Reliable Scrum).

Этот вариант представляет собой синтез лучших техник обоих подходов это:

  • Контроль расчетного времени завершения этапа работ.
  • Контроль успевания проекта в сроки за счет оценки этапа работ как критической цепи.
  • Наличие заложенного времени на дополнительный сбор требований, проработку архитектуры.
  • Формальное заключение договора между менеджером проекта и спонсором в виде Устава проекта (см PMBoK). В котором есть определение целей этапа работ и определены сроки когда продукт должен быть поставлен.
  • Общение с Заказчиком может быть формализовано за счет подписанного план-графика работ. На основании которого выполняется демонстрация достигнутого результата и корректировка движения.

Таким образом, у этого похода есть плюсы:

  • Прозрачность отношений между Заказчиком и Менеджером проекта.
  • Есть критерий оценки успеваемости проекта в срок, понятный для всех заинтересованных сторон.
  • Отсутствие "двойной бухгалтерии" в методологиях по проекту.

Однако есть и минусы

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

Поддержка подходов в BiPulse

Раз уж мы говорим о проектных подходах, то расскажем что есть для них в нашей системе. Сейчас система заточена на работу по XP/Agile методологии, но при этом она обеспечивает и контроль критической цепи. А чтобы это все работало эффективно есть несколько самых важных и базовых вещей на которых стоит обратить внимание:

Стоимость задачи

Основной для Agile планирования служит Оценка задачи в идеальных человеко-днях. На основе которой строится весь прогноз на основе скорости выполнения задач.

Кроме того на основе оценки задачи BiPulse рассчитывает несколько показателей:

  • коэффицент точности планирования, он поможет Вам как менеджеру давать быстрые оценки объемов работ.
  • скорость выполнения задач - учитывается при прогнозировании сроков завершения на основе исторических данных.
  • Оптимистичную дату завершения этапа работ.

Сроки этапа

Это второй важный параметр который нужен для расчета расписания. Обычно во всех баг-трекерах есть только дата релиза, или веха которая ничего не говорит о том когда этап работ должен быть начат. Но ведь это самый важный показатель , Только зная обе даты начала и конца можно стыковать пакеты работ на разных проектах между собой.

На основе указанных сроков этапа работ BiPulse может сообщить:

  • Количество дополнительной работы ,добавленной в этап работ. Это значит незапланированные расходы бюджета.
  • Состояние расписания этапа работ - успеваем ли в сдать в срок. Рассчитывается на основе степени расхода буфера критической цепи (см CCPM.
  • Скорость добавления работы
  • Пессимистичную дату завершения этапа работ.

Индикация буфера критической цепи

График расхода буфера критической цепи

Все проекты в BiPulse рассчитываются методом критической цепи. Однако учитывая тот факт, что в ИТ проектах исполнители на задачах часто меняются, то строить реальную цепь смысла нет. Поэтому, в варианте использования Reliable Scrum (Agile+CCPM), цепью считаются все задачи все задачи в этапе работ. И каждый проект имеет свою точку на графике расхода буфера критической цепи.

График портфеля проектов выводится на Сводке. Мимо него вы точно никогда не пройдете, даже если вы просто разработчик вы всегда знаете текущее состояние дел на проекте.

Итог

Все методологии в проектном управлении хороши, но каждая хорошая на своем месте. BiPulse позволяет использовать каждую методологию правильно, потому что это поддержано "by design".