На первой встрече руководитель просит личный кабинет, уведомления и отчёты. Подрядчик уточняет количество экранов, затем предлагает оценку. Через неделю выясняется, что часть сотрудников работает без постоянного доступа к сети, исходные данные меняет другое подразделение, а отчёт нужен для решения, которое пока никто не сформулировал.
Бриф помогает подготовить разговор: описать задачу, участников и условия, которые влияют на решение. Он не требует знания архитектуры и не заменяет техническое задание. Его результат — общий контекст и перечень вопросов, на которые нужно ответить до выбора способа реализации.
Ниже приведён шаблон с условным примером внутреннего сервиса заявок на обслуживание. Его можно скопировать в документ, заменить данные своими и приложить несколько обезличенных образцов. Если ответ неизвестен, так и пишите: честный пробел полезнее уверенного предположения.
Назначьте человека, который знает процесс
Владельцем брифа должен стать представитель бизнеса, способный объяснить, зачем меняется работа и кто принимает спорные решения. ИТ помогает описать системы и ограничения, а сотрудники показывают реальные действия. Один руководитель не всегда видит обходные пути, которыми пользуется команда.
Перед заполнением поговорите с двумя-тремя участниками процесса. Попросите показать последний обычный случай и последний проблемный. Запишите факты: что поступило, кому передали, чего не хватило, как узнали о завершении. Не начинайте с вопроса «какие функции вам нужны»: он часто даёт перечень привычных кнопок.
В руководстве GOV.UK об исследовании задачи предлагается сначала разобраться в пользователях, контексте и ограничениях. Исследование может показать, что проблему лучше решить изменением процесса, а не созданием нового сервиса. Бриф должен оставлять эту возможность открытой.
Блок 1. Задача, последствия и границы
Скопируйте следующие пункты и впишите ответы.
- Название процесса: что сотрудники делают от начала до завершения.
- Проблема: какое повторяющееся затруднение мешает работе.
- Последствие: кому и чем обходится затруднение.
- Основание: наблюдение, журнал, выборка или другое подтверждение.
- Входит в обсуждение: участок процесса, который хотим изменить.
- Пока исключено: соседние задачи, которые не требуется решать на первом этапе.
Заполненный пример: «Принимаем внутренние заявки на обслуживание оборудования. Обращения приходят в почту и общий чат, координатор переносит их в файл. Сотрудники повторно спрашивают статус, потому что не знают ответственного. За две недели проверили 60 обращений: по 14 пришлось отдельно выяснять, кто продолжает работу. Хотим упорядочить регистрацию, назначение и возврат на уточнение. Склад запчастей и расчёт зарплаты пока исключены».
Числа в примере условные. Если измерений нет, напишите: «По наблюдению координатора; требуется проверить на выборке». Не превращайте впечатление в точный показатель. На встрече это станет задачей исследования, а не спором о достоверности.
Блок 2. Участники и существующий маршрут
Для каждой роли укажите действие, решение и доступные сведения. Название должности само по себе недостаточно: два сотрудника одного отдела могут иметь разные обязанности.
В нашем примере:
- Инициатор: описывает проблему, прикладывает сведения, отвечает на уточнения.
- Координатор: проверяет полноту, назначает исполнителя, отслеживает незавершённые обращения.
- Исполнитель: подтверждает принятие, сообщает результат либо причину возврата.
- Руководитель: разбирает просрочки и спорные случаи.
- ИТ: сопровождает доступы и согласует подключение к существующим системам.
Кратко опишите нынешнюю последовательность: сообщение → ручная запись → назначение в чате → выполнение → ответ инициатору. Отметьте, какие шаги выполняются вне рабочего времени и где теряется информация.
Формулировка потребности может быть такой: «Координатор хочет видеть обращения без назначенного исполнителя, чтобы распределять их до конца смены». Она связывает участника, действие и цель, как рекомендует GOV.UK в руководстве по пользовательским историям. Детальные правила появятся позже, при подготовке требований.
Блок 3. Объём и условия работы
Заполните три разных величины: сколько людей имеют доступ, сколько работает одновременно и сколько операций проходит за период. Эти показатели нельзя заменять друг другом.
Условный ответ: «24 инициатора, четыре координатора, восемь исполнителей; одновременно обычно до десяти человек. Около 300 обращений в месяц, по понедельникам до 30 новых за утро. Основная работа идёт с настольных компьютеров. Исполнитель иногда открывает данные с телефона на участке, где связь нестабильна».
Добавьте сезонность, планируемое расширение и источник оценки. Если мобильная работа критична, опишите, какое действие нужно выполнить, а не просто попросите приложение. Просмотр заявки и полноценная работа без связи — разные требования.
Укажите также рабочие языки, ограничения браузеров и условия использования общих компьютеров, если они действительно есть. Не составляйте перечень всех возможных устройств: подрядчику нужны обстоятельства, влияющие на ваш процесс.
Блок 4. Данные и существующие системы
Перечислите основные объекты: заявка, сотрудник, оборудование, результат работы. Для каждого назовите источник и владельца. Приложите небольшой обезличенный образец, сохранив структуру и типичные ошибки.
В примере справочник оборудования ведёт эксплуатация, список сотрудников — кадровая система, а заявки лежат в таблице. Решения о подключениях пока нет. Это нужно написать прямо: наличие файла с выгрузкой не доказывает существование доступного интерфейса обмена.
Мини-шаблон описания источника:
- Название: реестр оборудования.
- Владелец: инженер эксплуатации.
- Формат: текущая таблица с инвентарным номером и участком.
- Изменения: новые позиции добавляют несколько раз в месяц.
- Проблемы: встречаются пустые номера и разные обозначения участка.
- Доступ: образец предоставлен; порядок рабочего обмена не согласован.
Отдельно отметьте сведения, которые нельзя использовать в демонстрационной среде. Вместо пересылки полного рабочего архива подготовьте несколько примеров с заменёнными персональными и коммерчески чувствительными данными.
Блок 5. Ожидаемый результат и его проверка
Фраза «повысить эффективность» не помогает выбрать решение. Опишите, что участник сможет сделать иначе и по каким наблюдениям вы это поймёте.
Для условного процесса можно записать: «Координатор видит все принятые заявки и их ответственных; инициатор находит статус без сообщения в общий чат; незавершённое обращение не исчезает после передачи другому исполнителю». Это ещё не детальная приёмка, но уже направление проверки.
Добавьте исходный показатель, целевой ориентир и способ измерения. Например: долю обращений, по которым приходится отдельно искать ответственного, сравниваем до и после пилота на сопоставимых выборках. Численный ориентир согласуем после проверки исходных данных. Не обещайте процент улучшения, если базовое состояние неизвестно.
Разделите обязательное и желательное. Для пилота обязательны регистрация и ответственность; красивый сводный экран может подождать. Обоснование приоритета должно ссылаться на рабочий результат, а не на личное предпочтение руководителя.
Блок 6. Ограничения, участники решения и вопросы
Запишите внешние даты и их причины. «Нужно к декабрю» может означать обязательный переход, сезонный пик или просто удобное пожелание. Подрядчику важно понимать, что можно менять, а что требует отдельного согласования.
Укажите доступность сотрудников для интервью, проверки и пилота. Если координатор сможет выделять час в неделю, это влияет на ход работы не меньше, чем число экранов. Определите, кто согласует требования, принимает результат и решает разногласия между подразделениями.
Бюджетный ориентир допустимо указать диапазоном либо написать, что его предстоит определить. Рядом перечислите существенные неизвестные: качество справочника, доступ к источнику данных, требования к размещению. Для каждого вопроса назначьте владельца и следующий способ проверки.
Проверьте бриф перед отправкой
Попросите коллегу, не участвовавшего в заполнении, пересказать задачу. Документ готов к первой встрече, если человек может ответить, кто работает, что мешает, какой участок меняется и как будет замечено улучшение.
Проверьте короткий список:
- Есть один владелец задачи и реальные участники процесса.
- Отделены наблюдаемые факты, оценки и неизвестные.
- Описаны обычный случай и хотя бы одно исключение.
- Указаны объёмы, источники данных и существенные ограничения.
- Границы первой задачи не смешаны с пожеланиями на будущее.
- Приложения обезличены и помогают понять работу.
После встречи обновите бриф: зафиксируйте уточнения, открытые вопросы и следующий результат обсуждения. Не превращайте каждое предложение подрядчика в обязательное требование. Сначала проверьте, какую потребность оно закрывает.
В ExtentLab можно прийти с таким брифом и несколькими примерами обращений. Этого достаточно для содержательного разговора о процессе; готовая архитектура или список всех экранов для первой встречи не нужны.
Источники и материалы по теме
- GOV.UK: исследование задачи до разработки.
- GOV.UK: роль, потребность и цель пользователя.
- Как превратить сценарии в техническое задание.
- Как контролировать бюджет разработки.