Контроль в традиционном проектном менеджменте vs контроль в Agile

Когда слышишь слово «контроль», в голове сразу всплывает образ сурового менеджера, который поминутно записывает, кто и чем занимается на работе. Только это не контроль, а банальный микроменеджмент.  

Настоящий контроль в другом. Он необходим для сверки факта с изначально намеченным планом. Всё ли идёт как надо? Есть ли еще время? Что с бюджетом? Давать согласие на внесение правок или нет? В поиске правильного, а не интуитивного, ответа на эти вопросы помогут различные инструменты и практики контроля, о которых расскажем в статье. 

Также разберёмся, в чём различия в подходах к контролю между традиционным проектным менеджментом и Agile; что, как и зачем в них контролируется.

Для начала давайте определим, что подразумевается под «традиционным подходом к проджект менеджменту».

Это подход к управлению жизненным циклом проекта, у которого есть базовый план (бейзлайн). Он, конечно, может меняться благодаря процессу управления изменениями, но важно то, что на старте уже есть полноценный список работ, которые необходимо провести. 

С чего начинается контроль 

Театр начинается с вешалки, а выбор подхода к контролю проекта — с определения цели этого контроля. Для этого сторонники традиционного метода задаются вопросом «Как контролировать». Эджайлисты же предпочитают начинать с «Зачем контролировать?» В этом и есть основное отличие. 

Вспомним геометрию — поговорим о треугольниках

Если бы был конкурс треугольников, то в категории «Любимый треугольник PM-ов» выиграл бы трёхсторонний товарищ «стоимость-расписание-содержание». 

Этот треугольник — база традиционного проджект менеджмента, но Agile-методологии отнюдь не отрицают его значимости. Просто эджайлисты по-другому его интерпретируют. Сравните:

Проджект менеджер — это именно тот человек, под контролем которого находятся три составляющие треугольника. Обязанности Agile PM-а —  не только контролировать объём работы, но и корректировать, если это нужно. Зачем? Для принятия адекватных решений с целью «дотащить» всё то, что было придумано изначально с наибольшей value для пользователя.

Как контролировать содержание

О треугольнике немного поговорили выше. Пришло время разобраться с его сущностями. Начнем с содержания, которое определяет суть проекта. 

Основные принципы контроля содержания в традиционном проектном менеджменте

1. Сделана ВСЯ работа и ТОЛЬКО та, что требовалась. Казалось бы, логично? Но часто у команды чешутся руки сделать какую-нибудь фичу, о которой заказчик не просил. Тут добрые намерения могут сыграть злую шутку в виде переработок и непредвиденных трат, что явно не порадует клиента. Задача PM-а не допускать того, что выходит за рамки оговоренного. «Вау-эффект» уместен в разовых продажах, в обычной проектной работе — даже не думайте. Если у вас нет цели взять все дополнительные расходы на себя, чтобы поразить клиента и поднять его лояльность, избегайте «голд-плейтинга».
2.  Сделанная работа соответствует ожиданиям. Проект делается для клиента. Поэтому важно попасть в оговоренные ожидания. Чтобы их очертить, PM-у нужно произвести ряд несложных, но полезных действий:
   • четко сформулировать ожидания от конечного результата проекта или конкретного блока задач;
   • преобразовывать ожидания клиента в требования для команды;
   • проделать необходимые действия по управлению этими ожиданиями.
3. Получение формального принятия работы. Другими словами — оплата труда. Иначе зачем всё это? Клиент подтверждает завершение проекта, когда переводит деньги на счет компании. 
4. Обеспечение контроля изменений. На изменения нужно реагировать вовремя, а то и раньше. Не нужно их подгонять под категории «хорошо»/«плохо». Изменения — они просто случаются. Это нужно принять. Где-то достаточно просто знать «да, такое бывает», реагировать вовремя и идти дальше, а где-то — менять целые процессы. 
5. Отслеживание уровня сплоченности команды. Если члены команды будут себя вести в проекте, как герои басни про Лебедя, Рака и Щуку, дела не будет. Точнее какое-то дело будет, но успешно реализованного проекта — нет.

Что отслеживается в Agile в рамках контроля содержания? 

1. Количество работы (сделанной и оставшейся). Рекомендуем отслеживать эту метрику по командам, релизам, проектам. В этом поможет диаграмма burn down chart.                                       
   

   Burn down chart (диаграмма сгорания задач) — диаграмма, которая показывает количество сделанных и оставшихся задач за определенный спринт или за проект в целом. С помощью этого чарта можно отслеживать эффективность команды и соответствие срокам спринта или проекта.

2. Количество и приоритетность дефектов, продуцируемых командой. Смотрим на то, насколько дефекты критичны и как они влияют на ценность, которая доносится командой
3. Velocity. Все знают (а если нет, то словарь не даст соврать), что velocity — это скорость. В разрезе проджект менеджмента — это показатель объема работы, который команда может выполнить за один спринт. 
4. Показатель улучшение Velocity. Той самой, о которой говорили выше.
5. Стабильность команды. Это не о постоянстве её состава. Это о том, что внимание команды не должно распыляться на сторонние факторы, мешающие работе над проектом. Поэтому работа на 10+ других проектах в Agile не приветствуется!
6. Забота о беклоге. Он любит, чтобы с задач, которые лежат там неделями, а то и месяцами, смахивали пыль. Если они там так долго, то скорее всего утратили свою актуальность. Возможно их стоит убрать?
7. Inflow к outflow. «С» значит стабильность. В нашем случае стабильность соотношения поставленных задач к выполненным. Если количество inflow задач намного больше по отношению к outflow, возможно команда физически не успевает? Если outflow задачи превышают inflow, то есть опасение, что скоро команда закончит всё раньше времени и будет прохлаждаться. Между тем, что ставится команде и тем, что решается, должен быть баланс. Если его нет, то это звоночек.

Как контролировать бюджет и сроки

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

Математическая точность в традиционном подходе

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

Контроль нужен для гарантии того, что проект будет выполнен в рамках утвержденного бюджета и сроков. Для того, чтобы его обеспечить, нужно отслеживать затраты и сроки на разных фазах проекта. Если прибегать к просчету уже в финале, толку не будет. Что можно сделать с тем, что уже почти просрочено или потрачено? 

Если же периодически отслеживать освоенный объем работ относительно планового или, скажем, индекс эффективности расходования средств в проекте, то с «Хьюстон, у нас проблемы!» можно справиться намного быстрее и с меньшими потерями. 

Для вашего удобства мы собрали самые нужные и готовы ими поделиться бесплатно.

Запасное время изначально закладывается в расписание проекта на случай реализации рисков. Это позволяет меньше стрессовать команде. А что поможет меньше стрессовать PM-у? Уверенность, что проект соответствует срокам на каждом из его этапов. В этом очень помогает диаграмма Ганта.

Диаграмма Ганта — столбчатый график, отражающий запланированные задачи к срокам.  

Что с математическим подходом в Agile?

Всё просто — его нет. В Agile-проектах количество членов команды устаканенное. Каждый из сотрудников задействован на 100% (Помните? Он не распыляется на другие проекты, вся продуктивность идёт только на один). Поэтому стоимость рабочего дня фиксирована. Дни составляют спринты, а спринты составляют общий срок проекта. Путём несложных математических вычислений, с которыми справится даже Петя из 4-Б, можно рассчитать бюджет. 

Расписание контролируется благодаря burn down chart. На нём удобно отслеживать количество стори поинтов, «сожжённых» за определенный период. 

Как контролировать документацию

Если на чашу весов положить продукт и документацию к нему, продукт перевесит в силу приоритетности. Услышав эту часть высказывания и эджайлисты, и PM, работающие в традиционном проектном менеджменте, одобрительно кивнут. Только вторые добавят: «Тем не менее документация тоже важна!»

Как многие не начинают утро без кофе, так и PM-ы, работающие в традиционном подходе, не начинают каждую из фаз проекта без нужной документации. Какие-то документы не изменяются (например, устав), а какие-то требуют постоянной актуализации (например, план). В документации можно найти правду и точность. На неё можно сослаться в спорных моментах. У заказчика 14 пятниц на неделе (даже не 7) и он доказывает, что кнопку нужно было сделать синей, а не красной. Тут PM со спокойствием удава открывает документацию, убеждается сам и убеждает заказчика в том, что цвет всё-таки был красный. После этого с сохраненными нервами и временем отправляется дальше контролировать команду.

Одна из ценностей Agile — «рабочее ПО превыше всеобъемлющей документации». Значит ли это, что эджайлисты ушли от документации вовсе? Нет. Это значит другое. К её составлению нужно подходить с умом. Нужно поберечь бумагу и место на облачном пространстве. Документация нужна тогда, когда актуальна. Просто «чтоб было» не подходит. Она создается только под определенные задачи и когда без неё не обойтись. 

Пару слов о контроле плана проекта

План — один из самых важных документов для того, чтобы понять, туда ли вообще катится машина под названием «Проект». Наверное, самое очевидное в процессе сверки с планом — это обязательное наличие плана. Какой план полезнее в работе: тот, что включает в себя 1326 пункта обо всём на свете и немного больше или тот, в котором собрано минимальное нужное количество пунктов для контроля проекта? *Играет музыка из «Что? Где? Когда?»*

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

Как контролировать риски

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

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

В Agile рассмотрение и контроль рисков идёт неотрывно от работы. Проработка рисков встроена в процессы (например, в митинги). Таким образом, работа с рисками в Agile происходит:

• чаще;
• вне отрыва от обсуждения и выполнения целей спринт.

Как контролировать и управлять изменениями без вреда для проекта

Всё еще не можете выбрать правильную тактику? Мечетесь между постоянными «да» на просьбу клиента внести уже десятое за эту неделю изменение в проект и вечными «нет» и так уже отчаявшемуся заказчику? Тогда мы идём к вам с полезной информацией!

Интегрированный контроль изменениями

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

Грамотное следование Agile-фреймворку при работе с изменениями

В Agile что-то постоянно меняется. Изначально определяем цель проекта таким образом, чтобы большинство изменений отметать ещё до того, как проект будет запущен в работу. Если изменение не соответствует цели проекта — адьос. В Agile формулировка «change request» отсутствует как таковая. Проект контролируется на нескольких уровнях:

• собственно проект в стадии разработки;
• релиз;
• итерация.

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

• обсудить готовность создавать/принимать проект небольшими порциями;
• продумать план коммуникации (как с командой, так и с заказчиком);
• обсудить готовность к изменениям;
• провести оценку рисков, в том числе и рисков инициативы, исходящей от вас как от PM-а;
• убедиться в наличии сильной спонсорской поддержки.

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

Как контролировать каждого человека по отдельности

Никак. Это не входит в обязанности PM-а. Он контролирует взаимоотношения в команде, сплоченность, понимание распределения задач между всеми членами. Кто сколько чашек кофе выпил на рабочем месте — это не область знания PM-а. 

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

Дело не в только в человеколюбии гибких подходов, но и в том, что если «выйдет из строя» хотя бы один болтик в этой большой машине под названием «проект», то пострадают все. PM заинтересован в том, чтобы понять, что мешает конкретному человеку в достижении цели; достаточно ли мотивирована команда; какие сильные стороны участников проекта. Хороший человек всё-таки этот PM!

Last but not least

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

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

Смеем предположить, что управлять проектами вы уже умеете (раз вы здесь, читаете эту статью). Надеемся, что теперь стало понятнее, что и как в них контролировать. И что при слове «контроль» теперь не бросает в холодный пот. Что еще нужно делать в проектах помимо контроля можно узнать на курсе PM Hard Skills: Release.