Рабочее развитие инженеров-менеджеров (МИМ)

Запись бесплатного практикума "ИИ знает почти всё. А вашу работу — нет" Анатолия Левенчука.

Коллеги, спасибо всем, кто сегодня подключился в Zoom ❤️

Почти 170 человек смотрели онлайн, пробовали FPF/SPF на своих задачах, задавали вопросы, сравнивали ответы ИИ, делали первые DPF/SPF-0 и сразу приносили результаты в чат.

Это новый для МИМ формат: практикум по свежей разработке, где материал показывался впервые, а участники сразу проверяли его на своих рабочих ситуациях.

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

Для практикума о передовой технологии это нормальная амплитуда.

Его ценность в первом рабочем результате — человек берёт свою задачу и видит, что меняется, когда AI-агент получает принципы работы, предметные правила и более точную постановку.

Особенно ценно, что сразу появились примеры из очень разных областей: backend-разработка, архитектура ПО, R&D, строительные проекты, маркетплейсы, СЭД, trading, DevOps, перевод, управление lead time, low-code ИС, карьерные задачи и другие рабочие ситуации.

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

Это тоже материал для дальнейшей работы💼 — его можно использовать вместе со слайдоментом👆 и транскрибацией семинара👇, чтобы разбирать практикум с AI-агентом, вытаскивать примеры, уточнять и видеть, как разные участники применяют FPF/SPF к своим задачам.

❗️Если вы не были онлайн, запись будет полноценной заменой.

Лучше смотреть её не фоном, а как рабочий материал: открыть слайды, подготовить одну свою задачу и пройти практикум вместе с AI-агентом.

Для подготовки:

1. Возьмите одну рабочую задачу: документ, процесс, решение, модуль, метрику, повторяющуюся ситуацию или место, где ИИ обычно отвечает уверенно, но промахивается.

2. Проверьте, что вам пришло письмо с инструкцией после заполнения:
https://forms.gle/Y89cievfJMVfcS4TA

Если письмо не пришло или произошёл сбой — напишите в комментариях, поможем вручную.

3. Во время просмотра держите фокус на первом результате: черновике SPF-0 под одну задачу. Потом его можно дорабатывать, уточнять с AI-агентом и приносить в чат.

4. Отдельно просим: присылайте свои черновики, даже сырые. Это полезно вам самим: когда вы описываете результат письменно, приходится точнее назвать задачу, увидеть промахи ИИ и сформулировать правила для агента.

Там часто помогают с разбором, усиливают удачные находки и показывают хорошие примеры на канале с учётом рабочих ограничений, чтобы у всех собиралась насмотренность по применению FPF/SPF в разных областях.

✅ Комментарии и вопросы по практикуму под этим постом.

Так обсуждение сохранится после встречи, и наставникам будет удобнее отвечать по ходу и после эфира. Zoom используем для просмотра и участия в семинаре.

❗️Важный технический момент: Telegram-бот защиты от спама может удалять анонимные аккаунты без предупреждения. Пожалуйста, проверьте, что в вашем Telegram-профиле указано имя.

Ссылка на подключение:

https://us06web.zoom.us/j/81869336950?pwd=GatgbNUmbzgy4s2dz0tjMWqIaUYjUF.1

✅ Слайдомент к практикуму:

https://disk.yandex.ru/i/0bQxr3e7b2PpfA

Мы даём презентацию заранее именно в формате слайдов, чтобы можно было приближать картинки, смотреть детали и возвращаться к ним после встречи.

Главное перед стартом — выберите одну рабочую задачу, с которой будете пробовать FPF/SPF (это будет "домашкой", с которой начнём).

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

___________________________

👇👇👇 Итого по подготовке.

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

2. По задаче, если есть 10–15 минут, форма подготовки:
https://forms.gle/Y89cievfJMVfcS4TA

3. Если времени совсем мало, можно взять быструю памятку со второй картинки здесь: https://t.me/mim_workdev/187

Сегодня хороший результат — взять одну задачу и сделать первый черновик SPF-0: правила, по которым AI-агенту будет легче и сильно качественнее работать именно в вашей области❗️

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

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

Здесь все учатся и помогают друг другу.

Перед бесплатным вводным практикумом хотим правильно настроить ожидания.

Это не будет лёгкий мотивационный вебинар про "пять промптов для работы". Мы идём к переднему краю: FPF, SPF, AI-агенты, предметные регламенты, первые принципы рабочих задач. Местами будет сложно, особенно если вы у нас впервые.

И это нормально.

Сложно не потому, что "вы не справляетесь", а потому что материал тянет выше привычного уровня. Когда вы идёте за сильным мышлением, часть пути всегда проходит через состояние: "я понимаю не всё, но начинаю видеть больше".

Задача на сегодня простая: не объять весь FPF, не разобраться во всех терминах, не построить идеальный предметный регламент.

Задача — дойти до первого понятного результата на одной своей рабочей ситуации.

Если текст на слайде пугает — смотрите на картинку и слушайте голосом❗️

Если потеряли нить — возвращайтесь к своей задаче: какой документ, процесс, решение, модуль, роль, метрика или повторяющаяся ситуация у вас есть прямо сейчас?

Если встретили непонятный термин — не зависайте. Запишите его и потом разберите с AI-агентом.

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

Ильшат в своём докладе хорошо показал рабочий способ: смотреть семинар не как одноразовое видео, а как материал, который можно разбирать с AI-агентом. Просить объяснить непонятное, собрать связное изложение, привести примеры, проверить понимание, помочь применить к своему проекту.

Поэтому сегодня идём по ступенькам (прикрепляем памятку):

1. Смотрим картинки и слушаем.
2. Дожидаемся практического задания.
3. Берём одну свою задачу.
4. Делаем первый черновик SPF-0.
5. После практикума возвращаемся к слайдам и разбираем непонятное с AI-агентом.
6. Присылаем здесь, в комментарии, свой первый черновик

После практикума пришлите в чат, что вы взяли за задачу и какой первый SPF-0 у вас получился. Даже если черновик сырой.

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

Мы будем помогать с разбором, усиливать удачные находки и показывать хорошие примеры на канале (с учётом nda), чтобы у всех собиралась насмотренность: как разные люди применяют FPF/SPF к своим задачам.

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

Наши наставники будут рядом в чате. Если вы у нас впервые, если пугают термины, если не знаете, с какой задачей зайти, пишите. Мы поможем пройти первый шаг.

Сегодня главное — попробовать и получить первый рабочий результат, а не понять всё.

Старт в 11:30 МСК — до встречи online!

Форма подготовки: https://forms.gle/Y89cievfJMVfcS4TA

Материалы и напоминания — здесь, в "Рабочем развитии" (@mim_workdev).

Вакансия для AI-агента уже выглядит менее странно, чем хотелось бы

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

Можно посмеяться, конечно. Но недолго.

Потому что за этой странной вакансией стоит вполне реальный сдвиг: AI всё чаще воспринимают не как чат для вопросов, а как участника работы, которому можно отдать кусок задачи. И вот тут быстро выясняется, что "умный агент" сам по себе не решает главную проблему.

Агенту всё равно надо объяснить, что такое хорошая работа.

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

Анатолий в комментариях дал очень точный образ: если всем скрипачам выдать скрипки Страдивари, музыка станет лучше, но играть они всё равно будут по-разному. Сейчас всем выдали сильный AI. Скорость и качество работы вырастут, но решающим остаётся мышление человека, который ставит задачу, направляет агента и понимает, что тот вернул.

В этом месте FPF становится способом усилить собственное мышление в работе с AI.

Он заставляет смотреть на задачу рабочими различениями: что именно меняем, какой объект под вопросом, какой ход сейчас уместен, какие основания нужны, что считать результатом.

Вчера участники уже пробовали это на живых задачах: кто-то прогнал через FPF работу Claude Code со skill-файлом и получил более точное поведение агента, кто-то собирал через сильную модель спецификацию для команды и дальше отдавал её Sonnet как уже подготовленную работу.

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

И теперь следующий шаг — SPF.

Потому что FPF даёт общие принципы рабочих ходов, а SPF отвечает на вопрос:

как именно это должно работать в вашей области.

Для программиста, аналитика, руководителя, методолога, исследователя, преподавателя, архитектора продукта — у всех будут разные типовые промахи, разные сильные ходы, разные границы самостоятельности агента.

Завтра на бесплатном практикуме Анатолия Левенчука будем делать первый маленький SPF-0 под одну свою задачу.

Это оптимальная точка входа: не нужно верить на слово, просто проверяем на своём примере, что меняется, когда AI получает не только запрос, но и принципы, по которым должен работать.

28 июня, 11:30 МСК
Бесплатный практикум "ИИ знает почти всё. А вашу работу — нет"

Материалы, презентацию и напоминания выложим здесь, на канале "Рабочее развитие": @mim_workdev

Пояснительная бригада приехала: ИИ может знать Левенчука, но не знает вашу работу

ИИ может знать статьи, книги, GitHub, конференции, модные слова и даже примерно понимать, кто такой Анатолий Левенчук.

Но вашу конкретную работу он не знает.

Возьмём простую ситуацию: мидл-программист работает с ИИ.

ИИ может объяснить паттерны проектирования, написать кусок кода, предложить тесты, найти ошибку, сравнить библиотеки и даже звучать как очень уверенный senior.

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

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

Он не знает, что этот модуль нельзя трогать без соседней команды.

Он не знает, что похожее решение уже ломало прод.

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

❤ И вот тут появляется SPF.

SPF — это предметный регламент для ИИ-агента. Не общая инструкция "думай лучше", а правила работы внутри конкретной области.

Например, SPF для мидл-программиста описывает не "объект, метод и результат" вообще, а живые рабочие ситуации:

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

FPF даёт общий язык рабочих ходов.

SPF переводит его на язык предметной области.

Для программиста это уже не "удержи контекст", а "учти сервис, модуль, API, контракт, тесты, релиз, владельца кода и риск для прода".

Не "собери варианты", а "предложи три реализации: быструю, безопасную и более архитектурную; покажи цену поддержки каждой".

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

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

Вот почему SPF может сильно изменить рабочие процессы.

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

И это меняет позицию специалиста.

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

За SPF почти год работы над FPF: сначала собирался общий язык рабочих ходов, а теперь появляется следующий шаг — предметные регламенты для конкретных областей.

На бесплатном практикуме мы не будем строить большой SPF для всей профессии.

Мы возьмём одну повторяющуюся задачу из вашей работы и соберём первый SPF-0: маленький регламент, по которому ИИ-агент начнёт работать точнее в одной конкретной ситуации.

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

28 июня, 11:30 МСК — бесплатный вводный практикум Анатолия Левенчука
"ИИ знает почти всё. А вашу работу — нет"

Форма подготовки: https://forms.gle/Y89cievfJMVfcS4TA

После заполнения вы получите маршрут с инструкцией на почту: что открыть, какой пример взять и с чем прийти на практикум.

Спасибо, нас оказалось много ❤️

За последние два дня форму подготовки к практикуму заполняли очень активно. Вчера утром поток оказался таким, что автоматическая отправка писем с маршрутами на время не справилась🫠

Мы всё починили и дослали письма тем, кто попал в эту паузу.

Если вы уже заполняли форму, но не видите письмо "Ваш маршрут подготовки к практикуму FPF", напишите нам в комментариях. Поможем разобраться и при необходимости дошлём.

✅ И важное уточнение по подготовке.

FPF не надо вставлять в сообщение ИИ целиком как огромный текст. В современных AI-системах лучше прикреплять FPF как файл в проекте, рабочем пространстве или папке агента, чтобы ИИ мог обращаться к нему как к рабочему стандарту. В разных системах это устроено по-разному: где-то это project files, где-то workspace, где-то папка с документами. Если ваша система не справляется, можно попробовать Qwen: у участников уже был опыт, что он загружает файл целиком.

На практикум достаточно прийти с одной задачей из вашей работы. Не с абстрактной темой "изучить FPF", а с конкретным случаем:

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

Именно для этого нужен SPF-0: короткий предметный регламент для ИИ-агента, который говорит, где он работает, что должен уточнить, где остановиться и какой результат вернуть человеку.

Форма, если ещё не заполняли — после которой направляем более подробную инструкцию по подготовке к практикуму: https://forms.gle/Y89cievfJMVfcS4TA

В это воскресенье, 28 июня, 11:30 МСК — бесплатный семинар в формате практикума от научного руководителя МИМ Анатолия Левенчука "ИИ знает почти всё. А вашу работу — нет".

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

ИИ знает почти всё. А вашу работу — нет

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

Опаснее другой сценарий, когда ИИ отвечает уверенно. Текст гладкий, структура есть, варианты есть, выводы звучат убедительно. Кажется, что работа сдвинулась.

А потом вы пытаетесь положить это в реальный проект — и всё начинает скрипеть.
🚫 Документ стал лучше, но задача не решена.
🚫 Идеи есть, но следующий ход непонятен.
🚫 Критерии звучат разумно, но проверять по ним нечего.
🚫 Рекомендация красивая, но ограничения проекта не учтены.

Умно звучит. Но в работу не положить.

Вот с этим местом мы будем работать на бесплатном вводном практикуме с Анатолием Левенчуком 28 июня.

В МИМ для таких задач используется FPF: он помогает отличать гладкий ответ от рабочего хода. Где промах? Какие критерии добавить? Что проверить? Какой следующий шаг выбрать? Что должно получиться, чтобы результат можно было использовать дальше?

А дальше появляется ещё более сильная штука — SPF.

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

Недостающая деталь между "ИИ знает почти всё" и "ИИ помогает именно в моей работе".

28 июня мы начинаем с бесплатного вводного практикума. Это первый вход в серию практикумов по FPF, SPF и ИИ-агентам.

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

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

Сейчас открыт первый шаг — короткая форма подготовки к бесплатному вводному практикуму. Она работает как маленькая полезная "игрушка": определяет ваш вход и отправляет на почту маршрут подготовки под ваш уровень.

Форма определит вашу стартовую точку:
— почти не работали с ИИ;
— пользуетесь ИИ, но не работали с FPF;
— знакомы с FPF, руководствами МИМ или моделированием.

И после заполнения вы получите письмо: что открыть, какой пример взять, как попробовать FPF с ИИ и с чем прийти на практикум.

Форма подготовки: https://forms.gle/Y89cievfJMVfcS4TA
28 июня, 11:30 (МСК) — бесплатный вводный практикум.
Завтра здесь, в @mim_workdev, дадим подробности по серии практикумов.

Это по мотивам поста https://systemsworld.club/t/lytdybr-ot-17-iyunya-2026/39721/

О рабочем развитии и связи с другими программами (исследовательского, личного развития), а также о том, что происходит с FPF

В IT и инженерных сферах сейчас происходит интересный разворот.

Андерс Хейлсберг, создатель C#, TypeScript, Turbo Pascal и Delphi, недавно озвучил ключевое о будущем разработки (и к чему МИМ готовила резидентов последние годы):

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

Ценность специалиста смещается — уже мало просто "уметь делать руками":

1. Нужно уметь ставить задачу так, чтобы она была понята.
2. Проверять результат, который сделал AI или другой участник команды.
3. Видеть, где красивая схема не совпадает с работой.
4. Понимать, что именно ускорилось, что стало хуже, где сработал метод, а где просто удачно совпали обстоятельства.
5. Удерживать взаимосвязи проекта при любой сложности. И интересы, и ограничения, и слабые места, и риск неуспешности.

❗️ Для инженеров, разработчиков, аналитиков, менеджеров и техлидов это хорошая возможность.

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

Именно под это сейчас идут ближайшие резидентуры программы "Рабочее развитие": R2, R3 и R5.

R2 "Моделирование как основа коммуникации и лидерства" — для тех, кто прошёл R1 и хочет, чтобы задачи, встречи и рабочие тексты приводили к согласованным действиям.

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

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

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

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

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

Это особенно важно сейчас: AI может быстро произвести текст, код или модель. Но кто-то должен понять, что именно там описано, где ошибка, где допущение, где основание для действия.

R5 "Системное мышление" — для тех, кому нужно управлять сложностью, а не просто много о ней думать.

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

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

Отдельно важно: руководства и FPF недавно обновились под эти резидентуры.

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

Сейчас можно присоединиться к ближайшим группам R2, R3 и R5.

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

Подключиться к своей группе: @SystemsSchool_bot

Прошло несколько месяцев с тех пор, как программа "Рабочее развитие" перешла в режим резидентур.

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

Это важно, потому что первый проход программы "Рабочее развитие" лучше делать последовательно.

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

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

Хочется сразу в R5, потому что проект сложный.
Хочется сразу в R7 или R8, потому что надо менять способ работы команды, разбираться с архитектурой, DevOps, требованиями и обоснованиями.

Но в развитии мышления легко срабатывает закон Гудхарта: когда показатель становится целью, он теряет способность показывать состояние дела.

Человек выбирает желаемый навык как метрику роста: найти целевую систему, построить причинный граф, разобрать WIP. Термин появился, схема нарисована, упражнение выполнено.

А сложная ситуация в проекте всё равно стоит на месте.

В обсуждениях рабочего развития есть хорошая метафора: сложный этап или сложный проект похож на бетонную плиту.

Её трудно сдвинуть, вцепившись в одну точку. Можно надорваться, отколоть кусок, получить ощущение усилия и даже красивый след работы. Но сама плита останется там же.

Так же со сложной рабочей ситуацией:

R1 помогает увидеть внимание, авралы, незавершёнку и переход от занятости к выпуску.
R2 переводит коммуникацию в работу с моделями, ролями, представлениями адресата и согласованными действиями.
R3 даёт точность рабочих моделей: объекты, роли, описания, методы, потоки работ и узкие места.
R4 добавляет причинность: гипотезы, объяснения, интервенции и проверку того, что действительно меняет ситуацию.
R5 помогает удерживать сложную систему: целевую систему, надсистему, подсистемы, интересы и риски неуспешности.
R6 развивает системное моделирование.
R7 переводит внимание к методам работы.
R8 переносит это в системную инженерию.
R9 показывает развитие личности и мастерства как инженерный проект.
R10 собирает управленческую сторону коллективной работы.

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

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

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

Проход "на троечку", но до конца, часто полезнее, чем многолетнее застревание в одном фрагменте в ожидании идеального понимания.

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

Мастерство растёт не от чистого чтения, а от повторного применения на реальных ситуациях.

Поэтому вопрос "куда мне?" нормальный. Особенно если вы:

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

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

Сейчас можно присоединиться к группам первых пяти резидентур: @SystemsSchool_bot

У нас к стартам новых потоков было принято разрабатывать новые версии руководств, но примерно год вместо новых версий руководств выходили новые версии FPF (что тоже хорошо).

Мы не отсталые и не работаем по идеям 80х годов прошлого века, то есть у нас release early, release often, а не "сырое не выпускать" (редкие релизы, длинные циклы, вечные догонялки по отношению к фронтиру).

И вот у нас обновление: новый набор руководств, экспериментальный вариант, это вывод руководств на фронтир: совмещение с FPF онтологии ролей. Десятки часов работы AI-агентов, ещё больше часов работы автора руководств. Далее делаем бенчмаркинг (сравниваем старые и новые версии — какие лучше?), ищем ошибки, обращаемся к опытным членам сообщества, демонстрируем приверженность собственным принципам работать на фронтире, работать с MVP.

Итак, подготовлены новые тексты руководств R5-R10 (там были сделаны изменения в онтологии ролей, чтобы поднять совместимость с FPF. Например, "целевая система проекта" — это роль системы в контексте проекта), и было бы интересно получить на них какие-то отклики — считать это экспериментом и бросить, или наоборот — продолжать доработку в этом направлении. Поэтому мастера могут получить эти экспериментальные тексты руководств (в .md, читаются в Google Docs) для того, чтобы помочь их как-то оценить и подсказать дальнейшие направления доработки. Это будет актуально ближайшие несколько дней и использовано для планирования: тратить больше времени на доработку руководств (у нас планируется запуск группы по R5 как минимум — можно ли их пускать по новому тексту?) или не тратить (и быстрее выпустить "архитектуру в FPF").

Пишите в личку А.Левенчуку — @ailevenchuk, а у кого нет ещё квалификации мастера — просьба на эту тему не беспокоиться, вы получите уже готовые варианты текстов.

На рынке давно существует понятный ценник за переход к задачам "высокого" масштаба.

В глобальных топовых MBA он измеряется десятками и сотнями тысяч долларов. По данным GMAC, средняя стоимость MBA из глобального топ-20 составляет около $171 тыс. в США, $116 тыс. в Европе и $89 тыс. в Азии.

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

В этом заинтересованы работодатели — в исследовании GMAC для рекрутеров способность разбираться со сложными рабочими задачами и мыслить стратегически остаётся среди самых ценных навыков для выпускников бизнес-образования.

Но сама по себе дорогая программа не создаёт квалификацию.

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

В логике МИМ это описывается точнее, чем через общий ярлык "менеджерский потенциал": агентность, масштаб и методологическая дисциплина.

Можете ли вы понять сложную ситуацию и изменить работу в реальном проекте?

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

R3 и R5 дают базу именно под такой рост.

R3 помогает убрать путаницу из рабочих описаний, документов, схем и коммуникации. Это про ситуации, где команда вроде договорилась, а потом начинаются переделки, лишние согласования, спор о требованиях, методах и ответственности.

R5 помогает думать о сложной системе и не терять главное: целевую систему, надсистему, роли, интересы, ограничения и риски неуспешности.

Именно поэтому откладывать опасно.

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

В такие моменты уже не звучит: "я неплохо работал".

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

MBA стоит дорого за обещание управленческого масштаба.

❗️МИМ тренирует саму способность брать этот масштаб: агентность, системность, методологическую дисциплину.

Вопрос не в выборе очередного курса.

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

R3 стартует сейчас.
R5 стартует в понедельник.

Подключиться: @SystemsSchool_bot

Карта выглядит убедительно. Но можно ли по ней ехать?

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

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

Документ был один. Отношение к реальности у разных частей документа было разным.

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

В рабочих проектах эту разницу часто пропускают.

Хотелки заказчика начинают жить как требования. План-график читают как отчёт о выполненной работе. Должностную инструкцию принимают за реальный способ, которым человек действует каждый день. Презентационную схему используют там, где нужен разбор фактов, ограничений и предметов работ.

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

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

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

В R3 "Рабочее моделирование" мы учимся строить именно такие описания. Такие, через которые люди начинают видеть одну и ту же работу одинаково.

Узнать подробности и присоединиться к группе: @SystemsSchool_bot

"Нам нужно оптимизировать процесс" — фраза, после которой часто начинается затягивание обсуждения.

— Нам нужно оптимизировать этот процесс.
— Это не процесс, это проект.
— Нет, это функция отдела.
— Подождите, это вообще регламент.
— А я думал, мы обсуждаем работу людей.

Так выглядит потеря рабочего объекта (а не спор о терминологии). В командах появляются слова-затычки:
"процесс", "проект", "роль", "система", "результат", "метод", "ответственный", "продукт". Они звучат умно и привычно.

Но часто под одним словом у разных участников лежат разные объекты.

Один говорит "процесс" и имеет в виду поток работ.
Другой — метод выполнения.
Третий — оргструктуру.
Четвёртый — регламент в документе.
Пятый — трудозатраты конкретных людей.

Пока это не разделено, команда не может договориться.
Она спорит не о решении, а о тумане.

В R3 мы тренируем "машинку типов", умение остановиться и спросить не "кто прав?", а:
— что именно мы сейчас называем этим словом?
— это объект, описание, роль, метод, работа, класс, отношение или ситуация?
— в каком контексте это слово имеет такой смысл?
— какой практический эффект будет, если мы перепутаем?

Например:
должность — это не роль.
роль — это не человек.
регламент — это не метод работы.
метод работы — это не фактическая работа по методу.
описание системы — это не сама система.

Эти различения могут показаться "слишком тонкими" ровно до момента, пока из-за их отсутствия команда:
🪫 не переделывает проект,
🪫 не теряет сроки
🪫 или не спорит две недели о том, что на самом деле уже можно было смоделировать за час.

Рабочее моделирование начинается не с диаграмм, оно начинается с точного указания: какой объект мы обсуждаем.

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

Набор в группу открыт до пятницы, подключиться: @SystemsSchool_bot