Урок 02.04: Анализ документов и Shadowing (наблюдение)

Цель урока

Освоить два ключевых метода выявления требований, основанных на изучении существующих артефактов (документы, регламенты, legacy-ТЗ) и наблюдении за реальной работой пользователей (Shadowing). Научиться извлекать требования из бумажных и электронных источников, а также видеть «скрытые» шаги, которые пользователь не описывает в интервью.

Ключевые понятия

Анализ документов (Document Analysis) — метод сбора требований путём изучения существующей документации: регламентов, инструкций, ТЗ, контрактов, логов, отчётов
Shadowing (наблюдение / «тень») — техника, при которой аналитик следует за пользователем в процессе его работы, наблюдая и фиксируя реальные действия, не вмешиваясь
Регламент — нормативный документ, описывающий обязательный порядок выполнения процессов
Legacy-документация — документы от предыдущих проектов / версий системы, часто устаревшие, но содержащие ценные требования
Инструкция пользователя (User Manual) — описание того, как пользователь должен работать с системой
Artefact Analysis — изучение артефактов (скриншотов, логов, эксель-файлов, скриншотов ошибок), которые пользователи создают в процессе работы
Асимметрия информации — разрыв между тем, что пользователь говорит (на интервью) и тем, что он делает (в реальности); Shadowing помогает его сократить

1. Зачем аналитику изучать документы и наблюдать?

Два метода — Document Analysis и Shadowing — решают одну и ту же проблему: реальность отличается от того, что говорят на интервью.

Проблема: «Говорят одно — делают другое»

Человек на интервью	В реальности
«Я заполняю форму за 2 минуты»	На деле — 10 минут, переключаясь между 3 окнами
«У нас всё автоматизировано»	На деле — Excel + калькулятор + переписка в мессенджере
«Мы строго следуем регламенту»	На деле — эвристики и «костыли», накопленные годами
«Вот копия регламента, там всё описано»	Регламенту 5 лет, процесс давно изменился

Document Analysis даёт официальную версию (как должно быть). Shadowing даёт реальную картину (как есть на самом деле). Сопоставление двух даёт аналитику полное понимание.

2. Анализ документов

2.1. Какие документы изучает аналитик?

Категория	Документы	Что ищем
Нормативная база	Законы, приказы, ГОСТы, отраслевые стандарты (152-ФЗ, 54-ФЗ, PCI DSS, ISO 27001)	Обязательные требования, ограничения, санкции за нарушение
Регламенты и инструкции	Внутренние регламенты процессов, должностные инструкции, SOP (Standard Operating Procedures)	AS-IS процесс (официальная версия), зоны ответственности
Проектная документация	ТЗ / SRS от предыдущих проектов, Vision Document, Бизнес-требования	Контекст, принятые решения, ограничения
Техническая документация	API-спецификации, ER-диаграммы, ADR (Architecture Decision Records)	Модель данных, интеграции, архитектурные решения
Пользовательские артефакты	Excel-файлы, скриншоты, логи ошибок, email-переписка	«Маленькие хитрости», реальные данные, частые ошибки
Отчёты и метрики	Ежедневные/еженедельные отчёты, дашборды	Частота операций, объёмы, узкие места

2.2. Пошаговый процесс анализа документов

Шаг 1: Инвентаризация

Составьте список всех документов, которые могут быть релевантны. Источники:

Запросить у заказчика: «Дайте всё, что связано с этим процессом»
Попросить показать «рабочие файлы», а не только официальные
Найти в общих папках / Confluence / SharePoint
Спросить пользователей: «Какими документами вы пользуетесь каждый день?»

Результат: Список из 5–20 документов, отсортированных по приоритету.

Шаг 2: Беглый просмотр (skim)

Каждый документ:

Кто автор? (надёжный ли источник?)
Дата? (актуален ли?)
Объём? (сколько времени займёт детальное чтение)
Структура? (есть ли нужные разделы?)

Результат: Документы разделены на три стопки:

🔴 Актуальные и важные — читать детально
🟡 Справочные — просмотреть по ключевым разделам
🔵 Устаревшие или нерелевантные — отложить (но не выбрасывать!)

Шаг 3: Детальное чтение (для критичных документов)

На этом этапе аналитик читает документ с вопросами:

Для регламента / нормативного документа:

Какие действия обязательны? (must / shall)
Какие действия запрещены? (must not / shall not)
Кто за что отвечает? (RACI из регламента)
Какие есть исключения?
Какие сроки установлены?
Есть ли ссылки на другие документы? (надо изучить их)

Для ТЗ / SRS (предыдущей версии):

Какие требования реализованы?
Какие требования не реализованы? (почему? может, станут новыми)
Какие архитектурные решения приняты? (почему — ADR)
Какие ограничения наложены?

Для пользовательских артефактов (Excel, логи):

Какие поля / колонки заполняются? (это скрытые атрибуты данных)
Какие данные вводятся вручную? (потенциальная автоматизация)
Какие формулы используются? (бизнес-правила!)
Какие частые ошибки / нестандартные значения?

Шаг 4: Извлечение требований

Каждый найденный факт превращается в требование (или инсайт):

Найдено в документе	Превращается в
«Обработка заявки не более 3 рабочих дней» (регламент)	НФТ (Performance): время обработки заявки в системе ≤ 3 рабочих дня (счётчик SLA)
«Подпись накладной — только сертифицированной ЭЦП» (регламент)	ФТ: Система должна интегрироваться с КриптоПро для подписания ЭЦП
«Поле "Комментарий" в Excel заполняется не всегда» (артефакт)	Инсайт: сделать поле обязательным только для определённых статусов
«API запрос /getOrders таймаутится каждую пятницу в 18:00» (лог ошибок)	НФТ (Reliability): прописать retry policy + уведомление администратора

Шаг 5: Валидация с экспертом

Найденные в документах требования не принимаются на веру — их нужно подтвердить у стейкхолдера:

«Я нашёл в регламенте №42, что срок обработки заявки — 3 дня. Этот регламент всё ещё действует? Или процесс изменился?»

Типичная проблема: Регламент устарел, но формально не отменён. Систему построят по старому регламенту, а работать придётся по-новому. Аналитик обязан проверить актуальность.

2.3. Работа с нормативной базой

Для регулируемых проектов (банки, медицина, госсектор) нормативные документы — главный источник требований.

Чек-лист анализа нормативного документа:

Какие данные мы обязаны собирать? (ФТ)
Какие данные мы обязаны хранить? Срок хранения? (НФТ — Data)
Какие данные мы НЕ имеем права собирать? (ограничение)
Какие данные должны быть зашифрованы? (НФТ — Security)
Где должны храниться данные? (локализация, 152-ФЗ)
Кто имеет доступ к каким данным? (RBAC requirement)
Какой срок реакции на запрос субъекта данных? (НФТ — Performance/SLA)
Есть ли требования к логированию и аудиту? (НФТ — Supportability)

Пример: 152-ФЗ «О персональных данных» → требования:

ФТ: Пользователь должен дать явное согласие на обработку ПД
ФТ: Пользователь может запросить удаление своих ПД (правa на забвение)
НФТ: ПД должны храниться на территории РФ
НФТ: Доступ к ПД — только авторизованным сотрудникам (лог доступа)

3. Shadowing (Наблюдение / Метод «Тени»)

3.1. Что такое Shadowing

Shadowing (или «метод теневого наблюдения») — аналитик буквально становится тенью пользователя и наблюдает за его работой в реальном времени, фиксируя каждый шаг.

Ключевой принцип: «Смотри, что пользователь делает, а не слушай, что он говорит о своей работе».

Отличие от интервью:

Интервью	Shadowing
Пользователь рассказывает о работе	Аналитик видит работу
Пользователь может приукрасить или упростить	Реальность без фильтров
Узнаём, что пользователь думает	Узнаём, что пользователь на самом деле делает
Занимает 30–60 мин	Занимает 1–4 часа (полный цикл работы)

3.2. Какие инсайты даёт Shadowing

То, что никогда не всплывёт на интервью:

«Маленькие хитрости» — пользователь нашёл способ обойти баг (открывает 2 окна, нажимает F5 3 раза, копирует из одной системы и вставляет в другую)
Неочевидные шаги — переключение между 5 системами, которые пользователь не считает «работой»
Реальное время — на интервью говорят «2 минуты», по факту — 15
Частота ошибок — как часто система тормозит, падает, требует перезагрузки
Физический контекст — пользователь работает в шумном зале, за маленьким монитором, стоя, в очках — всё это влияет на требования

3.3. Подготовка к Shadowing: как сделать так, чтобы пользователь не нервничал

Наблюдение за человеком — стресс. Пользователь может начать работать по-другому (эффект Хоторна). Задача аналитика — минимизировать это влияние.

Шаг 1: Выбор пользователя

Выбирайте среднего пользователя (не самого быстрого и не самого медленного)
Желательно — с опытом > 6 месяцев (новый сотрудник сам ещё не знает процесса)
Предупредите заранее (не менее чем за 3 дня)
Объясните зачем — не «проверить», а «понять, как сделать систему удобнее»

Шаг 2: Введение (первые 5 минут)

Ключевой момент — снять тревожность. Скажите пользователю:

Скрипт введения для Shadowing:

«Здравствуйте, [Имя]. Спасибо, что согласились. Я здесь не чтобы оценивать вашу работу — меня интересует процесс, а не вы лично.

Моя задача — понять, как работает система, чтобы улучшить её. Я буду сидеть рядом и записывать шаги, которые вы делаете.

Пожалуйста, работайте как обычно. Если вы обычно пьёте чай, пейте чай. Если разговариваете с коллегами — разговаривайте. Если ругаетесь на систему — ругайтесь. Мне важна реальная картина.

Я не буду вмешиваться. Даже если вы сделаете ошибку — я не скажу. Я просто замечу. Это мой способ учиться.

Если захотите что-то пояснить — говорите вслух (метод think-aloud). Если нет — просто работайте молча, я сам посмотрю.

Могу я сесть сбоку, чтобы видеть экран, но не мешать?»

Что важно донести:

«Я не ваш начальник, я — исследователь»
«Я не оцениваю вас — я оцениваю систему»
«Работайте естественно — я не буду вмешиваться»

Шаг 3: Организация пространства

Параметр	Рекомендация
Позиция	Сбоку (не за спиной!), чтобы видеть экран, но не дышать в затылок
Дистанция	НЕ вплотную. 0.5–1 метр. Не заглядывать через плечо
Инструменты	Блокнот + ручка (стук клавиш может раздражать). Или планшет
Длительность	1–4 часа. Не больше 4 часов за раз — внимание падает у обеих сторон
Телефон	Без звука. Не смотреть в телефон (пользователь подумает, что вам скучно)
Перерывы	Если сессия > 2 часов — предложить чай (и себе, и пользователю)

Шаг 4: Think-Aloud Protocol

Попросите пользователя проговаривать свои действия:

«Пожалуйста, комментируйте вслух то, что вы делаете и о чём думаете. Не для меня — для себя. Как будто вы объясняете стажёру, который сидит рядом».

Пример think-aloud:

«Так, открываю заявку... смотрю статус... "На согласовании". Нажимаю "Согласовать"... Ой, а поле "Комментарий" обязательное. Что написать? "Согласовано". Нет, это слишком коротко... "Согласовано, замечаний нет". Нажимаю "Отправить". Всё, заявка ушла... А, чёрт, я забыла прикрепить скан договора. Надо отозвать...»

Без think-aloud аналитик увидел бы только: «Нажала Согласовать → отправила → что-то ищет». С think-aloud — видно затруднения, неоднозначности, ошибки.

Важно: Think-aloud — навык, утомительный для пользователя. Начните с 10–15 минут, потом спросите: «Не слишком утомительно? Можем делать паузы».

3.4. Как фиксировать результаты

Что фиксировать

Каждый шаг пользователя записывается в структурированном виде:

Время	Действие	Система	Эмоция / Комментарий	Инсайт / Требование
09:32	Открывает заявку №584	CRM	—	—
09:33	Нажимает «Печать»	CRM (кнопка)	Раздражение: «Почему печать не на своём месте?»	Usability: переместить кнопку «Печать» ближе к данным
09:35	Сверяет данные из CRM с Excel-файлом	CRM + Excel	«У меня всегда открыт Excel, потому что в CRM нет графы "Дата отгрузки"»	ФТ: добавить поле «Дата отгрузки» в форму заявки
09:38	Копирует номер заказа из CRM в 1С	CRM → Ctrl+C → Alt+Tab → 1С → Ctrl+V	Автоматизация: передавать номер заказа в 1С через интеграцию, а не ручной ввод
09:40	Открывает email (Outlook)	Outlook	«Пришло уведомление об ошибке, но я его прочитала только через час»	Alerting: критические ошибки должны приходить в Telegram / SMS, а не email

Шаблон протокола Shadowing

Дата: 15.05.2026
Пользователь: Анна, оператор отдела продаж (8 лет в компании)
Наблюдатель: Иван, системный аналитик
Длительность: 2 часа (09:30–11:30)

Контекст: Обычный рабочий день. Анна обрабатывает заявки дистрибьюторов.

Ключевые наблюдения:
1. Анна постоянно переключается между CRM, Excel и 1С (в среднем 12 переключений в час)
2. Поле "Дата отгрузки" отсутствует в CRM — Анна ведёт его в Excel (источник расхождений)
3. Каждую 5-ю заявку нужно перепечатывать — кнопка "Печать" расположена неудобно

Требования:
- REQ-101: Добавить в карточку заявки поле «Дата отгрузки» (ФТ)
- REQ-102: Переместить кнопку «Печать» в верхнюю панель карточки заявки (Usability)
- REQ-103: Интеграция CRM → 1С по номеру заказа (ФТ, интеграция)

Открытые вопросы:
- Почему "Дата отгрузки" не была добавлена раньше? (история)
- Как часто CRM перезагружается? (Анна не знает, надо спросить у IT)

Цитаты:
«Если бы в CRM была дата отгрузки, я бы не вела Excel — это 2 часа в день»
«Кнопка "Печать" — это мой враг. Она каждый раз прячется»

Инструменты для фиксации

Инструмент	Когда использовать
Блокнот + ручка	Офлайн, не шумит, не отвлекает
Планшет + стилус	Можно делать зарисовки интерфейса
Диктофон	Только с разрешения пользователя (и HR). Фиксирует think-aloud
Видеозапись экрана	С разрешения! Позволяет пересмотреть и не отвлекаться на записи
CamScanner / фото	Сфотографировать экран с ошибкой (спросить разрешения)

3.5. Этические правила Shadowing

Правило	Почему важно
Предупредить заранее (3+ дня)	Внезапное наблюдение — стресс и подрыв доверия
Не оценивать	Аналитик не делает замечаний: «Вы не так заполнили», «Почему вы так долго?». Только наблюдает
Конфиденциальность	Реальные данные (фамилии, суммы) не покидают протокол. В протоколе — обезличенные данные
Право остановиться	Пользователь может прервать сессию в любой момент без объяснения
Не вмешиваться	Даже если пользователь делает ошибку — не подсказывать. Вы здесь не чтобы помочь, а чтобы учиться
Благодарность	После сессии — поблагодарить, можно небольшим подарком (кофе, шоколадка)
Обратная связь	Через 1–2 дня отправить резюме наблюдений и спросить: «Всё ли я правильно понял?»

3.6. Shadowing vs Другие методы наблюдения

Метод	Что делает аналитик	Когда применять
Shadowing (тень)	Следует за пользователем, фиксирует каждый шаг	Нужно детальное понимание процесса AS-IS
Fly-on-the-wall	Наблюдает со стороны, не взаимодействуя	Нужно увидеть групповое взаимодействие, совещания
Contextual Inquiry	Наблюдает + задаёт вопросы по ходу	Гибрид Shadowing и интервью (требует большого навыка)
Съёмка экрана / Video Recording	Записывает рабочий процесс на видео	Процесс длинный, аналитик не может сидеть 8 часов
Diary Study	Пользователь сам ведёт дневник своих действий	Процесс распределён во времени (неделя, месяц)

3.7. Типичные ошибки Shadowing

Ошибка	Почему это плохо	Как правильно
Наблюдать за лучшим сотрудником	Его процесс может отличаться от типичного	Выбрать «среднего» пользователя
Вмешиваться и советовать	Ломает естественное поведение	Записывать мысль, обсудить после сессии
Слишком длинная сессия (>4 часов)	Устают оба, теряется фокус	Разбить на 2 сессии по 2 часа
Нет think-aloud инструкции	Аналитик не понимает, что делает пользователь	Попросить проговаривать. Тренироваться 5 мин в начале
Пользователь — начальник	Начальник не выполняет типовые операции	Наблюдать за рядовыми сотрудниками
Не записывать время	Потеря метрики реальной длительности	Фиксировать время каждого шага
Единичное наблюдение	Сегодня — понедельник, процесс может отличаться от пятницы	Провести 2–3 сессии в разные дни

4. Сравнение методов: что когда использовать

Ситуация	Document Analysis	Shadowing	Почему
Проект стартует с нуля	✅	❌	Нет процессов для наблюдения
Замена legacy-системы	✅	✅	Оба метода: изучить старую документацию и посмотреть, как работают сейчас
Внедрение ERP	✅	✅	Регламенты важны, но практика отличается
Оптимизация процесса	❌	✅	Документы не покажут узкие места — только наблюдение
Compliance-проект (152-ФЗ, PCI DSS)	✅	❌	Нормативные требования — главный драйвер
UX-проект (улучшение интерфейса)	❌	✅	Только наблюдение покажет реальные проблемы

Идеальная комбинация:

Document Analysis — изучить регламенты и документацию (официальная версия)
Shadowing — посмотреть, как работает пользователь (реальность)
Сопоставить — найти расхождения (gap analysis)
Уточнить интервью — обсудить расхождения с пользователем

5. Полный пример: анализ кейса «Замена CRM»

Этап	Метод	Что узнали
1	Document Analysis: регламент отдела продаж	В регламенте: «Менеджер создаёт заказ в CRM за 2 минуты». Шагов: 10.
2	Document Analysis: SRS старой CRM	Обнаружили: поле «Тип клиента» не было реализовано, хотя было в SRS 2019.
3	Shadowing (2 часа, менеджер Анна)	В реальности: 15 минут на заказ, 3 переключения между CRM и Excel, 2 раза CRM зависла.
4	Сопоставление регламент vs реальность	Регламент: 2 минуты. Реальность: 15 минут. Gap = 13 минут.
5	Интервью по итогам	«Почему вы используете Excel, если в CRM есть поле для заметок?» — «Поле заметок видит только менеджер, а Excel я отправляю начальнику». → Требование: разные права видимости полей.

Вопросы для самопроверки

Какие 6 категорий документов может изучать аналитик? Приведите пример документа для каждой.
В чём состоит «gap analysis» при сопоставлении регламента и реальности?
Какие 5 шагов включает процесс анализа документов?
В чём разница между Shadowing и Contextual Inquiry?
Как подготовить пользователя к Shadowing, чтобы он не нервничал? Напишите скрипт введения.
Что такое Think-Aloud Protocol? Как его объяснить пользователю?
Почему наблюдать за «лучшим сотрудником» — ошибка?

Практическое задание

Кейс: Вы — аналитик в проекте «Автоматизация процесса выдачи пропусков в офис». Сейчас сотрудник приходит в бюро пропусков, заполняет бумажную анкету, секретарь проверяет данные в Excel, затем вносит в систему СКУД (контроль доступа). Процесс занимает 15–20 минут.

Задание 1. Document Analysis:

Составьте список документов, которые вы запросите для анализа (минимум 5).
Для каждого документа укажите: что вы надеетесь в нём найти (какие требования/инсайты).

Задание 2. Shadowing:

Напишите полный скрипт введения для секретаря бюро пропусков (минимум 150 слов). Используйте структуру из урока.
Какие 3 ключевые вещи вы будете фиксировать в протоколе наблюдения?
Предположите, какие 2 расхождения между «регламентом и реальностью» вы можете обнаружить.

Формат: Один файл (md) с двумя разделами.

Дополнительные материалы

Книга: «Contextual Design» — Hugh Beyer, Karen Holtzblatt (методология Contextual Inquiry — развитие Shadowing)
Книга: «Observing the User Experience» — Elizabeth Goodman, Mike Kuniavsky (UX-наблюдение)
BABOK 3.0: Глава 4.2 — Elicitation (Document Analysis, Observation)
Стандарт: ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы» (структура ТЗ в России)
Статья: «The Art of Shadowing: How to Observe Users Without Creeping Them Out» — Nielsen Norman Group
Шаблон: Shadowing Log Template (Google Sheets / Excel)
Инструмент: OBS Studio — запись экрана для удалённого наблюдения (с разрешения пользователя)

Анализ документов и Shadowing (наблюдение)