Раз уж я блогер, должен реагировать на хайповые темы. Даже и с запозданием. Ладно, я всё пропустил. Но всё равно, вот вам: группа 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. Перспективы открываются ошеломительные.