- А как будет по-английски “фигак, фигак и в продакшн”?
- “Agile software development”
(народный фольклор)
Про методологию проектного управления последнее время говорят все больше и больше. Очень часто в собеседовании в компанию, занимающуюся внедрением, соискателя будут пристально допрашивать, читал ли он PMBOK, умеет ли он работать по Agile. Вокруг темы проектного управления можно услышать огромное количество терминов и понятий. Причем, очень часто разные люди в одни и те же слова вкладывают совершенно разный смысл. Примером возможных разночтений, на мой взгляд, можно как раз считать эпиграф в начале статьи. "Фигак, фигак - и в продакшн" - это, как мне кажется, как раз типичный пример Do & Fix, а вовсе не Agile. Лично у меня ясность по вопросу разных проектных подходов появилась после детального изучения Agile Practice Guide от Project Management Institute в рамках подготовки к экзамену на PMI Agile Certified Practicioner.
По моему опыту, универсального подхода к управлению проектами не существует. Оптимальный для каждой ситуации подход нужно подбирать отдельно, анализируя большое количество факторов. В первую очередь - степень определенности требований и степень определенности технических решений. Многим знакома ситуация, когда при первых же встречах с заказчиком выясняется, что он представляет конечный результат в формате "сделайте мне красиво" (на схеме: уровень неопределенности требований - высокий). Или когда заказчик четко рассказал свои хотелки после перехода на новый программный продукт, а вот исполнитель уже не очень представляет, как именно технически этот запрос реализовать (здесь уровень неопределенности требований - низкий, а уровень технической неопределенности - высокий).
Ниже я хочу рассказать подробнее о том, как можно классифицировать разные методологии в управлении проектами, и для каких ситуаций подходит каждый из них. Два слова о себе: PMP, выпускник Таллиннской школы менеджеров Владимира Тарасова, бизнес-тренер, консультант по управлению проектами. Приходилось руководить проектными офисами и командами в различных IT-компаниях, иногда проекты были крупные и серьезные, иногда - собранные на коленке. Указанное ниже - мой сугубо личный опыт, рада буду комментариям и точкам зрения. Отдельно поясню, почему здесь морские фото. Так как мое основное хобби - парусный яхтинг, как яхтенный капитан, при сравнении подходов буду пользоваться здесь метафорой яхтенного плавания.
Подход Do & Fix
“Что-то сделали, если получилось не то - исправили ошибки. Потом снова что-то сделали… и далее по кругу” На русский язык иногда переводят как подход “тяп-ляп”. По сути - отсутствие методологии.
- На что это похоже? Мы каким-то образом оказались в море на парусной яхте, на которой нет ни одного опытного члена экипажа. Налетел шквал, яхта начала крениться и черпать воду. Чтобы не потонуть, нужно что-то сделать!!! Мы начинаем случайным образом тянуть за различные веревочки и крутить штурвал, и (если повезет и не затонем раньше), в конце концов нам удается снять нагрузку с парусов и повернуть к берегу...
- Как это выглядит в реальной жизни? К сожалению, когда команда не задумывается о применяемых методах, а действует по принципу “вижу проблему - решаю проблему”, чаще всего это и есть подход “do & fix”. Удовлетворение запросов пользователей без стратегического плана приводит к тому, что мы получаем конфигурацию, работающую в формате “что выросло, то выросло”...
- Когда подход может быть полезным? Когда у нас недостаточно компетенций и сведений для составления плана работы (и нет возможности это исправить), а что-то предпринимать нужно. Фактически, в ситуации полного хаоса - это единственное, что мы можем сделать… В моей практике такой подход был оправдан для решения "пожарных" задач в "эпоху перемен" - когда составление стратегического плана нововведений по каким-то причинам отложено, а работать нужно здесь и сейчас, и решения "на коленке" оказываются лучше комплексного планирования.
Каскадный подход или Waterfall (водопад)
Мы составляем четкий план и по нему действуем. Сначала собираем требования всей системы, потом определяем архитектуру, потом разрабатываем отдельные части, интегрируем, тестируем, внедряем.
- На что это похоже? В ходе подготовки к плаванию мы изучили лоцию, проанализировали долговременный прогноз погоды, уточнили компетенции экипажа. После чего составили и записали четкий маршрут, включая дату и место прибытия, промежуточные точки, расписание вахт, меню для кока и т. п. План действий записан в бортовой журнал и не подлежит изменениям.
- Как это выглядит в реальной жизни? Мы проходим с заказчиком весь путь от начала и до конца. Коммерческое предложение, определение концепции (верхнеуровневые бизнес-требования), детализация требований, технический проект, выполнение работ, проведение приемо-сдаточных испытаний, закрывающие акты. Все изменения в контракт - строго по доп.соглашениям.
- Когда такой подход может быть полезным? На самом деле, водопад - самый простой и надежный способ управления проектами. И он удобнее всего - с одним-единственным (и очень суровым) ограничением - когда мы можем в начале проекта четко понять требования и технологии реализации. Как выражаются матерые сотрудники крупных корпораций, где водопад часто неизбежен, “если у вас водопад, вам потребуются хорошие юристы, чтобы в конце доказать заказчику, что вы ему ничего не должны”... В моей практике водопад чаще всего оказывался неизбежным при тендерах с государственными или крупными заказчиками - подробный план составляется еще до подписания контракта, и отклонения от него (по-крайней мере, формально) считаются недопустимыми.
Следующим блоком идут адаптивные подходы. “Недоводопад, недоэджайл”. Даже догматичные авторы PMBOK начиная с 3-ьего издания (а нынче издано 6-ое) уже поняли, что каскадный метод управления проектами слишком консервативен. На практике не очень осмысленно на старте спланировать проект от начала и до конца - планирование лучше вести по кусочкам.
Итеративный подход
От слова “итерация” - повторение. Мы планируем так называемым “методом набегающей волны” - ближайшие события планируются подробно, более далекие - приблизительно. То есть мы готовы уточнять и корректировать планы по ходу проекта.
- На что это похоже? Как и в прошлый раз, в ходе подготовки к плаванию мы изучили всю необходимую информацию, определили ориентировочную дату и место прибытия. Но план составлен не столь подробно, скорее приблизительно. По ходу путешествия мы будем повторять процесс планирования, и корректировать изначальный план по ситуации - как изменится прогноз погоды, как поведет себя экипаж, как будет выглядеть навигационная обстановка на месте.
- Как это выглядит в реальной жизни? Мы стараемся заключить контракт в достаточно мягких формулировках, понимая только наиболее верхнеуровневые требования. Более точное техническое задание составляется уже по ходу работы.
- Когда такой подход может быть полезным? Итеративный подход находит свое применение существенно чаще, чем каскадный, и помогает преодолеть многие ограничения водопада - ибо в начале проекта заказчик чаще всего не может подробно описать требуемый функционал. Типичной иллюстрацией итеративного подхода являются прототипы - когда, к примеру, поставщик не пытается сразу разработать и внедрить ERP-систему целиком, а сначала простраивает какой-то один ключевой бизнес-процесс и дает заказчику с ним "поиграться".
Инкрементальный подход
От слова “инкремент” - промежуточный результат. Мы едим слона по кусочкам. Разбиваем наш проект на несколько небольших поставок, и отдельно планируем каждую из них.
- На что это похоже? Как и при работе по “водопаду”, мы составляем подробный и детальный план, отклонения от которого не предполагаются. Но - только на ближайшую часть плавания. Все остальное - включая время и место назначения следующего этапа, мы будем обдумывать, когда первая часть плавания завершится.
- Как это выглядит в реальной жизни? Главный признак инкрементального подхода - не одна финальная поставка, серия небольших. Чаще всего каждая поставка сопровождается отдельным контрактом или доп.соглашением. Результат, как правило, в большей степени устраивает клиента, чем при водопаде, но уверенности в завтрашнем дне и у исполнителя, и у заказчика может быть меньше. Исполнителю никто не обещал подписание следующего контракта, а заказчик может опасаться, что исполнитель “сольется” где-то в середине процесса. Впрочем, если исполнитель пропадет посередине большого проекта, управляемого “по водопаду”, то заказчик окажется в еще худшем положении…
- Когда такой подход может быть полезным? Особенно важно заключать контракты на куски работ, когда у нас нет четкого понимания, какие именно функции являются обязательными для проекта и уверенности в том, что проект будет завершен.
Гибкие методы управления проектами (Agile)
Мы соединяем оба принципа предыдущих подходов: планируем, во-первых, инкрементально, во-вторых итеративно.
- На что это похоже? В начале плавания мы можем не иметь определенности по многим пунктам. Например, мы можем знать точку назначения, но не знать, когда мы туда прибудем. Или знать дату окончания плавания, но не иметь определенности, куда мы приплывем. Из этого не следует, что мы “плывем куда глаза глядят”, как в первом случае - на каждом этапе плавания мы составляем план, при необходимости его корректируем. И в конце каждого этапа оцениваем, куда же мы приплыли, и как нам дальше управлять яхтой лучше…
- Как это выглядит в реальной жизни? Для того, чтобы гибкие методы были применимы в проектах внедрения, нужно, чтобы и заказчик и исполнитель были готовы к работе в условиях отсутствия детализированных требований в контракте. Заказчик на старте описывает требуемый результат, а дальше конкретные функции и механизмы детализируются уже по ходу проекта.
- Когда такой подход может быть полезным? Важные ограничения гибких методов - готовность всех сторон к их использованию. Важно наличие базового доверия между заказчиком и исполнителем, важна готовность заказчика деятельно участвовать в ходе проекта (с чем на практике бывают серьезные проблемы), важен профессионализм и дисциплина команды исполнителей. Важно не скатываться в подход “Do & Fix” - то есть постоянно сверяться с генеральным направлением и стремиться корректировать результаты от итерации к итерации.
Ниже привожу табличку, где можно наглядно увидеть, в чем отличия и преимущества каждого из описанных подходов.
Практический совет - поймите, каковы ваши граничные условия, что для вас является главной целью - и вам станет проще понять, какой подход применять разумнее. И, главное, помните, что “чистые” подходы встречаются чаще всего только в красиво оформленных учебниках, а в жизни мы применяем те или иные гибридные формы. Удачи в управлении проектами!
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
