Телеграм канал «Журнал инженера-программиста»

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

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

Пара примеров для наглядности:

1) Если в компании есть несколько отделов, которые при выписке документов используют различные стили нумерации - кто-то сквозную со дня основания компании, кто-то нумерует с начала года, кто-то явно указывает год и месяц в номере как префикс. При автоматизации документооборота никто не будет бегать за каждым сотрудником и спрашивать как именно ему кажется правильно нумеровать документы. Более того, даже за руководителями всех отделов не будут бегать - одного двух введут в рабочую группу автоматизации и только на их рекомендациях будут основываться. Но даже не важно какой стиль нумерации будет выбран по итогу - важно, что теперь новые номера по всей компании будет единообразно выдавать автоматизированная система. И пусть работники других отделов ругаются на привнесенный "хаос" и "бардак", но в разрезе компании уровень энтропии явно понизился.

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

Очевидно, что хаос - это отсутствие учета, а любой учет приводит к уменьшению хаоса. Более того, как "программ без ошибок не бывает", так и не бывает идеального учета и "идеальные процессы" все время улучшаются и адаптируются к изменениям рынка, отрасли и законодательства. Так почему же все фанатично зациклены на попытках сначала написать идеальное ТЗ и лишь затем приступать к написанию мифической "идеальной системы"?

Попробовал найти ранние упоминания выражения:
Автоматизация неэффективной операции увеличивает неэффективность (с) Билл Гейтс, книга "Бизнес со скоростью мысли", 1999 год
Истоки реинжиниринга лежат во фразе, которую один из нас сформулировал еще в конце 1980-х годов: "Автоматизация бардака дает лишь автоматизированный бардак" (с) Майкл Хаммер, книга "Реинжиниринг корпорации: Манифест революции в бизнесе", 1993 год

Таким образом истоки фразы и ее активное применение были даже не в начале 90х, а в 80х или даже в 70х. А что мы знаем про ИТ прошлого века? Верно - методология водопада! Т.е. ранее действительно нужно было написать всю документацию, а потом выполнять разработку буква-к-букве как в ТЗ.

Но старый ватерфлоу не выдержал проверку временем. Подходы начали меняться сначала как раз в ИТ, а далее гибкие методики планирования и проектирования подхватили другие сферы. Даже в ультраконсервативном PMI сдались в 2017 году и включили Agile-практики в 6-ю редакцию PMBOK. А суть гибких подходов как и заключается в том, что нужно перестать пытаться делать сразу идеально, а лучше сделать упор на анализ результатов и в следующую итерацию исправлять ошибки предыдущих подходов.

Так стоит или нет автоматизировать хаос?

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

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

#методология #проектирование #холивары

Уже второй проект на работе делаю в методике "парного программирования" с Claude Code. И сразу хочу отметить, что последние модели Sonnet 5, Opus 5, Opus 5.5 и Fable 5.1 уже превосходно знают платформу 1С и им для работы не нужны никакие дополнительные MCP со справкой.

Но пусть Claude и стал "программистом 1С", но он при этом самый настоящий джуниор и требует менторского присмотра. Чесно говоря, я так много не разжёвывал материал даже когда был наставником для сотрудников-людей.

Очень важно при ревью не исправлять самостоятельно ошибки логики, оформления кода или структуры элементов на форме, а каждый раз говорить ЧТО не так и ПОЧЕМУ это не правильно. Мы с Claude каждую ошибку рассматривает, описываем ее в правилах, а далее агент проходит по ранее сделанному и вносит правки во все похожие места.

Я слышал от коллег и читал в обсуждениях, что многие жалуются на говнокод от ИИ и потому отказываются с ним работать (не важно какая модель). Но ведь и живой студент-стажер без присмотра вам в базе может такого понаписывает, прикрываясь красивыми словами про SOLID и YAGNI, что потом поседеете.

#работа #ИИ #1C