Публикация была переведена автоматически. Исходный язык: Русский
В реальных IT-проектах редко используется только один стандарт или методология. Случается, команды комбинируют лучшие практики из разных источников: PMI PMBOK для управления проектами, BABOK для работы с требованиями, IEEE и отраслевые стандарты для технической документации.
Рассмотрим состав проектной документации, который объединяет эти подходы. Представленный перечень учитывает последовательность разработки документов, описывает их назначение и обозначает ответственных.
Роли на проекте:
Customer — заказчик;
Project Sponsor (PS) - спонсор проекта;
Product Owner (PO) - владелец продукта;
Project Manager (PM) - менеджер проекта;
Business Analyst (BA) - бизнес-аналитик;
System Analyst (SA) - системный аналитик;
Solution Architect (SА) - архитектор решения;
Technical Lead (TL) - технический лидер.
1. Концепция продукта (Concept Document) - фиксирует общие идеи и бизнес-логику. Описывает, зачем нужен проект, какие проблемы решает, возможные пути реализации. Не детализирует технические и функциональные аспекты. Документ разрабатывает спонсор проекта или бизнес-аналитик совместно со спонсором и/или заказчиком.
2. Устав проекта (Project Charter) - утверждает проект и его запуск. Фиксирует цели, сроки, ресурсы, риски, стейкхолдеров. Не содержит детальных требований. Разрабатывает PM, утверждает PS проекта.
3. Матрица распределения ролей (RACI Matrix - Responsible, Accountable, Consulted, Informed) - инструмент управления коммуникациями и ресурсами. Определяет, кто за что отвечает. Разрабатывает и актуализирует PM по мере формирования команды проекта. BA может участвовать для ролей, связанных с требованиями.
4. Реестр рисков (Risk Register) - фиксирует возможные риски, их вероятность, влияние и стратегии минимизации. PM ведет проектные риски, BA может выявлять риски продукта/требований, но итоговый реестр — ответственность PM.
5. Vision & Scope - описывает желаемое будущее состояние, определяет границы разработки. Включает видение заказчика, функциональные и нефункциональные требования, приоритеты. Фокусируется на продукте, а не на управлении проектом. Разрабатывает BA совместно с PM и заказчиком.
6. Дорожная карта релизов (Roadmap) - определяет последовательность разработки функциональности, основные версии и их содержимое. Разрабатывает PM / PO и Tech Lead.
7. Спецификация требований (Software Requirements Specification, SRS) - описывает функциональные и нефункциональные требования, ограничения, интерфейсы системы. Разрабатывает SA или BA.
8. Архитектурный документ (Architecture Document, SAD) - описывает структуру системы, компоненты, интеграции, технологии. Создается после SRS. Разрабатывает архитектор решения.
9. Техническое задание по ГОСТ (если требуется) - описывает весь проект: оборудование, ПО, внедрение, эксплуатацию. Разрабатывает SA и/или BA, PM контролирует внедрение и приемку, заказчик утверждает.
Оптимальный момент для расчета бюджета:
а) Первая приблизительная оценка - после Vision & Scope, когда понятны функции и границы решения;
б) Детальная оценка - после SRS + архитектуры, когда выявлены и описаны функциональность, интеграции, технологии;
в) Финальный бюджет – после ТЗ по ГОСТу (если требуется) или финальной спецификации, когда учтены все факторы.
Выводы:
• Ранние этапы (концепция, устав проекта) дают только грубые оценки.
• SRS + архитектурный документ – момент для реалистичного расчета бюджета.
• Если нужна очень точная оценка, необходимо дождаться ТЗ или полной детализации системы.
Примечания:
• SRS часто выступает в качестве аналога ТЗ. Но SRS более гибкий и ориентирован на программный продукт, тогда как ТЗ описывает весь проект, включая оборудование, внедрение и эксплуатацию.
• Представленный перечень документации оптимален для водопадной модели и гибридных подходов, а также для корпоративной и контрактной разработки, где требуется стандартизация.
• Для гибкой разработки такой объем описания избыточен. В Agile/Scrum обычно используются Product Backlog, Epics и User Stories, но верхнеуровневые артефакты, такие как Roadmap и Architecture Document, также актуальны.
В реальных IT-проектах редко используется только один стандарт или методология. Случается, команды комбинируют лучшие практики из разных источников: PMI PMBOK для управления проектами, BABOK для работы с требованиями, IEEE и отраслевые стандарты для технической документации.
Рассмотрим состав проектной документации, который объединяет эти подходы. Представленный перечень учитывает последовательность разработки документов, описывает их назначение и обозначает ответственных.
Роли на проекте:
Customer — заказчик;
Project Sponsor (PS) - спонсор проекта;
Product Owner (PO) - владелец продукта;
Project Manager (PM) - менеджер проекта;
Business Analyst (BA) - бизнес-аналитик;
System Analyst (SA) - системный аналитик;
Solution Architect (SА) - архитектор решения;
Technical Lead (TL) - технический лидер.
1. Концепция продукта (Concept Document) - фиксирует общие идеи и бизнес-логику. Описывает, зачем нужен проект, какие проблемы решает, возможные пути реализации. Не детализирует технические и функциональные аспекты. Документ разрабатывает спонсор проекта или бизнес-аналитик совместно со спонсором и/или заказчиком.
2. Устав проекта (Project Charter) - утверждает проект и его запуск. Фиксирует цели, сроки, ресурсы, риски, стейкхолдеров. Не содержит детальных требований. Разрабатывает PM, утверждает PS проекта.
3. Матрица распределения ролей (RACI Matrix - Responsible, Accountable, Consulted, Informed) - инструмент управления коммуникациями и ресурсами. Определяет, кто за что отвечает. Разрабатывает и актуализирует PM по мере формирования команды проекта. BA может участвовать для ролей, связанных с требованиями.
4. Реестр рисков (Risk Register) - фиксирует возможные риски, их вероятность, влияние и стратегии минимизации. PM ведет проектные риски, BA может выявлять риски продукта/требований, но итоговый реестр — ответственность PM.
5. Vision & Scope - описывает желаемое будущее состояние, определяет границы разработки. Включает видение заказчика, функциональные и нефункциональные требования, приоритеты. Фокусируется на продукте, а не на управлении проектом. Разрабатывает BA совместно с PM и заказчиком.
6. Дорожная карта релизов (Roadmap) - определяет последовательность разработки функциональности, основные версии и их содержимое. Разрабатывает PM / PO и Tech Lead.
7. Спецификация требований (Software Requirements Specification, SRS) - описывает функциональные и нефункциональные требования, ограничения, интерфейсы системы. Разрабатывает SA или BA.
8. Архитектурный документ (Architecture Document, SAD) - описывает структуру системы, компоненты, интеграции, технологии. Создается после SRS. Разрабатывает архитектор решения.
9. Техническое задание по ГОСТ (если требуется) - описывает весь проект: оборудование, ПО, внедрение, эксплуатацию. Разрабатывает SA и/или BA, PM контролирует внедрение и приемку, заказчик утверждает.
Оптимальный момент для расчета бюджета:
а) Первая приблизительная оценка - после Vision & Scope, когда понятны функции и границы решения;
б) Детальная оценка - после SRS + архитектуры, когда выявлены и описаны функциональность, интеграции, технологии;
в) Финальный бюджет – после ТЗ по ГОСТу (если требуется) или финальной спецификации, когда учтены все факторы.
Выводы:
• Ранние этапы (концепция, устав проекта) дают только грубые оценки.
• SRS + архитектурный документ – момент для реалистичного расчета бюджета.
• Если нужна очень точная оценка, необходимо дождаться ТЗ или полной детализации системы.
Примечания:
• SRS часто выступает в качестве аналога ТЗ. Но SRS более гибкий и ориентирован на программный продукт, тогда как ТЗ описывает весь проект, включая оборудование, внедрение и эксплуатацию.
• Представленный перечень документации оптимален для водопадной модели и гибридных подходов, а также для корпоративной и контрактной разработки, где требуется стандартизация.
• Для гибкой разработки такой объем описания избыточен. В Agile/Scrum обычно используются Product Backlog, Epics и User Stories, но верхнеуровневые артефакты, такие как Roadmap и Architecture Document, также актуальны.
