Записаться

1. Планирование проекта: назначение и исходная точка

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

Планирование начинается с подготовки технического задания (ТЗ) и описания других ограничений и целей, которые определяют и ограничивают проект. При этом не говорится, откуда именно взялось ТЗ. В стандарте 1207, рассмотренном ранее, была более длинная последовательность: контракт → контрактные требования → системные требования → ТЗ. Здесь подход проще, поскольку методика разрабатывалась раньше и не претендовала на всеобъемлющий охват. Планирование может выполняться итерациями.

2. Цели группы ключевых процессов планирования проекта

Группа ключевых процессов планирования проекта направлена на:

1. документирование объёма работ;
2. планирование;
3. документирование плана;
4. принятие обязательств.

3. Обязательства по выполнению

Для достижения этих целей организация должна выполнить ряд требований.

3.1. Роли и организационная политика

Должен быть назначен производственный менеджер проекта (production project manager). Это человек, который отвечает за производство и выполнение работ, обсуждает обязательства и готовит план разработки ПО. Существуют и другие менеджеры, например менеджер, взаимодействующий с клиентом и обсуждающий условия. Это отдельная роль. Производственный менеджер назначается не проектной командой, а кем-то извне — организатором или руководством.

Проект следует документированной организационной политике. Такая политика существует, доступна в виде документа и обязательна для проектной команды. В неё входит:

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

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

3.2. Управляемость плана и ТЗ

Полученный план разработки ПО является управляемым и контролируемым. Это означает, что он входит в базовую линию (baseline). Изменения в нём могут делать только уполномоченные сотрудники. Изменения регистрируются, контролируются, оцениваются и прослеживаются. Реализован контроль версий (version control): можно откатиться к предыдущей версии плана и отменить сделанные изменения.

Термин «разработка» не исключает сопровождение ПО. Речь может идти о поддержке, доработке, расширении системы и других работах.

ТЗ должно быть входом для всех остальных работ. Оно также должно быть управляемым и контролируемым, с контролем версий. В ТЗ раскрывается перечень вопросов, указывается, кто его рассматривает и как с ним работать.

3.3. Предпосылки планирования

1. Обязанности по созданию плана распределены. План не может составлять только производственный менеджер или только менеджер проекта. Он разрабатывается совместно с производственными группами, участвующими в проекте, потому что именно они понимают реальные затраты на выполнение работ. Процесс планирования должен быть включён в план проекта или профинансирован отдельно. Сложные задачи, например оценка объёмов работ, решаются через процедуры. Заинтересованные лица должны быть с этими процедурами ознакомлены.
2. Производственный менеджер координирует планирование всего проекта. Ответственность за промежуточные программные продукты распределяется и назначается производственным менеджером отслеживаемым и учитываемым образом. Каждое назначение ответственного документируется и контролируется; изменения в этой структуре также контролируются.
3. В разработке плана участвуют опытные сотрудники. Процесс подготовки плана обеспечивается инструментальными средствами, например электронными таблицами.

4. Выполняемые операции

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

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

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

Краткие итоги

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

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

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

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