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

Жизнь подкидывает иллюстрации к идеям с учебы. Я на тренинге рассказываю про оценку уровня риска для определения нефункциональных требований: ☹️недовольство пользователей, 🤬критические репутационные потери, 💵некритичная потеря денег, 💲критичная для существования бизнеса потеря денег, ☠️потеря жизни и здоровья человека / многих людей. Сюда же можно добавить отзыв лицензии / приостановку деятельности. И вот — пожар на складе временного хранения "Чердак". Очень сочувствую людям, потерявшим свои вещи — дорогие памятью или стоимостью. Сам был дважды в таком положении: с одного склада мои вещи просто выбросили ("забудь"), а отцовскую квартиру его квартиранты разграбили, выбросив на помойку семейные документы XIX века и архив работ моего прадеда-художника. Так что очень хорошо понимаю всю скорбь. А с точки зрения рисков — ну, вряд ли компания дальше продолжит своё существование, да и весь рынок временного хранения под вопросом. Впрочем, альтернатив особо нет. Риск, конечно, не связан с программным обеспечением, но если системно посмотреть — явно не учтен. На тренинге по информационной безопасности, например, пожарную безопасность тоже учитывают (а нам даже рассказывали про атаку проникновения, когда после поджога вместе с пожарными в офис вошли злоумышленники и утащили несколько корзин с дисками из серверной, уж не знаю, правда или нет). Однако, таких ситуаций, чтобы сбой ПО привел к краху компании, не очень много. Видимо, наши системы всё же не настолько критичны :) Потеря денег — да, катастрофы — ну, может быть, да и те в основном из-за человеческого фактора, но вот чтобы из-за этого организация прекратила своё существование? Я помню только один случай: Knight Capital Group, американская финансовая компания, специализирующаяся на высокочастотной торговле. Причем в пик своего расцвета она одна генерировала 17% объема торгов на Нью-Йоркской бирже и NASDAQ. Но в 1 августа 2012 года на один из восьми торговых серверов забыли раскатить новую версию их программы. А в ней было важное обновление: пересмотрен формат данных. И флаг, которым раньше помечалась выполненная заявка на сделку, был заменен на другой. Старое ПО новый флаг не воспринимало, не считало заявку выполненной, поэтому генерировало их в бесконечном цикле. За 45 минут оно успело выставить 4 миллиона заявок, накупило акций на 7 миллиардов и расфигачило фондовый рынок (цены на некоторые мелкие акции поехали в разные стороны на 70 и более процентов). На продаже ошибочно купленных акций компания потеряла 440 млн. долларов. Впрочем, даже такие деньги были в пределах требований регулятора по объему собственного капитала, так что формально компания могла существовать дальше. Они даже нашли финансирование на покрытие этих расходов. Но доверие было подорвано, акции самой компании критически упали, и через год её продали конкурентам. Вот такие последствия ручного развертывания релизов, неаккуратной политики версионирования форматов сообщений и отсутствия мониторинга бизнес-операций. Кажется, была ещё какая-то крипто-биржа, объявившая себя банкротом из-за бага и атаки, направленной на этот баг. По-моему, они там умудрились куда-то деть 850 тыс. биткоинов. Обратите внимание — в обоих случаях речь идёт о софте, который напрямую манипулирует деньгами, причем в больших объемах. Другие известные сбои, такие как коллапс системы сортировки багажа в аэропорте Хитроу или потеря космических аппаратов из-за программных ошибок — обычно не приводят к закрытию организаций, максимум — кого-нибудь увольняют. Поэтому, наверное, все программные системы до сих пор ещё не обвешены мониторингами со всех сторон и не проходят формальной верификации перед запуском — просто риски низкие.

Вот эти доклады мне очень запомнились. Остальные были уже не такими насыщенными, но я не все смотрел. Интересная мысль была у Алексея Кирпичникова из Контура: при руководстве 80 продуктами и ~2,5 тыс. человек ты, как руководитель, вообще не можешь ни кем конкретно руководить, вот такой парадокс. Ты можешь только устанавливать правила и политики, задавать стандарты и контролировать их внедрение / соблюдение. Тоже, кстати, было в курсе про бюрократию — многие великие правители государств именно с этого начинали — со свода законов и конфигурации управленческих структур. А всё остальное уже потом "само" получается, если правильно организовано.

Про InBetween 2025. Ещё одна экспериментальная джуговская конференция. Про задачи связи стратегии и тактики. Очень бодрое начало, но к концу как будто не хватило заряда. А в первой половине доклады были прямо огненные! В качестве кейноутера выступал Александр Прохоров, автор "Русской модели управления". В принципе, он пересказывал тезисы своей книги, но тут такое дело, что при каждом прочтении что-то новое обнаруживаешь. Я для себя понял, что многие руководители, вдохновляющиеся этой книгой, успешно создают "мобилизационный режим", аврал, стрессовый режим, когда русские люди готовы работать втрое-впятеро эффективнее, сворачивать горы и решать невозможные задачи. Вот только забывают про вторую часть — что между авралами должны быть периоды ленивого застоя. А то люди просто сгорят, знаете ли. Потом я ещё спросил про механику выхода из аврального режима, но сам Прохоров про это не очень хорошо знает, он специалист по авралам 😄 Обещал подумать. Я, впрочем, про себя тоже понял, что я-то больше кризис-менеджер, а в стабильных процессах мне скучно. Я сейчас вообще кайфую от возможности провести один-два мощных интенсива, а потом весь месяц отдыхать. Ну или за невозможные сроки спроектировать и запустить какую-нибудь систему. Впрочем, в рассказе была и новая перспектива: как, собственно, запускать этот авральный режим, когда всё застыло. Ответ — через параллельные управленческие структуры. Про то же говорится и в курсе "История бюрократии", кстати — на примере разных стран и эпох. Ну и сам я, если задуматься, довольно часто работал именно в параллельных структурах, выключенных из устоявшейся системы. Знание, которому не учат в бизнес-школах (ну или мне так не повезло, напишите, если кого-то учили такому). Следующий отличный доклад Ильи Балахнина про стратегические сессии. Доклад вокруг одного слайда — куда только ПК смотрит?! 😂 Много полезных советов про проектирование и ведение стратсессий, я раньше их вел иногда, так что отзывается. Из интересных тезисов: * не жалейте времени на выяснение главного вопроса. Ну иначе результаты будут бесполезны. А в чем главный вопрос (а не острый симптом, например) — это нужно выяснять. * используйте при анализе принцип деления MECE (Mutually Exclusive, Collectively Exhaustive) — так, чтобы предметы и признаки, которые вы делите, не попадали одновременно в разные категории (Mutually Exclusive), и покрывали все возможные варианты (Collectively Exhaustive). Нарушение этого принципа мы достаточно часто наблюдаем — когда часть вариантов пересекается, и из этого пересечения выстраиваются обобщения то в одну, то в другую сторону. * применяйте разные методы анализа проблемы: ** структурный (раскладываем проблему на части, смотрим, из чего она состоит) ** хронологический (раскладываем по времени / последовательности / сезонности, смотрим — что было до, что будет после) ** причинно-следственный (раскладываем по логике: что из чего вытекает, что на что влияет. Дерево текущей реальности Голдратта, Impact Mapping) ** иерархический (раскладываем по важности — что тут самое главное, а что второстепенное, что во что вложено) Вот эти два пункта прямо очень хороши для организации любого структурированного обсуждения, не только для страт.сессий, но и для обсуждения функций / архитектуры продукта, например. * не стройте дорожную карту сразу на сессии. Определите направления, фокус, а план пусть потом специально обученные люди строят в спокойной обстановке. * фиксируйте зоны ответственности по RASCI: кто выполняет задачу (R), кто отвечает за то, чтобы задача была выполнена с должным уровнем качества (A), кто помогает (S), кто консультирует (C), кто должен быть в курсе (I). Тут мы потом немного поговорили про DACI: Driver, Approver, Contributor, Informed. Но supported и consulted тоже интересные роли, можно и так.

Вчера заходил на митап Pimon 2025 — это, знаете, выглядит как полноценная конференция, посвященная ESB и интеграции! Такого, кажется, больше нет. Так что всем, кто занимается выбором, внедрением и настройкой ESB — рекомендую хотя бы записи посмотреть, было интересно, особенно про анализ российских решений. Ну и отдельно приятно, что карту интеграций там раздавали в качестве приза за лучший вопрос. А я получил полезную обратную связь, продолжу улучшать и развивать эту тему. Ну а дальше меня лично (или виртуально) можно будет увидеть на курсах Systems.Education: 25-27 сентября:«Системный анализ + ИИ. Разработка требований и функциональное проектирование систем». Это наш классический курс для систематизации знаний в системном анализе, где мы даем четкую последовательность действий и артефактов. Но сейчас — с помощью ИИ, когда мы можем ускорить анализ (например, выявление бизнес-сущностей из текстов), формирование текстов и диаграмм, и кросс-проверки. В общем, классика на новом уровне в формате интенсивного погружения за 3 дня. Курс-боевик. В очном формате, кстати, довольно редко проводится. А с 29 сентября начинаем экспериментальный онлайн-курс «Микросервисы для системных аналитиков». Без программирования и DevOps, ровно то, что нужно аналитикам. По-сути, это введение в архитектуру: там будет Event Storming, построение архитектурных диаграмм C4 до уровня компонент, практика составления записей архитектурных решений ADR, расчет нагрузки, ну и проектирование интеграций, но уже применительно к микросервисам: основные паттерны, сценарии взаимодействия, описание контрактов в OpenAPI и AsyncAPI (для Rabbit и Kafka). Это будет онлайн по три часа с утра. Ну и 3-4 октября — Flow в Санкт-Петербурге. Там буду делать доклад про логику построения карты интеграций, а точнее даже — про морфологию интеграций: что во всех технологиях в любом случае есть, о чем нужно задуматься и как разные технологии между собой сравнивать.

Говорят, у некоторых не загружается pdf из Github, прикреплю сюда файлом. Ну и напоминаю, что любые предложения, комментарии и идеи с удовольствием принимаю, пишите! По обратной связи уже понятно, что нужно делать инструмент для выбора подходящей технологии, но для этого нужно глубоко разобраться с базой и деталями, из которых каждая технология собрана. Ещё один вариант использования — адаптация карты под свою организацию, нечто вроде техрадара. А что у нас есть? Что мы для чего используем? На какие технологии мы пока смотрим только в экспериментальном режиме, что является стандартом, а что ещё используется, но новых проектов на этом делать не нужно. Сюда же можно добавить шаблон ADR для выбора интеграций и их нюансов — рассматривали вот такие варианты, решили делать так. Но это уже не просто картинка, это какой-то инструмент должен быть. Что думаете, полезно ли было бы?

Вообще я сегодня должен был написать либо про философские доклады с BiasConf, либо про InBetween. Но внезапно я сделал новую версию карты интеграций: https://github.com/yksi12/integrations/blob/main/Integrations%20Tech%201.0.1.pdf Добавил туда JSON-RPC, т.к. он в последнее время стал популярен в связи с MCP — протоколом для взаимодействия LLM с внешними источниками данных и сервисами. Также он используется в блокчейн-проектах (они не на слуху, но вообще-то вполне себе живы и развиваются). На картинке видно, что протокол легковесный: вся линейка почти пустая. Впрочем, карта уже дает предсказательную силу — ну не опишешь ведь RPC ни в OpenAPI, ни в AsyncAPI. Но должен же быть формат для описания спецификаций? Ну вот он и есть: OpenRPC! https://open-rpc.org/ То есть, когда вы сталкиваетесь с какой-то новой для себя технологией или приёмом, можете задать себе всё те же вопросы: — Верхнеуровневый паттерн: это удаленный вызов или обмен сообщениями (надеюсь, общую БД и файловый обмен вы не используете) — Это синхронно или асинхронно? — Какая метафора используется? Какая семантика взаимодействия? Вызов процедуры, CRUD над ресурсами, гипермедиа, запрос данных, извещение, подписка на событие, очередь? У некоторых авторов это называется "интеграционный стиль" — На каком это протоколе? HTTP, HTTP/2, TCP с какой-то своей нашлепкой? И если HTTP, то только как транспорт, или по полной, как в REST? Протокол-то вообще бинарный или текстовый? И вообще, этот метод завязан на конкретный протокол, или может использоваться с разными? — В каком формате передаем данные? Есть ли у этого формата схема? Строгая ли типизация в этом формате? Он плоский, или допускает вложенность? Насколько сложным по структуре может быть ответ? — Если нам нужно преобразование данных, то есть ли штатные средства для этого? — Что с обработкой ошибок? Можно ли определить и возвращать собственные коды ошибок и дополнительную информацию? — Что с безопасностью? Аутентификация и разделение полномочий? Есть ли штатные средства? Или всё ограничивается TLS/SSL и OAuth? — Что с производительностью, скоростью и гарантиями доставки? — В чем мы это будем описывать, какие есть языки спецификаций и инструменты тестирования? Где мы эти спецификации храним и как обеспечиваем их актуальность? И если мы берем какую-то совершенно новую технологию, нужно просто задаться всеми этими вопросами. И мы можем сравнить две технологии — дублируют ли они друг друга? Можно ли использовать на одном проекте RabbitMQ и Kafka? Что выбрать — GraphQL или gRPC? В общем, кажется, схема работает. Про что ещё можно спросить в отношении технологий интеграции, чтобы сравнить их друг с другом?

Сходил на BiasConf от JUG RU Group. Это эксперимент. Заявлена как конференция про философско-методологические и научные основы исследований в бизнесе, но больше было про исследования вообще. Доклады на конференции разбились на два очень далеких друг от друга класса: конкретные рассказы про приемы исследований и доклады про философию. К сожалению, последних было не очень много, но именно на них было больше всего людей! Кажется, люди очень интересуются философскими основаниями своей деятельности! Именно в этом, как мне показалось, на конференции был большой разрыв — связка между очень прикладными вопросами и философскими была утеряна. С другой стороны, почти все доклады были очень качественными, я почти из всех что-то себе записал, что обычно на конференциях редкость. Самый крутой доклад Дмитрия Соловьева и Александра Ветушинского: "Три метода концептуализации: феноменология, герменевтика, диалектика". Концептуализация — это наполнение какого-то понятия смыслом, или отделение одного понятия от другого. Аналитикам это должно быть близко, мы этим всё время по сути занимаемся, когда строим модели данных и деятельности. Что является одинаковым, а что разным, и как обобщить много разных "одинаковых". В докладе собственно основные методы описаны: — феноменология: то, что происходит со мной, и как я это чувствую. Возможно, с обобщением — что вообще происходит с людьми, когда они говорят о каком-то явлении. Отделить феномен от того, кто его воспринимает, невозможно. Можно максимум проанализировать, как разные воспринимающие о нем думают или его ощущают. Это, мне кажется, вообще типовая форма мышления большинства стейкхолдеров: зацепились за какой-то конкретный факт или событие, и про него рассказывают. Особенно почему-то топы так любят делать. Также мы это делаем, когда пытаемся "думать и чувствовать, как пользователь", "проявлять эмпатию". User story, CJM, наблюдение за деятельностью без предварительной установки — это всё феноменологические подходы. Когда в обсуждении человек говорит вам "а у меня не так" — это феноменология. — герменевтика: изучение текстов и — шире — вообще символов. А что по этому поводу написано? Как мы можем интерпретировать этот текст? А как те, кого мы исследуем, интерпретируют этот текст/символ? Что они говорят? Что мы у них спросим? Как наши тексты переплетутся между собой? В каком контексте был создан этот текст и в каком он интерпретируется? В общем, это всё про анализ документов, описаний, формальных моделей (которые тоже не явление само по себе, а его описание). Если вы любите строить и изучать модели бизнес-процессов, UML-диаграммы, а потом ещё и толковать их и обсуждать — вы занимаетесь герменевтикой. Если вы изначально задаете модель какого-то явления, и подгоняете под его структуру наблюдаемую реальность — это герменевтика. Когда человек говорит "а давайте сначала определим это понятие" — это герменевтика. На герменевтику опирается вся современная наука (опишем явление словами/моделями). Забавное замечание в Википедии: Гермес идеально выражает суть герменевтики, так как по верованиями греков он изобрел речь и язык, а также был посредником, переводчиком, вором, обманщиком и трикстером, и уводил души в царство мертвых. — диалектика: изучение противоположностей и развития. Во-первых, в любом явлении есть его противоречие. Если вы его не обнаружили — вы не до конца исследовали предмет. Во-вторых, нужно смотреть на прошлое и будущее, истоки ситуации и её развитие. Кроме того, невозможно рассмотреть явление без связи с другими. Связь, взаимоперетекание, изменчивость и отрицание — это диалектика. Нам это тоже должно быть знакомо — когда мы ищем проблему, которую собираемся решить. Внезапно у меня закончился пост, так что про позитивизм, язык и семиотику придется отдельно написать. Но, как вы наверное поняли, конференция мне в целом понравилась, жаль что мало было именно про философию.

Адаптация под разные поколения — это отдельный анекдот. Ну пятница же, вот вам для веселья: Исходный текст (тоже сгенерированный): Система управления обучением предназначена для организации учебного процесса, предоставления учебных материалов, контроля успеваемости и взаимодействия пользователей внутри образовательной среды. Система должна поддерживать разнообразные типы курсов, адаптироваться под потребности разных категорий обучающихся и обеспечивать удобную навигацию и управление контентом. Адаптированный для бумеров: Система поддержки образовательного процесса создана специально для удобной организации занятий, распространения необходимых учебных пособий, отслеживания успехов учащихся и налаженного общения всех участников учёбы. Она предусматривает широкий выбор различных курсов, легко приспосабливается к потребностям каждого ученика и обеспечивает лёгкое перемещение среди разделов и удобное управление материалами. Заметили разницу? Зачем использовать иностранные слова "учебные материалы", "навигация" и "контент", когда есть замечательные русские "пособия", "перемещение" и, хм, опять "материалы". Для миллениалов (обязательно нужно 90-е упомянуть и журналы! прям песочек посыпался): Система управления обучением — это такая штука, типа школьного дневника на стероидах, который помогает организовать учебный процесс, чтобы никто ничего не потерял и вовремя получил свою порцию знаний. Представьте себе классный портал, где собраны учебники, задания, оценки и даже место для общения преподавателей и студентов. Тут тебе и курсы разные найдутся, и контент удобно разложат, чтобы сразу было понятно, куда идти дальше. Как в девяностых и нулевых годах, когда мы листали журнал, надеясь найти интересную статью или рубрику, здесь тоже всё легко ищется и быстро открывается. Удобно, современно и никаких тетрадок с пометкой «сдать срочно!» 😉 Для зумеров (нужно больше смайликов!): Эта штуковина называется системой управления обучением 💻 Она создана, чтобы сделать твоё обучение классным и удобным! Представь себе место, где собраны все твои учебники, задания и оценки 😎 Ты можешь смотреть курсы, общаться с учителями и одноклассниками, получать обратную связь и даже проходить тесты онлайн! Всё удобно организовано, легко найти нужную инфу и управлять своими успехами ✨ Короче говоря, эта система помогает тебе учиться весело и эффективно 🚀😊 Короче, я понял вот что: 1) Все типовые посты в тг-каналах пишут зумеры. 2) По умолчанию Гигачат пишет в стиле поколения X (это я). Видите, под него не нужно текст адаптировать! Ну как, в каком стиле переписываем все документы? 😆

В Гигачате, тем временем, появился "умный редактор" документов с инструментами ИИ. Функции в нем в основном ориентированы на маркетинговые тексты (переписать понятнее, сделать живее и т.п.), но можно и для спецификаций воспользоваться, т.к. можно вводить промпты вручную. Например, "распиши этот юскейс подробнее" или "составь диаграмму последовательности для этого взаимодействия", "составь диаграмму классов". Пока, к сожалению, он плохо связывает текст с остальным документом, и куски иногда начинают разъезжаться. Но это уже лучше, чем последовательное задавание вопросов и самостоятельная сборка — всё-таки мы документы пишем не в режиме диалога. Как-то так примерно я и представляю рабочее место аналитика в будущем — как оператора и контролера результата работы ИИ, точечно улучшая и переделывая отдельные фрагменты. Что в редакторе есть сейчас: можно переписать, перевести и исправить ошибки. Переписать так: — Выделить главную мысль — Приукрасить текст — Сократить — Написать другими словами — Сделать проще — Расписать подробнее — Поменять стиль (официально-деловой, научный, художественный) — Адаптировать (под бумеров, под зумеров, под миллениалов) Плохо, что этот редактор переписывает текст, то есть заменяет, а не добавляет. Это нам для требований не особенно помогает, но сам подход мне нравится. Я бы сделал так: Переписывание: — Переписать в другом формате (канонические требования, user story, job story, use case) — Расписать по шагам (в формате use case, в формате bdd-сценария) — Проверить читаемость и упростить Добавление: — Добавить детализированные требования — Разбить требования на подсистемы (фронт и бэк) — Добавить описание интерфейса — Добавить верхнеуровневое требование — Добавить описание ошибок и исключительных ситуаций — Добавить описание API — Добавить схему данных Прослеживание: — Проверить соответствие верхнеуровневому требованию — Проверить полноту операций — Проверить соответствие модели данных (и добавить необходимые объекты и поля в модель) — Проверить соответствие интерфейсам и т.д. Проектирование и планирование: — Предложить модель данных — Предложить структуру API — Предложить варианты архитектуры — Предложить этапы работ Параллельно с текстом, где-нибудь сбоку, должна поддерживаться модель данных (с подсветкой объектов и атрибутов, упомянутых в тексте, но не присутствующих в модели); модель интерфейсов — UI/API; глоссарий; контекстная модель с названиями всех упомянутых систем; перечень ролей; матрица зависимостей требований. Все кросс-проверки, понятно, должны выполняться автоматически. В идеале ещё (можно же помечтать?) документ можно оформить в виде перечня задач на изменения, а можно в форме описания "как есть", как новый baseline. А чат пусть будет где-нибудь сбоку, чтобы с ним можно было обсудить какую-то часть или аспект документа. Или попросить вопросы позадавать наводящие, а потом перенести в документ. Вот такой бы редактор я хотел. А то почему у программистов есть всякие там курсоры, а у аналитиков нет специального инструмента?

Сайт InfoQ ежегодно выпускает отчеты по трендам в архитектуре. Вот отчет за 2022, а вот за 2025. Интересно посмотреть, что изменилось за последние 3 года. Забавно, что в отчете за 2022 год нет ничего про ИИ — ну да, ChatGPT вышел только в ноябре, а отчет в апреле. В 2025 LLM уже в разделе "позднее большинство", за три года-то! Революция, как она есть. Зато можно проследить другие технологии. Вот например HTTP/2 и gRPC уже в 2022 были всеми признаны, а GraphQL ещё нет, только к 2025 дополз до признания (хотя GraphQL Federation куда-то делся, а это же чуть ли не самое интересное). HTTP/3 всё ещё в разделе инновации! Про блокчейн забыли, ок. Правда, появились dApps — распределенные приложения на блокчейне. Удивительно, что service mesh, serverless и функциональное программирование в 2022 году были только на уровне раннего большинства: казалось, что они уже давно на слуху, но нет. И только в 2025 стали действительно массовыми. Про платформенную архитектуру тоже вроде бы давно говорят, но нет, в 2025 она всё ещё в разряде "раннее большинство". Удивительная история с ADR, записями архитектурных решений. Тоже, казалось бы, стандартная вещь, но нет — в 2022 только ранние последователи их использовали (в 2025 техника продвинулась на стадию раннего большинства). AsyncAPI в 2025 всё ещё среди ранних последователей! А ощущение, что все уже должны использовать. Но нет. Интересно про новые подходы к архитектуре, помимо навязших в зубах типов архитектур из старых статей и ответов ИИ: — модульный монолит — клеточная архитектура (cell-based) — акторная модель — Darp Вы вообще про что-нибудь из этого слышали? На российских архитектурных конференциях говорят про архитектуру-как-код, про процессы проектирования, архитектурные ката, про коммуникацию со стекхолдерами, governance, в лучшем случае — про платформенную архитектуру. Ну, может через 3-5 лет услышим. Обратите внимание, что никаких микросервисов уже вообще нигде нет, это общее место. Про зеленую архитектуру у нас говорить вообще не принято (а уж тем более считать углеродный след), ESG не в моде. Интересная штука Socio-technical architecture — это как бы "а давайте вспомним, что у нас вокруг систем вообще-то есть люди, которые ими пользуются, их проектируют, программируют, изменяют, поддерживают". Давайте про них тоже подумаем, причем заранее! Удивительно, а ведь системный анализ с этим как раз должен разбираться — выявление и анализ интересов стейкхолдеров. В общем, интересно — о чем говорят и в какую сторону смотрят архитекторы, и куда здесь можно приложить свои силы аналитик (что вырасти самому и поднять свою команду/организацию). Вот, например, с ИИ-агентами, малыми языковыми моделями и RAG ещё есть шансы — они и в мире-то, как мы видим, пока являются инновациями!

Такой день, нужно писать про образование. С образованием системных аналитиков у нас всё плохо. В смысле, всё хорошо с интенсивными практическими программами, ну вы знаете :) А вот фундаментальных нет — бакалавриата или магистратуры по системному анализу или по анализу и проектированию информационных систем вы не найдете. А если найдете — там скорее всего будет программирование с небольшими вкраплениями всего понемногу: немного управления проектами, немного моделирования бизнес-процессов, какая-нибудь "бизнес-аналитика" в виде элементарного введения в анализ данных и статистику + какой-то инструмент построения дэшбордов. В общем, обучают специалистов широчайшего профиля. Но и это ладно бы, проблема в том, что даже в такой программе с большой вероятностью не будет курсов по анализу систем, управлению требованиями и проектированию. Возможно, будет курс по системному анализу, но этот термин давно зарезервирован под совершенно другое направление: там вам будет рассказывать про обратную связь и колебания, многоагентные системы, теорию игр и методы рационального выбора из многих альтернатив, принятие решений и возможно про устойчивость или про сетевые взаимодействия. Пример — книга "Азбука системного мышления" Донеллы Медоуз или курс "Системный анализ и проектирование сложных систем" в Вышке. Это полезно для управленцев, бизнес-консультантов или авторов законопроектов, возможно даже для инженеров по надежности, но аналитик ИТ-систем с этим в своей повседневной работе редко сталкивается. С другой стороны, фундаментально необходимые дисциплины мало где дают. Да что там, для них и названий-то нет на русском языке! Что я считаю практически обязательным: * Логика. На самом деле — Reasoning, умение рассуждать и делать выводы, но это плохо переводится на русский. Ни один академический руководитель не поставит в план дисциплину с названием "Умение рассуждать", так нельзя. Вы что, набрали студентов, которых нужно учить рассуждать? В лучшем случае там будет логика (математическая логика, мы же другой не знаем), или "критическое мышление", или вообще какой-нибудь "дискуссионный клуб". Между тем, это база. Что из чего следует, что из чего не следует, что что опровергает, и т.д. Modus ponens, modus tollens, ex falso quodlibe, вот это всё. Кванторы, признаки, классы. Границы формальной логики, где она пасует и становится бессмысленной. Виды импликаций. Что значит, "из A следует B"? Там ведь штук шесть или даже больше разных вариантов. Модальности: мы знаем, что некое X невозможно. Почему? Логически невозможно, запрещено нормативно, ценностно недопустимо или недоказано, что так можно? Это всё разные модальности. Способы рассуждения: индукция, дедукция, абдукция (кстати, Шерлок Холмс в основном применял именно её, а не дедукцию) * Функциональная грамотность(?). Не знаю, как назвать. На самом деле — Verbal Reasoning. Умение понимать тексты и речь. Практическое применение логики. О чем говорится в тексте? Можно ли из этого текста сделать вывод, что определенное высказывание верно или ложно? Или однозначного вывода сделать нельзя? И какая информация нужна, чтобы его всё же можно было сделать? Говорится ли в тексте об одном предмете / классе / свойстве, или текст перепрыгивает с одного на другое? Если текст — ответ на вопрос, то ответил ли на самом деле респондент на заданный вопрос? * Объектное моделирование данных. Что является частным случаем чего и общим случаем чего? Что является признаком, а что — самостоятельным объектом? Что является частью чего? И могут ли части существовать отдельно? Что будет, если к двум яблокам прибавить три груши? А к ним ещё килограмм творога? * Структурирование информации. Вообще не знаю, в рамках какой дисциплины такому должны учить, но это примерно про то, как представить текст в виде списка или таблицы, и как на основе таблицы построить модель. Возможно, это структурный анализ и моделирование, незаслуженно забытые, но в более широком смысле. Тут опять всё крутится вокруг предыдущих курсов — про выделение признаков, классов, свойств, отношений. Что забыл из обязательного фундаментального?