Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).

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

За время доклада мы рассмотрим основные вехи развития подходов к управлению ИТ-проектами и эволюцию критериев качества ПО в мире и в России, которая в 90-х годах шла своим путем, но за последнее время приблизилась к общим трендам.

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

Моды ведения проектов - исторический обзор

1. Исторически ИТ-разработка выросла из норм ведения НИОКР, к которым термин "услуга" применим в значительной степени условно. Ситуация изменилась с появлением персональных компьютеров, достаточно мощных для автоматизации предприятий, которые сделали востребованной осуществление этой автоматизации как услугу. Оказание этой услуги методами НИОКР оказалось невозможным из-за кадрового голода: формат НИОКР предполагает достаточно квалифицированный персонал, которого в необходимых объемах просто не существовала. Первый подход к решению этой задачи заключался в нормировании процессов.
2. На первую половину 2000-х нормой оказания ИТ-услуги является ведение проекта по разработке (внедрению) ИТ-системы, которую необходимо спроектировать, а затем изготовить и внедрить с заданными критериями качества. Этот подход зафиксирован в PMBOK 3 версии (2004), на него же ориентирован RUP (2003). При этом упор делался на правильную организацию и надлежащее исполнение процессов. Далее я буду это называть "классическим подходом".
3. Проекты, не смотря на тяжелые процессы, не приводили к результату. Проблемы касались качественного планирования и проектирования, которое разбивалось об изменчивость мира. На уровне стандарта (PMBOK) было зафиксировано, что даже тщательное исполнение процессов и реализация в соответствии не дает гарантии достижения целей проекта.
4. Как ответ на вызов - появился Agile и SСRUM внутри него.
   1. SСRUM во главу угла поставил наблюдение за движением по проектной траектории. При этом было сформулировано, что задачу планирования решать бесполезно, надо определить цель и мерить до нее расстояние. А двигаться - итерациями, корректируя план.
   2. Нормировка качественного проекта изменилась, теперь в основу ставят адекватность оценки расстояния до цели и соответствие продвижения в итерацию предварительным оценкам. Для целей мониторинга движения к цели в отрасль втянута концепция SMART-целей, характеризующихся, в частности, измеримостью (Measurable). Сама концепция была известна в менеджменте с 60-х, приписывается то ли Друкеру (английская вики), то ли другим основателям.
   3. SCRUM позволил существенно снизить планку требований к младшему управленческому персоналу в ИТ с сохранением приемлемого уровня исполнения проектов, чем и объясняется его успех.
   4. После успеха SCRUM в отрасли итерационность разработки попробовали заложить в PMBOK 4 версии (2008), но по факту получилась эклектика. Там же попробовали нормировать проектирование (аналитическую работу), но через организацию процессов это тоже не получилось. Отмечу, что в RUP итерационность была изначально, а в другом стандарте, SWEBOK появилась в версии 3 (2004), однако там по факту речь шла о тяжелых итерациях, которые не возможно прокрутить быстро, как того требовал Agile. Таким образом, в стандарте уровня отрасли нормы Agile проявлены не были.
5. Это путь развития в масштабе мира. В России на этот тренд накладываются события 90-х, в результате которых обеспеченность ИТ-отрасли квалифицированными кадрами, вышедшими из науки и способными оказывать ИТ-услугу методами НИОКР была существенно выше, чем в мире. В результате использование процессного нормирования оказалось существенно менее выражено. В настоящее время эффект в значительной степени размыт, и отличие России от всего мира - нивелируется.

Современное состояние и вектора развития

1. Agile и SCRUM сдвинули норму оказания отрасли от проектной деятельности к непрерывной, процессной. Такую организацию можно применять не только для начальной разработки или существенному реинжинирингу, но и к текущему развитию и доработке систем. Следующим шагом на пути в этом направлении стал ИТ-вариант Kanban-процесса. Это примерно 2010. Дальнейшее развитие этого сдвига - тренд DevOps.
2. Ортогональная сдвижка, произошедшая в отрасли примерно в то же время - смещение фокуса от качества ИТ-системы (во всех смыслах, включая функционирование) к удовлетворенности стейкхолдеров проекта. Это смещение отчасти отразилось в PMBOK 5 версии (2013).
3. Еще одно направление сдвижки - фокус на достижение возможностей для бизнеса, которые должны обеспечить ИТ. Эта сдвижка видна преимущественно в стартап-проектах и в продуктовой разработке, особенно в производстве игр. Сдвиг произошел после 2010.
4. Произошедшие сдвижки нормирования зафиксированы в The Essence of Software Engineering, выдвинутой SEMAT и принимаемый сейчас OMG (beta1 - july 2013, beta2 - may 2014). В процессе работы из стандарта тщательно вычищали слово "проект", обеспечивая применимость на всех стадиях жизненного цикла. А в основные альфы включены стейкхолдеры, с которыми идет работа и возможности для бизнеса, которые желают получить.
5. Проблема правильного проектирования систем и нормировки в этом поле не решена в отрасли по-прежнему. Лучшее известное мне решение для процесса управления проектом - FDD (Джефф де Люка), а для способа разработки проекта - DDD (Эрик Эванс)

BigPicture методов ведения проектов

Историческая картина есть. Можно применять на практике? Нет, сначала нужно положить это на схемы, сделать Big Picture, на которых можно об этом рассуждать.

1. Эпохи в историческом развитии - самый простой способ. Но лишь показывает историю, а не дает возможность конструирования своего.
2. Вектора развития. Все они сохраняют актуальность, так как следующий этап - дополняет и расширяет предыдущий. Похожая, но отличающаяся картина - Энтони Лаудер "Культуры программных проектов".
3. История развитие как смещение фокусов внимания на схеме OMG Essence.
4. Изменения на V-диаграмме: ИТ-проект как интегрированная часть бизнес-проекта, раньше их рассматривали достаточно изолировано.

Применение на практике

1. На уровне проекта. Понимать, в чем фишка проекта.
2. На уровне компании. Что компания делает для мира и каким образом. Примеры различных концептов компаний.
3. Как с этим работать практически и для чего оно нужно.