Как завершать проекты в срок

10.03.20

Управление проектом

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

Бегло напомню к чему мы пришли в прошлой статье (//infostart.ru/public/1199781/):

  1. Качественной оценка длительности задания считается такая оценка, которая гарантирует не менее 80% вероятности завершения задания в срок.
  2. Оценка, гарантирующая вероятность 80% и более завершения в срок содержит не менее 50% подстраховки.
  3. Традиционно считается, что для того, чтобы весь проект завершить в срок, совершенно необходимо каждое задание завершить в срок.
  4. Из-за неправильной организации работ на проекте большинство заданий не завершается в срок, приводя тем самым к срыву сроков проекта.

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

  • Закон Паркинсона.
  • Студенческий синдром.
  • Потеря выигрыша и передача опозданий в цепи зависимых заданий.
  • Перепрыгивание от задания к заданию в мульти-проектных средах.

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

  • Оценка длительности заданий не переводилась в разряд ОБЯЗАТЕЛЬСТВ - это должно значительно сократить количество подстраховки.
  • Выигрыш по времени и опоздания компенсировали друг друга.
  • Перепрыгивания от задания к заданию резко сократились.

И так, что собой представляет решение?

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

Метод №1: Эшелонирование

Общепринятая практика при определении даты старта проекта такова: чем раньше проект начнется, тем больше шансов завершить его в срок. Но правильно ли это? Если мы запустим все проекты одновременно, то неизбежно возникнет конкуренция за ресурсы. Нам следует выровнять загрузку ресурсов и организовать ресурсно-обоснованный график запуска проектов в производство. Такой подход называется «Эшелонирование». При этом необходимо эшелонировать проекты относительно самого загруженного ресурса проектной команды!
Вот пример эшелонирования графика по ресурсу «F»:

Важное предупреждение: 

  1. Не начинайте работу раньше графика, даже если ресурсы простаивают!
  2. Обычно существует остаточная конкуренция и за другие типы ресурсов. Возникает соблазн выровнять все ресурсы проекта, однако, попытка убрать остаточную конкуренцию – просто выброшенное время: Мерфи все равно вмешается и вернет все на свои места. Не нужно оптимизировать в рамках шума!

Давайте промоделируем на нашем симуляторе проектов, как изменится время выполнения проектов при использовании метода Эшелонирования.

Напомню, что условия экспериментального проекта для моделирования мы описывали в предыдущей статье:  //infostart.ru/public/1199781/

Исходные условия были такими:

  • В производство запущено одновременно три одинаковых проекта.
  • Каждый проект содержит 7 в разной степени зависимых друг от друга заданий.
  • Всего на трех проектах заняты 10 различных спецов и каждый может выполнять задания только своего типа.
  • Каждое задание длится 20 дней и вероятность выполнения его в срок 80%.
  • В каждом задании 10 дней подстраховки.
  • Плановое время выполнения проекта 140 дней.
  • Для переключения между заданиями работа ресурса не прерывается чаще, чем один раз в неделю.
  • Отсутствуют затраты времени на переключения от задания к заданию.

В таблице результаты моделирования до и после эшелонирования 3-х проектов.

  • Третий проект закончится на 5 дней раньше - 1% ускорения.
  • Второй ускорился уже на 70 дней (16%). 
  • Самые выдающиеся результаты у Первого проекта: 54% ускорение!

Неплохой результат! Эшелонирование работает!

Давайте посмотрим, что с этим еще можно сделать.

Метод №2. Управление подстраховкой.

Вернемся к истории с избыточной подстраховкой в оценках длительности каждого задании. Мы тогда согласились, что должны обеспечить защиту завершения всего проекта, а не каждого отдельного задания ("нам важно, чтобы проект был завершен в срок"). Напрашивается логичное предложение: а давайте передвинем ВСЮ подстраховку, заложенную в КАЖДОМ отдельном задании, В КОНЕЦ проекта!

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

На самом деле не важно то, сколько подстраховки заложено в каждом задании – мы ведь никуда не дели эту подстраховку, мы просто передвигаем ее в конец проекта. И даже если мы ошиблись, определяя ее размер, то когда нам не будет хватать времени на задачу, мы просто будем брать это время из буфера в конце проекта. А раз так, то давайте просто на половину сократим количество времени, указанного в оценке. Тем более, что наш опыт показывает, что до внедрения Методов критический цепи исполнители закладывают не менее 50% времени на подстраховку.

В итоге:

  1. Никто не будет вести себя так, как будто у него есть масса времени. Уйдет Студенческий синдром и закон Паркинсона.
  2. Через какое-то время накопится реальная статистика по схожим задачам.  Мы будем давать более реалистичные оценки задач.

Как убедить исполнителей?

  1. Необходимо, чтобы все знали, что большое количество той подстраховки, которую забрали, заново вносится в план, только в конце проекта и может быть, как и ранее, использовано для защиты от Мерфи для каждого задания.
  2. Необходимо, чтобы все знали, что менеджмент не рассматривает новые оценки по времени как обязательства. Уложиться в эти намного более короткие сроки не является обязательным, но, по возможности, желательным. 
  3. Использование подстраховки теперь централизовано, а значит ее будет сложнее разбазаривать. Время – это невосполнимый ресурс! И более чем нормально, если учет резервов времени в команде будет вестись тщательно и прозрачно!

Идем дальше. Оказывается, подстраховка бывает двух разных видов. Чтобы объяснить это, нам нужно ввести такое понятие как «Критическая цепь».
Вопрос: Что определяет время исполнения проекта?
Ответ: Самая длинная цепь зависимых заданий.
Без учета конкуренции за ресурсы сама длинная цепь - это «Критический путь проекта». 


 
А как изменится ситуация, если есть конкуренция за ресурсы?

Возникает необходимость выстроить последовательно (эшелонировать) выполнение заданий, конкурирующих за ресурсы. В данном случае есть два варианта решения этой проблемы. И мы уже получаем 2 варианта «Критического пути».

Ситуацию, когда «Критический путь» зависит от варианта распределения ресурсов, принято называть «Критическая цепь».
Формулирую определение: Самая длинная цепь зависимых заданий с учетом конкуренции за ресурсы и будет называться «Критическая цепь проекта».
Обратите внимание: каждый раз, когда имеет место зависимость ресурсов, критическая цепь зависит от решения РП относительно того, какое задание выполняется первым!

Зачем нам вся эта история с критической цепью? Очевидно, что именно подстраховка в заданиях в критической цепи удлиняет время исполнения всего проекта, и от того как спланирует последовательность выполнения работ руководитель проекта, и зависит, где пройдет критическая цепь проекта. А значит именно эту подстраховку необходимо использовать для защиты от опоздания всего проекта.

Теперь, как мы и договорились, соберите в одно целое всю подстраховку, заложенную в каждом задании критической цепи, разделите ее на 2 и используйте для защиты ВСЕГО проекта.
Обратите внимание, что получившийся буфер подстраховки критической цепи не должен составлять более 1/3 всего времени исполнения проекта. Назовем общий резерв проекта в критической цепи «Буфер завершения»

Однако, у нас есть еще примыкающие цепи заданий в проекте. В цепи зависимых заданий опоздания по примыкающим цепям неизбежно будут передаваться в критическую цепь ("опоздания передаются, выигрыш по времени нет"). При этом в примыкающих некритических цепях есть своя подстраховка, которую мы пока не трогали. Нужно собрать эту подстраховку и использовать для защиты от опозданий в некритических цепях, создав таким образом собственный буфер. Назовем его «Питающий буфер». Напомню, что буфер должен составлять 1/3 от длины цепи, в которой до этого подстраховку сократили вдвое.

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

Давайте посмотрим, как изменится ситуация в нашей модели, когда мы к «Эшелонированию» введем в систему «Буфер завершения» в критической цепи и «Питающий буфер» в каждой некритической цепи заданий.

Результаты моделирования в таблице. 

Смотрите, совсем другое дело!

  • Третий проект заканчивается уже через 240 - минус 190 дней.
  • Второй ускорился на 125 дней. 
  • Первый улучшил свой предыдущее значение на 5 дней

Неплохой результат? Да, но мы хотим быстрее! Мы хотим определенно более прорывное решение!

Метод №3. Приоритеты выполнения заданий

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

Очевидно, что для того, чтобы следить за потреблением резервов, специалисты должны регулярно сообщать о прогрессе выполнения задания. Специалист должен сообщать «когда будет ЗАВЕРШЕНО задание», а РП должен вести учет расхода резервов.

Для управления приоритетами необходимо ввести следующие 2 правила:

  1. Задание критической цепи, которое начало потреблять буфер завершения, всегда будет иметь более высокий приоритет, чем задание в цепи, потребляющее питающий буфер.
  2. Задание имеет более высокий приоритет, если оно имеет более высокий процент потребления буфера в конце своей цепи.

Промоделируем эффект от использования Правил установки приоритетов.
Единственное отличие – каждый раз, когда ресурс может выбирать между двумя заданиями, симулятор рассчитывает приоритеты в соответствии с типом буфера и данными по текущему уровню потребления буфера.

Внимание на таблицу!

  • Третий проект – еще минус 30 дней!
  • Второй – минус 55 дней!
  • Первый - фантастический результат -  115 дней! Напомним, что самая первая модель с одним проектом давала нам 180 дней с той же вероятностью.

Важный побочный эффект: до внедрения Методов критической цепи ресурсы были заняты на протяжении 375 дней и это давало только 50% вероятности успеть в срок. В результате внедрения все ресурсы высвобождаются уже после 210 дней, при этом вероятность успеть в срок не менее 90%! Методы критической цепи высвобождают большое количество ресурсов, которые можно использовать на других проектах!

Но каким бы впечатляющим не был наш результат, тем не менее существует 10% вероятности не завершить первый проект в амбициозный срок 115 дней. В тоже время обязанность РП обеспечить выполнение проекта в срок!

Это можно сделать если:

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

Для этого нам нужна система показателей состояния дел на проекте.

Показатели оценки проектов

Для оценки ситуации на проекте и сравнения результатов нескольких проектов между собой нам достаточно всего три показателя:

  1. Сколько процентов критической цепи уже завершено.
  2. Сколько процентов буфера завершения потреблено в соотношении к проценту завершенной части критической цепи.
  3. Текущая скорость потребления буфера завершения.

Рассмотрим все три показателя более подробно.

Показатель №1. Прогресс проекта

Взгляните на этот график проекта:

  • Длительность проекта: 120 часов
  • Плановые трудозатраты: 300 часов
  • Фактически израсходовано: 150 часов

Традиционно прогресс проекта измеряется в соответствии с процентом выполненных работ в соотношении с общим количеством предполагаемых работ. На сколько процентов, по вашему мы завершили проект? Чаще всего мы услышим, что работы завершены на 50%.

Теперь представим, что на проекте на одном из заданий возникла заминка – работы приостановлены, скажем, по вине заказчика – они никак не могут ТЗ согласовать. Знакомая ситуация? Куда мы скорее всего назначим ресурсы, если не хотим, чтобы проект останавливался и ресурсы простаивали? Конечно на задания, по которым нет проблем! 

В итоге получаем такую закономерную картину:

  • Плановые трудозатраты проекта: 300 часов
  • Фактически израсходовано: 210 часов
  • Статус проекта: 70% завершено! 

Какой молодец наш РП – прошло всего 50% времени, отведенного на проект, а он уже отчитывается о 70% выполнении работ! Того и гляди, проект завершиться раньше срока! 

В результате проявляется тот самый неожиданный феномен: Исполнение последних 10% проекта занимает половину времени всего проекта!

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

При новом подходе прогресс приведенного для примера проекта будет: 25%. Статус проекта не меняется, пока не будет завершено проблемное задание.

Теперь мы знаем прогресс проекта, но как мы сможем понять, на сколько проблемное задание портит нам жизнь? Может 25% на данный момент — это норма? Для этого нам понадобится второй показатель.

Показатель №2. Процент потребления резервов времени

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

Взгляните на рисунок:

3-я задача сверху в критической цепи вызвала проблему и начала потреблять буфер завершения. При этом сдвинулись сроки завершения зависимой от нее задачи.
Статус проекта: 50% критический цепи завершено, при этом потреблено 20% буфера завершения. 
Все хорошо, у нас нет повода волноваться! 

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

И так, теперь мы знаем не только прогресс проекта, но и состояние резервов времени, и есть ли у нас проблема со сроками. Однако, возникает еще пара вопросов:

  • Как можно определить на регулярной основе, находится ли проект под контролем? 
  • Если на проекте случился перерасход буфера завершения, мы приняли меры, возможно ли как-то проверить – идет проект на поправку или нет?

 Для этого нам понадобится третий показатель.

Показатель №3. Скорость потребления буфера

Этот показатель позволяет увидеть, когда проблема возникает и вернули ли наши действия проект в свои рамки. Напомним, что буфер завершения составляет 1/3 времени исполнения проекта. А это значит, что если в определенный интервал времени скорость потребления буфера завершения выше, чем 1/3 (33%) времени данного интервала, то у нас проблемы накапливаются. 

Пример: Прошло еще 10 дней проекта, было потреблено дополнительно 5 (5 это 50% к 10) дней буфера завершения. Вывод: у нас проблема.

Если в определенный интервал времени скорость потребления буфера завершения ниже, чем 1/3 времени данного интервала – это означает, что относительная подстраховка увеличилась, мы накапливаем резервы времени. 

Пример: Прошло еще 10 дней проекта, было потреблено дополнительно 1 (1 это 10% к 10) день буфера завершения. Вывод: проект восстанавливается (накапливает подстраховку).

Выводы

Не важно, чтобы каждое отдельное задание было завершено в срок. Важно, чтобы в срок был завершен весь проект!
Для этого необходимо использовать 3 приема:

  1. Эшелонирование проектов.
  2. Критическая цепь с буфером завершения и питающими буферами подзадач.
  3. Расстановка приоритетов и правильные показатели оценки проектов.

Для того, чтобы начать применение методов критической цепи, необходимо выполнить 3 действия:

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

Действие №2. Внедрите Эшелонирование проектов. Придите к общему согласию о введении эшелонирования проектов в соответствии с выбранным дефицитным ресурсом, который и будет задавать темп и график всех проектов. В мульти-проектной среде эшелонирование проектов – абсолютная необходимость!

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

При внедрении и использовании методов критической цепи учтите, что это вызывает изменение в проектной среде:

  • Ресурсы начинают привыкать к тому, что перепрыгивание от задания к заданию резко сократилось и что их оценки по длительности выполнения больше не воспринимаются как обязательства. В результате они закладывают в свои оценки значительно меньше подстраховки.
  • После того как ресурсы исполнили несколько проектов по методу Критической цепи, будет ошибкой продолжать следовать правилу о сокращении времени оценки наполовину. Правило, которому необходимо продолжить следовать: «Буферы равны 1/3 времени исполнения в цепи»
  • Изначально наиболее загруженный ресурс совсем не является "бутылочным горлышком". Применение Методов критической цепи выявляет избыточную мощность и позволяет увеличивать количество проектов. В конечном итоге "бутылочное горлышко" все-таки возникает. На этом этапе важно, чтобы "бутылочное горлышко" никогда не оставалось без работы. Этого можно легко добиться за счет небольшого изменения в методе эшелонирования.

Для более углубленного понимания Методов критической цепи рекомендуем к прочтению следующие книги автора методики и создателя Теории ограничений систем (TOC – Theory of Constraints) Элияху Голдратта:

  1. Цель: Процесс непрерывного улучшения
  2. Критическая цепь.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Krasnodar.

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


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

См. также

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

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

02.05.2024    2978    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4093    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3437    0    user1853337    8    

29

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

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    3315    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15052    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6165    0    stnslv    5    

25

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    5210    0    andironenko    3    

32

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

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5788    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. kiset 19.03.20 11:17 Сейчас в теме
В теории всё звучит красиво и логично.

А как данная методика управляется на практике? Существуют ли такие инструменты управления проектами по методам эшелонирования и критической цепи?
Пока не получается представить, как можно этот процесс выстроить, чтобы при этом его использование не вызывало желания всё бросить, и начать управлять по старинке. Или же учёт использования буферов это ещё один инструмент, рассчитываемый в ручном режиме?
2. VLikhobabin 98 19.03.20 11:43 Сейчас в теме
(1) К сожалению готового софта "бери и работай" нет. Но мы же 1С-ники! Можем что угодно написать. Задача довольно простая - нужно к стандартному процессу учета и контроля оценок длительности добавить процесс формирования и учета резервов по цепям. Методика действительно высокоэффективная и проверенная сотнями проектов по всему миру.
3. kiset 19.03.20 11:51 Сейчас в теме
(2)Для того, чтобы допилить систему учёта на 1С, надо сначала эту систему учёта разработать. :)
1С-ники не обязательно ж ведут учёт в системах управления проектами, написанными на 1С.

(2)
Методика действительно высокоэффективная и проверенная сотнями проектов по всему миру.

Вот это меня немного и смущает. Вроде как методика проверена сотнями проектов по всему миру. Но здесь напрашиваются выводы:
- Либо готовый софт всё-таки существует, но мы о нём почему-то не знаем
- Либо существует возможность безболезненной настройки какого-либо софта
- Либо методика существует пока больше в теории, чем на практике
- Либо все сидят и руками сводят данные, но это больше пугает, чем радует
4. VLikhobabin 98 19.03.20 12:07 Сейчас в теме
(3) Существует, но забугорный и через чур кошерный.
С софтом для управления проектам внедрения 1С общая проблема. Т.к. нет универсальной таблетки, каждая команда изобретает кучу велосипедов по ходу своего развития. И начиная от эксела через трелло в джиру обрастает уникальными фитчами и практиками.
При этому, у методов критической цепи тоже есть свои недостатки. Методика исходит из того, что специалисты являются профессионалами в своей области и, как минимум, понимаю что делают. И если и дают оценку с запасом, то только с целью подстраховать свои обязательства. У нас же, как это часто бывает, за внедрение берется команда которая ни чего подобного ранее не делала. Рассуждаем так - "Ну это же 1С? Код открыт? Ну, разберемся! Что, первый раз что ли...." И ладно если это написание кода, а ведь многие проекты внедрения - это изменение процессов заказчика под типовой функционал. А как можно адекватно оценить "за сколько наши закупщики перестроятся делать закупки по новой схеме"? Нужно учитывать волю руководства, обучаемость сотрудников, атмосферу в коллективе.... тут проектная дипломатия больше ....
6. sbase 41 10.09.21 16:01 Сейчас в теме
(3)
Вот это меня немного и смущает. Вроде как методика проверена сотнями проектов по всему миру. Но здесь напрашиваются выводы:
- Либо готовый софт всё-таки существует, но мы о нём почему-то не знаем
- Либо существует возможность безболезненной настройки какого-либо софта
- Либо методика существует пока больше в теории, чем на практике
- Либо все сидят и руками сводят данные, но это больше пугает, чем радует


1. Все софты с поддержкой CCPM есть у Филиппа Мариса на сайте:
https://www.marris-consulting.com/en/our-expertise/critical-chain-project-management/critical-chain-project-management-software-solution

Но BIPULSE там нет, мы активно пока не выдвигались на западный рынок.

2. Есть надстройки к MSProject, A-Dato делает интеграцию с Джирой., BIPULSE - интегрируется со всем откуда можно вытянуть проектную аналитику или дать лучшие данные для принятия решений на всех уровнях.

3. Методика работает в практике, посмотрите доклады конференции Critical chain 2020 - https://www.criticalchain2020.com/

Список внедрений по миру у Марриса есть: https://www.marris-consulting.com/en/our-expertise/critical-chain-project-management

В России 15-20 внедрений. Большая часть - строительство.

4. Причина малого числа внедрений:

а) Некоторые свернули внедрение потому что неправильно применили правила. (нельзя резать оптимистичную оценку в 2 раза)

б) Мы не можем показать эти запасы нашему Клиенту
в) Мы не можем показать эти буферы другому подразделению
г) Я хочу планировать проектом как я хочу а не как система это делает.
е) Я хочу точно знать чем будет занят сотрудник в этот день

ж) У нас дофига денег, поэтому мы просто купим ресурсы чтобы сдать вовремя.
з) Сроки? Это те которые в договоре? Спокуха, мы договоримся.
и) Мы всегда сдаем проекты вовремя. Как? РП как-то договариваются. Ну как договариваются? Поляну накрываем и заказчик принимает.
к) Штрафы за просрочку? Не у нас нету, мы договариваемся, или на T&M переходим. Agile же!

Вот и получается что в РФ или всем по барабану "Все продалбывают" или дофига денег, чтобы урегулировать вопрос.
5. sbase 41 10.09.21 15:34 Сейчас в теме
(1) Если говорить об ИСУП, то BIPULSE - эшелонирует и делает её кучу всего на уровне скрещивания CCPM+Agile


Как выстроить процесс: написано в книге https://ridero.ru/books/upravlenie_proektnym_biznesom/
Оставьте свое сообщение