Процедуры ведения проекта КИС

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

1. Полное документирование проекта. Не надо боятся тратить время и деньги на документирование процесса разработки.

2. Обмен информацией об этапах проекта между участниками проекта.

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

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

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

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

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

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

Дата добавления: 2014-12-10