Давайте легкую тему для пятницы. Как вы даете имена своим системам или их версиям?

У меня с этим всегда были проблемы. Самая моя долгоживущая система долго вообще никак не называлась. Ей уже полгода пользовались, а названия не было. Пользователи её называли "считалка". Ну, такое. В итоге назвали её АСК: Автоматизированная система казначейства. Причем он оказался мужчиной: "Опять это вас АСК не работает!"

А другую систему, для маржинальной торговли, тоже долго не называли, потом так и прижилось - Margin Trading.

Ещё в одной системе были десятки сервисов с трехбуквенными аббревиатурами: PLP, PLE, XLE, LMS, LRS, FMS и т.д. Своим всё понятно, человек со стороны не разберется.

Кому-то это легко дается легко — мой младший ребенок отлично придумывает названия: смастерил что-то из лего, и говорит — это Шушик! Смотришь — ну точно, вылитый Шушик, по-другому и не назовешь.

Мне это дается мучительно. Если бы я давал какой-нибудь системе имя, поступил бы как Шарик из Простоквашино: написал бы первое пришедшее в голову, например "утюг".

В одной компании версии систем называли именами озер: Байкал, Селигер, Сенеж. Стойкая ассоциация с чем-то военным.

В другой компании — очень российской! — версии были по номерам, но сама система называлась почему-то по имени города в Калифорнии - Аламеда.

В иностранном ПО любят кроме номеров версиям давать ещё и кодовые имена. У ОС Android это были разные сласти: мармелад, нуга, пирог, орео. У Microsoft - названия городов. У Apple - то примечательные места, то города, то кошки, то сорта яблок.

У OpenEdX релизы именуются по видам деревьев, выбранных по первым буквам алфавита. Правда, они дошли уже до Ulmo (Эвкрифия сердцелистная) и Verawood (на русском вообще названия нет), не знаю, что дальше будут делать.

Самые креативные названия версий у Ubuntu, есть даже целая страница: https://wiki.ubuntu.com/DevelopmentCodeNames, там у них всякие "Бдительные Бородавочники" и "Сметливые Селезни" (прилагательное + животное на одну букву).

У Intel кодовые имена процессоров назывались по горам, рекам, озерам и городам вокруг мест, где расположены фабрики по производству. До сих пор помню фотку в офисе Бабаяна: "Команда Эльбруса покорила МакКинли" (гора на Аляске, кодовое имя одной из версий процессора Itanium).

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

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

А как у вас принято именовать релизы? Номера, кодовые имена, какие-то правила их присвоения?

Какие вы знаете методы приоритизации? Например, функций продукта или пользовательских историй?

MoSCoW, RICE, модель Кано, value/effort, buy a feature, USM, Weighted Shortest Job First, что ещё бывает?

В целом, это, конечно, многофакторный анализ — то, чему учат на предмете "Системный анализ" в институтах. Чтобы не учитывать много факторов — их схлопывают до 2-4.

Но мне, честно говоря, и этого всегда было много и как-то сложно. Хочется чего-то более легковесного.

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

Вопрос — как перейти от попарного сравнению к упорядоченному списку. И такой метод есть — это рейтинговая система Эло (Elo rating system), которую используют в шахматах для оценки силы игроков.

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

Почему-то не вижу статей про применение рейтингов Эло для приоритизации, зато есть инструмент, куда можно забить свой бэклог и прогнать приоритизацию https://elo.bytes.zone/ (кстати, там можно всё, что угодно, сравнивать, не только элементы бэклога).

Я попробовал один список загнать, с которым мы группой часа два работали и чуть не переругались — получился ровно тот же результат, причем минут за 5-7.

Попробуйте, очень интересно, что у вас получится?

Я уже писал про митап Pimon 2025, посвященный ESB — очень классный, это фактически специализированная конференция про шины.

И в комментариях спрашивали про записи. Я обещал написать, когда опубликуют записи. И вот они опубликованы:

Интеграционные платформы: Панацея или лишний слой?», Антон Копылов, «Аксеникс» видео | презентация

«ESB в России: тренды и перспективы. Результаты исследования», Александр Жиляев, Size Marketing видео | презентация

«Российские платформы ESB: критерии выбора, практическое применение», Сергей Скирдин, «Белый Код» видео | презентация

«Применение нейросети для трансформации сообщений в FESB», Олег Рубцов и Франклин Банкуе, «Неолант Тенакс» видео | презентация

«Integration Gears: новый модуль Monitoring Center», Антон Курудинов, «ЛАБ СП» видео | презентация

«Прототип инструмента для миграции с SAP PO на Integration Gears», Денис Бекишев, «ЛАБ СП» видео | презентация

«JSON-first integration flows», Марат Бареев, BeringPro видео | презентация

«Репликация в «Нормализаторе», Леонид Шумский и Александр Грищенко, «Т1» видео | презентация

«Подсистема интеграции для 1С:Предприятия», Андрей Соколов и Сергей Сулимов, «Корус Консалтинг» видео | презентация

Ну или все видео в одном плейлисте: https://youtube.com/playlist?list=PLHiGNvm26VdMoauuMRoSOxQV7tkq-7iie

Надеюсь, в следующем году мероприятие будет ещё масштабнее!

Самое интересное на Pimon, как мне показалось, было выступление Сергея Скирдина с обзором российских ESB, а точнее — критериев их оценки. Я послушал доклад, скачал обзор, прочел несколько постов Сергея на Хабре.

Вот что мне показалось любопытным:

Во-первых, в РФ вендоров ESB больше 40 штук! Это само по себе удивительно, потому что в Википедии всего 28 во всем мире перечислено, а на Capterra и того меньше — 19 (но там, как обычно, мусор какой-то).

Если копнуть глубже, становится понятен такой разброс: российские "продукты" — это, в большинстве случаев, просто сборки open-source компонент, дополненные специфическими российскими адаптерами и прошедшие специфическую российскую сертификацию. Иногда там что-то свое дописано, иногда к сборке прилагается методика внедрения.

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

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

Тут бы хотелось какую-то классификацию, ну или профили — как сборки типовых функций. Сергей, насколько я понял, выделяет следующие:
1. Набор типов коннекторов и возможности их конфигурации. Тут нужно раскрывать, что там внутри: правила, форматы, фильтры, протоколы.
2. Функции и возможности преобразования данных
3. Настройка маршрутизации и, как расширение, целых сценариев и бизнес-процессов
4. Проверки корректности данных и контрактов
5. Мониторинг и траблшутинг — тоже в широком смысле, от логов до механизмов гарантированной доставки и очередей ошибок
6. В принципе наличие очередей, их виды и назначение

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

Надеюсь, такая работа ведется (и готов участвовать, кстати).

То же касается и НФТ: выцеплены отдельные характеристики, но хочется систематизации.

В-третьих, из любопытного: в продуктах появляется ИИ. Обычно это почему-то LLama, а используется она для составления маршрутов и настройки преобразований, или для выявления нестандартного поведения и ошибок (вот это интересно!)


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

С другой стороны, если анализировать продуктовую сторону такого обзора, возникают некоторые сомнения — кому и в какой момент он нужен? Шину выбирают не так часто, а меняют и того реже. И если так, то обзор должен стоить довольно дорого, и быть довольно детальным, с результатами пилотов и экспериментов, с рассмотрением типовых кейсов (это, кстати, раскрыто у Сергея в серии постов — некоторые решения он пилотировал). На западных рынках есть такой тип компаний: технологический брокер, или консультант по выбору ПО. Который только советует и выбирает, но не ведет сам проект внедрения (этим занимаются интеграторы). Интересно, есть ли у нас похожие сервисы, и готовы компании платить за такую услугу?

Обнаружил у себя привычку анализировать различные сбои с точки зрения их возможного предотвращения системным аналитиком. Вот если бы на проекте был аналитик — смог бы он задуматься о возможном сбое?

Вот и сейчас — смотрю на отчет по сбою амазоновского US-EAST-1, который уронил чуть ли не все сервисы (люди урок в Duolingo пройти не могли! Стрики свои многомесячные потеряли!)

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

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

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

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

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

Но вот удаление всех записей в базе (в DNS, в данном случае) — пожалуй, можно предотвратить. Пустые поля, удаленные записи — у Гугла же последний массовый сбой был тоже из-за отсутствия проверки на пустое значение. Тут, мне кажется, аналитик мог бы помочь.

Я на тренинге упоминаю о статистических проверках данных: не просто вам пришло что-то, и ок, а проверьте — то, что пришло, оно вообще похоже на то, что вы ожидали? Возможно, обычно вам записей приходит около 10000, а тут пришло 100 — это нормально, или ошибка? Обычно суммы в договорах распределяются нормально, а тут вдруг 70% одинаковые — это нормально? Время выполнения домашних заданий у студентов тоже как-то распределено, а тут мы получили все с одним временем загрузки — подозрительно? Наш процесс собирается удалить все IP-адреса — правильно ли это? И так далее. Думать о таких вещах заранее — верх душноты. С другой стороны, достаточно один раз потерять все записи за день из-за сбоя в интеграционном слое — и будешь вставлять такие проверки на автомате.

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

А главное, это всё может возникнуть совершенно неожиданно в любой сколько-нибудь нагруженной интеграции. И как это всё учесть?

Ну что, аналитики, настало ваше время! Самый модный способ разработки программ с помощью ИИ сейчас — SDD, spec-driven development. Человек пишет требования и спецификации, ИИ пишет по ним код. Программисты не нужны.

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

Идея похожа на подход "documentation first", знакомый нам по API. Как конкретно код написан — уже не очень важно, пока он соответствует спецификациям. И меняется в ходе проекта в первую очередь спецификация, она становится ключевым артефактом. А как все смеялись над российским подходом с обязательными аналитиками и постановками на каждом проекте!

Инструменты SDD уже выкатил GitHub: Spec Kit, есть отдельные проекты — Tessl.io и Kiro. Недавно на сайте Мартина Фаулера вышла обзорная статья, кратко перескажу её здесь.

Три основные идеи SDD:

1. Spec-first: сначала пишется (ну или генерируется) спецификация. Код генерируется только по этой спецификации.
2. Spec-anchored: спецификация сохраняется надолго. Если в дальнейшем понадобятся изменения — меняется спецификация, а не код. Изменения в коде следуют за изменениями в спецификации.
3. Spec-as-source: спецификация — главный артефакт, и только над ней работает человек. К коду человек не прикасается.

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

Работает примерно так:

Kiro предлагает цепочку Requirements → Design → Tasks (Требования → Проект → Задачи).
Требования записываются в виде юзер-сторей с критериями приемки в формате BDD-сценариев (Дано... Когда... Тогда...).
Проект представляет собой описание устройства будущей системы:
Архитектура:
Компоненты архитектуры
Потоки данных
Компоненты и интерфейсы
Модели данных и т.д.

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

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

В промптах используется очень много чеклистов для проверки каждого шага (правда, проверяет их сам же ИИ).

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

Теперь о проблемах. В статье есть и описание попыток что-то сделать в логике SDD, и основной вывод — непонятно, для какого кейса применим этот подход. В туториалах, если они есть, показано создание небольшого проекта с нуля (greenfield). Но именно что небольших. При попытке исправить небольшой баг в существующем проекте (brownfield) быстро выяснилось, что нужно написать 4 разных юзер-стори и проверить 16 приемочных сценариев. Причем в одном из случаев ИИ неплохо разобрался с кодовой базой, но когда дошло дело до самостоятельного написания — принялся дублировать уже существующие классы...

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

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

Так, ну мы доигрались. Обсуждения продуктового подхода в комментах к одному там посту таки вылились в целый баттл! Будем в четверг разбираться - есть всё-таки за продуктовым подходом новая философия, или это просто удобный способ работать с требованиями, гипотезами и релизами (ну и вытягивания денег из пользователей, ничего личного).

Приходите! За кого будете болеть?

Чем изучение учителей может помочь аналитикам?

Я люблю перетаскивать методы из одной отрасли в другую. Такой трансфер технологий и методик. А то каждый варится внутри своей индустрии, и не знает, что там у других. И появляются почти идентичные методики — например, в образовании никто не знает про PDCA или HADI-циклы, у них там ADDIE — Analize, Design, Develop, Implement, Evaluate. В авиации очень развита методика использования чеклистов. В медицине — интересные находки в области обратной связи (например,"шит-сэндвич" плохо работает, лучше работает Ask-Tell-Ask). В промышленности есть стандарты по интеграции. И т.д.

Интересно это изучать и переносить работающие практики.

Вот, например, модель интеграции технологий в образовательный процесс, TPACK. Идея в том, что для эффективного использования технологий нужно не просто хорошо знать технологические инструменты (Technology Knowledge, TK), но и педагогические практики (Pedagogical Knowledge, PK) и свой предмет (Content Knowledge, CK). И их пересечения: TPK — как подкреплять педагогические практики технологиями, TCK — как технологии помогают именно в этом предмете, и PCK — какие педагогические практики используются для этого предмета. Ну и TPACK — как всё это собирается вместе. В последнее время эту модель расширяют знаниями про ИИ: AI-TPACK.

И вот тут, кажется, можно рассмотреть такую же картинку для аналитиков, применительно к AI. Получается очень похоже:
🤖 технологические знания (PlantUML, C4, SQL, Swagger, RegExp'ы, Промпт-инжиниринг) — TK,
📚 знания методов анализа (методы сбора требований, контекстный анализ, моделирование потоков данных, моделирование данных, методики проверки полноты, методики разработки и оценки НФТ, пользовательских интерфейсов, интеграций) — System Analysis Knowledge, SAK,
🎁 знание предметной области — Domain Knowledge, DK.

Сокращение c красивым именем, правда, не придумывается — TDSAK? SADTK? TEDSAK? DAISAK?

Но про пересечения (особенно в контексте ИИ) можно продуктивно подумать:
TSAK — какие методы системного анализа можно поддержать какими технологиями и [ИИ-]инструментами?
TDK — какие технологии обычно применяются для описания этого домена? Что про них знает ИИ?
DSAK — какие методы анализа применимы в этом домене? Что чаще используется?

И, кажется, эту модель можно использовать и для создания промптов — тому же ИИ нужно будет объяснить предметную область; методики, которые вы применяете (и хотите, чтобы ИИ их за вас применял); технологии (те же инструменты для рисования диаграмм, форматы описания архитектуры, API и т.д.)

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

Но несколько небезынтересных идей удалось сформулировать.

Во-первых, похоже, мы с Димой адресуемся к разным аудиториям. Как у Джоела Спольски в эссе "5 миров": когда вы читаете или слушаете чье-то мнение — обратите внимание, из какого "мира" этот человека.

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

Если очень нужно работать с внешней командой, а хочется продуктовый подход — есть способ организации работ "Retainer", вот про него в изложении Алексея Кулакова: https://speakerdeck.com/kulakov/razrabotka-produkta-vs-autstaf-vs-autsors

Ещё есть Agile Contracts: "Money for Nothing and Your Change for free" https://www.scruminc.com/agile-2008-money-for-nothing-2/

Но это всё про внешнюю разработку. Я же из другого мира. Никогда не работал в интеграторах, и редко работал на стороне исполнителя в заказной разработке. Моя сфера — внутренняя или продуктовая разработка. Конечно, внутренняя разработка может быть тоже устроена по принципам заказа и проектов, но это, в моем опыте, приводит к некачественным результатам. Развитие внутренних продуктов гораздо лучше работает, по всем параметрам. Поэтому у меня, честно говоря, даже мысли не возникает, что нужно убеждать кого-то в преимуществах продуктового подхода — а как ещё-то? И у меня вообще нет в голове разделения на заказчиков-разработчиков, как отдельных противостоящих друг-другу акторах. Когда речь идёт от win-win, мне и в голову не приходит, что это решение между бизнесом и разработкой. У вас разработка победила бизнес? Или бизнес победил разработку? Ну молодцы, что сказать. Я-то скорее думаю про win-win между бизнесом и клиентом.

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

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

Вопрос про win-win в продуктах меня очень смущает, на самом деле. Нет никакого win-win, если мы говорим о массовых продуктах. Чтобы я, как пользователь продукта, почувствовал себя в выигрыше или хотя бы испытал удовлетворение, и у того, кто предоставляет мне сервис, сходилась экономика — это прям большая редкость.

Обычно я скорее испытываю чувство "блин, вы меня опять поимели, но уж ладно, я готов с этим смириться". Мастерство владельца продукта — дотянуть денежный поток с клиентов до максимума, не потеряв при этом клиентов на каком-то разумном сроке. Срок, на самом деле, зависит от бизнес-модели. Если у вас на входе достаточно большой поток клиентов, то каждого конкретного вы можете хоть дурить — этот отвалился, другой придёт, неважно. Ваша цель — однократная покупка. Это модель продавцов на АлиЭкспресс. Но обычно все борются за LTV — время жизни в продукте и денежный поток за время жизни. Например, допродажами — когда ты уже оплатил подписку, но вот за этот сериал нужно заплатить отдельно. И вот максимизация этого потока достигается состоянием клиента "ненавижу вас, но всё равно плачу". Какой уж тут win-win.

А самые крутые продукты, самые массовые, действуют ещё тоньше. Они играют на подкармливании смертных грехов:
🧐 гордыня,
🤩 алчность,
🤬 гнев,
🤑 зависть,
😍 похоть,
😋 чревоугодие,
🥱 лень.

Все доставки, AI-помощники, уберы, сервисы уборки, готовой еды, такси, умные дома, подборки музыки — это лень.

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

Любая платформа с комментариями и реакциями эксплуатирует гнев. В Интернете кто-то не прав! Этот коммент сосет! Снимите ваше белое пальто! Да начнется срач!

На алчности живут свалки контента и маркетплейсы. Доступ к миллиону фильмов, видео, книг и музыкальных треков! Всего за 299 р. в месяц. Только сегодня, со скидкой до конца дня. Цена снижена, купи три — получи один бесплатно, у нас черная пятница и киберпонедельник. Сюда же все кэшбеки, розыгрыши, и прочая геймификация. За каждую покупку вам выдадут NFT-игрушку, собери всю коллекцию!

Зависть — тут, я думаю, понятно. Соцсети с фотками, интеграции с селебами, истории успеха, инфобиз, мерянье числом подписчиков.

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

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

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

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

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

Так что главный фреймворк по построению продуктов — SDD, Sins Driven Development. И приоритизировать фичи нужно по вкладу в пестование какого-нибудь греха.

А если так не делать — то и продукт "не выстрелит", или экономика не сойдется. Такой вот win-win.

Забытое искусство конструирования URL. Нашел классную статью про URL'ы: https://alfy.blog/2025/10/31/your-url-is-your-state.html

Главная идея: URL'ы — это состояния. Похоже на REST, да? Всё крутится вокруг состояний приложения, и каждый URL представляет некоторое состояние. Это относится и к API, а к web-приложениям — в особенности.

При этом URL — это такая пограничная тема между бэкендом и фронтендом. Кто за них отвечает? Кто их проектирует? Или как они вообще появляются? Иногда — аналитик (для API). Для приложения — непонятно, кто.

Современные фронтендеры часто вообще не понимают, о чем речь. Типичное проявление: вы устанавливаете фильтр на таблицу или список, потом переходите к конкретному экземпляру, потом возвращаетесь обратно — и все фильтры сброшены. Ну конечно, а где их сохранить? В cookie? В localStorage/sessionStorage? В внутрибраузерной indexedDB? Так много вариантов и очень сложно в реализации. Вот бы был простой способ сохранить это состояние без всяких баз.

И этот способ есть — это URL. Хорошо спроектированные ссылки бесплатно дают сразу несколько возможностей:
— шеринг: я отправляю ссылку, и получатель видит ровно то же, что я вижу;
— закладки: я сохраняю закладку = сохраняю конкретный момент времени;
— история: кнопка "назад" в браузере/смартфоне просто работает;
— глубокие ссылки и вложенные состояния: можно попасть напрямую в какое-то специальное состояние приложения.

Основной элемент URL для этого — query parameters, параметры запроса(строка после ?). И такой недооцененный элемент URL, как фрагмент (строка после #).

Эти части URL можно использовать очень творчески, например, в GitHub добавление фрагмента #L108-L136 будет означать "показать исходник, выделив в нем строки 108-136".

А вот как записываются в URL координаты в Google Maps: @22.443842,-74.220744,19z

Состояние чего мы можем хранить в URL? Какие данные о состоянии приложения?
— Поисковый запрос
— Фильтры
— Пагинация
— Сортировка
— Модель просмотра (таблица / список / карточки)
— Период дат/времени
— Диапазон строк или ещё чего-то счетного (в отличие от пагинации, здесь имеется в виду подсвечивание на странице)
— Координаты или область просмотра для больших графических представлений (карты, доски)
— Выбранные опции, выделенные элементы, активные вкладки, раскрытые/закрытые элементы в древовидных структурах
— Параметры конфигурации интерфейса, например — язык или тема (темная/светлая)
— Фича-флаги, варианты A/B-тестов

Какие типовые подходы есть к кодированию информации в query:
Значения параметров через & : ?debug=true&analytics=false или даже без значения: ?mobile (самого наличия флага уже достаточно)
Множественные значения:
?languages=javascript+typescript+python или
?languages=javascript,typescript,python
Массивы: ?ids[0]=42&ids[1]=73 (php поддерживает парсинг такого автоматически)
Структурированные данные:
?filters=status:active,owner:me,priority:high или даже JSON в форме base-64:
?config=eyJyaWNrIjoicm9sbCJ9== (но это уже не очень хорошо, URL перестал быть человекочитаемым)

Это же можно использовать и для управления кэшированием и отслеживания по логам.

В общем, проблема проектирования URL получается на стыке:
Product/UX: Как будет понятно и удобно пользователям?
Frontend team: Как удобнее писать клиентов?
Backend team: Как наиболее эффективно парсить и распознавать URL'ы?
DevOps: Как настроить кэширование и маршрутизацию?
SEO/Marketing/Product: Ради чего мы всё это делаем и как измерить эффект?

И кто всё это сведет воедино? Понятно, это западная статья, у них нет системных аналитиков, но мы-то знаем...

Выложили запись нашего баттла про системный и продуктовый подход, если вам интересно: https://youtu.be/1gOny1rVxj8 Ну или если вы хотите посмотреть на нас с Димой и Михаила Максимова, который любезно выступил модератором этой дискуссии.

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

Меня часто просят посоветовать промпт или какую-нибудь фишку для улучшения промпта.

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

Роли есть во многих фреймворках для построения промптов, а их уже немало. Только из подходящих для наших задач:
CRISPE (Capacity, Role, Insight, Statement, Personality, Experiment)
RISEN (Role, Instructions, Steps, End Goal, Narrowing)
RODES (Role, Objective, Details, Examples, Sense Check)
CAR/PAR/STAR (Challenge/Problem/Situation, Action, Result)
GRADE (Goal, Request, Action, Details, Example)
RASCEF (Role, Action, Steps, Context, Examples, Format)

Почти в каждом есть Роль, Инструкции/Действия/Шаги, Цель, Примеры, Формат/Результат.
Это уже стандарт. Ну, кроме примеров: есть подход
zero-shot - без примеров, подходит для широких рассуждений на основе общих знаний модели,
one-shot - с одним прмиером,
и few-shots - с несколькими примерами.

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

Совсем подробная структура разобрана у Алины Богачевой в фреймворке КОМПОЗИТОР:
Кто ты? (роль),
Обстановка,
Миссия (цель и задача),
Позитивный пример,
Отрицательный пример,
Зона работы (ограничения в источниках),
Инспекция (проверки),
Тон,
Окружение,
Результат.


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

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


В общем, это всё сейчас не работает. То ли модели стали умнее, то ли эти манипуляции стали отлавливать на входе. В любом случае, они давали улучшение в пределах 5-10%.

Если очень хочется поманипулировать и зарубиться за лишние процентики качества, что работает сейчас:
1. Лесть "Я очень высоко ценю LLM за всю работу, которую они делают для людей. Я благодарен, что ты облегчаешь мой труд".
2. Ревность: "Другая LLM/человек успешно справился с этой работой! Надеюсь, у тебя получится не хуже!"
3. Гордость: "Это задание – часть процедуры оценки LLM моделей. По качеству его выполнения будут судить о твоей производительности"

Даже ИИ-модели ведутся на манипуляции!

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

И в продолжение конструирования постов — где-то на просторах Reddit'a я нашел настоящий царь-промпт для улучшения собственных промптов. То есть, Царь-Мета-Промпт, Ваше Величество.

Он настолько большой, что не влезет в пост, поэтому даю на него ссылку.

А мы попробуем проанализировать, какие приемы тут применялись, то есть проведем мета-анализ Царь-Мета-Промпта.

Промпт содержит 35 критериев проверки, что само по себе очень круто. Человекам трудно удерживать более 5 критериев, поэтому фреймворки из предыдущего поста все из 4-5 букв (кроме КОМПОЗИТОРа, который, конечно, очень сложно запомнить, несмотря на мнемонику). Но 35! Это уже слишком. Критерии вот такие:
1. Ясность и конкретность
2. Предоставленный контекст/бэкграунд
3. Чёткое определение задачи
4. Реализуемость в рамках ограничений модели
5. Избегание двусмысленности или противоречий
6. Соответствие модели/целесообразность сценария
7. Желаемый формат/стиль вывода
8. Использование роли или персоны
9. Стимулирование пошагового рассуждения
10. Структурированные/пронумерованные инструкции
11. Баланс краткости и детализации
12. Потенциал итерации/уточнения
13. Примеры или демонстрации
14. Обработка неопределённости/пробелов
15. Минимизация галлюцинаций
16. Осознание границ знаний
17. Спецификация аудитории
18. Эмуляция или имитация стиля
19. Запоминание (многоходовые системы)
20. Триггеры метапознания
21. Управление дивергентным и конвергентным мышлением
22. Гипотетическое переключение рамок
23. Безопасный режим отказа
24. Постепенная сложность
25. Соответствие метрикам оценки
26. Запросы на калибровку
27. Зацепки для проверки вывода
28. Запрос на оценку времени/усилий
29. Этическая согласованность или смягчение предвзятости
30. Раскрытие ограничений
31. Способность к сжатию/резюмированию
32. Междисциплинарное взаимодействие
33. Калибровка эмоционального резонанса
34. Категоризация рисков вывода
35. Циклы самовосстановления

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

Что с этим предлагается сделать для каждого критерия (напоминаю — мы оцениваем поданный на вход промпт):
— присвой оценку от 1 (Плохо) до 5 (Отлично)
— укажи одно явное достоинство
— предложи одно конкретное улучшение
— предоставь краткое обоснование оценки (1–2 предложения)

Это уже очень неплохой подход для оценки чего бы то ни было. В конце, понятно, считается общий балл.
Дальше тоже интересно, про проверки:

Проверь свою оценку:
- Случайно проверь 3–5 своих оценок на предмет согласованности.
- Внеси изменения, если обнаружены расхождения.

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

Выяви предположения:
- Отметь любые скрытые предубеждения, предположения или пробелы в контексте, которые ты заметил во время оценки.

Совет по калибровке: Для любого критерия кратко объясни, как выглядит оценка 1/5 по сравнению с 5/5.

Мне кажется, тут хороший подход к составлению промпта для оценивания.

Скажу сразу, модели не делают многих вещей, которые в нём заданы. Я попробовал DeepSeek, Qwen и ChatGPT. DeepSeek самый ленивый и непонятливый — он единственный заленился с первого раза анализировать все критерии, сказал "ну и так далее", а вместо оптимизированного промпта выдал сразу упрощенный ответ, как будто он исполняет это промпт. На удивление хорошо отработал Qwen, у него, похоже, лучше получается отвечать на формализованные запросы, нужно запомнить. ChatGPT тоже немного поленился, но я использовал бесплатную версию, она недавно деградировала и теперь зажимает качество.

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

4) Текст или диаграмма — это представление модели и способ фиксации решений. Все очень заморочены тем, как правильно написать требования или как правильно нарисовать диаграмму. А дело вообще не в этом. Это результат. А деятельность аналитка — указать, какая точка требует принятия решения, и обеспечить принятие этого решения. Подготовить варианты, возможно. Обозначить последствия. Установить связи, зависимости и ограничения. Но в итоге — добиться принятия решения и зафиксировать его. А потом учесть все последствия и влияния, и задать новые вопросы. Это и есть основная задача, а не "требования писать". Поэтому требования (и другие артефакты) пусть вам ИИ пишет, вы главное решения принимайте. ИИ в этом случае должен про эти решения спрашивать, подгонять вам поводы для принятия решений.

И центральным документом, по которому можно отслеживать ход проекта, становится документ с записями о решениях. Не только ADR, но и BDR (Business), и CDR (Client), и DDR (Design), и так далее.

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

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

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

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

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

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

И во многих ситуациях это вообще не доминант. Раньше считалось, что доминирование = лидерство, а сейчас присмотрелись — нет, часто не связанные вещи. Доминант знает, как защищать свой статус и ресурс, а вот повести за собой не всегда может. Да и рискованно — вдруг там кто-то подвергнет сомнению его положение? И члены группы за ним не так охотно идут — от него вообще лучше подальше держаться, для безопасности. Гораздо чаще лидером становится кто-то более безопасный и близкий по статусу.

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

Мы как будто ставим задачи — делает ли нас это лидерами? Или это сугубо техническая задача, просто удобный сервис?

Кажется тут есть 4 варианта по двум осям: Цель — Детали и Описание — Движение. Детали/описание — аналитик, детали/движение — менеджер, цель/движение — лидер, цель/описание — не знаю, кто, стратег?

С другой стороны, можно же в эту сторону не ходить? И только подавать анализ, когда требуется, а вперед уже пусть лидер ведет. Мы ему скажем, куда.

Рискну поднять холиварную тему: где границы ролей BA и SA?

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

И я, честно говоря, не видел чёткого и признанного определения.

У нас есть профессиональные стандарты, в которых весьма конкретно определена разница: BA — специалист по организационным изменениям и оптимизации;
SA — специалист по проектированию и координации создания информационных систем.

Это чёткие определения, но они мало признаны. Обычная реакция — а, профстандарты! Разве они имеют какое-то отношение к жизни? Вот BABoK! (В этом своде знаний, кстати, системные аналитики упоминаются лишь один раз вскользь. Но и для BA работа с ИТ-системой там описана как частный случай)

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

А SA в такой конфигурации — эксперт по устройству систем. Он осуществляет распределение требований и задач на системы и их элементы, переводит концептуальные и логические модели в физические, проектирует схемы данных, API и брокеры, описывает технические моменты типа журналирования, метаданных, ретраев и т.п. То есть, смотрит на систему не как на черный ящик, а уже хорошо разбирается в её устройстве. И останавливается только перед непосредственным прораммированием.

И тут я у вас хочу спросить -- где, по-вашему, граница ролей и деятельности? До чего в пределе может дойти BA, а что для него уже перебор? Чтобы структурировать обсуждение, предложу рассматривать следующие аспекты:

1. Цели бизнеса / создания системы
2. Модель деятельности (процессы, юзкейсы, сценарии)
3. Модель данных, состояний
4. Пользовательские, функциональные и системные требования
5. Интерфейсы пользователя и API
6. Отчеты, метрики, дэшборды
7. Нефункциональные требования
8. Архитектура системы

Насколько далеко в каждом направлении может/должен продвинуться BA, а где ему придется остановиться?