Евгений Камашев — лектор курса «Проджект-менеджмент», директор по проектам в RockIT. Работал в «Метинвест Диджитал», Vodafone, «Альфа-Банк», «Проминвестбанк», ПУМБ — руководил портфелем проектов с бюджетом более $20 млн.
Нам Евгений рассказал, какие командные ошибки срывают дедлайны и как их исправить.
#1. Устанавливайте реалистичные сроки
Чаще всего дедлайны нарушают потому, что команды подписываются под невыполнимыми дедлайнами — переоценивают свои силы или поддаются давлению заказчиков.
Учитывайте не только ограничения, которые известны заранее, но и допущения: уточните, что готовы выполнить задачу в срок при определенных условиях. Например, если свои обязательства вовремя выполнят подрядчики или если заказчик будет согласовывать материалы в «течение дня».
Не устанавливайте слишком длинные сроки. Это делает проект дороже и снижает эффективность бизнеса, а в тендере, например, выиграют более оперативные исполнители.
Однажды я аудировал проектную IT-команду, которая планировала участвовать в тендере. Сроки были неадекватными, потому что каждый участник взял себе время «про запас», чтобы перестраховаться. Анализ ресурсов позволил сократить время в 2 раза, а бюджет — в 1,5.
#2. Учитывайте квалификацию команды
Чем меньше опыта, знаний и навыков у участников команды, тем больше времени нужно на проект. Если проект спланировали, но состав команды изменился (например, в него вошли менее компетентные специалисты) — сроки скорее всего придется корректировать.
Если состав команды стабилен, собирайте статистику продуктивности: фиксируйте планируемое и фактическое время на выполнение задач для каждого участника. Это помогает устанавливать коэффициенты трудозатрат.
Люди склонны переоценивать скорость своей работы. А если вы ведете учет, то заранее знаете: этот сотрудник планирует успеть за Х дней, а в сроки проекта нужно заложить коэффициент, например, 1,2Х.
#3. Предусматривайте риски
Непредвиденные ситуации возникают всегда. Поэтому в проектах планируйте:
- что можно сделать, чтобы не допустить/уменьшить влияние риска (пропишите в основном плане)
- что можно сделать, чтобы уменьшить влияние последствий риска на сроки/бюджет проекта, если он уже наступил (учтите в «плане Б»)
Чем сложнее проект, тем больше должен быть буфер «запасного» времени/бюджета — чтобы перестраховаться и успеть решить проблемы.
Используйте карту рисков, которая состоит из двух векторов:
- вероятность наступления риска
- влияние риска на проект
Риски с высокой вероятностью и влиянием требуют максимальной проработки. Зачастую именно на них необходимо заложить буфер времени.
Так, в «типовых» для команды проектах обычно достаточно 10–15% дополнительного времени. В долгосрочных проектах с высокой степенью неопределенности — примерно 30%. На R&D-проекты буфер «запасного» времени может быть 100% и более. Чем выше неопределенность, тем больше буфер.
Но не впадайте в крайности: если вы пытаетесь предусмотреть Армагеддон даже в самом простом проекте, его длительность неоправданно увеличится в разы.
Пересматривайте риски в течение проекта: одни «отпадут», другие появятся. Приняли новый закон, заболел или уволился сотрудник, заказчик перебросил часть ресурсов на другой проект — это невозможно предусмотреть при планировании. Также неизвестно, когда какой риск может произойти и произойдет ли вообще.
Частота пересмотра рисков может отличаться, главное — регулярность. Например, если я выполняю проект сам, могу делать пересмотр каждый вечер. Если проект длительный и в него вовлечено много людей — зачастую ревизию рисков достаточно проводить раз в две недели. Чем выше интенсивность проекта и степень неопределенности, тем чаще нужен анализ/пересмотр рисков.
#4. Мониторьте прогресс
Определите контрольные точки проекта, сроки которых влияют на конечный результат. Составьте план и регулярно сверяйтесь в ним. Если нужное событие не произошло, принимайте меры, чтобы его ускорить или компенсировать другими действиями.
Будьте проактивными в вопросах, которые зависят от заказчика или подрядчика. Лучше лишний раз заранее уточнить, успевают ли они сделать свою часть, чтобы эффективно планировать работу команды.
Установите «промежуточные дедлайны» и отслеживайте, укладываетесь ли в сроки по задачам. Это помогает заранее выявить отклонения от графика и успеть исправиться до финального дедлайна.
Может оказаться, что какие-то процессы завершаются даже быстрее — тогда можно отдать часть ресурсов (например, рабочее время специалистов) на «провисшие» участки.
Сроки промежуточного контроля зависят от длительности, масштаба, методологии и фазы проекта.
Например, в SCRUM стендапы проводятся каждый день — команда собирается и коротко обсуждает, кто и что сделал, есть ли проблемы. В кризис-менеджменте или в проектах на этапе быстрого запуска такие встречи проводят и несколько раз в день, потому что ситуация может меняться каждую минуту. А если у вас размеренная работа и «длинные задачи», достаточно проводить статус-встречи раз в неделю.
#5. Визуализируйте прогресс
Оптимальный инструмент — доска: физическая в офисе или виртуальная для работы удаленной проектной команды.
Большинство компаний обычно используют таск-трекинговые системы. Для больших проектов и команд это могут быть Microsoft Project, Primavera, Jirа. Небольшим командам может хватить и простых решений — Trello или ClickUp.
Маленькой команде, которая работает в офисе, лучше всего подойдет физическая доска. На ней фиксируйте задачи и прогресс. Регулярно собирайтесь с командой, чтобы их обсудить.
#6. Установите редлайны
Это предупредительные сроки перед дедлайнами — ориентируйтесь именно на эти «красные линии». Мотивируйте себя за соблюдение редлайнов: успели — купите себе пирожное, нет — останьтесь без десерта.
Время от редлайна до дедлайна зависит от трудоемкости задач: срока должно хватить, чтобы все-таки собраться и успеть до финальной точки, если что-то пошло не так.
#7. Следите за критическим путем
Есть задачи, которые стоят на критическом пути — напрямую влияют на сроки. Их нужно отслеживать в первую очередь. А есть задачи, которые можно выполнять параллельно. Сами по себе они не влияют на сроки проекта, их можно «двигать» или делать чуть дольше, чем планировалось. Но если их игнорировать, такие задачи станут «горящими», сформируют новый критический путь и сорвут дедлайн.
Например, в IT-проекте установка и доработка программного обеспечения — это задачи на критическом пути, а написание инструкций для пользователей новой системы — нет. Но если не заниматься параллельно инструкциями, в финале проекта может оказаться, что ПО готово, но как им пользоваться — никто доступно не изложил. Срок удлиняется.
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
#8. Делайте работу над ошибками
Проводите ретроспективы и составляйте Lessons Learned — чек-листы выводов: пусть они будут под рукой на старте нового проекта.
«Разбор полетов» лучше проводить не только в конце проекта, но и на промежуточных этапах.
Цель ретроспективы — улучшить работу, а не найти крайнего. Поэтому разделяйте эмоции и факты: обсуждайте, что делалось, как это повлияло на итог, что сработало, а что нужно поменять.
В IT-проектах частая ошибка — некачественно собранные у заказчиков нефункциональные требования. Это приводит к появлению дополнительных задач, которые нужно сделать «на вчера». Например, функционал программы работает, но скорость выполнения операции — три секунды, а для заказчика критично — за одну.
Накапливайте опыт не только своих, но и чужих ошибок, собирайте кейсы других команд. Когда столкнетесь с похожими ситуациями в своем проекте, замигает «красная лампочка».
Хотите получать дайджест статей?
