Есть типовой зазор: клиенту нужно сто локальных доработок, интеграция и доведение до прибыли, а продуктовая команда выпускает фичи для сотен клиентов. Если этот зазор не назвать и как-то не обустроить организационно, компания будет считать, что у неё “продуктовая масштабируемая экономика”, но будет жить по факту в немасштабируемом консалтинге.
Вот ещё один эксперимент, который я провёл по облегчению создания SPF (second principles framework): у меня в чате были запрошены подробности на тему, что там за такие forward-deployed engineers (“сначала развёрнутые у клиента инженеры, затем продукты”), Telegram: View @ailev_blog_discussion. Я кратенько ответил – но понял, что надо писать пост. Собственно, вот этот самый пост, который вы читаете. Но я думал написать его сам, а потом понял, что это хороший способ провести ещё один эксперимент с SPF, и считаю его удачным.
Тут меня меньше интересовала FDE как модная роль, на которую все себя примеряют (ибо спрос на эту роль уже чуть ли не больше, чем на product managers), а способ получать начальный SPF для предметной области в три промпта.
Как я и говорил, я очень долго возился с фундаментальными “первыми принципами” в FPF (через неделю проекту FPF исполнится год!), но зато теперь можно ожидать резкого ускорения входа в разные предметные области. Это верно и для людей (фундаментальное образование и бесконечное развитие интеллекта ещё никому не вредили, ибо прикладные предметные области приходят и уходят, а это – остаётся), и для не совсем людей (ибо из всезнающего AI-агента надо вытянуть целенаправленную работу по SoTA, а не попсовый ответ “чтобы понравиться этой мокрой нейросетке”).
Вход в разные предметные области – это SPFs, second principles frameworks. Сам FPF – это александеровский/alexandrian язык паттернов (Pattern language - Wikipedia) трансдисциплин, а SPF – язык для паттернов прикладных дисциплин. SPF соответствует метаУ-модели из наших руководств, но если метаУ-модель – это главным образом онтология, то докрутка до паттерна обычно означает семантику (онтологию+лексику) с выходом в прагматику: каким образом паттерн как описание метода решения каких-то проблем/problems помогает в проблемной ситуации (problem frame) проекта (context). Главный вопрос смещается на “что же делать?!” с вопроса “какие у нас тут объекты внимания” (хотя онтологический вопрос, конечно, тоже решается, как же без него!). Чтобы с этим всем разобраться, как раз и нужен FPF.
Я уже веду эксперименты по FPF, первый сделал на танцах (lytdybr: ailev — ЖЖ). Получение SPF сводится к тому, чтобы:
- задать богатый контекст (обозначить предметную область), то есть поговорить и наработать какой-то объём текстов, накидать каких-то вопросов, ибо “определения – гробик для уснувшей мысли”, так предметные области задать нельзя.
- подсунуть FPF (подложить как файл в проект: в разных AI-системах подложить как файл в проект делается по-разному, тут все кричат “в контекст не лезет”, но его и не надо грузить в контекст, ЭТО ОШИБКА. Да, капсом, ибо не обращают внимания, ОБРАТИТЕ ВНИМАНИЕ. Нужен файл в проекте/папке у AI-агента для работы с ним через Python и RAG, а не файл, который будет прочитан агенту в контекст “для мышления”. Если не понимаете, о чём речь, спросите знающих людей. Это сегодня уровень “не очень продвинутый пользователь компьютера”, “знаниевые работники” уже должны к сегодняшнему дню в таком разобраться).
- дать промпт на создание SPF. Можно даже так его не называть, но после этого промпта у вас есть набор паттернов (и его дальше можно улучшать).
- использовать этот SPF (например, делать на его основе TPF для вашей организации, то есть идти на ещё один уровень конкретизации, third principles framework, работа с метаС-моделью, “корпоративными стандартами, чеклистами, кастомизированными workflow”. Или просто читать-изучать, ибо это ж “справочник-учебник”, набор типовых паттернов действия в проблемной ситуации).
Вот полный текст чата: https://chatgpt.com/share/6a198a83-1b28-83eb-a27e-6116a32b2417 (чат в ChatGPT с моделью GPT-5.5 Pro).
Итак, надо разговорить. Я дал для этого три промпта:
- Первый задаёт тему: “А что это за новая роль forward-deployed engineer? Чем отличается от остальных ролей? Это очень похоже на webmaster, роль “всё на свете про вебсайт” продержалась буквально год-другой, распавшись на разные другие роли (дизайнер, редактор, контент-менеджер, программист фронт-энда, программист бэкенда и т.д.) – я прав в этом наблюдении? Как это конкурирует с другой такой же всеохватной ролью product manager (или product owner)?”
- Второй добавляет разворот в общие принципы и методы работы и подчёркивает слово “паттерн” с разворотом в генерализацию: “Это вообще-то очень интересный зазор между “клиенту нужно 100 оптимизаций для 4 наших продуктов и непонятная никому интеграция, которую мы никогда не делали, иначе у этого клиента не будет прибыли” и “наши разработчики выдали по 3 новые фичи по каждому из четырёх продуктов, они пойдут сотням клиентов”. Вероятно, этот зазор много ещё в каких местах. Похоже, что многие open source компании работают как раз на этом зазоре: у них есть open source продукт, а зарабатывают они на FDE. А ещё есть примеры этого паттерна как бизнес-паттерна, как организационного паттерна? А если выйти за пределы software engineering?”.
- Третий промпт просит сгенерировать SPF (но не называет его так), при этом я подгрузил в чат файл FPF (только на этом ходе диалога): “У тебя в файле FPF. Ты описал некую проблему, когда масштабируемая технология сталкивается с немасштабируемой деятельностью – и набор паттернов из какого-то языка паттернов (alexandrian pattern language), которые эту проблему решают: как выстроить организацию, какие сделать роли, чтобы конфликт разошёлся по разным исполнителям ролей вместо того, чтобы стать конфликтом интересов в одной роли и т.д. Напиши мне в файл это как небольшой язык паттернов “организация кастомизации без падения масштабирования”, ориентируясь на E.8 как шаблон формата публикации паттернов для этого языка. Можешь использовать и другие паттерны FPF, там много полезного для выражения подобных проблем. Паттерны пиши на русском языке (хотя в E.8 указано, что они должны писаться на английском). Пиши качественно, в файле у тебя нет ограничений по его итоговому размеру всех паттернов. Возьми времени столько, сколько надо”.
Результирующий файл (86K знаков, генерация его шла 19 минут) содержит язык паттернов “PL.CUST — Организация кастомизации без падения масштабирования”, в нём девять паттернов. Посмотрите эту выдачу вот тут: PL.CUST-organization-of-customization-without-losing-scale.md — Яндекс Диск (я специально ничего там не трогал, чтобы пример был чистым. Конечно, я бы это сильно доработал! Скажем, там слишком много английского языка, несмотря на предложение писать по-русски, или перевод value как “ценность”, а не “полезность” – такая замена сильно бы подняла полезность паттерна, pun intended. Или “якобы русский” вроде “продуктализации”. Есть идеи и по тому, как это улучшить не только по линии редактирования плохой речи, но и по линии усиления инженерно-менеджерского содержания. И это тоже можно делать не ручным редактированием. На это тоже есть методы работы, значит, есть паттерны в FPF, значит, это может делать AI-агент. Но пока – “чистое сырьё, руками не трогал”).
Вот список этих паттернов (даже не чищу этот markdown, должно быть и так понятно, тут тоже ничего не трогал):
| Паттерн | Первый вопрос | Главный выход |
|---|---|---|
PL.CUST.0 — Зазор локальной ценности и масштабируемой возможности |
Это единичная кастомизация или симптом незрелого продукта? | Две петли: локальная доставка и продуктализация |
PL.CUST.1 — Граница контекстов кастомизации |
Где кончается клиентская реальность и начинается продуктовая абстракция? | Контекстная карта и Bridge-записи |
PL.CUST.2 — Ролевое расщепление конфликтующих интересов |
Кто отвечает за клиента сейчас, а кто за масштабируемость завтра? | Разделение ролей и decision rights |
PL.CUST.3 — Полевой пробный контур |
Как дать клиенту value без создания вечной кастомной ветки? | Time-boxed field probe + evidence trail |
PL.CUST.4 — Реестр кастомизационных дельт |
Что именно изменилось ради клиента и куда это должно попасть? | Delta ledger + reuse ladder |
PL.CUST.5 — Ворота продуктализации |
Когда локальный паттерн достоин стать продуктовой primitive? | Productization gate decision |
PL.CUST.6 — Пакет внедрения вместо скрытой фичи |
Когда надо стандартизировать внедрение, а не core product? | Deployment pack / service productization |
PL.CUST.7 — Экономический предохранитель кастомизации |
Как не продать консалтинг как software margin? | Cost-to-serve and margin sentinel |
PL.CUST.8 — Outcome envelope за пределами software |
Когда можно продавать результат, а не продукт или часы? | Outcome contract envelope |
Интересные вопросы, да? Это вам не про онтологию с семиотикой читать – интерес возникает сразу.
Приведу целиком нулевой паттерн из этого списка, тоже ничего в нём не трогая, а за остальными восемью паттернами идите в файл, ссылку на который я привёл. Смотреть в этом фрагменте надо не на отвратительный Runglish, хотя именно он сразу бросается в глаза и именно в нём разбираются все русскоговорящие (поэтому критиковать текст вызовется даже пятиклассник, ничего не соображающий в предмете этого паттерна). Важно другое:
- агент сразу вынул problem frame, три типовых дефекта, два рабочих цикла (обозвал их “петлями”, но это неважно) и чётко опёрся на FPF. То есть получился не бытовой пересказ темы FDE, а начальный язык проблемных ситуаций, которые рассматриваются последующими паттернами. Это будет интересовать онтологов, методологов.
- инженеров-менеджеров может заинтересовать другое: ответ на вопрос из моего чата – что это за такая ситуация, в которой нужен FDE, что там реально делать, на какую SoTA опираться и что вообще надо предусмотреть. Паттерн как раз излагает кусочек описания осмысленного поведения для предметной области, занимающейся проблемой беготни за двумя бизнес-зайцами: желанием угодить каждому клиенту (ибо без этого никаких денег, никаких продаж) и желанием иметь продукт формата one-size-fits-all (“цвет автомобиля может быть любым, если он чёрный”). И ещё это пример разведения конфликта интересов по разным ролям (смотрите там раздел “последствия” применения паттерна).
И да, мне не стыдно приводить тут “стену текста из AI-агента”: за этим – целый год моей работы full time, так что это просто демонстрация того, что сегодня возможно:
PL.CUST.0 - Зазор локальной ценности и масштабируемой возможности
Type: Architectural pattern
Status: Draft
Normativity: Candidate normative for this pattern language
Plain name: Клиентский value-gap как управляемая архитектурная граница
PL.CUST.0:1 - Problem frame — Рамка проблемы
Используйте этот паттерн, когда продуктовая организация видит устойчивый разрыв между reusable product capabilities и тем, что конкретный клиент должен получить в своём операционном контуре. Продукт уже существует, но ценность не возникает без локальных интеграций, process redesign, обучения пользователей, data cleanup, compliance tuning, нестандартных ролей и ручного перехода через клиентские границы.
Первый полезный ход: перестать спрашивать «это продукт или сервис?» и начать вести две разные петли. Первая петля доставляет локальную ценность клиенту. Вторая извлекает из локальной работы повторяемые primitives. Одна петля без другой либо превращает фирму в консалтинг, либо оставляет продукт «демонстрационно полезным» и production-бесполезным.
Not this pattern when: клиент просто использует стандартную конфигурацию, проблема уже полностью покрыта существующим deployment pack, или речь идёт о единичном support incident без reusable signal. Тогда достаточно обычной работы по U.Work, support, incident, acceptance или release governance.
PL.CUST.0:2 - Problem — Проблема
Когда зазор не назван, организация создаёт один из трёх дефектов.
Первый дефект — героическая универсальная роль. Один человек становится одновременно PM, engineer, consultant, sales engineer, customer success, domain analyst и support escalation. Он удерживает конфликт в голове, но организация не видит, какой конфликт был разрешён, какой отложен, а какой превращён в debt.
Второй дефект — backlog laundering. Локальная просьба клиента попадает в roadmap как будто она уже является product primitive. Core-команда строит фичу, которая решает один контекст, но ухудшает архитектуру для многих.
Третий дефект — consulting disguised as product. Компания продаёт software economics, а доставляет bespoke service economics. Revenue выглядит как scalable ARR, но margin, support tail и roadmap drag ведут себя как professional services.
PL.CUST.0:3 - Forces — Силы
| Force | Tension |
|---|---|
| Локальная ценность vs reusable architecture | Клиенту нужен результат в его контуре сейчас; продукту нужна обобщаемая primitive для многих. |
| Скорость внедрения vs доказательность | Field-команда хочет быстро исправить; product-команда нуждается в evidence, scope и repeatability. |
| Sales promise vs delivery reality | Коммерческая команда обещает outcome; delivery видит missing capabilities and hidden work. |
| Margin vs learning | Глубокая кастомизация дорогая, но именно она даёт сигналы, из которых рождается настоящий продукт. |
| Generalist usefulness vs role conflict | FDE-like generalist полезен на фронтире, но вреден как постоянное место хранения всех противоречий. |
PL.CUST.0:4 - Solution — Решение
Организуйте зазор как двухпетлевую архитектуру.
Петля A — Local Delivery Loop. Её цель — довести конкретного клиента до измеримого local outcome. Эта петля работает в CustomerRealityContext и JointDeploymentContext, создаёт U.Work, собирает evidence, фиксирует integration constraints, обучает пользователей и проверяет acceptance.
Петля B — Productization Loop. Её цель — не обслужить клиента, а извлечь reusable pattern. Эта петля работает в ProviderProductContext, DeploymentPatternContext и, если нужно, PartnerEcosystemContext. Она классифицирует field deltas, выбирает productization route, создаёт product primitive, deployment pack, partner playbook или explicit rejection.
Минимальная форма записи:
LocalValueCase :=
CustomizationDelta :=
ProductizationRoute := <reject local-only="local-only" paid-custom="paid-custom" deployment-pack="deployment-pack" product-primitive="product-primitive" partner-handoff="partner-handoff" outcome-service="outcome-service">
Никакая local delta не должна попадать напрямую в core roadmap без route decision. Никакая local delivery не должна оставаться «просто сделано» без evidence record. Никакая field role не должна иметь одновременно окончательное право обещать клиенту, менять продуктовый roadmap и скрывать economics.
PL.CUST.0:5 - Archetypal Grounding — Архетипическое заземление
System archetype — enterprise AI deployment. Поставщик имеет platform product, но банк получает value только после интеграции с IAM, data lake, approval workflow, audit logging и человеческими review roles. Field team доставляет working deployment. Product team забирает повторяющиеся элементы: connector pattern, access-control primitive, eval harness и audit view. Всё, что не повторяется, остаётся paid local work.
Episteme archetype — клиническая практика. Исследовательская рекомендация полезна только после адаптации к больничному workflow, регуляторным требованиям, оборудованию и навыкам персонала. Локальная implementation guideline не становится автоматически новой научной теорией; повторяющиеся adaptation patterns могут стать clinical pathway template, training pack или evidence gap for research.
PL.CUST.0:6 - Bias-Annotation — Аннотация смещений
Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal across software, industrial systems, healthcare, research translation, open source commercialization, and public services.
Паттерн намеренно bias-ит организацию против «героического универсала» и против неявного консалтинга. Этот bias полезен, но может привести к чрезмерной бюрократизации раннего discovery. Митигация: первые записи должны быть lightweight; более тяжёлые gates включаются только при commitment, repeated pattern, customer promise, compliance load или core-roadmap pressure.
PL.CUST.0:7 - Conformance Checklist — Чеклист соответствия
| ID | Requirement | Purpose |
|---|---|---|
| CC-CUST0-1 | A conforming use SHALL name at least one LocalValueCase and at least one CustomizationDelta; generic “customer needs” wording is insufficient. |
Prevents vague field anecdotes from driving roadmap. |
| CC-CUST0-2 | A conforming use SHALL classify each local delta into one ProductizationRoute. |
Ensures local work is not silently converted into product debt. |
| CC-CUST0-3 | A conforming use SHALL keep local delivery evidence separate from productization decision evidence. | Prevents “it worked once” from becoming “ship it to all customers”. |
| CC-CUST0-4 | A conforming use SHALL declare which role owns local outcome, which role owns product primitive decision, and which role owns delivery economics. | Keeps conflict from residing in one role. |
| CC-CUST0-5 | A conforming use SHALL state stop conditions for both loops: local delivery stop and productization stop. | Prevents endless field engagement and endless abstraction. |
PL.CUST.0:8 - Common Anti-Patterns and How to Avoid Them — Антипаттерны
Hero FDE as architecture. Симптом: один сильный инженер «всё понимает» и всё решает. Repair: сделать field role источником evidence and integration work, но отделить product gate and economics gate.
Roadmap laundering. Симптом: customer escalation превращается в product commitment без evidence of repeatability. Repair: провести delta через PL.CUST.4 и PL.CUST.5.
Consulting hidden in ARR. Симптом: local work не priced, не scoped, не ограничена, но поддерживается как будто входит в software subscription. Repair: применить PL.CUST.7.
Demo success as production evidence. Симптом: pilot demo считается proof of value. Repair: требовать production work evidence, acceptance and adoption measures.
PL.CUST.0:9 - Consequences — Последствия
Паттерн делает field work легитимной частью продуктовой системы, но не позволяет ей стать скрытым центром компании. Он даёт язык для открытого trade-off: какую часть кастомизации продать как local work, какую инвестировать как product learning, какую запретить, какую передать партнёрам.
Цена — больше явных границ. Sales, product, field and finance теряют удобную возможность говорить одним словом «delivery». Но именно эта потеря удобства предотвращает смешение promise, capability, method and work.
PL.CUST.0:10 - Rationale — Обоснование
Зазор возникает не потому, что продукт «плохой», а потому что real value is situated. Масштабируемая technology обычно содержит capability, но client profit возникает после того, как capability связана с process, data, people, policy and evidence.
FPF already separates role, capability, method, work, promise content, scope and evidence. Этот язык применяет эти различения к business architecture кастомизации. Главная мысль: локальная адаптация не исчезает; её нужно сделать явной, оплачиваемой, измеримой и переводимой в reusable assets.
PL.CUST.0:11 - SoTA-Echoing — Связь с современной практикой
| SoTA practice | Alignment with this pattern | Adoption status |
|---|---|---|
| Forward-deployed engineering / field engineering. Palantir and current AI vendors describe field engineers as people who turn platform capabilities into production systems inside customer contexts. | The pattern adopts field engineering as a local value loop, but rejects making it the hidden owner of product roadmap and economics. | Adopt and constrain. Field work is legitimate, but must produce deltas and evidence. |
| Team Topologies. Stream-aligned, platform, enabling and complicated-subsystem teams separate value flow from platform and specialist load. | The pattern adapts this split: field cells resemble enabling/collaboration modes, while product primitives belong to platform/core ownership. | Adapt. Do not import the exact four-team taxonomy as universal. |
| Service productization. Recent service-productization literature frames productization as transforming variable, ad-hoc service into well-defined repeatable service products. | The pattern treats deployment packs and productization gates as routes out of ad-hoc field work. | Adopt. Use productization only after evidence, not as rebranding. |
| Servitization and outcome-based contracts. Manufacturing firms increasingly wrap products in services or outcomes. | The pattern accepts outcome/value framing only when evidence, control and economics are explicit. | Adopt with guardrails. Outcome contracts require PL.CUST.8. |
PL.CUST.0:12 - Relations — Связи
Builds on FPF: A.1.1 U.BoundedContext, A.2.1 U.RoleAssignment, A.2.2 U.Capability, A.2.3 U.PromiseContent, A.15 Role–Method–Work Alignment, A.15.1 U.Work, F.9 Bridges, C.25 Q-Bundle, G.5 selected-set discipline.
Coordinates with this language: PL.CUST.1 for contexts, PL.CUST.2 for roles, PL.CUST.3 for field probes, PL.CUST.4 for delta ledger, PL.CUST.5 for productization, PL.CUST.7 for economics, PL.CUST.8 for non-software outcome patterns.
PL.CUST.0:End
Меня, как целый год возившегося с FPF, тут больше всего удовлетворяет PL.CUST.0:12 – и там “Builds on FPF”, перечисление паттернов, на которые опирается этот паттерн. Машинка работает примерно так, как и задумано, магия по третьему закону Кларка в действии.
