Урок 01.02: Роли и ответственность аналитика
Цель урока
Изучить зоны ответственности системного аналитика в ИТ-проекте, освоить ключевые артефакты, которые он создаёт, и научиться выявлять всех стейкхолдеров (включая «скрытых») — от заказчика до юристов и службы безопасности.
Ключевые понятия
- Стейкхолдер (Stakeholder) — любое лицо, группа или организация, которая имеет интерес (stake) в проекте или может влиять на его результат / быть под влиянием результата
- Артефакт — документированный результат работы аналитика: спецификация, диаграмма, модель, контракт
- SRS (Software Requirements Specification) — спецификация требований к программному обеспечению — основной документ, описывающий, что должна делать система и в каких условиях
- Vision / Concept Document — документ видения продукта: цели, бизнес-обоснование, границы проекта, ключевые функции
- ТЗ (Техническое Задание) — в российской практике аналог SRS или более детальный документ, регламентирующий требования к разработке
- BRD (Business Requirements Document) — документ бизнес-требований (обычно создаётся бизнес-аналитиком)
- User Story — короткое описание функции с точки зрения пользователя (формат: «Как [роль], я хочу [цель], чтобы [причина]»)
- Traceability Matrix (Матрица трассировки) — таблица, связывающая требования с их источником, реализацией и тестами
1. Место аналитика в команде: полная карта взаимодействий
Системный аналитик — центральный узел коммуникаций в ИТ-проекте. В отличие от разработчика, который большую часть времени работает с кодом, аналитик постоянно взаимодействует с разными ролями.
1.1. Круг взаимодействия
┌─────────────────┐
│ Заказчик / │
│ Product Owner │
└────────┬────────┘
↓ (что нужно бизнесу)
┌──────────────┬──────┴──────┬──────────────┐
↓ ↓ ↓ ↓
┌────────────┐ ┌───────────┐ ┌──────────┐ ┌────────────────┐
│ Архитектор │ │Разработчик│ │ QA-тест. │ │ DevOps │
│ (как реал.)│ │(что реал.)│ │(чем тес.)│ │(где развер.) │
└────────────┘ └───────────┘ └──────────┘ └────────────────┘
↑ ↑ ↑ ↑
└──────────────┬──────────────┴──────────────┘
│
┌─────┴──────┐
│Аналитик (СА)│
└─────┬──────┘
│
┌──────────────┼──────────────┐
↓ ↓ ↓
┌────────────┐ ┌───────────┐ ┌──────────────┐
│ Дизайнер │ │ Project │ │Юристы / Без- │
│ (UX/UI) │ │ Manager │ │опасность / │
│ │ │ (сроки) │ │Compliance │
└────────────┘ └───────────┘ └──────────────┘
1.2. Характер взаимодействия с каждой ролью
| Роль | Аналитик взаимодействует... | Пример диалога |
|---|---|---|
| Product Owner / Заказчик | Выявляет потребности, согласует приоритеты | «Какой функционал критичен для запуска? Что такое MVP?» |
| Архитектор | Уточняет техническую реализуемость | «Можем ли мы интегрироваться с legacy-системой по REST, или нужен брокер сообщений?» |
| Разработчик | Детализирует требования до задач | «В этом сценарии пользователь может ввести отрицательное число — как должны обрабатывать?» |
| QA-инженер | Проверяет тест-кейсы на полноту покрытия | «Этот тест покрывает требование FR-007? Давай добавим кейс с граничными значениями» |
| UX/UI-дизайнер | Согласует пользовательские сценарии | «Пользователь должен пройти ровно 3 шага до оформления заказа — вот пошаговый сценарий» |
| Project Manager | Уточняет сроки и зависимости | «Для реализации этого требования нужна интеграция с платёжным шлюзом — это dependency на внешнюю команду» |
| DevOps | Определяет нефункциональные требования | «Система должна выдерживать 1000 RPS, нужно предусмотреть горизонтальное масштабирование» |
| Юристы / Служба безопасности | Согласует compliance-требования | «Хранение персональных данных должно соответствовать 152-ФЗ — какие поля можно логировать, а какие нет?» |
Важно: Аналитик не просто «передаёт информацию». Он трансформирует бизнес-потребность в структурированное техническое задание, понятное каждой из этих ролей. Одно и то же требование он расскажет заказчику на языке бизнеса, разработчику — на языке API и БД, а QA — на языке тестовых сценариев.
2. Основные артефакты аналитика: глубокий разбор
Артефакты — это осязаемый результат работы аналитика. Они фиксируют договорённости, служат источником истины (single source of truth) для команды и позволяют проследить связь от бизнес-идеи до готового кода.
2.1. Vision / Concept Document (документ видения)
Что это? Vision Document — это «конституция» проекта. Краткий документ (обычно 5–15 страниц), который фиксирует ответы на главные вопросы:
- Какую проблему решаем? (Problem Statement)
- Кто будет пользоваться? (Target Audience)
- Какие у проекта границы? (Scope / Out of Scope)
- Почему это выгодно бизнесу? (Business Case / ROI)
- Какие ключевые функции? (Feature Overview)
- Кто конкуренты? (Competitive Landscape)
Зачем нужен?
- Синхронизирует команду и заказчика на старте: все должны понимать проект одинаково.
- Помогает не распыляться: если новое предложение не вписывается в Vision — оно либо отклоняется, либо пересматривается Vision.
- Является входом для SRS: из Vision «вырастают» детальные требования.
Пример фрагмента Vision Document:
Problem: Менеджеры тратят до 2 часов в день на ручное согласование заявок через email. Vision: Единый портал, где заявка создаётся за 2 минуты, согласовывается в 1 клик, а история хранится 5 лет. Scope: Создание, согласование, архив заявок. НЕ входит: бухгалтерский учёт, интеграция с 1С (вынесено в фазу 2).
Кто создаёт: Обычно БА или Product Owner при участии СА. Формат: Word / Google Doc / Confluence.
2.2. SRS (Software Requirements Specification) / ТЗ
Что это? SRS — это детальное описание требований к системе. Основной рабочий документ аналитика. В российской практике его часто называют Техническим Заданием (ТЗ), хотя есть нюансы: ТЗ традиционно включает ещё и требования к составу работ, срокам, порядку приёмки.
Стандарты:
- IEEE 830-1998 (устарел, но структура до сих пор используется как база)
- ISO/IEC/IEEE 29148:2018 (современный стандарт)
Типовая структура SRS (по IEEE 830):
1. Введение
1.1 Цель документа
1.2 Область применения
1.3 Определения, акронимы, сокращения
1.4 Ссылки
1.5 Обзор документа
2. Общее описание
2.1 Контекст системы
2.2 Функции системы (общий обзор)
2.3 Характеристики пользователей
2.4 Ограничения
2.5 Допущения и зависимости
3. Детальные требования
3.1 Функциональные требования (пронумерованные, FR-001 ... FR-N)
3.2 Нефункциональные требования (производительность, безопасность, etc.)
3.3 Требования к внешним интерфейсам (UI, API, аппаратура)
3.4 Требования к данным (модель данных, словарь данных)
4. Приложения
- Диаграммы (UML, BPMN, ERD)
- Глоссарий
- Матрица трассировки
Зачем нужен?
- Единый источник правды для команды разработки: разработчик смотрит в SRS и пишет код.
- Основа для тестирования: QA берёт требования из SRS и строит тест-кейсы.
- Договорённость с заказчиком: подписанный SRS = юридически значимый документ, фиксирующий объём работ.
- Борьба с scope creep (расползанием требований): любое новое пожелание заказчика сверяют с SRS. Если его нет в SRS — это change request (изменение, требующее пересмотра сроков и бюджета).
Пример записи функционального требования:
FR-012: Система должна отправлять email-уведомление на адрес пользователя после успешной регистрации. Приоритет: High Источник: Стейкхолдер — отдел маркетинга
Кто создаёт: Системный аналитик (при участии БА и архитектора). Формат: Word / Google Doc / Confluence / Markdown (всё чаще).
2.3. Use Case / User Story
Что это?
- Use Case (вариант использования) — формальное описание сценария взаимодействия пользователя (актёра) с системой. Включает: название, актёров, предусловия, основной поток, альтернативные потоки, исключения, постусловия.
- User Story (пользовательская история) — короткая запись (1–3 предложения), описывающая функцию с точки зрения пользователя. Формат: «Как [роль], я хочу [действие], чтобы [ценность]».
Сравнение:
| Характеристика | Use Case | User Story |
|---|---|---|
| Детализация | Высокая (пошаговый сценарий) | Низкая (намерение) |
| Формат | Структурированный документ | Карточка в бэклоге |
| Где применяется | Waterfall / традиционные проекты, сложная логика | Agile / Scrum |
| Кто пишет | СА | БА / PO / СА |
| Пример | Основной поток: 1. Пользователь вводит email. 2. Система проверяет формат. 3. Система отправляет код. | Как клиент, я хочу войти по email, чтобы не запоминать пароль. |
Зачем нужны?
- Use Case: детально проработать сценарий, не пропустить альтернативы и ошибки.
- User Story: быстрая фиксация потребности, обсуждение деталей происходит позже (на уточнении / grooming).
2.4. BPMN / UML диаграммы
Что это?
- BPMN (Business Process Model and Notation) — нотация для моделирования бизнес-процессов. Позволяет описать поток работ, события, шлюзы (развилки), роли (пулы и дорожки).
- UML (Unified Modeling Language) — унифицированный язык моделирования, включает 14 типов диаграмм. Аналитик чаще всего использует: Use Case, Activity, Sequence, Class, State Machine.
Зачем нужны?
- Визуализация сложного: один рисунок заменяет страницы текста. Процесс, описанный в BPMN, воспринимается за 30 секунд, тогда как на чтение текстового описания уйдёт 5 минут.
- Обнаружение ошибок: на диаграмме сразу видны логические разрывы (например, после шлюза не указано условие).
- Синхронизация команды: разработчик, тестировщик и заказчик смотрят на одну диаграмму и одинаково понимают процесс.
Пример (описание диаграммы активностей):
Диаграмма активности «Оформление заказа»: начальный узел → пользователь заполняет корзину → проверка наличия (ветвление: есть / нет) → если нет — возврат к корзине, если есть — переход к оплате → оплата → финальный узел.
Кто создаёт: СА, реже БА (БА чаще делает BPMN более высокого уровня).
2.5. API-контракты
Что это? API-контракт (спецификация API) — это формальное описание интерфейса взаимодействия между компонентами / системами. Чаще всего — в формате OpenAPI 3.0 (бывший Swagger) для REST, или Proto-файлы для gRPC, или WSDL для SOAP.
Контракт фиксирует:
- Доступные эндпоинты (URL + HTTP-метод)
- Формат запроса и ответа (JSON / XML схема)
- Статус-коды (200, 400, 401, 404, 500...)
- Аутентификацию (API Key, OAuth 2.0, JWT)
- Ограничения (rate limiting, размер payload)
Зачем нужен?
- Договорённость между командами: команда фронтенда и команда бэкенда могут разрабатываться параллельно, имея единый контракт.
- Автоматическая генерация: из OpenAPI-спецификации можно сгенерировать клиентские SDK, серверные заглушки (stubs), документацию.
- Тестирование: на основе контракта строятся интеграционные тесты и проверки (contract testing).
Пример фрагмента OpenAPI:
paths:
/api/v1/orders:
post:
summary: Создать новый заказ
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
customer_id:
type: string
items:
type: array
items:
type: object
properties:
product_id: { type: string }
quantity: { type: integer }
responses:
'201':
description: Заказ создан
'400':
description: Некорректные данные
Кто создаёт: СА (совместно с архитектором). Инструменты: Swagger Editor, Redoc, Stoplight, Postman.
2.6. Матрица трассировки требований (Requirements Traceability Matrix, RTM)
Что это? RTM — это таблица, которая связывает каждое требование с его источником (откуда взялось), реализацией (где реализовано) и тестами (чем проверяется).
Пример матрицы:
| ID требования | Источник | Use Case | Компонент | Тест-кейс | Статус |
|---|---|---|---|---|---|
| FR-001 | Интервью с заказчиком, 15.03 | UC-01 «Регистрация» | Auth Service | TC-001, TC-002 | ✅ |
| FR-012 | Требование юр.отдела (152-ФЗ) | UC-05 «Удаление аккаунта» | User Service | TC-045 | ✅ |
| NFR-007 | Соглашение SLA | — | API Gateway | TC-101 (нагруз.тест) | 🟡 |
Зачем нужна?
- Полнота: позволяет проверить, что каждое требование реализовано и протестировано.
- Impact analysis: если требование меняется, RTM показывает, какие тест-кейсы и компоненты нужно перепроверить.
- Аудит и compliance: для регулируемых отраслей (банки, медицина) RTM обязательна — она доказывает регулятору, что все требования покрыты.
Кто создаёт и поддерживает: СА (актуализирует при каждом изменении требований).
2.7. Дополнительные артефакты (для справки)
| Артефакт | Описание | Когда используется |
|---|---|---|
| BRD (Business Requirements Document) | Бизнес-требования (создаёт БА) | На этапе инициации |
| ADR (Architecture Decision Record) | Запись архитектурного решения (создаёт архитектор / СА) | При проектировании |
| Data Dictionary | Словарь данных — описание всех сущностей, атрибутов, типов | При проектировании БД |
| Wireframes / Mockups | Прототипы интерфейсов (создаёт UX/UI + СА) | На этапе уточнения требований |
| Glossary | Глоссарий терминов проекта | Весь проект |
| Release Notes | Описание изменений в релизе | При выпуске версий |
3. Стейкхолдеры: как найти всех (включая «скрытых»)
3.1. Кто такие стейкхолдеры?
Стейкхолдер — это не только тот, кто платит деньги. Стейкхолдер — любой, кто:
- влияет на проект (может заблокировать, затормозить, изменить направление);
- использует результат проекта (пользователи, операторы, администраторы);
- поддерживает проект (ИТ-инфраструктура, эксплуатация);
- регулирует проект (юристы, compliance, служба безопасности);
- страдает от проекта (если проект внедряется, чья-то работа может измениться или исчезнуть).
Золотое правило: если вы упустили стейкхолдера на старте, он напомнит о себе на этапе приёмки — когда переделывать уже дорого.
3.2. Полная классификация стейкхолдеров
| Категория | Примеры | Типичный интерес |
|---|---|---|
| Инициаторы / Спонсоры | CEO, VP, владелец бизнеса | ROI, стратегическая цель |
| Заказчики / PO | Product Owner, бизнес-заказчик | Функции, сроки, бюджет |
| Пользователи | Операторы, менеджеры, клиенты | Удобство, скорость работы, функциональность |
| Разработчики | Архитектор, backend/frontend/devops | Чёткие требования, реализуемость |
| Тестировщики | QA, QA Lead | Тестируемость, критерии приёмки |
| Техническая поддержка | Helpdesk, эксплуатация | Документация, мониторинг |
| Регуляторы / Контроль | Юристы, служба безопасности, compliance, DPO | Законность, защита данных, отсутствие рисков |
| Негласные конкуренты за ресурсы | Другие проекты в компании | Не остаться без разработчиков |
| Косвенно затронутые | Смежные отделы (бухгалтерия, HR) | Как изменится их работа? |
3.3. Кто такие «скрытые» стейкхолдеры и почему их важно найти?
Скрытые стейкхолдеры — это лица или группы, которых нет в оргструктуре проекта, но которые могут существенно повлиять на его успех или провал. Они не очевидны на старте — о них либо забывают, либо не знают.
Чем опасен пропущенный скрытый стейкхолдер:
- На этапе согласования архитектуры приходит служба безопасности и говорит: «Ваше API не соответствует политикам безопасности, переделывайте».
- На этапе ввода в эксплуатацию приходит юрист и говорит: «Вы храните персональные данные на серверах за пределами РФ — штраф до 6 млн руб.».
- На этапе приёмки бухгалтерия говорит: «Нам от вашей системы нужен акт сверки в формате XLS, а у вас только PDF — мы не можем принять работу».
Все эти ситуации = переделки, срыв сроков, потеря денег. Аналитик должен выявить всех скрытых стейкхолдеров до того, как требования зафиксированы.
3.4. Техники поиска скрытых стейкхолдеров
Техника 1: Анализ по цепочке «вход — обработка — выход»
Возьмите ключевой бизнес-процесс системы и для каждого шага спросите: «Кто даёт входные данные? Кто получает результат?»:
[Формирование заказа] → [Оплата] → [Доставка] → [Закрытие заказа]
↓ ↓ ↓ ↓
Кто даёт товар? Кто проводит Кто доставляет? Кто закрывает
(Кладовщик) платёж? (Курьерская в бухгалтерии?
(Бухгалтер) служба) (Бухгалтер)
В этом примере кладовщик и бухгалтер — скрытые стейкхолдеры: они не заказывали систему, но будут с ней работать.
Техника 2: Матрица «Власть — Интерес» (Power-Interest Grid)
Нанесите на сетку всех, кого уже нашли, и посмотрите на пустые зоны:
ВЫСОКАЯ ВЛАСТЬ
┌──────────┬──────────┐
│ Удовл. │ Ключ. │
НИЗКИЙ │ (Keep │ (Manage │ ВЫСОКИЙ
ИНТЕРЕС │ Satisfied)│ Closely) │ ИНТЕРЕС
├──────────┼──────────┤
│ Миним. │ Держать │
│ (Monitor)│ (Keep │
│ │ Informed)│
└──────────┴──────────┘
НИЗКАЯ ВЛАСТЬ
- Ключевые (High Power, High Interest): спонсор, PO — управлять в плотную.
- Удовлетворять (High Power, Low Interest): CEO («отчитаться раз в месяц»).
- Держать в курсе (Low Power, High Interest): пользователи (показать прототип, собрать фидбек).
- Мониторить (Low Power, Low Interest): редко, но не забывать.
Где могут прятаться скрытые? Часто в квадранте High Power, Low Interest — кто-то, кто может одним решением закрыть проект, но не проявляет интереса, пока его не заденут. Это могут быть: IT-директор, Head of Security, Chief Legal Officer.
Техника 3: Вопросы «А кто ещё?» (метод снежного кома)
После каждого интервью со стейкхолдером задавайте 3 вопроса:
- «Кто ещё, по вашему мнению, должен быть вовлечён в проект?»
- «Кто может быть против этого проекта или заблокировать его?»
- «Кто будет использовать результат нашей работы? А кто будет его обслуживать?»
Каждый новый названный человек может назвать ещё 2–3. За 2–3 итерации вы получите полную карту.
Техника 4: Проверка по чек-листу регуляторных и вспомогательных функций
Пройдитесь по списку функциональных подразделений компании и отметьте, кого нет в вашем списке:
- Юридический отдел — договоры, лицензирование, 152-ФЗ (персональные данные), авторские права
- Служба безопасности (Information Security) — политики безопасности, шифрование, антифрод
- Compliance / AML — для финансовых проектов: борьба с отмыванием денег
- Бухгалтерия / Finance — акты сверки, закрывающие документы, налоговые отчёты
- Отдел качества (QA) — если QA выделен в отдельную функцию (в крупных компаниях)
- ИТ-инфраструктура / DevOps — серверы, сети, CI/CD, мониторинг
- Техническая поддержка (Helpdesk / Support) — документация для пользователей, FAQ
- HR / Административный отдел — если система влияет на учёт рабочего времени или кадровые процессы
- Отдел маркетинга — если система взаимодействует с клиентами (email-рассылки, push-уведомления)
- Внешние подрядчики / вендоры — если есть интеграция с внешними системами
- Аудит (внутренний или внешний) — если проект попадёт под аудиторскую проверку
- Data Protection Officer (DPO) — если обрабатываются персональные данные граждан ЕС (GDPR)
Техника 5: «Анализ последствий» (что произойдёт, если...)
Представьте, что система уже построена. Кто:
- её будет администрировать?
- будет обучать пользователей?
- будет чинить, если она сломается?
- будет платить штраф, если она нарушит закон?
- потеряет работу / бонусы / статус из-за автоматизации?
Каждый из этих людей — стейкхолдер, и его нужно найти до старта.
3.5. Пример: поиск скрытых стейкхолдеров для кейса «Мобильное приложение сети кофеен» (из предыдущего урока)
Очевидные стейкхолдеры:
- Владелец сети кофеен (спонсор)
- Администраторы кофеен (будут принимать предзаказы)
- Разработчики мобильного приложения
- Клиенты (пользователи)
Скрытые стейкхолдеры (по технике 4):
| Скрытый стейкхолдер | Почему он важен? | Что будет, если его упустить? |
|---|---|---|
| Юрист | Предзаказ с оплатой = договор оферты, онлайн-касса (54-ФЗ), персональные данные клиентов (152-ФЗ) | Штраф до 300 тыс. руб. за отсутствие онлайн-кассы |
| Служба безопасности банка | Интеграция с платёжным шлюзом должна соответствовать стандарту PCI DSS | Банк заблокирует приём платежей |
| Бухгалтер сети | Нужны отчёты о продажах за смену, закрывающие документы | Система будет работать, но бухгалтер не сможет закрыть месяц |
| DevOps компании | Нужен сервер для бэкенда, CI/CD, мониторинг | Разработчики напишут код, но негде будет его развернуть |
| Техподдержка (Helpdesk) | Клиенты будут звонить с вопросами по приложению | Операторы не будут знать, как отвечать на вопросы |
| Отдел маркетинга | Push-уведомления об акциях, программа лояльности | Приложение есть, но клиентов не привлекают |
| Конкурирующий проект | Параллельно разрабатывается CRM-система, обеим нужны одни разработчики | Недопонимание по ресурсам, срыв сроков |
4. Soft skills аналитика: развёрнутый гайд
Технические навыки (знание инструментов, нотаций, стандартов) составляют примерно 30% успеха аналитика. Остальное — гибкие навыки (soft skills), поскольку аналитик работает с людьми и для людей.
4.1. Ключевые soft skills
| Навык | Почему важен | Как прокачивать |
|---|---|---|
| Коммуникация | Аналитик говорит с разными аудиториями: заказчик не поймёт технического жаргона, разработчик — бизнес-метафор | Практика «перевода»: одно требование — на 3 языках (бизнес, техника, тесты) |
| Активное слушание | Стейкхолдер часто не говорит прямо, что ему нужно. Нужно слышать подтекст | Техника «5 почему», переформулирование, уточняющие вопросы |
| Фасилитация | Воркшопы, мозговые штурмы, grooming — нужно управлять групповой динамикой | Каркас воркшопа: цель → правила → тайминг → результат |
| Системное мышление | Способность видеть картину целиком, а не отдельные требования | Практика построения mind map, контекстных диаграмм |
| Эмпатия | Понимание мотивации и боли каждого стейкхолдера | Поставить себя на место пользователя / заказчика |
| Навыки переговоров | Приоритизация часто конфликтна: «И это тоже в MVP!» | Модель «Interest-based negotiation» (Гарвардский метод) |
| Английский язык | Техническая документация, API-спецификации, международные команды | Технический английский: чтение спецификаций, написание SRS на английском |
4.2. Пример: как один аналитик провалил проект из-за soft skills (реальный кейс)
Ситуация: Аналитик подготовил идеальный SRS: 80 страниц, каждая деталь описана, UML-диаграммы выверены. Он скинул документ заказчику по email и сказал: «Читайте, подписывайте». Заказчик не читал 80 страниц. Через 2 месяца выяснилось, что заказчик представлял систему совсем иначе. Проект пришлось переделывать, сроки сорваны.
Вывод: SRS недостаточно написать — его нужно презентовать, пройти по ключевым моментам, убедиться, что заказчик понял каждое положение. Аналитик должен уметь не только писать, но и говорить и слушать.
5. Типичные ошибки начинающего аналитика в зоне ответственности
- «Я просто запишу, что сказал заказчик» — не анализируя, не задавая вопросов. Результат: требования противоречивы или нереализуемы.
- «Артефакт ради артефакта» — нарисовать 30-страничный SRS, который никто не будет читать. Результат: документ есть, пользы нет.
- «Забыть про стейкхолдера» — не пригласить юриста на согласование требований к персональным данным. Результат: на приёмке — штраф или блокировка.
- «Говорить на своём языке» — использовать термины API, SQL, микросервисы в разговоре с заказчиком, который не понимает технических деталей. Результат: потеря доверия, недопонимание.
- «Ждать, пока скажут» — не проявлять инициативу в поиске стейкхолдеров и уточнении неясных моментов. Результат: пробелы в требованиях вскрываются на поздних этапах.
Вопросы для самопроверки
- Назовите 5 основных артефактов системного аналитика. Для каждого объясните: «зачем он нужен» одной фразой.
- Что такое SRS? Какие разделы он должен содержать (хотя бы 5)?
- В чём разница между Vision Document и SRS?
- Какие стейкхолдеры могут быть «скрытыми» в проекте по разработке внутреннего портала для компании (200 сотрудников)? Примените технику «проверка по чек-листу».
- Используя матрицу «Власть — Интерес», определите, как управлять:
- генеральным директором (высокая власть, низкий интерес);
- пользователями системы (низкая власть, высокий интерес);
- главным бухгалтером (средняя власть, средний интерес).
- Почему RTM (матрица трассировки) важна не только для тестировщиков, но и для самого аналитика?
Практическое задание (для самостоятельной проработки)
Вы — аналитик в проекте «Мобильное приложение для доставки еды из столовой в офис» (корпоративный кейтеринг).
Задание 1: Составьте полный список стейкхолдеров (минимум 10), разделив их на «очевидные» и «скрытые». Для каждого укажите интерес и степень влияния.
Задание 2: Для двух «скрытых» стейкхолдеров опишите, какие требования они могут выдвинуть. Пример: «Скрытый стейкхолдер — юрист. Требование: в приложении должна быть публичная оферта и чек, соответствующий 54-ФЗ».
Формат: свободная форма (можно таблицей в любом редакторе).
Дополнительные материалы
- Книга: «Software Requirements» — Karl Wiegers, Joy Beatty, 3rd Edition (библия аналитика)
- Книга: «Stakeholder Analysis and Management» — проектная литература (PMI)
- Стандарт: ISO/IEC/IEEE 29148:2018 — Requirements engineering
- Стандарт: PMBOK Guide, раздел «Stakeholder Management» (PMI)
- Шаблоны: IEEE 830 SRS template, Vision Document template (можно найти по запросу)
- Инструменты: Miro (для карт стейкхолдеров и воркшопов), Confluence (для хранения артефактов)