Два протокола управления проектами

http://habrahabr.ru/blogs/pm/86791/

Доброго времени суток.

Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом. 

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

Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.

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

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

Люди vs Винтики

В наши дни в ИТ проектах идет война между двумя идеологиями управления проектами — детерминантной и эмпирической. Детерминантные процессы подходят для хорошо прогнозируемых областей — таких, как строительство, железная дорога, заводской конвейер… Детерминантные процессы можно и необходимо планировать. Методики и инструменты для таких процессов развивались вместе с индустриальным капитализмом и принесли миру Гантт, PERT, Критический путь, WaterFall, CMMI аттестацию, несколько десятков видов прикладного менеджмента. 

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

Чем отличаются эти две идеологии? Детерминантный процесс строится на полном понимании глубинных процессов и на возможности их просчитать и спланировать. Люди — участники процесса — рассматриваются как винтики, работающие по определенной программе и правилам. В эмпирическом процессе мы осваиваем проблему вслепую — мы сегодня получаем фидбек от системы, которую строим, и используем эти данные для того, чтобы спланировать наш завтрашний шаг. Нету общего плана. Мы идем так быстро, как получается и не знаем, где мы будем в дальней перспективе. Люди в эмпирическом процессе являются главной движущей силой и инструментарий такого процесса призван оптимизировать индивидуальную и командную производительность участников. 

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

Какой подход лучше?

На этом этапе давайте сделаем привязку к конкретике управления проектами. В качестве примера детерминантного процесса будем рассматривать чистый WaterFall (Водопад), а в качестве примера эмпирического — Scrum (Скрам). 

На самом деле, ответ на поставленный вопрос — «какой подход лучше?» — прозвучит несколько неожиданно. Эти подходы нельзя сравнивать, поскольку они отвечают за различные контексты процесса разработки. Нет смысла выяснять что лучше — отвертка или молоток, нога или рука — это инструменты, созданные для определенной работы. Если представить детерминантный и эмпирический подходы в виде языка или протокола общения, то мы увидим, что оба языка необходимы для успешного ИТ проекта. Нам просто нужно научится эти протоколы между собой не смешивать и использовать в правильном контексте.

На языке Водопада идет начальное обсуждение проекта на уровне заказчика, аналитика, CEO, финансового менеджера. Они должны понять сколько денег и времени нужно потратить на проект. Очень редко встречаются проекты с «резиновым» бюджетом. В моей практике, например, первые движения в проекте происходят по традиционному детерминантному сценарию. Идет быстрый, предварительный сбор требований, добавляются риск-факторы и мы выходим на некий виртуально-глобальный план выполнения проекта, выходим на волшебные цифры X денег и Y дней. Таким образом, мы проходим 2 фазы Водопада — сбор требований и анализ, архитектурный дизайн и планирование. 

На следующем этапе мы переключаемся на язык Скрам. Во время запуска проекта был установлен финансовый лимит — а теперь, во время разработки, вовлеченные стороны (заказчик и программисты) пытаются сделать максимально полезную работу за эти деньги. При этом, каждые 2-3 недели (длительность итерации) состав фич (кусков функционала) может радикально меняться, а изначальный Большой План в общем игнорируется.

Скрам беспокоится о том, как наиболее эффективно решать сложные задачи с большим вкладом человеческого фактора и ему нет дела до Большого Плана. Интересно, что заказчику тоже более выгоден Скрам с его динамическим бэклогом (динамическим списком кусков функционала) и правилом 20/80. Получить функционал, тщательно подогнанный под бизнес и способный сразу приносить деньги — намного важнее формального чек-листа для прошлогоднего Большого Плана.

Интегрируем Водопад и Скрам.

В начале статьи я обещал рецепт совместного использования этих двух протоколов. Давайте попробуем все сказанное упорядочить…

Итак, проект разбиваем на 3 этапа:
— Мини-Водопад для оценки финансового лимита. 
— Скрам для разработки
— Согласовывающая последняя итерация.

На первом этапе мы создаем табличку со списком историй пользователя и оцениваем ее в контексте архитектуры, в которой будем реализовывать Систему. Далее, мы рисуем Гантт и моделируем выполнение проекта во времени при определенной конфигурации команды. Так мы выходим на финансовый лимит.

На втором этапе мы создаем бэклог продукта и приоритезируем истории пользователя в соответствии с предпочтениями заказчика. Причем, он (заказчик) волен менять набор этих историй как ему заблагорассудится. Разбиваем этот бэклог на итерации и выполняем их. Так мы продвигаемся вплоть до «стоп-отмашки». Стоп-отмашка — это событие, которое знаменует конец Скрам-общения и возврат к Водопаду. Определить «стоп-отмашку» могут такие факторы, как достижение финансового лимита или решение клиента (например — если его вполне устраивают достигнутые результаты и он хочет просто остановиться). 

Третий этап — это, по сути, особая итерация, где мы согласовываем набор кусков функционала одновременно и с заказчиком, и с Большим Планом. Здесь мы опять переключаемся на язык Водопада для того, чтобы сдать проект в формальных рамках самой первой оценки — то есть, на уровне топ менеджмента и финансов. Приведу пример… Пусть в Большом Плане мы брали обязательства реализовать фичи A, B и C. В ходе разработки клиент выкинул фичу С и ввел новые фичи — D и E. Дальше, пусть фичу А мы сдали на предыдущих итерациях, а фичу B мы не успели закончить (она имела низкий приоритет). Тогда, во время согласовывающей итерации, мы должны закончить В, а также, если оценка С меньше суммы оценок D и E, то заказчик должен доплатить разницу нашей фирме. 

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

Этот подход я взял на вооружение совсем недавно. На данный момент его мне удалось проверить только на одном проекте. Результат оказался положительным. Мне очень интересно услышать Ваше мнение, мысли и идеи по теме поста.

Спасибо за внимание и удачи!