В реальной работе всё идёт не по плану

В начале проекта процесс обычно описывают довольно просто.

Клиент приходит. Заказ оформляют. Оплату принимают. Работа завершена.

На бумаге всё выглядит логично. Но в повседневной работе всё происходит не так гладко.

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

Это не какие-то исключительные ситуации, которые случаются раз в год. Это обычная часть работы бизнеса.

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

Именно здесь и начинается проблема.

С чего начинается проблема?

Часто проблема возникает не во время написания кода, а ещё на этапе описания самого процесса.

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

Но в реальной работе именно на них уходит немало времени и внимания.

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

В итоге на экране всё выглядит нормально, хотя на самом деле вопрос ещё не закрыт.

Часть информации хранится в системе, часть — в переписке, а окончательное решение вообще остаётся в чьей-то памяти. Через некоторое время, чтобы разобраться в ситуации, приходится искать не данные в системе, а сообщения и заметки.

Когда исключение перестаёт быть исключением?

Я бы не стал считать ситуацию исключением только потому, что она отличается от основного сценария.

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

Например:

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

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

Если эти ситуации не предусмотрены в системе, программа отражает не то, как бизнес работает на самом деле, а то, как мы предполагаем, что он должен работать.

Что нужно выяснить до разработки системы?

Разумеется, сначала необходимо определить основной рабочий процесс. Без этого сложно понять его границы.

Но этого недостаточно. Нужно заранее обсудить и ситуации, которые регулярно возникают в повседневной работе.

Начать можно с нескольких простых вопросов:

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

Ответы на эти вопросы могут увеличить объём разработки. Возможно, понадобятся дополнительные статусы, новые правила или отдельная логика обработки операций.

Само по себе это не проблема.

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

В заключение

Объяснить процесс на встрече несложно. Настоящие трудности начинаются тогда, когда что-то идёт не по плану.

Хорошая система должна учитывать не только ситуации, в которых всё работает как задумано, но и то, как бизнес справляется с повседневными проблемами.

Сначала нужно разобраться в реальных правилах работы бизнеса, а уже потом строить систему на их основе.

Потому что повседневная работа бизнеса не ограничивается идеальным сценарием.