Сэкономили на разработке. За что теперь платит бизнес?

Убрали из сметы. А из работы?

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

По отдельности каждое решение выглядит терпимо. Особенно когда бюджет ограничен и хочется уже запуститься. Но после запуска заказы всё равно нужно переносить, товары — находить, ошибки — исправлять. Просто этой работой теперь занимаются люди.

По моему опыту, при обсуждении бюджета легко недооценить именно такие вещи. Их трудно показать на красивом первом экране. Зато их отсутствие хорошо чувствуется в обычный рабочий день: кто-то снова копирует адрес, объясняет статус или помогает оформить заказ с телефона.

Я не считаю, что в первую версию нужно включать всё. Полезнее задать другой вопрос: если мы уберём эту функцию, кто будет выполнять её работу, как часто и насколько это неудобно? Ответ помогает отличить разумное сокращение объёма от расходов, которые просто переехали из сметы в ежедневные процессы.

Покупатель снова собирает то, что уже покупал

Представим магазин расходных материалов. Клиент регулярно заказывает примерно один и тот же набор: бумагу, упаковку, несколько видов канцелярии. История заказов есть, но повторить заказ нельзя. Человек открывает старый список и заново ищет каждую позицию.

Для магазина это может выглядеть как небольшое неудобство. Для покупателя это отдельная задача: найти правильный артикул, не перепутать размер, указать количество, убедиться, что ничего не забыто. Менеджер помогает ему по телефону, хотя все исходные данные уже находятся в системе.

При этом кнопка «Повторить» не должна слепо копировать старый заказ. За прошедшее время могли измениться цены, остатки и упаковки. Какой-то товар сняли с продажи. Хороший сценарий переносит доступные позиции, объясняет изменения и оставляет покупателю возможность проверить результат.

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

«Менеджер пока перенесёт руками» — тоже рабочее решение

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

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

Здесь полезно замерить несколько обычных операций целиком. Время от открытия заказа до проверки результата — более честная величина, чем время на одно копирование. Исправления и уточнения можно учитывать отдельно, чтобы не потерять их и не посчитать дважды.

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

У автоматического обмена тоже есть работа по сопровождению: сопоставление справочников, проверка отказов, изменение форматов. Поэтому сравнивать стоит два конкретных процесса — текущий ручной и будущий с автоматизацией. Фраза «всё будет происходить само» для такой оценки слишком расплывчата.

Сколько времени набегает за месяц

Возьмём условный пример: 30 операций в рабочий день, четыре минуты на каждую, 22 рабочих дня. Получается 44 часа в месяц. В отдельном заказе четыре минуты почти незаметны; в сумме это уже объём работы, который стоит обсудить.

Подставьте свои значения. Считать можно перенос заказа, подготовку документа или повторное уточнение данных. Если операцию выполняют несколько сотрудников, укажите общее количество операций всей команды.

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

На обработке ошибок тоже можно сэкономить. До первого обращения

Покупатель заполнил форму и нажал «Отправить». В ответ — «Произошла ошибка». Какие данные не подошли? Создалась ли заявка? Нужно ли пробовать ещё раз? Человек не знает и либо повторяет действие, либо пишет менеджеру.

Если при этом форма очистилась, ему придётся вводить всё заново. Если заявка успела сохраниться, повторная отправка может создать дубль. Теперь уже сотрудник выясняет, сколько заказов клиент хотел оформить на самом деле.

Такие ситуации редко выглядят как отдельная большая функция. Однако они входят в обычный пользовательский путь. Нужно сохранить введённые данные, объяснить исправимую ошибку рядом с нужным полем, показать выполнение запроса и однозначно сообщить о результате.

Для действий с последствиями — создания заказа, бронирования, оплаты — одной заблокированной после нажатия кнопки недостаточно. Система должна учитывать повтор запроса. Конкретный механизм зависит от операции, но сам вопрос стоит включить в разработку сразу: что произойдёт, если одно действие придёт дважды?

Необязательно угадывать все исключения заранее. Начните с тех, которые легко воспроизвести: обязательное поле не заполнено, соединение пропало, внешний сервис не ответил, пользователь вернулся назад. По ним уже видно, сможет ли человек продолжить работу самостоятельно.

Мобильная версия и скорость — часть основного сценария

Отдельно я бы смотрел на вещи, которые часто откладывают под названием «полировка». Например, страницу сверстали под телефон, но выбор количества неудобен, клавиатура закрывает подсказку, а после ошибки пользователь теряет введённый адрес. Формально мобильная версия существует. Покупку с неё всё равно трудно завершить.

Со скоростью похожая история. При проверке на рабочем компьютере страница открывается нормально. Но покупателю приходится ждать тяжёлые изображения или скрипты, прежде чем заработает нужная кнопка. Если он в этот момент пытается оформить заказ, задержка становится частью обслуживания.

Не нужно начинать с требования добиться максимального балла во всех инструментах проверки. Пройдите основные действия на телефоне и посмотрите, где человек ждёт, ошибается или не понимает следующий шаг. Данные об устройствах посетителей помогут расставить приоритеты, а проверка на обычном устройстве покажет то, что легко пропустить в макете.

Можно отложить сложную анимацию. Рабочий поиск, понятная корзина и возможность отправить форму заслуживают отдельной проверки в той версии продукта, которую уже предлагают клиентам.

Что можно отложить без лишней драмы

Ограниченный бюджет заставляет выбирать, и это нормально. Для первой версии полезно оставить один законченный рабочий путь: покупатель может оформить заказ, сотрудник — обработать его, а обе стороны понимают результат.

Дальше можно сокращать число сценариев. Например, начать с одного согласованного способа доставки, одного формата импорта или одной схемы согласования. Ограничение должно быть видно пользователю и соответствовать тому, что компания действительно готова обслуживать.

К редким настройкам, дополнительным ролям и сложным отчётам можно вернуться, когда появятся реальные примеры использования. Но доступ к чужим данным, потеря заказов и невозможность исправить ошибку не становятся второстепенными оттого, что продукт называется первой версией.

Перед сокращением сметы задайте четыре вопроса

Для каждой спорной функции запишите, кто будет выполнять её работу без автоматизации, как часто возникает задача, что случится при ошибке и по какому признаку вы вернётесь к доработке. Этого достаточно, чтобы обсуждать не абстрактное «дорого», а конкретные последствия решения.

Последний вопрос особенно полезен. «Вернёмся когда-нибудь» легко забыть. «Вернёмся, когда перенос заказов начнёт задерживать их обработку» уже можно проверить. Ещё лучше заранее определить, как команда заметит эту задержку и кто поднимет вопрос.

Если функцию решено отложить, временный процесс тоже нужно устроить: назначить ответственного, договориться о порядке действий и убедиться, что клиент понимает происходящее. Тогда компания сознательно выбирает ручную работу на этом этапе.

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