DevRel CFP Bot (@devrelcfpbot) - персональный напоминальщик о дедлайнах IT-конференций :)
За два года работы в Райфе у меня накопилось четыре темы для выступлений. Но искать конференции вручную - ужасно лень.
счастью, есть отличный инструмент, который напоминает, когда подача докладов вот-вот заканчивается, и помогает не упустить ни одну подходящую площадку.
За два года работы в Райфе у меня накопилось четыре темы для выступлений. Но искать конференции вручную - ужасно лень.
счастью, есть отличный инструмент, который напоминает, когда подача докладов вот-вот заканчивается, и помогает не упустить ни одну подходящую площадку.
👍3❤2
Доброе всем утро.
Тут интересное видео* про то, что пока мы с вами переживаем что нашу работу заберёт AI, таких ключевых и сложно автоматизируемых людей как медики и преподаватели становится все меньше. А без них общество и государства нормально функционировать не могут.
* YouTube заблокирован в РФ
Тут интересное видео* про то, что пока мы с вами переживаем что нашу работу заберёт AI, таких ключевых и сложно автоматизируемых людей как медики и преподаватели становится все меньше. А без них общество и государства нормально функционировать не могут.
* YouTube заблокирован в РФ
YouTube
Why Essential Workers Are Going Extinct
Go to https://surfshark.com/economics or use code ECONOMICS at checkout to get 4 extra months of Surfshark VPN!
We have all been told AI is coming for our jobs, but a more urgent crisis is already here. Across developed countries, many schools and hospitals…
We have all been told AI is coming for our jobs, but a more urgent crisis is already here. Across developed countries, many schools and hospitals…
❤3👍1
👨💻🌟 Мысль: Айтишечная грейдовка не так сильно отличается от армейской
На прошлой неделе обсуждаем с одним из клиентов - систему грейдов. Он из семьи военных.
— Коллега: "Джуниор, мидл, сениор - это же как звания. Пипка на погонах. В армии знаешь как? Раз в 4 года звание присваивают автоматически. Выслуга идёт — звание растёт."
— Я: "Ну... в IT немного по-другому работает."
— "А почему? Человек же тоже опыт набирает!"
Ну короче, в целом-то он прав. Если человек 4 года пишет код и не растёт - это не его проблема. Это проблема нашей организации как системы, которая его не развивает (и, может быть, недостаточно окупает).
Хорошей пятницы.Пусть ваши звания растут быстрее, чем в армии 🤝
На прошлой неделе обсуждаем с одним из клиентов - систему грейдов. Он из семьи военных.
— Коллега: "Джуниор, мидл, сениор - это же как звания. Пипка на погонах. В армии знаешь как? Раз в 4 года звание присваивают автоматически. Выслуга идёт — звание растёт."
— Я: "Ну... в IT немного по-другому работает."
— "А почему? Человек же тоже опыт набирает!"
Ну короче, в целом-то он прав. Если человек 4 года пишет код и не растёт - это не его проблема. Это проблема нашей организации как системы, которая его не развивает (и, может быть, недостаточно окупает).
Хорошей пятницы.
Please open Telegram to view this post
VIEW IN TELEGRAM
🥰3👍2
По мотивам сессий менторинга: Команда из 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