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

Еще одно простое, регулярное управленческое решение:

Какого специалиста нанять, чтобы улучшить ситуацию?

Можно опереться на опыт и выбрать “как привычнее”. А можно разложить системно и увидеть где выигрываем время, где ресурс, где получаем задел на будущее. И в этот момент часто рабочим оказывается неочевидный, контринтуитивный вариант. Ты его находишь, радуешься, выполняешь❤ Приходит специалист, с блеском осуществляет поставленную задачу, все в выигрыше. Не потому что “так сложилось”, а потому что решение было не только принято на основании опыта, но и системно проверено до запуска в работу. ✅ Подключайтесь в чат участников — к чек-листу безошибочной работы, выложили пошаговый план "что делать, если вы уже в rework": @SystemsSchool_bot Завтра, в 11:30, уже начнем разбор с наставником МИМ на ваших проектах.

“Давайте заведём AI-агента, который будет помогать писать business requirements. Это же быстрее, дешевле и логично.”

Дальше началась обычная работа: — Собрали первый вариант. — Протестировали. — Получили выход агента. Посмотрели — “ну, в целом неплохо, но не то”. — Подкрутили. — Запустили ещё раз. Потом ещё. Через какое-то время в команде начинают звучать знакомые фразы:

“нужно ещё чуть точнее сформулировать” “видимо, модель слабовата” “надо просто ещё пару итераций” “ну, мы же в новом процессе, нормально, что не сразу”

Cнаружи всё выглядит как освоение нового инструмента. А по факту команда уже попала в ловушку: решение было принято до того, как его проверили: 1. Не был задан критерий “что считается хорошим результатом”. Не в смысле общего “чтобы требования были качественными”, а в смысле минимально проверяемого: — по каким признакам мы понимаем, что результат годится? — где граница между “сырой, но полезный черновик” и “текст, который потом разрушит работу дальше по цепочке”? 2. Не был обсужден способ реализации. То есть никто не ответил на вопрос: мы вообще каким способом решаем эту задачу? Мы делаем: — черновик для ускорения? — полноценную замену части работы product manager? — интерфейс между PM и командой? Не были собраны варианты. Вместо этого почти всегда берут один, самый очевидный ход.

“Пусть агент пишет BRD”

А потом долго допиливают его, как будто проблема в качестве исполнения. 🚫И этого хватает, чтобы команда уже пошла в ложный способ решения. Как это выглядит в жизни через неделю? Команда чувствует не ускорение, а странную вязкость. Вроде бы работы стало больше. Результатов — не особенно. 🚫Product manager раздражён, потому что теперь вместо “написать самому” он: — перечитывает длинные, криво акцентированные тексты, правит смысл, — вычищает двусмысленности. 🚫Руководитель раздражён, потому что вместо обещанной скорости команда начинает: — дольше согласовывать, — чаще уточнять, — больше переделывать. Вместо — "какие есть варианты, как мы проверяем до запуска и подходит ли вообще это решение?" ❤Опыт даёт только первый ход. Дальше его нужно уметь проверять. И именно здесь начинается новая развилка по квалификации: один человек продолжает “пробовать и подкручивать”, другой начинает проверять решение до запуска. И через полгода между ними уже не просто разница в стиле работы. Там разница в уровне. Это инженерная работа с решением. Подключайтесь в чат участников семинара, забирайте чек-лист безошибочной работы или сразу оплачивайте, чтобы не пропустить его разбор online с наставником МИМ на семинаре 05 апреля, 11:30: @SystemsSchool_bot (→ Меню → Оплатить резидентуру / практикум / семинар → Семинар. Как перестать переделывать и начать управлять результатом в работе: через критерии, варианты и AI → Ссылка на чат)

Подслушано в чате поддержки рабочего развития: В крупной компании программистам запретили писать код — теперь они управляют агентами. А агенты пишут код. Это только одна из ситуаций, когда программистам необходимо становиться менеджерами. В современности — это уже неизбежно следующий шаг. И если человек не готов, ошибки плодятся, результат “не сходится”, всё повторяется. И снаружи это может выглядеть как слабая работа с AI-агентами или неготовность к росту. По факту: методы работы специалиста пока просто не скорректированы под обновлённую реальность, где решения начинают выполняться быстрее, чем успевают быть осмыслены и проверены. ✅ Оптимальное “лекарство” здесь — базовые шаги системной инженерии. И корректирует, спасает процесс именно тот, кто их понимает. Несколько простых вещей, которые позволяют не угадывать, не работать на ощущениях. Или, как мы говорим, немногие принципы, знание которых освобождает от необходимости учитывать множество факторов. Когда, после качественного прогона этих принципов, ты понимаешь, что можешь работать с любыми сложностями — в любой компании, с любым контекстом, в любом переходном этапе. И один из них — это рассматривать не один вариант, а несколько, проверяя по критериям. После чего становится видно, где выиграешь время, а где потеряешь ресурсы. Вот в этом месте появляется выбор с понятным результатом. ❤ В этом месте появляется свобода выбора и управляемость результатом. На выходных разбираем чек-лист безошибочной работы, через прогон с наставником, чтобы убрать слепые зоны в своих решениях. Это фрагменты из резидентур R7 и R8: характеристики, стратегирование. Объединённые и углублённые в рабочую форму. Это рабочая мантра или заклинание, которое важно разобрать, понять и повторять — чтобы действительно скорректировать результаты. Впервые или снова, под разными углами — до момента, когда это начинает работать автоматически. Чтобы перестроить мышление в сторону минимизации своих ошибок и повысить управляемость результатов (своих, коллег, AI-агентов). Поэтому разбираем именно на практике, как задать решениям на своём проекте базовую проверку до запуска — чтобы не возвращаться к ним с корректировками или переделками. Подключайтесь в чат участников, чтобы уже сейчас посмотреть на чек-лист безошибочной работы из презентации к семинару. Печатаем его и вешаем рядом — будем разбираться, как ловить ошибку до того, как она уйдёт в проект. 📌 Забрать чек-лист и последующие подготовительные материалы → @SystemsSchool_bot (до начала семинара доступ будет оставаться открытым без оплаты). Программа рабочего развития, включая все материалы и семинары — помогают не адаптироваться, а не терять квалификацию в момент, когда требования к работе меняются быстрее, чем вы успеваете перестраиваться.

Представьте, что каждый раз, когда вы вносите правку, с карты сразу списываются деньги — с пометкой “плата за ошибку”. Как в недавнем примере на семинаре научного руководителя МИМ Анатолия Левенчука: станок приходится разбирать, чтобы поставить прокладку. Это стоит времени и ресурсов — потому что вариант не проверили до запуска. В реальности списания тоже есть, просто растягиваются во времени — в виде оплачиваемого простоя команды, зависших задач и отложенных результатов. На том же семинаре мы обсудили: один вариант решения — это ошибка. Идём дальше: что с этим делать в реальной работе? Ключевая проблема не в количестве переделок, а в том, что слишком часто решения либо не проверяются изначально, либо проверяются после запуска в работу, когда уже поздно и дорого. Выбор происходит на ощущении: — не задаются критерии — не рассматриваются альтернативы Это уже меняется. Руководители, продуктовые и техлиды начинают прогонять решения через AI-агентов. Как в громком примере, когда генеральный директор James Quincey недавно прогонял через ИИ решение об уходе. Потому что опыта больше недостаточно. Его нужно проверять. Но достаточно ли просто переспросить у нейронки? В это воскресенье, 05 апреля, в 11:30 идём в практику с наставником Мастерской инженеров-менеджеров: разбираемся, как принимать решения так, чтобы к ним не приходилось возвращаться: — возьмём ваш кейс — найдём, где именно возникает ошибка и почему — зададим критерии, по которым решение можно проверить до запуска — соберём несколько вариантов вместо одного — и обсудим как лучше прогнать через AI Это работа с тем, как вы принимаете решения. Результат: вы начинаете системно проверять варианты и видеть ошибки до того, как они превращаются в переделки. Формат: интерактив + упражнение Соберём минимальную рабочую схему под ваш кейс. Стоимость: 3 500 ₽ Пререквизит: не требуется Материалы начнём выкладывать в чате мероприятия — подключиться можно через бота @SystemsSchool_bot

Надо ли нам ставить это в Aisystant? После какой резидентуры?

Вы уже посмотрели запись семинара? Мини-конспект (выборка важного): 1️⃣ Варианты нужны не для креативности, а чтобы не выбрать непродуманное. 2️⃣ Даже слабый прототип окупается пониманием пространства решений. 3️⃣ Поздние ошибки всегда дорогие — потому что это уже rework. 4️⃣ Отсутствие выбора — это не скорость, это недоисследованность и это ошибка. И топ неприятных фактов: — Если у вас был только один вариант — это уже ошибка. — Самые дорогие ошибки — незаметные, которые выглядят как нормальная работа. В этот раз семинар вышел на грани исследовательского — мы не шли по руководствам, а пошли дальше, в материалы, которых там еще нет. И тем самым, заставили многих задуматься:

Вы действительно уверены, что ищете решение, а не исправляете ошибку?

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

Видео семинара "Ошибка — это не вариант!"

Ссылка на семинар в рамках программы рабочего развития "Три прототипа — это нормально. Три исправления ошибки — нет" с Анатолием Левенчуком: https://us06web.zoom.us/j/83755935138?pwd=io3zCWfQiWHgCIsiCpnVlNOIaWoTgF.1 Начинаем. Слайды: https://disk.yandex.ru/i/5YpJ3styw9P00g

https://us06web.zoom.us/j/83755935138?pwd=io3zCWfQiWHgCIsiCpnVlNOIaWoTgF.1 — это ссылка на семинар https://disk.yandex.ru/i/5YpJ3styw9P00g — это ссылка на слайды

Завтра разберём один конкретный момент, из-за которого работа уходит в доработки и уточнения. Вчера выложили короткий подготовительный материал — 3 теста для самопроверки. Он нужен, чтобы прийти на семинар уже с примером из своей работы. Прочитайте сегодня — этого достаточно, чтобы завтра лучше “поймать” свой случай в разборе. Завтра в 11:30 пришлём сюда ссылку на Zoom. Будем разбирать, где у вас был выбор, а где ошибка стала видна слишком поздно. Запись тоже будет здесь: @mim_workdev

Есть одна вещь, которую в рабочих командах часто вообще не различают. Сделали один ход. Потом второй. Что-то уточнили. Что-то переделали. Снаружи это может выглядеть одинаково. Но: — В одном случае команда нормально ищет решение: пробует варианты, сравнивает, отбрасывает лишнее. — В другом — уже тратит время на исправление ошибок, которые заметили слишком поздно. Разница есть и она значительная. Мы сделали короткий материал: "3 теста, после которых вы иначе посмотрите на переделки в проекте" Не длинная теория. Не “10 шагов к эффективности”. Только три вопроса для самодиагностики, после которых обычно становится видно, что именно у вас происходит:

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

Это короткий материал, который помогает увидеть главное различие: где у вас ещё поиск решения, а где уже дорогие исправления. https://docs.google.com/document/d/1zVmzbxyWS6z86e9jUkOfeUVpzvTJq9FeXK0w36eqNK4/edit?usp=sharing 📍А дальше — приходите на бесплатный семинар Анатолия Левенчука 22 марта, в 11:30, сюда же, на канал Рабочего развития МИМ. Мы будем разбираться где вариант, а где ошибка. Почему несколько прототипов — это нормально. Почему несколько исправлений одной и той же ошибки — уже нет. И в какой момент команда перестаёт выбирать и начинает просто надеяться, что “в этот раз сойдётся🙏”. Это один из тех случаев, когда онлайн важнее записи. Вживую увидеть свою собственную рабочую ситуацию — в моменте, пока идёт разговор и примерять его на свой проект, — намного ценнее. 📌 Материал, видео-запись и ссылка на эфир будут здесь же — @mim_workdev

Есть одна вещь, которую в рабочих командах часто вообще не различают. Сделали один ход. Потом второй. Что-то уточнили. Что-то переделали. Снаружи это может выглядеть одинаково. Но: — В одном случае команда нормально ищет решение: пробует варианты, сравнивает, отбрасывает лишнее. — В другом — уже тратит время на исправление ошибок, которые заметили слишком поздно. Разница есть и она значительная. Мы сделали короткий материал: "3 теста, после которых вы иначе посмотрите на переделки в проекте" Не длинная теория. Не “10 шагов к эффективности”. Только три вопроса для самодиагностики, после которых обычно становится видно, что именно у вас происходит:

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

Это короткий материал, который помогает увидеть главное различие: где у вас ещё поиск решения, а где уже дорогие исправления. https://docs.google.com/document/d/1zVmzbxyWS6z86e9jUkOfeUVpzvTJq9FeXK0w36eqNK4/edit?usp=sharing 📍А дальше — приходите на бесплатный семинар Анатолия Левенчука 22 марта, в 11:30, сюда же, на канал Рабочего развития МИМ. Мы будем разбираться где вариант, а где ошибка. Почему несколько прототипов — это нормально. Почему несколько исправлений одной и той же ошибки — уже нет. И в какой момент команда перестаёт выбирать и начинает просто надеяться, что “в этот раз сойдётся🙏”. Это один из тех случаев, когда онлайн важнее записи. Вживую увидеть свою собственную рабочую ситуацию — в моменте, пока идёт разговор и примерять его на свой проект, — намного ценнее. 📌 Материал, видео-запись и ссылка на эфир будут здесь же — @mim_workdev

Резидентуры закрываются. В такие моменты у людей обычно наступает развилка. R9 уже ушла в работу. R2 — сегодня последний шанс попасть на первый разбор. R6 — донабор до понедельника (23.03), и туда сейчас заходят те, кто ранее проходил самостоятельно. И вот здесь важное наблюдение. За последние дни к нам пришло несколько человек из "самопрохождения". Большинство — не новички. Они уже читали, обсуждали, собирались в группы. Кто-то даже сам прошел всю программу Рабочего развития. Но в какой-то момент, чаще всего: → обсуждения идут по кругу → решения не закрепляются → ощущение: «вроде понимаю, но применяю явно слабее, чем люди из чатов МИМ» Потому что мышление корректируется резидентурами не при самостоятельном чтении, а при применении полученных знаний на своем проекте под присмотром наставника и с формированием насмотренности в групповой динамике. Наш наставник Юля недавно очень точно написала:

«Руководство нужно не чтобы понять текущее, а чтобы смочь прочитать следующее»

И это контринтуитивно. Кажется, что нужно остановиться и «допонять». На практике же — это замедляет в 2 раза. Смотрите разницу: Самостоятельно — читаешь — обсуждаешь — делаешь как понял — не замечаешь ошибок — закрепляешь их В резидентуре — делаешь — тебе сразу показывают, где мимо — внимание сдвигается — мышление становится воспроизводимым — появляется позиция, которую можно защищать И именно отсюда начинаются реальные изменения. Не «я прочитал курс», а: — вас начинают хантить на проекты — вы начинаете понимать сложные системы — то, что вы говорите коллегам/начальству перестает быть просто мнением — вы влияете на решения, а не комментируете их ✅ Как это выглядит в реальности (один из кейсов применения навыков из резидентур): — человек за 3–4 месяца перестраивает R&D на 40+ систем — к нему начинают приходить из других стран «посмотреть как устроено» — его руководитель уходит на уровень выше — и забирает его с собой Это не «талант». Это следствие действия + калибровки мышления. ❗️Кому сейчас точно в R6: Если вы: — проходили старые версии системного мышления — шли сами по руководствам или в группе самопрохождения — недопрошли второй семестр — или сейчас чувствуете, что «упёрлись» в потолок понимания Большинство из тех, кто сейчас заходит в R6, это как раз такие участники. ❗️Кому в R2: Если вы: — прошли самостоятельно или с наставником R1 — или хотите перестать «обсуждать» и начать влиять — или видите, что коммуникация — узкое место Одна из самых частых ошибок:

«я ещё дочитаю сам и потом зайду».

Теряется скорость, мышление "остывает" и ясность появляется не ДО, а ПОСЛЕ следующего шага. Что сейчас важно: R2: сегодня можно попасть на первый разбор R6: идёт финальный донабор из тех, кто проходил самостоятельно Запись — через бота: @SystemsSchool_bot

Когда команда осознанно делает несколько вариантов решения — это норма. Но когда один и тот же вариант решения переделывают снова и снова из-за "неминуемых ошибок" и "не учли" — это уже ошибки инженерного мышления. Если вы потратили время на три прототипа, а два выкинули — это очень хорошо! Если вы сделали две ошибки, а в третий раз "ура, получилось" — это плохо. И особенно плохо, что вы можете даже не знать, что делаете ошибки — ведь работа с ошибками это "как всегда" и "нормальная работа". Но именно из-за ошибок: • бесконечные уточнения и возвраты на доработку • переписанные задачи и возвраты на доработку • срывы сроков из-за возвратов на доработку Какие причины заставляют делать много вариантов — и это профессионализм, а какие причины заставляют переделывать по многу раз — и это пустая трата времени? В это воскресенье, 22 марта, в 11:30 на бесплатном семинаре в рамках программы рабочего развития, научный руководитель МИМ Анатолий Левенчук разберёт: • почему команды делают лишнюю работу • как отличить намеренный поиск лучших решений от ненамеренных ошибок • где именно и отчего появляется rework • классы распространённых ошибок • и как увидеть это в своём проекте, если ошибки тем и отличаются, что они невидимы (иначе бы их не делали!) Семинар будет интересен: • руководителям проектов • продукт-менеджерам • предпринимателям • инженерам-разработчикам • инженерам платформы Когда: 22 марта, 11:30 Формат: Online, Zoom Пререквизит: не требуется Ссылка на эфир, видео-запись и материалы будут доступны здесь, на канале Рабочего развития @mim_workdev.

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

«После нескольких резидентур понимаешь, что стал другим человеком. Просто начинаешь думать по-другому. Умнее, лучше.»

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

Раньше — бесконечные объяснения. После R2 — вижу с кем и какая модель сократит обсуждения.

R5 → R6 от отдельных моделей → к системному моделированию Инженерный проект (кейс):

Раньше обсуждали детали по кругу. После R6 могу направить общее обсуждение на любой уровень детализации без потерь.

R8 → R9 от личной квалификации → к передаче мастерства Руководитель команды (кейс):

Раньше сам делал лучше всех. После R9 начал инженерно выстраивать обучение команды

❗️Важная мысль Иногда люди переживают: "я не успел всё сделать идеально." Это нормально. Резидентуры — это не экзамен. Это процесс развития мышления. Если откладывать — теряется ритм развития, всё откатывается. Поэтому лучше идти дальше, даже если что-то не успели. Сегодня и завтра запись доступна через бота: @SystemsSchool_bot

Типовые организационные катастрофы в проекте без понимания целевой системы: 1️⃣ Программа изменений в компании Начинаем осваивать новую методологию работы. Три месяца идут: — воркшопы — обсуждения — обучение сотрудников ❌ Но поведение людей в работе почти не меняется. Проблема часто в том, что люди не могут переключиться с вопроса "за что платят деньги мне" на вопрос "за что платят деньги нам". 2️⃣ Стартап Основатели говорят: мы делаем сервис. Инвесторы обсуждают его как SaaS. Клиенты воспринимают его как обещание услуги. Программисты как сервер. Кажется, что все говорят об одном и том же. ❌ Но на самом деле обсуждаются разные объекты. Поэтому команда не может договориться, что именно является продуктом (это и есть целевая система) и какую пользу он создаёт, как его эффективно реализовать. Все делают разное, и это "разное" не стыкуется между собой. 3️⃣ Образовательный проект Команда инвестирует в платформу: — улучшает интерфейс — добавляет AI — развивает функциональность ❌ Но студенты всё равно не заканчивают обучение. Проблема в том, что платформа — это только часть системы создания. А целевая система — опять-таки снаружи: мастерство даже не студента, а выпускника. И тогда что будет целевой системой, за которую "платят деньги нам"? ___ Во многих проектах усилий прикладывается достаточно. Но команда не договорилась: что именно является целевой системой, какую работу она должна выполнять у клиента. 12 марта в 19:00 состоится индивидуальный разбор первого шага системного мышления в ваших проектах с научным руководителем МИМ — Анатолием Левенчуком. Здесь мы тренируемся выделять целевую систему в своем проекте, отделять важные разговоры от шума и на выходе получаем "лифтовый тест": можете ли вы за две минуты, пока едете в лифте с кем-то важным, рассказать о том, что вы делаете. ✅Участники любого уровня смогут: — системно рассмотреть свой проект (systems review), минимизируя риск катастроф в глобальных результатах — получить обратную связь по корректности целевой системы, значительно уменьшая разногласия — увидеть не только свой результат, но и понять процесс Стоимость участия — 12 000 ₽ Пререквизит: не требуется Формат: online, мини-группа 5 человек Оплата и доступ в чат через бота: @SystemsSchool_bot Меню: Оплатить → Резидентура / Практикум / Семинар → Разбор