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