+38 (093) 580-29-22 info@lokhnin.com

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

Сандартные проблемы в управлении ИТ проектами

Я не хочу в данной статье рассматривать типичные проблемы менеджмента в целом. Допустим, что все сотрудники имеют необходимую квалификацию, соответствуют ценностям компании, ответственно подходят к работе, мы работаем с адекватными заказчиками и т.д. Давайте сосредоточимся на проблемах, которые уникальны для управления ИТ проектами:

  • Студенческий эффект – сотрудник откладывает начало работы т.к. ему кажется, что времени еще более чем достаточно. Если на работу отведена неделя, то до среды сотрудники стабильно работают в расслабленном режиме и забывают что час, потерянный в самом начале проекта настолько же цене, как и час, потерянный во время завершения проекта;
  • Закон Паркинсона – работа занимает все отпущенное на нее время. Если программист закончил написание кода раньше отведенного срока, то естественно он себя лишних два раза перепроверит или в крайнем случае сходит поиграть в теннис, но уж точно не передаст её на тестирование;
  • Перепрыгивание между заданиями – специалист может участвовать одновременно в нескольких проектах и поэтому ему приходится постоянно перепрыгивать между заданиями. В таком случае катастрофически падает производительность труда;

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

На самом деле всё ещё хуже!

Приведу пример, который катастрофически часто встречаю в реальной жизни.

При определении планового срока исполнения и трудоемкости задания, исполнитель учитывает все вышеперечисленные проблемы (исходя из накопленного ранее опыта) и закладывает соответствующие риски. Он называет трудоёмкость и срок исполнения, в котором он уверен с вероятностью минимум 90%, а то и все 100%. Естественно это мы говорим про субъективные проценты.

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

А вот и не угадали ))) Я же говорил, что всё намного хуже

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

И снова в него не вкладывается. И этот цикл стабильно ухудшает показатели выполнения проекта и снижает производительность труда. Радуюсь, что ещё ни разу не видел, чтобы из-за указанных проблем закрылась компания. Есть естественные позитивные факторы, которые этому мешают, например: сотрудники уходят, а на их место подрастает молодёжь, которая делает задачи быстрее…

Весь парадокс заключается в том, что вопреки всей здравой логике, со временем трудоёмкость задач начинает не уменьшаться, а увеличиваться. Такую ситуацию можно назвать прямой противоположностью циклу PDCA и полным несоответствием теории менеджмента, которая гласит что каждое удвоение количества проделанной работы ведет к 10% повышению ее эффективности.

Кстати! Если Ваши сотрудники стабильно вкладываются в оценки и при этом компания не применяет метод критической цепи или хотя бы PERT, это значит, что оценки катастрофически завышены и в перспективе это приведёт к тому, что клиенты будут уходить к другим исполнителям. Но уже тема для отдельной статьи…

Метод критической цепи

Метод критического пути разрабатывался в условиях, когда проекты были обеспечены всеми необходимыми ресурсами. В общем понимании, метод критического пути не учитывает взаимосвязи операций по ресурсам (хотя например MS Project позволяет провести выравнивание проекта по ресурсам). Такой подход давно уже устарел. На смену ему пришел метод критической цепи.

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

  • Создать буфер проектов. Не пытаться сделать больше проектов, чем это позволяет наиболее слабое звено (ограниченный ресурс). Лучше не начинать проекты, а создать буфер, из которого передавать проекты в работу, только после того, как завершен один из текущих проектов. В таком случает, не будет постоянного перепрыгивания между заданиями. Вы можете сказать, что ресурсы будут простаивать. Да, это так. Но:
    • Будут простаивать ресурсы, которые не являются ограничением системы, соответственно эффективности системы в целом не уменьшиться. Свободных людей можно занять интересными и полезными занятиями такими как саморазвитие;
    • Если буфер создать перед самым слабым звеном, это позволит более эффективно использовать ограниченные ресурсы и повысить эффективность системы в целом;
  • Создать буфер проекта. Чтобы устранить студенческий синдром и Эффект Паркинсона, необходимо 50% каждой задачи на критическом пути перенести в буфер проекта. По всем некритическим задачам сделать то же самое, только буфер создавать перед входом такой задачи в критическую цепь. ВАЖНО! Объяснить всем исполнителям, что мы не ждем, что все 100% задач будут выполнены в срок, и мы понимаем, что минимум 50% будут завершены после оговоренного срока, а некоторые из них – с существенным опозданием. Другими словами объяснить что мы не «забираем» их время, а просто переносим в «буфер», которым они могут пользоватья;
  • Планировать «от завершения» и учитывать взаимосвязь операций по ресурсам. В MS Project планирование от завершения сделано достаточно криво т.к. при любом автоматическом перепланировании переводит все задачи в ручной режим. Поэтому лично мне легче использовать MS Excell.

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

Что происходит на практике, когда применяем метод критической цепи?

Вы можете задать резонный вопрос: «А как именно метод критической цепи связан с озвученными выше проблемами и, тем более, как помогает их решить?». Давайте посмотрим, что происходит при его применении:

  • Как только мы сокращаем каждую задачу в 2 раза, то мы этим сразу «убиваем» эффект паркинсона. На практике лучше начать с сокращения задач (за счёт переноса времени «в буфер») на 30% — именно такой процент обычно морально готовы принять как сотрудники, так и заказчики. В результате:
    • когда сотрудник выполнил задачу в рамках оценки или даже быстрее, он уже не будет тратить время впустую и перейдёт к решению следующей задачи;
    • если задача «просрочена», то время просрочки необходимо забрать из сформированного ранее «буфера», в таком случае конечная дата проекта не меняется;
  • т.к. перестаёт от сдвижения сроков задач меняться итоговая дата группы задач (вехи), например, готовность дизайна, бекэнда, вёрстки… ТО следующие в цепочке специалисты приступают к своим задачам согласно планам и это устраняет перепрыгивание между задачами.
    • Важная оговорка: в случае если технологически процесс построен таким образом, что сотрудник начинает делать одну задачу, но ещё на него могут упасть баги от предыдущих задач… То необходимо при планировании учитывать, что его эффективная загрузка может быть в среднем 6 часов в день, а не 8 часов. Рекомендую начинать именно с такого деления и при необходимости уже откорректировать цифры;
  • Планирование от завершения, выравнивание по доступным ресурсам (не планировать на одного сотрудника больше задач, чем он может сделать) и осознанное выстраивание списка задач перед «узким горлышком», например, перед РМ или дизайнером, позволяет максимально эффективно использовать их время, не давать в работу две задачи одновременно и повысить эффективность не только за счёт отсутствия перепрыгивания, но и за счёт отсутствия лишних затрат времени на нервы, конфликты, выяснение отношений.
    • Да, придётся смириться, что у других сотрудников могут быть простои. Это намного лучше, чем заовертаймить до смерти самого занятого сотрудника в компании. Проверено на личном опыте. Намного лучше сформировать для таких сотрудников программы обучения или задействовать на внутренних проектах
    • Да, придётся смириться, что некоторым клиентам придётся ждать пока их проект будет взят в работу. Клиенты этого не любят и хотят приступить к работам максимально быстро. Поэтому хорошим решением всё-таки будет не допускать «узкого горлышка» на уровне РМ и/или передать часть работы на sale или клиента: например, в небольшом проекте sale вместе с клиентом легко справятся с заполнением Брифа (или Устава), что существенно упростит работу РМ;
    • Да, нужно отказываться от проектов, которые жёстко ограничены по срокам, и мы ещё до старта проекта видим что просто не выполним его. Лучше отказаться, чем зафакапить. ИМХО.

 

UPDATE от 20 октября 2016

На одном из недавних проектов благодаря применению метода критической цепи удалось сэкономить 70 чел/мес по сравнению с плановым бюджетом. Что эквивалентно 100 000 долларов США. Проект сдали вовремя и содержание не резали.