Сегодня мир управления проектами разделен на два лагеря: остроконечников и тупоконечников. Конечно, у нас не все так запущено, как у великого Джонатана Свифта. Но все же перед руководством любого проекта еще до начала работ всегда встает проблема: как разбить яйцо, с острого или тупого конца выбора программного обеспечения: основанного на классических или на современных гибких методиках. Выбор стоит именно так: либо одно, либо другое.
Иллюстрация: Alamy/PHOTAS
Рис. 1. Заседание руководства проектом Остроконечники и тупоконечники
Воспользуемся сравнительным анализом существующих методик управления проектами, изложенным в монографии Роберта Высоцкого «Адаптивное управление проектами: традиционные, гибкие и экстремальные методики». Седьмое издание этой книги не так давно стало доступным англоязычной аудитории. Насколько мне известно, она еще не переведена на русский язык. А жаль, книга замечательная, видимо не зря на американском Амазоне у нее 4ый рейтинг среди литературы по Аджайлу.
Прежде, чем пойдем дальше, хотел бы предупредить читателя, что в настоящей статье и в последующих будут рассматриваться только вопросы, связанные исключительно с фреймворком – теоретическими основами методик управления проектами. Никакие другие темы, в том числе и связанные с практическим применением этих методик, рассматриваться не будут.
Давайте начнем с классификации различных типов жизненных циклов проекта. Ниже приводится несколько упрощенная, по сравнению с приведенной в книге Высоцкого, сравнительная схема.
Рис. 2. Типы жизненных циклов проектов и методики управления
Как видно из рисунка 2, пять показанных на нем типов жизненного цикла проекта отличаются друг от друга возможностью (или невозможностью) в тот или иной момент «откатиться» назад, на одну из уже пройденных стадий проекта. Это свойство методики управления проектами вслед за Высоцким будем называть адаптивностью. Или, другими словами, адаптивность – это возможность предоставляемая методикой планирования и управления проектами вносить изменения в состав и план работ по проекту на различных стадиях жизненного его цикла.
Чем выше на схеме расположена модель жизненного цикла, тем большей адаптивностью обладает методика управления, на ней основанная. Так, например, методика экстремального управления, обладающая по Высоцкому максимальной адаптивностью, позволяет «откатиться» на самое начало жизненного цикла проекта и изменить многое, вплоть до самой цели проекта.
Еще раз, несколько изменяя классификацию Высоцкого, объедининим вышеприведенные типы жизненного цикла на две группы, выделенные на рис. 2 различными цветами:
— классические: то есть такие, при которых заранее полностью подготовленные иерархическая структура работ (далее – ИСР) и план проекта не изменяются в ходе выполнения работ. Может допускаться небольшой объем изменений, но, как написал Высоцкий, скорее как исключение, чем как правило,
— аджайл: гибкие современные методики, которые позволяют практически в любой момент «откатиться» сколь угодно назад. Делать это можно, в том числе, и периодически, в соответствии с заранее запланированными циклами. Нет необходимости предварительного полного задания ИСР.
Давайте теперь построим карту Лилипутии двухмерного мира методик управления с координатами: адаптивностью и сложностью проектов. На этой карте разместим оба лагеря остроконечников и тупоконечников сторонников классических и аджайл методов.
Сначала определимся в том, что будем подразумевать под сложностью проектов.
Под сложностью будем понимать не сколько общее число работ, сколько сложность структуры связей между работами, объединяющей отдельные работы в ИСР и проект. Собственно так и определяется проект: это не только совокупность работ, но и уникальная структура связей, объединяющие отдельные работы в проект.
Поясним понятие сложности проекта на схеме, приведенной на рисунке 3 ниже.
Рис. 3. Иерархическая система проекта
Самый простой проект можно адекватно описать, используя только два уровня из
рисунка 3: «Уровень 0» – собственно проект и «Уровень 1» – компоненты проекта. Если для описания проекта необходимо использовать иерархическую структуру, имеющую большее число уровней иерархии – проект сложный. Чем больше работ, связей и уровней иерархии – тем выше сложность проекта.
Теперь можем вернуться к нашей карте – она приведена на рис. 4.
Рис. 4. Методики управления проектами
На рисунке 4 мир методик управления проектами разделен на три прямоугольника различных цветов: зеленого, желтого и голубого, а также область белого цвета справа вверху.
Внутри прямоугольника зеленого цвета, представляющего собой область пересечения желтого и голубого прямоугольников, находятся самые простые проекты. Уверен, любой руководитель проекта с опытом практической работы согласится, что существуют проекты настолько простые, что для управления ими не имеет большого значения выбор методики. Здесь сработает все, и классика, и аджайл.
Прямоугольник желтого цвета – классические методы. Им доступно управление проектами довольно высокой сложности. Область применения классических методик ограничена сверху предельным уровнем адаптивности, о котором было упомянуто ранее со ссылкой на Высоцкого: ИСР и план проекта должны быть подготовлены до начала работ. Эта граница несколько размыта. Как было отмечено ранее, изменения ИСР и плана допускаются, но только как исключение.
В чем причина такого ограничения? Она проста: при создании или изменении ИСР и плана проекта связи между работами необходимо задавать вручную. Представьте себе, периодически, после каждого скрума, необходимо вручную переделывать все систему связей. За почти 120 лет после Карла Адамецкого ничего не изменилось. Только вместо карандаша человеку надо работать с компьютерной мышкой и клавиатурой. Откровенно говоря, это занудная и кропотливая работа. И источник человеческих ошибок, число которых нелинейно возрастает с увеличением сложности проекта. Следует заметить, что необходимость устанавливать связи вручную – это не только ограничение на гибкость классических методик, но и серьезный недостаток, который существенно осложняет управление сложными проектами даже в таких классических областях их применения как строительство и промышленность.
Небольшое историческая ремарка. Упомянутый в предыдущем абзаце выпускник Санкт-Петербургского практического технологического института Карл Адамецкий в 1896 году доложил на собрании Императорского Русского Технического Общества об изобретении им диаграммы, названной позднее именем Генри Гантта. И в этом же самом году Анри Беккерель открыл явление радиоактивности. За прошедший век ядерная физика и индустрия продвинулись довольно далеко вперед. А теория управления проектами? Мы по-прежнему, основную работу делаем по старинке, вручную. Замечательные достижения в UI и UX модных приложений и сервисов последних лет, имеющие сотни тысяч активных пользователей по всему миру, могут только приукрасить эту печальную действительность, но полностью скрыть ее не могут.
Итак, будем считать, что именно этот фактор: необходимость устанавливать связи вручную ограничивает область применения классических методик сверху, как показано рисунок.
Область применения гибких или аджайл методик — голубой прямоугольник на рисунке 4, тоже ограничена, но справа. Давайте попробуем ответить на вопрос: «Чем определено это ограничение, и где эта граница пересекает горизонтальную ось нашей системы координат?»
Очень подходящую для нашей цели формулировку в свое время дал Джоел Спольски в своем блоге: «… связи настолько очевидные, что нет смысла тратить силы на их формальное отслеживание» Немного обобщая, можно сказать, что слева от этой вертикальной линии допускаются простые проекты, содержащие только несложные системы связей и минимальное число уровней иерархии. Зато там нет ограничений на уровень адаптивности. Низкая сложность проектов или, как было отмечено выше, полное или почти полное отсутствие связей – это цена, заплаченная за обеспечение высокой адаптивности. И для 80% от общего числа проектов (в их числе и в разработке программного обеспечения), если верить количественной оценке Роберта Высоцкого, это сработало.
Вернемся к нашему рисунку, точнее, к загадочному белой области справа вверху. Может быть, самое интересное находится именно там, внутри белого прямоугольника? Уверен, что так. Это место для сложных проектов, при управления которыми не обойтись без гибких методик. Проекты разработки сложного программных комплексов находятся здесь. Также тут расположен инновационный hi-tech с его исключительно высокой мерой неопределенности. Естественно, здесь будут располагаться и проекты совместной разработки аппаратных и программных средств. И чем дальше мы будем продвигаться вдоль оси сложности вправо, тем более интересные, более инновационные и более дорогостоящие проекты мы там встретим. Полагаю, в эти оставшиеся 20% вкладывается существенно больше средств, чем в упомянутые выше 80%. И эта тенденция будет действовать еще не один год.
Итак, для того, чтобы комфортно путешествовать себя внутри белого прямоугольника, нужно уметь не только учитывать внутреннюю структуру проектов, но и научиться без труда, на лету, ее модифицировать. Это позволит управлять сложными проектами с любой степенью адаптивности.
Вы не можете до начала работ определить ИСР проекта? Не страшно, дорисуете недостающие компоненты по ходу выполнения. Вы хотите отказаться от части уже запланированных или даже выполненных компонент? Не беда, просто исключите их из ИСР. Хотите изменить последовательность разработки, изменив последовательность связей между компонентами ИСР? Пожалуйста. Вы хотите отказаться от предварительной оценки времени или трудозатрат? Не проблема.
И даже более того. А если вы не хотите или, может быть, не можете заранее ограничивать себя рамками одной конкретной методики управления? Не хотите заранее выбирать, с какого именно конца разбивать яйцо только один из пяти приведенных на рисунке 1 фреймворков? Вы не хотите тратить средства и время на покупку программного обеспечения, его внедрение и обучение сотрудников, чтобы позднее, уже в ходе выполнения проекта или, что еще хуже, после его окончания, понять, что выбор был ошибочен? И что сам проект мог бы закончиться совсем по-другому?
Если так, попробуем задать вопрос: возможен ли аналог Теории Великого Объединения в управлении проектами? Возможно ли в универсальном, едином, максимально гибком фреймворке объединить все пять различных типов развития проектов, показанных на рисунке 1?
Чем же должна быть обеспечена полная универсальность или максимальная гибкость применения единого фреймворка? Давайте попробуем для этого использовать автоматизацию установки связей. Посмотрим, можно ли передать эту работу от человека компьютеру и достигнем ли мы нашей цели этим путем.
Как читатель легко может предположить, у автора есть предложение о том, как это можно сделать. Но об этом в следующей статье.
Автор: thinkdo
