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

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

«Как это применять?»

Но действительно интересны обычно другие моменты: ⁃ где это ломается ⁃ что и когда не работает ⁃ как понять, что ты делаешь не то ✅ Напоминаем, что перед сегодняшним семинаром можно задать именно такой вопрос (вот здесь) и получить разбор на практике. Не общий ответ, а: ⁃ что делать ⁃ где проверять ⁃ где обычно ошибка

На видео фрагменты обсуждения в 2024г. и ранее, о применении руководств Рабочего развития в реальных системах. На семинаре завтра, 07 апреля, в 17:00, будет редкая возможность задать любой ваш вопрос в таком же формате по своему проекту, конкретному методу, внедрению. 🔧 Не «как правильно», а: ⁃ как это делается на 19 командах и 48 продуктах ⁃ где не сработало ⁃ что пришлось переделывать ⁃ какие решения в итоге работают и почему Ответ будет с разбором, как это было реализовано на практике. Ссылка на список вопросов, где можно добавить свой: https://docs.google.com/document/d/1-HCHeIzVatRhflnso8EEHyh1gXelcoR20pSMJbxyyec/edit?usp=drivesdk Вчера на семинаре разбирали глубже, как проверять решения до запуска в ИИ, через 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-агентов. Как в громком примере, когда генеральный директор 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.