Гибкая разработка (Agile)

Два подхода к управлению проектами

Рассмотрим вторую интересную группу частных референтных моделей — модели проектного управления.

Классическое плановое управление

Большинство традиционных моделей управления проектами базируется на предположении, что проект необходимо тщательно спланировать, а затем выполнить. Типичный пример — системы вроде Microsoft Project: в них обязательно строятся диаграммы Ганта, планируются ресурсы, их загрузка, даты начала и окончания задач.

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

Влияние информационных технологий

Развитие ИТ породило совершенно иной взгляд на управление проектами. Его основой стали системы, которые называют багтрекерами (bug tracker) или системами управления задачами. В них на первый план выходит не прогнозирование, а умение быстро и оптимально распределять внезапно возникающие задачи среди участников так, чтобы суммарное время их решения было минимальным. Это сугубо реактивная система, которая не пытается предсказать, когда и в связи с чем появится следующая задача. Подобный подход характерен, например, для управления инцидентами в библиотеке ITIL (Information Technology Infrastructure Library) — там события происходят непредсказуемо, и главная цель — как можно быстрее обработать их имеющимися ресурсами.

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

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

Гибкие методологии: Scrum

На этой же идее базируются популярные в ИТ методы управления проектами, такие как Scrum. Процесс создания продукта в нём растягивается на неопределённый срок: он длится до тех пор, пока у заказчика не закончатся деньги, не пропадёт интерес или он не сочтёт, что дальнейшие улучшения не окупают затрат. Это гораздо более подвижная и адаптивная технология.

Краткие итоги

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

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

Именно этот разрыв между физической и информационной реальностью порождает реактивные системы управления. Багтрекер и подобные ему инструменты принципиально отказываются от календарного горизонта. Их цель — не предвидение, а минимизация времени реакции: непрерывная оптимизация очереди входящих задач под текущий состав и загрузку исполнителей. Такой подход уже институционализирован в ITIL как процесс управления инцидентами, где непредсказуемость событий заложена в саму модель.

Дальнейшим развитием этого мышления становятся гибкие методологии, наиболее ярким представителем которых выступает Scrum. Они доводят отказ от долгосрочного плана до логического завершения: проект превращается в перманентный поток коротких итераций без финальной точки, а его продолжительность и содержание регулируются не заранее утверждённым документом, а экономической целесообразностью, определяемой заказчиком по ходу дела. Практическая ценность такой трансформации проявляется в средах с высокой неопределённостью и низкой ценой изменений — то есть именно там, где информационный продукт доминирует, а стоимость переделки несоизмеримо ниже, чем в строительстве или машиностроении.

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