В последней редакции Руководства к Своду знаний по управлению проектами (PMBOK) рекомендуется добавить в проекты гибкости. Если проектный менеджер захочет попробовать аджайл у себя в проекте, ему предстоит убедить Проектный офис и топ-менеджмент, чтобы ему дали право отойти от проектной методологии. Это сложно, трудоемко и неприятно. Есть другой путь — внедрить партизанский аджайл.
Консультанты пугают тем, что без изменения корпоративной культуры в организации, без поддержки высшего руководства у вас будет не аджайл, а сплошной карго-культ. Карго-культ — это механическое выполнение процессов без осознавания их сути и, как следствие, без существенной пользы.
Отчасти это правда. Но мы — проектные менеджеры, кое-что можем сделать самостоятельно, не привлекая топ-менеджмент и проектный офис. В конце концов, руководитель проекта — это CEO небольшого «стартапа». Мы отвечаем за успех, значит, имеем право действовать.
Кроме мифа об обязательном вовлечении «топов» есть еще несколько иллюзий на тему аджайла:
- Чтобы быть аджайл, все команды должны перейти на аджайл.
- Только команды, разрабатывающие программное обеспечение, могут быть аджайл.
- Аджайл означает отсутствие организации и документирования.
- Аджайл — это просто мода, которая скоро пройдет, а на смену аджайлу придет другая концепция.
- Аджайл работает, только если внедрить все, как написано в книжках. Иначе это не аджайл.
Все эти убеждения бесконечно далеки от истины. Да, мир стал другим — запутанным, сложным, быстро изменяющимся. Поэтому быть гибким сейчас становиться жизненной необходимостью. Но каждая организация идет своим путем к гибкости, нет единого правильного пути по определению самого понятия аджайл. Было бы странно, если бы была жесткая инструкция о том, как быть гибким. Это оксюморон какой-то.
Быть гибким — это, в первую очередь, разделять ценности:
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
Следовать этим ценностям можно и в классическом проекте. А если включить в проект несколько практик, то эффект будет еще лучше.
Создавать инкременты
В аджайл-командах принято разбивать конечный продукт на совокупность небольших частей — инкрементов, имеющих минимальную функциональность, но создающих ценность. Такой мини-продукт уже можно выпустить на рынок, и получить первые продажи. При традиционном подходе мы можем изготавливать продукт 1,5 года, ровно столько мы будем ждать первой реакции потребителей.
Нам, как руководителям проекта, никто не запрещает перераспределить пакеты работ иерархической структуры (ИСР, WBS) таким образом, чтобы команда создавала последовательно ряд инкрементов, каждый из которых потенциально может быть передан Заказчику. Это полностью в нашей власти. Так мы получим регулярную обратную связь и возможность улучшений продукта.
Ежедневно встречаться
В обычных проектах мы встречаемся раз в неделю или раз в месяц или по факту прохождения важной контрольной точки. А аджайл-ребята встречаются каждый день с утра.
Проектный менеджер тоже может собрать команду на 15 минут в день, чтобы узнать, как прошел вчерашний день, что планируется делать сегодня и какие есть трудности. Если есть конкретные вопросы к обсуждению, для них организуем отдельные встречи. Новизна только в такой утренней летучке. Она позволяет очень экономичным образом получить у команды единое понимание происходящего.
Чтобы внедрить ежедневные короткие встречи, нам опять же не нужно спрашивать разрешения. Да и команда легко согласится, потому что это позволит сократить длительность еженедельных статус-митингов, которые вряд ли кому нравятся. Причем, нам даже не обязательно признаваться, что это аджайл-практика. Пусть думают, что это наши менеджерские причуды.
Проводить обзоры и ретроспективы
В аджайл-командах после создания каждого инкремента проводят две специальные встречи — обзор и ретроспективу.
На обзоре команда передает готовый инкремент заказчику и конечным пользователям, чтобы те посмотрели на продукт, пощупали, опробовали его в работе. Так команда получает живую обратную связь и дополнительные идеи по улучшению продукта. Ни одно техническое задание, которые часто пишут в начале проекта, не даст такого уровня понимания, чего на самом деле хочет клиент.
На ретроспективу собирается только команда вместе с руководителем проекта. В аджайл-командах роли руководителя проекта нет, но сути это не меняет. Собираются только те, кто создают продукт. На ретроспективе команда обсуждает свою работу, предлагает идеи по улучшению взаимодействия, по улучшению коммуникацию, по устранению преград. Команда на лету перестраивает рабочий процесс, причем делает это после каждого инкремента. Любой проектный офис позавидует такой оперативности изменений в методах работы. Это вам не шесть месяцев согласований новых процедур.
После ретроспективы инкремент продукта может быть передан Заказчику, выпущен на рынок или над ним может быть продолжена работа, если возникли идеи по улучшению. В традиционных проектах ретроспективы если и проводятся, то в конце проекта, когда уже поздно что-то менять. Польза от таких финальных ретроспектив тоже есть, но она проявит себя только в последующих проектах.
Нам не нужно получать «добро» сверху, чтобы внедрить эти три практики. Опыт проектных менеджеров говорит о том, что как раз эти практики дают основной эффект к гибкости. Как видно, практики простые, не требуют серьезной подготовки и не требуют рассекречивания наших планов — внедрить аджайл так, чтобы никто не догадался. Давайте это делать!
