"Автоматизация хаоса дает лишь автоматизированный хаос" - казалось бы стройная и логичная концепция, но по сути это абсурд!
Пара примеров для наглядности:
1) Если в компании есть несколько отделов, которые при выписке документов используют различные стили нумерации - кто-то сквозную со дня основания компании, кто-то нумерует с начала года, кто-то явно указывает год и месяц в номере как префикс. При автоматизации документооборота никто не будет бегать за каждым сотрудником и спрашивать как именно ему кажется правильно нумеровать документы. Более того, даже за руководителями всех отделов не будут бегать - одного двух введут в рабочую группу автоматизации и только на их рекомендациях будут основываться. Но даже не важно какой стиль нумерации будет выбран по итогу - важно, что теперь новые номера по всей компании будет единообразно выдавать автоматизированная система. И пусть работники других отделов ругаются на привнесенный "хаос" и "бардак", но в разрезе компании уровень энтропии явно понизился.
2) Пусть на складах творится бардак - никто точно не знает сколько там остатка и все смирились с недостачами и пересортами, а кладовщики считают приемлемым редактирование и перепечатывание исправленных экселек, чтобы скрыть свои косяки. При автоматизации вводится система штрихкодирования для отслеживания каждой единицы товара, все движения по складу строго через сканирование, все документы на поступление и выдачу идут строго из системы с уникальным штрихкодом. Первое время кладовщики будут вопить, что им навязали бардак и так работать невозможно (пока не найдут новые методы воровать и успокоятся), но в целом по компании движения товаров станут более прозрачными и количество тех же пересортов уменьшится.
Очевидно, что хаос - это отсутствие учета, а любой учет приводит к уменьшению хаоса. Более того, как "программ без ошибок не бывает", так и не бывает идеального учета и "идеальные процессы" все время улучшаются и адаптируются к изменениям рынка, отрасли и законодательства. Так почему же все фанатично зациклены на попытках сначала написать идеальное ТЗ и лишь затем приступать к написанию мифической "идеальной системы"?
Попробовал найти ранние упоминания выражения:
Автоматизация неэффективной операции увеличивает неэффективность (с) Билл Гейтс, книга "Бизнес со скоростью мысли", 1999 год
Истоки реинжиниринга лежат во фразе, которую один из нас сформулировал еще в конце 1980-х годов: "Автоматизация бардака дает лишь автоматизированный бардак" (с) Майкл Хаммер, книга "Реинжиниринг корпорации: Манифест революции в бизнесе", 1993 год
Таким образом истоки фразы и ее активное применение были даже не в начале 90х, а в 80х или даже в 70х. А что мы знаем про ИТ прошлого века? Верно - методология водопада! Т.е. ранее действительно нужно было написать всю документацию, а потом выполнять разработку буква-к-букве как в ТЗ.
Но старый ватерфлоу не выдержал проверку временем. Подходы начали меняться сначала как раз в ИТ, а далее гибкие методики планирования и проектирования подхватили другие сферы. Даже в ультраконсервативном PMI сдались в 2017 году и включили Agile-практики в 6-ю редакцию PMBOK. А суть гибких подходов как и заключается в том, что нужно перестать пытаться делать сразу идеально, а лучше сделать упор на анализ результатов и в следующую итерацию исправлять ошибки предыдущих подходов.
Так стоит или нет автоматизировать хаос?
Для консультантов ответ очевиден - НЕТ, ведь они зарабатывают деньги на обследованиях и предпроектах. А вот остальным стоит хорошо задуматься, прежде чем в современном мире продолжать использовать устаревшие подходы.
В конце-концов, в военном ремесле тысячи лет назад "разведку боем" придумали не от скуки, и несколько пусть даже провальных MVP могут дать для качественной будущей автоматизации больше чем попытки описать живой бизнес в терминах методологии, которая "успешно работает у сына маминой подруги".
#методология #проектирование #холивары