Marat @ Predictable.Team

В этом году выступаю с темой про эффективность команд на Merge Innopolis. Забабахали промо-код со скидкой на покупку билетов на конференцию. ___ До профессиональной ИТ-конференции Синтез | Merge в Иннополисе осталось меньше месяца Программа события готова и уже на сайте. В этом году конференция пройдет в Республике Татарстан в пятый раз и традиционно не ограничивается одним направлением, а соберет на одной площадке весь спектр ИТ. К конференции уже присоединились специалисты из 50+ городов России — от Владивостока до Калининграда. Что ждет участников: — 170+ докладов от экспертов из 100+ передовых компаний; — Только разбор реальных кейсов, без воды и общеизвестных фактов; — Живой и открытый нетворкинг с лидерами отрасли; — Возможность посетить первый в России наукоград для ИТ-специалистов. Для кого: В числе участников конференции — разработчики, тимлиды, тестировщики, топ-менеджеры, собственники бизнеса, маркетологи, HR-специалисты, аналитики. Программа сформирована так, чтобы новые знания, полезные контакты и ценные инсайды увез с собой каждый. Подобрее о конференции на официальном сайте. По промокоду UFA действует скидка 15% на билеты.

Открываем Agile Ufa 2026 с митапом "Как меняется работа с качеством в эпоху ИИ" 🗓 9 апреля, 19.30 🗺 Верхнеторговая 6, БЦ Нестеров, 4 этаж. Подискутируем и рассмотрим, как будет меняться и уже меняется парадигма работы с качеством в SDLC 📣 Обсудим: - Как трансформируется роль и обязанности QA в эпоху AI-SDLC - Какие изменения ждут другие роли в команде - Как изменилась ваша роль в команде по мере внедрения AI в процесс разработки. 👉 Регистрация здесь по ссылке на Timepad

Если вы в Уфе, и если вы читали статью выше - то определенно приходите подискутировать с QA-сообществом "Как меняется роль и работа с качеством в эпоху AI-инструментов"! Тема наболевшая, открываю первый митап Agile Ufa этого года актуалочкой.

Перевел очень холиварную статью, которую мы супер часто в последние пару месяцев обсуждали и в проф. сообществах, и на работах, и даже в коворкинге. Она вкратце про то, что: ☠️ SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули. - Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого. - Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом. - Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability. 🌱🤖 Новый жизненный цикл — это узкая петля:  Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

Сегодня подытоживаем тему про важность достижения целей для эффективных команд статьей на Хабре :) призываю дискутировать в комментариях и лайкать за букву “ө” в слове “өчпочмак” https://habr.com/ru/articles/1011932/

Решил с вами поделиться тем, что рассказывал на конференции: 🔥 Эволюция приоритизации: от харизмы стейкхолдеров к ROI Представьте продукт с 50+ стейкхолдерами и все одновременно чего-то хотят 😅 Можно нанять больше людей. Но если нет фильтра на входе, задач всегда будет больше, чем ресурсов. За 3 года мы прошли путь: Квоты → RICE → ROI Расскажу как это было. 🧩 Вызов №1. 50+ стейкхолдеров на один продукт На 2022 год у нас было: - 12 продуктовых команд и - 200 участников, - Более 30 бизнес-заказчиков, - 5 архитекторов, - И 20 связанных приложений и подсистем. Все заинтересованные лица приходили с задачами. У всех «срочно» и «очень важно». Понятно, что у каждой из продуктовых команд не более 10 стейкхолдеров, но и это всё равно очень много. На этом этапе ключевая проблема была не в выборе лучшей задачи, а в том, что: - команды физически не могли взять всё; - давление на команды росло. 📊 Решение №1. Квоты Первым шагом стали квоты по capacity: - Бизнес-задачи - Запросы от других приложений - Развитие платформы - Техдолг и инциденты - Буфер под неопределённость 🎯 Результат: - стало прозрачно, сколько команда реально может взять; - снизилось давление со стороны стейкхолдеров; - исчезла гонка «кто первый занял весь capacity». Важно: Квоты не решают приоритизацию. Они просто убирают первый слой хаоса. 👩‍🎤 Вызов №2. Приоритизация на основе харизмы В 2023 году всплыла новая проблема: lопустим, к одной команде приходят 5 архитекторов: - один топит за микросервисы - второй за дизайн-систему, - третий за PCI DSS - и т.д. Квота на платформу ограничена, а все задачи «важные». И что происходит? Берут задачу того, кто убедительнее говорил. Я назвал это «приоритезация на основе харизмы» 🕺 📊 Решение №2: RICE Мы внедрили приоритезацию на основе RICE:

RICE = Reach × Impact × Confidence / Effort

Reach - охват Impact - влияние на ключевую метрику квартала Confidence - уверенность в оценке остальных показателей Effort - трудозатраты Что изменилось: ✅ споры превратились в структурированное обсуждение ✅ решения стали проверяемыми ✅ стресс у команд снизился ✅ начали учитывать трудозатраты, а не только «важность» 🎀 Вызов №3. «Бантики» против ценности 2024 год: Одна команда завалена сверхценными инициативами. Другая - делает «бантики», потому что у неё в зоне ответственности всё самое важное уже сдеалано. Это локальная оптимизация. 💰Решение №3: Сквозная приоритезация по ROI Нужен был объективный показатель, позволяющий сравнить задачи разных команд между собой. И этот показатель — деньги. Именно так мы выбрали показатель ROI.

ROI = (Эффект − Инвестиции) / Инвестиции × 100%

Эффект - рост дохода или снижение затрат Инвестиции - стоимость реализации Что это дало: 🔥 сравнивать задачи между командами; 🔥 передавать самые ценные инициативы в команды, где в беклоге менее ценные задачи; 🔥 отсекать убыточные задачи ещё до реализации; 🔥 приоритезация ROI более точный и объективный показатель, чем RICE. 🧠 Что мы поняли за 3 года 1️⃣ Квоты - хороший временный инструмент, но они не заменяют экономическую модель. 2️⃣ Визуализация приоритетов резко снижает градус конфликтов. 3️⃣ ROI — самый точный инструмент, но он требует ресурсов. Для растущих продуктов часто достаточно RICE, но на масштабе без денег не обойтись. Если приоритеты всё чаще определяются «громкостью голоса», а не ценностью — поздравляю, вы доросли до следующего уровня зрелости 😉 Больше интересного на канале Продуктовая трансформация #УправлениеЛюдьми #БольшиеПродукты

Хочу попиарить канал который сам читаю - и прекрасный пример интересного поста. Мы познакомились с Денисом на Agile Random Coffee с год назад, у него канал по продуктовой трансформации. Он сейчас работает в АйТи дочке Вкусвилла. Пост классно описывает путешествие - какие модели приоритизации применяли на практике, где они применимы и почему в итоге пришли к текущей :)

Товарищи, в этом году выступаю на DUMP Ekb (который состоится 24 апреля 2026) Если кто-то собирался поехать, но не купил билеты - то вам промокод на 10% KINIABULATOV https://dump-ekb.ru

🧑‍🚒 Сигнальная система: как узнать о том что цели не достигаются чаще чем раз в квартал. В прошлых постах: • 👍 QBR выравнивает руководителей раз в квартал. • 👎 Но проблема на 3-й неделе спринта не дождётся следующего QBR. Нужна сигнальная система снизу — чтобы риски всплывали раньше. Поэтому - каждый спринт (или каденцию) мы делаем ревью достижения целей уровне команды. Вы можете использовать формат анализа - стали ли вы ближе по KR (если используете OKR), или руководствоваться старым добрым светофором • 🟢 По плану — цель будет достигнута • 🟡 Риск — нужна помощь или решение (но вроде бы успеваем) • 🔴 Критично — без вмешательства не успеем Самая маковка: ваши Sprint Review (обзоры спринта) идеально для этого подходят. • На них вы снимаете фидбек с пользователей по использованию вашего продукта • Смотрите где вы по роудмапу уже находитесь и стоит ли его поправить из-за фидбека 🛣 При этом на те же цели и их статус круто смотреть и на планировании (так как цель спринта - прямая производная от квартальной/годовой цели). А на ретроспективе - посмотреть на причины опоздания по целям. Но перед этим надо правильно настроить... 🛣 ..трассировку от цели организации до каждой задачи Помните, мы говорили что без понимания каждым сотрудником цели - хороших результатов с вовлеченными людьми мы не достигнем? Каждый сотрудник должен видеть: "зачем я это делаю?" Путь: задача → цель спринта → цель квартала (или прогресс по KR) → цель организации (objective). • Если путь очевиден — работа имеет смысл. Человек понимает ценность. • Если путь неочевиден — это сигнал задать вопрос: «Какого хрена мы это делаем?» 🔜 Когда команда видит связь между задачами и целями, происходит сдвиг: • Раньше: делаем задачи → надеемся, что это приведёт к цели • Теперь: видим цель → замечаем, что задачи идут в другую сторону → предлагаем альтернативы Так мы формируем вовлечённость изнутри. Команда, которая видит расхождение и может предложить решение — это совершенно иной уровень мотивации. Нам с вами важно сделать 🤯 культурный сдвиг (который заставит сигнальную систему снизу работать на предотвращение невыполнения целей) в мышлении команды. • Красный ≠ провал. Красный — это сигнал о помощи. • Скрывать проблемы = узнать о потенциальном срыве в конце квартала. • Показать красный вовремя = получить помощь и успеть. • Честность важнее зелёного цвета. ⚙️ Механика обзора статуса по целям • Sprint goal (цель спринта) привязана к квартальной/годовой цели • В конце спринта — статус светофора (по цели или KR) • Жёлтый/красный — эскалация или запрос помощи • Надо эскалировать конкретно: «ждём ответ ИБ 5 дней, блокирует 3 фичи». А не эти ваши "ой, все сложно, команда Васи Пупкина как обычно нас игнорит". ⛓️ Вот мы и прошлись по двум петлям обратной связи • Петля "сверху-вниз" через QBR руководителей, раз в квартал • Петля "снизу-вверх" через обзор светофора команды, каждый спринт (каденцию) 🤝🤝 Вместе они создают систему, где проблемы видны до того, как станут настоящими проблемами. 👍 Больше про целеполагание и системную работу с эффективностью команд в блоге Марата Киньябулатова про предсказуемые команды

QBR: как проводить обзор целей и извлекать из него полезную информацию (+ 🎁бонусом шаблон для мультикомандного обзора целей в комментариях) В прошлом посте: зачем нужен QBR — параллельные велосипеды, системные блокеры, руководители в пузырях. Теперь — как его проводить. Здесь и далее: QBR и OKR Review тождественны. В OKR Review добавляется количественный показатель (как как он обязателен). Минимальный формат • Частота: 4 раза в год (можно комбинировать онлайн и оффлайн) • Длительность: от 2 часов (просто пробежаться по целям) до 6 (с доп. фасилитацией) • Инструменты: светофор целей (must), остальное по необходимости Светофор целей Главный инструмент QBR — визуальный статус каждой цели: Формат: Цвет - Статус - Что делаем 🟢 Зелёный - Всё по плану - Делимся практиками — что сработало 🟡 Жёлтый - Риск срыва, но годовую цель закрыть успевам - Обсуждаем, ищем поддержку 🔴 Красный - Критично - Эскалируем, открыто обсуждаем варианты решений, запрашиваем помощь. Важно: красный — это не провал. Это сигнал о помощи. Логика: Скрывать проблемы = узнать о срыве в конце квартала. Показать красный вовремя = получить помощь и успеть. Эволюция участников • Старт: руководители команд + их руководители • Со временем: расширяйте до представителей смежных отделов (ИБ, инфра, юристы, закупки). Иначе получите ловушку: внутри вы согласованны, а критичные части общего end-to-end — нет. Узкие места всегда на стыках. Два режима QBR 1️⃣ Начало года — постановка целей Каждая команда отвечает на вопросы: • Вектор работ — какие крупные направления видим на год? • Фокусы — что входит в этот вектор, на чём концентрируемся? • Как драйвим — каким образом команда будет двигать эту повестку? Выравнивание: На этом этапе сверяемся — не делаем ли одинаковую работу с соседями? Нет ли пересечений? 🕸 Зависимости: Критичные зависимости от соседних команд — что нужно и когда Зависимости от других отделов вне департамента Риски: Какие видим? Что будет, если не проработаем? 2️⃣ В течение года — обзор статуса (Q1, Q2, Q3) Цели уже поставлены. Теперь смотрим: • Светофор целей — кто зелёный, жёлтый, красный • Общие затыки — где застряли, что мешает • Выученные уроки — что сработало, что нет • Системные паттерны — похожие проблемы у разных команд Обстукиваем друг об друга: «У нас такая же проблема — как вы её решили?» 💰 Бонус: фасилитации Раз собрались таким составом — используйте (дорогущее) время по максимуму. Проведите 1–2 фасилитации по самым горячим темам: • По вершинам «Учпочмака» — цели, люди, предсказуемость • По другим вызовам перед организацией или отделом Это редкая возможность собрать всех лидеров в одной комнате. Не тратьте её только на статусы. В следующий раз обсудим: почему раз в квартал - это слишком редко. И как с этим работать.

🗓 QBR: зачем собирать руководителей раз в квартал В прошлом посте: только 9% сотрудников согласны с тем, что цели их команды двигают организационные. Остальные 91% оптимизируют что-то своё. Нужен механизм синхронизации. Внедрить культуру согласованности на уровне 45 команд — долго и дорого. Но есть путь короче. TL;DR: В этом посте разберем как QBR выравнивает руководителей + и два кейса из опыта когда экономически мы очень выигрывали от проведения таких сессий. ⚖️ Принцип Парето Собрать 10-15-50 руководителей на один день в квартал — реалистично (особенно онлайн). Если их выровнять - то можно получить эффект на масштабе всей организации. Выравниваемся с помощью QBR (Quarterly Business Review) — квартальный обзор бизнеса. Что видно только сверху (и сразу) 🚲 Проблема 1: Параллельные велосипеды Кейс: Пример, основанный на реальных событиях (но с другой предметной областью). Две команды параллельно разрабатывали системы управления лимитами — для кредитных карт и для расчётных счетов. • Обе по 7–8 человек, каждая ≈ 3,5 млн ₽/мес (опять аппелируем к исследованию зарплат hh / habr 2025) • Работали независимо 3 месяца • На QBR выяснилось: функциональность на 70% пересекается Потери (все подсчеты максимально упрощены): • Общая стоимость разработки: 2 команды × 3.5 млн × 3 мес = 21 млн ₽. • Поскольку функционал пересекался на 70%, только на задвоении работы компания потеряла больше 7 млн ₽. • Плюс задержка выхода на 1–2 квартала. Если бы QBR прошёл до старта: одна команда, одна архитектура, десятки миллионов сэкономлены. 💣 Если честно, там потом оказалось что этого вообще делать не надо. Так что настоящие потери: 21 млн. ⚛️ Проблема 2: Системные блокеры Кейс: На QBR выявился паттерн — 6 из 14 команд красные по одной причине: долгий найм (4–5 месяцев на вакансию). На уровне команды каждый думал: «HR медленно работает, надо пинать». Это прямо в графе в причинах невыполнения Key Results для Целей писали. На уровне системы стало видно: • Один HR на все направления • Длинная цепочка согласований • Конкуренция команд за одних кандидатов Решение через QBR: эскалация → квартальное планирование найма → предварительно одобренные позиции → выделенный рекрутер. ∆ до и после: • Время закрытия вакансии 4–5 мес -> 6–8 недель • Команды в красной зоне 6 из 14 -> 1 из 13 (одну по пути сократили) • Отказы кандидатов 35% -> 12% Принцип Парето: 20% усилий на одно системное решение = 80% результата для 5 команд. 🫧 Почему руководители в пузырях Каждый погружён в свой контекст (от состояния и мотивации команды, 1-1, целей, смежных систем, сложностей в аппруве архитектуры, you name it!). Видит только свою часть. QBR выводит из пузыря: когда команды проговаривают планы вслух, остальные видят картину целиком. 💵 Экономика Один QBR, который предотвращает «параллельные велосипеды», окупает все затраты на координацию на год вперёд. А еще в стартапах и не только на QBR классно смотреть на продуктовые инициативы которые вы реализовали и проверять их ROI (стоило их вообще делать или нет, ожидаемый результат получили или нет). О механике такого процесса я писал здесь. В следующем посте — как проводить QBR: формат, светофор целей, два режима работы.

🏔 Почему цели важнее всех остальных вершин: пять исследований В прошлом посте я сказал что для эффективности команды важен порядок: цели -> люди -> предсказуемость. Многие ставят во главу угла людей, но все таки команда нанимается из экономических соображений. По этому поводу есть много исследований, подтверждающих этот порядок. Сегодня рассмотрим кратенько пять из них: 🏫 1. Ричард Хэкман (из Гарварда) Автор модели «5 условий эффективности команд». Второе условие — Compelling Direction (ясное направление). Оно стоит ПЕРЕД поддерживающим контекстом (атмосфера) и коучингом (рост и обучение). «Чини контекст и структуру до того, как отправлять команды на тренинги — иначе лечишь симптомы, а не причины» 🏫 2. Эми Эдмондсон (тоже из Гарварда ) Автор концепции психологической безопасности. Первый шаг её метода «Set the Stage» начинается с цели: • Зачем мы здесь? • Что на кону? • Для кого это важно? Цель создаёт контекст, в котором безопасность имеет смысл. Без цели работа над безопасностью — абстрактное «давайте будем за все хорошее, против всего плохого». 💼 3. McKinsey (Team Effectiveness Index) Четыре блока эффективности: • Alignment (ясность направления) • Collaboration (взаимодействие) • Execution (исполнение) • Innovation (инновации) McKinsey называет ясность направления — «первым и самым забытым шагом». 🧑‍🎓 4. CIPD (это как PMBOK, только от HR - Научный обзор 2024) Лидеры, задающие mastery goals (цели, направленные на развитие и результат), создают среду, в которой люди чувствуют себя безопаснее для рисков. Цели → Безопасность, а не наоборот. 📊 5. HEC Paris Business School (2024) Ясности целей и согласованность между проектом и целями организации увеличивают психологическую безопасность. Цели буквально порождают безопасность. 💾 Помните, мы говорили в прошлом посте: • Только 9% сотрудников считает что цели их команды согласованы с общеорганизационными. Так вот: это проблема самой архитектуры согласованности в организации. И начинать решать ее надо только с целей. Без этого пререквизита работать с остальными вершинами смысла нет.

👩‍🔬Модель «Учпочмак» — три вершины эффективной команды Начинаем серию: Эффективные команды (1/n) Что такое эффективная команда?

Команда из семи инженеров обходится бизнесу в 30–40 млн рублей в год (статистика habr/hh за 2025 по средней зп). Организациям хочется понимать, что за эти деньги получаешь.

Последние 6 лет я работаю подразделениями с множеством команд. За это время дооформилась модель «Учпочмак» — треугольник с тремя вершинами. Название — от 🇷🇺 башкирской (ну ладно, еще и татарской) выпечки: если один угол испорчен, начинка вытекает. Три вершины 🎯 1. Цели: Команда достигает целей (Goal Achievement) Команда понимает, зачем она существует. Её работа привязана к бизнес-результату: выручке, конверсии, NPS. Цифры: • Только 9% сотрудников согласны, что цели команды соответствуют целям организации • Лишь 14% организаций: сотрудники хорошо понимают стратегию • Компании с понятным направлением вдвое чаще прибыльнее медианы • Конкретные, амбициозные цели повышают производительность на 11–25% 🦁 2. Люди: Команда мотивирована (Team Satisfied & Motivated) Команда способна выполнять цели регулярно. Для этого люди должны быть мотивированы, не выгорать, говорить о проблемах открыто. Парадокс Эдмондсон: высокоэффективные команды сообщают о большем количестве ошибок. Там безопасно признавать проблемы. Цифры: • Психологическая безопасность объясняет 43% вариации в эффективности команд • Команды с высоким доверием в 5.1 раза результативнее • Вовлечённость → -51% текучести, +23% прибыльности • Паттерны коммуникации важнее интеллекта и навыков 🌊 3. Метрики потока сбалансированы: Команда предсказуема (Predictability) Работа движется предсказуемо. Команда может ответить на вопрос «когда будет готово?» с разумной точностью. Метрики потока — приборная панель. Показывают, как работает двигатель. А вот куда едем — это вершина 1. Ключевые метрики: • Throughput — сколько единиц работы завершено за период • Lead Time — время от идеи до доставки клиенту • WIP — работа в процессе (единственный рычаг управления) Связь между ними описывается законом Литтла: Lead Time = WIP / Throughput. 👮‍♀️ Порядок важен 1. Сначала цели. Если непонятно, куда идём — быстрый поток не поможет. 2. Потом люди. Если команда боится говорить о проблемах — метрики будут скрывать реальность. 3. И только потом поток. Цели → Люди → Поток. 💡Главный инсайт Корреляция между хорошими метриками потока и достижением бизнес-целей — ниже 60% (как-нибудь напишу пост про свое мини-исследование на 500 человек). Можно иметь стабильный throughput, низкий cycle time, красивые дашборды. И делать не совсем то, что нужно бизнесу. Эффективность — баланс всех трёх вершин. Один испорченный угол — и учпочмак уже не тот. Про AI • 80%+ инженеров отмечают рост индивидуальной продуктивности с AI. При этом нестабильность доставки и выгорание остались на том же уровне. • AI усиливает то, что уже есть в команде.

Эффективные команды: выжимка из стрима с Андреем Посновым Сделал выжимку, чтоб вам не надо было включать ВПН для youtube 🙂 🥧 Модель «Эчпочмак» для эффективной команды Представьте треугольник (как наш башкирский (ну ладно, татарский тоже) эчпочмак). Если один угол с дефектом — всё испорчено. Вот и у команды три вершины: 1️⃣ Достижение целей — команда делает то, что нужно бизнесу 2️⃣ Довольные люди — мотивация без выгорания 3️⃣ Предсказуемость — стабильные метрики потока Многие команды работают по схеме: «цели есть, но никто их не понимает». Результат: 50-70% работы уходит не туда (это из нашего с Андреем опыта в MetaMap). 🥕️️️️️️ Как объяснить цели команде Не надо читать лекции про миссию. Надо: • Показать, как задача влияет на конверсию/деньги • Привести на ревью реальных клиентов — пусть разработчики увидят, как люди страдают • Дать end-to-end ответственность за фичу (от идеи до метрик на проде) Когда человек понимает, что его тикет влияет на годовой доход от клиентов в Мексике — мотивация другая. 📊 Метрики потока vs Стори поинты Если команда их использует — отлично. Если нет — тоже норм. Главное — предсказуемость, а не скорость. Вам важно знать: • Сколько задач делаете за спринт (throughput) • За какое время задача проходит от «в работе» до «готово» (cycle time) • Норма: ±20% отклонения от плана — это ок для индустрии. • Инструмент: JiraMetricsPro — показывает всё из коробки, Predictable.Team, в Jira тоже дофига возможностей. 🤩 Парадокс Эдмондсон Исследование Стэнфорда: в высокоэффективных командах люди сообщают об ошибках чаще, чем в малоэффективных. • Почему? Потому что там безопасно говорить о проблемах. Не боятся, что их обвинят. • Задача лидера - сделать безопасную среду. 😱 Scrum vs Kanban — что выбрать? Не важно. Выбирайте то, что нравится команде. Разница: • Scrum = push-система (запихнули работу на 2 недели) • Kanban = pull-система (взяли следующую задачу, когда есть слот) Оба подхода пришли к одним метрикам потока. Главное — цель выполнять, не гореть и быть предсказуемыми. 👍 Совет начинающим руководителям команд • Пойми, как твоя команда приносит пользу бизнесу • Расскажи команде, куда едет компания • Узнай, чем живут твои люди • Научись давать обратную связь (это отдельный навык!) • Выясни ожидания своего руководителя — вы партнёры 🎁 Бонус: тренд на продуктовость Код написать — не проблема, есть Claude. Проблема — понять, что делать и на какие метрики бизнеса это повлияет. Технические специалисты всё больше становятся продуктовыми. Это неизбежно. • 🎤 Полная запись стрима на YouTube • 📣 Канал Андрея • 📝 Подробнее про метрики потока — в моём канале @predictableteam

Всем привет! Стрим будет уже через 5 минут в Zoom - где мы с Андреем поговорим про эффективные команды. • 22:00 Уфы • 20:00 Москвы Upd: стрим закончился. Спасибо что пришли)

🔥 Стрим: Как строят High-Performance команды (и как это поможет вам быстрее расти) Когда-то мы работали вместе с Маратом, его канал @predictableteam и во многом именно благодаря его подходу и экспертизе я смог вырасти из тимлида в Engineering Manager. (Его интерактивные сессии для команд и тимлидов/менеджеров помогли понять, что надо бизнесу и для роста в айти) Сейчас Марат - крутой Agile Coach, а я смотрю на процессы со стороны менеджмента и будущего Director Of Engineering (чтобы быть там через 1-2 года, надо уже начинать). Мы решили собраться на совместный стрим, чтобы поговорить про эффективность ИТ-команд. Кому и зачем это смотреть: * 👨‍💻 Инженерам и не-менеджерам (Cheat Code для Performance Review): Вы поймете, чего на самом деле от вас ждет бизнес и менеджеры. Когда вы знаете, как ваша работа влияет на P&L компании и цели (а сейчас их понимают только 9% сотрудников), вам становится в разы проще собирать мощные кейсы для ревью, аргументировать повышение и расти по грейдам. * 👔 Тимлидам и ИТ-менеджерам: Вы узнаете, как сделать так, чтобы бизнес видел в вас инвестицию, а не «центр затрат». И главное - как руководителю перестать тушить пожары и стать «организационным архитектором». Что конкретно обсудим: * Треугольник эффективности: почему Цели, Люди и Поток работают только вместе. * Ловушка процессов: почему нет смысла ускорять разработку (оптимизировать поток), если вы не выровняли цели - вы просто начнете быстрее делать ненужное. * Парадокс Эдмондсон: почему высокоэффективные команды сообщают о большем количестве ошибок, чем слабые. * Реальные кейсы: как отсутствие синхронизации приводит к разработке «параллельных велосипедов» 📅 Когда: завтра в среду 25 февраля в 18:00 (по Барселоне) 📍 Где: на этом канале / но скорее всего пришлю ссылку в зум #стрим

Всем привет! Сегодня вечером в Zoom мы с Андреем поговорим про эффективные команды. Анонс ниже - в 22:00 Уфы - 20:00 Москвы

Доброго рабочего утра! Завтра записываем стрим с бывшим коллегой @andreyposnov (ныне Engineering Manager в Барселоне) — будем говорить про эффективные команды. Анонс - позже. Перед этим хочу спросить вас: • Что для вас эффективная команда? Не гуглите, не думайте долго. Первое, что приходит в голову — то и пишите в комментариях. После стрима сделаю серию постов про то как на это смотрю я и индустрия. И почему большинство ответов — про симптомы, а не про суть. Перевод картики: они уже всё сломали! а как выглядит твоя эффективная команда?

📚 Пятничный нерабочий пост Обычно утро начинается с дайджестов: tl;dr, leaddev, что нарыл Perplexity по новостям. Но на этой неделе всё иначе. Я увяз в середине «Прежде чем их повесят» — второй книги цикла Джо Аберкромби «Первый закон». Тот случай (довольно редкий), когда думаешь: «нужно пережить рабочий день, чтобы наконец узнать, что там дальше». Таких захватывающих вещей у меня в копилке немного. Ближайший аналог — серия игр Dishonored, которую я прошёл залпом лет 3-4 назад. Там всё сошлось: мир, персонажи, механика, подача сюжета. Еще - когда началась движуха в «Задаче трех тел». Здесь — то же ощущение. Меня в цикле цепляет вот что: — После первой книги мир раскрылся. Первая — камерная. Вторая — широкая. — 4 главных героя, 3-4 параллельных линии сюжета. Всё жду, когда же они сойдутся. — Битвы описаны очень хорошо — без пафоса, жёстко и честно. — Персонажи развиваются. Они совершенно не статичные, они интересные: "Логен Девятипалый" аля Конан-Варвара, супер-циничный и мрачный Инквизитор-калека "Глокта", - прям в сердечко. — Магия есть, но в меру — не заглушает всё остальное. — И главное: здесь нет полностью положительных ни персонажей, ни фракций. Я такое люблю. Если любите тёмное фэнтези и баттл-фэнтези — рекомендую.

«ИИ пишет код, который потом невозможно поддерживать» — это главный страх техлидов сегодня. Я сделал выжимку из свежего исследования Echoes of AI, где этот миф проверили на реальных метриках (CodeHealth, покрытие тестами, скорость доработок). 🧠 Результаты контринтуитивны: ИИ не «ломает» поддержку, а у опытных пользователей код получается даже чище, чем у тех, кто пишет руками. Но есть нюанс: метрики не видят «когнитивный долг» и code bloat — ситуации, когда генерация опережает понимание. В статье на Хабре разбираю, почему ускорение разработки на 30% может выйти боком и почему DORA называет ИИ просто усилителем ваших текущих процессов (или хаоса). 👉 Читать на Хабре