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