5 крайне неэффективных привычек владельцев продуктов по мнению разработчиков

Мы много пишем о том, что должен или не должен делать Владелец продукта, какие “стойки” он должен занимать, а каких избегать. Чаще всего такую информацию пишут сами владельцы продукта или коучи.

⭐️ А вот интересное мнение разработчиков: какие привычки владельца продукта они считают сомнительными.

Давайте посмотрим на них и постараемся не повторять.

Читать полностью…

Четыре квадрата для проверки OKR

Одним из этапов OKR-цикла является “исполнение” наших целей.
Кроме выполнения самой работы, на протяжении всего квартала участники команды должны оценивать свой прогресс. Также они должны сверяться со стейкхолдерами и другими командами, чтобы вовремя решать возникающие сложности.

💡 Одной из практик OKR, применяемых в течение квартала, являются контрольные встречи. Они могут проводиться еженедельно или раз в спринт (если вы работаете спринтами).
Основная цель контрольных встреч — обсудить прогресс в достижении ключевых результатов, уровень уверенности в их достижении, получить обратную связь и, при необходимости, скорректировать действия.
❗️Разумеется, это обсуждение должно основываться на текущих показателях ключевых метрик.

Что еще можно отслеживать на таких встречах?
➡️ Кристина Водтке, автор отличной книги “Радикальный фокус”, предлагает простую модель «Четыре квадрата» («4sq»).

1️⃣ Приоритеты этой недели
Основные задачи, на которых команде нужно сфокусироваться на предстоящей неделе.

2️⃣ Уверенность в достижении OKR
Регулярно и быстро (в ненаучной форме) команда оценивает свою уверенность в достижении каждого ключевого результата по шкале от 0 до 10. Эти оценки помогают обсуждать, как скорректировать работу для повышения уверенности или удержания ее на достигнутом уровне.

3️⃣ Предстоящие крупные проекты
Это важные запуски или события, которые могут повлиять на работу команды. Важно не упустить их из виду.

4️⃣ Метрики здоровья
Это 1-3 показателя, на которые команда должна постоянно обращать внимание при достижении своих OKR. Важно, чтобы их было немного. Чаще всего это то, что имеет фундаментальное значение для команды и бизнеса.

Шаблон четырех квадратов доступен в Miro

Читать полностью…

Цикл OKR

В большинстве организаций ежеквартально прилагаются огромные усилия для составления идеальных целей (и ключевых результатов, если используется подход OKR). Как только эти цели установлены, они записываются куда-то и «покрываются там пылью». В конце квартала цели снова достаются и дополняются статусами их достижения. Неудивительно, что цели часто остаются невыполненными.

📌 Поэтому важна не только постановка целей, но и весь цикл OKR.

Цикл OKR — это временная шкала или период, в течение которого OKR устанавливаются, транслируются, выполняются, контролируются и подводятся итоги.

Цикл OKR обычно выглядит следующим образом:
➡️ Приоритизация: подготовка к формулированию OKR — определение общего направления деятельности организации на следующий период.
➡️ Фокус: создание целей и ключевых результатов продуктовыми группами и командами, обеспечение согласованности целей во всей организации и распространение их среди всех сотрудников.
➡️ Исполнение: выполнение работы, оценка прогресса, мониторинг метрик и корректировка действий при необходимости.
➡️ Обзор: оценка общей картины процесса OKR и текущего цикла, извлечение уроков и разработка плана улучшений.

Как выбрать цикл OKR?
Квартал — это самый распространенный период для цикла OKR, но существуют и альтернативные (например, годовые) циклы.

💡 Подстраивайте цикл OKR под бизнес-процессы и особенности своей компании.
Можно выбрать «двойной цикл», используя комбинацию квартальных и годовых OKR.

✈️ Больше про целеполагание и OKR мы говорим на нашем тренинге.
📌 Ближайшая группа 16-17 декабря.

Читать полностью…

— А знаешь ли ты, Джек, что благими намерениями вымощена дорога в ад?
— Знаю.
— Ну тогда пошли в лабораторию, найдём всё, что тебе нужно! - "Кошмар перед Рождеством"

🎃 Ребята, если вы еще не решили, какую ретроспективу провести для своих команд, то вот 3 шаблона, заряженные духом Хелоуина:

🍭 Trick or Threat

🪱 Nightmare Before The Christmas

🧛 Vampires, Werewolfs, Zombies

❓ Какую ретроспективу подготовили вы? Буду рада услышать ваши идеи в комментариях 👋

#ретроспектива

Читать полностью…

Матрица принятия решений в команде

Разные ситуации требуют разных процессов принятия решений в команде.
Решения могут приниматься одним человеком, некоторыми (например, экспертами), или всей командой.
🔍 Вопрос в том, когда использовать тот или иной подход к тому, как команда будет принимать решение?
➡️ Здесь на помощь приходит "Матрица принятия решений в команде" из Менеджмента 3.0.

Матрица командных решений поможет вам и вашей команде понять, когда следует использовать тот или иной способ принятия решений. Она помогает определить, нужно ли советоваться с командой или просто принять решение самостоятельно, а также определить, должно ли решение быть согласовано со всей командой или нет.

Создайте свою Матрицу принятия решений

1️⃣ Выпишите ключевые области, по которым обычно требуется принимать решения в команде.

2️⃣ По каждой области договоритесь, какой подход к принятию командных решений вы хотите использовать:
🔸 Один
🔸Большинство
🔸Некоторые
🔸Все
🔸Кубики/монетка

3️⃣Сохраните эти договоренности в командном пространстве и используйте, когда нужно принять решение.

💬 Обычно, мы создаем эти договоренности при запуске команды. Но если команда работает давно, а таких договоренностей нет, самое время этим заняться.

Читать полностью…

Критерии хорошей стратегии

Мы уже рассказывали вам о трех фреймах, которые можно использовать для создания стратегии. При этом, лучшего или универсального формата, как создать стратегию, нет.

⭐️ Но какой бы инструмент вы не выбрали, полезно создавать стратегии, которые удовлетворяют шести критериям, о которых мы рассказываем в карточках.

🔥 Подробнее о том, как посмотреть на стратегию, используя Карту гипотез, говорим на нашем воркшопе
🔥Ближайшая группа 31 октября

Читать полностью…

Полезный эфир для Скрам-мастеров

Партнер scrum.ru Ильи Павличенко поговорил с ребятами из Альфа Банка Сергеем Макаркиным и Михаилом Острецовым.

В Альфе одно из самых больших и сильных сообществ Скрам-мастеров в России (80 человек), поэтому было интересно послушать их точку зрения на:
🟡 Развитие компетенций и мастерства СМ
🟡Денежную мотивацию
🟡 Фокусы СМ
🟡 Культурный код и принципы работы СМ в Альфе
🟡Оценку эффективности

📎 Видео доступно по ссылке

Читать полностью…

Линейный мыслитель, дизайн-мыслитель и системный мыслитель заходят в бар...
Они говорят о доме будущего.

Линейный мыслитель рисует план дома. Он подробно описывает спальни, кухню, гостиную и т. д. Он убеждается, что в каждой комнате есть достаточное освещение, отопление и т. д.

Дизайн-мыслитель смотрит на план и перечисляет, чего захотят жильцы будущего (он уже опросил и наблюдал их в повседневной жизни). Он отмечает их образ жизни и стремление быть как можно более экологичными. Он спроектировал дом, работающий на солнечной энергии, из материалов, оптимизирующих энергопотребление. Он также проектирует довольно умные помещения, чтобы вписать их в образ жизни семьи.

Системный мыслитель отмечает, что дом будущего будет частью умного города, где преобладает жизнь на открытом воздухе, а люди возвращаются домой только для того, чтобы поспать. Он также отмечает, что материалы, используемые дизайнером, не вечны: они очень дороги и их сложно переработать по истечении срока службы. Кроме того, в их состав входят наноматериалы, влияние которых на здоровье человека не проверено. Поэтому в долгосрочной перспективе они могут принести больше вреда, чем пользы. Он также набросал схему того, как энергия будет распределяться между различными зданиями и помещениями в городе, и указал лучшие места для энергетических узлов.

В какое видение вы бы инвестировали?
➡️ Если вы сделаете ставку только на линейное мышление, вы можете увязнуть в мельчайших деталях дома и упустить общую картину.
➡️ Если полагаться только на дизайн мышление, можно в итоге создать красивые, элегантные решения не той проблемы или создать решения, которые увековечат проблему в долгосрочной перспективе.
➡️ Если полагаться только на системное мышление, можно оказаться парализованным всеми возможностями и всеми соображениями и в итоге вообще ничего не сделать.

✨ Нужно, чтобы все три составляющие работали вместе.
⭕️ Системный мыслитель определит ключевые проблемы и точки приложения усилий, которые помогут вам добиться эффекта и при этом свести к минимуму непредвиденные негативные последствия.
⭕️ Дизайн мышление поможет создать индивидуальные решения.
⭕️ Линейное мышление - сосредоточиться на тонкостях реализации.

Если вы посмотрите на свою организацию, то увидите множество примеров сложных проблем, которые сохраняются, несмотря на усилия по их решению.
Вы увидите множество примеров решений, которые поначалу работают, но впоследствии создают новые проблемы.
🌹 Если вы работаете над решением таких сложных проблем, у вас будет больше шансов добиться успеха, если вы пригласите трех мыслителей, а не какого-то мыслителя в одиночку.

💘 Взято у Houda Boulahbel

Читать полностью…

Зачем вообще кому-то что-то делегировать?

Выполнять множество задач самостоятельно может быть приятно — это создает чувство компетентности, контроля и позволяет оперативно принимать решения. Такой подход работает, пока организация или команда небольшая, потому что один человек в состоянии удерживать весь контекст и быстро принимать качественные решения.

Однако с ростом команды и бизнеса начинает работать "принцип темноты". Это означает, что менеджеру становится сложно удерживать весь контекст и контролировать каждый процесс, поскольку объем информации и количество задач значительно увеличиваются. Нагрузка становится слишком тяжелой как в эмоциональном, так и в физическом плане.

📌 В этот момент возникает потребность в делегировании задач.

“Делегирование — это передача полномочий и ответственности за выполнение задач от одного лица к другому, обычно от руководителя к подчиненному, с целью более эффективного распределения обязанностей и достижения оптимальных результатов.”

Зачем вообще кому-то что-то делегировать?
⬇️
Ответ, который напрашивается сам собой: чтобы не "утонуть" под бесконечным потоком задач. На любого лидера ложатся как стратегические задачи, так и рутинные операционные вопросы. Также нужно заниматься мотивацией и развитием сотрудников, не забывая о собственном развитии.
Без делегирования можно оказаться в ситуации, когда работа поглощает всё время и энергию, что ведет к эмоциональному и физическому выгоранию.
Есть и другие доводы в пользу делегирования.
⬇️
Отсутствие делегирования приводит к тому, что все решения сосредоточены в руках одного человека. Это замедляет процесс принятия решений, так как этот ключевой человек чаще всего перегружен задачами и не может быстро рассматривать каждый вопрос. Это имеет неочевидные экономические последствия. Немногие организации считают и управляют стоимостью задержки принятия решений – Cost of Delay.
⬇️
Кроме того, делегирование положительно влияет на мотивацию сотрудников. Когда задачи доверяют, человек чувствует свою значимость и вклад в общее дело. Делегирование дает возможность развивать новые навыки и применять их на практике. В итоге оно способствует росту вовлеченности и удовлетворенности сотрудников.

Так что делегирование - это не только про самого менеджера.
⚡️ Делегирование - это про эффективность команды и организации.

✖️ Больше о делегировании на нашем тренинге Менеджмент 3.0

Читать полностью…

3 ошибки в использовании метрик

Что стоит измерять Scrum-командам и организациям? Это важный вопрос.
Но важен не только сам факт измерений, но и то, зачем и как мы их используем. Именно это поможет понять, что на самом деле нужно измерять.

Три распространённые ошибки, которые ведут к неправильному использованию метрик

6️⃣Метрики как показатель успеха или провала
Метрики не должны использоваться для оценки успеха команды или лидера. Это всего лишь данные, которые помогают принимать решения. Когда мы начинаем считать, что хорошие показатели говорят о наших усилиях или навыках, мы можем упустить важную информацию для улучшений. В итоге цель становится не улучшить работу, а сделать так, чтобы метрики выглядели «зелеными». Это приводит к проблемам и трениям в команде и компании.

2️⃣Потеря фокуса на результатах для клиентов
Часто мы измеряем только то, что можем контролировать, например, выполненные задачи или потраченный бюджет. Но такие метрики не говорят нам о том, насколько довольны наши клиенты или как наш продукт помогает им. Это ведёт к тому, что мы можем «играть» с показателями, забывая об истинной цели – создании ценности для клиентов.

3️⃣Узкий взгляд на измерение ценности
Оценка результатов для клиента – сложное дело, так как на реакцию клиентов влияет много факторов. Нужно учитывать как краткосрочные, так и долгосрочные эффекты, а также качество и технические аспекты продукта. Поэтому лучше использовать разные показатели, чтобы видеть полную картину и понимать как рыночную ценность, так и внутренние возможности организации.

Например, Scrum.org предлагает нам смотреть на четыре категории:
➡️ Влияние на компанию
➡️ Результат для клиента
➡️ Выход, который мы получили в результате
➡️ Активность

💡 Наличие нескольких направлений для измерений помогает сбалансировать наш прогресс в достижении долгосрочных целей, а также нашу оперативность и эффективность как организации.

Читать полностью…

Термин HiPPO (от англ. "Highest Paid Person’s Opinion" — мнение наиболее высокооплачиваемого человека) описывает ситуацию, когда при принятии решений наибольший вес придается мнению самого высокопоставленного сотрудника, независимо от его знаний и опыта по обсуждаемому вопросу.

Эффект HiPPO может проявляться даже в самых незначительных ситуациях. Например, история с директором, который сделал замечание о цвете стен в региональном офисе, привела к тому, что стены действительно были перекрашены.
Еще более серьезный пример — когда генеральный директор, не имея глубоких технических знаний, настаивает на использовании определенной технологии, что приводит к неоправданным затратам и снижению эффективности работы команды.

Проблемы, Связанные с HiPPO
🔘Затрудненное общение. Сотрудники не хотят высказывать свои идеи, зная, что их мнение не будет иметь веса.
🔘Ограничение инноваций. Решения принимаются без учета мнений экспертов, что тормозит внедрение новшеств.
🔘Снижение психологической безопасности. Люди чувствуют себя неуверенно и менее склонны к высказыванию своего мнения, когда их идеи не получают должного внимания.

Что делать с HiPPO?
🔘Признайте существование HiPPO. Осознайте и обсудите влияние мнений высокопоставленных лиц на решения.
🔘Задавайте вопросы: "Мы следуем мнению HiPPO?" или "Может ли здесь присутствовать эффект HiPPO?"
🔘Приглашайте всех к участию. Выслушивайте мнения всех участников и учитывайте их знания и опыт. Используйте фасилитацию: освобождающие структуры, работу в малых группах.
🔘Переоцените решение. Критически оценивайте причины принятия решений и анализируйте доступные данные. Спросите: "Почему мы это делаем? Каково наше обоснование?"

🧬А вы свстречались с HiPPO в ваших организациях? Буду рада услышать ваши истории 🤩

Читать полностью…

Professional Scrum Master от Scrum.org

Уже через неделю проведем тренинг для тех, кто хочет по-настоящему разобраться в фреймворке Scrum.
️ Приятная скидка в 20% по промокоду PSM20.

📌 17-18 октября
➡️ Успевайте забронировать место

Читать полностью…

Приглашаем на Аджайл-митап в Москве

Программа:
💬 Алексей Пикулев: “Как токсичность разрушает продуктивность и потенциал команды”
💬 Илья Павличенко: “Ищите свой фреймворк”

После презентаций неформальный lean coffee.

📌 16 октября в 19:00
Москва
🔜 Регистрация по ссылке

Читать полностью…

Разработчик — не только тот, кто пишет код

Существует миф, что разработчики в Скрам-команде — это только те, кто пишет код.
Слова капитана очевидности, но каждый раз, приходя в новую компанию или обсуждая этот вопрос на тренингах, приходится развенчивать этот миф.

Разработчик — это человек, который что-то разрабатавает/создает.

🔜 Это любой человек, участвующий в создании чего-либо. Иногда это программное обеспечение, иногда — станок, иногда — маркетинговая кампания.

Разработчики в Скраме — это люди, приверженные созданию любого аспекта готового к использованию инкремента в каждом спринте. Конкретные навыки, необходимые разработчикам, зависят от предметной области выполняемой работы и могут быть самыми разными.

🔜 Это могут быть навыки аналитики, дизайна, маркетинга, работы с продуктом, программирования, тестирования — всего, что требуется для создания продукта.

▶️ Как только вы начинаете участвовать в проектировании, анализе, проверке, создании и т. д. продукта или услуги, согласно фреймворку Скрам, вы считаетесь разработчиком.

Кроме того, такие люди должны входить в Скрам-команду и продуктовую группу. Если люди, которые помогают создавать ваш продукт, проектируя, анализируя, тестируя и т. д., не являются частью Скрам-команды, это означает, что в команде отсутствует важный навык, что снижает общую адаптивность и результаты, которые вы можете достичь.

📎 Приходите разбираться в Скраме к нам на тренинг Professional Scrum Master.
В группу 17–18 октября осталось всего 3 места.
❤️ Приятная скидка в 20% по промокоду PSM20.
Регистрация 🔜 на нашем сайте.

Читать полностью…

МТС приглашает на конференцию TRUE Product Transformation

21 октября | 11:00 | Лофт «Весна», Москва + онлайн
23 октября | 11:00 | Онлайн

В программе доклады от руководителей Центра практик Agile МТС, CTO кластеров, директоров центров, лидеров Agile-практик и агентов изменений. Эксперты поделятся опытом проведения изменений в командах, результатами продуктовой трансформации и расскажут, какие инструменты помогли их достичь.
Будет интересно членам продуктовых команд, CTO, PO, CPO, Scrum-мастерам, Agile-коучам и руководителям, которые меняют процессы в компании и развивают компетенции сотрудников.

Конференция пройдет в лофте «Весна» в Москве и онлайн.

Подробная программа и регистрация по ссылке.

Читать полностью…

Уже через неделю мы проводим онлайн тренинг Management 3.0 Foundation

Это тренинг для лидеров по должности и по духу.
Обсудим современные подходы к управлению, делегирование, мотивацию и то, как создать и развивать команду, которая приносит результат.

📌 14-15 ноября
➡️ Присоединяйтесь

Читать полностью…

Команды с общим продуктовым фокусом как основа гибкости

На прошлой неделе партнер Scrum.ru Илья Павличенко выступил на конференции Agile-среда с докладом "Команды с общим продуктовым фокусом как основа гибкости".

В рамках подготовки, Илья сделал запись "прогона" выступления и поделился ею с нами.
Что можно найти в видео:
🟣 Тейлоризм в продуктовой разработке и его последствия: низкая скорость, низкая адаптивность
🟣 Интересный факт - 64% фич используются крайне редко или не используются вообще
🟣 Шокирующие результаты A/B тестирования в некоторых известных продуктовых компаниях
🟣 Новая парадигма: фокус на скоростном обучении и адаптивности в комплексной среде

🔜Видео доступно по ссылке https://youtu.be/F9Q_kMn8rjA

Читать полностью…

Самое интересное, чтобы ничего не пропустить

🍂 Неоправданные потери в продуктовой разработке: как избежать "страны пустых надежд"
Прежде чем погружаться в разработку, тестируем гипотезы через быстрые, дешевые эксперименты.

🍁 Вопросы, чтобы начать рабочую встречу по-другому
Попробуйте начинать встречу не с привычного "как дела?"

🍂 Конфликт в команде
Вмешиваться или нет? Когда уже пора помогать его преодолеть? И как?

🍂 Декомпозиция целей: от стратегического видения к задачам на спринт
Чтобы цели действительно стали достижимыми, важно разбить их на понятные, выполнимые шаги.

🍂 Ретро-набор от компании Spotify
Скачать и дать разработчикам, чтобы самостоятельно проводили ретроспективу.

🍄 3 ошибки в использовании метрик
Чего избегать и на какие категории метрик смотреть

Спасибо, что читаете ❤️‍🩹
Врываемся в продуктивный ноябрь!

Читать полностью…

Приглашаем на митап

В этот раз он будет посвящен конфликтам.

В программе:
💬 Алексей Пикулев: «Канвас Конфликтов  ‌  инструмент для разрешения командных противоречий»
💬 Екатерина Обухова: «Эффективная команда  ‌  инструменты бизнес-психолога»
💬 Илья Павличенко: «Маппинг полярностей  ‌  инструмент разрешения конфликтов»
💬 Алексей Штатнов: дискуссия «Конфликт или избегание? Взаимодействие Agile-коуча и бизнеса»

💌 14 ноября в 19:00, Москва
✏️ Регистрация по ссылке

Читать полностью…

Я с рекомендацией канала про IT менеджмент

Артём Арюткин работал директором по технологическому развитию в Департаменте данных и рекомендательных систем в Сбере. Я бы назвала его “человек-оркестр”, потому что опыта и знаний в разных сферах очень много.

🔥 В его канале @badTechProject можно найти и про работу с проектами, и про командную работу, много про личное развитие и про работу проджекта.
А еще почти каждый день полезный контент разбавляется мемами, от чего читать канал становится еще приятнее.

😍 Моя любимая рубрика у него - разборы фильмов:
🟣 Вот советы про увольнение из фильма MoneyBall
🟣 Кунг-фу Панда и как научить группу что-то делать быстро
🟣 Головоломка и важные мысли про работу
🟣 Захваченный рейс и ошибки в переговорах

Рекомендую @badTechProject ☀️

Читать полностью…

Попробуйте уточнять Бэклог продукта по-другому

Бэклог продукта — это упорядоченный и постоянно обновляемый список того, что необходимо сделать в продукте. Это такой "список идей". Прежде чем взять какую-то идею в работу, ее нужно проработать или уточнить.

Уточнение Бэклога Продукта — это процесс разбиения элементов на более мелкие и конкретные элементы, и их дальнейшее уточнение. Это постоянная деятельность по добавлению деталей, таких как описание, порядок и размер.

Как обычно проходит этот процесс?
🔜 Назначается встреча, на которой одна за одной разбирается каждая задача. Еще хуже, когда аналитики проделывают всю работу сами, принося проработанный элемент, а разработчикам остается просто исполнять.

🔥 Попробуйте работать над уточнением Бэклога продукта по-другому.
Вот идея от либераторов:

Пункты в Бэклоге продукта — это напоминания об обсуждениях, которые команде предстоит провести. Проработка этих пунктов — это не формальные, запланированные встречи.
Более того, не все задачи нужно прорабатывать всей командой. Поэтому и общая встреча не нужна.
Какие-то задачи могут прорабатывать отдельные подгруппы, которые затем поделятся результатами с остальными.

Мы видели, что командам помогает подход «Схождение-расхождение»:
1️⃣ Команда определяет, какие пункты нужно разобрать, и кто будет этим заниматься.
2️⃣ Небольшие группы работают над этим во время спринта, когда им удобно, (расхождение) и потом делятся результатами с командой для принятия решений (схождение).
3️⃣ Следующие этапы, такие как оценка и изменение порядка в Бэклоге, делают на основе этих результатов.
4️⃣ В зависимости от сложности задач такие циклы «расхождения-схождения» могут повторяться несколько раз в спринте.

Главное — чтобы проработка элементов Бэклога продукта оставалась командной работой. Даже если не все делают это одновременно, каждый должен участвовать. Если доработкой занимаются только аналитики или тимлиды, это плохая практика, так как не учитывает мнения всей команды.

⭐️ Больше о работе с Бэклогом продукта на нашем воркшопе
✏️ Ближайшая группа 11-12 ноября

Читать полностью…

10 мифов про DoD

Если свести фреймворк Скрам к одному элементу то это был бы готовый инкремент.

Это слова Кена Швабера, одного из создателей самого фреймворка Скрам.

🔜 А чтобы всем в команде было понятно, что значит "готовый", есть определение готовности - Definition of Done (DoD).

Определение готового помогает Скрам-команде обеспечивать цикл эмпирического процесса по продукту, обеспечивая прозрачность по состоянию продукта, его готовность к релизу для пользователей.
В целом, этот элемент появился в фреймворке когда Кен обратил внимание что часто разные участники процесса разработки продукта по-разному понимают что значит завершенная работа.

⭐️ И конечно же, вокруг DoD есть много мифов.
Самые популярные:
🔘DoD нужен для того чтобы понять готова ли фича
🟡DoD - это список требований
🔘DoD - это критерии приёмки
🟡DoD - это определение успешности разработки фичи
🔘DoD нельзя изменять
🟡DoD - это что-то разработческое, на бизнес не влияет
🔘DoD - необязательный элемент
🟡Большой DoD замедляет разработку
🔘Разные задачи могут иметь разный DoD
🟡DoD используется в одной отдельной команде

Каждый из этих мифов рассмотрел наш инженерный тренер Сергей Лобин в своей новой статье.

Читать полностью…

Четыре командных паттерна для эффективной поставки продукта

При разработке софтовых продуктов абсолютное большинство продуктовых команд сталкиваются с одними и теми же трудностями:
🟡 Непонятно, насколько то, что мы сейчас делаем, действительно ценно.
🟡 Всё важно; много параллельной работы; невозможно сфокусироваться на чём-то одном, самом ценном.
🟡 Разработка идет огромными фичами.
🟡 Вал незавершенной работы.
🟡 Релизы большие и редкие.

Большинство таких команд не знает своих клиентов и пользователей и никак не взаимодействует с ними. Главенствующая установка — мы либо поставляем сразу все, либо ничего. Каждый участник команды работает в функциональном колодце, фокусируясь на какой-то своей технической части без понимания цельной картины.

Метафора футбольной команды, наверное, лучше всего передает идею.
🔜 Команда приезжает на стадион. Ее приветствуют фанаты. Команда готовится к игре, собирается и выходит на поле. Фанаты ликуют. Звучит свисток, и команда получает мяч. Участники на поле видят друг друга. Они работают вместе, иногда небольшими группами, чтобы как можно быстрее переместить мяч по полю к воротам противника и забить гол. Победа – это забивание максимально возможного количества голов через тесное взаимодействие всей команды.
Команда всегда видит счет и оставшееся время. Они слышат реакцию болельщиков. А когда раздается свисток, они могут стремительно перегруппироваться и адаптироваться к сложившейся обстановке на поле. Команда работает как единое целое с максимальной производительностью.

Чего мы не увидим в футболе?
✖️ Пустого стадиона.
✖️ Большого количества мячей на поле, каждым из которых владеют разные участники одной и той же команды.
✖️ Брошенных мячей, до которых никому нет дела.
✖️ Поля, строго разделенного по функциональным зонам.

Есть четыре командных паттерна, которые помогают исправить эту ситуацию:
1️⃣ Прямое взаимодействие с пользователями и заинтересованными лицами
2️⃣ Разрабатываем продукт тонкими срезами пользовательской функциональности
3️⃣ Завершаем одно, прежде чем стартовать другое
4️⃣ Работаем как команда, а не группа разрозненных специалистов

Подробнее о каждом паттерне можно прочитать в статье нашего блога.

Читать полностью…

Конфликт в команде

Представьте, что между участниками вашей команды назревает конфликт.
Что вы будете делать? Вмешаетесь, чтобы потушить конфликт на ранней стадии, или подождете, пока «разгорится»? Конструктивные конфликты могут быть полезны, а вмешательство может помешать команде развиваться.
Но тогда, сколько ждать?
🔜 Если конфликт мешает продуктивности, нарушает рабочую атмосферу в команде или переходит перерастает в личные разногласия, вмешательство становится необходимым.
⚡️ Но ваша задача — не решать конфликт за команду, а помочь ей научиться справляться с такими ситуациями самостоятельно.

Шаги для вмешательства

1️⃣ Оценка конфликта
Прежде чем вмешиваться, важно оценить характер конфликта:
🟡Конструктивен ли он? Если спор касается рабочих вопросов (например, подходов к решению задач), это может быть продуктивной дискуссией. В таком случае лучше дать коллегам возможность обсудить это без вмешательства.
🟡Есть ли личные разногласия? Если конфликт переходит на личности или в команде ощущается напряжение, важно вмешаться, чтобы не допустить эскалации.
🟡Как долго продолжается? Если конфликт затягивается и начинает негативно влиять на работу, необходимо мягко направить команду на его разрешение.

2️⃣ Наблюдение и фидбэк
Если ситуация ещё не переросла в открытый конфликт, на начальной стадии можно предложить команде обсудить её, например, на ретроспективе:
🟣 Ненавязчиво обратите внимание на напряжение. Например: «Я заметил, что в последнее время возникают разногласия по поводу задач. Давайте обсудим, как можно улучшить наше взаимодействие».
🟣 Сосредоточьтесь на фактах. Это поможет избежать обвинений и эмоциональных реакций.

3️⃣ Фасилитация диалога
Если конфликт уже явный, стоит провести встречу с участием обеих сторон, чтобы помочь им обсудить проблему. Выступайте как нейтральный фасилитатор:
🔵 Фокусируйтесь на проблеме, а не на эмоциях. Важно помочь команде перейти от обвинений к обсуждению фактов: «В чем именно заключается проблема с выполнением задачи?» или «Какие шаги мы можем предпринять для улучшения ситуации?».
🔵 Применяйте активное слушание и перефразирование. Перефразируйте сказанное, чтобы стороны чувствовали, что их услышали: «Правильно ли я понимаю, что ты считаешь, что работа не была выполнена в срок из-за недостатка информации на старте?».

4️⃣ Психологическая безопасность
Работайте над созданием безопасной атмосферы, в которой каждый может свободно высказывать свои мнения:
🔵 Поддерживайте доверие и открытость. Объясните, что все мнения важны, и никто не должен бояться высказываться. Например: «Здесь нет правильных или неправильных точек зрения; важно услышать всех».
🔵 Призывайте к открытому обсуждению проблем. Если команда научится обсуждать возникающие проблемы сразу, они не будут накапливаться и превращаться в конфликты.

5️⃣ Использование ретроспективы
Ретроспективы — мощный инструмент для решения конфликтов. Можно направить обсуждение на выявление причин разногласий:
🟣 Фасилитируйте диалог. Спросите: «Что пошло не так в этом спринте с точки зрения взаимодействия?» или «Что вызвало недопонимание между участниками?».
🟣 Используйте техники для поиска корневых причин. Например, «5 Почему» поможет разобраться, что привело к возникновению конфликта, а не просто обсудить его поверхностные симптомы.

⭐️ Зрелость команды заключается в способности саморегуляции, в том числе в управлении конфликтами.

Читать полностью…

❤️ Приглашаем на ИТ конференцию «Agile среда в ПСБ: Импортозамещение и стратегии для финтеха».

💿 Что обсудим:

🟣Как гибкие практики помогают трансформировать цифровой бизнес
🟣Как выстраивать обратную связь с клиентами
🟣Как повышать качество пользовательского опыта и при этом сокращать время вывода продукта на рынок
🟣Как адаптировать мировой опыт практик и подходов и улучшать результаты
🟣Как лавировать в условиях импортозамещения

Также поделимся нашими кейсами и наработками.

В программе 14 докладов, 3 практических воркшопа и панельная дискуссия с экспертами ПСБ и лидерами в гибком управлении.

А еще будем много общаться, знакомиться, обсуждать вопросы после выступлений. И отдохнем на афтепати.

Регистрируйся! И до встречи!

Erid 2VtzqwdniXc
Реклама. ПАО "Промсвязьбанк". ИНН 7744000912

Читать полностью…

Регулярные полёты на Луну и Марс стали ещё ближе!
Ведь вчера SpaceX впервые успешно вернула на Землю многоразовый ускоритель самой тяжёлой ракеты Starship.

Это отличный повод рассказать, как в SpaceX внедрены принципы Agile, например, в подходе к разработке и тестированию.

⭐️ Инвестиции в автоматизацию разработки
SpaceX разработала систему, которая позволяет проектировать и проверять свои изделия через симуляции, а затем автоматически производить детали. Они внедрили систему 3D-моделирования, которая ускоряет производство и снижает затраты на детали, дизайн которых постоянно меняется. Вместо того чтобы каждый раз создавать новые пресс-формы для производства, они просто печатают новые версии деталей.
Этот подход отражает системное мышление, характерное для DevOps. Важно дать инженерам возможность как можно быстрее и проще переходить от дизайна к тестированию, сокращая время цикла разработки.

⭐️ Постоянно меняющийся дизайн
Если спросить инженера SpaceX о текущем состоянии проекта, его ответ может кардинально измениться уже через месяц. Для внешнего наблюдателя это может казаться хаотичным, но на самом деле это естественная часть эволюционного и гибкого процесса проектирования. Например, компания полностью пересмотрела свой подход к созданию марсианского корабля: сначала планировалось использовать Falcon Heavy с капсулой, но затем появилась идея Starship. Изначально он разрабатывался из углеродного волокна, но позже было решено использовать нержавеющую сталь, и уже через несколько месяцев SpaceX построила первый прототип.

⭐️ Быстрое тестирование и обучение
Когда компании приходится вносить такие крупные изменения в дизайн, традиционный подход мог бы задержать проект на годы. Обычно новый дизайн проходит длительную симуляцию и проверку, прежде чем будет построен первый прототип, который должен работать идеально. В SpaceX всё наоборот — они не ожидают, что прототипы будут идеальными или даже работоспособными.
Например, их первый прототип Starship был разрушен во время тестирования, но это было ожидаемо. Прототипы создаются для того, чтобы проверить границы дизайна и выявить недостатки. Уже строятся новые версии с учётом полученных данных.

🌙 Постоянные итерации, активное тестирование и способность быстро внедрять изменения позволяют компании быстро адаптироваться и совершенствовать свои разработки, значительно сокращая время до выпуска готового продукта. И всё это в условиях сложнейшего продукта.

Читать полностью…

Handelsbanken — уникальный банк с уникальной структурой

Пример того, как даже в крупных банках может работать всё то, о чем мы пишем.

Handelsbanken — шведский банк, основанный в 1871 году, с текущим числом сотрудников около 11 000 человек. Он работает в Швеции, Финляндии, Норвегии, Великобритании и Нидерландах.

Подход Handelsbanken можно описать через четыре основных элемента:

1️⃣Четкое стратегическое видение
🔹Превосходство во всех аспектах. Handelsbanken стремится быть лучшим во всех аспектах: лучшим местом работы для сотрудников, лучшим банком для клиентов и лучшей инвестицией для акционеров.
🔹Децентрализация. Девиз банка «Филиал — это банк» отражает широкую автономию, предоставленную местным филиалам для эффективной работы.
🔹Клиентоориентированность. Каждое решение начинается с анализа потребностей клиента.
🔹Прозрачная культура работы. Банк ставит во главу угла прибыльность, а не объем продаж, и постоянно совершенствует процессы, уделяя особое внимание удовлетворенности клиентов и эффективности затрат.

2️⃣Децентрализованная структура
🔹Местные филиалы. Каждый филиал является центром прибыли и отвечает за своих клиентов, сотрудников и рентабельность. Филиалы обладают автономией в разработке местных стратегий и принятии бизнес-решений с учетом особенностей своей клиентской базы.
🔹Центральный офис. Головной офис в Стокгольме отвечает за стратегию, ценности и кредитную политику на глобальном уровне.

3️⃣Прозрачная система учета
🔹Доступность данных. Всем сотрудникам доступны данные о результатах деятельности. Система отслеживает различные показатели эффективности, позволяя филиалам видеть, как их решения влияют на общую прибыльность.
🔹Установление ожиданий. Банк ориентируется на более высокую прибыльность по сравнению с аналогичными банками, достигая этого за счет снижения затрат и повышения удовлетворенности клиентов.
🔹Отчетность и бенчмаркинг. Ежемесячная отчетность, матрицы эффективности и таблицы рейтингов способствуют здоровой конкуренции и постоянному совершенствованию филиалов.

4️⃣Схема коллективного вознаграждения
💡Handelsbanken отказался от краткосрочных индивидуальных бонусов в пользу долгосрочной коллективной схемы распределения прибыли. Когда банк достигает высоких показателей рентабельности, часть сверхприбыли поступает в фонд. Этот фонд, принадлежащий сотрудникам, инвестирует в акции Handelsbanken и выплачивает средства по достижении сотрудниками 60-летнего возраста, способствуя их долгосрочной лояльности и заинтересованности в успехе банка.

В блоге Corporate Rebels можно найти много статей об этом удивительном банке.

#реальнаяжизнь

Читать полностью…

Измерение успеха трансформации

Любая трансформация в организации (цифровая, культурная, операционная) — непростой процесс. Нужно четко понимать, что нужно изменить и к каким последствиям это приведет. Если не оценивать успех, легко потерять контроль над процессом, упустить ошибки или отклониться от целей. Это может привести к провалу или поверхностным изменениям, которые не принесут результата. А там недалеко и до того, чтобы сотрудники потеряли мотивацию.

Почему важно измерять успех трансформации?
1️⃣ Оценка прогресса
Трансформации редко проходят быстро и гладко. Измеряя успех, можно увидеть, насколько компания продвинулась к своим целям, и сравнить ожидания с результатами. Это помогает корректировать процесс по мере необходимости.

2️⃣ Эффективное использование ресурсов
Изменения требуют больших затрат времени и денег. Оценка результатов помогает понять, насколько эффективно используются ресурсы, и где можно улучшить процесс, сделать его дешевле и быстрее.

3️⃣ Корректировка планов
Во время трансформации могут возникнуть непредвиденные трудности или новые возможности. Без оценки сложно понять, когда и что нужно менять. Иногда требуется больше времени или ресурсов, чем ожидалось, или какие-то изменения могут оказаться менее полезными.

4️⃣ Поддержание мотивации
Когда сотрудники видят, что их усилия приносят результат, это вдохновляет их продолжать работу. Если же прогресс незаметен, команда может устать и потерять веру в успех изменений.

5️⃣ Доказательство возврата на инвестиции (ROI)
Трансформация — это всегда инвестиции. Менеджеры хотят видеть результат и возврат на вложенные средства. Показатели успеха помогают доказать, что изменения оправданы, ведут к увеличению прибыли, снижению затрат, улучшению эффективности или повышению удовлетворенности клиентов.

Как измерить успех трансформации?
🔜 Своим опытом делится партнер Scrum.ru Илья Павличенко в нашем блоге.

Читать полностью…

Декомпозиция целей: от стратегического видения к задачам на спринт

Цель без плана — это просто мечта. Особенно это верно в мире разработки продуктов, где стратегические цели часто кажутся абстрактными или слишком крупными.
➡️ Чтобы цели действительно стали достижимыми, важно разбить их на понятные, выполнимые шаги.

Как это сделать?

1️⃣ Начните с глобальной цели. Например, ваша команда может стремиться увеличить удовлетворенность пользователей на 20%. Это отличная цель, но как её достичь?
2️⃣ Определите промежуточные цели. Для достижения удовлетворенности пользователей можно сфокусироваться на улучшении времени загрузки приложения, повышении юзабилити или улучшении техподдержки. Каждый из этих примеров можно сделать самостоятельной целью.
3️⃣ Декомпозируйте до уровня задач. В рамках спринта каждая промежуточная цель должна быть преобразована в конкретные задачи. Для улучшения времени загрузки можно, например, пересмотреть архитектуру кода или оптимизировать использование изображений.
4️⃣ Установите критерии успеха. Убедитесь, что каждая задача имеет измеримые результаты, чтобы в конце спринта можно было оценить прогресс. Важно, чтобы каждая задача соответствовала глобальной цели и вела к её достижению.

📌 Итоговый результат может выглядеть так: «Мы предполагаем, что за счет уменьшения используемых изображений на 30%, мы сможем сократить время загрузки страницы на 20%, что приведет к росту клиентской удовлетворенности на 2%».

💡 Декомпозиция целей помогает создать прозрачную и управляемую структуру работы, где каждая задача имеет смысл и приближает команду к стратегическим целям.

Читать полностью…

Ретро-набор от компании Spotify

Ретроспектива - обязательное для проведения каждый спринт, событие в Скраме. Классно, когда у каждой команды есть Скрам-мастер, он фасилитирует ретроспективу.
Но что если Скрам-мастер заболел/ушел в отпуск/к другой команде, а ретроспективу проводить надо?

💡 У компании Spotify возникла идея - создать инструмент, который позволит разработчикам самостоятельно проводить ретроспективы в легкой форме.
➡️ Так создался Spotify Retro Kit!

💌 Ретро-набор состоит из двух частей: черных страниц и цветных страниц.
Черные содержат некоторые основы ретроспективы, с которыми полезно ознакомиться перед проведением ретро. Цветные - это пошаговые инструкции по проведению.

Как пользоваться:
1️⃣ Решите, кто будет проводить ретроспективу.
2️⃣ Вручите ему Ретро-набор.
Если фасилитатор раньше не использовал Ретро-набор, ему/ей стоит просмотреть черные страницы, чтобы получить представление о том, как работают ретроспективы.
3️⃣ Затем фасилитатор выбирает любой формат.
4️⃣ И проводит ретроспективу.

📌 Скачайте Ретро-набор от компании Spotify по ссылке https://storage.googleapis.com/production-eng/1/2017/12/retro-kit3.pdf
Или создайте свой, идея огонь.

😋Кстати, форматами ретроспектив регулярно делится наша Женя в своем канале @plusdeltaplus
Можно взять её идеи для создания ретро-набора для своих команд.

Читать полностью…