Ответ на комментарий ко вчерашнему посту: «Стек посредников — необходимость или костыль?»
Эпоха АРМ (автоматизированных рабочих мест) действительно была временем, когда разработчик работал напрямую с пользователем, и это было просто, понятно и эффективно. Но затем системы усложнились, и возник тот самый «стек»: бизнес-консалтинг → функциональный консультант → разработчик. И сегодня этот стек подаётся как нечто естественное и необходимое. Я же утверждаю, что он стал не решением, а частью проблемы — и вот почему.
Когда-то АРМ решал локальную задачу: автоматизировать рабочее место конкретного бухгалтера или кладовщика. Пользователь был способен описать свой интерфейс, потому что его деятельность была обозримой. Затем бизнес усложнился, процессы стали сквозными, данные потребовали интеграции — и прямое общение с пользователем перестало давать полную картину. Возникли посредники, которые должны были «перевести» язык бизнеса на язык системного анализа, а затем — на язык кода.
Проблема в том, что каждый такой перевод — это искажение. Бизнес-консультант интерпретирует услышанное от бизнеса через свои методички и шаблоны, функциональный консультант — через свои нотации, разработчик — через свои технические ограничения. На выходе мы получаем систему, которая является не точным отражением потребности бизнеса, а компромиссом между интерпретациями трёх посредников. Знаменитый эффект «испорченного телефона» здесь не баг, а конституирующее свойство.
Стек создаёт иллюзию надёжности: кажется, что чем больше профессионалов вовлечено, тем точнее будет результат. На деле он размывает ответственность. Бизнес говорит: «Мы заплатили консультантам, они должны были всё продумать». Консультанты говорят: «Мы описали верхнеуровневые требования, а детализацию должны делать функциональщики». Функциональщики говорят: «Мы сделали постановку, а разработчики почему-то не так реализовали». И никто не отвечает за то, что итоговый продукт неудобен конечному пользователю.
Более того, стек удлиняет цикл обратной связи. Пока бизнес через цепочку посредников поймёт, что на экране не та кнопка, и пока это исправление пройдёт обратно по цепочке — проходят недели и месяцы, бюджет тает, доверие разрушается.
Главное недоразумение, которое я вижу в критике «новой архитектуры» — это мнение, что мы предлагаем выкинуть консультантов, аналитиков и архитекторов, оставив бизнес один на один с программистом. Нет. Я предлагаю иное: переместить их усилие туда, где оно даёт максимальную ценность, и освободить от роли переводчиков с неизбежными искажениями.
В книге «Диалоги о цифре» стратегическая сессия — это не отказ от экспертов, а их интенсивная работа с бизнесом на этапе формирования онтологии и целевой модели управления. Консультант здесь не «собирает требования», чтобы потом унести их куда-то, — он фасилитирует рождение ясного видения у самого бизнеса. Он помогает бизнесу вычленить роли в сквозных процессах и описать эти процессы в строгой нотации. Это и есть та самая недостающая «постановка задачи», но сделанная не за бизнес, а вместе с бизнесом и воплощённая в визуальной, однозначной форме — в макетах интерфейсов.
Таким образом, профессионалы никуда не исчезают. Просто вместо того, чтобы быть передаточным звеном, которое неизбежно искажает сигнал, они становятся катализаторами, которые помогают бизнесу самостоятельно сформулировать своё ТЗ — а затем разработчики реализуют его без додумываний. Ответственность ложится на того, кто будет пользоваться системой, — и это, на мой взгляд, единственно правильное место.
Эпоха АРМ была прекрасна своей прямотой, но она работала в мире локальных задач. Современная цифровая платформа — это не сумма разрозненных АРМов, а целостная экосистема, подчинённая единой модели управления. Собрать такую экосистему из кусочков, описанных разными посредниками, невозможно — получится лоскутное одеяло.
