· Заметки о продукте

Чеклист пилота Zorky: что подготовить до старта

Пилот проваливается не из‑за «модели», а из‑за неготовности стенда и размытых критериев успеха. Ниже — практический чеклист до старта: сторона заказчика, сторона Zorky, замеры.

Зачем чеклист, а не «просто включить камеру»

Zorky встраивается в существующее МПС. Значит, пилот — это совместный инженерный проект: доступ к тестовой сборке, ответственный разработчик, согласованные сценарии и площадка. Без этого техдемо превращается в презентацию.

Опубликованные кейсы появляются в разделе /cases/ только после согласования с заказчиком. До этого чеклист — способ не потерять месяцы на организационных дырах.

Что нужно от заказчика

  • Тестовый стенд МПС — сборка, куда можно встроить SDK без риска для продакшена.
  • Ответственный разработчик — контакт, который реально выделяет время на интеграцию и регрессию.
  • 1–2 сценария — например, поиск заказа на стеллаже или поиск обуви по артикулу; не «всё сразу».
  • Площадка — участок с реальными этикетками и понятным регламентом смены.
  • Критерии успеха — заранее, в измеримых наблюдениях (не обязательно в публичных цифрах).

Опционально, но ускоряет

Опросный лист ИБ и NDA — если ИБ подключается до пилота. Доступ к тестовым справочникам заказов/артикулов. Согласование окна для ограниченного запуска.

Что даёт Zorky

Техническая рамка поставки — на странице SDK. Мы не обещаем универсальные сроки в неделях: они зависят от вашего релизного цикла.

  • Документацию и примеры интеграции.
  • Поддержку встраивания на этапе техдемо и пилота.
  • Согласование формата отчёта по итогам ограниченного запуска.
  • При необходимости — ИБ-брифинг и ответы на опросный лист.

Как замерять результат

До пилота договоритесь, что считается успехом. Примеры направлений замера (без нормативных значений):

  • Время от постановки задачи до нахождения нужной позиции (наблюдение на площадке).
  • Доля задач, завершённых без переключения на «второе приложение».
  • Субъективная нагрузка обучения для новых сотрудников (качественный фидбек смены).
  • Технические метрики модуля: попытки, пустые результаты, отмены — в согласованном составе.

Публикация цифр

Любые цифры в маркетинге и в разделе кейсов — только после письменного согласования. Внутри пилота цифры могут жить в закрытом отчёте.

Короткий pre-flight перед стартом

Если пункт не закрыт — лучше сдвинуть старт, чем получить «пилот без данных». Заявка на пилот — через форму ниже или раздел кейсов.

  1. Брифинг: сценарии, роли, критерии.
  2. Стенд МПС доступен, SDK подключен в тестовой сборке.
  3. Разрешения камеры и устройства для пилотной группы проверены.
  4. План ограниченного запуска согласован с площадкой.
  5. Формат отчёта и дата разбора итогов назначены.

Риски, которые стоит закрыть письменно

  • Нет владельца пилота со стороны заказчика — задачи «висят» между ИТ и операциями.
  • Стенд МПС доступен только через месяц — техдемо без встраивания.
  • Сценариев слишком много — распыление и нет сопоставимых замеров.
  • ИБ подключается в конце — внезапный стоп перед площадкой.
  • Критерий успеха «почувствуем» — невозможно принять go/no-go.

Зафиксируйте владельца, дату разбора и формат отчёта в коротком протоколе брифинга. Это дешёвая страховка. Публичные кейсы в разделе кейсов появятся позже; внутренний отчёт пилота может существовать раньше и не обязан быть публичным.

Если ИБ требует пакет документов до выхода на площадку — заложите это в timeline явно. Параллелить «уже ищем на стеллаже» и «ещё не ответили на опросный лист» рискованно для репутации пилота внутри сети.

Минимальный протокол брифинга

Сценарии, роли, критерии, дата стенда, дата площадки, формат отчёта, открытые вопросы ИБ. Одного листа достаточно, чтобы не потерять договорённости в переписке.

После пилота: rollout или пауза

Если критерии выполнены — планируйте промышленный rollout: расширение групп, обучение смен, мониторинг технических метрик, поддержка релизов МПС. Если нет — зафиксируйте причины (этикетки, UX, данные, интеграция) и решите, нужен ли второй ограниченный запуск.

Не смешивайте «модель плохо работает» и «стенд не был готов». Чеклист выше как раз отделяет одно от другого. Команда Zorky помогает разобрать отчёт; решение о масштабировании — за заказчиком.

Для подготовки технического контура держите под рукой страницу SDK. Для подготовки ИБ — privacy и whitepaper. Для ожидания публичных историй — раздел кейсов без вымышленных сетей и цифр.

Заявка на пилот через форму на этой странице или через раздел кейсов запускает тот же процесс брифинга. Чем конкретнее вы опишете стенд и сценарии, тем быстрее можно перейти от разговора к тестовой сборке.

Пример плана на первую неделю пилота

День 0: протокол брифинга согласован по смыслу — сценарии, роли, критерии. Далее: доступ к стенду МПС и ветке интеграции, модуль в тестовой сборке, permission и базовый UI, прогон фикстур и ручной чеклист на устройстве.

Затем — окно на площадке по согласованному графику смены. Ежедневно короткий разбор: что мешало, какие этикетки, какие UX-правки. В конце окна — отчёт и решение go или no-go. Календарные оценки зависят от заказчика; это каркас, не обещание сроков.

Параллельно держите открытым список вопросов ИБ. Если брифинг ИБ ещё не проведён, не расширяйте пилотную группу только потому, что операциям нравится интерфейс. Масштаб без комплаенс-контура создаёт откат дороже, чем пауза.

После go — отдельный план rollout: обучение, мониторинг, поддержка релизов. После no-go — список причин и решение о повторном ограниченном запуске. Оба исхода нормальны, если критерии были честными с самого начала.

Кому внутри сети нужен статус пилота

Операции — чтобы понимать, что меняется на смене. ИТ/МПС — чтобы планировать релизы. ИБ — чтобы не узнать о камере постфактум. Закупки — если сравнивают с ТСД. Руководитель площадки — чтобы выделить окно и людей. Короткий статус раз в неделю снимает слухи лучше, чем большой отчёт в конце.

В статусе достаточно: что сделано, что блокирует, какое следующее окно площадки. Без выдуманных процентов готовности и без обещаний даты промышленного запуска до go по критериям.

Краткий итог

Пилот стартует, когда есть стенд, владелец, 1–2 сценария, критерии и понятный формат отчёта. Технический контур — через SDK; комплаенс — через ИБ-брифинг; публичные истории — только после согласования в разделе кейсов.

Если чего-то из списка нет, честнее сдвинуть старт, чем получить красивое демо и пустой отчёт. Форма ниже — точка входа в тот же процесс брифинга.

Запросить пилот

Пришлите контекст сети и сценарий — вернёмся с форматом брифинга.

Заявка

Укажите компанию и вопрос — ответим по демо или пилоту.

Заявка придёт на info@softverno.ru.