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

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

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

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

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

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

Для миллениалов (обязательно нужно 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), а ещё выше!

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

На это есть ответ в том же канале Product Games — кстати, очень рекомендую, если интересуетесь управлением продуктами. Я на несколько каналов продакт-менеджеров подписан, но они все почему-то странные — либо там бородатые мужики, которые все посты пишут матом, либо сплошная реклама каких-нибудь своих курсов. В этом смысле Product Games — прямо глоток свежего воздуха и чистой речи! (Реклама там тоже есть, но не чрезмерно).

Так вот, пост про разницу в понимании роли менеджера по продукту в разных странах:

в Европе это, действительно — чел, который координирует процессы, принимает готовый roadmap, и KPI — это «чтобы все были довольны». До пользователей далеко, решения принимаются "где-то наверху".

в США — PM отвечает за рост, влияет на стратегию, напрямую работает с выручкой, ценой и активацией. Много автономии, скорости и доверия.

В РФ я сталкивался с разными ожиданиями, даже пытался об этом рассказывать почти 10 лет назад на AgileDays.

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

Где-то посередине оказываются "продакты по европейскому образцу" — операционные менеджеры, своими управленческими и лидерскими усилиями переводящие чьё-то видение и роадмэп в реально работающий продукт.

На самом деле CEO ведь тоже не самый главный — он отвечает перед собственниками, инвесторами и советом директоров. И как мини-CEO, тоже будешь отвечать, и делать то, что тебе ставят как KPI.

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

Или, например, ты думаешь, что твои клиенты — обучающиеся, и выстраиваешь весь продукт под них, а совет директоров тебе говорит: думать нужно о ректорах региональных вузов, основные деньги будем брать от них. То есть продукт резко стал не B2C, а B2B (я придумал обозначение U2U — University to university), и всё совсем другое. Ну и продакт не нужен, больше нужны прошаренные сейлзы. Собственно, продуктовая история на этом закончилась.

Так что нужно выбирать, и выбирать аккуратно. Я про себя точно знаю, что в чистый маркетинг я не хочу идти, мне важно видеть, как идея превращается в работающий продукт и приносит пользу людям. Это, кстати, и в отчете видно: от продактов хотят достижения бизнес-показателей, но только 12% радует эта работа. Остальных больше драйвит создание чего-то нового, креативное решение проблем, глубокое понимание проблем пользователей и внедрение инноваций.

У Жени Калинина ("Школа трекеров") в рассылке подсмотрел отличную мысль про применение ИИ в бизнесе. Сейчас же все побежали, всем везде нужен ИИ. В какую тусовку не придёшь — все обсуждают ИИ.

У аналииков ИИ, у разработчиков ИИ, у архитекторов, у девопсов, у врачей, у учителей, у писателей — все только про ИИ говорят (имея в виду в основном LLM, конечно). В последнее время — про агентов.

Но эффект не очень виден — по крайне мере, не очень однозначен. Кому-то помогает, а кому-то вообще нет. На Pimon я слушал доклад про инструмент для настройки мэппинга и преобразования данных в шине при помощи LLM. У слушателей был главный вопрос — зачем?

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

И вот (цитирую рассылку) ИИ очень хорошо решает проблему, когда у вас чего-то много и вы не успеваете это обрабатывать. То есть приходится от чего-то отказываться. Например, у меня в бытность CPO всегда было в бэклоге штук 40-50 гипотез и идей, которые стоит попробовать, но до них руки не доходят. Даже подумать про них пристально нет времени. У меня и KPI такой был специальный — время зависания новой идеи среди входящих, до принятия решения по ней.

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

Если бы, конечно, именно это было главным ограничением.

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

Если у вас и так сильно загружены разработчики — нет смысла увеличивать число написанных постановок, их всё равно будет некому делать. Нужно сначала разработку разгрузить. И так далее. Опасность тут в том, что у нас зачастую каждая функция отвечает за себя, а не за весь процесс от начала до конца. А локальная оптимизация одного участка ведет к росту незавершенки, а не росту выпуска. Я до сих пор вижу, как в одном продукте продолжают реализацию разработанной мной ещё в 2022 году дорожной карты; я уже три года там не работаю, а они её всё никак не сделают.

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

В общем, применяйте генеративный ИИ не где попало, а где у вас сейчас главное ограничение! Тогда и эффект будет значимый.

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

Я считаю — у любого явления должны быть свои проявления. За изменением в способе мышления должна следовать перестройка способа деятельности. И это можно отследить. Ну не может быть такого, что делаем мы всё так же, как и раньше, но теперь у нас продуктовый подход! Хотя, если посмотреть на Agile и SAFe...

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

Есть хороший пример про школы, мне один директор подсказал: руководство может сколько угодно говорить, как они ориентированы на ребенка, но посмотрите — на каком уровне висят плакаты на стенах? На уровне глаз детей или взрослых?

Вот хочется такие же критерии про продуктовый подход. Заходишь в офис, и сразу видишь — тут продуктовый подход. А вот у этой — не-а, вообще другой какой-то. Что это может быть?

Ну, точно понятно, когда не. Это мне в одной организации директор по разработке говорил — а кто такие продакты? Какая от них польза? Как пользователи работают — бизнес-аналитики опишут. Удобные интерфейсы дизайнеры нарисуют. Даже CSI и NPS мы в опросах выясняем регулярно. Roadmap по функциям верхнее начальство спустит, исходя из своих соображений. А продакты ваши что делают?

Тут как раз всё понятно. И, глядишь, года через три — они уже и сами продактов нанимают, разобрались.

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

Я попробую накинуть, а вы, пожалуйста, отреагируйте как-нибудь — отзывается, или совсем не то:

* Связь функций и деятельности пользователей. Вот прямо в явном виде: есть такой документ/рисунок, где видно, как какая-то функция на какую-то деятельность влияет. Может быть даже функция-деятельность-метрика (внедрение функции ведет к изменению деятельности, что ведет к изменению целевой метрики). Это, если роль пользователя добавить, Impact map получается. Ну или карта гипотез, как её Александр Бындю перебрендировал.
(Вот как надо, кстати говоря! Я на курсе-то примерно то же самое рассказывал, только упаковать не сумел).

В общем, ни курс не был востребован, ни живьем я ни у кого такой карты не видел (ну, кроме как у себя). Ну ладно, изменение деятельности — это слишком сложно, но хотя бы связь функций с метриками? То есть, набиваем бэклог не по принципу "что влезает", а по текущим целям и показателями продуктовых метрик. Можно даже таблицу составить — какая функция на какую метрику и в каком масштабе влияет. Мне Леша Кулаков (директор по продукту Ridero) такую показывал — у него ещё шкала влияния была нелинейная: 1,3,9. Гипотезы, конечно, но хоть что-то.

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

Критерий: есть ли артефакт, в котором можно посмотреть — какие функции для кого и зачем сделаны? Как они должны были повлиять на поведение/метрики, и как реально повлияли?

* Структура и предмет коммуникации. Это сложнее вытащить, но можно по назначенным встречам посмотреть. Кто, с кем и о чем говорит? Если мы хотим внедрить сквозное понимание, зачем мы каждое движение в продукте делаем, то обсуждаем ли мы цели продукта с разработкой и поддержкой? А берем их откуда, это с кем обсуждаем и как часто? Пользователи в этом участвуют?

* Представленность пользователей продукта. Откуда мы вообще узнаем о пользователях? Насколько мы от них далеки? Кто их вообще видел в последний раз? Как мы их слышим? Являются ли сами члены команды пользователями?

Вот что сразу в голову приходит, на что ещё стоит посмотреть?

Отдельная тема для интеграций — сериализация данных. Про неё почему-то мало говорят на "курсах по интеграциям и проектированию API".

А это, между тем, чуть ли не половина успеха интеграционного решения.

Вот, например, CSV. Существует же чуть ли не с 1972 года, говорят, его удобно было на перфокартах пробивать. И ведь до сих пор активно используется! Весь ETL, вся BigData, весь ML на нём только и держится.

А почему? Потому что
* человекочитаемый
* самый легковесный из человеко-читаемых (из оверхеда — только разделители, кавычки, переносы строк и символы экранирования — почти ничего, если сравнивать с JSON или XML)
* самый быстрый для обработки (до 300 тыс. строк в сек, какое API столько выдержит?), отлично параллелится

С другой стороны:
* не стандартизованный (а вы видели CSV с табуляцией? А с палками | в качестве разделителей? А с крышками ^?)
* бессхемный, нетипизированный
* плоский
* невероятно хрупкий — одна лишняя запятая, кавычка или разрыв строки, и конец обработке

Но если мы это понимаем, то можем предположить, что на каждую проблему должно быть своё решение. И действительно — есть CSV Schema , правда в статусе вечного драфта. С другой стороны, есть стандарт метаданных для описания табличных данных в Вебе: https://www.w3.org/TR/tabular-data-primer/

Как обычно, если нет одного стандарта, значит их будет два.

Ну и, конечно, есть альтернативный формат на основе JSON, берущий лучшее из двух миров — JSON Lines, JSONL.

Выглядит примерно так:

["Name", "Session", "Score", "Completed"]
["Gilbert", "2013", 24, true]
["Alexa", "2013", 29, true]
["May", "2012B", 14, false]
["Deloise", "2012A", 19, true] 

Решена проблема с внезапными разрывами строк, вложенными объектами и неоднозначностью разделителей. Правда, для него даже RFC пока нет.

В общем, всё укладывается в теорию гибридов Клейтона Кристенсена — в процессе подрывной инновации индустрия проходит стадию гибридов: парусно-паровые суда, гибридные автомобили, я в одном музее выдел даже гибрид шпаги и пистолета. У нас в интеграциях — странные наполовину JSONы, наполовину CSV; или вот диковинные гибриды JSON и XML (в NoSQL языке запросов JSONiq):

[ xs:date("1066-10-14"), <mercury>Hg</mercury>, "ice cream" ]

Так что, если вы видите какой-то гибрид (например, гибрид редактора кода и ИИ-генератора), это значит, что мы посреди подрывной инновации.

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