Системный сдвиг

При подготовке курса по инструментам ИИ для системных аналитиков в очередной раз задумался — а какова, всё-таки, роль человека при общении с ИИ? И вспомнил модель SECI by Nonaka & Takeuchi из области управления знаниями. Модель про явное и неявное знание. Tacit и Explicit. И четыре перехода: Неявное → Явное (артикуляция) Явное → Явное (рекомбинация) Явное → Неявное (интернализация) Неявное → Неявное (социализация) Это всё про процессы обмена и обогащения знаний среди людей. И где тут ИИ? Мне кажется, генеративный ИИ — отличный инструмент для работы в области артикуляции и рекомбинации. Вы получаете некий ответ от модели и сравниваете его со своими знаниями. Если знания оформлены явно — можно автоматизировать контроль: что вы сказали модели, то она и должна сделать. Но все знания не могут быть явными. Поэтому возникают ситуации "ах ты глупый чат, всё ты не так сделал!". Это последствия свободных рамок, не заданных ограничений в промпте. Всё, про что явным образом не было сказано, как делать, будет сделано как-то. Как получилось. Как делало большинство тех, чьи результаты сформировали обучающую выборку. И тут вы видите, что всё не так. Ну или что-то не так. Может быть, вы об этом и не думали заранее. Вы даже предположить не могли, что так можно. Ну это же "очевидно"! Например, что в названиях эндпоинтов API нужно использовать существительные. Это RESTful, ну камон. При этом, если сказать в явном виде — опирайся на принципы REST, на выходе получим что? Правильно, HATEOAS, это же самый главный принцип! Ну, "это же очевидно", что мы с HATEOAS не будем упарываться, нам бы немного похожее на REST API сделать, и хватит. То есть, каждый раз, когда ИИ выдает "что-то не то", это "не то", скорее всего, относится к неявным знаниям, к тому, что вы не задали модели в промпте — скорее всего, потому что это вам кажется "очевидным", зачем об этом думать-то отдельно? И когда вы жалуетесь, что "этот ИИ какую-то ерунду пишет" — скорее всего, его вывод не соответствует вашим неявным ожиданиям. Поэтому цикл работы с участием человека выглядит так: постановка задачи (явная) → рассмотрение результата и сравнение его с неявными знаниями → их артикуляция и фиксация в промпте. Выдача ИИ превращается в стимульный материал для экстериоризации неявных знаний. Я уже собирался нарисовать соответствующую картинку, когда нашел ровно такую же статью годовой давности. Умные люди пишут не посты в малоизвестный канал, а статьи в рецензируемые журналы. В общем, статья Human-AI-Collaboration SECI Model: The Knowledge Management Model of the Experts’ Tacit Knowledges with Augmented LLM-Based AI от авторов Akashi Matsumoto, Ryu Nishikawa & Chikako Morimoto (опять японцы, да?) https://doi.org/10.1007/978-981-97-6469-3_12 Они вводят модель HAC-SECI: Human-AI-Collaboration SECI и два цикла: цикл развития агента и цикл развития человека. В цикле развития человек проявляет свои знания в процессе оценивания ответа агента, а в цикле развития агента человек передает агенту в явном виде то, что понял и осознал при оценивании. Через некоторое время такого взаимного обучения, со складыванием новых выявленных правил в хранилище и подключение его как RAG, ответы агента начинают гораздо лучше удовлетворять человека. Фактически, постепенно создается его цифровая копия. Что при этом происходит с самими человеком, исследование не раскрывает.

Или совсем другой подход к моделированию: встроим редактор BPMN прямо в выдачу! Вообще одной из фишек последнего времени является генерация ответа в виде html-файла. В самом деле, на что нам это красноглазие с копированием какого-то кода из одного окна в другое. Ведь даже swagger нужен лишь для того, чтобы сформировать красивую интерактивную документацию API. И теперь мы можем генерировать такую же красивую и интерактивную документацию на любую тему. А в случае BPMN мы можем сгенерировать не только диаграмму, но и страницу со встроенным редактором. Как мы знаем, в выдаче LLM могут быть мелкие недочеты, которые проще поправить руками, чем убедить переделать ИИ. Поэтому строим такой воркфлоу: ИИ делает диаграмму, показывает нам сразу в редакторе и с кнопкой "Сохранить". Мы немного меняет диаграмму, как нам нужно, и сохраняем в файл .bpmn Возможно, так и будут выглядеть интерфейсы будущего (по заветам Джефа Раскина), когда редактор генерируется сразу под формат редактируемых данных. Причем, что удивительно, качество кода самой диаграммы становится лучше — возможно, это связано с внутренней проверкой кода, а может, просьба сгенерировать код активирует какие-то слои нейросети, позволяющие лучше работать и с файлами XML. Запрос при этом используется самый примитивный:

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

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

Я тут боролся с генерацией ИИ-шкой 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

Многие думают, что 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 задает хорошую структуру для обсуждения и принятия решения. Если у вас к совещанию будут подготовлены варианты с описанием почему нам нужно принять это решение (драйвер), почему именно сейчас, что мы не можем сделать без этого решения, какие альтернативы мы рассмотрели, какие у них есть преимущества и недостатки, на какой срок / до каких условий мы принимаем это решение, обратимое ли оно (и какие усилия нужно будет предпринять для отката) — ваше обсуждение пройдет гораздо более эффективно.

Приглашаем на третий System Analysis Meetup SberHealth ❤️ Когда: 20 мая в 18:30 Где: онлайн На митапе поговорим о навыках и подходах, которые помогают расти системным аналитикам. Через доклады и реальные примеры рассмотрим, как создавать новые решения в работе, развивать архитектурное мышление и растить техническую экспертизу ⭐️ В программе: 🟣Ирина Облецова, старший системный аналитик, поделится, как разработала своё решение для оформления требований к мобильной разработке — диаграмму на стыке Figma и блок-схемы 🟣Мария Горгоц, старший системный аналитик, расскажет, что стоит знать аналитику, чтобы подружиться с архитектурными решениями и расти в архитектуре Приглашённый спикер: 🟡Виктория Кухтяева, эксперт по системному анализу и котикам, поделится, какие знания по кибербезопасности нужны для уверенной работы с разработкой и архитектурой, а также как закладывать требования безопасности в решения 🆕Круглый стол Обсудим, как системному аналитику перейти в архитекторы: реальные истории, рабочие практики и нужные навыки 🔜 Регистрация на митап и подробности

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

Ещё один пост про руководителей и лидов. Конечно, хочется написать именно для руководителей аналитиков, но тут первичны навыки управления, а процесс зачастую вторичен. Вся специфика бизнес- и системного анализа заключается в поиске верного места для этой функции в общей логике создания ПО. Зачем мы это делаем? Для чего мы нужны? Какую ценность мы приносим? Что без нас будет работать хуже? А вот принципы руководства не очень сильно зависят от функции и сути деятельности, которой ты руководишь. Поэтому профессиональные управленцы довольно легко могут переходить из одной предметной области в другую, особенно если им хватает ума не залезать в конкретную технологию работы и не пытаться в ней что-то менять. Самый лучший вариант, конечно, на стыке: понимать и в управлении, и в технологии. Это такое же сильное сочетание, как понимание технологии и ИТ, или ИТ и бизнеса. Но я хотел написать про чистое управление. Я наконец дослушал курс "История бюрократии", и кое-что из него извлек. (Стоит заметить, что курс про государственное управление, и это, конечно, не то же самое, что управление организацией. Но это ещё одна метафора — организация, как государство. Кроме того, нужно учитывать, что государства у нас практически всегда начинают с персонального управления, это тоже накладывает определенную оптику). Итак, что мы можем полезного извлечь из уроков гос.управления (что прослеживается во многих государствах и системах): 1. Первое, что нужно сделать — перепись. Для государства это связано со сбором налогов, а для руководителя организации — с пониманием ресурсов, которыми он располагает. Я наблюдал несколько раз смену руководителей или объединение организаций, и опытные люди всегда начинают с этого. Что мы имеем? Что нам оставил предшественник? Ещё это очень важно, чтобы зафиксировать точку "0" — с чего мы стартуем, и отделить унаследованные косяки от наших собственных. Так что одним из результатов "переписи" должен быть список проблем, уже имеющихся на момент принятия вами руководства. 2. Второе — сохранение и опора на существующую организацию (в курсе — аристократию). Не надо ссориться, нужно встроить имеющихся людей в свою систему. Не свергать князей, а выдавать им ярлыки :) 3. Но если вы хотите что-то всерьез поменять — стройте параллельные управленческие структуры из новых людей. Какие-нибудь временные комитеты, комиссии, советы; отлично тут работают проекты. Главное — выдернуть людей из существующей структуры и наделить чрезвычайными полномочиями, лучше всего — максимально неопределенными!. Я работал на многих проектах в кризисе, и это то, что всегда делают антикризисные менеджеры — создают параллельные структуры со специальными полномочиями и подотчетностью первому лицу (или вообще совету директоров). Часто приводят с собой варягов, не связанных с организацией. В общем, преторианская гвардия и чиновники особых поручений. 4. Для остальных нужно установить понятные правила игры: что можно, что нельзя, и как решаются конфликты. Где правда? Древнерусские установления так и назывались — Правда. Обычно они отменяли всякую дичь типа кровной мести и вводили более гуманные порядки. 5. Люди, которых вы привлекаете, должны быть лично обязаны вам и зависеть от вашего успеха. Опять же, тут отлично подходят проекты (а процессы наоборот вредят). Если у вас есть процесс или функция, не дай б-г, владелец этого процесса — это как поместная аристократия, наделенная землей. Сядет на этот процесс или ресурс, и будет вести себя, как его хозяин. А если у вас постоянно временные проекты, и основные деньги исходят из оплаты этих проектов — проектами владеете вы, и можете рулить этим по своему усмотрению — начинать проекты, останавливать проекты, привлекать людей к проектам (или не привлекать, пусть сидят на голой зарплате). 6*. Для придания себе дополнительной власти можно опереться на людей и группировки, которым до этого не давали голоса. Рекомендации макиавеллианские, но это опыт поколений автократов. В демократии всё по-другому, а приведенный рецепт — это как раз инструкция по её демонтажу. Тут думайте сами — где вы и чего хотите.

Здесь мог быть остроумный кликбейт Но не будем тратить время. Приглашаем на последний поток программы Интеграция и архитектура систем для аналитиков, которую проведет Андрей Бураков (ex-NextWay). Кому полезно: • Хотите перейти в архитектуру, но задачи на работе не дают развиваться • Изучили кучу материалов про архитектуру и паттерны, но в голове осталась каша • Ищите работу, но пугают System Design секции Чему научитесь: • Осознанно использовать технологии интеграции: Message Brokers, REST, RPC, WebSockets, GraphQL • Выбирать подходящие хранилища данных (микро)сервисов: реляционные, NoSQL, NewSQL • Уместно использовать архитектурные паттерны, для обеспечения производительности, масштабируемости, отказоустойчивости систем • Разберетесь в инфраструктуре для деплоя и управления сервисами в промышленных средах: Docker, Kubernetes, Service Mesh 📆 13 мая — 21 июня, каждую среду и воскресенье 🔗 Смотрите подробности и регистрируйтесь на сайте Реклама. ИП Бураков Андрей Олегович ИНН 632133429581

Вынесу из комментов: я тут нашел хорошую таблицу, связывающую проектное и процессное управление. Это стандарт P3M3, часть PRINCE2. Почему-то многие считают, что проектное управление предшествует процессному. Продолжая предыдущий пост, зачастую организации пытаются перейти к проектному управлению от управления по поручениям. Ну а что: проект — это же просто набор поручений! (Задач). А процессы — это что-то сложное и непонятно. А потом, конечно, они спрашивают — а почему это у нас проекты как-то плохо запускаются? А завершаются ещё хуже?.. А потому что ваши проекты опираются на хаотическую деятельность, ad-hoc. Или, того хуже, на героическую. Когда каждый проект вытаскивают отдельные герои, в отсутствие ресурсов и поддержки. Главное, это же очень удобно — зачем налаживать управление, если каждый раз находятся герои, которые и так смогут. Культура постоянного подвига. (Если кому-то пришлось совершить подвиг, значит до этого кто-то другой плохо выполнил свою работу. Всегда!) Я тут критиковал процессный подход, но в случае проектной деятельности именно установленные процессы должны стать опорой для проектов. Нет процессов = нет стабильной и предсказуемой проектной деятельности. Если вы читали PMBoK — там исключительно процессы описываются, это стандарт в процессной логике. Обратите также внимание, с какого уровня начинается управление процессами. С 4-го, предпоследнего! До этого ничем управлять невозможно, можно только руководить (в смысле микроменеджмента). А системно оптимизировать процессы можно только на пятом уровне зрелости! У организации, как у человека, есть зона ближайшего развития. Вы не можете перейти от хаоса к оптимизации*, не пройдя промежуточные шаги! У меня когда-то один студент писал диплом по управлению требованиями, и вывел там ФОРМУЛУ: 5-2=3. Если организация находится на 2 уровне зрелости, и собирается оптимизировать управление требованиями, ей нужно пройти ещё три уровня. По-другому никак! Поэтому, пожалуйста, будьте осторожны со словом "оптимизировать", учитывайте промежуточные состояния. Возможно, сначала вам нужно будет разобраться с такими словами, как "определить", "внедрить" и "измерить". * впрочем, есть теория хаоса и понятие странных аттракторов, но это совсем другая математика (и картина мира) и другой способ управления. И ещё одна метафора организации, кстати.

Я тут немного учусь на "настоящего управленца" (бесит это слово, честно говоря), и вот что наблюдаю. Первое: мы с вами в пузыре. Мы привыкли, что в организациях есть процессное управление, ну или хотя бы представление о процессах. Или, например, есть представление об управлении знаниями (все наши вики и architecture as a code — это оно). Многие в курсе про качество и даже слышали про ISO 9000. То есть, мы с вами чаще всего работаем в компаниях, где всё это есть. Часто ещё и с заимствованными с запада практиками управления и опорой на стандарты. Я имею в виду банки, крупную промышленность, крупный ритейл, интернет-компании — многие из которых изначально создавались иностранцами, как Авито и Ламода. Иногда этот подход проникает даже в образовательные проекты типа Сириуса и Летово. Но масса организаций работают безо всяких процессов или проектов, а управление осуществляется путем поручений. То есть, работник сидит и ждет, когда ему что-то поручат делать. Поручили — делает, не поручили — сидит дальше. И выполняет не конкретный процесс, а поручение руководителя. Основной деятельностью в такой системе является получение поручений и документов сверху и расписывание их на исполнителей. Ну и контроль потом. Но много где нет и этого, а поручения выдаются устно, слабо контролируются, а процесс исполнения даже типовых поручений придумывается каждый раз заново. И вот тут второе: что делает руководитель в таких системах? Интересное дело: в основном работает с мотивацией. Потому что в процессах можно поставить KPI и измерять какие-то показатели, оптимизировать шаги. А если у вас управление по поручениям, то ваша основная метрика — своевременное исполнение. Точнее: 1) исполнение в принципе и 2) исполнение в срок. И тут нужно как-то людьми манипулировать, чтобы они всё это делали (а они обычно не хотят, потому что нет смысла — не видно какой-то великой цели, сплошное реагирование и тушение пожаров). Поэтому такой управленец постоянно изучает: кто же такие его работники и что как они реагируют на разные воздействия. То есть, постоянно их типирует. По разным психологическим и псевдопсихологическим тестам. По Герчикову, Белбину, Адизесу, DISC, MBTI, Big 5, уровень эмоционального интеллекта, стиль решения задач по Алану Роу и т.д. Заодно типирует среду в компании и отслеживает социальные связи: кто, с кем и зачем общается. А также — и вот тут я немного удивился — так же всё время типирует себя. То есть, получается, что человек знает очень много о себе: как он принимает решения, на что реагирует, в чем имеет сильные стороны, а где слаб. И то же самое знает про своих сотрудников и про своих контрагентов (или про своих руководителей). И, соответственно, умеет подобрать правильные подходы ко всем и в любой ситуации. Я писал про тетраграмматон Кулакова — это же та же схема: типирование + рекомендации лидеру, что делать (вставать в уравновешивающую позицию — если у вас в команде сплошные тролли и эльфы, вам нужно действовать, как гном, и строить продажи). Один мой знакомый постоянно именно этим занимается, причем тратит довольно большие деньги на серьезные коммерческие тесты (тестирует себя) и даже сертифицировался для проведения диагностики (чтобы исследовать свою команду), потом загоняет эту информацию в ИИ, вместе с описанием коллег и руководителей, и гоняет в ИИ до посинения сценарии развития событий, диалогов, реакций на возможные действия. Я немного скептически относился к такому развлечению, но, послушав с десяток действующих руководителей разных организаций — впрочем, в основном образовательных — уже стал думать, что что-то в этом есть. То есть, если вы руководитель или лид команды, вы должны постоянно этим заниматься — досконально знать себя, своих людей, окружающих людей, среду в вашей команде, среду в организации, и всё это постоянно учитывать (а часто ещё и менять). А не "выстраивать процессы", как часто говорят. Знаете ли вы себя и команду?

Ещё из актуального: в отличие от некоторых школ, которые считают нормальным в конце года просто оповестить смской учащихся и педагогов о закрытии одним днем и отправить всех в комиссию по банкротству в Делавэре, Systems.Education доводит все дела до конца. Завтра завершается последний поток трёхмесячного интенсива  Systems Analyst Bootcamp, и можно посетить открытое финальное демо. Там можно увидеть презентацию команд, оценить результаты и задать вопросы. И присмотреть себе аналитиков, если вам нужны в команду джуны+ / почти миддлы. Обучались они вот по этой программе. Порядок проведения демо - по ссылке. Финальное демо пройдёт в онлайн-формате 6 и 7  мая с 18:00 до 20:00 МСК Будем рады вашему присутствию! Запиcываться через @systemseducation

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

Мой менти столкнулся с проблемой, которую не знаю, как быстро решить. Возможно, вы тоже с таким встречались. По-английски называется "Игра принеси-мне-камень" (Bring me a rock), прием психологического насилия, когда человек просит принести камень, вы ему приносите, а он говорит — нет, это не такой камень. А какой нужен? Не знаю, ты принеси, посмотрю — скажу. Раньше в такую игру любили поиграть заказчики — "ой, ну тут что-то не то... а что не то, мы не знаем..." — но теперь мы столкнулись с игрой со стороны разработчиков. Выглядит так: ну, вы тут напридумывали, здорово, но мы так сделать не можем. Давайте как-нибудь по-другому. А как по-другому? Не знаем, вы же с пользователями общаетесь. Так мы точно не сможем сделать. Принесите камень, который нам подойдет. Есть множество статей на эту тему, с общим посылом: это игра, в которой единственный способ выиграть — не играть вообще. К сожалению, мы не можем выйти из игры и перестать работать с этой командой (ну, или можем — выход есть всегда, в том числе из компании). Остается что: 1) пытаться договориться с разработчиками и 2) эскалировать на руководителя. Эскалация сработает, если у вас в принципе выстроен механизм медиации, если руководители уделяют внимание психологической обстановке, пресекают буллинг и работают с установками работников. Вариант "договориться" — это если разработчики готовы договариваться. Исходим из того, что у всех нас одна общая цель, нет конкуренции между аналитиками и разработчиками, нет каких-то политических игр и подстав. Тут может быть всякое — аналитики и разработчики могут вообще подчиняться разным руководителям (я видел варианты, что даже разным C-level: аналитики — директору по технологиям, а разработчики — техническому, и их конкуренция транслируется до рядовых исполнителей), аналитики могут постоянно меняться и команде не понравился конкретный аналитик и т.д. Тут проблема не техническая, но парадоксальным образом иногда решение оптимальнее искать вне координат проблемы: если проблема политическая, то решение должно быть техническим, и наоборот. Это вообще полезное правило — неразрешимое противоречие в одной системе координат нужно решать в другом измерении. Допустим, у всех одна искренняя цель, но сделать мы так не можем. А как можем, мы сами не знаем. Тут нужно заметить, что фраза "мы так сделать не можем" очень часто означает "мы так делать не хотим, потому что..." и вот тут возможны варианты: * сделать можно, очень много переделывать, но на задачу отведено мало времени и есть риск что-то упустить * сделать можно, но это будет очередной костыль (архитектура уже давно не соответствует потребностям бизнеса, но времени и ресурсов на рефакторинг так же давно не выделялись) * сделать можно, но придется отказаться от готового компонента (и нести в дальнейшем риски и тратить ресурсы на развитие) * сделать можно, но это выглядит, как ультра-локальное изменение и частный случай, который больше нигде и никогда не получится использовать * сделать можно, но очевидное решение будет сильно нагружать бэк/фронт, или будет слишком медленным. Возможно, тут чисто математическая сложность. Всё это можно "вскрыть", если действовать осторожно и не идти на конфликт. И если разработчики готовы говорить откровенно, а не ты дурак, ничего не понимаешь, мы так и думали, аналитики бесполезны. Я бы пробовал просто потыкать палочкой все эти места. Это принципиально невозможно, или просто слишком много переделывать? В чем основная сложность? (Тут бы нужно локализовать проблемную зону, ну примените те же методы анализа, то есть рассечения на части, только уже системы. Проблема с фронтом, бэком или базой? Что сложнее всего поменять?). Это будет костыль? Чисто теоретически, можно это сделать костылем? У вас этот компонент самописный или готовый? Это прямо сейчас сложно сделать, или вы про будущую поддержку переживаете? Сколько по времени обойдется, если нормально сделать? А если закостылить? Ну и рассчитывал бы на сессию совместного проектирования. А вот цикл "вот вам постановка - мы так не можем" обычно ни к чему хорошему не приводит, только к выгоранию аналитика.

Для лидов-аналитиков контента почему-то мало, попробую разбавить. Будет пост для лидов. Основная забота лидов — конечно, отслеживать производительность. Одновременно поддерживать командный дух и вообще хорошее самочувствие (well-being). Для разработчиков есть много фреймворков для оценки и производительности, и самочувствия, и других факторов. Есть DORA, SPACE, DevEx, а самый новый, 2025 года, объединивший их все — DX Core 4 Я (с помощью ИИ) попробовал адаптировать DX Core 4 для системных аналитиков. Вот что получилось. Фреймворк состоит из четырех блоков: 1. Скорость 2. Эффективность 3. Качество 4. Влияние Скорость Главная метрика: производительность, объем поставок — сколько аналитических артефактов передается разработчикам в неделю / месяц (смотря какие у вас характерные скорости). Это общая метрика на подразделения / гильдии, ни в коем случае не персональная! Вторичные метрики: - Скорость прохождения требований: Сколько времени в среднем проходит от постановки задачи до передачи итогового артефакта разработчикам. Так как задачи бывают очень разного объема и их сложно сравнивать, тут можно ввести категоризацию по масштабу (но не сильно сложную, . - Скорость согласования требований со стейкхолдерами (среднее время полного цикла согласования) - Воспринимаемая скорость поставки (оценочно, как аналитикам кажется: быстро они сдают свои артефакты?) Эффективность Главная метрика комплексная: AXI, Analyst Experience Index, Индекс опыта аналитика Собираем индивидуальные оценки удовлетворенности от каждого аналитика по шкале от "Совершенно не удовлетворен" до "Вполне удовлетворен" Компоненты AXI: - Доступ к стейкхолдерам и экспертам предметной области - Качество имеющейся документации - Инструменты моделирования и анализа - Процессы ревью требований - Взаимодействие с другими командами и ролями - Ясность целей и задач бизнеса - Наличие времени на глубокую проработку (против контекстных переключений) - Процессы управления изменением требований - Доступ к данным для анализа Дополнительные метрики: - Время до 10-го сданного артефакта (для новых аналитиков) - Легкость сбора требований (субъективная) - Частота ухода ценных аналитиков из организации / команды Качество Ключевая метрика: уровень дефектов требований. Доля требований, потребовавших дополнительных уточнений или переделывания после передачи в разработку. Вторичные метрики: - Доля пропущенных требований (обнаруженных уже в процессе разработки/тестирования) - Удовлетворенность стейкхолдеров взаимодействием с аналитиками - Доля переделок в коде из-за ошибок анализа - Актуальность документации / архитектурных схем и т.п. Влияние (Импакт) Главная метрика: Доля времени, потраченная на принципиально новые функции (в отличии от времени на некоторое улучшение существующих функций или отработки дефектов) Дополнительные метрики: - Среднее соотношение времени на анализ и на разработку для одной единицы функциональности (пользовательской истории, фичи) - Ценность для бизнеса в пересчете на аналитика (очень сложно посчитать, тут если только вы считаете ROI конкретной фичи) - Соотношение выпущенных фичей (если у вас бывает, что аналитик работает "в стол") Как это применять: ну, в идеале, должна быть триангуляция, то есть получение объективных данных (из систем), субъективных (опросных), и взгляда с другой стороны (стейкхолдеры, разработчики). На практике можно для начала провести опрос, чтобы понять базовые значения, с которых стартуем. Вот ссылка на заготовку для опросов. Главное, нужно следовать нескольким правилам: 1. Это не оценка людей, это оценка процессов 2. Чинить нужно одну вещь за один раз (за квартал, например) 3. Метрики работают только вместе (чтобы не ухудшать одну метрику за счет других) Вот такой инструмент, как вам? Я бы с большим интересом поговорил про опыт внедрения!

Ещё одна метафора — организация, как ролевая игра. У Моргана такой нет, в 1986 это было не очень развито. Впрочем, и сейчас это не такая распространенная метафора, хотя в проектном бизнесе она очень продуктивна! В конце концов, каждый проект — это как рейд в игре! Метафора ведь хороша чем — она сразу задает понимание, что есть в мире, и что с чем связано. Вот в ролевых играх на основе фэнтези есть расы — каждая со своими способностями и ценностями, есть классы (маг, воин и т.п.), есть какая-то типовая механика (например, собирается рейд на какого-нибудь монстра). Такую метафору организации когда-то подробно расписал Алексей Кулаков (JetStyle, Ridero). Вот краткий пересказ: сотрудников компании обычно можно отнести к трем фэнтезийным расам — гномы, эльфы и тролли. У них разные этические системы (понимание того, что хорошо) и взгляд на мир. 👴 Гномы на все смотрят, как на ресурс, из которого можно получить золото. Соответственно, хорошо умеют выстраивать из ресурсов механизмы для зарабатывания этого золота. Работники в этом смысле тоже попадают в категорию ресурсов. И разговоры гномы всегда ведут о ресурсах, о потоках (золота) и об их контроле. Про это же все решения гномов. Самое ценное для гнома — больше ресурсов и контроля. Соответственно, его можно убедить, предложив контроль/ресурс или напугав возможной потерей ресурсов. Самое страшное преступление для гнома — воровство и растрата ресурсов. Стиль управления — директивный, ресурсы должны делать, что им сказали. 🧝‍♀️Эльфы — про любовь и хорошие отношения. Эльфы строят отношения, создают атмосферу, гасят конфликты, ведут переговоры, занимаются дипломатией, выяснением, как помочь, как сделать лучше и т.п., чтобы всем было хорошо. [У Леши это не написано, но я думаю, бывают и темные эльфы, которые искусно плетут интриги, манипулируют чувствами и мастерски стравливают людей друг с другом]. Стиль принятия решений эльфов ужасен: это консенсус. Пока все не договорятся, дальше не двинемся. Эти разговоры могут продолжаться многими часами. Основная идея эльфа — сотрудники должны работать добровольно. Если не работают — нужно с ними поговорить. При этом эльфы не могут образовывать команды и ужасно ревнивы. Главные грехи для эльфа — измена и дезертирство. Ты что, не любишь нашу команду?! Третья раса, распространенная в ИТ — 🧌тролли. Если гномы — про ресурсы, эльфы — про отношения, то тролли — про истину. Троллей интересует, как устроен мир на самом деле. И они до этого докопаются, а потом расскажут в самый неподходящий момент. При этом им вообще безразличны и чувства окружающих, и гномские потоки денег. Если кто-то где-то неправ или о чем-то не знает — нужно ему срочно об этом рассказать! [Я думаю, что троллей должно быть особенно много среди системных аналитиков и архитекторов]. Главная цель тролля — революция. Всё должно быть перестроено, потому что всё не так! Стиль управления троллей — доказательства. Мы будем делать так, потому что это правильно. Вот примеры из литературы, вот данные, вот факты. Самые страшные грехи — сокрытие/искажение правды и неприятие фактов. Все три этики конфликтуют между собой, но все они нужны организации, иначе наступает дисфункция. А кроме ролей есть ещё функции (классы): маги, жрецы и воины. 🔰Маги всегда хотят сделать что-нибудь новое, первыми и таким способом, которым никто не делал. Или убедиться, что так сделать невозможно. Практическое применение и тем более деньги их не интересует, только приоритет. Для магов главное — эксперимент. 🧘‍♂️ Жрецы рассказывают людям, кто они, зачем они вместе и ради чего работают. И какие соратники им нужны, а какие нет. Главное для жрецов — миссия. 🦾 Воины отвечают за захват внешнего мира в самом широком смысле. Новые продажи, новые продукты, новые рынки. Воин готов терпеть боль, свою и чужую. Обычно это продавцы 😁 В компании нужны все расы и все классы. Они балансируют друг-друга. Когда маги зарубаются с воинами, нужен жрец, который им напомнит, зачем мы все здесь. Когда тролли подкидывают  идею магам, нужен гном, чтобы сделать на этом деньги. Как вам метафора? Встречали этих персонажей на работе?

Извините, будет пост про бизнес-анализ, а не системный. Причем бизнес-анализ именно в смысле организационного консультирования, а не сбора требований к информационной системе. Ну, какими проектами занимаюсь, про то и пишу. Сейчас вот так. И что хочу сказать: очень большое упущение в образовании бизнес-аналитиков — практически полное игнорирование теорий менеджмента! Если мы посмотрим на BABoK, он не основан ни на какой теории, это просто сборник некоторых практик "из полей". Взять, хотя бы, модель организации. Есть такая книга, аж 1986 года, "Образы организаций" канадского профессора Гэрета Моргана. Он говорит, что любая модель организации следует какой-то метафоре, и приводит их 8: 1. Машина, механизм, состоящий из соединенных деталей. 2. Организм, пытающийся выживать и адаптироваться к меняющейся окружающей среде. 3. Мозг, постоянно получающий и обрабатывающий информацию, принимающий решения. 4. Культура, общество в миниатюре. Со своими суб-культурами, ценностями, нормами, верованиями, ритуалами. 5. Политическая система. Организация — это игра, борьба разных акторов за влияние и власть. 6. Психическая тюрьма. Организация — это набор мифов и историй, ограничивающих мысли, идеи и действия людей. 7. Инструмент доминирования. Организации нужны, чтобы подавлять и эксплуатировать людей. 8. Непрерывный поток трансформаций. Организация постоянно должна находиться в поиске и постоянно меняться в ответ на вызовы. А теперь думаем: как аналитики, мы с какой метафорой работаем? Важно, что это не _типология_ организаций, а метафоры — как мы смотрим. Это значит, что на каждую организацию можно посмотреть через любую оптику. У вас гибкая обучающаяся бирюзовая организация? Или ваш миф настолько силен, что это уже выглядит, как секта? Мы думаем, что мы работаем с внедрением автоматизированных систем. Но на самом деле мы работаем с _изменениями_. Системы не было, система появилась. Это изменение. Оно меняет: - способ осуществления деятельности, структуру механизма организации (очевидно) - возможности организации к адаптации (то, что делали руками, можно быстро поменять, а вот то, что зашито в программную систему...) - распределение мест хранения и способов распространения информации - соответственно, распределение власти. Та информация, которую раньше я раздавал порционно и в нужном мне ключе, теперь доступна всем. Ой-ой, я потерял рычаг манипуляций. И какие-то там итшники, у которых и бизнес-целей нет, стали вдруг очень важны — ведь без них ничего не будет работать. - культуру. У нас была культура взаимных одолжений, а теперь в вашей системе нужно всё делать в срок и одинаково для всех. Нарастает отчуждение, разрушаются неформальные связи. Или наоборот, возникают тайные практики противодействия и фальсификации данных. - ограничения. Ура, мы теперь можем ограничивать сотрудников так, как раньше и подумать не могли! - гибкость. У нас не было никаких процессов, мы были супер-гибкими, каждый проект могли делать индивидуально. А в вашей системе нужно делать всё одинаково, слишком узкие рамки. Мне кажется, мы чаще всего смотрим из метафоры машины, где вся деятельность выглядит, как набор бизнес-процессов, а шаги бизнес-процесса всегда выполняются четко, в рамках регламента, и, в общем, неважно кем — лучше бы роботами, конечно. В связи с этим вопрос: какая метафора лучше всего подходит, если мы собираемся внедрять в организацию ИИ? Или, того хуже, перестраивать организацию по принципу AI-first?

Вдогонку к предыдущему посту: у многих аналитиков техника Event Storming вызывает... ну, почти что отторжение, а между тем это же всё очень похоже на юскейсы. Вот смотрите: 🟧 События — это предусловия, постусловия и триггеры. (И тут как раз мы уходим от любимого всеми триггера "Пользователь нажал на кнопку" — это не событие предметной области!). Почему предусловия и постусловия — это события? Потому что событие в ES — это что-то, что случилось в прошлом и уже неизменно. То есть, вообще говоря, это состояния каких-то объектов предметной области, или в терминах ES — агрегатов. В этом смысле поток событий можно и как диаграмму состояний трактовать. Когда мы изучаем юскейсы, я всем советую составлять отдельный перечень всех событий, собирая их из предусловий/постусловий. Кто хоть раз составлял такой перечень и отслеживал его актуальность? А в штурме событий он занимает центральное место! 🟦 Команды — это шаги юскейса или целиком юскейсы, смотря на каком уровне мы смотрим. Тут, кстати, тоже снимается вопрос, который часто возникает при проектировании сценария юскейса: прерывание выполнения. Юскейс — это цель, которой пользователь может добиться за один сеанс работы с системой. Может ли он посреди этого сеанса встать и уйти? Или наоборот, должен ли ждать завершения выполнения какого-то действия? В случае юскейсов обычно этим пренебрегают, т.к. число юскейсов начинает кратно расти. А ES заставляет задуматься о каждом переходе между действиями (командами) — он синхронный или асинхронный? Достигли ли мы какого-то состояния, в котором можем находиться сколь угодно долго, или это состояние должно сброситься через определенное время? Это связано и со stateful/stateless — следим мы за состоянием или нет. REST предлагает за состоянием не следить, то есть мы можем положить товар в корзину, а потом через день положить другой, и это норм. Но это значит, что у нас нет юскейса "сформировать корзину", есть только "добавить товар в корзину" и "оформить заказ", и это разные кейсы. (Кейса "сформировать корзину" нет ещё и потому, что нет такого события "корзина сформирована") Интересно, что в обратную сторону это не работает — шаги юскейса могут быть не командами, а инвариантами-проверками внутри 🟨 агрегата (вот эти вот шаги "система убеждается") или 🟩 моделью чтения ("система отображает"). А 🟪 полиси — это либо триггеры, либо точки ответвления для альтернативных сценариев. Тут получается, что ES диктует размещение бизнес-логики в разных местах: внутри агрегатов (инварианты) — то, чего никогда не должно случиться (предотвращение событий), и в полиси — как реагировать на то, что уже случилось (реакция на события). Акторы, они везде акторы. Остаются только UI, но это тоже понятно — мы и в юскейсах можем спросить, на каком экране происходит этот шаг сценария и как это выглядит. Так что ES — это те же юскейсы, только записанные необычным образом и с указанием объектов данных (агрегатов). Но! В моделировании юскейсов нет инструментов для выявления ограниченных контекстов и поддоменов. Ну вот как вы будете выявлять их? Через CRUD над объектами? Через что? Нет механизма. В Use Cases 2.0 (и 3.0) появляются слайсы, но это скорее элемент управления работами. Если методика ещё получит развитие, где-нибудь в Use Cases 4.0 или 5.0 увидим что-то для выделения контекстов.

⚡️Чем занимается аналитик и как получить оффер в 2026 году? Переживаете, что рынок труда нестабилен? Хотите ворваться в аналитику, но не знаете как гарантировать себе трудоустройство? Переживания уйдут, если вы будете уверены в правильности своих действий, в своих компетенциях, резюме и портфолио. Приглашаем на бесплатный вебинар, где Андрон Алексанян - эксперт в области аналитики и CEO Simulative — в прямом эфире разберет все важные аспекты в работе аналитика, а также расскажет как получить оффер быстрее других. Кстати на вебинаре разберут и то как стать аналитиком в 30/40/50 и более лет. На вебинаре будет: 🟠Разберем полный роадмап: что учить, в каком порядке, до какого уровня; 🟠Структура хорошего портфолио с примерами; 🟠Что говорят реальные наниматели - какие у них сейчас требования: — Покажем реальные примеры, как оформить резюме и портфолио, чтобы привлекать внимание; — Обсудим какие отклики работают, а какие сразу отправляют в корзину; — Изнанка найма: инсайдерский взгляд на процессы отбора 💬 Регистрируйтесь и получите бесплатно урок по основам Excel из нашего платного курса, этот урок поможет освоить работу с данными на базовом уровне! 😶Зарегистрироваться на бесплатный вебинар

Вы удивитесь, но статья Raccoon, L.B.S. (1995) The Chaos Model and the Chaos Life Cycle, ACM SIGSOFT Software Engineering Notes, 20, 1 из первоапрельского поста на самом деле существует! Про неё даже в Википедии написано. L.B.S. — это сокращение от Laughing But Serious, по-русски что-то вроде "смех смехом, но серьезно"). Raccoon, я думаю, понятно. Так вот что пишет этот енот: каждая строка кода соответствует всему проекту. Поэтому методика скорее не про хаос, а про фракталы, т.к. на каждом уровне повторяется один и тот же цикл работ. У нас есть 4 уровня: * вся система, * отдельный компонент архитектуры, * отдельная функция * отдельная строка кода. Все уровни связаны между собой. Смежные уровни влияют друг на друга очень сильно, отдаленные — слабо. Но тут как раз и возникает связь с теорией хаоса в математическом смысле, когда минимальные изменения (одна строка кода) приводят к принципиально разным — и непредсказуемым — результатам в макро-масштабе. То есть система находится в очень далеком от стабильного состоянии. Собственно, стабилизация системы на каждом уровне — это и есть конечная цель. Линейные модели, согласно автору, рассматривают систему, как стабильную, до возникновения новой задачи. После успешной реализации задачи (пройдя стадии определения проблемы, разработки решения и интеграции его в существующую систему) достигается новое стабильное состояние. В хаотической модели система ни в какой момент не находится в стабильном состоянии, а стадии фрактально отражаются на каждом уровне. В линейной модели сначала вы определяете проблему на уровне всей системы ("собираете требования"), потом "декомпозируете" её на более низкие уровни, дожидаетесь решения и проверяете его. В хаотической — определяете проблему на уровне системы, декомпозируете на низкие уровни, сталкиваетесь там с новыми проблемами, определяете их (вероятно, уже не в терминах требований, а в большей степени в виде сочетания требований и ограничений), пытаетесь решать, переходите на более низкий уровень, сталкиваетесь там с новыми проблемами, и так далее, вплоть до отдельной строки кода. А потом в обратную сторону — реализовать, проверить, интегрировать, проверить систему после интеграции. Разработчик при этом находится между двух огней, они как раз видны на картинке: внешние требования к системе (требования пользователей и ограничения) сверху и возможности архитектуры/инструментов снизу. И вот где-то между ними, в попытке придумать решение с учетом и того, и другого, и находится большая часть работы. При этом, как отмечает автор, для такой работы нет инструментов. Нижний уровень описывается интерфейсами библиотек и классов, верхний — сценариями использования, UI и внешними API. Их связка не описывается и не моделируется ничем (на 1995 год). 30 лет спустя мы называем это "архитектурой приложений" и "дизайном системы", но сильно легче, честно говоря, не стало. Интересно, что разработчик идёт в эту историю один, без сопровождения. Аналитик может проработать определение проблемы на верхнем уровне, выявить проблемы, с которыми столкнется пользователь или смежная системы. А вот с какими проблемами столкнется разработчик, пытаясь это реализовать внутри, аналитик обычно даже не представляет. Но разработчику придется делать то же самое — анализировать требования и ограничения, вырабатывать решение, реализовывать и проверять его. Поэтому разработчики часто скептически смотрят на аналитиков — ну да, мы это всё каждый день делаем, только не называем громкими словами. А ещё у нас всё детерминировано, хорошо бы на входе тоже все было определено, а не эти непонятные люди, которые сами не знают, чего хотят. Ну и поэтому решение всегда влияет на дизайн, причем очень часто заранее непредсказуемым образом — ведь о проблемах и ограничениях низкого уровня мы узнаем, только когда начнем пытаться это делать. И влияние движется не только сверху вниз, но и снизу вверх — ограничения решения могут заставить пользователей перестроить свою деятельность. Впрочем, неожиданные возможности тоже — риски бывают и положительными.