Пример контрольного (базового) плана ИТ-проекта

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

Рассмотрим особенности его основных блоков на основе примера, приведенного в табл. 7.3. Автор неоднократно использовал предложенный шаблон для составления контрольных (базовых) планов.

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

Таблица 7.3

Шаблон базового плана проекта.

Сначала дадим несколько общих комментариев.

В табл. 7.3 по отдельным задачам представлены сроки окончания работ и представления их результатов. Это контрольный план, а не рабочий координационный. На этапе составления контрольного плана высокой точности планирования добиться невозможно. У руководителя проекта должна сохраняться возможность «маневра» сроками старта отдельных работ на уровне рабочего планирования. Это его право.

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

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

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

Таблица 7.3 предполагает реализацию 18 задач в течение 270 дней. Таким образом, контрольные точки с предоставлением распознаваемых и согласуемых документов предусмотрены в среднем через каждые 14 дней. Это показывает, что, несмотря на значительную длительность (270 календарных дней), проект является очень интенсивным (ранее мы говорили о том, что контрольный (базовый) план предпочтительно должен включать контрольные точки с периодичностью 1 месяц).

План содержит единственный значимый резерв по времени, начиная с 8 пункта. Это означает, что потенциально проект может быть сжат по общему сроку примерно на 30 дней. Это может реализоваться, если и поставщик, и внутренний исполнитель смогут согласовать с командой проекта и обеспечить поставку в режиме МУР (сокращенной функциональности).

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

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

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

Задача 2 — «Обследования участка автоматизации». Ранее, в гл. 2, рассматривались основные подходы к решению сложных инженерных задач. Было указано на то, что одним из основных подходов является последовательность «анализ — синтез». Часто на практике упускают необходимость выполнения первой фазы «анализ» и переходят сразу к фазе «синтез», тем самым значительно увеличивая риск ошибок при проектировании.

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

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

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

Раздел, содержащий описание существующей архитектуры модернизируемого участка автоматизации с указанием взаимодействующих систем, интерфейсов и режимов взаимодействия, обычно не занимает больше 2—3 страниц и состоит из графической схемы и последующей таблицы описания систем и их взаимодействия. Схема практически всегда доступна для размещения в «читабельном» виде на формате листа А4.

Интересна история, связанная с подобной схемой. До того, как автор принял участие в проекте, организация занималась его реализацией на протяжении четырех лет. Результаты проекта в использование не поступали. Разработка ядра автоматизированного комплекса велась итерационно, т. е. требования направлялись внешнему поставщику участками, после чего получаемый участок системы подвергался тестированию. Несмотря на высокую интенсивность работ (в проекте участвовало с полной занятостью до 60 человек с обеих сторон), система не «срасталась» в единый функционирующий комплекс. Главной причиной было отсутствие закрепления границ комплекса на начальной фазе проекта; у каждого технолога — разработчика требований было свое представление о том, какой функционал крупноблочно включен в проект. И это представление дополнительно изменялось с течением времени.

В результате быстрого рестарта проекта была оперативно набрана собственная группа разработчиков, и еще до ее полного укомплектования в течение трех недель проведено обследование с маркировкой на схеме модернизируемых участков. Непосредственно после демонстрации отчета руководству организации оно приняло решение о премировании новой команды проекта с формулировкой: «Мы, наконец, разобрались, что модернизируем».

Под номером 3 в шаблоне плана приведена задача «Разработка и согласование требований». Если мы имеем дело с мелким проектом, требования к которому принципиально могут быть разработаны за указанный срок, то они могут иметь достаточно детальный характер. Если проект масштабный, то требования должны быть высокоуровневыми и детализироваться в дальнейшем на этапе 6 (разработка частных требований). Повторно отметим, что требования должны согласовываться с заинтересованными сторонами проекта, включая службу защиты информации и эксплуатирующие подразделения.

Следующие две задачи (4, 5) — «разработка и согласование эскизного проекта» и «презентация эскизного проекта» — тесно взаимосвязаны и при этом разнесены в отдельные задачи для выделения значимости активной коммуникации команды проекта с заинтересованными сторонами проекта, желательно в виде специально подготовленной совместной презентации эскизного проекта. По своей сути эскизный проект в рамках Единой системы конструкторской документации.

(стандарт ЕСКД) имеет целью выделение этапа, на котором принимаются верхнеуровневые принципиальные проектные решения и задается декомпозиция систем на крупные блоки.

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

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

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