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

Но у JUG Ru Group осенью будет ещё несколько отличных конференций. (У Джугов вообще все конференции отличные, но в основном для программистов, для меня слишком глубоко). А вот на какие две я лично собираюсь, кроме Flow:

InBetween — про оперативное управление. У нас не так много конференций для менеджеров, а искусству управлять толком нигде не учат и мало где обсуждают. Каждый учится на практике, набивая себе шишки и пересчитывая новые седые волосы. Поэтому новая конференция про управление давно уже напрашивалась, как площадка для обсуждений. Очень рассчитываю на умение JUG Ru собирать классных спикеров и поднимать актуальные темы!

Кстати, онлайн-часть уже прошла и можно посмотреть доклады в записи (после регистрации). Уровень дискуссий повыше, чем в среднем на обычных конференциях! Ну и моё почтение за выбор названия — это же явная отсылка к австралийскому сериалу Mr. Inbetween, да?.. да?.. На русский его перевели как "Решала". Про эксперта в оперативном и тактическом управлении, так сказать.

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

Обе конференции пройдут в Москве, InBetween — 8 сентября (когда же ещё обсуждать управление, как не в понедельник); BiasConf — 6 сентября (в субботу самое правильное поговорить о философии).

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

* Не опечатка! Отсылка к старинному текстовому мему "я джва года хочу эту игру [в которой можно грабить корованы]"

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

Была такая отдельная роль — проектировщик интерфейсов, результатом работы которой был прототип, который потом отдавали дизайнеру для отрисовки в Фотошопе.

Например, об этом упоминается в статье про анализ вакансий (2013, и её продолжение через 10 лет — проектировщики интерфейсов и умение создавать прототипы исчезли полностью), а в этой статье Ярослава Перевалова (2012)  разбирается, какие роли участвуют в процессе дизайна и как они взаимодействуют (там вообще отдельно проектировщик, дизайнер и юзабилити-специалист, бизнес-аналитик и системный аналитик).

Потом появилась Figma, и финальный дизайн стало рисовать очень просто (когда у тебя есть подготовленные компоненты) и быстро. И предварительные мокапы оказались не нужны. А вместе с ними и процессы анализа и проектирования.

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

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

Ничего не напоминает? Да это же ситуация с вайб-кодингом! Сначала будем невероятно быстро писать код, а потом долго и скрупулезно исследовать — что же там не так работает и как исправить? Как это там называется, vibe coding cleanup specialist, да?

Такой день, нужно писать про образование.

С образованием системных аналитиков у нас всё плохо. В смысле, всё хорошо с интенсивными практическими программами, ну вы знаете :)

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

В общем, обучают специалистов широчайшего профиля.

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

С другой стороны, фундаментально необходимые дисциплины мало где дают. Да что там, для них и названий-то нет на русском языке! Что я считаю практически обязательным:

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

* Функциональная грамотность(?). Не знаю, как назвать. На самом деле — Verbal Reasoning. Умение понимать тексты и речь. Практическое применение логики. О чем говорится в тексте? Можно ли из этого текста сделать вывод, что определенное высказывание верно или ложно? Или однозначного вывода сделать нельзя? И какая информация нужна, чтобы его всё же можно было сделать? Говорится ли в тексте об одном предмете / классе / свойстве, или текст перепрыгивает с одного на другое? Если текст — ответ на вопрос, то ответил ли на самом деле респондент на заданный вопрос?

* Объектное моделирование данных. Что является частным случаем чего и общим случаем чего? Что является признаком, а что — самостоятельным объектом? Что является частью чего? И могут ли части существовать отдельно? Что будет, если к двум яблокам прибавить три груши? А к ним ещё килограмм творога?

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

Что забыл из обязательного фундаментального?

В Гигачате, тем временем, появился "умный редактор" документов с инструментами ИИ.

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

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

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

Что в редакторе есть сейчас: можно переписать, перевести и исправить ошибки. Переписать так:
— Выделить главную мысль
— Приукрасить текст
— Сократить
— Написать другими словами
— Сделать проще
— Расписать подробнее
— Поменять стиль (официально-деловой, научный, художественный)
— Адаптировать (под бумеров, под зумеров, под миллениалов)

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

Это нам для требований не особенно помогает, но сам подход мне нравится. Я бы сделал так:
Переписывание:
— Переписать в другом формате (канонические требования, user story, job story, use case)
— Расписать по шагам (в формате use case, в формате bdd-сценария)
— Проверить читаемость и упростить

Добавление:
— Добавить детализированные требования
— Разбить требования на подсистемы (фронт и бэк)
— Добавить описание интерфейса
— Добавить верхнеуровневое требование
— Добавить описание ошибок и исключительных ситуаций
— Добавить описание API
— Добавить схему данных

Прослеживание:
— Проверить соответствие верхнеуровневому требованию
— Проверить полноту операций
— Проверить соответствие модели данных (и добавить необходимые объекты и поля в модель)
— Проверить соответствие интерфейсам
и т.д.

Проектирование и планирование:
— Предложить модель данных
— Предложить структуру API
— Предложить варианты архитектуры
— Предложить этапы работ

Параллельно с текстом, где-нибудь сбоку, должна поддерживаться модель данных (с подсветкой объектов и атрибутов, упомянутых в тексте, но не присутствующих в модели); модель интерфейсов — UI/API; глоссарий; контекстная модель с названиями всех упомянутых систем; перечень ролей; матрица зависимостей требований. Все кросс-проверки, понятно, должны выполняться автоматически.

В идеале ещё (можно же помечтать?) документ можно оформить в виде перечня задач на изменения, а можно в форме описания "как есть", как новый baseline.

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

Вот такой бы редактор я хотел. А то почему у программистов есть всякие там курсоры, а у аналитиков нет специального инструмента?

Адаптация под разные поколения — это отдельный анекдот. Ну пятница же, вот вам для веселья:

Исходный текст (тоже сгенерированный):

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

Адаптированный для бумеров:

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

Заметили разницу? Зачем использовать иностранные слова "учебные материалы", "навигация" и "контент", когда есть замечательные русские "пособия", "перемещение" и, хм, опять "материалы".

Для миллениалов (обязательно нужно 90-е упомянуть и журналы! прям песочек посыпался):

Система управления обучением — это такая штука, типа школьного дневника на стероидах, который помогает организовать учебный процесс, чтобы никто ничего не потерял и вовремя получил свою порцию знаний. Представьте себе классный портал, где собраны учебники, задания, оценки и даже место для общения преподавателей и студентов. Тут тебе и курсы разные найдутся, и контент удобно разложат, чтобы сразу было понятно, куда идти дальше. Как в девяностых и нулевых годах, когда мы листали журнал, надеясь найти интересную статью или рубрику, здесь тоже всё легко ищется и быстро открывается. Удобно, современно и никаких тетрадок с пометкой «сдать срочно!» 😉

Для зумеров (нужно больше смайликов!):

Эта штуковина называется системой управления обучением 💻 Она создана, чтобы сделать твоё обучение классным и удобным! Представь себе место, где собраны все твои учебники, задания и оценки 😎 Ты можешь смотреть курсы, общаться с учителями и одноклассниками, получать обратную связь и даже проходить тесты онлайн! Всё удобно организовано, легко найти нужную инфу и управлять своими успехами ✨ Короче говоря, эта система помогает тебе учиться весело и эффективно 🚀😊

Короче, я понял вот что:
1) Все типовые посты в тг-каналах пишут зумеры.
2) По умолчанию Гигачат пишет в стиле поколения X (это я). Видите, под него не нужно текст адаптировать!

Ну как, в каком стиле переписываем все документы? 😆

Сходил на BiasConf от JUG RU Group. Это эксперимент. Заявлена как конференция про философско-методологические и научные основы исследований в бизнесе, но больше было про исследования вообще.

Доклады на конференции разбились на два очень далеких друг от друга класса: конкретные рассказы про приемы исследований и доклады про философию.

К сожалению, последних было не очень много, но именно на них было больше всего людей!

Кажется, люди очень интересуются философскими основаниями своей деятельности!

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

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

В докладе собственно основные методы описаны:
— феноменология: то, что происходит со мной, и как я это чувствую. Возможно, с обобщением — что вообще происходит с людьми, когда они говорят о каком-то явлении. Отделить феномен от того, кто его воспринимает, невозможно. Можно максимум проанализировать, как разные воспринимающие о нем думают или его ощущают. Это, мне кажется, вообще типовая форма мышления большинства стейкхолдеров: зацепились за какой-то конкретный факт или событие, и про него рассказывают. Особенно почему-то топы так любят делать. Также мы это делаем, когда пытаемся "думать и чувствовать, как пользователь", "проявлять эмпатию". User story, CJM, наблюдение за деятельностью без предварительной установки — это всё феноменологические подходы. Когда в обсуждении человек говорит вам "а у меня не так" — это феноменология.

— герменевтика: изучение текстов и — шире — вообще символов. А что по этому поводу написано? Как мы можем интерпретировать этот текст? А как те, кого мы исследуем, интерпретируют этот текст/символ? Что они говорят? Что мы у них спросим? Как наши тексты переплетутся между собой? В каком контексте был создан этот текст и в каком он интерпретируется? В общем, это всё про анализ документов, описаний, формальных моделей (которые тоже не явление само по себе, а его описание). Если вы любите строить и изучать модели бизнес-процессов, UML-диаграммы, а потом ещё и толковать их и обсуждать — вы занимаетесь герменевтикой. Если вы изначально задаете модель какого-то явления, и подгоняете под его структуру наблюдаемую реальность — это герменевтика. Когда человек говорит "а давайте сначала определим это понятие" — это герменевтика. На герменевтику опирается вся современная наука (опишем явление словами/моделями). Забавное замечание в Википедии: Гермес идеально выражает суть герменевтики, так как по верованиями греков он изобрел речь и язык, а также был посредником, переводчиком, вором, обманщиком и трикстером, и уводил души в царство мертвых.

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

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

Вообще я сегодня должен был написать либо про философские доклады с 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?

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

Говорят, у некоторых не загружается pdf из Github, прикреплю сюда файлом.

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

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

Ещё один вариант использования — адаптация карты под свою организацию, нечто вроде техрадара. А что у нас есть? Что мы для чего используем? На какие технологии мы пока смотрим только в экспериментальном режиме, что является стандартом, а что ещё используется, но новых проектов на этом делать не нужно.

Сюда же можно добавить шаблон ADR для выбора интеграций и их нюансов — рассматривали вот такие варианты, решили делать так.

Но это уже не просто картинка, это какой-то инструмент должен быть. Что думаете, полезно ли было бы?

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

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

Ну а дальше меня лично (или виртуально) можно будет увидеть на курсах Systems.Education:

25-27 сентября: «Системный анализ + ИИ. Разработка требований и функциональное проектирование систем». Это наш классический курс для систематизации знаний в системном анализе, где мы даем четкую последовательность действий и артефактов. Но сейчас — с помощью ИИ, когда мы можем ускорить анализ (например, выявление бизнес-сущностей из текстов), формирование текстов и диаграмм, и кросс-проверки. В общем, классика на новом уровне в формате интенсивного погружения за 3 дня. Курс-боевик. В очном формате, кстати, довольно редко проводится.

А с 29 сентября начинаем экспериментальный онлайн-курс «Микросервисы для системных аналитиков». Без программирования и DevOps, ровно то, что нужно аналитикам. По-сути, это введение в архитектуру: там будет Event Storming, построение архитектурных диаграмм C4 до уровня компонент, практика составления записей архитектурных решений ADR, расчет нагрузки, ну и проектирование интеграций, но уже применительно к микросервисам: основные паттерны, сценарии взаимодействия, описание контрактов в OpenAPI и AsyncAPI (для Rabbit и Kafka). Это будет онлайн по три часа с утра.

Ну и 3-4 октября — Flow в Санкт-Петербурге. Там буду делать доклад про логику построения карты интеграций, а точнее даже — про морфологию интеграций: что во всех технологиях в любом случае есть, о чем нужно задуматься и как разные технологии между собой сравнивать.

Про 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 тоже интересные роли, можно и так.

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

Про протоколы приколы интеграции.

Сижу, готовлю презу к Flow. Подходит сын, садится рядом и внимательно изучает, что я рисую. Потом говорит: "Ааа! Протоколы интеграции! А я думал — приколы интеграции!"

Ну, поговорили о приколах. Навскидку, вспомнил такие приколы:

* SOAP, один из самых сложных по структуре протоколов, расшифровывается как Simple Object Access Protocol. Простой он по сравнению с такими монстрами, как CORBA.

* MQTT, несмотря на буквы MQ в названии (обычно означающие Message Queue), вообще не содержит очередей.

* YAML не является языком разметки, его теперь так и расшифровывают: YAML Ain't Markup Language.

* Основной принцип REST — управление через гипермедиа, HATEOAS. Но этому принципу почти никто следует в реальных REST API.

* REST API (HTTP-запросы) считается синхронным, но в реальных программах почти всегда HTTP-запросы выполняются асинхронно.

* Брокеры типа Kafka и RabbitMQ считаются (и являются!) асинхронными, но скорость обмена (latency или round trip) в них может быть в разы меньше, чем в "синхронных" HTTP-запросах.

* FlatBuffers, несмотря на своё название (flat=плоский), может хранить и вложенные объекты (через опцию nested_flatbuffers).

* Продукты RabbitMQ и Kafka часто рассматривают, как альтернативы, но они принципиально отличаются: RabbitMQ — это брокер сообщений с очередями без записи на диск, а Kafka — распределенный журнал с высоконадежным хранением, но без маршрутизации и очередей. Впрочем, в последнее время в Kafka появились очереди (в каком-то виде), а в RabbitMQ — персистентные сообщения и журналы (в каком-то виде). Напоминает сказку Киплинга про ежа и черепаху, которые друг друга учили плавать и сворачиваться в клубок.

* Несмотря на наличие "семантики доставки" exactly-once в Kafka, на самом деле доставка консьюмеру тут вообще никак не контролируется, это только про однократную и без потерь запись в журнал.

Это те, что я вспомнил минут за пять. Какие у нас ещё есть приколы в области интеграции?

Один из принципов контроля качества обучения, я считаю — открытые защиты. Да и в принципе открытость. Если у школы/университета всё внутри, всё только для своих — это вызывает некоторое подозрение. Либо они так пытаются торговать своей закрытостью и эксклюзивностью, либо что-то скрывают 🤔

Когда я ещё работал в вузе (МИЭМ), у нас были открытые защиты с 2007 года — кажется первые в стране.

В конце концов, ваш результат — не оглавление программы и не презентации, а изменение в умениях и понимании выпускников. Ну и покажите товар лицом. Systems.Education вот регулярно устраивает публичные защиты.

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

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

С полной программой курса можно ознакомиться по ссылке.
Порядок проведения демо - по ссылке.

🔹Как принять участие
Финальное демо пройдёт в онлайн-формате в 2х частях:
- в среду, 24 сентября, с 18:00 до 20:00 (мск)
- в четверг, 25 сентября, с 18:00 до 21:00 (мск).

Чтобы попасть на него, напишите нашему администратору Елене Гриценко: @elgritsenko. После подтверждения участия вам вышлют ссылку на онлайн-встречу.

Будем рады вашему присутствию!

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

Поэтому я целенаправленно в какой-то момент стал стремиться к ролям, на которых сам бы мог определять, что делать. Называлось это по-разному: руководитель бизнес-практики, директор по развитию, директор по продуктам. Когда ты работаешь в небольшой компании, можешь сам себе придумывать название должности (впрочем, в больших компаниях тоже иногда можно). Я как раз бросил компанию из группы ММВБ и ушел делать стартап, а получилась R&D компания с несколькими продуктами, которую так и не удалось сфокусировать. Потом была ещё пара-тройка похожих историй.

И знаете, что оказалось? Даже когда ты продакт-менеджер или там директор, ты тоже далеко не всегда самостоятельно определяешь, что делать.

Я подсмотрел в канале у Кристины Гусевой отчет Atlassian о состоянии продуктовых команд (они опрашивали менеджеров продуктов сеньорного уровня в США, Германии и Франции, всего 700 респондентов).

И знаете, что? Только 52% говорят, что имеют полномочия (feel empowered) определять стратегию и внедрять инновации. Остальные в той или иной мере реализуют чужие идеи. Меньше половины (47%) говорят, что продакт вообще направляет работы. В лучшем случае (43%) они имеют то же влияние, что и другие команды.

И — та-дам! — знаете, на что времени у продактов всегда не хватает?

На стратегическое планирование и разработку дорожных карт (отметили 49% респондентов) и на анализ и отслеживание метрик (тоже 49%). На третьем месте — личное развитие и обучение, на 4-м — инновации и эксперименты.

Погодите, а чем тогда вообще занимается продакт? Как образно пишут в отчете: 'it seems like product teams are focused on keeping their heads above water', "прикладывают все усилия, чтобы не потонуть".

Там весь отчет про то, как продуктовые команды и их руководители пытаются жонглировать множеством проектов, конкурирующими приоритетами, capacity команд, и ещё судорожно думают, куда бы тут воткнуть ИИ, потому что в каждом же продукте теперь должен быть ИИ, так?

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

В общем, не то чтобы роль продакта была очень развеселой и давала больше полномочий. В основном совпадает с моим опытом. Определять развитие продукта можно? Можно, если хватает времени и по согласованию с топ-менеджментом / владельцами / советом директоров. Эксперименты проводить можно? Можно в ограниченном объеме, в низкорискованных областях и только с разрешения руководства. Да, и чтобы метрики прибыльности ни в коем случае не падали! А релизить нужно чаще! 'Product development becoming a more cutthroat environment' — пишут авторы. Cutthroat!

Причем ИИ не особо помогает (про него в отчете тоже есть). На максималках он может экономить до 2 часов в день, в 50% случаев — от 10 минут до часа, вот только им в основном генерят тексты PRD, user story и отчеты для руководства. Сами респонденты считают это автоматизацией отдельных рутинных операций, а целостного системного способа внедрения ИИ в процессы пока нет.

Вторая часть отчета, которая подробно раскрыта в посте у Кристины, про то, что с этим делать. Выглядит, честно говоря, немного как "мышки, станьте ежиками". Вам не дают заниматься стратегией и экспериментами? Отлично, занимайтесь больше стратегией и экспериментами! Ну, эээ, спасибо. Нет, ну ладно, это самая интересная часть работы, и инструменты там описаны классные, хотя в общем и простые. Но напомнить себе лишний раз не помешает.

Например, что думать нужно не про output (созданных артефактах), а про outcome (достигнутых результатах).

Или про пирамиду RUF: Reliability-Usability-Features. Сначала надежность, потом пользовательский опыт, и только над ними уже новые фичи.

Ну а свободу в принятии решений нужно искать, видимо, не на уровне продакта (или даже CPO), а ещё выше!