Гибридная методология ведения проектов WaterScrum как мы это настроили

Всем привет.

Меня зовут Геннадий Гребеник и мы с командой трансформации Фора-Банка столкнулись с задачей сочетания в своей работе классических и гибких методологий управления проектами. В ходе решения данной задачи командой были разработаны подходы к гибридной модели ведения проектов, когда управление сверху остается в классическом, каскадном планировании, а команды снизу реализуют данные проекты с применением гибких подходов управления. В виду того, что многие организации в своей работе сталкиваются с необходимостью сочетать в своей работе классические и гибкие методологии управления проектами, хотим поделиться своим опытом.  

Современные подходы ведения проектов и разработки новых решений дают гибкость, необходимую в конкурентной борьбе за клиента, за качество сервисов, за лучший клиентский опыт. Помогают делать успешные проекты в быстро изменяющейся среде. Но не для всех компаний данная методология доступна в чистом виде, и дело тут в ментальности и жизненном опыте организации. Прежде всего, для понимания необходимости и места гибридной методологии, давайте разберем основные причины невозможности внедрить книжные Agile в большинстве Российских организаций.

1. Неумение делегировать ответственность за бизнес результат. Неумение ставить векторные задачи и контролировать процесс, не с точки зрения реализации шагов, а с точки зрения получения конечного результата.

2. Из первого пункта вытекает то, что у Бизнеса, у ТОП менеджмента при использовании гибких методологий нет ощущения контроля процесса. Если конечная цель не определена, бюджеты плавающие, сроки реализации – чем быстрее, тем лучше, то нет возможности зацепиться за привычные формализованные критерии оценки эффективности и успешности выполнения задач и поручений.

3. Убеждение в том, что сотрудники могут давать результат только под давлением целей и сроков. Отсутствует понимания полноценной ответственности и заряженности сотрудников на общий результат.

4. Модели мотивации сотрудников, как правило, строятся от качественного выполнения своих должностных обязанностей и очень редко от финансового результата конкретного проекта или направления бизнеса. Еще одной сложностью в постановке и контроле правильных целей является непонимание или неумение рассчитывать бизнес результат для конкретных подразделений, продуктов, сервисов. Отсутствие возможности всестороннего анализа деятельности своей организации.

Если  же возьмем классический каскадный подход планирования и реализации проектов WaterFall, то для данной категории организаций, он становиться инструментом, дающим ощущение контроля и управляемости проекта. Для большинства Российских организаций переход на гибкие методологии без глобальной смены бизнес модели, модели управления, ТОП менеджмента невозможен. Таким образом, реализуя новые продукты, системы, сервисы встает вопрос, каким образом, не меняя ощущения контроля, для Заказчика реализовать подходы управления, соответствующие современным практикам? Именно об одной из возможных комбинаций методологий хотел бы сегодня рассказать. Делимся своим опытом, в рамках которого разработали подход и методологию гибридного управления проектами, в котором гибкие методологии внедрены внутрь классического каскадного подхода. Сочетание гибкой модели управления на тактическом уровне с отражением стратегических изменений в каскадном планировании. WaterScrum – наше внутреннее названия комбинированной методологии.

Основные определения

Прежде чем перейти к описанию несколько важных постулатов:

·        Конечны результат никогда не будет соответствовать запланированному

·        Объем неопределенности пропорционален объему задачи

·        Заказчик на входе не знает, что хочет на выходе Проекта

·        С опытом повышается точность оценки Проектов

Теперь про процесс.

Процесс разделен на две части, Каскадная и Гибкая части методологии.

Каскадная часть:

Проект – временное предприятие, направленное на создание уникального продукта, услуги или результата (PMBOK), в своей практике мы используем данную форму для задач выше 100 ч.д. Временные предприятия менее 100 ч.д. для нас описываются как Задачи.

Бюджет и сроки проекта – бюджетная оценка проекта формируется на базе оценки первоначальных требований к категории проекта и поскольку мы внутри процесса используем гибкий подход, объему возможных дополнительных задач проекта. При формировании оценки Проекта получаем три показателя:

·         Базовая оценка проекта 100% трудозатрат и сроков - объем проекта

·         Риски проекта 20-30% от объема проекта

·         Дополнительные работы 0 – 30% объема проекта (данная сумма может оставаться как резерв и выделяться траншами при формировании запросов на изменение проекта)

Бюджетная оценка проекта включает в себя все три составляющие. Бюджет на реализацию проекта выделяется в размере первой и второй частей, третья часть остается на новые работы, появившееся в рамках реализации проекта – запросы на изменение Проекта.

Категория риска проекта – уровень риска, который несет проект и который зависит от уровня зрелости методологии в организации (насколько хорошо существующие команды, зная предстоящие задачи, могут спрогнозировать появления новых рисков), объема проекта, глубины проработки входящей задачи. Данные показатели определяются для организации индивидуально и меняются в ходе вызревания методологии в организации.

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

Категория проекта – в зависимости от предполагаемого объема проекта, определяет методы планирования и наличие и проработку первоначальных артефактов на входе. Для себя мы определили следующие градации Проектов/Задач

·         Задачи до 10 ч.д. Задача описывается верхнеуровневой постановкой. Данная постановка может быть сформулирована в виде письма электронной почты или комментарием в ходе ежедневного планирования (Ежедневный SCRUM) или планирования спринта. Данная формулировка обязательно должна фиксироваться в трекинговой системе ведения задач. Оценка осуществляется экспертом разработчиком или аналитиком с допустимым уровнем погрешности 20% - 30% (уровень риска). Данная погрешность заносится в оценку сроков и объема задачи. Если эксперт дал оценку в 8 ч.д., то финальная оценка задачи будет 9,6 ч.д. при уровне риска 20%. Именно 9,6 ч.д. идут в планирование ресурсов, бюджетов и сроков.

·         Задачи до 100 ч.д. Задача описывается верхнеуровневой постановкой с проведением анализа работ и формированием каскадного плана. Оценка осуществляется аналитиками с привлечением разработчиков и архитектора решения. Уровень погрешности 20%-30%, который так же заносится в оценку задачи.

·         Проекты до 500 ч.д. Задача описывается формальной постановкой с проведением анализа работ и формированием каскадного плана. Оценка осуществляется аналитиками с привлечением разработчиков и архитектора решения на базе формальной постановки от Заказчика. На данные задачи возможно привлечение enterprise архитектора. Уровень погрешности 30%-50%, который так же заносится в оценку задачи.

·         Проекты до 2000 ч.д. Задача описывается формальной детальной бизнес постановкой, которая в данной методологии является первоначальным договором о реализуемых требованиях. Формальная детальная бизнес постановка, как правило, готовиться Заказчиком совместно с Бизнес аналитиками исполнителя, в которую входит полноценная проработка задачи с постановкой архитектурного решения, брифа системного анализа. На базе планирования формируется каскадный план. Уровень погрешности 30%-50%, который так же заносится в оценку задачи. Для особо крупных проектов в ходе реализации задачи могут существенно меняться. Для этих целей целесообразно разделить первоначальную оценку проекта с риском уровня 20%-30% и дополнительный бюджет на реализацию новых требований 20%-30%, как это было описано ранее.

·         Проекты свыше 2000 ч.д. необходимо дробить. Оценка подобных проектов в гибридной методологии не возможна в связи с значительным изменением состава в течении его реализации.

Стратегический план проекта – план проекта, построенный по принципам каскадного планирования, отражающий основные комплексные задачи, необходимые к реализации. Фактически, это дорожная карта проекта, сохраняющая взаимозависимости между задачами.

Временные слоты проекта – элемент, совмещающий гибкие методологии с каскадным планированием. Градация сроков задач в каскадной части проекта формируется в соответствии с двух-трех недельными спринтами, принятыми в области гибкой методологии. Таким образом задачи в проекте планируется дискретно по спринтам гибкой части методологии.

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

Гибкая часть методологии.

Спринт – временной цикл проекта в гибкой части методологии. В отличии от Scrum подхода в спринт могут входить отдельные части целой, крупной задачи. В своей практике мы используем спринт/спринты на бизнес анализ, системный анализ, разработку, тестирование, сборку и регресс. Из Scrum остается требование получения ощутимого, проектно-значимого инкремента по задачи.

Backlog проекта – Стратегический план проекта. Задачи распределены по спринтам, в соответствии с текущими приоритетами. 

Планирование спринта происходит в первый день спринта и включает в себя формирование задач на спринт из Backlog проекта.  При этом происходит пересмотр приоритетов, объема задач, который в последствии, после планирования спринта, найдет свое отражение в Стратегическом плане проекта (Каскадной части методологии). Задачи распределенные на команду, отражаются в трекинговой системе. Мы используем в своей работе Jira.

Ежедневный Scrum – стандартный процесс гибкой части методологии. Короткие встречи команды или части команды для ежедневного планирования работ.

Предпланирование спринта – отдельная, дополнительная встреча между Бизнес-заказчиком и ключевыми сотрудниками команды – Scrum мастером/руководителем проекта, аналитиками. Задачи, поступающие на вход команде от Бизнес-заказчика должны быть проработаны и формализованы в соответствии с их категорией. Цель мероприятия, определить готовность задач со стороны Бизнес-заказчика для следующего спринта. Данная встреча позволяет управлять потоком задач со стороны Бизнеса.

Показ – мероприятие, планируемое на конец каждого спринта для демонстрации его результата. В показе принимает участие вся команда и представители Бизнес-заказчика. Показ осуществляется по всем задачам, запланированным в спринт.

Ретроспектива спринта – внутренняя встреча команды с целью:

·         высказаться

·         определить основны точки улучшения процесса

·         найти точки возникновения рисков с категоризацией и учетом рисков в общей системе знаний

Определение точек возникновения рисков, категоризация и учет является ключевым механизмом вызревания методологии в организации. В ходе анализа выполненных работ проводится их категоризация по следующему принципу:

·         Запланированные работы на задачу

·         Работы на новые, незапланированные задачи – фиксируются как доп. требования.

·         Работы на непредвиденные задачи или недооценка выполняемой задачи – Риски

Блок Риски так же подвергается категоризации и учету:

Категории риска – в ходе проекта возникают риски, которые распределяются на три категории для дальнейшего использования в ходе созревания гибридной методологии

·         Ошибки в оценке, ошибки в процессах создания продукта – замеряем, корректируем процессы, обогащаем базу знаний

·         Новые знания – риски связанные с отсутствием на входе знаний об окружающей среде, процессах – задача обогащает базу знаний

·        Непредсказуемые риски – замеряем и учитываем в следующих оценках

Дополнительные требования – задачи, возникающие в ходе реализации проекта, оцененные командой и согласованные с Бизнес-заказчиком. В случае наличия Бизнес постановки на входе, содержащие маркировку изменяемых или добавляемых бизнес требований. Согласование большого количества мелки работ всегда проходит легче согласования одной комплексной задачи. Данный подход позволяет минимизировать сроки на формальное согласование доработок и позволяет избежать задержек в зоне гибких методологий.

И снова каскадная часть

Запрос на изменение проекта – формальный документ, который оформляется в ходе реализации проекта, меняющий объем задач и сроки реализации проекта. Данный запрос формируется на базе сформированных доп. требований, возникших в ходе проекта. Обеспечивает своевременную корректировку Стратегического плана проекта, утверждение изменений на высшем уровне управления организацией.

Проектный комитет – еженедельное собрание основных участников проектной деятельности организации для актуализации Стратегических планов проектов, а также решения вопросов взаимосвязанности проектов и ресурсов.

Описание процесса

Формирование годового бюджета – В ходе стратегического планирования формируется план Проектов с верхнеуровневым расчетом бюджета. Поскольку на входе нет точного понимая, что должно быть реализовано, составление точного бюджета невозможно. На данном уровне делается так называемая бюджетная оценка. Есть несколько методов расчета бюджетной оценки для целей годового планирования:

·         Расчет бюджета по аналогичным проектам. Делается экспертная оценка уровня сложности и приводится к ранее реализованным проектам той же категории.

·         Расчет бюджета по фиксированной или предполагаемой команде

·         Декомпозиция задачи. По теории вероятности, чем детальнее разбивается проект с целью оценки входящих в него компонент, тем выше точность оценки Проекта. Но для этого необходим глубокий опыт в предметной области и практика реализации подобных проектов.

·         Сколько можем себе позволить – часто встречающаяся модель, но это не тема текущей статьи.

Формирование Проекта – формальный процесс, состоящий из сбора требований, построения архитектурного решения, декомпозиции задач и планирования Проекта. Классический подход, на котором останавливаться не буду, единственное, хочу обратить внимание, что задачи свыше 500 ч.д. желательно проработать детально, с подготовкой Бизнес требований, архитектурного и интеграционного решений. Если вы имеете коммерческие взаимоотношения со своим Заказчиком, как в нашем случае, данные работы необходимо выполнять за отдельно выделенный бюджет и до формирования окончательной оценки проекта. На выходе в Проекте должны быть как минимум:

·         Бюджетная оценка проекта с учетом рисков и дополнительных работ

·         Стратегический план проекта

·         Схема проектных команд и модель коммуникации

·         Ограничения и риски проекта

Далее утверждение, выделение бюджета, контрактация и старт.

Стратегический план проекта является сформированным и распределенным по приоритетам и зависимостям Backlog-ом гибкой части методологии. Планирование релизов происходит в зоне каскадного планирования с переносом в зону гибких методологий. В рамках Планирования спринта осуществляется анализ задач текущего спринта, декомпозиция на атомарные задачи сотрудников. Более правильный подход, распределение задач – по желанию, когда член команды сам вызывается на решение задачи и определяет объем и сроки реализации. Если данные сроки и объем не соответствуют запланированным в каскадной части методологии, делается детальный разбор задачи с привлечение тимлидов. В ходе данного анализа либо меняется срок в гибкой части методологии, либо корректируется задача в каскадной части планирования. В данном процессе фиксируется плановые сроки и плановые трудозатраты по атомарным задачам.

Далее система управления максимально приближенная к Scrum методологии

Ежедневный Scrum, ежедневное планирование с командами, которое может быть на всю команду 15-30 минут, или разбито по крупным направлениям. У себя мы часто применяем разбиение, так как в нашей практике есть команды гораздо превышающие максимальное число команды по классической методологии Scrum. Мы используем команды от 6 до 25 человек за счет чего получаем экономию на управлении командой.

Разработка, аналитика, тестирование, регрессионное тестирования проводится в соответствии с запланированными задачами.

Для детального анализа плана/факта Проекта производится контроль списания трудозатрат по принципу 40 ч.ч. в неделю. Превышение фактически потраченного времени сотрудника фиксируется дополнительными часами только в том случае, если данные работы были согласованы с организацией. Данные работы оплачиваются по двойной ставке в соответствии с трудовым законодательством и увеличивают время, потраченное сотрудником на проекте. Данный учет позволяет контролировать реальные расходы проекта (деньги) и является входящим сигналом для корректировки модели управления рисками.

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

Сборка решения осуществляется как при подготовке релиза, так и в процессе разработки для показа результатов спринта, формирования тестовых версий в тестовом контуре, предпрод и продакшен. Процесс сборки, поставки решения осуществляется через стандартные процедуры DevOps.

Цикл пользовательского тестирования осуществляется в зоне каскадного планирования, так как Заказчик, как правило, живет вне гибкой методологии. В нашей практике есть проекты, Заказчик которых уже перешел в зону гибких методологий. Таким образом, гибридный подход затягивает Заказчиков на уровне исполнителей и руководителей локальных продуктов в новый современный подход управления проектами и повышает эффективность взаимодействия в проектах.

Если в ходе реализации Проекта возникают новые задачи или задачи меняются в связи с изменение бизнес требований, данные задачи оцениваются и согласуются с Бизнес заказчиков в режиме ежедневной работы команды. Большинство данных задач не превышают 10 ч.д.. Если в ходе реализации возникает более обширная задача, процесс уходив в ветку планирования спринтов или в целом перепланирование проекта в каскадной зоне.  Для гибкой и оперативной реакции на изменения у Бизнес заказчика должен быть предусмотрен дополнительный бюджет на изменения, о котором говорилось ранее.

Процесс планирования крупных задач всегда идет в зоне каскадного планирования.

Перенос на прод, и сдача функционала Заказчиком осуществляется в стандартной каскадной модели. В случае возникновения доработок, исправлений ошибок задачи дополняют Backlog и уходят зоны гибкой методологии, в которой учитываются в планировании работ следующего спринта.

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

Заключение

Данная методология позволяет решить ряд вопросов, и обеспечить гибкое управление проектами в организациях, неготовых к применению гибких методологий.

·         Сохраняется гибкость при ведении проектов, есть возможность оперативно пересматривать и изменять задачи проекта

·         У Заказчика сохраняется ощущения контроля, есть ориентиры в виде бюджетов и сроков

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

·          ИТ команда понимает цели Проекта и активно участвует в формировании направления его развития

Минус

·         Дополнительный административный и управленческий ресурс для сочетания двух противоположных методологий.