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

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

Я задал автору несколько уточняющих вопросов (а вдруг передо мной начинающий коллега, ну бывает же). Выяснилось, что это была первая подобная автоматизация в компании, а сам Алексей не имел опыта архитектурного проектирования. Первоначальное решение содержало около 30–50 активностей, но после последовательных доработок выросло до "502 нод, 74 веток выполнения и 111 переменных". Накопился технический долг, потребовался рефакторинг.

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

Подмена анализа реализацией

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

Отказ кандидата выйти на работу или прекращение трудовых отношений во время адаптации не являются неожиданными событиями. Для их выявления не требуется знание конструктора Битрикс24. Требуется исследование предметной области. Разумеется, невозможно предусмотреть абсолютно все, но между неизвестными будущими обстоятельствами и невыявленными базовыми сценариями существует принципиальная разница.

Смешение бизнес-процесса и его автоматизации

Автор сообщает о разделении приема и адаптации на два самостоятельных БП. Однако что именно изменилось: границы организационных процессов или структура их автоматизированной реализации? Это разные архитектурные уровни. Бизнес-процесс определяется деятельностью организации, ее целями и результатами, а автоматизированное решение реализует логику поддержки этой деятельности. Разделение технического шаблона на два не обязательно означает изменение архитектуры бизнес-процессов организации.

Недостаточное управление изменениями

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

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

Ложная альтернатива

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

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

Именно поэтому меня удивляет не история первого проекта и не необходимость рефакторинга. Ошибки случаются, особенно при освоении новой технологии. Меня удивляет профессиональный вывод Алексея.

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

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

И это вопрос не к возможностям Битрикс24, а к методологии анализа и проектирования.