Файл: Разработка проекта по внедрению информационноаналитической системы на предприятии x 5 Grup Цель работы.docx

1/10 от длительности проекта. В случае, если план проекта будет показан заказчику, безусловно лучше использовать подход с включением рисков в оценки всех работ — не все поймут появление еще одного этапа (за который заказчик должен заплатить). Но в случае, если вы делаете внутренний проект для своей компании, предпочтительнее включить этап Contingency и использовать данное время для внештатных ситуаций — болезни ключевых сотрудников, внезапных корпоративов и т.д. Внутреннему заказчику будет легче транслировать перенос сроков. Далее определим команду проекта:

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

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

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

Разработчик — основной разработчик проекта,
Младший разработчик — джуниор на подхвате кода, решает задачи под контролем разработчика, параллельно учится.
Аккаунт — менеджер по работе с клиентами, отвечает за взаимодействие с клиентом, составление и подписание договоров, контроль удовлетворенности клиента и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
Куратор — высший менеджер компании исполнителя, обеспечивающий контроль и поддержку проекта. Может быть так же — руководитель портфеля проектов и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
Заказчик — все сотрудники заказчика, привлекаемые к проекту. В плане — не детализируемы, предполагается что заказчик сам решит, кого из своих специалистов привлекать к тем или иным активностям.

Далее вносим команду проекта в «Лист ресурсов». Указываем роли, краткое наименование и внутренние ставки, а так же отражаем базовый календарь (Рис. 1)

Рис. 1

Общий обзор этапов, их сроков и стоимости отображен на рис. 2:

рис. 2

Итак, у нас есть 8 этапов (включая нулевой) и проект, который начинается 10 января , завершается 5 октября. Заказчику — можно вовсе не показывать этап 0, и конечно, не стоит его учитывать если вы не считаете ФОТ пресейлов и пилотов (но это для первый звоночек того, что вам есть над чем поработать, так как такой ФОТ считать нужно обязательно).

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

Этап 0 — подготовка проекта

Предположим, процесс описания плана и оценки поставлен на поток, и после оценки куратор проекта одобряет ее (и накидывает % на торг и внепроектные риски) после чего КП отправляется на согласование заказчику. Здесь указанных 7 рабочих дней может быть явно мало, поэтому эта работа указана отдельно, и именно от нее зависит веха «КП Утверждено» (рис. 3)

Рис. 3

Этап 1 — сбор требований

Итак, мы успешно подписали контракт (или получили одобрение от спонсора внутреннего проекта) и теперь самое время стартовать, начав со сбора требований к системе. Но перед этим, надо надо устроить kick-off meeting, или как это называется на русском, стартовую встречу.

В некоторых проектах есть смысл показать разработанный Project Charter, в некоторых проектах вместе с договором подписывается официальный устав, но независимо от этого кикофф нужен — для того, что бы ясно объяснить цели и сроки проекта команде (или командам) и познакомить всех друг с другом, договорится о взаимодействии.
Т.к. проект небольшой, мы предполагаем, что 12 часов хватит нам, что бы подготовить небольшую презентацию, в которой мы вкратце обозначим цели и задачи проекта, участников и их роли, наглядно покажем сроки проекта (например, красивую диаграмму Ганта) и представим следующие шаги (например график встреч с заказчиком) (рис. 4)

Рис. 4

Ниже представлен график встреч — для нашего простого проекта мы предусмотрели 6 встреч, на которых участвуют разные специалисты и которые стоят для нас по разному. Предполагается, что график мы заранее согласовали с заказчиками (или спонсорами), что бы бизнес-пользователи и вообще все заинтересованные лица, не ушли в отпуска или не Рассмотрим несколько встреч на примере (рис. 5)

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

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

Естественно, это идеальный вариант, который работает только при наличии 2 очень сильных и мотивированных проектных команд.

В реальной жизни — отсидеть на встрече 4 часа и за 4 часа составить приличный протокол с описанием требований и договоренностей (или отревьювить его) — и так 6 дней подряд — довольно тяжело. Не говоря о том, что встреча может быть и более 4 часов (кстати, в этом случае эффективность встречи резко падает и протокол может быть и не согласован). Если сроки (и заказчик) позволяют — заложите 1 встречу в 2 дня, и взять в запас неделю — для проведения дополнительных встреч и ревью протоколов.

Этап 2 — Архитектура и дизайн

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

Здесь предусмотрим 2 итерации согласования требует от заказчика определенной ответственности. Во второй — только проверяет их исправление, а новые замечания — не ставятся (рис. 6).

Рис. 6

Этап 3 — Разработка

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

Рис. 7

Этап 4 — Тестирование

Этапы тестирования информационной системы представлены на рис. 8

Рис. 8

Этап 5 — Внедрение

Рис. 9

Этап 6 — Поддержка

Рис. 10

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

Ниже представлены стадии создания информационно-аналитической системы. Также дана оценка длительности каждого из этапов внедрения системы.

Стадия I. Организация проекта

Этапы работ	Результат	Дней
Заключение контракта	Контракт на разработку системы заключен	10
Согласование процедур управления	Процедуры управления проектом и устав проекта согласованы	5
Сбор команды проекта	Команда проекта сформирована	5
Обучение членов проектной команды	Компетенция участников проекта соответствует требованиям. Этап реализуется по необходимости	10

Стадия II. Формирование требований и разработка технического задания

Этапы работ	Результат	Дней
Системно-аналитическое обследование объекта автоматизации	Проведены интервью с функциональными и IT-специалистами Заказчика. Собрана информация о: требуемых отчетах, показателя, измерениях возможных системах-источниках данных системном ландшафте сетевом окружении	20
Анализ и обработка полученной информации	Сформированы: альбом показателей альбом измерений и иерархий альбом отчетности определены источники данных для каждого показателя	20
Разработка концептуальной модели данных	Концептуальная модель данных	15
Разработка технического задания	Техническое задание и приложения к нему	20
Согласование и утверждение	Согласованное и утвержденное техническое задание	10