Материал: 970

8)дефицит специалистов и/или высокая текучесть кадров;

9)разрыв в квалификации специалистов разных областей знаний;

10)нехватка информации о внешних компонентах, определяющих окружение ПП;

11)недостаточная производительность получаемой системы.

Среди наиболее часто упускаемых требований к ПП можно выделить:

·отсутствие функциональных требований к программам установки, настройки, конфигурации, к миграции данных и интерфейсам с внешними системами;

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

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

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

·переоценка проекта при каждом добавлении или изменении требований;

·интеграционная разработка проекта с периодическим уточнением требований, передача части рисков заказчику;

·учет в оценках трудоемкости и сроков возможности роста требований (резервирование риска).

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

·привлечения экспертов-консультантов на начальных этапах;

·учета в оценках трудоемкости издержек на обучение сотрудников;

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

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

·постоянное взаимодействие по вопросам реализации про-

екта;

·согласование пользовательских интерфейсов и разработку прототипа продукта;

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

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

Ошибки в оценках трудоемкости и сроков проекта связаны с принципиальной невозможностью точно определить эти величины на стадии инициации проекта (оценка трудоемкости имеет погрешность от –50 % до +100 %). Если не прилагать специальных усилий, этот «дамоклов меч» неопределенности будет висеть над проектом на всем его протяжении [26].

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

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

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

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

Мониторинг рисков — это процесс наблюдения и контроля за ходом исполнения принятых в отношении рисков планов и инициирование изменений в проекте. Другими словами, мони-

торинг и управление рисками — это процесс идентификации,

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

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

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

На основании анализа отклонений и трендов проекта мож-

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

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

2.4. Командообразование

2.4.1.Организация командной работы над проектом

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

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

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

заказчик — будущий владелец и пользователь результатов проекта, физическое или юридическое лицо, заинтересованное в осуществлении проекта и достижении его результатов. Следует учитывать, что заказчик и инвестор проекта не всегда совпадают;

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

руководитель проекта — проект-менеджер, физическое лицо, которому заказчик и инвестор делегируют полномочия по руководству работами при осуществлении проекта;

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

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

Всоответствии с методологиейMicrosoft Solutions Framework

вкоманде проекта рекомендуется выделять семь функциональных ролевых групп и шесть видов специализации сотрудников.

Функциональные ролевые группы:

1) группа управления программой — управление процес-

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

2) группа проектирования архитектуры— формулирова-

ние спецификации решения и разработка его архитектуры, определение структуры развертывания (внедрения) решения;

3) группа разработки ПП — определение деталей физического дизайна; оценивание необходимого времени и ресурсов на реализацию каждого элемента дизайна; разработка или контроль разработки элементов; подготовка продукта к внедрению; консультирование команды по технологическим вопросам;

4) группа тестирования — поиск и обнаружение дефектов; разработка стратегии и планов тестирования; тестирование;

5) группа управления выпуском — представление интересов отделов поставки и обслуживания продукта; организация снабжения проектной группы; организация внедрения продукта; выработка компромиссов в управляемости и удобстве сопровождения продукта; организация сопровождения и инфраструктуры поставки;