Когда за разработку процессов берутся люди, далекие от понимания алгоритмов, часто возникают ошибки. Причем, на словах, в понимании разработчиков, процесс получается вполне себе годным, но на бумаге он становится нерабочим. Люди думают – да ладно, все же понимают, как надо работать, а бумажка – это так, для отписки.

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

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

Особенно много ошибок допускается при рисовании схем алгоритма процесса. Тут «помогает» сам формат нарисованного процесса, требования к схеме и правила оформления. Нарисовать живой процесс в таких требованиях сложно, но нарисовать – «надо», особенно если действует какой-либо стандарт оформления. Вот и рисуют, кто как умеет, лишь бы «сдать».

Оформление процесса в виде алгоритма – это просто проекция, переложение понятной информации в некий формат. Любая проекция всегда ведет к потере части информации, либо к ее искажению. И красивая схема, и квалиграмма, и текстовое описание, и должностная инструкция – просто проекции.

Любая проекция искажает. Это – основной принцип, который следует помнить при разработке формализованного описания процесса. Как тогда быть? Ведь описание процесса – необходимо.

Правило номер 1: не начинайте с описания процесса.

Начните с самого процесса – сделайте его рабочим. Достигните критериев, которые вы или заказчик предъявили к процессу. Потом описание сделаете.

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

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

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

Правило номер 2: используйте несколько форматов одновременно.

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

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

Аналогично стоит описывать процессы. Например, в схеме для исполнителей нет смысла упоминать методики, которые вы использовали – людям это не интересно. А вот бизнес-программисту, который возьмется за рефакторинг процесса, будет полезно знать, что вы применили принципы ТОС или Scrum.

Главное же – не забывайте о здравом смысле. В бизнес-программировании нет стандартов, строгих правил и законов, кроме одного: должно работать.