2. Процессы управления разработкой пс. Структура управления разработки пс. Планирование составление расписания по разработке пс. Аттестация пс.
Управление проектом – управление производством продукта в рамках отведенных ограниченных средств и времени, с учетом требований к продукту.
Вся деятельность предприятия делится на проектную и операционную. Операционная деятельность представляет собой ежедневную рутину, например: ведение бухгалтерского учета, расчетно-кассовое обслуживание и т.д. Внутренняя проектная деятельность предприятия направлена на оптимизацию его операционной деятельности. Примеры: внедрение ПО с целью автоматизации бизнес-процессов, консолидация офисного пространства, маркетинговая акция.
Управление проектом (project management) – это обеспечение достижения задач проекта в рамках отведенных средств, человеческих ресурсов и времени.
Динамика проекта обусловлена влиянием следующих параметров:
Стоимость
Функционал ПО
Сроки
Качество
Эти 4 параметра (иногда 3, исключая качество) согласуются заказчиком и поставщиком ПО и определяются на начальном этапе проекта.
2. Инициация (запуск) проекта
В компаниях, где проектная деятельность не является исключением из правил, при запуске проекта составляется следующая нормативная документация:
Паспорт (устав) проекта
Расписание проекта
Положение о проектной группе
План управления рисками
1. Паспорт (устав) проекта.
Содержит наименование проекта, согласованные значения параметров на момент запуска, краткое описание проекта, предварительную оценку эффективности. Паспорт должен составлять общую картину, доступную для понимания руководством компании. Иногда в паспорте проекта приводят оценку рисков, связанных с действиями руководства, чтобы показать желаемую степень участия руководства в проекте. В целом, этот документ должен содержать только основную суть, конкретные сроки, стоимость и минимум деталей. Паспорт проекта обязан быть легко читабельным и хорошо смотреться - по аналогии, например, с веб-сайтом.
2. Расписание проекта.
Это документ, например, составленный в MS Project, в котором представляется декомпозиция задачи на подзадачи, а также устанавливаются зависимости и сроки подзадач.
3. Положение о проектной группе
Положение о проектной группе регламентирует состав команды, ведущей проект. В эту команду могут входить сотрудники и со стороны заказчика, и со стороны поставщика ПО. Для сотрудников, задействованных в проекте не полностью, устанавливаются примерные проценты их загрузки на подзадачах. Следует также понимать, что в отличие от механической ручной работы, задачи, связанные с программированием и внедрением ПО, часто оказываются неделимы. Заменить программиста или аналитика в процессе выполнения задачи - означает начать задачу заново. В связи с этим, нельзя требовать от персонала ровно того процента загрузки, который указан в расписании проекта. Согласование процентов загрузки лишь позволяет менеджеру проекта получить в свое распоряжение сотрудника из неподчиненного подразделения на некоторое время, в перерыве между другими его рядовыми заданиями.
Варианты организационной структуры проекта
Организационная структура проекта не всегда оформляется документально, но в любом случае должен быть назначен ответственный за каждую отдельную задачу во избежание перекладывания ответственности участниками друг на друга. Для проектов сравнительно небольшой стоимости, где участвуют 2-3 сотрудника, этот пункт не обсуждается. Как правило, если у компании-заказчика имеется специальное подразделение, занимающееся исключительно проектной деятельностью (например, управление развития в департаменте ИТ), оргструктура проекта является подструктурой этого подразделения. В таком случае по-умолчанию применяется иерархическая структура.
1.Иерархическая
Этот вид организационной структуры отражает «естественные» связи подчинения. В классификации подразделений самым крупным явлается департамент, за ним следуют (по уменьшению величины) управление, отдел, группа. Преимуществом является четкое определение ответственного за весь проект и за отдельные задачи.
2. Горизонтальная
Если проект требует взаимодействия многих подразделений, применяется горизонтальная модель.
Например, под проект требуется закупка нового оборудования, настройка сети, установка серверного ПО, развертывание клиентских рабочих мест, настройка и доработка установленного ПО в соответствии с особенностями предприятия-заказчика. Таким образом, будут задействованы: отдел закупок, техники, системные администраторы, программисты, системные аналитики, администраторы баз данных, сотрудники техподдержки. Понятно, что «ближайший общий начальник» (по аналогии с наименьшим общим кратным) для них – это, как минимум, директор департамента ИТ, который ни в коей мере не должен входить в проектную группу. Поэтому ответственным за координацию деятельности всех этих сотрудников является только менеджер проекта, а сами сотрудники не имеют формальных связей подчинения между собой:
3. Матричная
Применяется в условиях дефицита трудовых ресурсов, по принципу «если останется время». Связи подчинения отсутствуют, за исключением подчинения менеджеру проекта. Для каждого сотрудника устанавливается примерный процент его загрузки на той или иной задаче проекта, а также его роль в проекте. Преимуществом такого подхода является возможность профессионального роста в результате частой смены деятельности, например, программист может выступать в роли аналитика и т.д.
Управление рисками
Риск – это фактор, который может появиться в ходе работ и оказать негативное влияние на проект. При управлении рисками требуется эти риски выявить, оценить и, по мере возможности, устранить.
Выявление рисков
Практически для любого проекта внедрения характерны следующие риски:
Вмешательство в проект высшего руководства (например, резкое изменение постановки задачи в результате непонимания руководством основного предназначения ПО)
Привлечение неадекватных пользователей (например, не умеющих работать за компьютером в нужной степени)
Нехватка знаний/навыков у персонала
Конфликты в проектной группе
Увольнение ключевого сотрудника
Технические моменты
Оценка рисков
Оценить риск – значит оценить его критичность для проекта. В процессе оценки рисков рассчитывается приоритет каждого из них:
Возможна оценка рисков к зависимости от одного параметра - их стоимости - вместо стоимости и затрат времени.
Альтернативы по управлению рисками (Устранение рисков)
Набор альтернатив по управлению риском включает:
- избежание риска – данная единица портфеля рисков исключается из него посредством устранения причин потенциальных рисковых событий (например, отказ от услуг определенного поставщика);
- передача риска – заключение специального соглашения, по которому данный риск принимает на себя другая компания (например, страхование, ответственность производителя за используемое в проекте оборудование и др.);
- снижение риска – принятие мер по снижению вероятности и/или ущерба от возникновения рисковых событий (при выработке таких мер важно сбалансировать их стоимость с ожидаемой денежной выгодой от снижения риска)
- принятие риска – в этом случае компания оставляет для риска возможности для реализации, формируя под него соответствующие резервы (стоит отметить, что часть рисков, оставшаяся после снижения, принимается автоматически).