Шаблон запросов заинтересованной стороны
Коротко Документ «Запросы заинтересованной стороны» (Stakeholder Requests) в фиксированной структуре записывает, что одна заинтересованная сторона рассказала вам на интервью. Это рабочий документ аналитика, а не документ на утверждение, и он отделяет собственные слова собеседника от ваших догадок.
По материалам: А. Перерва, В. Иванова, «Путь аналитика», прил. «Запросы заинтересованного лица»; шаблон Requirements Management Plan из IBM RUP.
На этой странице
Главные идеи#
Зачем он нужен#
Перерва и Иванова приводят этот шаблон в приложении к своему руководству. В их модели типов требований документ хранит «сырые» запросы заинтересованных сторон (этот тип они обозначают STKR) до того, как вы превратите их в бизнес-требования, бизнес-правила или требования к качеству. Шаблон плана управления требованиями (Requirements Management Plan) в RUP тоже ставит запросы заинтересованных сторон в начало цепочки трассировки (traceability), поэтому этот документ — первое звено, до которого можно проследить требование в обратном направлении.
Два свойства делают его полезным:
- Одна заинтересованная сторона — один документ. Вы фиксируете взгляд одного человека, а не согласованный компромисс. Конфликты становятся видны, когда вы сравниваете документы.
- Без утверждения. Никто его не подписывает. Поэтому можно записывать всё, включая недодуманные идеи, и цикл ревью вас не тормозит.
Три удачных решения, которые стоит перенять#
- Подсказки не останавливаться. Раздел о проблемах напоминает интервьюеру снова и снова спрашивать «Что-нибудь ещё?», чтобы разговор не заканчивался на первом ответе.
- Шаг резюме. Перед завершением вы своими словами пересказываете проблемы собеседника и прямо спрашиваете, точен ли и полон ли пересказ. Это самая дешёвая валидация, какую вам доведётся провести.
- Отдельный раздел для ваших гипотез. Проблемы, которые вы подозреваете, но которые собеседник не назвал, записываются в собственный раздел, и каждую вы проверяете вместе с ним: реальна ли она, чем вызвана, как с ней справляются сегодня, насколько она важна по сравнению с названными проблемами? Раздельная запись сохраняет происхождение каждого пункта.
Что он охватывает#
Кроме проблем, шаблон спрашивает о роли заинтересованной стороны и о том, как для неё выглядит успех, о рабочей среде и компьютерных навыках, о реакции на предложенное решение, о том, сколько людей будет им пользоваться, об ожиданиях по надёжности, производительности и поддержке, а также о правовых и нормативных ограничениях. Эти разделы служат чек-листом вопросов, которые легко забыть в свободном интервью.
Как применять#
- До интервью заполните то, что уже знаете о человеке: имя, роль, основные обязанности. Вы придёте подготовленным и потратите время интервью на проблемы.
- Используйте раздел о проблемах как план интервью. По каждой задаче, в которой человеку нужна помощь, спросите: в чём проблема, почему она возникает, как вы справляетесь с ней сегодня, как хотели бы справляться?
- После каждого ответа спросите «Что-нибудь ещё?» хотя бы один раз.
- Подведите итог перед завершением. Зачитайте своё резюме и спросите, что в нём неверно или упущено.
- Свои гипотезы поднимайте в последнюю очередь, чтобы они не направляли ответы собеседника. Его реакцию запишите в раздел аналитика.
- В конце спросите, можно ли будет обратиться ещё раз, и перечислите открытые вопросы.
- После интервью перенесите бизнес-требования, бизнес-правила и требования к качеству в репозиторий требований и свяжите каждое из них с этим документом.
Заполняйте документ во время разговора или сразу после него. При повторных интервью с тем же человеком дополняйте тот же документ.
Шаблон#
# Запросы заинтересованной стороны: <имя>, <роль>
Интервьюер: <имя> · Сессии: <даты> · Статус: рабочий документ, не для утверждения
## 1. Введение
- Назначение — записать проблемы этой заинтересованной стороны для дальнейшего анализа
- Аудитория — бизнес- и системные аналитики проекта
- Ссылки — необязательно: связанные документы
## 2. О заинтересованной стороне
- Организация, должность, основные обязанности
- Что человек производит и кто этим пользуется
- По чему оценивают его успех
- Что мешает; что облегчает или затрудняет работу
## 3. Проблемы (повторить для каждой задачи)
- Задача —
- Проблема и её причина —
- Как с ней справляются сегодня —
- Как хотели бы справляться —
- Что-нибудь ещё? —
## 4. Рабочая среда
- Подготовка пользователей и компьютерные навыки; опыт работы с похожими инструментами
- Используемые или планируемые платформы; приложения, с которыми нужно взаимодействовать
- Ожидания по простоте использования, времени обучения и документации
## 5. Резюме
- Резюме проблем, сформулированное аналитиком своими словами
- Ответ заинтересованной стороны: точно? что-то упущено?
## 6. Гипотезы аналитика (повторить для каждой гипотезы)
- Предполагаемая проблема — реальна ли? чем вызвана?
- Как справляются сейчас / как хотели бы
- Приоритет по сравнению с проблемами, которые назвала заинтересованная сторона
## 7. Реакция на предложенное решение (если есть)
- Представленная возможность — реакция — важность для собеседника
## 8. Перспективы
- Кто в организации будет пользоваться решением; сколько людей каждого типа
- Ценность успешного решения для этой заинтересованной стороны
## 9. Надёжность, производительность и поддержка
- Ожидания по доступности и скорости; кто будет поддерживать
- Потребности в безопасности, установке, лицензировании, распространении, фирменном стиле
## 10. Другие требования
- Применимые законы, нормативы и стандарты
- Всё остальное, что пришло в голову
## 11. Завершение
- Открытые вопросы
- Разрешение обратиться повторно: да / нет
Пример#
В «Мастерской» (вымышленной сети веломастерских) аналитик проводит интервью с сотрудником стойки приёма.
- Проблема: клиенты звонят спросить, готов ли их велосипед. Сейчас сотрудник идёт в цех и спрашивает механика. Он хотел бы видеть статус каждого ремонта на своём экране.
- Что-нибудь ещё? Иногда клиенты приходят за велосипедом, который ждёт запчасть, а им об этом никто не сказал.
- Резюме: «То есть главная боль — отвечать на вопросы о статусе, не имея надёжной информации. Верно?» Сотрудник добавляет, что хуже всего вечером, в час пик.
- Гипотеза аналитика: записи по телефону и записи клиентов, пришедших лично, могут накладываться друг на друга в бумажном журнале. Сотрудник подтверждает, что так бывает, и ставит эту проблему ниже проблемы со статусом.
Теперь у каждого пункта понятное происхождение: его назвала заинтересованная сторона или предложил аналитик, а собеседник подтвердил.
Подводные камни#
- Объединять нескольких людей в одном документе. Вы теряете, кто что сказал.
- Вписывать своё решение в чужую проблему. Записывайте проблему так, как её описали; решениям место в разделе 7.
- Считать документ согласованной базовой версией. Это сырые входные данные; согласование происходит позже, на уровне проанализированных требований.
Источники и что почитать#
- А. Перерва, В. Иванова. Путь аналитика. Практическое руководство. Прил. «Запросы заинтересованного лица».
- Шаблоны документов IBM Rational Unified Process (RUP): Requirements Management Plan (запросы заинтересованных сторон как первый элемент трассировки).