Электронная библиотека » Виктор Николенко » » онлайн чтение - страница 12


  • Текст добавлен: 14 февраля 2024, 12:07


Автор книги: Виктор Николенко


Жанр: Прочая образовательная литература, Наука и Образование


Возрастные ограничения: +16

сообщить о неприемлемом содержимом

Текущая страница: 12 (всего у книги 32 страниц)

Шрифт:
- 100% +
3.3 Планирование инженерного проекта

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


Целью процесса технического планирования проекта является разработка и координация эффективных и выполнимых планов. Удобно использовать в практике управления большими проектами четырехуровневую структуру планов:

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

• Единый сквозной план-график (ЕСПГ) программы. Используется для решения задач оперативного и директивного планирования по программе. Этот план содержит все основные работы, запланированные для реализации программы, и имеет также графическое представление. Представляет собой интегрированный сетевой график, содержащий все отдельные рабочие пакеты, задачи или действия более низкого уровня, необходимые для поддержки событий, достижений и критериев мастер-плана.

• Системно-инженерный план (СИП). Определяет для всех участников, как проект будет технически управляться в рамках ограничений, установленных мастер-планом. Детализирует особенности системного подхода.

• Детальные планы-графики. Частные планы работ подразделений, участвующих в проекте, отображающие текущий этап проекта или программы.


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

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


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

A. События, которые включают основные технические усилия, а также обзоры и ключевые демонстрационные моменты.

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

C. Критерии выполнения. Для каждого из результатов по предыдущему пункту указаны критерии, которые можно измерить. Например, «технический отчет завершен», «испытание по проверке надежности принято», и т. д.

D. Хронология по вехам. Для требуемой последовательности событий указаны необходимые длительности для завершения работ вовремя.


В планах процесса проектирования систем удобно выделить основные категории для контроля:

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

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

3. Технические цели. Здесь излагают эксплуатационные цели для системы.

4. Обучение. Описывают цели обучения, метрики измерения результатов, учебное заведение, а также поддержку, основные сроки и графики обучения.

5. Стандарты и процедуры. Должны быть перечислены внутренние стандарты и процедуры, относящиеся к проекту (человеческие ресурсы, бухгалтерский учет, контроль качества и т.д).

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


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

a) иерархическая структура (состав) продукта, является ключевым входом для структуры разбиения работ;

b) иерархическая структура разбиения работ (СРР), включает организованное представление всех действий проекта, которые должны быть указаны, проверены и выполнены в программе для достижения требований и в рамках бюджета;

c) иерархическая структура организации, включает организованное представление программных команд. Каждый рабочий пакет СРР должен быть передан выделенной группе в компании, команде проекта или поставщику.


Для составления плана работ проекта необходимо в качестве исходных данных сформировать структуру разбиения состава продукта и структуру разбиения работ проекта. СРР используется для выполнения следующих задач:

• Определить полный объем работ проекта с точки зрения результатов и далее разложить эти результаты на компоненты. Эта декомпозиция содержания проекта отвечает потребности руководства в контроле с соответствующим уровнем детализации.

• Создать основу планирования, на которой будут базироваться управленческие отчеты о состоянии проекта и его ходе.

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

• Обеспечить исходные данные для других процессов управления проектом и достижения веховых результатов по срокам.


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

a) графического изображения или текстовой схемы содержания проекта;

b) контроля всех результатов на протяжении всего жизненного цикла проекта;

c) поддержки интеграции и оценки графика и эффективности затрат;

d) определения целей производительности;

e) мониторинга, а также показателей затрат и графиков производительности, связанных с проектом;

f) идентификации ключевых контрольных точек (вех) управления, которые используются для коммуникации и контроля объема, качества, технической обоснованности, графика и эффективности затрат.

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


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

• Все 100% работ и результатов проекта должны быть явно включены в СРР.

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

• Результаты должны быть логически разложены на уровни, отражающие способ их производства (проектирование, закупка, субподряд, изготовление).

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

• Результаты выполнения пунктов СРР должны быть ограничены по размеру и определению для эффективного контроля на нижнем уровне рабочих пакетов.

• При изменении объема работ необходимо обновить СРР.

• Каждая запись в СРР, представляющая субподрядные или внешние результаты, должна напрямую соответствовать ответным записям в СРР субподрядчика.

• Все важные отчетные элементы (например, обзорные совещания, ежемесячные отчеты, отчеты о тестировании и т. д.) включены и идентифицированы в СРР.

• Набор ключевых работ по управлению проектом (управление процессами, услуги и обеспечение, информация, коммуникация, отчетная документация, обучение и программное обеспечение) должны быть определены как элементы СРР.


В таблице 2 приведен состав пунктов типового разбиения работ программы создания инновационного продукта. Базовые блоки СРР должны присутствовать при разбиении любых технических систем, что важно для полного возмещения затрат по проекту. Детальное разбиение может отличаться в зависимости от типа и уровня сложности системы.



Можно видеть, что кроме собственно декомпозированного состава продукта или системы, включая действия по ее разработке (п.1) в СРР присутствуют управленческие усилия (пп.2,3), оснащение оборудованием для верификации и валидации (пп.4,6,7), закупки для производства (пп. 8,9) и ППО (п.10), а также затраты на обучение пользователей и сервисного персонала (п.5).


Рабочий пакет, согласно руководству PMBоK, представляет собой обособленную задачу для планирования и выполнения на самом низком уровне структуры декомпозиции работ. Содержание каждого рабочего пакета аналогично мини-контракту и включает:

1) определение задачи;

2) конечные результаты (для отчета или передачи в другие пакеты);

3) оценку сроков и график проведения работ;

4) требования к ресурсам;

5) смету работ (бюджет пакета);

6) исходные данные и необходимые результаты предыдущих этапов;

7) ответственность за исполнение и качество;

8) оценку рисков.


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


Все работы в СРР должны быть оценены по длительности и трудоемкости, обеспечены ресурсами, запланированы, учтены в бюджете и определены для контроля. СРР состоит из двух частей: структуры и определения компонентов для исполнителей. Это механизм, который делит и организует объем проекта на единицы рабочих пакетов, чтобы каждую единицу можно было оценить, выделить ресурсы, запланировать, заложить в бюджет и контролировать во время отчета о ходе выполнения.

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


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

1. Объем, техническое задание, устав проекта, включая цели, системные требования.

2. Обеспечение деталей работы (СРР, рабочие пакеты, необходимые ресурсы).

3. Определение входов, выходов и результатов задач.

4. Определение времени начала и окончания для каждой задачи.

5. Оценка продолжительности задачи и потребностей в ресурсах для выполнения каждой задачи. Потребности включают численность персонала по дисциплинам и по срокам участия, бюджет для выполнения задач и специальные ресурсы (например, программные приложения, средства обучения и тестирования продуктов).

6. Определение критического пути (самого длинного временного пути запланированных действий до конца проекта).

7. Организация проекта (опыт, навыки, обязанности персонала).

8. График проекта (хронология, ключевые и поставочные вехи).

9. Бюджет проекта (разбивка по пакетам работ и ресурсам, расходы и доходы как функции времени).

10. Процедуры обзоров и контроля (обзоры работы, поддержка качества, оценка на контрольных рубежах, контроль изменений, мониторинг рисков).


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


3.3.2 Системно-инженерный план


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

Данный план является основным источником информации при оценке способности и возможностей подрядчиков выполнять технические действия, связанные с разработкой системы, а также дает хорошее представление о понимании системы и того, что необходимо для ее реализации. Полезно изучить ГОСТ Р 58607– 2019/ ISO/IEC/IEEE 24748—4: 2016 «Системная и программная инженерия Управление жизненным циклом Часть 4 Планирование системной инженерии».


Задачи плана системной инженерии вкратце перечислены ниже.

a) объясняет потребности и ожидания заказчика; заявляет цели, системные границы и масштаб, допущения и ограничения проекта;

b) план суммирует наиболее важные показатели проекта: характеристики системы, затраты, сроки и риски;

c) обеспечивает коммуникации между менеджером и инженерными группами проекта, детализирует техническое содержание инженерной работы;

d) представляет ключевые решения и предложенные архитектуры системы;

e) включает ключевые элементы управления интеграцией: собственно интеграцию, сроки, стоимость, контроль качества, материально-техническое обеспечение этапа, персонал, коммуникации, риски;

f) предоставляет специфику технических усилий команды проекта: какие технические процессы будут использоваться при реализации деятельности; какие соответствующие рабочие продукты будут сделаны; определяет стоимость и график, связанные с выполнением деятельности; описывает конечные результаты разработки: что будет представлено, кем, когда;

g) должен быть написан простым языком и предназначен для управления проектом и информирования общественности;

h) рассматривает надежность, доступность, ремонтопригодность, ППО и интегрированную логистическую поддержку продукта.


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

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

Детальное содержание СИП можно найти в книгах [3, 4, 10…12].

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


В некоторых больших проектах можно добавлять планы конкретной деятельности, например:

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

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

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

4. План управления интерфейсом определяет все важные интерфейсы внутри и вовне продукта, и определяет обязанности организаций по обе стороны интерфейсов.

5. План технических обзоров содержит цели, время, место, докладчиков и участников, темы, критерии входа и критерии выхода по каждому обзору проекта.

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

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

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

9. План обучения содержит детали обучения, которое необходимо провести для персонала ППО, и для эксплуатации.

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

11. Другие планы могут включать вопросы обеспечения безопасности, управления ресурсами, и др.

Эти планы должны быть подготовлены для большой программы, когда они явно необходимы.


3.3.3 Контроль исполнения планов работ.


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

• Разделить сложный продукт на управляемое количество модулей, которые могут включать одну или несколько систем продукта.

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

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

• Обучить членов команды выбирать и применять инструменты проекта.

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

• Наладить для каждой группы регулярное (еженедельное) предоставление информации о состоянии своих результатов в соответствии с их СРР руководству управления программой.


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


Надзор за исполнением планов фокусируется на необходимых направлениях:

1. Коммуникационное управление.

2. Управление конфигурацией.

3. Управление данными.

4. Управление производительностью и оценка.

5. Обеспечение качества и контроль качества.

6. Управление интерфейсом.

7. Интегрированная разработка, отслеживание и контроль расписания.

8. Официальные технические обзоры.

9. Управление партнерами, подрядчиками и поставщиками.

10. Контроль изменения системных требований.


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

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

B. Еженедельная встреча предназначена для предоставления обновленной информации о продвижении за неделю. Оформляется стандартный отчет с ключевыми достижениями, проблемами, необходимой поддержкой и дальнейшими шагами.

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


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

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

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

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


Традиционно для измерения текущих результатов проекта применяют следующие оценки прогресса:

1. Количество достигнутых вех проекта на дату проверки, например, завершение чертежей, отчетов, или решение конкретных технических проблем.

2. Испытания и демонстрации. Фиксация результатов от простых тестов элементов на промежуточных этапах до сертификационных испытаний готовой системы.

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

4. Готовность проектной документации. Используют грубые количественные оценки процента завершения заданного в плане набора документов (чертежи, схемы, функциональные схемы, объемные модели, сборочные чертежи, руководства и процедуры тестирования). Достаточно использовать по рабочим пакетам следующую шкалу: 0%, если работа не начата; 50%, когда работа в процессе; 100%, если работа завершена.

5. Наличие используемых ресурсов и своевременность запросов на их изменение.

6. Изменения, ошибки и доработки. Количество изменений и ошибок должно уменьшаться по мере того, как проект приближается к завершению.


Контроль расходования бюджета проекта можно осуществлять посредством метода освоенного объема, рис.5. Кривые на графике отражают необходимую для анализа информацию (расшифровки показаны справа).


Рис.5 Контроль бюджета методом освоенного объема.


Если проект отстает от графика, необходимо вводить корректирующие мероприятия. Фактически менеджер должен выбрать между вариантами реагирования с учетом уровня рисков:

a) использовать сверхурочную работу, оценить, когда и как долго;

b) временно нанять недостающий персонал, с учетом потребного обучения;

c) использовать резервные запасы бюджета, времени и ресурсов, и др.


Опыт коррекции отставаний графика от плана показывает, что:

• любая задержка графика приводит к перерасходу бюджета на содержание простоев команды проекта;

• если нагонять плановый график без увеличения привлеченных ресурсов, это всегда будет стоить дороже;

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

• замедленное движение в проекте увеличивает его плановые затраты.


Часто обещаемые варианты применения для коррекции отставания «нагонного» графика (без добавления ресурсов) не работают по понятной причине. Вряд ли выполнимо ускорение работ, если команда не справляется с исходным, более щадящим графиком. Нужно установить причины отставания. Сверхурочные работы не рекомендуется применять постоянно, качество будет падать.

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

Нужен регулярный контроль эффективного использования рабочего времени. Реальный уровень персональной загрузки должен находиться на отметке 75…80% от располагаемого календарного рабочего времени с учетом ежегодного месячного отпуска сотрудника. Небольшая часть времени затрачивается на медицинские бюллетени, командировки, обучение. Затраты рабочего времени удобно фиксировать еженедельно. В одной из моих организаций удалось после организации контроля за три месяца повысить коэффициент использования рабочего времени с 40% до 70%, то есть фактически вдвое увеличить производительность труда команды за счет уточнения постановки целей.

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


Страницы книги >> Предыдущая | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | Следующая
  • 0 Оценок: 0

Правообладателям!

Это произведение, предположительно, находится в статусе 'public domain'. Если это не так и размещение материала нарушает чьи-либо права, то сообщите нам об этом.


Популярные книги за неделю


Рекомендации