ScrumTrek

«Где теперь брать джунов?» — решённая задача!!! Но не у нас ) Да, вы слышали же этот плач сто раз. Джуны вымирают: всю рутину, на которой они росли, забрал ИИ. Никто больше не пишет руками 😭ыыы, а значит, никто и не научится. А что будет, когда ИИ на полдня приляжет? Мы кластер Kubernetes сами не поднимем, стыдобища 🙃)) Что помогает? Посмотреть на тех, кто этот путь прошёл до нас. Пока мы тут открываем Америку, кто-то уже лет сорок как живёт в этом будущем.  Это станочники-работяги на заводах.  Короче, раньше токарь точил деталь руками: крутил маховики, чувствовал металл, ловил подачу на слух. Пришло ЧПУ — и станок режет точнее любого мастера. И у токарей встал ровно НАШ вопрос: а надо ли теперь новичку уметь точить руками? Или сажаем сразу за ЧПУ и не паримся? Товарищи до сих пор срутся на эту тему, натурально, прямо на форумах. «Без ручного опыта ты кнопкодав (button pusher) — сломаешь дорогой инструмент, потому что не чувствуешь, как гнётся резец!!!». Другие: «да ручная токарка — это как учить счеты, когда есть калькулятор, учи сразу ЧПУ!!!». Один в один наш спор про то, заставлять ли джуна писать код руками.  Но это форумы. А что с индустрией? ИХ отрасль этот вопрос давно закрыла системно.  Работу развели на две роли. Оператор (CNC operator) — тот самый кнопкодав: загрузил деталь, нажал старт, следишь. Вошёл с улицы, обучение на месте, потолок низкий, прайс мелкий. И станочник (CNC machinist) — который налаживает, ловит брак, чинит, когда станок дурит. Вот он уже судит, а не жмёт кнопку. А между ними — ЛЕСТНИЦА. Но в чем ее особенность? В Штатах есть стандарт NIMS, живёт с 1995 года. Учат так. Сначала фундамент — слесарка, измерения, ручная обработка, потом ЧПУ. Штук двенадцать ступеней, каждую надо сдавать руками.  Отрасль давно поняла простую вещь: завод сам из кнопкодава мастера не растит.  Российский программист учился кодить на практике (типа «постоит у станка — научится»). Теперь так не получится. Суждение не капает из стажа. Его нужно ставить специально! Ну так вот и весь ответ на наш плач. Джуны не вымрут — просто их теперь двое. ИИ-вайбкодер, который промптит и принимает. И ИИ-станочник, который умеет сказать, годный код или мусор, и почему. Тот, кто в три часа ночи поднимет кубер ручками, — это второй. И растить его надо не в стиле «посидит рядом с ИИ и наберётся», а лестницей обучения, где суждению учат в лоб. Наверное и у нас так будет. У них не развалилось и у нас не развалится.  Если что — реддит, где токари рубятся про «руками или сразу ЧПУ»: r/Machinists

🤩Для нас сеттинг — это целая история, которая проходит через всё мероприятие: от оформления площадки до активностей, мерча и деталей, которые участники замечают уже на самом фестивале. За последние годы мы успели побывать в аэропорту, отправиться в путешествие по Неве, вдохновиться джазом и даже китайской культурой. Вчера концепция AgileDays ФЕСТ 2026 наконец была утверждена. Пока можем сказать только одно: в этом году нас особенно вдохновляют места, где связь иногда пропадает, разговоры становятся откровеннее, а самые ценные открытия случаются по пути к главной цели. Хочется, чтобы после фестиваля каждый увёз с собой не только новые знания, но и то самое чувство, которое появляется после хорошо пройденного маршрута. Остальное — чуть позже. Пусть часть пути всё-таки останется сюрпризом для всех участников! Уже догадались, какая главная тематика ФЕСТА будет в 2026?

Вечер пятницы, ура! Легкий по стилю изложения, но глубокий по смыслу пост: про выгорание, AI и как это все победить. Пойдемте отдыхать, а Сережа за нас подумает! 😉

Когда Scrum только появлялся, его целью было не заставить команды проводить стендапы, а помочь компаниям перестать тратить время на работу, которая не создаёт ценности. Прошло 25 лет. Вопрос остался тем же: Если завтра убрать половину процессов в вашей компании, клиент вообще заметит разницу?   Готовьтесь к жарким спорам на AgileDays FEST

Кто виноват, если налажал ИИ агент? Deloitte так формулирует: агент — ни капитал, ни труд. Ведёт себя как работник, а куплен как софтина. Идеальный безответственный. Кто отвечает за его решения? За риск? За качество? Почти везде сейчас по факту НИКТО. Купило IT — значит, «это к айтишникам». Поставил вендор — «это к вендору». А клиент, которому агент нахамил или слил лишнего, — он же не к IT приходит. Значит структуру ответственности надо переделывать. Теперь смотрите, что говорят цифры. Только 6% компаний доверяют агентам вести ключевые процессы сами. При этом 84% так и не переделали ни одной должности под ИИ. То есть агентов насажали, а оргструктуру не тронули 🤯 И теперь у нас в индустрии новая игра: придумывать роли под агентов. Agent Supervisor, Eval Owner, Exception Handler, Human-in-the-Loop Reviewer.  Свёл всё это в систему Cloud Radix — небольшая консалтинговая контора по ИИ. Роли они собрали из свежих разборов MIT Technology Review и Deloitte чтобы вам не пришлось запускать deep research Кто есть кто, если коротко: — Agent Supervisor — надсмотрщик за флотом агентов: следит за выработкой, качеством и деградацией (drift). — Eval Owner — определяет, что такое «хороший результат», и держит набор тестов качества. — Exception Handler — разгребает краевые случаи, которые агент зафлагал или завалил, и владеет эскалацией. — Human-in-the-Loop Reviewer — аппрувит или режет высокорисковый вывод до отгрузки (юр, мед, финанс). Вся эта россыпь сводится к трём вопросам про ответственность: 1️⃣ Кто владелец? У КАЖДОГО агента должна быть фамилия человека, который за него отвечает. И сидит он не в IT, а в той функции, что жрёт его результат. IT агента строит и чинит. Отвечает — владелец. 2️⃣ Кто определяет, что «хорошо»? Это тот самый Eval Owner. И это, между прочим, единственная ПО-НАСТОЯЩЕМУ новая работа во всём списке — остальные это переименованный менеджмент. 3️⃣ Кто ловит косяки? Кто разгребает краевые случаи и аппрувит рискованное до того, как оно улетит клиенту. У нас в Oper8 это «владелец процесса» — человек от бизнеса, у которого появился подчинённый, который не спит, не устаёт и иногда так уверенно несёт чушь, что ему еще три роли на обслуживание дают)). Источник: Rethinking Org Design for Agentic AI (Cloud Radix, 2026) https://cloudradix.com/blog/rethinking-org-design-agentic-ai-mid-market-2026/

Вопрос «Кто такой Владелец продукта в Scrum?» в наших компаниях до сих пор вызывает бурю эмоций и путаницу. Поэтому решили освежить эту тему в вашей памяти как очень важную для карьеры и понимания своих реальных полномочий 🧠✨ Если почитать историю того, как создавался Scrum, то вот такие инсайты вполне могут перевернуть ваше представление о роли Владельца продукта: 1⃣ PO не было в самом начале В первом документе по Scrum (1995 год) продуктом управлял Менеджер. Но быстро поняли: когда стейкхолдеров много, нужен один человек, который будет единолично расставлять приоритеты и говорить «нет». Так в 2001 году появилась фигура Product Owner. 2⃣ Изначально PO задумывался как «мини-CEO» Создатели Scrum (Кен Швабер и Джефф Сазерленд) закладывали в эту роль колоссальную мощь. В ранних книгах PO отвечал за финансирование, ROI (возврат инвестиций) и напрямую отчитывался перед топ-менеджментом. Более того, в 2021 году сам Джефф Сазерленд признался: он создавал PO с бОльшей ответственностью за стратегию и доходы, чем у классического Product Manager! 3⃣ Как корпорации «урезали» роль В более поздних версиях Scrum Guide (2010-2017) из описания PO исчезли слова про ROI и бюджеты. Их заменили на мягкое «максимизация ценности продукта». Авторы Scrum сделали это намеренно, чтобы бизнес не пугался радикальных изменений и чтобы Scrum можно было применять в разных контекстах: от небольших стартапов до крупных корпораций. 4⃣ Роль против подотчетности (2020 год) В последней версии Scrum Guide создатели отказались от слова «роли» и ввели «подотчетность» (accountabilities). Суть проста: вы можете делегировать команде исследование, аналитику и даже часть бэклога. Но ответственность за ценность и результат остается лично на вас. 💡 Главный вывод для нас: Настоящий Product Owner — это стратег, который объединяет взгляд рынка, клиентов и бизнеса, а не «человек, который красиво описывает таски в Jira и следит за спринтами». Сталкивались с такой путаницей на практике? Часто ли у нас PO наделяют реальными полномочиями «мини-CEO», или у нас они просто «приоритизаторы бэклога»? Делитесь в комментариях, знаем, что в многих компаниях там настоящие корпоративные детективы! 💬 А если вы хотите почитать про разницу ролей PO и PM, напоминаем про одну классную статью – читать

Помните исследование, которым год пугали любителей ИИ? Оно только что шикарно развалилось Есть такая контора — METR. Правда очень крутые ребята, тестируют ИИ в разных сценариях. Летом 2025 они выкатили рандомизированное контролируемое исследование, всё по красоте. Участвовало 16 опытных разработчиков, Cursor + Claude. Результат: с ИИ они работали на 19% МЕДЛЕННЕЕ, чем без него 😬. А сами разработчики были уверены, что ИИ их УСКОРЯЕТ процентов на 20. То есть ощущение скорости и скорость поехали в разные стороны.  Читали, наверняка ))  Теперь прикол.  METR запускает второй заход — новые модели, побольше народу. И в феврале 2026 честно пишет: слушайте, а мы не можем закончить эксперимент. Потому что разработчики ОТКАЗЫВАЮТСЯ работать в условии «без ИИ». 30–50% участников признались, что специально не подают часть задач — просто чтобы их не заставили делать руками. Один сформулировал кмк гениально: «У меня голова взорвётся, если делать по-старому. Это как идти пешком через город, когда ты уже привык ездить на Uber.» Вот и весь эксперимент 🤷‍♂️. Оч хочется глазки приподзакрыть на сопутствующие обстоятельства, но удержусь. METR все-таки НЕ доказал, что «теперь ИИ ускоряет на 18%» — у них там доверительные интервалы недостоверные (через ноль), оплату срезали втрое, куча оговорок. Как чистое РКИ — это провал, и они сами это признают, молодцы канеш 🤝. Но все-таки развалилось оно НЕ ОБ МЕТОДОЛОГИЮ. Люди ПРОГОЛОСОВАЛИ НОГАМИ. Довод «ИИ замедляет разработчиков» умер потому что подопытных невозможно затащить обратно в контрольную группу )). Так что когда спорите про ИИ цифрами двухлетней давности — проверьте, живы ли ещё те цифры. А то мир меняется быстрее, чем выходит препринт 🙂

Agile больше не трансформация, а гигиена: запуск продуктового подхода в MAGNIT TECH за год Бэклоги, спринты и демо давно перестали кого-то удивлять. Сегодня всё это есть во многих командах, но возникает другой вопрос: Почему даже при наличии Agile-практик компании продолжают сталкиваться с конфликтом приоритетов, борьбой за ресурсы, разрывом между стратегией и реальной работой команд? На AgileDays ФЕСТ 2026 Александр Бульдяев и Залина Сланова из MAGNIT TECH расскажут в своём докладе, как за год запускали продуктовый подход в большой технологической организации и с какими вызовами столкнулись на этом пути. Без историй про идеальную трансформацию, зато с практическим взглядом на то, какие элементы действительно важны на масштабе: продуктовые метрики, приоритизация, квартальный ритм, портфельное планирование, capacity management, discovery и delivery. Отдельно коллеги поговорят о том, почему крупным компаниям всё реже подходит «чистый Scrum» и всё чаще требуется собственная система управления, собранная из разных практик под конкретные задачи бизнеса. И, пожалуй, самый интересный вопрос в рамках доклада: Можно ли за один год запустить продуктовый подход, увидеть первые результаты и создать общий язык внутри компании? Или это только начало гораздо более длинного пути? Обсудим на AgileDays ФЕСТ 2026.

Идея подарка корпоративным труженикам. Задумывались, что "говорить" и "работать" - это два разных слова и действия и не всегда они должны совпадать? Довольно часто, когда мы консультируем клиентов в части настройки операционного ритма команд или больших структур и презентуем набор необходимых каденций, нам говорят "эээ, еще и эти встречи, а работать-то когда?". Ответ как правило шокирует и звучит так: "в нормальной команде кроме этих встреч других-то, в целом, и не должно быть". Потом требуется примерно 5 минут дополнительных объяснений и споров, чтобы ув. представители клиента допустили, что такое теоретически возможно. Но веры в этот дивный мир, где у тебя нет 4-5 встреч в день... Эту веру приходится добывать фактурой в процессе работы. И видели бы вы счастливые лица людей, которым больше не надо тратить половину жизни на зум-звонки!

Во время кризиса эффективность становится главным залогом выживания компаний. Но как в погоне за результатами не забыть о стержне любого бизнеса — о людях?    Последнее время часто получаем такие вопросы от наших корпоративных клиентов и решили напомнить вам, что у нас есть классный видеокурс, в котором, по нашему скромному мнению, мы четко ответили на этот вопрос: Бесплатный видеокурс тут 🧑🏻‍🏫 В теме «Люди как основа гибкой компании» поговорим о задачах управления в кризисный период: — как выбрать лучшую практику человекоориентированного управления командой и компанией;  — как в условиях массовой миграции сотрудников не потерять наработанные командные связи и как в новом контексте выбрать подходящую стратегию назначения вознаграждений. 🌱Тема «Стратегии стрессоустойчивости» целиком посвящена важному препятствию для эффективности — стрессу. «Под микроскопом» разберём что такое стресс, как справиться с ним самостоятельно и помочь в этом сотрудникам или сокомандникам.