«План ничто, планирование — всё...» — Дуайт Эйзенхауэр, 34-й президент США
В данной статье поговорим о методах планирования работ и их особенностях. Статья не претендует на полноту или управленческую новизну, это просто мнение «пессимиста» на основании собственного опыта в консалтинговых проектах.
Планировать или нет?
Американский писатель Артур Блох в книге «Полное собрание законов Мёрфи», написал отличную фразу: «Всё намного сложнее, чем кажется на первый взгляд». Те, кто управлял проектами знают, что в управлении один из ключевых навыков — это опыт.
Уровень неопределенности, который вы можете встретить в проекте у нового заказчика часто тяжело предусмотреть до тех пор, пока на окажетесь в самом проекте. На практике я встречал случаи, когда отклонение фактических трудозатрат от плановых было в десять раз, и как вы догадались не в меньшую сторону.
Для того что бы повысить точность планирования проектов в консалтинге мы тестировали разные способы оценки трудозатрат, пробовали и экспертные оценки, и оценки по параметрам, и детализацию работ до уровня небольших задач, которые проще оценить. Однако, это не сильно приближало нас к качественному результату, пока мы не накопили опыт проектов и не смогли от собранного факта нормировать трудозатраты на свои работы. Но даже в рамках нормирования у нас появилась куча параметров, влияющих на трудозатраты (конфликтность заказчика, опытность команды, особенности предметной области и так далее, и тому подобное). Как часто говорят ИТ‑архитекторы: «Все зависит от контекста». Если задача типовая, и уже выполнялась, то оценка с определенной степенью точности возможна, если что‑то новое, то нет, можно даже не пытаться.
Вспоминается звонок руководителя организации, который запросил коммерческое предложение на работы по описанию, оптимизации и регламентации всех процессов своей немалой организации на дальнем сервере России, при этом, на уточняющие вопросы, сколько у вас процессов и какие должны попасть в объем проекта, а также какой результат проекта необходим я не получал ответа, при этом потенциальный заказчик требовал оценку всех работ прямо сейчас, не соглашаясь на поэтапное контрактование в проекте.
Кстати практика работы зарубежных консультантов была иная, и если в России большинство консалтинговых компаний контрактовалось за фиксированную цену, закрепляя объем работ в техническом задании, которое становилось приложением к договору, то наши европейские коллеги предпочитали оплату по фактической выработке по листам учета, обработанного консультантами рабочего времени.
Что делать, если нужно работать за фиксированную цену
В свое время, пройдя обучение по PMBOK, я понял, что в библиотеке описан идеальный мир: спланировал затраты, заложил запасы сроков и трудозатрат по рискам, показал план проекта заказчику и поехали. Однако, на практике часто приходилось вести себя по‑другому, опытный руководитель проекта как «хомяк» прячет в план проекта запасы трудозатрат, при чем не дай бог показать заказчику эти запасы, по опыту заказчик сразу попытается их забрать под новые требования, а когда реализуются риски, на которые закладывались трудозатраты, он разведет руками и скажет, что это не его проблема.
В некоторых организациях руководители проектов имели три плана: один для заказчика, второй для своего руководства и третий для себя, тогда еще есть шансы довести проект до конца, если конечно он изначально не «завальный». При этом наиболее хорошее место для хранения запасов — это самые сложные участки работ, если где‑то разрабатывался программный код, то это отличное место для размещения запаса.
На практике был пример, когда в проекте была «серая» область в части работ, при этом никто у заказчика не мог уточнить требования, а жесткость договора требовала, чтобы этот объем был в проекте. Решение было непростое, но несмотря на серьёзную сумму, мы отказались от проекта, и с ужасом наблюдали как наш конкурент, с радостью вошедший в проект, получил из серой зоны дополнительный объем фактически неоплачиваемых работ, сравнимый со объемом всего проекта. Вывод тут простой, если риски велики, и вы ими не управляете, лучше оставить эту «смоляную» яму другому.
А что в теории?
Надеюсь большинству известны библиотеки PMBOK и BABOK, которые содержат несколько методов, которые можно использовать при оценке трудозатрат. В качестве примера заглянем в BABOK:
· Сверху‑вниз: рассмотрение компонентов, начиная с верхнего уровня иерархической декомпозиции.
· Снизу‑вверх: использование элементов самого нижнего уровня иерархической декомпозиции для детального рассмотрения и индивидуальной оценки стоимости или трудозатрат, а затем суммирование всех элементов для общей оценки.
· Параметрическая оценка: использование откалиброванной параметрической модели атрибутов оцениваемых элементов.
· Грубая прикидка: высокоуровневая оценка, обычно основанная на ограниченной информации, которая может иметь очень широкий доверительный интервал.
· Бегущая волна: повторяющееся в ходе инициативы или проекта оценивание, дающее детальные оценки краткосрочной деятельности (таких как итерация работы) с экстраполяцией на оставшуюся часть инициативы или проекта.
· Метод Дельфи: использует комбинацию экспертных оценок и истории.
· Метод PERT: каждому компоненту оценки дается три значения: (1) — оптимистичное, представляющее наилучший сценарий, (2) — пессимистичное, представляющее наихудший сценарий, (3) — наиболее вероятное. После этого, значение PERT для каждого компонента вычисляется как взвешенное среднее: (Оптимистичное + Пессимистичное + (4 х Наиболее вероятное))/6.
В моей практике большую точность давал метод параметрической оценки, правда нужно было убедить заказчика зафиксировать в договоре количество объектов (моделей процессов, интервью, подразделений) на основании которых мы оценивали трудозатраты проекта, что не всегда удавалось.
Ключевой развилкой в части планирования работ являются: уровень неопределённости в проекте, возможность изменения требований на входе и компетенции проектной команды. Если неопределённость высока, требования на входе изменяются, а команда не имеет экспертного опыта в предметной области и применяемых технологиях, то планировать бесполезно.
Именно с этим часто связана проблема управления ИТ‑проектами по водопаду в том, что невозможно спланировать с приемлемым качеством работы связанные со сложными технологиями, в условиях, когда вводные требования к продукту постоянно меняются. И тут можно вспомнить очередной закон Мерфи — «Если что‑то может пойти не так — оно пойдет не так».
Хорошо, если можно работать по Agile
Agile дал возможность не тратить ��ремя на планирование, а идти небольшими спринтами, планируя лишь то, что может быть спланировано, что сильно упростило работу для многих команд, которые смогли убедить заказчиков перейти на данный подход.
Но даже в Agile часто непросто спланировать бэклог работ на ближайший спринт, потому что не всегда понятно сколько времени займет та или иная работа и начинаются опять различные варианты экспертных оценок, например, Poker Game или аналогичные способы.
В качестве примера, вспоминается недавний проект, в котором нужно было собрать автоматизацию на базе workflow‑движка и нескольких AI‑агентов, при этом на старте команде были непонятны как технологии реализации этой «шайтан‑машины», так и требования заказчика. И тут даже на ближайший спринт было тяжело оценить задачи, и пришлось уйти от спринтов к простейшей канбан доске.
У Agile есть и обратная сторона, подход через спринты не позволяет определить итоговую стоимость работ, и еще страшнее, при постоянном изменении требований со стороны заказчика вы так и будете крутить спринты, так и не достигнув целевого состояния системы.
Поэтому Agile не применим, когда объявляется фиксированная цена проекта за тот или иной объем работ.
И да, при Agile подходе может накопиться серьезный технический долг, который вызван непонятностью требований на старте проекта, что не дало возможности построить правильную архитектуру ИТ‑решения.
Кстати, мода на Agile привела к тому, что его пытаются использовать в областях, где задачи изначально понятны, их трудозатраты можно оценить, и планирование проекта может вестись с необходимой точностью.
Вспоминается организация, которая пыталась применить Agile при проектировании зданий, при этом образ результата был понятен изначально, высокомотивированными командами она не обладала, и при попытке внедрить Agile получила полный бардак в управлении. В рамках консультаций пришлось их убеждать что в их случае Agile не совсем к месту.
В качестве вывода
Если задача понятна, требования ясны и команда имеет необходимые компетенции, я бы шел классическим проектным подходом и даже контрактовался за фиксированные работы, заложив трудозатраты на риски.
Если один из параметров не выполняется, нужно пытаться организовать работу по Agile, контрактуясь за отработанное в проекте фактической время, если конечно это возможно. Ну а если у вас достаточно коммерческой загрузки просто не идти на договора с фиксированной оплатой работ, настаивая на оплате по тайм‑шитам.
Если хочется реже играть в «три плана» и увереннее работать с неопределённостью, стоит прокачать деливери-управление как профессию. На курсе от OTUS "Delivery Manager" разбирают управление портфелем/командами до 50 человек, настройку процессов и переговоры — с фокусом на ограничения: бюджет, ресурсы, качество и риски. Чтобы узнать, подойдет ли вам программа курса, пройдите вступительный тест.
Для знакомства с форматом обучения и экспертами приходите на бесплатные демо-уроки:
28 января в 20:00. «Почему ваши оценки проекта всегда ошибочны». Записаться
5 февраля в 20:00. «Измеряя управляй. Метрики как важный инструмент Delivery Manager». Записаться
9 февраля в 20:00. «От проекта к портфелю: как управлять несколькими проектами?». Записаться
