В одном из обсуждений поста про ритуалы и дейлики возникла тема про доверие. Человек отреагировал очень резко: синхронизация под запись в чате?! Да никогда! Это же всё сохранится и может быть заскринено и использовано!

Я, честно говоря, даже немного опешил. За 28 лет я с такой культурой встречался, пожалуй, только раз — в одном государственном проекте, где всегда нужно было думать, что и кому ты говоришь, взвешивать слова и понимать, кому твои слова будут переданы и в каком виде, и как будут использованы (скорее всего, с целью навредить). Долго я там работать не смог, естественно. Вообще не представляю, как работать в среде с низким уровнем доверия.

Тренеры по лидерству тут любят вспоминать Патрика Ленсиони и его книгу "5 пороков команды" (дисфункций), где он описывает пирамиду "пороков": отсутствие доверия ➜ боязнь конфликтов ➜ необязательность ➜ избегание ответственности ➜ безразличие к результатам.

Как любая вертикальная теория, эта пирамида описывает всё в упрощенном виде, но сами по себе эти "пороки" я вижу в командах очень часто. Конечно, всё не так просто, и научные модели дают более комплексную картину. Например, сами по себе конфликты могут быть и продуктивными, и деструктивными. Умеренные конфликты по поводу выполнения задач, или "конфликты идей" наилучшим способом оказывают скорее полезное влияние на общий результат (к таким конфликтам относятся разные взгляды на выбор технологического решения, например). Затяжные "процессные" конфликты скорее вредят (конфликты, связанные с логистикой задач и данных, процедур принятия решения и распределением ответственности). Межличностные конфликты вредят в любом случае (сюда же относятся конфликты целей, норм и ценностей).

Конечно, мы исходим из предположения, что у всех членов команды одна общая цель или цели хотя бы взаимосвязаны — если выиграешь ты, выиграю и я, без этого конфликты вообще сложно решить. Ещё важно, кто во что верит и как оценивает ситуацию — как win-win, или как win-lose. Особенно удивительно видеть, когда представители бизнес-заказчиков начинают бодаться с разработкой, рассматривая этот конфликт как win-lose. В отдельных случаях встречаются даже персонажи, находящиеся в парадигме lose-lose: "Ура! Всем плохо!".

Источники конфликтов тоже разнообразны:
- проблемы в коммуникации (слишком редкая, слишком нерегулярная, перегружающая, неправильно выбранный канал / время / форма / тон, недостаточно контекста, недостаточно прямая);
- неверный выбор основы власти или стиль управления (принуждение или стимулирование, нечеткие границы и двусмысленные требования);
- культура организации (поощрение личной конкуренции, а не кооперации)
- недостаток координации, знаний и сплоченности (члены команды не понимают, зачем они работают, и изолированы друг от друга)

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

Факторы внешнего давления:
1. Проекты с высоким риском / ставками
2. Двусмысленные, плохо разграниченные роли и области ответственности
3. Несколько начальников с противоречивыми требованиями
4. Использование сложных технологий с запутанными связями
5. Нереалистичные сроки
6. Недостаток ресурсов
7. Недостаточное финансирование
8. Некомпетентное руководство

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

За летними делами пропустил историческую новость: в протокол HTTP добавили новый метод! Не каждый день бывает.

Добавление свежее, июньское, RFC 10008. Статус у него — Proposed Standard, но с таким статусом множество технологий живет, это значит — в целом норм, можете уже реализовывать в своих системах. В Nginx новый метод уже поддерживается. Называется этот метод QUERY. используется он примерно так:

QUERY /products/search HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded
Accept: application/json
q=distributed+systems&category=books&min_year=2025&sort=relevance

То есть, это фактически официальный GET с телом.

Проблема была в чем: если вы хотите найти что-то по сложному условию и множеству параметров, можно использовать GET, но параметры поиска можно передать только в строке запроса. Тела запросам GET не положено — его можно передать, но сервер или любой промежуточный узел может это тело проигнорировать и дальше не передавать. Строка запроса обычно ограничена по длине, есть даже специальный код ответа 414 URI Too Long.

GET безопасный, идемпотентный и кэшируемый.

POST небезопасный, неидемпотентный и не кэшируется. Зато у него может быть тело большого размера.

QUERY объединяет самое лучшее: он идемпотентный, безопасный, может кэшироваться и содержать тело. Заодно не оставляет следов в логах (что там было в теле — не видно). Так что если ваши запросы были слишком специфичны — теперь для них есть специальный механизм.

В каком именно формате вы будете передавать запрос в теле, стандарт не задает, но требует, чтобы вы явно указали это в заголовке Content-Type.

Там есть всякое интересное:
application/x-www-form-urlencoded — это строка запроса из URL
application/sql — SQL-запрос (вот так, прямо через REST API)
application/jsonpath — для вытаскивания специфических данных из JSON
application/xslt+xml — то же для XML
application/graphql — запрос в формате GraphQL
application/sparql-query — запрос в формате SPARQL
и т.д.

Можно спросить у сервера, в каких форматах он готов принимать запросы (он ответит в заголовке Accept-Query).

Можно ещё добавить Accept, то есть, например, в одном эндпоинте передавать простые запросы через строку, а для сложных переходить на SQL (теоретически), и получать ответ либо в JSON, либо в CSV (если сервер умеет). Всякую интересную логику можно реализовать.

Начинают играть коды ответов, про которые никто и не помнил:
415 Unsupported Media Type — сервер не поддерживает этот формат запроса к этому ресурсу
422 Unprocessable Content — сервер поддерживает этот формат, синтаксис запроса валидный, но выполнить его невозможно (например, нет такой таблицы, к которой обращается SQL)
406 Not Acceptable — клиент запросил ответ в таком формате, который не поддерживается сервером.

Сервер может даже создать новый ресурс, содержащий результат выполнения запроса! Как явный кэш, или как снэпшот на определенное время. Вернуть ссылку на него клиенту в заголовке Content-Location, а дальше к нему уже можно делать обычный GET. Сам QUERY при этом остается безопасным — новых ресурсов при повторных вызовах создаваться не будет.

Вот такая штука. Слышали уже? Планируете использовать?

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

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

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

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

Так нам говорит теория соц.исследований. UX-исследования, в сущности, специальная область применения таких исследований. Мне стало интересно — есть ли в UX исследования провокацией? И, представьте себе, есть! Даже термин для этого есть: provotype (provocation + prototype, провокационный прототип).

Это как бы доказательство от противного: что для пользователей действительно важно, а с чем они готовы мириться (а может быть, радикальные изменения, на которые никто не мог решиться, наоборот будут удобны!)

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

В одной статье описан провотип, который был сделан, как хоумпейдж из 90-х: с Comic-sans, желто-розовый и с gif-анимациями. Это был прототип сайта налоговой службы. В обсуждении быстро стало понятно, что именно тут кажется неуместным заказчикам и пользователям. Это ещё один принцип: не спрашивайте, что нужно и что удобно, спрашивайте — что мешает. В таких вариантах провотипа используется явно неуместный объект, не отсюда. Иногда присутствие такого объекта заставляет задуматься, а так ли он неуместен?

Ещё один вариант: против правил. "У нас всегда...", "Система не позволяет...", "Пользователь привык, что...". А что если нет? Что если мы подвергнем сомнению этот принцип, и сделаем наоборот?

Близко к этому примыкает тонкий прием, когда в прототипе что-то заведомо неправильно. Например, одна и та же информация представлена в двух вариантах, без какого-то объяснения. Исследователь фиксирует — а заметил ли вообще это пользователь, и какой вариант лучше? Возможно, информация неконститентна (и это специально). Многие дизайнеры вообще не следят за консистентностью, и иногда это можно обратить на пользу. Например, однажды дизайнер нарисовал интерфейс, в котором у ученика 6-го класса были выведены результаты ЕГЭ. Ух, мы много новых требований вытащили из этого прототипа!

Я часто вижу среди рекомендаций по системному анализу книгу Донеллы Медоуз "Азбука системного мышления" ('Thinking in Systems. A Primer'). Тут у меня дошли руки прочитать её.

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

Ну да, это известная проблема с одинаковыми названиями двух совершенно разных дисциплин: системного анализа и системного анализа. Первый — кусок из кибернетики/теории управления, с математическим моделированием, теорией оптимизации и принятия решений, исследованием операций и всяким таким. Второй — набор практик для выявления требований и проектирования ИТ-систем. Вот "Азбука системного мышления" из первой области. Более того — это "системное мышление" применительно к управлению социальными системами, а технические если и упоминаются, то лишь в качестве иллюстрации.

Какие тезисы внутри:
🔸 Системы состоят из элементов, связанных потоками информации. Пока вроде всё ок.
🔹Поведение системы может быть адаптивным, целеустремленным, ориентированным на самосохранение и иногда на эволюцию. Очевидно, мало какие ИТ-системы обладают такими свойствами. Скорее наоборот — сами по себе они практически не адаптивны, не ориентированы на самосохранение или эволюцию.
🔸Цель системы, как правило, не выражена явно. Всё наоборот, да?
🔹Главное в системах — запасы, то, что накапливается. Ну, в каком-то смысле можно рассматривать накопление информации, но тут есть ловушка: обычно в ИТ-системах накапливается информация, но только эта "информация" обычно не имеет смысла для системы: система никак не меняется под действием этой информации. Это отличается от понятия "информация" из физики, где поступление медленнее, чем изменение объемов входящих и исходящих потоков. То есть, у системы есть инерция, и она меняется под внешним воздействием не так быстро, как мы ожидаем. Это с одной стороны может демпфировать резкие скачки потока, не давая системе сломаться, с другой — затягивает требуемые изменения. Даже не знаю, как это применить к ИТ-системам, разве что к проектированию нагрузки и эластичности.
🔹Наличие запасов позволяет исходящим потокам не зависеть от входящих.
🔸Система управляет собой через обратные связи. Но в ИТ-системах ничего подобного нет! Они не эволюционируют сами по себе, не содержат петель обратной связи и у них нет запаздывания реакции.

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

В общем, это всё очень интересно с точки зрения внедрения изменений в организациях и обществе, но к ИТ-системам имеет отдаленное отношение. Для ИТ-систем это всё начинает работать, только если мы включаем в рассмотрение команду поддержки и разработки системы — тех, кто как раз получает обратную связь о работе системы и может её менять. Если рассмотреть всё вместе: ИТ-систему, технические средства и команду разработки, а ещё лучше — управленческую и политическую обвязку — то принципы Медоуз начнут работать. Именно в управленческом или лидерском аспекте. Может быть также полезно посмотреть с этих позиций, если вас интересует — как изменится деятельность организации после внедрения какой-нибудь системы. Это уже для правильных бизнес-аналитиков и продактов.

А для задач сбора требований и проектирования программных систем книга практически ничего не дает.

Глядя на разрастание объема требований в очередном проекте, вспомнил шутку про поправочный коэффициент π×e, на который нужно умножать число выявленных требований, чтобы получить число реальных.

Эта формула имеет геометрический смысл: R×π×e,

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

При многоступенчатом процессе согласования уже нужно брать интеграл по поверхности требований, но итоговая формула получается тоже простой: 2π×R×h×e, где h - число уровней согласования.

В среднем получается ~8.54, что очень похоже на большинство проектов.

Математики до сих пор не уверены, является ли это число иррациональным, но мы-то знаем...

Обратите внимание, что π в данном случае показывает разворот требований на 180°, то есть строго в противоположную сторону. Если ваш заказчик при согласовании требует не противоположного, а перпендикулярного первоначальной задумке, можно использовать коэффициент π/2, то есть примерно 4.27.

Правда, если заказчик движется не по окружности, а по синусоиде, придется опять вернуться к 8.54, т.к. заказчик колеблется от π/2 до -π/2, что дает полный размах безумия.

Так же в терминах управления проектами интерпретируется знаменитое равенство Эйлера:

e^iπ + 1 = 0.

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

Сел тут выписывать категории стейкхолдеров. В проекте положено делать анализ стейкхолдеров, да? Обычно его либо не делают, либо с умным видом рассказывают про "луковичную диаграмму" (и иногда даже рисуют её).

Луковичная диаграмма делит стейкхолдеров на круги, или слои. Конкретные названия слоев варьируются.

Йэн Александер (собственно, автор методики и книг «Writing Better Requirements» и «Discovering Requirements: How to Specify Products and Services» — кстати, не вижу, чтобы они переводились на русский, а это вам не Вигерс, это конкретное руководство про выявлению и написанию требований) предлагает следующие:

0 слой: сам продукт
1 слой: "наша" система: продукт + операторы + инструкции/правила по работе с системой
2 слой: объемлющая (содержащая) система: наша система + бенефициары нашей системы (кто получает пользу от её функционирования, но сами могут не пользоваться ей)
3 слой: широкое окружение: объемлющая система + все остальные стейкхолдеры

Раскладывает стейкхолдеров по типам так:
1 слой ("наша система"):

* Нормальный оператор: вводит данные, отдает команды и получает результат от работы продукта. Главные требования: наличие необходимых функций, удобный и понятный пользовательский интерфейс, скорость работы, отсутствие ошибок/потерь данных, безопасность.

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

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

2 слой ("содержащая система"):

* Функциональный бенефициар. Получает пользу от нашей системы, возможно не напрямую, а от операторов. Это немного старомодное деление, когда умение работать с компьютерами было отдельным скиллом. Хотя встречается и сейчас, в любом взаимодействии, когда вы смотрите на экран компьютера с обратной стороны: на кассах, в банках, МФЦ и т.п. Функциональный бенефициар в данном случае мы, мы взаимодействуем с оператором, а не с системой напрямую.

* Владелец смежной системы. Александер называет их "Ответственными за интерфейсы". С кем вы будете говорить, когда речь пойдет об интеграциях.
* Приобретатель. Может быть один (в организации) или миллионы (в массовом продукте, тогда их представляет Продакт). Кто выкладывает денежки. Кто отвечает за то, чтобы продукт был сделан.
* Спонсор или чемпион продукта. По-русски мы так не говорим, но это тот, кто вообще пробивает создание нашего продукта. Причем не только находит деньги но и решает политические вопросы. Исполнительный продюсер.

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

Он даже предлагает выделять специальную роль:

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

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

* Финансовый бенефициар. Получит прибыль от создания системы. По-честному, редко берется в расчет, если вы не делаете коммерческий продукт.

* Регулятор. Тот, кто задает правила игры — обычно в виде ограничений или навязанных функций.
* Разработчик. Есть мнение, что они вообще не должны быть в этой модели, они перпендикулярны.
* Консультант (западная практика, бывает ли в РФ?)
* Поставщик (обычно очень далекая роль, но для некоторых систем бывает крайне важен)

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

Дальше культурно-историческая теория деятельности (в изложении Энгестрема) говорит о противоречиях — contradictions, или о напряжениях — tensions. Зачастую эти противоречия уже существуют, сложились исторически ещё до внедрения ИТ-системы, а система может их гасить или усугублять, или вводить новые напряжения.

Эти же напряжения являются на самом деле движущей силой для эволюции системы деятельности, в том числе для создания ИТ-систем. Интересный вопрос — какое напряжение, какое противоречие стало поводом создать вашу систему?

Энгестрем выделяет структурно 4 уровня противоречий:

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

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

3. Противоречие между существующей системой деятельности и новой. Это когда мы пытаемся что-то менять.

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

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

У противоречий есть 4 проявления:
1. Дилемма
2. Конфликт
3. Критический конфликт
4. Двойное послание

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

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

Впрочем, это оптимистичный взгляд — бывает и по-плохому:
* система деятельности может застрять в бесконечных воркэраундах, а люди начнут просто сгорать из-за двойных посланий;
* сообщество может фрагментироваться и поляризоваться: все начнут обвинять друг-друга, и без способности объединиться никакого обучения происходить не будет, а будет происходить политический паралич;
* руководство (особенно бюрократическое) может начать усиливать давление: раз правила не работают, значит, их плохо соблюдают. Давайте введем больше правил и строже штрафовать! Система сваливается в раскручивающуюся петлю обратной связи
* вместо усложнения деятельности система может деградировать и вернуться к более простым, но энергетически более выгодным формам

В общем, это всё ужасно интересно, и особенно — какова во всем этом роль ИТ-систем, какое перераспределение информации и власти они создают, и это, на мой взгляд, и есть самый настоящий бизнес-анализ. Только я такого ни в одной учебной программе по БА не видел.

Знаю, что в Яндексе работает много аналитиков данных, или BI-аналитиков — тех, кто перемалывает массивы данных и извлекает из них всякие интересные инсайты.

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

У Яндекса есть подкаст от аналитиков для аналитиков "Доверительный интервал" — это регулярные встречи, где они обсуждают свои задачи и актуальные боли. Последний выпуск там был про ИИ: у них тоже идёт освоение, adoption, есть сомневающиеся, есть и ментальные блоки "ой, я попробовал, ничего эти агенты не умеют".

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

Интересная мысль там была про агентов. Я сам где-то с весны работаю не в отдельных чатах, а в Cursor'е. Какие там агенты, где там агенты — ну, где-то внутри они есть, для меня это всё равно выглядит, как чат. Но! Этот чат (через агентов) имеет доступ к файлам на диске, к браузеру, к интерпретатору python или node, MCP, и может запускать разных агентов для разных задач. Если вы видели ИИ только в виде чата в браузере — попробуйте. Это вообще другой уровень. Те же презентации агентами гораздо удобнее собирать, в чате у меня ни разу нормально не получалось, а тут один агент думает над содержанием, другой пишет код, генерирующий pptx, и запускает его, третий думает про оформление, четвертый проверяет. А когда у вас есть подключенные системы и данные, всё вообще начинает выглядеть, как магия.

В том числе и для пользователей. Я помню, как давно зрела идея, что бизнес сам сможет получать нужные данные. SQL продвигали под этим соусом, конструкторы дашбордов — ничего не срабатывало, всё равно заказчику нужно было или звать разработчиков/аналитиков, или самому становиться таким разработчиком. И вот, наконец, с ИИ — вроде начало получаться. Можно сказать, чего ты хочешь, и ты получишь это. НО! Проблема в том, чтобы убедиться, что данные достоверны. Вот это сомнение важно в заказчика заложить (и ребята в видео как раз об этом говорят), а то часто все принимают на веру.

Куда в таком случае деваются аналитики, и нужны ли они? Ну, во-первых, остаются всё-таки сложные задачи (которые всё равно теперь можно делать в разы быстрее); а, во-вторых, и это даже важнее — аналитики становятся архитекторами инфраструктуры. Чтобы ИИ всё сделал, нужно ему подготовить качественные данные (и убедиться, что они качественные), описания этих данных (чтобы понял смысл) и ограничители/валидаторы (харнесс), чтобы быть уверенными, что ИИ выдал не ерунду.

И это интересное свидетельство о том, какие формы применения ИИ зарождаются в индустрии: 1) усиление себя, делегирование своих задач, получая ускорение в разы или даже десятки раз; 2) передача своих функций заказчикам, оставляя за собой построение архитектуры и контроль качества. Две разных стратегии, но в обеих получается делегирование, только разное — ИИ-агентам или своим же заказчикам. А вы посередине, как царь горы 🤩

Должен вам сказать, на самом деле я не отношусь к ранним последователям. Я даже скорее тормоз в этом смысле. Вот и с ИИ я только весной этого года добрался до Cursor. И вот что советую: если вы пробуете что-то делать в свой работе через чаты — бросайте эту ерунду. Это работает только в режиме "спросить что-то очень быстро" или "сгенерить очередную одноразовую картинку". Для настоящей работы над сколь-нибудь большим проектом нужно использовать среду разработки со встроенными агентами — Cursor, Claude Code, OpenCode и т.п.

Мне нравится Cursor, потому что у него знакомый интерфейс VSCode (и интерфейс в принципе есть, а не просто консоль, я не консольный чувак), есть выбор из разных моделей и встроенные агенты. Это не вайбкодинг, это так сейчас программирование выглядит. Я, кстати, впервые с 2012 года взялся за написание чего-то большего, чем скрипт для анализа или парсинга данных, и сейчас в одиночку строю проект, на который раньше понадобилась бы команда из 3-5 человек.

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

Что у меня из скиллов в постоянной работе:

grill-me от Matt Pocock (https://github.com/mattpocock/skills). Скилл делает ровно то, что в названии — качественно прожаривает вашу идею, иногда прямо очень жестко. Работает он в режиме интервью, то есть задает вам вопросы. Аналитика, который бы задавал такие вопросы, любой заказчик сам бы прожарил из огнемета. А когда они исходят от тупой машины, вроде и не так обидно. На выходе получается план проекта с основными техническими решениями (grill-with-docs формирует документацию, в которой, в том числе, задан язык, которым вы описываете проблемную область). У Мэтта там целый пак скиллов, которыми можно дальше генерить проект по спеке после прожарки, но я использую в основном для обкатки идей проектов и документов.

spec-kit для Cursor (https://github.com/madebyaris/spec-kit-command-cursor). Вы знаете, какое самое последнее новшество в разработке? SDD — Spec-Driven Development, разработка, управляемая спецификациями. Вот неожиданность, правда? Оказывается, ИИ лучше всего разрабатывает по детальным спецификациям, вот так новость! Скиллы от Мэтта — это тоже SDD, но я пока не придумал, как их объединить. SpecKit хорош тем, что содержит цельный воркфлоу, от написания этих самых спецификаций до их реализации. Он тоже сначала проводит с вами интервью, но более поверхностно, без прожарки. Если мне не нужно сильно вникать, я беру его. Он генерит большие объемы спецификаций (сотни задач), а потом так же неутомимо их реализует. Фактически, это таск-трекер на основе файлов, со статусами и ссылками на спецификацию (у меня в одном из проектов оно сделало сходу 61 задачу, и это только MVP!)

adversarial-editorial-review (https://github.com/Halfofthesky/adversarial-editorial-review) — это тоже прожарка, но для статей (очень мне помог при написании магистерской, правда результата от людей-ревьюверов я пока не видел 😅). Он берет ваш текст и дает трем разным "ревьюверам": один считает, что доказательная база слабее, чем вы преподносите, второй — что в аргументации есть логические изъяны, третий — что вы упускаете точку зрения кого-то из вовлеченных лиц, или слишком вольно трактуете теорию, на которую опираетесь. Для научных публикаций мне очень понравился (хинт: можно не только свои брать, но и чью-то готовую опубликованную подсунуть!), нужно бы такой сделать для проектных аналитических документов — чтобы с разных сторон критиковали, а потом редактор сводил общий результат.

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