Мой менти столкнулся с проблемой, которую не знаю, как быстро решить. Возможно, вы тоже с таким встречались. По-английски называется "Игра принеси-мне-камень" (Bring me a rock), прием психологического насилия, когда человек просит принести камень, вы ему приносите, а он говорит — нет, это не такой камень. А какой нужен? Не знаю, ты принеси, посмотрю — скажу.

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

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

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

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

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

Я бы пробовал просто потыкать палочкой все эти места. Это принципиально невозможно, или просто слишком много переделывать? В чем основная сложность? (Тут бы нужно локализовать проблемную зону, ну примените те же методы анализа, то есть рассечения на части, только уже системы. Проблема с фронтом, бэком или базой? Что сложнее всего поменять?). Это будет костыль? Чисто теоретически, можно это сделать костылем? У вас этот компонент самописный или готовый? Это прямо сейчас сложно сделать, или вы про будущую поддержку переживаете? Сколько по времени обойдется, если нормально сделать? А если закостылить?

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

Раз уж я блогер, должен реагировать на хайповые темы. Даже и с запозданием. Ладно, я всё пропустил. Но всё равно, вот вам: группа Angine de Poitrine. Переводится как "Боль за грудиной" или "Стенокардия". Ребята умудрились в эпоху тотального нейрослопа сделать что-то настолько неожиданное, что никакой нейросети с самой высокой температурой не приснится.

По форме это "экспериментальный микротоновый математический рок с элементами костюмированного перформанса". И это меня прямо вернуло на 25 лет назад, когда я активно программировал, и, конечно, делал это под музыку.

Итак, неожиданный пост про фоновую музыку для работы.

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

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

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

Поэтому мой набор для программирования в начале 2000-х был весьма диковат: Сергей Курехин, John Zorn, Les Hurlements d’Leo, Eläkeläiset, саундтрек "Бойцовского клуба", который The Dust Brothers, их последователи The Chemical Brothers и прочий брейк-бит, The Prodigy, Lemon Jelly, Эдуард Артемьев, Skanatra и т.д. Видите какую-нибудь логику? Я вот тоже сначала нет, а теперь понимаю: основное свойство — неожиданность. Неожиданность тут двух типов: музыкальная (необычные размеры, ломанный бит, сваливание чуть ли не в чистый шум — ой, это я ещё про japanoise забыл написать, Merzbow, Masonna, The Gerogerigegege — тоже было!), либо культурная — различные перепевки, каверы и прочая культурная мешанина.

Ну и микротональная музыка Angine de Poitrine из этой же серии — микротоны, это же звуки с интервалами вне европейского равномерно темперированного строя, то есть ноты, которые "между" соседних клавиш на фортепьяно или "внутри" ладов на гитаре (у Khn de Poitrine на грифах гитары вдвое больше ладов, чем обычно). Чаще всего это звучит для нашего уха фальшиво, но тут всё получилось.

Короче, тут чистая математика — нарезка диапазона частот на необычные ноты, и применение странных ритмических размеров, далеких от 4/4: 7/8, 11/8 и т.п. И даже если убрать микротоны, это математический рок, mathrock — рок со странными размерами и их сменой внутри одной композиции. А уж этого мат-рока очень много (особенно почему-то много японского мат-рока, даже с вокалом). И это у меня теперь будет базовой музыкой для фоновой работы, а то всё предыдущее я уже наизусть.

В чем тут фишка? Это всё про дофаминовую стимуляцию. Дофамин — гормон радости ожидания нового. При программировании он и так вырабатывается, потому что ты ждешь, что оно заработает, а оно не работает, а потом как заработало! Выплеск дофамина. Главная фишка для выработки дофамина — неожиданность. Когда результат известен — награды не будет. Когда есть только шанс получить что-то интересное (или ещё более интересное!) — работает дофамин. Этот гормон стимулирует интерес и обучение. Но только в условиях безопасности, иначе он сразу перебивается адреналином! Дофаминовый транс или "состояние потока" заставляет программистов писать лучший код, а аналитиков — лучшие документы. Math-rock с неожиданными и меняющимися ритмами делает мозгу щекотно как раз за счет промахов в ожидании следующей ноты: думал, сейчас будет очередная доля? А нет! Получи выброс дофамина!

Вот такой музыкальный биохакинг.

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

Завтра завершается последний поток трёхмесячного интенсива  Systems Analyst Bootcamp, и можно посетить открытое финальное демо.

Там можно увидеть презентацию команд, оценить результаты и задать вопросы. И присмотреть себе аналитиков, если вам нужны в команду джуны+ / почти миддлы.

Обучались они вот по этой программе.

Порядок проведения демо - по ссылке.

Финальное демо пройдёт в онлайн-формате 6 и 7  мая с 18:00 до 20:00 МСК

Будем рады вашему присутствию!
Запиcываться через @systemseducation

Я тут немного учусь на "настоящего управленца" (бесит это слово, честно говоря), и вот что наблюдаю.

Первое: мы с вами в пузыре. Мы привыкли, что в организациях есть процессное управление, ну или хотя бы представление о процессах. Или, например, есть представление об управлении знаниями (все наши вики и architecture as a code — это оно). Многие в курсе про качество и даже слышали про ISO 9000. То есть, мы с вами чаще всего работаем в компаниях, где всё это есть. Часто ещё и с заимствованными с запада практиками управления и опорой на стандарты. Я имею в виду банки, крупную промышленность, крупный ритейл, интернет-компании — многие из которых изначально создавались иностранцами, как Авито и Ламода. Иногда этот подход проникает даже в образовательные проекты типа Сириуса и Летово.

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

И вот тут второе: что делает руководитель в таких системах? Интересное дело: в основном работает с мотивацией. Потому что в процессах можно поставить KPI и измерять какие-то показатели, оптимизировать шаги. А если у вас управление по поручениям, то ваша основная метрика — своевременное исполнение. Точнее: 1) исполнение в принципе и 2) исполнение в срок. И тут нужно как-то людьми манипулировать, чтобы они всё это делали (а они обычно не хотят, потому что нет смысла — не видно какой-то великой цели, сплошное реагирование и тушение пожаров).

Поэтому такой управленец постоянно изучает: кто же такие его работники и что как они реагируют на разные воздействия. То есть, постоянно их типирует. По разным психологическим и псевдопсихологическим тестам. По Герчикову, Белбину, Адизесу, DISC, MBTI, Big 5, уровень эмоционального интеллекта, стиль решения задач по Алану Роу и т.д. Заодно типирует среду в компании и отслеживает социальные связи: кто, с кем и зачем общается. А также — и вот тут я немного удивился — так же всё время типирует себя.

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

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

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

Знаете ли вы себя и команду?

Вынесу из комментов: я тут нашел хорошую таблицу, связывающую проектное и процессное управление. Это стандарт P3M3, часть PRINCE2.

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

Ну а что: проект — это же просто набор поручений! (Задач).

А процессы — это что-то сложное и непонятно.

А потом, конечно, они спрашивают — а почему это у нас проекты как-то плохо запускаются? А завершаются ещё хуже?..

А потому что ваши проекты опираются на хаотическую деятельность, ad-hoc. Или, того хуже, на героическую. Когда каждый проект вытаскивают отдельные герои, в отсутствие ресурсов и поддержки. Главное, это же очень удобно — зачем налаживать управление, если каждый раз находятся герои, которые и так смогут. Культура постоянного подвига. (Если кому-то пришлось совершить подвиг, значит до этого кто-то другой плохо выполнил свою работу. Всегда!)

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

Обратите также внимание, с какого уровня начинается управление процессами. С 4-го, предпоследнего! До этого ничем управлять невозможно, можно только руководить (в смысле микроменеджмента). А системно оптимизировать процессы можно только на пятом уровне зрелости!

У организации, как у человека, есть зона ближайшего развития. Вы не можете перейти от хаоса к оптимизации*, не пройдя промежуточные шаги! У меня когда-то один студент писал диплом по управлению требованиями, и вывел там ФОРМУЛУ: 5-2=3. Если организация находится на 2 уровне зрелости, и собирается оптимизировать управление требованиями, ей нужно пройти ещё три уровня. По-другому никак!

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

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

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

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

Самый лучший вариант, конечно, на стыке: понимать и в управлении, и в технологии. Это такое же сильное сочетание, как понимание технологии и ИТ, или ИТ и бизнеса.

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

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

1. Первое, что нужно сделать — перепись. Для государства это связано со сбором налогов, а для руководителя организации — с пониманием ресурсов, которыми он располагает. Я наблюдал несколько раз смену руководителей или объединение организаций, и опытные люди всегда начинают с этого. Что мы имеем? Что нам оставил предшественник? Ещё это очень важно, чтобы зафиксировать точку "0" — с чего мы стартуем, и отделить унаследованные косяки от наших собственных. Так что одним из результатов "переписи" должен быть список проблем, уже имеющихся на момент принятия вами руководства.

2. Второе — сохранение и опора на существующую организацию (в курсе — аристократию). Не надо ссориться, нужно встроить имеющихся людей в свою систему. Не свергать князей, а выдавать им ярлыки :)

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

4. Для остальных нужно установить понятные правила игры: что можно, что нельзя, и как решаются конфликты. Где правда? Древнерусские установления так и назывались — Правда. Обычно они отменяли всякую дичь типа кровной мести и вводили более гуманные порядки.

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

6*. Для придания себе дополнительной власти можно опереться на людей и группировки, которым до этого не давали голоса.

Рекомендации макиавеллианские, но это опыт поколений автократов. В демократии всё по-другому, а приведенный рецепт — это как раз инструкция по её демонтажу. Тут думайте сами — где вы и чего хотите.

Рынок как будто начинает оттаивать, вот и митапы для аналитиков снова пошли, что не может не радовать!

Многие думают, что ADR — Architecture Decision Records — это про фиксацию решений. Вообще нет, это, в первую очередь, мощный инструмент для принятия решений.

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

И в ADR есть отличные механики для этого.

Про них почему-то не всегда даже пишут, а это-то самое важное, что там есть. Вот смотрите:

1) Срок действия решения. Это то, что убивает все обсуждения и заставляет их длиться бесконечно. Люди бьются, как будто каждое решение принимается навсегда! Стоит только вбросить волшебную фразу "это только на следующие полгода" — как все затыки и противоречия чудесным образом снимаются. Ну, полгода уж мы как-нибудь потерпим!

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

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

2) Триггеры для пересмотра. Решение может изменяться не по времени, а по значению какой-то метрики. "Это решение действует, пока объем передаваемых данных / частота обращения к API / время обработки сообщения / ... не превысит значение X".

Разумеется, тут нужен механизм, автоматически отслеживающий этот показатель и напоминающий, что нужно бы ADR-то пересмотреть.

3) Обратимость решения. Если решение обратимо без последствий и разумными усилиями — его вообще обсуждать долго не нужно, нужно выбрать какой-то вариант, определить метрики и критерии успеха, и посмотреть, что будет. Если не получилось — вернуться назад. В культуре Amazon ("Day 1") это называется "two-way door": дверь, в которую можно и войти, и выйти. Если пристально посмотреть и создать правильную инфраструктуру, таких решений может быть гораздо больше, чем кажется!

4) Уровень уверенности. Если вы не уверены в решении, это НЕ означает, что его не нужно принимать. Это означает, что оно должно быть обратимым и измеримым. А ещё — записать в явном виде, какой информации нам не хватает для принятия решения, и какие риски мы рассматриваем.

Ещё интересно, когда стоит вообще принимать решение. В последний момент, но не позже! (Last Responsible Moment). Решение, принятое слишком рано, может быть не самым оптимальным, потому что мы ещё многого не знаем. Это как раз связано с информацией из п.4. Ключевые вопросы: нам обязательно принимать это решение сейчас? Что нас заставляет это сделать? Можем ли мы что-то делать уже сейчас, не принимая пока это решение? Что позволит нам принять более взвешенное решение (если мы будем знать что?).

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

Я тут боролся с генерацией ИИ-шкой BPMN-диаграмм, и всё равно сразу генерировать XML очень плохо получается. В итоге я вроде смог объяснить ИИ синтаксис Bpmn-sketch-miner.ai, и теперь он генерирует уже почти без ошибок (ну, иногда вставляет лишние пустые строки).

В итоге, процесс получается такой:
1) Вставляем в промпт текстовое описание бизнес-процесса
2) Сгенерированный код вставляем в Bpmn-sketch-miner.ai
3) Исправляем ошибки, если есть
4) Доделываем до нужного нам результата
5) Экспортируем в формат bpmn,
6) Вставляем в Camund'у или ваш любимый редактор процессов, растаскиваем элементы, чтобы визуально было красиво.

Конечно, не то чтобы идеальный результат получается — визуально так и вообще кривоватый — но для набросков сойдет, не зря же он sketch называется. Для обсуждения процессов можно и не перегружать в "настоящий" редактор, можно и картинки из Bpmn-sketch-miner показывать, ещё и править их сразу на ходу.

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

Промпт здесь: https://raw.githubusercontent.com/yksi12/prompts/refs/heads/main/bpmn-sketch-prompt.md

Или совсем другой подход к моделированию: встроим редактор BPMN прямо в выдачу!

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

И теперь мы можем генерировать такую же красивую и интерактивную документацию на любую тему.

А в случае BPMN мы можем сгенерировать не только диаграмму, но и страницу со встроенным редактором.

Как мы знаем, в выдаче LLM могут быть мелкие недочеты, которые проще поправить руками, чем убедить переделать ИИ. Поэтому строим такой воркфлоу: ИИ делает диаграмму, показывает нам сразу в редакторе и с кнопкой "Сохранить". Мы немного меняет диаграмму, как нам нужно, и сохраняем в файл .bpmn

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

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

Запрос при этом используется самый примитивный:

Опиши процесс согласования документов в крупной организации, организованной иерархически (управления, отделы, руководители и т.п.). Результат представь в виде модели бизнес-процесса в BPMN, размещенного на html-странице. Используй библиотеку bpmn.js

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

Главная магия — "Используй библиотеку bpmn.js". Вы знаете, сколько этих библиотек для js уже сделано? Хоть для моделирования бизнес-процессов, хоть для анимации, хоть для визуализации, хоть для 3D. Перспективы открываются ошеломительные.

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

А вот в лице LLM мы находим благодарного читателя. Он читает быстро, и ему не лень перелопатить десяток сценариев. А польза несомненна — например, интерфейсы и клиентов на основе сценариев ИИ генерирует замечательно. В принципе, на основе сценариев много что можно создать — и структуру API, и модель данных, и для разбивки на микросервисы они очень помогают: отлично работают, как формализация Event Storming, и дальше удобно анализировать по ним потоки данных, границы сервисов и нагрузку.

Писать самому сценарии тоже не нужно, пусть машина пишет, а мы поправим. И тут возникает ещё одна вещь, никогда ранее никем не виданная: fully dressed use case. У Коберна описана структура полного описания юскейса, примерно страницы на две. Мы же обычно в практике ограничиваемся коротким набором:
* Код
* Название
* Действующие лица
* Предусловия
* Триггер
* Постусловия
* Шаги основного сценария
* Альтернативы / Исключения / Расширения

А можно ещё так много дописать! Вот смотрите, что у Коберна:
* Действующие лица разделены на Главное действующее лицо и Второстепенных действующих лиц
* Есть область действия (Scope): проект и система
* Уровень (от бизнес-юскейса до взаимодействия модулей)
* Стейкхолдеры и их интересы: кому нужен этот юскейс и в чем их интерес?
* Минимальные гарантии: даже если юскейс не будет выполнен, что гарантируется? (в каком состоянии будет система)
* Гарантии при успехе (отдельно)
* Соответствие бизнес-правилам (ссылки на бизнес-правила)
* Используемые технологии и форматы данных, их варианты
* Приоритет
* Целевой релиз
* Частота использования
* Ожидаемое время отклика / время выполнения
* Каналы взаимодействия для главного действующего лица / второстепенных действующих лиц
* Открытые вопросы

А вот что ещё можно добавить:
* Автор
* Источник
* Статус
* Версия
* Дата последнего изменения
* Уровень архитектуры
* Требования безопасности
* Требования локализации / i18n
* Требования к доступности (WCAG / ГОСТ Р 52872-2019)
* Масштабируемость: число конкурирующих запросов
* Нефункциональные требования (прочие)
* Спецификация данных (словарь) для хранения / ввода / вывода
* Интерфейсные решения / прототипы интерфейсов
* Допущения и предположения
* Ссылки на связанные требования
* Рекомендации по тестированию

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

А вот машине всё равно — она и написать не затруднится, и прочитать не поленится. А самое главное — она же для себя пишет, и действительно может использовать всё написанное. А другая машина может проконтролировать, и тут чем детальнее описано, тем проще проконтролировать. На месте Коберна я бы сейчас активно продвигал какой-нибудь фреймворк для AI SDD на основе юскейсов.

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

Написал в 2025 году книгу про связь User Story, Use Cases и User Story Maps. То, что я много раз рассказывал на тренингах, но в книгу не оформил, да даже и на конференциях ни разу не рассказывал, думал, это слишком просто. А вот нет, нужно говорить и писать! Впрочем, приятно чувствовать себя на одной волне с великими.

Что он пишет:

User Story — значимое для пользователя изменение в системе (показатель прогресса), что-то, что пользователь может увидеть и пощупать.

Use Case — перечисление способов, которыми пользователь может достичь своей цели (или не достичь).

Story map — раскладка карточек, где слева направо идёт процесс, а сверху вниз — приоритеты.

Основные принципы:
1. Глаголы подразумевают продолжительное действие
2. Раскладывайте глаголы на более короткие (по продолжительности действия) глаголы
3. Управляйте точностью (precision — тут правильный перевод ближе к "сфокусированности", "кучности")
4. Раскладывайте (декомпозируйте) всё, не только глаголы
5. Пишите документы вместе, разработка + бизнес
6. Пишите с точки зрения пользователей
7. Пишите только потребности, а не энциклопедию всего
8. Жертвуйте совершенством ради читаемости

Принципы декомпозиции:

Для use cases: до уровня целей взаимодействия пользователя с системой (имеющих смысл, даже если системы нет, система — это просто один из вариантов реализации), в метафоре Коберна — до "уровня моря"

Для User story — хоть до "уровня моллюсков", то есть почти бесконечно.

Use case поставляет полное описание способов работы с системой, поэтому из него нарезаются единицы прироста пользы — user story. Каждая история представляет собой срез юскейса (slice).

Story map объединяет user stories и use cases: верхняя строка — это успешные шаги одного большого сценария, который обеспечивает вся система (и одновременно — названия юскейсов более низкого уровня). Карточки в колонке — срезы юскейсов, варианты данных / каналов / интерфейсов, обработка ошибок.

Вот такое мнение гуру.

А в 2026 году он уже успел выпустить ещё одну книгу: "Упрощая проектирование программных продуктов: гениальность бюрократии".

Говорит, архитектура программных систем должна строиться на двух принципах матерых бюрократов:

* "Это не моя задача"
* "Мне это не нужно знать"

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

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

Кусочек из продуктового управления. Для описания сути продуктов используются разные формулы. Часто можно услышать формулу: "Мы верим, что..."

1. Мы верим, что [наше убеждение о мире, людях или индустрии].
2. Поэтому мы создаем [наш продукт, услуга или решение].
3. Чтобы помочь [указание на целевую аудиторию] [конкретная польза или изменение в жизни клиента].

Пример:

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

Но эта формула апеллирует к вере, что ставит нас немного в слабую позицию, а наших критиков заставляет играть роль Станиславского: "верю/не верю".

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

1. Нас бесит, что [распространенная несправедливость, обман или глупость на рынке].
2. Вместо этого должно быть [как выглядит идеальный, честный или удобный мир].
3. Поэтому мы сделали [наш продукт или услугу], где все именно так.

«Нас бесит, что в онлайн-курсах только записанные видео и тесты.
Вместо этого всё обучение должно происходить через практику.
Поэтому мы сделали курс, в котором 70% времени занимает практическая работа и разбор результатов»

Если вдуматься, в точности подходит ко всем успешным продуктам:

«Нас бесит, что и Интернете ничего не найти. Вместо этого должна быть одна страница, на которой есть все ответы. Поэтому мы сделали страницу, где можно ввести запрос и мгновенно получить ответ на любой вопрос» (тут, кстати, сразу понятно, почему ИИ убивает поиск — у них формула продукта одинаковая).

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

«Нас бесит, что чтобы посмотреть фильм вечером нужно идти в магазин и покупать/арендовать DVD. Вместо этого должна быть возможность посмотреть любой фильм через интернет. Поэтому мы сделали онлайн-стриминг»

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

«Нас бесит, что для доставки груза в космос используются одноразовые ракеты и это стоит дофига денег. Вместо этого разгонные ступени должны использоваться много раз. Поэтому мы сделали такое, что наш основатель стал первым в истории долларовым триллионером».

В общем, продукт должен радикально что-то менять, и это что-то должно быть всем ненавистно. Прикиньте к своим продуктам, что вас, как авторов, бесит?

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

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

В общем, не делайте ватных продуктов, радикализируйте свою формулу.

Удивительно, но я оказывается не писал здесь про 6D's фреймворк: 6 'Ds' цифровизации. То есть, что нам цифровизация вообще дает? Это аналитический фреймворк Питера Диамандиса, показывающий, что происходит с вещами и процессами при цифровизации. Если мы говорим не просто об автоматизации какой-то деятельности, а о её цифровизации, по фреймворку можно проследить — что будет происходить дальше, если мы в какой-то процесс пустили цифру.

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

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

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

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

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

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

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