Несмотря на то, что мы уже давно живём в 21-ом веке, а методологий по управлению проектами существует, по меньшей мере, с десяток, очень часто приходится сталкиваться с тем, что управление проектами по разработке изделий либо не ведётся, либо делается вручную на бумаге или, в лучшем случае, в таблице Excel. Конечно, бывают и достаточно зрелые организации, в которых осознали потребность в специализированных инструментах – корпоративных системах по управлению проектами (КСУП), таких как, например, MS Project. Но это, как правило, исключение.
Из-за отсутствия отработанных подходов к управлению проектами разработки руководителям чаще всего не видно, кто из специалистов чем занят, и когда освободится. Если ему требуется выяснить, кому поручить новое задание, он может обзванивать своих сотрудников по телефону или постараться это узнать в личной беседе. Обычно это выглядит так: «Николай, ты сейчас чем занят? Много ещё осталось? Это откладывай, вот есть срочное задание, ему нужно дать «зелёный свет». И Николай добросовестно переключается на новый проект. Спустя какое-то время выясняется, что новая задача не такая уж и срочная, ну или там не хватает данных и требуется дополнительная проработка и всё, что к этому времени было сделано, мягко говоря, не подходит. Кроме того, предыдущая задача (с которой Николая сняли) оказывается чрезвычайно важной и её нужно было завершить ещё вчера. Наш герой возвращается к первоначальной задаче и тратит некоторое время, чтобы «погрузиться» в проблему, т.е. вспомнить, что он делал, какие были идеи, что следовало бы не забыть. В зависимости от количества параллельных задач и сложности проектов время переключения может быть достаточно большим и зачастую превышать то время, которое бы потребовалось на выполнение задачи без лишних переключений.
Вторая неприятность, с которой сталкиваются руководители подразделений, это неизвестность на каком этапе находится проект (сколько сделано, сколько осталось, когда будет завершен). Если нет КСУП, а проектами не управляют, то выяснить, как идут дела, можно только вручную: по телефону, сделав рассылку или в личной беседе. Тут нужно помнить ещё и о том, что над проектом трудятся люди, которым, если они в процессе, бывает трудно признаться в том, что они не успевают, а иногда они вообще этого не осознают, полагая, что всё идёт по плану и они прекрасно справляются. В ряде организаций от сотрудников требуется заполнять какие-либо формы отчётности о том, что они сделали, по какому проекту, сколько осталось. После этого руководитель пытается обработать полученные сведения (естественно, в ручном режиме). Отчётов может быть много, степень детализации может различаться. Т.е. получить реальную картину происходящего достаточно сложно. Кроме того, пока происходит обработка отчётности, ситуация по проекту может измениться, т.е. руководитель будет обладать неактуальной информацией по проекту.
Третья распространенная проблема - сложность оценки сроков по новым проектам (т.е. если мы сейчас запустим ещё один проект, то когда мы РЕАЛЬНО его выполним с учётом всех других проектов). Как правило, заказы принимают одни люди (например, менеджеры по продажам), а выполнять их приходится совсем другим (конструкторы, технологи, производство). Естественно, менеджер предупреждает клиента о том, что срок выполнения заказа нужно согласовать с разрабатывающими и производственными подразделениями предприятия и берёт на это пару дней. Далее возможны различные сценарии, суть которых сводится к тому, что предприятие не может оценить реальный срок выполнения заказа. Если руководство предприятия дорожит репутацией и по-человечески относится к своим сотрудникам, то клиенту называется весьма отдалённый срок (всегда есть вероятность получить согласие). Конечно, заказчик может начать возражать: «Да вы что? Мне надо завтра». Ему отвечают: «Ну, понимаете, у нас очень высокая загрузка ресурсов, мы не успеем», а доказать, обосновать (показать план-графики по другим проектам, вывести сводку по доступным ресурсам) обычно не удаётся. А ведь это было бы правильно, «по-взрослому». Поэтому менеджер просто разводит руками и говорит, что ничем помочь не может, а клиент уходит к конкурентам (если они есть, конечно; если конкурентов нет, то статью можно дальше не читать). Часто руководство организации идёт на риск, и менеджер пытается выяснить у клиента его пожелания и, чтобы не потерять заказчика, называет срок, близкий к этому, невзирая на реальные возможности.
Наконец, на предприятиях, выполняющих государственные заказы, принято планировать работы с даты окончания (т.е. срок выполнения заказа спускается «сверху»). В этом случае бывает сложно оценить потребность в ресурсах (т.е. если мы сейчас запустим ещё один проект, то сколько потребуется ресурсов, чтобы выполнить его в срок, и чтобы при этом не пострадали ранее запущенные проекты). Здесь многие менеджеры руководствуются принципом: «Главное получить этот заказ, а потом как-нибудь выкрутимся». В результате заказчика заверяют, что всё будет выполнено в срок и с наилучшим качеством, получают заказ, а потом героическими усилиями стараются этот заказ «вытянуть». В подавляющем большинстве случаев это не удаётся сделать, сроки срываются, репутация страдает. Конечно, кого-то это не смущает, ведь клиентов так много…
Прочитав про все эти типовые проблемы, поневоле задаёшься вопросом: «А как надо?» и «Что значит - эффективно управлять проектами разработки?». Давайте попробуем разобраться в этих вопросах...
Во-первых, мы всегда знаем загрузку специалистов и имеем представление о доступности ресурсов. Это выражается в том, что у руководителя подразделения есть инструментарий, который позволяет оперативно получать сведения о том, кто из его сотрудников трудится над каким проектом в текущий момент времени. Мы знаем, когда он освободится (или когда у него есть «окна»). В этом же инструменте отражаются сведения о том, когда сотрудник уходит в отпуск.
Во-вторых, по каждому проекту у нас есть чёткое понимание ситуации (мы владеем актуальными сведениями о ходе выполнения, знаем, что осталось, и когда проект завершится). Также как и в предыдущем случае, здесь речь идёт о наличии инструмента, который позволяет в онлайн режиме получать «срез» по проектам. Т.е. видеть, какие задачи выполняются, какие задачи скоро должны начаться, какие задачи отстают от план-графика и требуют оперативного вмешательства, по каким задачам можно допустить небольшое отставание, а по каким это невозможно (задачи, лежащие на критическом пути). Более того, мы можем не просто довериться проценту завершения, который указал пользователь, но увидеть, что именно было сделано по задаче, какие документы разработаны: КД, ТД, расчёты, отчёты об испытаниях. И уже глядя на эти документы, можно понять, соответствует ли процент завершения реальности.
Наконец, мы всегда можем реально оценить сроки нового проекта с учётом уже запущенных. И, что немаловажно, мы можем обосновать этот срок перед заказчиком. Это решается просто. Так как все проекты ведутся в КСУП и используется единый пул ресурсов, то мы видим все назначения всех пользователей. Когда запускается новый проект, мы составляем план-график и назначаем исполнителей. При этом инструменты КСУП позволяют находить «окна» и показывать, когда нужный нам ресурс освободится. После выполнения этих операций мы проверяем, нет ли перегрузки у каких-либо исполнителей. Если перегрузка есть, мы можем сделать выравнивание загрузки. В этом случае для планируемого проекта КСУП автоматически передвинет отрезки диаграммы Ганта в соответствии с существующей загрузкой ресурсов. Да, конечно, сроки поползут. Зато они будут соответствовать реальности. Аналогичный подход можно применять при планировании с даты окончания (т.е. когда мы имеем жёсткие сроки окончания проекта). Вместо выравнивания загрузки мы определяем задачи, по которым требуется повышенное кол-во ресурсов (более 100%). С этим списком задач и цифрами можно обращаться к вышестоящему руководству с целью «выбить» дополнительные ресурсы для выполнения проекта. Всё это возможно при наличии на предприятии КСУП и отработанных подходов к управлению проектами.
Очевидно, что само по себе наличие той или иной системы по управлению проектами и методологии не обеспечит требуемого результата. Ключевым звеном в этой цепи, как всегда, являются люди – те сотрудники, которые работают в КСУП по выбранной методологии. Как правило, на любом предприятии, независимо от того, есть ли у них какая-либо КСУП или нет, в проектах разработки имеется три уровня ответственности. Планированием верхнего уровня занимается руководитель проектов верхнего уровня (например, главный конструктор). Он распределяет крупные блоки работ между своими замами или руководителями по направлениям. Те, в свою очередь, проводят декомпозицию работ и назначают конечных исполнителей (конструкторов, технологов) из своих отделов. Конструкторы выполняют проектирование в соответствии с поставленными задачами и своевременно предоставляют отчётность своим начальникам (средний уровень), а те – своим.
Давайте подробнее рассмотрим роль руководителя проекта верхнего уровня (РПВУ). Во-первых, он составляет план-график верхнего уровня (на уровне изделия). Здесь возможны различные подходы. На каких-то предприятиях в таких план-графиках раскрывается состав изделия (крупные узлы), внутри которых расписывается набор необходимых видов документов (КД, ТД, паспорта). На других предприятиях в план-графике верхнего уровня фигурируют такие задачи, как «Разработка КД», «Разработка ТД» - т.е. этапы подготовки к запуску в производство. Вторая задача, выполняемая РПВУ, это проверка декомпозиций, составляемых руководителями проектов среднего уровня, и их согласование. Наконец, он осуществляет контроль над ходом выполнением проекта в целом – на своём уровне. При необходимости он может углубиться в детали, посмотреть, что было сделано по проекту вплоть до документа (модели или чертежа).
Руководитель проекта среднего уровня (РПСУ), во-первых, получает крупные блоки работ от руководителя верхнего уровня и проводит декомпозицию работ (на уровне узлов изделия) – составляет план-график на подпроект. Это обусловлено тем, что он, как правило, является специалистом в какой-либо области и хорошо представляет, что именно требуется сделать, сколько времени это займёт, сколько понадобится ресурсов. Во-вторых, в его задачи входит распределение задач внутри отдела с учётом актуальной загрузки ресурсов. Т.е. он общается с исполнителями напрямую и хорошо представляет возможности и доступность каждого своего сотрудника. Наконец, также как и в предыдущем случае, РПСУ осуществляет контроль над ходом выполнения на своём уровне – на уровне подпроектов. При необходимости он также может углубиться в детали и посмотреть, что было сделано в рамках подпроекта, вплоть до документа (модели или чертежа).
В обязанности исполнителя, помимо выполнения непосредственно работы по проекту, входит связывание результатов с задачами и своевременное предоставление отчётности своему руководителю. Связывание задач с результатами их выполнения необходимо, если мы хотим иметь возможность видеть, что было сделано по задаче. Под своевременным предоставлением отчётности понимается своевременное обновление процента завершения задачи. Очевидно, что это должно выполняться в привычной среде, в которой работает исполнитель. Для конструктора и технолога такой средой является, как правило, PDM-система. Отчётность с помощью процента завершения является самым простым способом отслеживания хода выполнения проекта. Однако он может не обеспечивать необходимую степень точности, а в ряде случаев вводить в заблуждение. Например, что значит, что КД готова на 90%? Это значит, что готовы 90% чертежей, или каждый из чертежей готов на 90%? Первый вариант может быть приемлем. А вот второй вариант говорит о том, что КД не готова. В связи с этим существуют другие способы отслеживания хода выполнения. Например, при помощи фактических значений даты начала или даты окончания. По сути это отчётность по принципу «Да» или «Нет». Т.е. нас не интересует, на сколько процентов завершена КД. Нам важен только факт завершения. Немного жёстко, но зато справедливо. Мы же не можем отдать в производство чертёж, завершённый на 90%. Что мы получим: деталь или заготовку? Или мы получим 90% от детали? Ещё одним способом отслеживания хода выполнения является внесение данных о фактической и оставшейся длительности. С точки зрения исполнителя это вполне здравый подход. Ведь он всегда может посчитать, сколько он уже трудится над задачей и сколько, по его мнению, осталось. Проблема кроется в том, что вчера ему могло казаться, что осталось 2 дня, а сегодня он что-то переосмыслил и решил, что нужно ещё 3 дня. Т.е. процент завершения, рассчитываемый как «Факт.длит.»/(«Факт.длит.» + «Ост.длит.»), всегда будет «плавать». По крайней мере, до тех пор, пока оставшаяся длительность не окажется равной 0.
Мы с вами рассмотрели, чем занимаются участники проектов разработки по отдельности. Теперь давайте взглянем на процесс целиком. Всё начинается с руководителя проекта верхнего уровня, который разрабатывает план-график верхнего уровня и назначает ответственных за подпроекты. Руководители проекта среднего уровня, получив оповещение, проводят декомпозицию работ, согласовывают эти декомпозиции и планируют работу в своих отделах. Исполнители приступают к выполнению своих задач по оповещению, а, выполнив их, отчитываются перед своими начальникам. Сведения о ходе выполнения проекта стекаются к руководителям, которые осуществляют контроль и при необходимости предпринимают корректирующие действия. Т.е. всё достаточно просто. Условно это можно представить в виде пирамиды. При этом есть движение вниз (постановка задачи и распределение назначений) и движение вверх (сбор данных о ходе выполнения проекта).
Второй вариант, это разворачивание серверного решения КСУП (например, MS Project Server). По сравнению с предыдущим вариантом появляется возможность обеспечить доступ рядовым сотрудниками к своим задачам через WEB-интерфейс. Там же они смогут отчитываться об их выполнении и даже присоединять результаты выполнения. Правда, здесь нужно сделать оговорку, что это серверная КСУП не предназначена для хранения сложных, имеющих много ссылок на другие документы (например, сборки ссылаются на детали) и тяжёлых документов САПР. Присоединить текстовые документы или PDF всё же возможно (хоть это и не тривиальная задача, особенно, если файлов много). Благодаря тому, что пользователи смогут вносить данные о завершении задач, становится возможным получать автоматизированным способом эти данные на уровне руководителей проектов. Из неудобств стоит отметить, что рядовым исполнителям придётся работать в ещё одной программе – WEB-интерфейсе КСУП. Ах да, серверное решение стоит приличных денег…
Наконец, третий вариант – это решение, адаптированное под предприятия, на которых интенсивно разрабатываются и подготавливаются к запуску в производство новые изделия. Это решение подразумевает взаимодействие двух программ. Первая программа – это наиболее распространённая система по управлению проектами MS Project (локальная версия, например MS Project Standard). Вторая программа – система по управлению инженерными данными SWE-PDM. Взаимодействие обеспечивается с помощью специализированного модуля интеграции MSProject2PDM. Т.е. давайте исходить из того, что предприятие достаточно доросло, чтобы использовать MS Project, а не Excel для планирования проектов, и на предприятии внедрена (или планируется к внедрению) PDM-система, в которой работают конструкторы, технологи и другие сотрудники, участвующие в процессе подготовки изделия к запуску в производство.
В системе управления инженерными данными SWE-PDM преимущественно работают исполнители. Эта программа позволяет управлять данными проекта (хранить, контролировать доступ, защищать от несанкционированных изменений). Также в SWE-PDM имеются инструменты, которые позволяют реализовать любые бизнес-процессы, например «Согласование план-графиков». Наконец, SWE-PDM играет роль DashBoard’а (т.е. информационной панели), на которой пользователи могут видеть свои задачи и сроки выполнения.
Модуль интеграции MSProject2PDM обеспечивает автоматизированное взаимодействие двух программ. Для проектов MS Project модуль строит дерево задач в SWE-PDM. Для каждой задачи заполняет карточку данных основными сведениями (начало, окончание, длительность, ответственный). При создании или изменении назначений модуль рассылает соответствующие оповещения всем заинтересованным лицам. При обратном взаимодействии модуль зачитывает данные из SWE-PDM и обновляет план-график актуальными сведениями о ходе выполнения проекта.
В чём преимущества этого варианта по сравнению с рассмотренными выше? Во-первых, решается главная задача – управление проектом и назначениями пользователей. Во-вторых, обеспечивается связь задач с результатами выполнения, при этом PDM-система обеспечивает управление файлами проекта (в том числе САПР), позволяет проводить согласование план-графиков в электронном виде. Наконец, и руководители, и исполнители работают в привычной для них среде: в MS Project и SWE-PDM соответственно.
Нельзя не упомянуть ещё об одном преимуществе, которое мы получаем, используя связку MS Project и SWE-PDM. Всем хорошо известно об инструментах MS Project по составлению различного рода отчётов. В дополнение к этим инструментам добавляются отчёты, формируемые из SWE-PDM. Эти отчёты просты, позволяют получить моментальный снимок происходящего по проекту, а служба Reporting Service позволяет подать это в очень красивом виде с различными индикаторами прогресса. Помимо этого мы можем настроить рассылку таких красивых и понятных отчётов руководителям высшего уровня. Давайте представим, как утром главный конструктор приходит на своё рабочее место, включает компьютер и видит в почте аккуратно составленный PDF на одну страницу, в котором указано, какие проекты движутся хорошо, а по каким требуются корректирующие действия. При необходимости можно в отчёт включить перечень виновных… Что будет происходить дальше, думайте сами.
