По мотивам сессий менторинга: Команда из 15 человек, которая не хотела работать
Разбираю с коллегой её ситуацию. Команда: 15 человек. Четыре бэкенда, два фронта, два аналитика, PO, PM, ещё какие-то люди периодически.
PBR — по два часа. Все жалуются что долго.
Первая мысль: «Ну да, 15 человек, понятно почему долго».
Но потом выясняем интересное.
• Жалуются те, кто молчит. Не те, кто говорит. Говорят одни и те же 3-4 человека. Остальные сидят и недовольны.
• Потому что им скучно. Они не участвуют — они присутствуют. А это разные вещи.
🔽 Копаем дальше.
• «А почему они не участвуют?»
• «Им норм. Аналитик напишет, они потом разберутся».
💎 Вот оно.
Оказалось: раньше был техлид. Сильный, опытный. Он всё решал. Требования? Техлид разберётся. Архитектура? Техлид знает. Проблемы? Техлид порешает.
👋 Потом техлид ушёл. А привычка осталась.
Это у людей не лень, а выученная беспомощность. Их отучили думать о требованиях, потому что раньше за них думал кто-то другой.
И ещё момент: самый опытный в команде — год стажа. Остальные — полгода или меньше. Откуда им знать, как должно быть?
❓ Почему "просто заставить участвовать" не работает:
Пробовали.
• 🔈 "С понедельника все обязаны высказываться на рефайнменте".
Результат:
• люди говорят что-то, лишь бы сказать. Или молчат демонстративно. Формальное участие хуже, чем никакого.
Мы ж про изменения в образе мешления у людей. Нельзя заставить людей думать. Можно только создать условия, в которых думать — выгодно.
🙅♂️ Что реально было сломано:
• Слишком много людей → слишком мало "вещательного времени" на каждого
• Привычка «за нас решат» → нет ownership (владения)
• Нет понимания «зачем» → нет мотивации участвовать
⚙️ И вот с этим мы начали работать.
→ Следующий пост: три вещи, которые реально сработали
Ссылка на мой профиль на getmentor.dev
Разбираю с коллегой её ситуацию. Команда: 15 человек. Четыре бэкенда, два фронта, два аналитика, PO, PM, ещё какие-то люди периодически.
PBR — по два часа. Все жалуются что долго.
Первая мысль: «Ну да, 15 человек, понятно почему долго».
Но потом выясняем интересное.
• Жалуются те, кто молчит. Не те, кто говорит. Говорят одни и те же 3-4 человека. Остальные сидят и недовольны.
• Потому что им скучно. Они не участвуют — они присутствуют. А это разные вещи.
• «А почему они не участвуют?»
• «Им норм. Аналитик напишет, они потом разберутся».
Оказалось: раньше был техлид. Сильный, опытный. Он всё решал. Требования? Техлид разберётся. Архитектура? Техлид знает. Проблемы? Техлид порешает.
Это у людей не лень, а выученная беспомощность. Их отучили думать о требованиях, потому что раньше за них думал кто-то другой.
И ещё момент: самый опытный в команде — год стажа. Остальные — полгода или меньше. Откуда им знать, как должно быть?
Пробовали.
• 🔈 "С понедельника все обязаны высказываться на рефайнменте".
Результат:
• люди говорят что-то, лишь бы сказать. Или молчат демонстративно. Формальное участие хуже, чем никакого.
Мы ж про изменения в образе мешления у людей. Нельзя заставить людей думать. Можно только создать условия, в которых думать — выгодно.
🙅♂️ Что реально было сломано:
• Слишком много людей → слишком мало "вещательного времени" на каждого
• Привычка «за нас решат» → нет ownership (владения)
• Нет понимания «зачем» → нет мотивации участвовать
⚙️ И вот с этим мы начали работать.
→ Следующий пост: три вещи, которые реально сработали
Ссылка на мой профиль на getmentor.dev
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥12❤1
Marat @ Predictable.Team
По мотивам сессий менторинга: Команда из 15 человек, которая не хотела работать Разбираю с коллегой её ситуацию. Команда: 15 человек. Четыре бэкенда, два фронта, два аналитика, PO, PM, ещё какие-то люди периодически. PBR — по два часа. Все жалуются что долго.…
Три вещи, которые реально работают, если команда большая и митинги длинные:
- разделить команду на несколько
- shift left разработчиков
- научиться планировать исходя из статистики
Продолжаем историю про команду из 15 человек.
Диагноз мы в таких случаях ставим:
• слишком много людей, выученная беспомощность, нет понимания «зачем». Но есть классные практики, которые помогут добиться результатов на горизонте двух месяцев - квартала.
- PBR в таких случаях сокращается больше чем в два раза
- Участие: с 3-4 человек до почти всех (это база когда вы делите большую команду)
- Планирование: попадание в спринт растет до ~70%
1️⃣ Разделите команду на две группы
Если вы хотите ротировать людей ходить на PBR / Planning, чтоб ограничить контекст - не надо!
Люди путаются, кто когда должен быть, контекст теряется.
Хитрый момент: Если боитесь «а вдруг одна группа станет круче другой из-за экспертизы?». Не надо. Просто распределяляйте задачи равномерно.
Результат: встречи станут короче, люди начнут говорить. Когда тебя 7 человек, а не 15 — у тебя больше эфирного времени. И больше ответственности(!).
2️⃣ Сдвигайте разработчиков влево - но постепенно
я вообще за то, чтобы QA и аналитики скорее были ролями, контролирующими качество. А не писателями и проверяльщиками.
Нельзя сказать людям, которые никогда не работали с требованиями: «Теперь вы пишете критерии приемки». Даже если они сеньоры и вы этого от них ждете.
Хитрый момент: Главное правило — не допустить ситуации «товарищ-аналитик, всё не то, иди переделывай». Это его/её прибьёт. И поломает процесс.
Если команда только критикует и не предлагает — откатываемся на шаг назад. Сначала учимся дополнять, потом — предлагать.
3️⃣ Научитесь пользоваться статистикой (но не всем понравится)
«У нас нет нормальной статистики, мы не можем планировать».
Спрашиваю: «Сколько задач закрываете за спринт?»
— «Ну... 8-12 обычно».
Вот тебе и статистика.
Хитрый момент: «Но задачи же разного размера!»
Да. И пропускная способность это учитывает. Если у вас стабильно закрывается 10 задач разного размера — значит, в среднем* у вас получается 10 задач разного размера. Всё.
Пропуская способность — это факт. Он уже включает больничные, отпуска, тупняки, неожиданные баги.
*Лучше смотреть на 50 и 85 процентили, но давайте пока не усложнять.
❓А у вас эти приёмы как работают? :)
- разделить команду на несколько
- shift left разработчиков
- научиться планировать исходя из статистики
Продолжаем историю про команду из 15 человек.
Диагноз мы в таких случаях ставим:
• слишком много людей, выученная беспомощность, нет понимания «зачем». Но есть классные практики, которые помогут добиться результатов на горизонте двух месяцев - квартала.
- PBR в таких случаях сокращается больше чем в два раза
- Участие: с 3-4 человек до почти всех (это база когда вы делите большую команду)
- Планирование: попадание в спринт растет до ~70%
Если вы хотите ротировать людей ходить на PBR / Planning, чтоб ограничить контекст - не надо!
Люди путаются, кто когда должен быть, контекст теряется.
Разделите группу конкретно:
- Группа А: 2 бэкенда + 1 фронт + 1 аналитик
- Группа Б: то же самое
- Скрам-мастер ходит в обе
Хитрый момент: Если боитесь «а вдруг одна группа станет круче другой из-за экспертизы?». Не надо. Просто распределяляйте задачи равномерно.
Результат: встречи станут короче, люди начнут говорить. Когда тебя 7 человек, а не 15 — у тебя больше эфирного времени. И больше ответственности(!).
я вообще за то, чтобы QA и аналитики скорее были ролями, контролирующими качество. А не писателями и проверяльщиками.
Нельзя сказать людям, которые никогда не работали с требованиями: «Теперь вы пишете критерии приемки». Даже если они сеньоры и вы этого от них ждете.
Сделайте по-другому:
• Месяц 1: Аналитик пишет всё сам. Команда приходит только сказать «ок» или «не ок» по критериям приёмки. Минимальное вовлечение.
• Месяц 2: Аналитик пишет черновик. Команда дополняет: «А что если пользователь сделает вот так?», «А этот кейс учли?»
• Месяц 3: Команда накидывает вопросы на старте. Аналитик оформляет. Приносит обратно — команда валидирует.
Хитрый момент: Главное правило — не допустить ситуации «товарищ-аналитик, всё не то, иди переделывай». Это его/её прибьёт. И поломает процесс.
Если команда только критикует и не предлагает — откатываемся на шаг назад. Сначала учимся дополнять, потом — предлагать.
«У нас нет нормальной статистики, мы не можем планировать».
Спрашиваю: «Сколько задач закрываете за спринт?»
— «Ну... 8-12 обычно».
Вот тебе и статистика.
А надо так: сильно упрощённо смотрим: за последние 6-8 спринтов закрывали по в среднем* 10 задач.
Значит, берём 10. Если задачи крупнее обычного — берём меньше.
Хитрый момент: «Но задачи же разного размера!»
Да. И пропускная способность это учитывает. Если у вас стабильно закрывается 10 задач разного размера — значит, в среднем* у вас получается 10 задач разного размера. Всё.
Пропуская способность — это факт. Он уже включает больничные, отпуска, тупняки, неожиданные баги.
*Лучше смотреть на 50 и 85 процентили, но давайте пока не усложнять.
❓А у вас эти приёмы как работают? :)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍2
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4😁4🤪1
Agile Coach мертв. Да здравствует Change Agent.
Давайте сегодня пофилософствуем: роль Agile Coach, какой ее видели 4-6 лет назад, уходит. Сам ношу эту "лычку" последние два года, но отношусь к ней с долей иронии.
Здесь и далее: скрам-мастер и аджайл коуч тождественны.
1. Выделенная роль в команде — это кража ответственности
Постоянно приставленный к команде Agile Coach (или Scrum Master, или Delivery Manager в роли "няньки") — это прямое забирание ответственности у руководителей.
Нафига мы платим продактам и тимлидам хорошие деньги? Чтобы кто-то другой создавал атмосферу безопасности, фасилитировал и работал с людьми?
Если руководитель не умеет управлять динамикой команды — значит, его надо учить, а не ставить ему "костыль" в виде коуча. Например, в этом году мы делали большой упор на обучение руководителей фасилитации. Цель простая — чтобы количество обращений к нам, как к сервису, снизилось. И они могли реализовывать свои задумки.
2. Коуч для руководителей и архитектор среды
Роль трансформируется в коуча для руководителей и человека, который проводит изменения (зачастую проектно).
Чаще всего моя работа сводится к тому, чтобы двигать систему к зрелости через работу с лидами. Вы — архитекторы среды обмена опытом. Даже на разборах ситуаций я стараюсь (когда получается) молчать и давать слово коллегам руководителя, даже если знаю "правильный" ответ. Система должна уметь саморегулироваться, когда меня не будет.
Тут еще есть научная обоснованность: в модели ADKAR доказательно видно как CLARC (people менеджеры) это те, через кого мы проводим изменения.
3. Тест на прочность: "А что, если я уйду?"
Agile Coach делает хорошую работу, если после его ухода система радикально не ломается. Посмотрите, как быстро команды откатываются назад и насколько (например, по метрикам), когда из них убирают скрам-мастера.
С одной командой плотно работать дольше 3–6 месяцев может быть не супер продуктивно. Возникает привыкание, вы тратите свое время неэффективно. Нужно зайти, настроить, передать ответственность лиду и выйти. А потом трекать (как в настоящем стартапе) - что получается у лида и команды, что нет - и точечно консультировать.
4. Мы наняты бизнесом, а не командой
Прошли времена раздутых бюджетов, когда можно было плодить "аджайл ради аджайла" чтобы "оптимизировать процессы". В текущих реалиях (особенно с нынешними ставками ЦБ) каждая копейка на счету.
Мы должны уметь драйвить бизнес-стратегию, будь то оргтрансформация, радикальная смена концепции стартапа, оптимизация костов. И часто команда будет считать, что это "не по аджайлу".
Балансировать перформанс и здоровье команды (например, удовлетворенность, отток, выгорание) — вот это реальная задача.
🦾 Софт скилы - это новые хард скилы
Управление изменениями, оргдизайн, работа с сопротивлением и сложная фасилитация — язык не поворачивается назвать это "софт скилами". Сейчас это самые настоящие харды. И именно за эти харды бизнес готов платить.
• ну чо, пора менять визитки?
• фоточка с дюны Tal Moreeb
TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать мы должны не "вечно", а проектно - как спецназ внедрения изменений.
Давайте сегодня пофилософствуем: роль Agile Coach, какой ее видели 4-6 лет назад, уходит. Сам ношу эту "лычку" последние два года, но отношусь к ней с долей иронии.
Здесь и далее: скрам-мастер и аджайл коуч тождественны.
1. Выделенная роль в команде — это кража ответственности
Постоянно приставленный к команде Agile Coach (или Scrum Master, или Delivery Manager в роли "няньки") — это прямое забирание ответственности у руководителей.
Нафига мы платим продактам и тимлидам хорошие деньги? Чтобы кто-то другой создавал атмосферу безопасности, фасилитировал и работал с людьми?
Если руководитель не умеет управлять динамикой команды — значит, его надо учить, а не ставить ему "костыль" в виде коуча. Например, в этом году мы делали большой упор на обучение руководителей фасилитации. Цель простая — чтобы количество обращений к нам, как к сервису, снизилось. И они могли реализовывать свои задумки.
2. Коуч для руководителей и архитектор среды
Роль трансформируется в коуча для руководителей и человека, который проводит изменения (зачастую проектно).
Чаще всего моя работа сводится к тому, чтобы двигать систему к зрелости через работу с лидами. Вы — архитекторы среды обмена опытом. Даже на разборах ситуаций я стараюсь (когда получается) молчать и давать слово коллегам руководителя, даже если знаю "правильный" ответ. Система должна уметь саморегулироваться, когда меня не будет.
Тут еще есть научная обоснованность: в модели ADKAR доказательно видно как CLARC (people менеджеры) это те, через кого мы проводим изменения.
3. Тест на прочность: "А что, если я уйду?"
Agile Coach делает хорошую работу, если после его ухода система радикально не ломается. Посмотрите, как быстро команды откатываются назад и насколько (например, по метрикам), когда из них убирают скрам-мастера.
С одной командой плотно работать дольше 3–6 месяцев может быть не супер продуктивно. Возникает привыкание, вы тратите свое время неэффективно. Нужно зайти, настроить, передать ответственность лиду и выйти. А потом трекать (как в настоящем стартапе) - что получается у лида и команды, что нет - и точечно консультировать.
4. Мы наняты бизнесом, а не командой
Прошли времена раздутых бюджетов, когда можно было плодить "аджайл ради аджайла" чтобы "оптимизировать процессы". В текущих реалиях (особенно с нынешними ставками ЦБ) каждая копейка на счету.
Мы должны уметь драйвить бизнес-стратегию, будь то оргтрансформация, радикальная смена концепции стартапа, оптимизация костов. И часто команда будет считать, что это "не по аджайлу".
Балансировать перформанс и здоровье команды (например, удовлетворенность, отток, выгорание) — вот это реальная задача.
🦾 Софт скилы - это новые хард скилы
Управление изменениями, оргдизайн, работа с сопротивлением и сложная фасилитация — язык не поворачивается назвать это "софт скилами". Сейчас это самые настоящие харды. И именно за эти харды бизнес готов платить.
• ну чо, пора менять визитки?
• фоточка с дюны Tal Moreeb
👍8❤3
This media is not supported in your browser
VIEW IN TELEGRAM
В интернетах классный комикс про метрики потока и лимиты незавершенной работы :) срочно распространить, если надо объяснить бабушке почему много одновременно делать нельзя
🔥8❤2
🔴 План «заменим разработчиков ИИ» провалился. Вот цифры
• 95% корпоративных GenAI-пилотов не дали ни доллара ROI.
• 45% AI-кода содержит уязвимости из OWASP Top 10.
• Набор джунов упал на 50%, а техдолг вырос в разы.
Вместо обещанной «революции» получили slop layer - код, который работает, но никто не понимает как. Senior'ы тратят 11 часов в неделю на проверку AI-галлюцинаций и работают медленнее, чем без ассистентов.
Так как активно работаю с внедрением ИИ на работе, написал тут разбор данных MIT, Stanford, Veracode и CodeRabbit -> что пошло не так и что с этим делать компаниям и разработчикам 👇
https://habr.com/ru/articles/995640/
• 95% корпоративных GenAI-пилотов не дали ни доллара ROI.
• 45% AI-кода содержит уязвимости из OWASP Top 10.
• Набор джунов упал на 50%, а техдолг вырос в разы.
Вместо обещанной «революции» получили slop layer - код, который работает, но никто не понимает как. Senior'ы тратят 11 часов в неделю на проверку AI-галлюцинаций и работают медленнее, чем без ассистентов.
Так как активно работаю с внедрением ИИ на работе, написал тут разбор данных MIT, Stanford, Veracode и CodeRabbit -> что пошло не так и что с этим делать компаниям и разработчикам 👇
https://habr.com/ru/articles/995640/
Хабр
Почему план «заменить разработчиков ИИ» превращается в техдолг и кадровый кризис
Статья: компиляция нескольких исследований середины-конца 2025 года, на них ведут ссылки Морбо в студии Преамбула В 2023–2024 годах менеджерам в корпорациях активно продавали идею, что большие...
👍11🔥3😢1🤡1
«ИИ пишет код, который потом невозможно поддерживать» — это главный страх техлидов сегодня. Я сделал выжимку из свежего исследования Echoes of AI, где этот миф проверили на реальных метриках (CodeHealth, покрытие тестами, скорость доработок).
🧠 Результаты контринтуитивны: ИИ не «ломает» поддержку, а у опытных пользователей код получается даже чище, чем у тех, кто пишет руками.
Но есть нюанс: метрики не видят «когнитивный долг» и code bloat — ситуации, когда генерация опережает понимание. В статье на Хабре разбираю, почему ускорение разработки на 30% может выйти боком и почему DORA называет ИИ просто усилителем ваших текущих процессов (или хаоса).
👉 Читать на Хабре
🧠 Результаты контринтуитивны: ИИ не «ломает» поддержку, а у опытных пользователей код получается даже чище, чем у тех, кто пишет руками.
Но есть нюанс: метрики не видят «когнитивный долг» и code bloat — ситуации, когда генерация опережает понимание. В статье на Хабре разбираю, почему ускорение разработки на 30% может выйти боком и почему DORA называет ИИ просто усилителем ваших текущих процессов (или хаоса).
👉 Читать на Хабре
Хабр
ИИ-ассистенты не ломают поддерживаемость кода. Но есть нюансы (выжимка из исследования Echoes of AI)
Перевод и выжимка исследования Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability Более визуально видео с обзором исследования можно посмотреть на канале...
❤🔥6👍1
Обычно утро начинается с дайджестов: tl;dr, leaddev, что нарыл Perplexity по новостям. Но на этой неделе всё иначе.
Я увяз в середине «Прежде чем их повесят» — второй книги цикла Джо Аберкромби «Первый закон». Тот случай (довольно редкий), когда думаешь: «нужно пережить рабочий день, чтобы наконец узнать, что там дальше».
Таких захватывающих вещей у меня в копилке немного. Ближайший аналог — серия игр Dishonored, которую я прошёл залпом лет 3-4 назад. Там всё сошлось: мир, персонажи, механика, подача сюжета. Еще - когда началась движуха в «Задаче трех тел». Здесь — то же ощущение.
Меня в цикле цепляет вот что:
— После первой книги мир раскрылся. Первая — камерная. Вторая — широкая.
— 4 главных героя, 3-4 параллельных линии сюжета. Всё жду, когда же они сойдутся.
— Битвы описаны очень хорошо — без пафоса, жёстко и честно.
— Персонажи развиваются. Они совершенно не статичные, они интересные: "Логен Девятипалый" аля Конан-Варвара, супер-циничный и мрачный Инквизитор-калека "Глокта", - прям в сердечко.
— Магия есть, но в меру — не заглушает всё остальное.
— И главное: здесь нет полностью положительных ни персонажей, ни фракций. Я такое люблю.
Если любите тёмное фэнтези и баттл-фэнтези — рекомендую.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍10❤2
Доброго рабочего утра!
Завтра записываем стрим с бывшим коллегой @andreyposnov (ныне Engineering Manager в Барселоне) — будем говорить про эффективные команды. Анонс - позже.
Перед этим хочу спросить вас:
• Что для вас эффективная команда?
Не гуглите, не думайте долго. Первое, что приходит в голову — то и пишите в комментариях.
После стрима сделаю серию постов про то как на это смотрю я и индустрия. И почему большинство ответов — про симптомы, а не про суть.
Перевод картики: они уже всё сломали! а как выглядит твоя эффективная команда?
Завтра записываем стрим с бывшим коллегой @andreyposnov (ныне Engineering Manager в Барселоне) — будем говорить про эффективные команды. Анонс - позже.
Перед этим хочу спросить вас:
• Что для вас эффективная команда?
Не гуглите, не думайте долго. Первое, что приходит в голову — то и пишите в комментариях.
После стрима сделаю серию постов про то как на это смотрю я и индустрия. И почему большинство ответов — про симптомы, а не про суть.
Перевод картики: они уже всё сломали! а как выглядит твоя эффективная команда?
❤4🔥2
Всем привет! Сегодня вечером в Zoom мы с Андреем поговорим про эффективные команды. Анонс ниже
- в 22:00 Уфы
- 20:00 Москвы
- в 22:00 Уфы
- 20:00 Москвы
Zoom
Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise cloud communications.
👍6
Forwarded from Андрей Поснов
🔥 Стрим: Как строят High-Performance команды (и как это поможет вам быстрее расти)
Когда-то мы работали вместе с Маратом, его канал @predictableteam и во многом именно благодаря его подходу и экспертизе я смог вырасти из тимлида в Engineering Manager.
(Его интерактивные сессии для команд и тимлидов/менеджеров помогли понять, что надо бизнесу и для роста в айти)
Сейчас Марат - крутой Agile Coach, а я смотрю на процессы со стороны менеджмента и будущего Director Of Engineering (чтобы быть там через 1-2 года, надо уже начинать).
Мы решили собраться на совместный стрим, чтобы поговорить про эффективность ИТ-команд.
Кому и зачем это смотреть:
* 👨💻 Инженерам и не-менеджерам (Cheat Code для Performance Review):
Вы поймете, чего на самом деле от вас ждет бизнес и менеджеры. Когда вы знаете, как ваша работа влияет на P&L компании и цели (а сейчас их понимают только 9% сотрудников), вам становится в разы проще собирать мощные кейсы для ревью, аргументировать повышение и расти по грейдам.
* 👔 Тимлидам и ИТ-менеджерам:
Вы узнаете, как сделать так, чтобы бизнес видел в вас инвестицию, а не «центр затрат». И главное - как руководителю перестать тушить пожары и стать «организационным архитектором».
Что конкретно обсудим:
* Треугольник эффективности: почему Цели, Люди и Поток работают только вместе.
* Ловушка процессов: почему нет смысла ускорять разработку (оптимизировать поток), если вы не выровняли цели - вы просто начнете быстрее делать ненужное.
* Парадокс Эдмондсон: почему высокоэффективные команды сообщают о большем количестве ошибок, чем слабые.
* Реальные кейсы: как отсутствие синхронизации приводит к разработке «параллельных велосипедов»
📅 Когда: завтра в среду 25 февраля в 18:00 (по Барселоне)
📍 Где: на этом канале / но скорее всего пришлю ссылку в зум
#стрим
Когда-то мы работали вместе с Маратом, его канал @predictableteam и во многом именно благодаря его подходу и экспертизе я смог вырасти из тимлида в Engineering Manager.
(Его интерактивные сессии для команд и тимлидов/менеджеров помогли понять, что надо бизнесу и для роста в айти)
Сейчас Марат - крутой Agile Coach, а я смотрю на процессы со стороны менеджмента и будущего Director Of Engineering (чтобы быть там через 1-2 года, надо уже начинать).
Мы решили собраться на совместный стрим, чтобы поговорить про эффективность ИТ-команд.
Кому и зачем это смотреть:
* 👨💻 Инженерам и не-менеджерам (Cheat Code для Performance Review):
Вы поймете, чего на самом деле от вас ждет бизнес и менеджеры. Когда вы знаете, как ваша работа влияет на P&L компании и цели (а сейчас их понимают только 9% сотрудников), вам становится в разы проще собирать мощные кейсы для ревью, аргументировать повышение и расти по грейдам.
* 👔 Тимлидам и ИТ-менеджерам:
Вы узнаете, как сделать так, чтобы бизнес видел в вас инвестицию, а не «центр затрат». И главное - как руководителю перестать тушить пожары и стать «организационным архитектором».
Что конкретно обсудим:
* Треугольник эффективности: почему Цели, Люди и Поток работают только вместе.
* Ловушка процессов: почему нет смысла ускорять разработку (оптимизировать поток), если вы не выровняли цели - вы просто начнете быстрее делать ненужное.
* Парадокс Эдмондсон: почему высокоэффективные команды сообщают о большем количестве ошибок, чем слабые.
* Реальные кейсы: как отсутствие синхронизации приводит к разработке «параллельных велосипедов»
📅 Когда: завтра в среду 25 февраля в 18:00 (по Барселоне)
📍 Где: на этом канале / но скорее всего пришлю ссылку в зум
#стрим
1❤6👍6❤🔥2🤔1
Андрей Поснов
🔥 Стрим: Как строят High-Performance команды (и как это поможет вам быстрее расти) Когда-то мы работали вместе с Маратом, его канал @predictableteam и во многом именно благодаря его подходу и экспертизе я смог вырасти из тимлида в Engineering Manager. (Его…
Всем привет!
Стрим будет уже через 5 минут в Zoom - где мы с Андреем поговорим про эффективные команды.
• 22:00 Уфы
• 20:00 Москвы
Upd: стрим закончился. Спасибо что пришли)
Стрим будет уже через 5 минут в Zoom - где мы с Андреем поговорим про эффективные команды.
• 22:00 Уфы
• 20:00 Москвы
Upd: стрим закончился. Спасибо что пришли)
Zoom
Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise cloud communications.
🔥4❤🔥1
Эффективные команды: выжимка из стрима с Андреем Посновым
Сделал выжимку, чтоб вам не надо было включать ВПН для 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
Сделал выжимку, чтоб вам не надо было включать ВПН для youtube 🙂
🥧 Модель «Эчпочмак» для эффективной команды
Представьте треугольник (как наш башкирский
1️⃣ Достижение целей — команда делает то, что нужно бизнесу
2️⃣ Довольные люди — мотивация без выгорания
3️⃣ Предсказуемость — стабильные метрики потока
Многие команды работают по схеме: «цели есть, но никто их не понимает». Результат: 50-70% работы уходит не туда (это из нашего с Андреем опыта в MetaMap).
🥕️️️️️️ Как объяснить цели команде
Не надо читать лекции про миссию. Надо:
• Показать, как задача влияет на конверсию/деньги
• Привести на ревью реальных клиентов — пусть разработчики увидят, как люди страдают
• Дать end-to-end ответственность за фичу (от идеи до метрик на проде)
Когда человек понимает, что его тикет влияет на годовой доход от клиентов в Мексике — мотивация другая.
📊 Метрики потока vs Стори поинты
Если команда их использует — отлично. Если нет — тоже норм.
Главное — предсказуемость, а не скорость. Вам важно знать:
• Сколько задач делаете за спринт (throughput)
• За какое время задача проходит от «в работе» до «готово» (cycle time)
• Норма: ±20% отклонения от плана — это ок для индустрии.
• Инструмент: JiraMetricsPro — показывает всё из коробки, Predictable.Team, в Jira тоже дофига возможностей.
Исследование Стэнфорда: в высокоэффективных командах люди сообщают об ошибках чаще, чем в малоэффективных.
• Почему? Потому что там безопасно говорить о проблемах. Не боятся, что их обвинят.
• Задача лидера - сделать безопасную среду.
Не важно. Выбирайте то, что нравится команде.
Разница:
• Scrum = push-система (запихнули работу на 2 недели)
• Kanban = pull-система (взяли следующую задачу, когда есть слот)
Оба подхода пришли к одним метрикам потока. Главное — цель выполнять, не гореть и быть предсказуемыми.
• Пойми, как твоя команда приносит пользу бизнесу
• Расскажи команде, куда едет компания
• Узнай, чем живут твои люди
• Научись давать обратную связь (это отдельный навык!)
• Выясни ожидания своего руководителя — вы партнёры
🎁 Бонус: тренд на продуктовость
Код написать — не проблема, есть Claude. Проблема — понять, что делать и на какие метрики бизнеса это повлияет.
Технические специалисты всё больше становятся продуктовыми. Это неизбежно.
• 🎤 Полная запись стрима на YouTube
• 📣 Канал Андрея
• 📝 Подробнее про метрики потока — в моём канале @predictableteam
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Marat Kiniabulatov | High Perfomance команды, Agile, Scrum, Kanban, Sprints, OKR, KR, как вырасти
#spain #испания #барселона #barcelona #teletrabajo #digitalnomad #цифровойкочевник #teletrabajar #teletrabajador #айти #it #developer #программист #engineering #espana
канал Марата, много инфы про эффективность команд https://t.me/predictableteam
канал…
канал Марата, много инфы про эффективность команд https://t.me/predictableteam
канал…
🔥7👍6
👩🔬Модель «Учпочмак» — три вершины эффективной команды
Начинаем серию: Эффективные команды (1/n)
Что такое эффективная команда?
Последние 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 усиливает то, что уже есть в команде.
Начинаем серию: Эффективные команды (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 усиливает то, что уже есть в команде.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍7🔥3❤2
В прошлом посте я сказал что для эффективности команды важен порядок: цели -> люди -> предсказуемость. Многие ставят во главу угла людей, но все таки команда нанимается из экономических соображений. По этому поводу есть много исследований, подтверждающих этот порядок.
Сегодня рассмотрим кратенько пять из них:
🏫 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% сотрудников считает что цели их команды согласованы с общеорганизационными.
Так вот: это проблема самой архитектуры согласованности в организации. И начинать решать ее надо только с целей. Без этого пререквизита работать с остальными вершинами смысла нет.
Please open Telegram to view this post
VIEW IN TELEGRAM
4❤4👍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: формат, светофор целей, два режима работы.
В прошлом посте: только 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 прошёл до старта: одна команда, одна архитектура, десятки миллионов сэкономлены.
⚛️ Проблема 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👍4🔥4❤2
QBR: как проводить обзор целей и извлекать из него полезную информацию (+ 🎁бонусом шаблон для мультикомандного обзора целей в комментариях)
В прошлом посте: зачем нужен QBR — параллельные велосипеды, системные блокеры, руководители в пузырях. Теперь — как его проводить.
Здесь и далее: QBR и OKR Review тождественны. В OKR Review добавляется количественный показатель (как как он обязателен).
Минимальный формат
• Частота: 4 раза в год (можно комбинировать онлайн и оффлайн)
• Длительность: от 2 часов (просто пробежаться по целям) до 6 (с доп. фасилитацией)
• Инструменты: светофор целей (must), остальное по необходимости
Светофор целей
Главный инструмент QBR — визуальный статус каждой цели:
Формат: Цвет - Статус - Что делаем
🟢 Зелёный - Всё по плану - Делимся практиками — что сработало
🟡 Жёлтый - Риск срыва, но годовую цель закрыть успевам - Обсуждаем, ищем поддержку
🔴 Красный - Критично - Эскалируем, открыто обсуждаем варианты решений, запрашиваем помощь.
Важно: красный — это не провал. Это сигнал о помощи.
Логика: Скрывать проблемы = узнать о срыве в конце квартала. Показать красный вовремя = получить помощь и успеть.
Эволюция участников
• Старт: руководители команд + их руководители
• Со временем: расширяйте до представителей смежных отделов (ИБ, инфра, юристы, закупки).
Иначе получите ловушку: внутри вы согласованны, а критичные части общего end-to-end — нет. Узкие места всегда на стыках.
Два режима QBR
1️⃣ Начало года — постановка целей
Каждая команда отвечает на вопросы:
• Вектор работ — какие крупные направления видим на год?
• Фокусы — что входит в этот вектор, на чём концентрируемся?
• Как драйвим — каким образом команда будет двигать эту повестку?
Выравнивание: На этом этапе сверяемся — не делаем ли одинаковую работу с соседями? Нет ли пересечений?
🕸 Зависимости:
Критичные зависимости от соседних команд — что нужно и когда
Зависимости от других отделов вне департамента
Риски: Какие видим? Что будет, если не проработаем?
2️⃣ В течение года — обзор статуса (Q1, Q2, Q3)
Цели уже поставлены. Теперь смотрим:
• Светофор целей — кто зелёный, жёлтый, красный
• Общие затыки — где застряли, что мешает
• Выученные уроки — что сработало, что нет
• Системные паттерны — похожие проблемы у разных команд
Обстукиваем друг об друга: «У нас такая же проблема — как вы её решили?»
💰 Бонус: фасилитации
Раз собрались таким составом — используйте (дорогущее) время по максимуму. Проведите 1–2 фасилитации по самым горячим темам:
• По вершинам «Учпочмака» — цели, люди, предсказуемость
• По другим вызовам перед организацией или отделом
Это редкая возможность собрать всех лидеров в одной комнате. Не тратьте её только на статусы.
В следующий раз обсудим: почему раз в квартал - это слишком редко. И как с этим работать.
В прошлом посте: зачем нужен QBR — параллельные велосипеды, системные блокеры, руководители в пузырях. Теперь — как его проводить.
Здесь и далее: QBR и OKR Review тождественны. В OKR Review добавляется количественный показатель (как как он обязателен).
Минимальный формат
• Частота: 4 раза в год (можно комбинировать онлайн и оффлайн)
• Длительность: от 2 часов (просто пробежаться по целям) до 6 (с доп. фасилитацией)
• Инструменты: светофор целей (must), остальное по необходимости
Светофор целей
Главный инструмент QBR — визуальный статус каждой цели:
Формат: Цвет - Статус - Что делаем
🟢 Зелёный - Всё по плану - Делимся практиками — что сработало
🟡 Жёлтый - Риск срыва, но годовую цель закрыть успевам - Обсуждаем, ищем поддержку
🔴 Красный - Критично - Эскалируем, открыто обсуждаем варианты решений, запрашиваем помощь.
Важно: красный — это не провал. Это сигнал о помощи.
Логика: Скрывать проблемы = узнать о срыве в конце квартала. Показать красный вовремя = получить помощь и успеть.
Эволюция участников
• Старт: руководители команд + их руководители
• Со временем: расширяйте до представителей смежных отделов (ИБ, инфра, юристы, закупки).
Иначе получите ловушку: внутри вы согласованны, а критичные части общего end-to-end — нет. Узкие места всегда на стыках.
Два режима QBR
1️⃣ Начало года — постановка целей
Каждая команда отвечает на вопросы:
• Вектор работ — какие крупные направления видим на год?
• Фокусы — что входит в этот вектор, на чём концентрируемся?
• Как драйвим — каким образом команда будет двигать эту повестку?
Выравнивание: На этом этапе сверяемся — не делаем ли одинаковую работу с соседями? Нет ли пересечений?
🕸 Зависимости:
Критичные зависимости от соседних команд — что нужно и когда
Зависимости от других отделов вне департамента
Риски: Какие видим? Что будет, если не проработаем?
2️⃣ В течение года — обзор статуса (Q1, Q2, Q3)
Цели уже поставлены. Теперь смотрим:
• Светофор целей — кто зелёный, жёлтый, красный
• Общие затыки — где застряли, что мешает
• Выученные уроки — что сработало, что нет
• Системные паттерны — похожие проблемы у разных команд
Обстукиваем друг об друга: «У нас такая же проблема — как вы её решили?»
💰 Бонус: фасилитации
Раз собрались таким составом — используйте (дорогущее) время по максимуму. Проведите 1–2 фасилитации по самым горячим темам:
• По вершинам «Учпочмака» — цели, люди, предсказуемость
• По другим вызовам перед организацией или отделом
Это редкая возможность собрать всех лидеров в одной комнате. Не тратьте её только на статусы.
В следующий раз обсудим: почему раз в квартал - это слишком редко. И как с этим работать.
1🔥3❤1
🧑🚒 Сигнальная система: как узнать о том что цели не достигаются чаще чем раз в квартал. (5/n)
В прошлых постах:
• 👍 QBR выравнивает руководителей раз в квартал.
• 👎 Но проблема на 3-й неделе спринта не дождётся следующего QBR.
Нужна сигнальная система снизу — чтобы риски всплывали раньше.
Поэтому - каждый спринт (или каденцию) мы делаем ревью достижения целей уровне команды.
Вы можете использовать формат анализа - стали ли вы ближе по KR (если используете OKR), или руководствоваться старым добрым светофором
• 🟢 По плану — цель будет достигнута
• 🟡 Риск — нужна помощь или решение (но вроде бы успеваем)
• 🔴 Критично — без вмешательства не успеем
Самая маковка: ваши Sprint Review (обзоры спринта) идеально для этого подходят.
• На них вы снимаете фидбек с пользователей по использованию вашего продукта
• Смотрите где вы по роудмапу уже находитесь и стоит ли его поправить из-за фидбека
🛣 При этом на те же цели и их статус круто смотреть и на планировании (так как цель спринта - прямая производная от квартальной/годовой цели). А на ретроспективе - посмотреть на причины опоздания по целям.
Но перед этим надо правильно настроить...
🛣 ..трассировку от цели организации до каждой задачи
Помните, мы говорили что без понимания каждым сотрудником цели - хороших результатов с вовлеченными людьми мы не достигнем?
Каждый сотрудник должен видеть: "зачем я это делаю?"
Путь: задача → цель спринта → цель квартала (или прогресс по KR) → цель организации (objective).
• Если путь очевиден — работа имеет смысл. Человек понимает ценность.
• Если путь неочевиден — это сигнал задать вопрос: «Какого хрена мы это делаем?»
🔜 Когда команда видит связь между задачами и целями, происходит сдвиг:
• Раньше: делаем задачи → надеемся, что это приведёт к цели
• Теперь: видим цель → замечаем, что задачи идут в другую сторону → предлагаем альтернативы
Так мы формируем вовлечённость изнутри.
Команда, которая видит расхождение и может предложить решение — это совершенно иной уровень мотивации.
Нам с вами важно сделать 🤯 культурный сдвиг (который заставит сигнальную систему снизу работать на предотвращение невыполнения целей) в мышлении команды.
• Красный ≠ провал. Красный — это сигнал о помощи.
• Скрывать проблемы = узнать о потенциальном срыве в конце квартала.
• Показать красный вовремя = получить помощь и успеть.
• Честность важнее зелёного цвета.
⚙️ Механика обзора статуса по целям
• Sprint goal (цель спринта) привязана к квартальной/годовой цели
• В конце спринта — статус светофора (по цели или KR)
• Жёлтый/красный — эскалация или запрос помощи
• Надо эскалировать конкретно: «ждём ответ ИБ 5 дней, блокирует 3 фичи». А не эти ваши "ой, все сложно, команда Васи Пупкина как обычно нас игнорит".
⛓️ Вот мы и прошлись по двум петлям обратной связи
• Петля "сверху-вниз" через QBR руководителей, раз в квартал
• Петля "снизу-вверх" через обзор светофора команды, каждый спринт (каденцию)
🤝 🤝 Вместе они создают систему, где проблемы видны до того, как станут настоящими проблемами.
Этот пост - пятый из серии про эффективные команды.
• Модель эффективной команды (1),
• Почему вершина целей - важнее людей и метрик (2),
• зачем нужен QBR (3) , как его проводить (4).
👍 Больше про системную работу с эффективностью команд в блоге Марата Киньябулатова про предсказуемые команды
В прошлых постах:
• 👍 QBR выравнивает руководителей раз в квартал.
• 👎 Но проблема на 3-й неделе спринта не дождётся следующего QBR.
Нужна сигнальная система снизу — чтобы риски всплывали раньше.
Поэтому - каждый спринт (или каденцию) мы делаем ревью достижения целей уровне команды.
Вы можете использовать формат анализа - стали ли вы ближе по KR (если используете OKR), или руководствоваться старым добрым светофором
• 🟢 По плану — цель будет достигнута
• 🟡 Риск — нужна помощь или решение (но вроде бы успеваем)
• 🔴 Критично — без вмешательства не успеем
Самая маковка: ваши Sprint Review (обзоры спринта) идеально для этого подходят.
• На них вы снимаете фидбек с пользователей по использованию вашего продукта
• Смотрите где вы по роудмапу уже находитесь и стоит ли его поправить из-за фидбека
Но перед этим надо правильно настроить...
🛣 ..трассировку от цели организации до каждой задачи
Помните, мы говорили что без понимания каждым сотрудником цели - хороших результатов с вовлеченными людьми мы не достигнем?
Каждый сотрудник должен видеть: "зачем я это делаю?"
Путь: задача → цель спринта → цель квартала (или прогресс по KR) → цель организации (objective).
• Если путь очевиден — работа имеет смысл. Человек понимает ценность.
• Если путь неочевиден — это сигнал задать вопрос: «Какого хрена мы это делаем?»
🔜 Когда команда видит связь между задачами и целями, происходит сдвиг:
• Раньше: делаем задачи → надеемся, что это приведёт к цели
• Теперь: видим цель → замечаем, что задачи идут в другую сторону → предлагаем альтернативы
Так мы формируем вовлечённость изнутри.
Команда, которая видит расхождение и может предложить решение — это совершенно иной уровень мотивации.
Нам с вами важно сделать 🤯 культурный сдвиг (который заставит сигнальную систему снизу работать на предотвращение невыполнения целей) в мышлении команды.
• Красный ≠ провал. Красный — это сигнал о помощи.
• Скрывать проблемы = узнать о потенциальном срыве в конце квартала.
• Показать красный вовремя = получить помощь и успеть.
• Честность важнее зелёного цвета.
⚙️ Механика обзора статуса по целям
• Sprint goal (цель спринта) привязана к квартальной/годовой цели
• В конце спринта — статус светофора (по цели или KR)
• Жёлтый/красный — эскалация или запрос помощи
• Надо эскалировать конкретно: «ждём ответ ИБ 5 дней, блокирует 3 фичи». А не эти ваши "ой, все сложно, команда Васи Пупкина как обычно нас игнорит".
• Петля "сверху-вниз" через QBR руководителей, раз в квартал
• Петля "снизу-вверх" через обзор светофора команды, каждый спринт (каденцию)
Этот пост - пятый из серии про эффективные команды.
• Модель эффективной команды (1),
• Почему вершина целей - важнее людей и метрик (2),
• зачем нужен QBR (3) , как его проводить (4).
Please open Telegram to view this post
VIEW IN TELEGRAM
2❤5🔥4👍2
Товарищи, в этом году выступаю на DUMP Ekb (который состоится 24 апреля 2026)
Если кто-то собирался поехать, но не купил билеты - то вам промокод на 10%KINIABULATOV
https://dump-ekb.ru
Если кто-то собирался поехать, но не купил билеты - то вам промокод на 10%
https://dump-ekb.ru
2🔥12
Хочу попиарить канал который сам читаю - и прекрасный пример интересного поста.
Мы познакомились с Денисом на Agile Random Coffee с год назад, у него канал по продуктовой трансформации. Он сейчас работает в АйТи дочке Вкусвилла.
Пост классно описывает путешествие - какие модели приоритизации применяли на практике, где они применимы и почему в итоге пришли к текущей :)
Мы познакомились с Денисом на Agile Random Coffee с год назад, у него канал по продуктовой трансформации. Он сейчас работает в АйТи дочке Вкусвилла.
Пост классно описывает путешествие - какие модели приоритизации применяли на практике, где они применимы и почему в итоге пришли к текущей :)