Ответ.

История вопроса:

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

Проблема:

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

Решение:

Грамотный системный аналитик:

• Проводит стартовые встречи с командой и заказчиком, выясняет их боль и удобные форматы артефактов.
• Формирует матрицу ответственности (RACI) по документации: кому какой артефакт нужен, кто его поддерживает и на каком этапе.
• Совместно с архитектором и лидами договаривается, где необходимо использовать, например, диаграммы классов (для сложной логики), а где достаточно BPMN-процесса или mockup.
• Постоянно уточняет и пересматривает набор артефактов по ходу проекта — актуальность выше полноты.

Ключевые особенности:

• Нет универсального набора артефактов: для разных проектов нужны разные документы.
• Коммуникация и совместная договорённость — фундамент успеха (shared ownership).
• Каждый артефакт должен решать конкретную задачу, быть живым и поддерживаемым.

Вопросы с подвохом.

Можно ли использовать только один вид диаграмм (например, только BPMN) для всех ситуаций?

Нет, каждый вид диаграммы или документа раскрывает разный аспект системы: BPMN для процессов, UML для объектов и взаимодействий, таблицы для справочников. Комбинировать их — лучшая практика.

Всегда ли нужен подробный документ спецификации требований?

Не всегда. В стартапах, пилотах, гибких (Agile) проектах может быть достаточно лёгких документов с опорой на backlog — главное, чтобы команда понимала задачи.

Может ли аналитик требовать от команды следовать своему шаблону документации?

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

Типовые ошибки и анти-паттерны

• Механическое копирование полного пакета документов из других проектов.
• Создание документации «ради документации».
• Игнорирование фидбека команды, отказ работать с актуальными артефактами.

Пример из жизни

Негативный кейс: Системный аналитик внедрил 6 разных диаграмм по каждому процессу в рамках корпоративного проекта. Команда захлебнулась в документации, никто её не читал, работали по устным задачам.

Плюсы:

• Желание формализовать систему на высоком уровне.

Минусы:

• Потери времени, путаница.
• Недостоверная документация к моменту реализации.

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

Плюсы:

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

Минусы:

• Иногда для внешних аудиторов требовались дополнительные отчёты и схемы.