ГЛАВНАЯ МЫСЛЬ
Для первого этапа выберите одну операцию, которую сотрудник сможет выполнить целиком в новой системе.
Посмотрите, как проходит обычная операция
Допустим, администратор получает заявку в сообщении, проверяет свободное время в таблице, записывает имя гостя и отдельно отмечает предоплату. Чтобы подтвердить одну бронь, он открывает несколько окон. Именно эту последовательность полезно разобрать перед заказом программы.
Попросите сотрудника показать недавнюю заявку от начала до конца. Где он искал сведения? Что копировал вручную? В какой момент уточнял что-то у коллеги? На таких примерах быстрее обнаруживаются лишние действия и исключения, о которых редко вспоминают на общей встрече.
Название будущего инструмента можно выбрать позже. Даже знакомое слово CRM — система для учёта работы с клиентами — пока мало говорит о том, что конкретно нужно вашему администратору.
Ограничьте первый этап
После первого разговора список пожеланий обычно растёт: к бронированию хочется добавить отчёты, переписку, смены и расчёт зарплаты. Сохраните эти идеи, а для начала выберите законченный участок работы. Например, от заявки гостя до подтверждённой записи у администратора.
Теперь разберите исключения внутри этого участка. Выбранное время уже занято. Гость передумал. Администратор исправил дату. Два человека одновременно открыли одну запись. Такие ситуации входят в ежедневную работу, поэтому их стоит обсудить до разработки.
- С какого действия начинается операция?
- Кто её выполняет и какие сведения ему нужны?
- Кто вправе изменить или отменить запись?
- Что должно произойти в конце?
Договоритесь, что будете проверять
Запишите ожидаемый результат словами пользователя: «Я ввожу данные гостя один раз, и подтверждённая бронь появляется в рабочей программе». По такой формулировке можно проверить готовую версию. Обещание «повысить эффективность» для приёмки слишком расплывчато.
Если важна скорость, замерьте несколько обычных операций до изменений. Отдельно отметьте сложные случаи: поиск старой заявки, исправление ошибки, отмену. После запуска сравните те же действия в похожих условиях. Так у обсуждения появится основа, даже если первая версия ещё требует доработок.
Доведите одну задачу до конца
Первая версия полезна, когда с её помощью можно закончить работу. Для бронирования это весь путь от ввода данных до подтверждения или понятного отказа. Если после красивой формы сотруднику всё равно приходится переносить заявку в таблицу, этот шаг остаётся частью задачи.
Будущие связи тоже стоит обозначить заранее: обмен с сайтом, доступ руководителя, загрузку старых записей. Разработчику важно знать о них при выборе структуры данных. Саму реализацию можно распределить по следующим этапам.
У небольшого первого этапа есть ещё одно удобство: команда успевает разобраться в изменениях и дать предметные замечания, пока проект не разросся.
Проверьте программу вместе с сотрудником
Возьмите те заявки, с которых начался разбор, и попросите сотрудника обработать их в новой системе. Дайте ему попробовать самостоятельно. Пауза перед кнопкой, поиск нужного поля или возврат к старой таблице показывают, что ещё мешает работе.
После запуска разделите замечания на ошибки, неудобства и новые пожелания. Ошибка в расчёте требует исправления, лишний переход — упрощения, новый отчёт — отдельного обсуждения. Такой список помогает выбирать следующий этап по наблюдениям команды.
Начать можно с простого: выбрать одну частую операцию, показать её разработчику и договориться, что сотрудник должен уметь сделать после первой версии.