Как работают вызовы API внутри сервера.

Когда рассказывают про интеграции и про API, обычно сервер рисуют как черный ящик. Вот в него входят HTTP-запросы, дальше говорим про URI, параметры, схемы данных.

Но для новичков иногда непонятно, чем отличаются разные технологии. Однажды на тренинге по интеграциям мне задали вопрос: про Кафку мы поняли, её нужно ставить как дополнительное ПО. А вот gRPC — он тоже ставится на отдельный сервер?..

Тут, кажется, стоит вернуться к основам, попробовал нарисовать.

Клиент обращается к серверу (1). Сервер — это компьютер, у него есть сетевая карта (или даже несколько), у карты есть IP-адрес. На него из сети приходит запрос. В запросе указан порт.

Операционная система смотрит по своей таблице портов, в какой из запущенных сервисов отправить этот запрос (2). На одном порту отвечает только один сервис. Всего TCP-портов может быть 65535, то есть один сервер может отвечать по-разному на разных портах. Связь порта и сервиса называется биндинг, приложение при запуске пытается этот биндинг создать и дальше "слушать" порт, то есть ждать из него сообщений.

Стандартные порты — HTTP:80, HTTPS:443. То есть, всё, что приходит на 443, будет отправлено в HTTP-сервер, если он запущен. HTTP-сервер может быть встроен в приложение бекэнда, а может быть отдельным сервисом. Как правило, из соображений безопасности и производительности, в промышленном контуре HTTP-сервер отдельный. HTTP-сервер устанавливает зашифрованное соединение, проверяет корректность запроса и доступы.

Дальше он пытается выполнить запрос. Есть три основных варианта:

— просто отдать файл, лежащий на диске (3.1). Это называется "статика" — обычно это картинки или другие медиа, документы, HTML-страницы, стили, JS-скрипты. Статика отдается очень быстро (зависит от размера, конечно). Структура URL при этом не должна повторять структуру реальных папок на диске — мэппинг настраивается на HTTP-сервере.

— выполнить скрипт, лежащий на диске (3.2). Эта технология называется CGI. Веб-сервер запускает скрипт, и отдает клиенту результат выполнения. Скрипт при этом может обращаться к БД или ещё что-то делать — это обычная программа. Так работают многие PHP-фреймворки. У HTTP-сервера должен быть установлен мод для запуска скриптов на конкретном языке (Perl, PHP и т.д.). На каждый запрос запускается свой отдельный экземпляр скрипта в отельном потоке.

— передать запрос запущенному в памяти сервису (3.3) — приложению бэкенда (в UNIX-подобных системах он ждет запросов тоже по TCP, на каком-нибудь порту. Поэтому легко разнести HTTP-сервер и сервер приложений на разные машины, если понадобится). В сервере приложений в ответ на входящий запрос запускается функция роутинга всех входящих запросов, которая парсит заголовок запроса и вызывает соответствующую функцию (метод) у себя внутри (4). Эта функция уже делает всё, что нужно, чтобы обработать запрос и выдать ответ: обращается к БД (5) или к внешним сервисам (6) — тогда ваш сервер приложений работает частично как шлюз API.

Всё это может работать на одной машине, а когда нагрузка растет — мы разносим их по разным: HTTP-сервер, сервер приложений, СУБД.

Теперь, где работает GraphQL? GraphQL — это замена вашему фреймворку для обработки вызовов на сервере приложений. Есть три варианта: встроить в ваш фреймворк — тогда ваш сервер приложений по одному из эндпоинтов будет отвечать как GraphQL; поставить отдельно в параллель вашему серверу приложений; поставить перед ним, как API-шлюз.

Где gRPC? gRPC работает вместо вашего фреймворка, занимающегося парсингом входящих сообщений. HTTP-сервер, если он есть, будет проксировать TCP-трафик на ваш сервер, где его ловит gRPC и вызывает нужные процедуры.

Вы, наверное, уже читали внутреннюю памятку для сотрудников Shopify про ИИ, которая сначала утекла в сеть, а потом уже и CEO Тоби Лютке у себя в X опубликовал.

Там 6 пунктов:

1. Использование ИИ теперь — фундаментальное ожидание от каждого сотрудника Shopify.

2. ИИ обязательно использовать на стадии прототипирования GSD. Get Shit Done — это у них такая методология и инструмент ведения проектов.

3. Вопросы про использование ИИ включаются в оценку перформанса и взаимного оценивания. В том числе — кто кому помогал осваивать ИИ.

4. Поддерживается максимальный обмен практиками использования ИИ: у кого что получилось, у кого что не получилось. В цикле разработки продуктов выделяется время на эксперименты с ИИ. Результаты команд озвучиваются на ежемесячных общих встречах.

5. Прежде чем запрашивать новые ресурсы или людей, команды обязаны показать, почему они не могут сделать это при помощи ИИ. Как бы эта зона ответственности выглядела, если бы автономный ИИ-агент уже был членом команды?

6. Это относится к каждому сотруднику, включая CEO и высшее руководство.


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

А ещё — хороший пример управленческого воздействия. Всего-то 6 пунктов, а принципы заданы основополагающие. Я похожие принципы пытался внедрить в одном фонде, когда был CTO — но не для ИИ, а для прототипирования продуктов своими силами, без привлечения разработчиков и сбора данных — основатель фонда очень хотел цифровую трансформацию. Но я тогда не дожал, а вот это выглядит как решение (но исходить должно не от CTO, конечно, а от CEO). Предполагаю, кстати, что скоро появится хайп на тему "ИИ-трансформации", какую-нибудь должность "Директор по ИИ" придумают и множество программ на эту тему от бизнес-школ.

А как у вас? Собираетесь вводить в штатное расписание ИИ-агентов?

Увидел сегодня табличку для проектирования управленческих решений и их мониторинга. От управленцев, которые, в общем, довольно далеки от ИТ. Но пропагандируют решения на основе данных.

И они, конечно, не знают таких методик, как Impact mapping, или её развития — Карты гипотез от Александра Бындю, или Business Decision Records, или какого-нибудь Business Model Canvas/Value Proposition Canvas, или например Digital Policy Model Canvas, если речь идёт о госполитике в некоммерческих областях типа культуры или образования.

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

1. Проблема (формулируется как конфликт: с одной стороны это, но с другой стороны вот то, и одно другому противоречит)
2. Данные, подтверждающие наличие проблемы: количественные (мы что-то измерили, это статистически значимо и репрезентативно) и качественные (конкретные вопиющие кейсы)
3. Причины или гипотезы об источниках проблемы
4. Данные, нужные для подтверждения или опровержения гипотез о причинах.
5. Источники данных (для каждой причины)

Это аналитическая часть. Теперь решенческая:

6. Меры по преодолению/устранению причин.
7. Риски
9. Ресурсы для осуществления мер:
— имеющиеся
— необходимые
10. Показатели для оценки:
— процесса (это про меры — что реально делается?)
— результатов (это про проблему — происходят ли улучшение?)
— эффективности (это про соотношение результатов и ресурсов — сколько нам стоит улучшение на N пунктов?)
— эффектов (что ещё улучшается/изменяется в результате? Улучшается ли общая картина, что-то, что выше проблемы? Не выходят ли из под контроля риски? Эффекты могут быть отложенными по времени)

Вот такие две простые таблицы, но, кажется, очень полезные на ранних этапах, для оценки инициатив. Есть ли реально проблема? Откуда знаем? Как будем решать? Как узнаем, что решили?

Дальше добавляем время: сроки реализации мер и периодичность измерений — и получаем готовый план!

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

Канал уверенно преодолел отметку 9k подписчиков, и это очень круто!

Кто-нибудь другой на моем месте уже создал бы курс по раскрутке телеграм-канала без бюджета (я дважды заплатил за премиум-аккаунт, это пока всё, что я потратил на развитие канала. Ну ещё ЭДО для обмена документами с рекламодателями).

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

— Рассказывать о чем-то новом, про что мало кто говорит. Серьёзно, я вас сильно уважаю, дорогие подписчики, чтобы тупо постить что-нибудь вроде "Основные методы HTTP и какие из них идемпотентны". А если я вдруг про это и напишу, то с какого-нибудь редкого угла рассмотрения — например, должен ли идемпотентный метод всегда возвращать один и тот же результат при одинаковых значениях параметров. Хотя и это слишком просто. Вот связь идемпотентности с функциональным программированием, абстрактными алгебрами и геометрическими проекциями — это уже интересно!

— Давать не просто интересную информацию, но и полезную, применимую сразу.

— Рассказывать максимально просто (но не проще!)

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

Но что мы всё обо мне. У меня же есть традиция (хорошо, когда есть традиции!) — на круглых числах рассказывать о своих подписчиках и их каналах. Вот в прошлый раз у нас были такие каналы:

Аналитик маминой подруги — канал Валентина Заботина. Что беспокоит всех — зарплаты, собеседования, прохождение испытательного срока, инструменты, ну и просто реальная жизнь системного аналитика.

Быть продактом (быть, а не казаться!) — от Антона Куликова, действующего CPO — про научный подход, рациональность и продуктивные конфликты. И про работу CPO, конечно.

V{IT}A ZAEBYMBA | Путь корпората (извините, из названия слова не выкинешь) — канал офигенно развивается, Вита, как ты это делаешь, поделись инсайтами! Вовлеченность подписчиков нереальная. Очень авторский контент про системный анализ и про жизнь ИТшника в большой компании.

IT АНАЛитика (ещё раз извините) Виктора Вильда — много разборов важных для аналитика понятий на простом языке.

https://hottg.com/systemny_analiz_prosto — к сожалению, на паузе. Был разбор задачек с собеседований.

https://hottg.com/itsysdes_events — Cобытия для аналитиков и проектировщиков ИТ-систем, новости, статьи.

https://hottg.com/sysanaly — мемы и наблюдения за жизнью системного аналитика. С интересом прочел отзыв на тренинг, который я вел, а автор канала посетил :)

Eye of the Tigress \🐯/ Системный анализ — живой авторский канал, вдумчивые посты.

Продукт и рост | Яна Доценко — канал от настоящего продакта с настоящими классными приемами и как продакту работать и искать работу в Европе.

https://hottg.com/mialinist — Заметки об управлении школой @systems_education и исследовательские статьи о финансах, бизнесе и анализе. Самый внутренний внутрячок про школу системного анализа!

Анка Аналитик — длинные посты про системный и бизнес-анализ. Автономный транспорт! Биотех! Крутые предметные области.

Самореализация и публичность IT-специалистов — канал Smart Effect Натальи Семеновой — про подготовку к выступлениям на конференциях.

Финансовый сыч — для разнообразия, канал не про системный анализ, а про финансовый. Автор делится своим личным опытом и ценными советами по управлению финансами и личными инвестициями.

Вот такие у нас классные каналы! Все, как на подбор. Почти готовая папка получилась.
Ну а в комментариях к этому посту можете писать о своих каналах! Даешь переопыление подписчиками!

Открытие дня — оказывается, провал коллективного принятия проектировочных решений, то, что называется "Design by Committee" — имеет строгое математическое доказательство и называется "Теорема Эрроу о диктатуре".

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

Универсальность означает, что итоговое решение существует для любых частных выборов участников.

Независимость от внешних альтернатив — при добавлении ещё одной опции в итоговом решении не происходит перестановки приоритетов уже имеющихся.

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

Отсутствие диктатора — ни у кого из голосующих нет права последовательно продавливать своё решение, игнорируя остальные голоса.

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

Теорема работает, начиная с двух голосующих и трёх вариантов выбора. Под выбором имеется в виду упорядочивание без количественной оценки — как приоритеты в бэклоге и карточная сортировка.

Эта теорема связана с парадоксом Кондорсе — когда при голосовании не удается прийти к единому мнению, и обсуждение зацикливается (математически становится транзитивным, как в игре "камень-ножницы-бумага" — всегда есть вариант лучше и вариант хуже). Возможно, вас это успокоит: бесконечные согласования с несколькими стейкхолдерами — это не баг, а фича. Научно доказано.

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

Хуже того: недавно появилась статья https://arxiv.org/abs/2504.06589 (пока в виде препринта), в которой авторы показывают, что задача, сформулированная в теореме Эрроу, эквивалентна проблеме остановки, и, соответственно, не может быть вычислена. Это доказал ещё Гёдель. Точнее, три первых свойства являются невычислимыми без диктатора. То есть, мы принципиально можем их рассчитать только при наличии единственного лица, принимающего итоговое решение.

В общем, у нас теперь есть научное обоснование необходимости единственного человека, управляющего развитием системы (системного аналитика, архитектора) или продукта (продакта).

Про что ещё хотел вам рассказать: мероприятие, к проектированию которого я лично приложил руку — это весенняя конференция Flow — Flow Spring 2025.

Она будет 26 апреля, в субботу, бесплатно и только онлайн. Так сказать, как разогрев к осенней, которая уже оффлайн и на пару дней.

Вместе с ПК запланировали два трека: смыслы и фейлы.

• Смыслы — о глубоком понимании профессии и про мотивацию.

• Фейлы — честно о провалах. О [не]принятых решениях и их последствиях, о забытых требованиях, о поиске ответов без готовых рецептов. Ошибки, на которых можно научиться.

Набор спикеров шикарный:
Бураков, Бесков, Лобзов, Чернухин, Сатин, Максимов, Безуглый — просто все, кого в любом случае интересно послушать. (Я сам пока коплю силы на осень).

Александра Клименко про коммуникации — у неё был один из самых посещаемых докладов на прошлом Flow с интерактивом, вот тут про него писал.

Полная программа тут

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

Регистрируемся тут

Вот эту схему вам ещё, кажется, не показывал. Все области знаний по архитектуре! От сообщества DNA, это какие-то польские ребята, случайно наткнулся.

Люблю обобщающие схемы! Вы уже, наверное, поняли.

Про разбивку, конечно, можно спорить, но давайте посмотрим, что мы тут видим.

Во-первых, 4 области:
* Системы
* Решение
* Инфраструктура
* Приложение

Давайте начнем с решения. Тут у нас 4 раздела:
* Область проблемы
* Визуализация
* Принятие решений
* Область решения

(Опять проблемы с русским языком — не отличаем solution от decision)

Что тут интересно: область проблемы — это сразу DDD, выделение доменов и поддоменов (ядро бизнеса, поддерживающие, общие), и Event Storming. Всё, нету никаких требований и функций, есть только домены. В принципе, для архитектора этого может быть и достаточно — ему же нужно разбить систему на части, так чтобы они не были сцеплены и изменения были изолированы, и на этом всё.

Хороший блок про принятие решений. OODA, надо же. Это нужно подробнее разобрать, надо бы пост отдельный сделать.

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

В инфраструктуре — сплошные облака и контейнеры, но это наверное и правильно. И это то, что обычно наиболее далеко от аналитика. Так что если думаете про карьеру архитектора — нужно с этим разбираться. Там много всего интересного. Ну и инфраструктура как код.

Область приложений — это про то, о чем обычно все книги, статьи и курсы по архитектуре. Архитектура отдельного приложения: гексагональная, микроядерная, трёхзвенная, модульная, каналы-и-фильтры. Как можно извратиться, пока всё это ещё считаетс одним приложением. Проверьте себя, знаете ли вы все эти баззворды :)

Область систем — это в основном про распределенные системы. Тут мне особенно нравится раздел 'Invalid assumptions during system distribution' — ложные представления при проектировании распределенных систем (нулевая задержка передачи, надежные сети, бесконечная пропускная способность, защищенные сети, топология не меняется, есть только один администратор, стоимость передачи данных равна нулю, сеть гомогенна — тут всё прекрасно!)

И 'Reasons for system distribution' — основания для распределения. Почему вы хотите распределенную систему, а не монолит? Это всё совсем не бесплатно. Вы решаете организационную проблему или техническую?

Большой кусок про микросервисы, с перечислением "за" и "против", и раздел про коммуникации, где живут наши интеграции (ну ещё захватывая раздел "шины").

В общем, козырная схема. Даже не знаю, что добавить. Сначала хотел придраться к структуре команд и обратному закону Конвея — но он упомянут в области решений и в микросервисах. Потом — к схемам и контрактам, но про них есть в коммуникациях. Про брокеры сообщений есть в разделе Fire-and-Forget. Вот фитнесс-функции куда-то потерялись, в явном виде не упомянуты.

Разбор всей схемы тянет на хорошую такую учебную программу месяцев на 8. Или на 6 отдельных курсов 😉

Как минимум, можно проверить себя: что из этого я знаю и использовал, о чем знаю только теоретически, и про что не знаю ничего. и составить план по изучению в режиме self paced learning.

Забираем, пользуемся!

Она же в виде картинки, только телеграм её пережимает до неразличимости, поэтому выше есть pdf.

А за что минусы-то?

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

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

Модели полезны тем, что дают советы по возможным действиям. Вы можете завести демократическое голосование, но тогда решение может быть неоптимальным или выборы могут зациклиться. Или вам нужно единоличное принятие решения. Или вы можете подкидывать кандидатов-"спойлеров", оттягивающих голоса у реальных альтернатив. Ни разу не слышал про такое, но математика говорит, что должно сработать: подкинуть явно непроходную фичу, но часть стейкхолдеров на неё отвлечётся и не будет возражать против нужных функций. Как легендарный атомный взрыв в фильме Гайдая — специально чтобы отвлечь внимание цензуры. (Если что, я не призываю манипулировать стейкхолдерами, хотя иногда ну очень хочется).

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

Более реалистичный вариант предложен Дунканом Блэком в форме теоремы "медианного избирателя": если предпочтения голосующих распределены вдоль какой-то оси — в политике, например, между "левыми" и "правыми" — голосование работает без ограничений теоремы Эрроу, и диктатор не нужен (а оптимальная стратегия для кандидата — найти медиану среди предпочтений, и декларировать максимально близкую к ней позицию). В требованиях это может быть ось "безопасность"-"удобство", или "стабильность работы"-"гибкость", то есть любые разумные конфликтующие требования с возможными промежуточными состояниями.

А в книгах ещё говорится, что нужно избегать конфликтующих требований! Да совсем наоборот — нужно тщательно оберегать конфликты, иначе придётся вводить диктатуру!

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

Тут опять вмешивается математика с уточнением, что ось распределения предпочтений должна быть только одна! В многомерном пространстве теорема медианного избирателя уже не работает.

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

Например, уже трёхзначаная шкала [-1,0,+1] уже лучше, чем просто упорядочивание (для большого числа избирателей, для малочисленных групп лучше использовать [-2,-1,0,+1,+2]). Недостатком тут является неустойчивость системы выборов к согласованным стратегиям голосующих и манипулируемости. Тут можно говорить об открытости и закрытости информации: знают ли участники о выборах других участников. И могут ли они менять свои голоса после того, как узнают о голосах других участников. Это всё сильно усложняет выборы, тут уже какие-то другие модели нужны (напишите мне, если знаете про них).

Я сам часто использую для оценки функций кардиналистский подход со шкалой [0,1,3,9]. Я не нашел модели, которая бы математически обосновывала такой выбор, подсмотрел у старших товарищей чисто в виде эмпирического правила. Но работает отлично!

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

[Если вас интересует хороший обзор темы, рекомендую вот эту статью: https://plato.stanford.edu/entries/arrows-theorem/ ]

Кто лучше всех учит навыку?

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

Ну просто многие вещи он уже делает на автомате, и даже не замечает, что их делает.

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

И тут недавно я получил ответ на одном занятии. Хотя, в общем, и раньше можно было додуматься.

Хороший тренер — это тот, кто разделяет деятельность, которой он учит, на минимальные составляющие, вычленяет в деятельности подопечного эти составляющие и корректирует те, что нуждаются в улучшении.

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

Это давно известно в спорте — я вот в институте немного занимался тяжелой атлетикой, и у нас в зале висели кинограммы рывка и толчка: покадровая съемка каждого упражнения, 15-20 фото на упражнение + траектория движения грифа штанги чуть ли не по сантиметрам. А так-то кажется — ну что там, взял, поднял.

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

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

Поэтому почти бессмысленны курсы и материалы, которые выглядят как набор тем. Ну, вы будете это знать (наверное). А как вы будете это применять? В какой последовательности? Как одно вытекает из другого? Какие проблемы могут возникнуть на каждой связке? У нас на тренингах участники удивляются чуть ли не после каждого шага: ой, мы теперь хотим вернуться и дописать/переписать требования. Ну да: потому что требования в спецификации — это не начальный артефакт, а конечный, мы в этой форме фиксируем результаты анализа.

То есть, важно не "что", а "как". По этой же причине "не работают" ГОСТы — в них написано "что", но почти никогда не написано "как".

С другой стороны, простой раскладки деятельности на отдельные составные части недостаточно, а на начальной стадии она даже вредна. Если вы начнете докапываться до мелких деталей у человека, который в целом не понимает, как что-то делать — пользы это не принесет. Нужно общее понимание, гештальт. Вы можете очень долго фокусироваться на отдельных движениях руками, ногами и телом, когда учитесь езде на велосипеде, но пока не "щёлкнет" — вы не поедете. Причем никто не сможет вам объяснить рассудочно и логично, что нужно делать. То есть, может, но это не поможет.

Тоже, кстати, довольно часто встречается у людей, которые переходят в профессию аналитика из других — в самом начале можно видеть, как у них "не щелкает" и они вообще не понимают, что тут происходит. Их тексты не складываются в единое целое (и одним из приемов является составление таблицы вместо текста), их диаграммы выглядят как нагромождение геометрических фигур и значков.

Эти наблюдения полезны и тем, кто развивает у себя в компании систему наставничества. Кто будет лучшим наставником? Не просто тот, кто лучше других выдает результат, а тот, кто:
1) выдает результат,
2) очень хорошо понимает, из каких отдельных действий состоит этот результат (то есть, скорее всего, обладает высокой степенью рефлексии),
3) понимает и может увидеть деятельность подопечного во всей целостности, как гештальт.