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