Методы сжатия расписания и вехи в проекте. Курс по управлению проектами, часть 19

29.03.19

Управление проектом - Компетенции и навыки РП

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

Предыдущая часть курса: Критический путь в расписании

Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера

 

Посмотрев на нарисованное автоматически расписание, вы  понимаете, что вы не укладываетесь в сроки. У вас в уставе рамки жестче чем сроки, которые у вас получились в графике. И надо как-то впихнуть, как-то утрамбовать расписание, уложиться в временные границы, которые обозначены в уставе. Необходимость сжатия расписания иногда возникает уже в ходе планирования, а иногда и позже. Потому что зачастую вас из расписания вышибают какие-то события: заболел человек, подвел поставщик, заказчик пришел с какой-то гениальной идеей, обязательной для включения в план.
 
Как вернуться в расписание? Что надо сделать, чтобы уложиться в срок, если вы начинаете из него выпадать? Есть следующие варианты:
 
- Урезать какие-то работы, содержание.  Вполне хороший метод, хоть и не бесплатный. Мы не можем урезать то, что в уставе было указано явно. Например, мы строим 9-тиэтажный кирпичный дом. Это нельзя менять, это неприкосновенно. Но в уставе не написано, будем мы стеклить балконы или нет. Поэтому как вариант – можно отказаться от остекления балконов. Это сделает немного более несчастным лицо заказчика, ему это не очень понравится. Но если мы правильно выбрали работу для урезания, это не сильно сделает его несчастным - ведь благодаря этому сокращению, мы уложимся в сроки (если нам это необходимо).
 
- Снизить качество. Этот вариант проще всего объяснить на примере х/ф «Марсианин». Там есть момент, когда NASA запускает ракету, и им надо очень быстро уложиться в сроки, чтобы человека спасти. Они не успевают, поэтому начинают думать, что можно сократить. Кто-то предлагает отказаться от предзапускового тестирования. Начинают обсуждать, как часто предстартовое тестирование выявляет проблемы? Выясняется, что нечасто. Решили от этого этапа отказаться, запустить ракету без него. Но у них, кстати, ракета взрывается на старте, потому что тестирование убрали. Урезать качество можно, иногда это может сделать заказчика более довольным. Но надо понимать, что риски повышаются.
 
- Привлечь еще людей в команду. У этого варианта даже есть название – crashing – когда вы, грубо говоря, нагнали людей. Допустим, у вас было 2 землекопа, а теперь их 5. И они будут быстрее копать. Но вы понимаете, в чем проблема этого способа? Работа дорожает. У вас больше народа трудится, значит, работа станет дороже. Причем,  crashing – это не обязательно привлечение большого числа людей. Может, вы вместо землекопов пригнали экскаватор. Он изначально не был запланирован, чтобы сэкономить. Но сейчас вы не укладываетесь в сроки, поэтому изменили решение. Но вы должны понимать, что crashing не всегда работает. Потому что, например, землекопы вдвое или впятером в яму еще вмещаются, а вдесятером – уже нет. Или некоторые работы не поддаются линейному ускорению. Это относится к любым интеллектуальным работам – например, проектированию и программированию. Допустим, у вас было 5 программистов, у вас была одна скорость. Вы взяли еще двоих, скорость чуть повысилась. Вы увеличили количество программистов до 12, но скорость упала до первоначальной, когда у вас было 5 специалистов. Почему так может быть? Потому что интеллектуальные задачи, и не только в программировании, требуют обильных коммуникаций. Люди общаются, кто что делает, кто как делает. Но чем больше людей, тем ниже уровень коммуникации. И скорость работы падает. Но на простых работах crashing работает, хотя и делает сами работы дороже.
 
- Запараллелить работы. У этого способа тоже есть название – fast track. По-русски звучит ужасно – «быстрый проход». Допустим, у нас были работы, которые шли последовательно, а мы их запараллелили. В чем проблема этого способа? У всего есть своя цена, и fast track всегда повышает риски. Представьте себе, что вы строите дом, сначала фундамент, потом стены и крышу, потом обои клеите. Но вы не успеваете. И решаете, ладно, фундамент и стены есть, хорошо, а обои и крышу будем делать одновременно. Может быть, у вас это получится. Но если пойдет дождь, обои просто отклеятся, и вы потеряете и деньги, и время. То есть этот метод повышает риски. Работы потому и стояли последовательно в диаграмме Ганта, что это был самый надежный способ все сделать как следует, а не просто потому, что кому-то так захотелось.
 
- Перепланировать, скорректировать планы. Это единственный бесплатный способ. Но вы должны хорошо подумать и найти какое-то новое решение. Сначала у вас были одни планы, но потом в ходе проекта обнаружилось, что можно перепланировать. Например, можно одних людей поменять на других. Или вы заложили какие-то риски, но они не сработали, и у вас остался резерв, который можно использовать на другие работы. Повторюсь, это единственный бесплатный способ, который ничего не стоит. Может быть, когда вы столкнетесь с проблемами, у вас уже будут идеи, что можно изменить, и это не сделает проект дороже, но может немного ускорить его реализацию. Так чаще всего и бывает. Поэтому устав у нас «отлит в бронзе», а планы и все остальное у нас гибкое. Так что если вы видите, что не укладываетесь в сроки, сначала подумайте, нельзя ли внести изменения в план и сэкономить время за счет этого.
 
- Отказаться от изменений.  Этот способ работает, если причина нарушения сроков связана с какими-то изменениями, о которых вас попросили, и от них можно отказаться. К примеру, заказчик предложил поставить в доме лифты ОТИС, а не Могилевского завода. Но вы смотрите, что это, во-первых, дороже, а во-вторых, надо лифтовую шахту расширять, на это понадобится время. Поэтому вы отказываетесь от таких изменений. Или предлагаете заказчику выбрать, от чего ему нужно отказаться, чтобы изменения сохранить. Например, мы не стеклим балконы, но поставим лифты ОТИС. Хотя, конечно, корректировать изменения не всегда возможно.
 
- Переработки. Этот метод сжатия расписания самый простой, но у него есть и минусы. Что плохого в переработках? Качество страдает. Люди выматываются. У меня есть глубокая убежденность, я это проверил на проектах в двух отраслях – в IT и производстве: если у вас серьезные переработки, то есть вы работаете раза в полтора больше, вместо  8 – 12 часов и больше, то в таком режиме люди без потери бдительности и потери качества могут работать не дольше двух-трех недель. Дальше люди очень сильно выгорают. И потери от выгорания будут сильнее, чем выигрыш от переработок. То есть если вы работаете в таком режиме не 3 недели, а 6, то у вас к этому сроку и даже раньше падает производительность настолько, что вы в итоге теряете спустя еще 3 недели все ускорения, которые отыграли за предыдущие недели. Люди, действительно выгорают, они устают, теряют концентрацию. И самое страшное – они просто увольняются. Кроме того, от работы в авральном режиме страдает качество, поэтому еще неизвестно, что вам дороже выйдет: отстать от сроков или в качестве потерять.  За те 2-3 недели, в которые вы можете выжимать соки из людей, на мой взгляд, можно отыграть около недели примерно. То есть за счет того, что человек работает сверхурочно, вы сможете компенсировать максимум неделю отставания. После этого у него начнет падать производительность, ему потребуется длительное время, чтобы вернуться в норму. Есть еще один минус в переработках (кроме повышения рисков из-за усталости и ошибок), тоже очевидный. Особенно актуален для тех менеджеров, которых не волнует, что люди выгорают, что им тяжело. Это еще и дорого, потому что переработки в приличном обществе принято оплачивать. Так что у переработок две проблемы - деньги и качество. 

 

Вехи в расписании проекта

 


Последняя тема, о которой я хочу рассказать завершая тему управления расписанием, это - вехи или ключевые точки. 
Коллеги, вам наверняка приходилось слышать такое понятие как вехи. Что это? Это маячки, засечки. Вообще веха, по определению, это работы с нулевой продолжительностью. Но это совершенно безумное определение, которое не отражает суть. Помните, мы говорили, что в уставе заложен срок проекта, когда надо закончить. Например, дом надо построить не позднее чем через год. И спонсор вам говорит: слушай, у меня есть еще одно важное ограничение – у меня заканчивается аренда земли через 9 месяцев. И поскольку продлевать разрешение очень дорого, мне надо, чтобы через 9 месяцев вся техника с площадки ушла. Поэтому через 9 месяцев надо закончить стройку, а отделка может еще продолжаться.  В итоге в уставе зафиксировано две вещи – срок окончания проекта (12 месяцев), и уход техники с площадки через 9 месяцев. И это как раз веха. Вы согласились, подписали устав, и дальше вы, как менеджер, у себя спрашиваете, что нужно сделать, чтобы техника ушла с площадки? Выясняется, что надо сделать массу всего. Расписываете все работы (колбаски Ганта), ставите засечку в тот момент, когда техника должна уйти. А когда мы сделаем отделку, поставим сантехнику, подведем сети, проведем сдачу-приемку, тогда мы скажем, что дом построен. И это будет вторая засечка.
 
Этих засечек, вех может быть N-ное  количество. Но обычно вех, которые включаются в устав, немного. Они добавляются, чтобы сориентироваться.
 
Чтобы в Microsoft Project поставить веху, нужно, действительно, вбить туда работу с нулевой продолжительностью. То есть вы добавляете ее как обычную работу (колбаску), а потом вы вручную в столбце «продолжительность» вбиваете цифру 0. Не он вам ставит, а вы сами, своими руками вбиваете, что эта работа длится 0. Тогда Project понимает, что это веха. Он обозначает ее ромбиком. Программа перерисовывает ваш квадратик в виде ромбика.
 
Еще одна история про вехи, которую полезно держать в голове, – то, что вехи – отличный способ коммуникации с высшим руководством. Если вы пытались напечатать диаграмму Ганта, про которую я раньше рассказывал, то вы, может, знаете, как это страшно. Она обычно занимает две страницы в ширину, к тому же она длинная, и вы пытаетесь собрать эти странички, склеить их скотчем, чтобы получить диаграмму. Но поймите, спонсора обычно мало волнуют эти нюансы. Его по-настоящему волнуют вехи. Чтобы не мучаться,  в Project есть отличный способ – «график вех» называется, где он убирает все эти колбаски Ганта и оставляет только вехи. Это компактная штука, которая помещается на одну страничку. И он вам отдельно показывает, какие вехи уже достигнуты, то есть какие работы уже выполнены,  сколько остается до  следующих вех, например, 60% мы уже сделали, 40% осталось, а до следующей вехи еще далеко. То есть это очень компактная штука, и спонсору именно она интересна. С ее помощью можно разговаривать с высшим руководством, спонсором, убрав все лишние детали. То есть график контрольных точек - очень удобный инструмент в первую очередь для коммуникации с руководством и прочими заинтересованными сторонами. 
 

 

Предыдущая часть курса: Критический путь в расписании

Следующая часть курса: Методы определения себестоимости и способы отслеживания прогресса проекта

Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера

 

Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"

См. также

Коммуникации Лидерство Компетенции и навыки РП Бесплатно (free)

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

11.11.2024    283    4    dklimchuk    1    

2

Компетенции и навыки РП Коммуникации Бесплатно (free)

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

06.11.2024    636    0    Kukabarra    2    

7

Компетенции и навыки РП Руководитель проекта

Есть занятный психологический эффект, когда мы игнорируем проблемы, с которыми мы не понимаем что делать. В своей книге “Вальсируя с медведями” авторы назвали этот эффект “А, вы имеете в виду этот приближающийся поезд…”

05.11.2024    1053    0    MariaTemchina    1    

27

Компетенции и навыки РП Бесплатно (free)

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

22.05.2024    2450    0    user1669221    0    

8

Компетенции и навыки РП Бесплатно (free)

Часто аналитики входят в профессию и ограничиваются знаниями конкретных конфигураций. Но аналитик 1С – это, в том числе, технический специалист, и он должен обладать соответствующими навыками. О том, как аналитику не превратиться в консультанта, пойдет речь в статье.

20.05.2024    3017    0    TanyaRi    1    

8

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3617    0    biimmap    39    

39

Компетенции и навыки РП Руководитель проекта Бесплатно (free)

Статья о том, как быть эффективным руководителем проектов. Кто такой руководитель проектов, что подразумевает эта роль в проекте, и зачем она нужна?

22.03.2024    1249    0    PChizhov    0    

6

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

Самый важный человек на проекте – это РП со стороны заказчика. Он принимает все решения и за эти решения зачастую отвечает головой. О том, кого выбрать руководителем проекта со стороны заказчика, как работать с заинтересованными сторонами, собрать рабочую группу, экономно расходовать бюджет и бороться с саботажем, расскажем в статье.

26.02.2024    2928    0    user1270271    0    

13
Оставьте свое сообщение