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

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

На семинаре завтра, 07 апреля, в 17:00, будет редкая возможность задать любой ваш вопрос в таком же формате по своему проекту, конкретному методу, внедрению.

🔧 Не «как правильно», а:
⁃ как это делается на 19 командах и 48 продуктах
⁃ где не сработало
⁃ что пришлось переделывать
⁃ какие решения в итоге работают и почему

Ответ будет с разбором, как это было реализовано на практике.

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

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

______
Материалы вчерашнего семинара еще доступны через бота, можно подключиться и на практике освоить способ безошибочной работы с любыми решениями — сложными, зависшими, непонятными или новыми (через ИИ + FPF + понимание как можно самостоятельно углубиться в фреймворк, делающий AI-агентов умнее):

@SystemsSchool_bot

Оплата резидентуры/практикума/семинара — Как перестать переделывать и начать управлять результатом в работе: через критерии, варианты и AI

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

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

Можно опереться на опыт и выбрать “как привычнее”.

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

И в этот момент часто рабочим оказывается неочевидный, контринтуитивный вариант.

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

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

✅ Подключайтесь в чат участников — к чек-листу безошибочной работы, выложили пошаговый план "что делать, если вы уже в 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
→ Ссылка на чат

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

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

Как в недавнем примере на семинаре научного руководителя МИМ Анатолия Левенчука: станок приходится разбирать, чтобы поставить прокладку. Это стоит времени и ресурсов — потому что вариант не проверили до запуска.

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

На том же семинаре мы обсудили: один вариант решения — это ошибка. Идём дальше: что с этим делать в реальной работе?

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

Это уже меняется.

Руководители, продуктовые и техлиды начинают прогонять решения через 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

Запись будет здесь же, на канале рабочего развития @mim_workdev

Завтра разберём один конкретный момент, из-за которого работа уходит в доработки и уточнения.

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

Прочитайте сегодня — этого достаточно, чтобы завтра лучше “поймать” свой случай в разборе.

В 11:30 пришлём сюда ссылку на Zoom.
Будем разбирать online с автором руководств программы Рабочего развития А.Левенчуком, где у вас был выбор, а где ошибка стала видна слишком поздно.

Запись тоже будет здесь: @mim_workdev

❤3 быстрые проверки: где вы ищете решение, а где уже исправляете ошибку

Есть одна вещь, которую в рабочих командах часто вообще не различают.

Сделали один ход.
Потом второй.
Что-то уточнили.
Что-то переделали.

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

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

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

Мы подготовили короткий материал — 3 быстрые проверки: где вы ищете решение, а где уже исправляете ошибку.

Не длинная теория.
Не “10 шагов к эффективности”.

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

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

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

https://docs.google.com/document/d/1zVmzbxyWS6z86e9jUkOfeUVpzvTJq9FeXK0w36eqNK4/edit?usp=sharing

📍А дальше — подключайтесь на бесплатный семинар Анатолия Левенчука 22 марта, здесь же, на канале Рабочего развития МИМ.

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

И в какой момент команда перестаёт выбирать, начинает просто надеяться, что “в этот раз сойдётся🙏”.

Это один из тех случаев, когда онлайн важнее записи.

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

📌 Материал, видео-запись и ссылка на эфир будут здесь же — @mim_workdev

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

Если вы потратили время на три прототипа, а два выкинули — это очень хорошо! Если вы сделали две ошибки, а в третий раз "ура, получилось" — это плохо.

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

Но именно из-за ошибок:
• бесконечные уточнения и возвраты на доработку
• переписанные задачи и возвраты на доработку
• срывы сроков из-за возвратов на доработку

Какие причины заставляют делать много вариантов — и это профессионализм, а какие причины заставляют переделывать по многу раз — и это пустая трата времени?

В это воскресенье, 22 марта, в 11:30
на бесплатном семинаре в рамках программы рабочего развития, научный руководитель МИМ Анатолий Левенчук разберёт:
• почему команды делают лишнюю работу
• как отличить намеренный поиск лучших решений от ненамеренных ошибок
• где именно и отчего появляется rework
• классы распространённых ошибок
• и как увидеть это в своём проекте, если ошибки тем и отличаются, что они невидимы (иначе бы их не делали!)

Семинар будет интересен:
• руководителям проектов
• продукт-менеджерам
• предпринимателям
• инженерам-разработчикам
• инженерам платформы

Когда: 22 марта, 11:30
Формат: Online, Zoom
Пререквизит: не требуется

Ссылка на эфир, видео-запись и материалы будут доступны здесь, на канале Рабочего развития @mim_workdev.

Работа, которая меняет и проект, и способ мышления

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

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

Именно для этого существуют резидентуры.

Дмитрий, который проходит сейчас последние резидентуры, на одном из разборов с Анатолием сказал очень точно:

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

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

Рассмотрим подробнее кейсы и доступные сейчас резидентуры, на которые еще открыт набор до 16 марта.

R1 → R2
от управления хаосом → к управлению коммуникацией

Главное изменение — решения принимаются быстрее.

Руководитель продукта (кейс):

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

R5 → R6
от отдельных моделей → к системному моделированию

Инженерный проект (кейс):

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

R8 → R9
от личной квалификации → к передаче мастерства

Руководитель команды (кейс):

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

❗️Важная мысль
Иногда люди переживают:
"я не успел всё сделать идеально."

Это нормально. Резидентуры — это не экзамен. Это процесс развития мышления. Если откладывать — теряется ритм развития, всё откатывается.

Поэтому лучше идти дальше, даже если что-то не успели.

Сегодня и завтра запись доступна через бота: @SystemsSchool_bot