Гибкий водопад: гибрид Agile и Waterfall в проектном управлении. Часть 2

Руководитель корпоративных практик ALP Group Александр Казеннов отвечает на вопросы по устройству описанной ранее гибридной системы управления проектами и объясняет, почему эффективный менеджер не делает ни из одной методологии культа.

Предыстория: полгода назад я рассказал на VC про устройство гибридной цифровой системы Agile+Waterfall — мы придумали и разработали ее уже много лет назад для упрощения проектного управления в своей компании. Один из комментариев под материалом содержал в себе целый список уточняющих вопросов:

Владимир прав — развернутый ответ достоин отдельной статьи. А я наконец-то добрался до этой задачи в бэклоге! :)

1. Система без документации?

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

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

2. Быстрые релизы в масштабах всей страны?

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

3. Не ломают ли новые требования «водопад»?

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

О каком эффекте бабочки идет речь? Нередко бывает, что заказчик может прийти с запросом на добавление определенного признака в нужном ему документе. Формально, на его добавление уйдет минут 15. Вот только затем нужно будет подготовить для службы безопасности аналитическую записку в формате ЧТЗ. Потом может оказаться, что новый признак влияет на смежные системы, и тогда придется согласовывать его с ними, а затем выполнять параллельную или последовательную разработку, затем ее тестировать, затем опять дожидаться, пока безопасники проверят код и разрешат выпустить соответствующие релизы. Словом, одна маленькая доработка может породить кучу взаимодействий, которые необходимо выполнить для того, чтобы доработка вышла на продуктив.

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

4. Имеет ли заказчик шанс на итерационную переделку и эксперименты?

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

5. Как происходит синхронизация между командами, когда доработка требуется во многих местах?

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

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

В идеале, по мере накопления такого опыта взаимодействия вводятся четкие правила о том, каким образом мы меняем данные и метаданные для межсистемного взаимодействия, потому что во многих случаях доработки можно вносить, просто это требуется сделать таким образом, чтобы не «положить» все обмены и межсистемные взаимодействия и не ухудшить качество данных для смежных систем. Если определить набор правил, то дорабатывать свою систему можно спокойно, не дожидаясь от смежных систем вердикта и не ставя важную для бизнеса разработку на паузу, из-за которой потом придется «в пожаре» допиливать свою систему в последний момент (на рынке корпоративных разработок такое происходит довольно часто).

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

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

Отвечая на присланные вопросы, я задумался над тем, что мне не очень нравится всё время четко разграничивать Agile- и Waterfall-подходы и маркировать каждое управленческое решение как принадлежащее к инструментам той или иной методологии. Любой проект — и я сейчас даже не говорю конкретно о разработке — вообще всё, что мы делаем в жизни, мы делаем ради достижения какого-то результата, ради создания ценности. Этот результат может быть достигнут через какие-то шаги, последовательность действий — и вот у нас уже естественным образом возникает «водопад». А дальше в этой последовательности действий могут быть зоны неопределенности — элемент НИОКРа, который всегда решается через гибкие методологии, потому что это удобно. Тогда нам всего лишь нужно заложить риск НИОКРа в наш главный план-график, и действовать по нему. Ну а параллельно с этим, нам всем в принципе как команде полезно поддерживать обратную связь, чтобы четко понимать, что мы движемся к цели правильно, удобно и рационально — и тогда мы снова возвращаемся к инструментам оперативной взаимосвязи из гибких методологий.

В конце концов, для себя я пришел к пониманию, что в реальности не существует (или, по крайней мере, не должно существовать) разделения на Waterfall и Agile — это всё проектное управление, просто на разных стадиях проекта. Стадия инициации — это Waterfall. Стадия работы над проектом — это Agile с оглядкой на Waterfall. Нужно ли всё время проговаривать, на какую методологию мы опираемся в конкретный момент времени, — на мой взгляд, нет.

Владельцам бизнеса всё равно, делаются ли у них проекты по «водопаду» или по гибким методологиям, — им важно, чтобы нужные результаты достигались в заявленные сроки (а лучше раньше). Кажется, руководителям проектов тоже пора перестать мыслить по шаблону и цепляться за учебники с описанием методологий управления — реальный мир и реальные бизнес-задачи гораздо интереснее и сложнее.