`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Тимур Ягофаров

Секреты планирования

+22
голоса

В продолжение рассказа о курсах по project management поделюсь тем, что вызвало интерес у меня и других участников. И на этот раз речь пойдет о составлении плана.

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

До тех пор, как я пришел на работу в конструкторское бюро, меня удивляло, как удается сформировать план создания какого-то сложного объекта, типа космического корабля. Ведь не может же отдельный человек разбираться в деталях во всем, что нужно для его создания. В таких больших проектах план формируется блочным способом, и PM (а в былые времена – главный конструктор) не задумывался о том, сколько и каких гаек и болтов должно быть выточено к определенному сроку. Контроль за каждой составляющей делегировался ответственным. Они-то и должны были каждый на своем уровне формировать план.

Поэтому даже если вы не PM, то умение составлять план от вас в любом случае потребует жизнь, ведь все мы работаем в связке с кем-то. И работа каждого – это «кирпичик» в общем здании бизнеса, чем бы он ни занимался: хоть материальными объектами, хоть нематериальными идеями.

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

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

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

А как планируете свою деятельность вы? Какие используете для этого инструменты?

+22
голоса

Напечатать Отправить другу

Читайте также

Дуже б хотілось планувати свою діяльність, але на жаль, доволі складно визначити скільки піде часу на реалізацію того чи іншого алгоритму.
Тому приходиться визначати з дуже великим запасом і це більше схоже на перелік намірів, а не на план. І чим більше у проекті задіяно людей тим приблизніший план.
----------------------------------------------
Мерітократія, честь, компетентність, служіння.

Есть два мировых лидера-продукта в области автоматизации процессов планирования - Cognos и Hyperion :)

OMG-псот:
не все что "планирование" имеет отношение к управлению проектами

А зачем ограничиваться только "управлением проектами"? Это ведь далеко не та тема, что близка широкой аудитории

"в продолжение рассказа о курсах по project management"

Для того и придумали проектную методологию, чтобы увеличить эффективность - уменьшить затраты на выбор методов и механизмов.
А мы, внезапно, смешиваем, путаем и разбавляем.

ПС. Имхо тема "управление проектами" для широкой аудитории, которая занимается компьютерным бизнесом - может почти совпадать со всей аудиторией. Содержательный расссказ о алгоритмах и методологии планирования в указанных системах, боюсь, будет не совсем просто воспринять даже узким спеециалистам. А непонимание в целостности не специалистами только навредит, потому что системы такие)))

Отчасти согласен с Вами, но умному человеку лишняя информация никогда не помешает, как говорится: кто владеет информацией, тот владеет миром ;)

Я привел примеры систем планирования финансов, т.к. в них, как мне кажется, заложены основные принципи и методики, который на данное время являются самыми передовыми.

Это скользящее планирование, когда план составляется не на год, например, а на 15-18 месяцев, и например каждый месяц или 3, он корректируется и добавляется следующие 1-3 месяца в план. В этом случае невозможна такая ситуация, как: конец года, а мы без бюджета на следующий год (как наше правительство :) )

Или планирование по драйверам, когда гл.конструктору не нужно думать о каждой "гайке".

Или коллективное планирование, когда каждый сотрудник имеет свой кусочек плана, за который он отвечает. Чем подробнее будет разделена ответственность, тем точнее будет план.

Сюда же реализация планирования "сверху-вниз" и "снизу-вверх" можно отнести.... и много-много-много чего еще можно рассказать, не привязываясь конкретно к планированию финансов и управлению проектами.

Ну да, знание метода планирования набегающей волной на экзамене тоже ведь никто не отменял.
ПМ, время - это ресурсы, использование которых должно быть рациональным. Потому принцип декомпозиции работ (построение дерева разбиения задач) оринетирован на понимание зависимостей и контроль эффективного использования этих самых ресурсов - в виде описания требуемого результата (актива) и механизмов\методов его измерений (а это тоже затраты ресурсов, включая). И далее - понимание форм реакции на отклонения, управления рисками с учетом затрат на контроль. С осознанием, что работа специалиста без промежуточной информации неделю (40 чел.часов) - это много, 2-х с понедельника до обеда среды (40 ч.ч.) нормально, а 720 с утра и до обеда в попытках судорожно в 15-минутном цикле отчитаться и поправить отставание проекта - профуканный человеко-год.
Собственно, количесво ресурсов, потратив которые желательно обозначить результат, может варироваться, и зависит от проекта. Но рассказ про 15-минутные вехи - это из области фантастики для начинающих микро-РМов. Мелочный контроль каждого выдоха с отчетом времени членов команды еще никогда не приводил ни к чему хорошему.
Если такой проект, что в нем много важных микрособытий, то все их вполне можно перевести в плоскость контроля качества и чек-листов (хочешь сделать правильно - сделай отчсчет сам). Захламлять план-график это зло, ведь его не только РМ читает. Собственно, как раз попытка чрезмерно выпрямлять "исполнительскую дичциплину" в проекте (который есть творческая деятельности с нестандартными результатами, иногда процессами, иногда наборами процессов) - путь к хаосу.
Т.е. все правильно, но реализовать такие рекомендации может только опытный ПМ, а для неопытных такие советы выглядят как стимулирование получить свою часть опыта на провокации микромэнеджмента.
Просто здравый смысл: пусть в проекте 8 человек (тогда ПМ - играющий спец), и ПМ намикропланнировал этапос со средней длительностью в 2 часа. Тогда в неделю у ПМ-а 140 событий, которые надо проконтролировать, за которые членам команды надо отчитаться, самое главное - отреагировать на отклонения +-7 мин. Ибо отсутсвие реакции ПМа при таких требованиях к членам команды микропланнировать (и соответсвующих затрат на него всех, а не только ПМа) - путь к недоумению и формализму.
Потому конкретно мне интересно только, что сделал программист за день (коротко в пару строк и конкретно, без оценок типа "написал 30% модуля"), и не дай БГ за два часа (для таких, которым надо котролировать часы, есть руководитель группы), или сколько бетона залили за пятидневку (но если сорвется график за день - эскалация, чтобы я был в курсе).

Что касается матрицы приоритетов. Не совсем понял а) причем операционная деятельность, приоритеты - при управлении проектами в) не совсем понял, что имеется ввиду дорогое: ПО в рамках подходов 6Sigmа, ПО "расширения" стратпереходов в ТО Голдрата и тп. в) чем плохи стратегические карты, инструменты для построения и анализа которых дешевы.
Если речь шла о системах, реализующих один из алгоритмов анализа компонент на больших объемах данных, то проекты тут тем более ни при чем - по определению. Только где-то там, на 75 уровне "оптимизированный" статистического управления качеством возникает возможность наложить технологический уровень организации на планирование. Но я о таких организациях в СНГ не слышал, а проект - это искусство возможного.

Собсвенно, в этом моем излиянии меня занимают только следующие вопросы: уот э фак что за ПО, если не секрет? И каковы сценарии его применения в проектах?

Потому как инициация проекта с необходимыми параметрами - это и есть результат приоретизации, более того - взаимосогласованный и непротиворечивый с операционной деятельностью. И не важно какова культура и слова, происходит приоретизация в рамках стратегического управления, или в рамках управления портфелями проектов (но не программами) - хороший ПМ ханимается обеспечением выполнения проекта: в графике (потому все что на критическом пути прямо сейчас - у него приоритет), в бюджете, с качеством, эскалацией в случае реализации рисков.
Но не приоритетами вне проекта. Да, отличный ПМ в первую очередь управляет отношениями (в проекте) и немного рядом. Но если он начинает заниматься приоритетами организации, или на правах самого умного тащить инструментарий и создавать микросреды в организацпии, конфликта интересов и ухудшения выполнения проекта не избежать.

Планирование "набегающей волной" допустимо, если есть четкое понимание что более-менее детальное планирование "сейчас" неэффективно, так как нет однозначного понимания перечня подзадач, их структуры и зависимостей. А планирование избыточного кол-ва задач недопустимо, так ведет к перерасходу бюджета. Но простое откладывание планирования (т.е. мы знаем что надо делать, когда и сколько для этого нужно ресурсов, но займемся этим позже, так как сейчас нет времени) однозначно приведет к проблемам по ходу реализации проекта.

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

Согласен, но есть нюанс: отложенное планирование vc детальное планирование.
(Забавно, что для того, чтобы четко понять что сейчас планирование неэффективно - нужен опыт и умение пользоваться правильными инсрументами.)

Обычно нормальные проекты (под нормальным понимается такой, для которого, например, есть проектная\рабочая документация, хорошо документированные аналоги), которые дляться год-полтора, методом набегающей и планируются. Не в аспекте "отложенного" планирования (а как иначе подписаться, если цена фиксированная +), а в смысле масштаба-детализации. Понятно, даже в таких проектах основные оттоки на оборудование и внешние ресурсы четко привязываются и моделируются варианты. Но без привязок операций отдельных работ по часам)) Как раз при использовании статистических методов по опыту не всегда полезно на первых этапах перегибать с детализацией удаленных по времени этапов - усложняет интерпретацию или ничего к ней не добавляет.
Опять же, подход позволяет немного "размазать" в циклах затраты тру-ПМа на планирование.

Естественно, случаи и проекты бывают разные.
Если все длиться 4 месяца, все понятно, то лучше напрячся и запланировать более-менее детально, чтобы изначально ставить полную задачу исполнителям.

Другой случай (встречется нередко), когда исполнитель, который называется ПМом в проекте, не может качественно провести именно планирование, управлять архитектором проекта и др пр. Потому реально процессами планирования на начальном этапе проекта и двиганьем рамок занимается некий "главный ПМ"-технический директор-начальник управления, вовлекая ПМа-исполнителя. Ясно, что в таком случае чисто психологически, чем детальнее изначально - тем лучше, даже если понятно, что вроде как неэффективно - чтобы был шаблон (правильность, зачем, особенности такого подхода - другой вопрос).

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

Важно не только что бы задача была выполнена, а что бы был достигнут нужный результат. А это далеко не всегда одно и то же. Иногда кол-во задач бывает избыточно и нужный результат достигается раньше времени. Хотя чаще наоборот: вроде все сделали, но результат достигнут не полностью. Соответственно нужно возвращаться к анализу и новому витку планирования, но зачастую это видно на этапе 60-70% степени выполнения задач.

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

Из инструментов использую: Project Scheduler для Android (там постоянно 2-3 проекта болтаются в активном статусе) и MS Project.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT