Все статьи

Авторское эссе · Максим Перфильев

Не управляйте результатом. Управляйте пространством, в котором он возникает

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

MP
Max PerfiljevFounder & CEO, AES · Архитектор автономных организаций
Read in English

Максим Перфильев · Архитектор систем

Компания может создавать себе лишнюю работу именно потому, что очень хорошо выполняет работу. Руководитель способен сохранять сломанный процесс, постоянно его спасая. А эксперт — уменьшать субъектность основателя, каждый раз выдавая следующий правильный ответ.

Это не аргумент против скорости, компетентности или помощи. Это предложение поменять объект вмешательства.

Долгое время я считал архитектурный метод самым высоким полезным уровнем управления: перестать раздавать отдельные указания и построить систему, которая регулярно производит нужный результат. Недавно, когда я наконец смог немного отойти от работы и подумать, начал видеть ещё один уровень. Я называю его пространственным методом: проектировать условия, внутри которых возможны разные траектории, не назначая заранее каждое действие и единственную окончательную архитектуру.

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

Когда быстрая разработка порождает новые запросы

В продуктовом контуре клиент предлагает идею. Мы быстро реализуем её, показываем результат — у клиента сразу возникает следующая идея. Реализуем и её. Приходит новый запрос.

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

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

Можно перестроить бэклог, замедлить разработку или добавить согласования. Здесь важное вмешательство оказалось точечнее: разделить скорость инженерной работы и скорость предъявления результата клиенту. Ввести состояния доступности: Internal, Beta и Stable. Реализованная функция больше не обязана немедленно становиться видимой снаружи.

Меняется одно граничное условие, а не весь процесс разработки. Инженеры по-прежнему могут работать быстро. Клиент получает полезные релизы. Но переход от готовой функции к новому внешнему стимулу перестаёт быть автоматическим.

Практический вопрос: какие запросы возникают из способа, которым мы показываем результаты, а не из потребности, существовавшей независимо от нашего ритма релизов?

Когда сильнейший участник скрывает ограничение

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

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

Назвать это проблемой дисциплины недостаточно. Сама система сделала невидимую компенсацию нормальным способом закрывать отсутствующую зависимость.

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

Это не принуждало директора к одному решению. Можно менять приоритеты, добавлять ресурсы, сокращать объём или отменять обязательство. Смысл — вернуть явный выбор туда, где находится реальное ограничение.

Здесь важная граница: видимый разрыв — информация, а не разрешение подвергать клиентов или коллег неконтролируемому ущербу. Критический инцидент может требовать немедленной компенсации. Но она должна быть явной, с владельцем и записью, а не выдаваться за штатную работу. Наблюдение без момента пересмотра и пути эскалации превращается в бездействие.

Вопрос не в том, нужно ли вообще помогать. Вопрос в том, сохраняет помощь знание о проблеме или стирает его.

Когда единственного правильного ответа нет

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

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

Полезным вмешательством оказалась не новая инструкция о том, как правильно быть самостоятельным. Мы убрали несколько ложно абсолютных условий. Дедлайн не священен сам по себе. Домашнее задание — инструмент, а не обязанность, определяющая успех. Эксперт и трекер могут ошибаться. Четырёхминутный питч принадлежит основателю. Нет единственного правильного шаблона презентации, который гарантирует правильную компанию.

Это не отменяет реальные ограничения. Чужие время и ресурсы не ждут бесконечно. У обязательств остаются последствия. Меняется предположение, будто кто-то снаружи уже знает единственную верную траекторию.

Когда это предположение исчезает, возникает неудобный момент: а что тогда делать? Привычный ответ — заполнить пространство новой подсказкой. В этом случае важнее было сохранить место для выбора. Раньше я называл похожее состояние управляемой неопределённостью. Теперь вижу в нём изменение условий, внутри которых может возникнуть субъектность.

Четыре разных объекта управления

Различие становится яснее, если разделить четыре вопроса.

  • Императивный: какое действие должно произойти следующим? «Сделай вот это».
  • Декларативный: какой результат нужен? «Достигни такого состояния».
  • Архитектурный: какая система должна регулярно производить результат? «Построй такую структуру переходов».
  • Пространственный: какие траектории должны оставаться допустимыми? «Задай условия, внутри которых возникают выбор и архитектуры».

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

В условной записи императивное вмешательство выбирает действие u(t). Декларативное задаёт множество целевых состояний G. Архитектурное меняет правило перехода F. Пространственное задаёт множество Ω траекторий, удовлетворяющих граничным условиям B.

Это язык для размышления, не доказательство оптимальности. Содержательный вопрос проще: какие условия делают полезные траектории естественнее, плохие — дороже или недоступнее, а осмысленный выбор сохраняют?

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

Сложность результата не требует такой же сложности вмешательства

Мне помогает аналогия с множеством Мандельброта. Начинаем с z₀ = 0, затем повторяем zₙ₊₁ = zₙ² + c. Множество составляют значения параметра c, для которых орбита остаётся ограниченной. Простое правило и граничный критерий дают сложную структуру.

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

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

Пустое пространство — состояние, а не отсутствие управления

Если возможны несколько архитектур, немедленная реализация одной закрывает часть остальных. Иногда именно это и требуется для прогресса. Иногда преждевременный выбор дороже, чем сохранение неопределённости ещё на какое-то время.

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

Слово «пока» здесь принципиально. У полезного пустого пространства есть назначение, наблюдаемые последствия и момент пересмотра решения. Это не приглашение бесконечно уклоняться от ответственности. И не техника создания неопределённости, которую другие не могут истолковать. Границы должны быть понятны тем, кого они затрагивают.

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

Как находить рынок, не назначая каждого клиента заранее

Этот взгляд меняет и поиск рынка. Императивный подход: написать ста генеральным директорам. Декларативный: получить пять клиентов. Архитектурный: построить воронку, регулярно приводящую клиентов.

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

Например: почему быстрая компания иногда сама создаёт себе больше работы? Какие процессы существуют только потому, что кто-то постоянно компенсирует неправильную работу системы?

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

Ценность может находиться в работе, которая перестаёт возникать

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

Условно: предотвращённая работа + проявленные ошибки + высвобождённое внимание. Это не финансовый расчёт. Обнаруженная ошибка не становится экономией автоматически: организации ещё нужно что-то с ней сделать. А неудачная граница способна подавить полезное экспериментирование. Наблюдать нужно оба эффекта.

Тем не менее модель меняет предмет измерения. Вместо вопроса только о количестве выполненных задач появляется вопрос: почему эти задачи вообще существуют?

Что это может значить для ИИ

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

Это гипотеза о возможном направлении, а не заявление, что AES уже автономно перепроектирует компании. Диагностика петли не даёт агенту права её менять. Вмешательства затрагивают людей и обязательства: нужны доказательства, явные полномочия, по возможности обратимые эксперименты и ответственный за решение.

Интересная цель — не только «пусть ИИ делает всё, что мы уже делаем». Ещё и «давайте обнаружим действия, которые лучше устроенной организации не пришлось бы генерировать».

Начните с одного ограниченного вопроса

Какие процессы в вашей системе прямо сейчас существуют только потому, что вы слишком быстро заполняете пространство собственными решениями?

Выберите одну обратимую ситуацию. Назовите переход, который обычно закрываете автоматически. Сделайте видимыми стоимость и последствия. Договоритесь о границе, сроке наблюдения и условиях вмешательства. Затем посмотрите, что делает система, когда вы не подставляете недостающую деталь немедленно.

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

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

ПОСТРОИТЬ С AES

Превратите архитектуру в работающую компанию.

AES связывает стратегию, задачи, организационную память, знания, агентов, людей и согласования в единой среде исполнения.