?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Фуршетное - октябрь 2011
psilonsk
Я в октябрьском фуршете у tema
Как всегда - развернутые ответы на умные вопросы по управлению проектами. :-) Кстати, мне не лень ответить на вопросы по управлению проектами и вне фуршета.


promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1

Созрел, кстати, вопрос :)

Сейчас у меня процесс создания сайта выглядит примерно таким образом: рисуем дизайн, верстаем, программируем. Как правило параллельно в работе идет около 10-ти проектов, каждый на разных стадиях. Есть такая проблема, что я совершенно никак не могу спрогнозировать, сколько времени уйдет на работу с дизайном. У одних клиентов правок мало, у других много и долго, кто-то отвечает быстро, кто-то медленно, Из-за этого, я не могу спрогнозировать, когда мы приступим к программированию. Разброс от недели до 3-х месяцев. В результате — невозможно контроллировать загрузку программиста, бывает такое, что сразу 3 проекта наваливаются на программирование одновременно, и естественно все три успеть невозможно. Какие есть способы/решения такой ситуации? Заранее спасибо ;)

Re: Созрел, кстати, вопрос :)

О, я тоже тут посижу, подожду ответа)

Re: Созрел, кстати, вопрос :)

Кирилл, обязательно отвечу, только чуть позже - сегодня вечером или завтра, хочется ответить максимально детально, а времени прямо сейчас на это нет. )

Re: Созрел, кстати, вопрос :)

Предлагаю разделить задачу на две части.
1. Есть проблема с точностью оценивания сроков одного из этапов проекта – дизайна. Мало того, что это очень «творческая» деятельность сама по себе, так еще и в разных ситуациях для разных клиентов длительность работы имеет большой разброс во времени.
2. Есть проблемы с планированием проекта в целом – хочется сделать проект предсказуемым по срокам исполнения, чтобы клиента лишний раз в заблуждение не вводить. На самом деле, это главная проблема и есть, просто в дизайне она проявилась сильнее всего.

Подход к решению первой проблемы – развитие культуры планирования в команде. Под культурой здесь понимается следование следующим принципам:
A. Вся команда вовлечена в планирование. Устраиваются регулярные сессии по составлению, обсуждению и апдейту планов. Даже если команда на удаленке, можно собирать их раз в 3 дня (или с другой периодичностью в зависимости от средней длины итерации или всего цикла производства) и по скайпу обсуждать план.
B. Вся информация о планировании должна доводиться до всех членов команды. Если дизайнер сможет разобраться в подходах и стратегиях планирования, то он сможет быть активным участником сессий планирования и задавать полезные вопросы. Что еще лучше – он станет совсем иначе относиться к своей работе, будет появляться меньше оценок «пальцем в небо».
C. Чем раньше сделаны оценки, тем ниже их точность. Собственно, для уточнения оценок и устраиваются сессии планирования. Более того, любой план имеет вероятностный характер (по статистике оценки, сделанные на ранних этапах проекта отклонены от реальности примерно на 400%). Бороться на ранних этапах проекта с этими проблемами можно только хорошим ТЗ. Нет требований – нет нормальных оценок. Не формализовали требования - получили риск. Пусть это понимают все.
D. Планирование – КРI дизайнера, который отражается на его вознаграждении. Плохо планируешь работу – поможем это делать лучше, но ты отвечаешь за сроки. Цель здесь не запугать дизайнеров, а переместить его стиль планирования из области «ну как-то так» в область расчетов. Расчеты основываются на предыдущем опыте, здравом смысле и простой математике – разбили задачу дизайна на серию подзадач, оценили, обсудили с руководителем, переоценили и т.д. Кстати, чем лучше дизайнеры понимают глобальную цель проекта, тем лучше он поймет свою задачу и тем точнее будет оценка ее длительности.
E. Чем раньше в проекте начинается управление рисками, тем лучше. Спорю на шоколадку, что у тебя в компании управления рисками нет в принципе (это почти норма, оно мало где есть даже в крупных компаниях). :-) Но чем скорее эта практика появится в твоей компании, тем лучше.
Предположим теперь, что мы подняли культуру планирования на новый уровень, пусть и не сразу, а постепенно, шаг за шагом. Мы получили от команды оценки длительности исполнения задач. Как теперь сделать план, который работает?

(продолжение следует) :-)

Re: Созрел, кстати, вопрос :)

Итак, продолжаем.
Предлагаю воспользоваться техникой, предложенной Э.Голдраттом и хорошо развитой в применении к управлению проектами  Лоуренсом Личем. Суть методики состоит в следующем. При традиционном планировании проблемы, связанные с неопределенностью (т.е. с законом Мерфи), законом Паркинсона и одновременной работой сотрудников над несколькими задачами (например, в нескольких проектах), решают включением в задачу всех рисков и неопределенностей. Другими словами, для каждой задачи пытаются минимизировать риски, включая в нее резервное время. При таком подходе руководитель контролирует срок исполнения каждой задачи, который жестко задан – исполнители стремятся выполнить задачу в отведенное для этого в плане время. Есть много негативных влияний такого подхода, например, пресловутый «синдром студента» - исполнитель все время откладывает начало работы над задачей. Есть и другие негативные факторы, один из важнейших  – досрочное завершение задач не только не означает досрочного выполнения проекта, но и вообще не влияет на скорость его завершения. Ну и не будем забывать про запаздывание зависимых задач (= запаздывание программистов после дизайнеров в рассматриваемом случае). Подробнее о негативных последствиях можно почитать тут.
Все эти проблемы и решает методика Голдратта (ССРМ), получившая название теории ограничений. В ней рассматривается понятие критической цепи – критического пути проекта, получившегося после выравнивания ресурсов. В отличие от традиционного подхода, мы не закладываем буфер на каждую задачу, а суммируем буферы в конце проекта, избавляясь от неопределенности. Этот буфер резервного времени защищает нас от вариаций в плане. Сами задачи оцениваем с 50% обеспечением риска по времени (= сокращаем оценочное время в 2 раза для каждой задачи). Получаем примерно такую картинку:         
 
В методике используются и другие типы буферов – буферы ресурсов, буферы на слияние нескольких задач.  Они хорошо описаны в книге Лича, поэтому не останавливаемся на этом подробно – за определенное время до начала задачи мы предупреждаем члена команды, что у него появится задача из критической цепи. Это время – ресурсный буфер первого типа.  Дополнительные или альтернативные ресурсы для задач критической цепи – ресурсный буфер второго типа.
В итоге алгоритм действия выглядит так:
  • Оценить длительность исполнения задач. В качестве оценки длительности задач брать оценки с 50% покрытием неопределенности.
  • Исключить конкуренцию за ресурсы выравниванием нагрузки.
  • Использовать проектные буферы. Вставить проектный буфер в конце проекта для аккумуляции резервного времени (изначально – примерно 50% от длины пути критической цепи).
  • Использовать ресурсный буфер для предотвращения ситуации нехватки ресурсов.
  • Не допускать многозадачности ресурсов (один из вариантов – планирование задач от конечной даты).
  • Члены команды должны передавать результат своей работы на следующий этап, как только она завершена.
  • Управлять не вехами проекта, а проектными буферами, стремясь сохранить не промежуточные вехи, а конечную плановую даты завершения.

Re: Созрел, кстати, вопрос :)

Конечно, вышеописанное – только краткая идея, а не подробная рекомендация. Потому что подробные рекомендации можно найти тут:
http://en.wikipedia.org/wiki/Theory_of_constraints
http://www.focusedperformance.com/articles/ccpm.html
http://www.ozon.ru/context/detail/id/4784265/
http://www.ozon.ru/context/detail/id/4341360/
http://www.ozon.ru/context/detail/id/6258664/
 
Если решишь воспользоваться вышеперечисленными советами, пожалуйста, расскажи, что делал и что получилось  – обсудим и двинемся дальше. :-) Можно сюда или на почту: psilonsk@gmail.com

Edited at 2011-10-24 08:33 pm (UTC)

меня тоже интересует этот ворос.

Где почерпнуть инфы, какаие есть труды нормальные. По менеджменту и прочему? То есть мне нужна матчасть по управлению проектами, чтоб знать, какие бывают, к примеру, проектные методы или как там вы говорили? =)

благодарствую!

  • 1