Какие пользовательские истории хорошие?

Билл Уэйк один из основоположников Extreme Programming придумал удобную аббревиатуру для 6 ключевых характеристик хорошей пользовательской истории:
I — Independent (Независимая)
N — Negotiable (Обсуждаемая)
V — Valuable (Ценная)
E — Estimable (Оценимая)
S — Small (Маленькая)
T — Testable (Тестируемая)

✏️ Как использовать INVEST?
🟡После создания пользовательской истории вернитесь к критериям INVEST и проверьте “Соответствует ли история всем критериям”.
🟡 Если какие-то то критерии не соблюдены, то “Что нужно сделать, чтобы исправить её?”
Возможно, потребуется дополнительный диалог с пользователем или работа над её декомпозицией.
🟡После корректировки проверьте историю на соответствие INVEST снова.

❓ Хотите научиться создавать маленькие и ценные пользовательские истории?
🔜 Присоединяйтесь к нашему воркшопу по декомпозиции 24 июля.

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

За кулисами написания Agile Манифеста

В феврале 2001 года группа из 17 экспертов в области программного обеспечения собралась на горнолыжном курорте Snowbird в штате Юта, США, чтобы обсудить набирающие популярность подходы к разработке программного обеспечения, которые тогда называли легкими методами...

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

✏️ Мне всегда было интересно, что происходит за кулисами таких знаковых событий. Поэтому я раскопала воспоминания очевидцев и собрала их в статье.

💬 Почитайте, как творилась история.

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

Пользовательские истории - типичные ошибки

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

😥 Фокус на документации.
Одной из самых распространенных ошибок является превращение пользовательских историй в документацию, которая пишется и забывается. Карточка с историей — это не конечный продукт. Истории должны служить основой для обсуждения, уточнения и совместной работы участников команды и пользователей.
Что делать? ➡️Проводите совместные сессии по уточнению бэклога продукта, используйте фасилитацию (например, liberating structures, innovation games), чтобы вовлечь каждого участника процесса.

😥 Отсутствие обратной связи.
Даже если команда активно коммуницировала с пользователем, часто в процессе разработки теряется фокус на реальных потребностях пользователей.
Что делать? ➡️ Регулярно встречайтесь с конечными пользователями для получения обратной связи в ходе разработки. Это поможет уточнить их потребности и избежать ненужных изменений в дальнейшем.

😥Недостаток деталей.
Слишком общее описание может привести к различным интерпретациям и, как следствие, к некачественной реализации.
Что делать? ➡️Обсуждайте детали каждой пользовательской истории, включая возможные варианты выполнения. Разбейте крупную историю на более мелкие, чтобы улучшить понимание и реализацию. Например, можно использовать методику «трех уровней детализации», где история сначала описывается на высоком уровне, затем уточняются детали, и наконец, записываются конкретные шаги для реализации.

🌺На нашем воркшопе по декомпозиции, который состоится 24 июля, вы сможете углубить свои знания и навыки работы с пользовательскими историями и научиться избегать типичных ошибок.
➡️ Записывайтесь, пока есть свободные места!

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

Почему индивидуальные OKR не работают. Опыт Spotify.

В 2013 году мы решили отказаться от индивидуальных OKR для сотрудников.

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

1️⃣ Индивидуальные OKR тормозили нас.
OKR хорошо работают на корпоративном уровне, они отлично подходят для визуализации общих целей и результатов и заставляют всех двигаться в одном направлении. Но наш корпоративный уровень очень подвижен… наши цели быстро меняются, и адаптация интегрированных OKR на нескольких уровнях, вплоть до индивидуального, отнимает время и энергию, которые мы просто не можем себе позволить так часто.

2️⃣ В индивидуальных OKR речь идет о том, “как”. Мы же сосредоточились на причинах.
Наш бизнес развивается с бешеной скоростью. Мы убедились, что "почему" гораздо важнее, чем "как". И нам нужно все предельно упростить. Поэтому мы сосредоточились на определении приоритетов и на том, чтобы все понимали, куда и зачем мы движемся. Исходя из этого, наши команды и отдельные сотрудники сами решают, как это сделать. И они очень хороши в этом.

3️⃣ Shit in, shit out
С той скоростью, с которой мы работаем, фундамент, необходимый для установления хороших OKR, постоянно меняется и отстает. То, что мы формулировали в начале OKR цикла, часто уже устаревало, когда мы доходили до реализации.
Мы заметили, что тратим энергию на процесс, который не приносит никакой пользы. Поэтому мы решили отказаться от него и сосредоточиться на контексте и приоритетах. Мы убедились, что все точно знают, куда мы движемся и каковы текущие приоритеты, а затем позволили командам взять на себя ответственность за то, как этого добиться.

🔜 Индивидуальные цели ставятся таким образом, чтобы они не зависели от изменений в направлении нашего бизнеса. Таким образом, наши сотрудники могут сосредоточиться на том, чтобы бизнес работал, а не на том, чтобы работал процесс OKR.

📌 Мы говорим об OKR на нашем тренинге.
Присоединяйтесь!

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

Самое интересное за прошедший месяц

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

⭐️ Почему новые инициативы проваливаются
Или почему серебряных пуль не существует. Синхронное и системное изменение всех частей организации - вот ключ к успеху.

⭐️ Мне плевать на Scrum... но не на эмпиризм
О важных принципах, которые и есть самое ценное.

⭐️ Организация, основная на навыках…
в которой фокус смещен с традиционных должностных ролей на конкретные навыки и компетенции сотрудников. Набирающий обороты подход.

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

⭐️ Как генеральный директор Google использовал OKR для создания самого популярного в мире браузера.
Или о том, как 2 года не достигать целей, но продолжать бороться.

Спасибо, что читаете нас ❤️

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

Расписание тренингов Scrum.ru на июль

🌺 8-10 июля Professional Scrum Product Owner Advanced
Продвинутые инструменты управления продуктом для владельцев продукта и продуктовых менеджеров.

🌸 22-23 июля Certified OKR Practitioner
Основы для всех, кто занимается целеполаганием в организации.

🌸 24 июля Воркшоп по декомпозиции
Техники разбиения больших элементов Бэклога продукта на маленькие.

🌸 26 июля Воркшоп по ретроспективам
Секреты проведения эффективных ретроспектив.

☺️ Обучение на август уже можно забронировать на нашем сайте.
Все онлайн, можно участвовать из любой точки мира!

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

А насколько вы уверены?

В большинстве случаев мы переоцениваем свою уверенность. Это может мешать, например, при работе с матрицей важность\доказательства.

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

Как пользоваться:
✔️ Найдите тип данных который у вас есть на диаграмме
✔️ Посмотрите, в какую категорию он попадет
✔️ Вздохните, и подумайте над способом получения более достоверного подтверждения

🔜 Еще 25+ прикладных инструментов, которые мы отработаем на большом сквозном кейсе на нашем тренинге PSPO-A.
⭐️Возможность получить подтверждение знаний международным сертификатом, как приятный бонус.
😍 Приходите!

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

В лучших продуктах наиболее часто используется 16% функциональности. Среднее значение – 6.4%. Все еще думаете, что без вот этой вот важной фичи вообще никак?

"Неважно, насколько красива ваша теория, неважно, насколько вы умны. Если она не подтверждается экспериментом, значит, она неверна".
Ричард Фейнман, Американский физик-теоретик

🦞 Чтобы избежать ловушки, используйте простую матрицу: Важность\Доказательства.

➡️ На оси Х вы размещаете все свои гипотезы, чтобы показать, сколько доказательств у вас есть для подтверждения конкретной гипотезы.

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

✔️Для начала откажитесь от неважных идей.
✔️Затем критично пересмотрите гипотезы, оказавшиеся в верхнем левом квадранте. Точно ли они важны? Найдите доказательства этому.
✔️Правый квадрант тоже проверьте - точно ли у нас достаточно сильных доказательств, чтобы подтвердить, что гипотеза сработает?

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

Еще 25+ прикладных инструментов управления продуктом на нашем тренинге.
✨8-10 июля
🌺 Детали и регистрация по ссылке.

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

Возвращение в офис: стремление контролировать или повысить производительность?

Все больше компаний возвращают сотрудников на 100% в офис. Если говорить на чистоту, то не для того, чтобы повысить производительность. Это жажда контроля!

🔜 Недавнее исследование показало, что компании с низкими показателями выручки с большей вероятностью будут проводить политику возвращения в офис.
Почему? Не потому, что работа из дома вредит прибыли, а потому, что это удобная причина. Виноваты работники, которые лениво работают из дома, а не руководство - классическое уклонение.

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

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

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

Один из примеров - бунт Amazon. Более 5 000 сотрудников подписали петицию против требования компании возвращаться в офис.

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

⭐️ Какова же альтернатива?
Например, Spotify, Airbnb и Atlassian, придерживаются моделей удаленной или гибкой работы. Они признают ценность гибкости и доверяют своим сотрудникам.
Эти компании процветают, доказывая, что офис не является волшебным средством повышения производительности, как думают некоторые руководители.

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

⭐️ Компаниям пора проснуться. Гибкость - это не привилегия, это новый стандарт. Компании должны адаптироваться, иначе они рискуют стать реликтами ушедшей эпохи и потерять свои лучшие таланты в пользу более прогрессивных организаций.
Выбор очевиден: эволюционировать или умереть.
Эпоха жестких офисных мандатов закончилась - адаптируйтесь сейчас или останетесь позади.

Это адаптированный перевод статьи замечательных corporate-rebels

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

Техника SPIDR для декомпозиции пользовательских историй

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

Рассказываем об этом в наших карточках.

⚡️ Еще больше техник разбиения элементов бэклога продукта практикуем на воркшопе по декомпозиции.
Приносите свои большие задачи, разберемся с ними вместе!
Регистрация открыта.

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

Сформулировали OKR и хотите проверить их качество?

🪴 Вот вам чек-лист для проверки.

В нем лишь базовые пункты, на которые стоит обращать внимание. Вы можете расширить его, добавив другие пункты. Ведь у каждой организации и команды свой контекст. Подстраивайте инструмент под него.

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

Айтишник снова отказался править чужой код. Бесит, правда?

✅ «Я не могу сделать это за час, нужна минимум неделя»
✅ «Мощностей клиента не хватит на такой проект»
✅ «Нет, без тестов никак нельзя»

Если от этих фраз у вас начался нервный тик, приходите на открытый воркшоп для менеджеров «Чиним сломанный телефон» от Слёрма. В режиме реального времени будут учить договариваться о задачах и выстраивать коммуникацию с айтишниками.

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

Смогут ли в Слёрм примирить два конфликтующих мира? Узнаем СЕГОДНЯ в 19:00.

ССЫЛКА НА РЕГИСТРАЦИЮ: @crocodile_slurm_bot

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

Что Скрам-мастер делает весь день?

🔜 Если кратко, то Скрам-мастер отвечает за то, чтобы фреймворк Scrum работал в соответствии с руководством по Scrum.
🔜 А если чуть подробнее, то в наших карточках.

⚡️ У нас есть базовый курс для Скрам-мастеров от Scrum.org Professional Scrum Master
❤️ Ближайшая группа 27-28 июня
📎 Регистрация по ссылке

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

🤬Нет точной статистики о том, сколько людей страдают от выгорания. Согласно опросу агентства Gallup в 2021 году, около 76% работников в США заявили, что чувствуют выгорание в той или иной степени.

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

🙂Ниже приведены 9 вопросов для каждого из аспектов, которые помогут диагностировать выгорание.

Постоянное чувство истощения, вызванное переутомлением в течение продолжительного времени без адекватного или регулярного восстановления.
🔘Что истощает меня или вызывает стресс?
🔘Что мешает мне достаточно отдыхать или делать регулярные перерывы?
🔘Что придает мне энергии и чего не хватает в моей работе или жизни?

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

Эмоциональное отдаление от работы.
Обычно проявляется как антипатия, отвращение или даже ненависть.
🔘Что заставляет меня чувствовать себя негативно или цинично?
🔘Что мне нравилось в моей работе, но я больше не получаю от этого удовлетворения?
🔘Когда произошло это изменение и что его вызвало?

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

🚀Какой первый шаг вы можете предпринять для борьбы с выгоранием?

😎 Хорошей пятницы, ребята! Полноценно отдохните и не выгорайте!

#ментальное_здоровье

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

$306 000 или 5 500 часов разработки в год.
Это средняя стоимость технического долга для продукта в 1 миллион строк кода.

Ребята из компании Sonar провели масштабное исследование стоимости технического долга.
В течение 12 месяцев они изучили более 200 реальных проектов разного масштаба и на разных языках программирования. Полученные данные составили около 11 миллионов строк кода.

Основные выводы исследования:
⚡️ По оценкам, в течение пяти лет расходы, связанные с техническим долгом за 1 миллион строк кода, могут достигать 1,5 миллиона долларов, что эквивалентно 27 500 часам работы разработчика. Кроме того, проблемы технического долга становятся все более сложными и обременительными, если их не решать, что сказывается на общем качестве продукта.
⚡️ Каждый месяц технический долг растет по мере добавления новых проблем. Объем новых проблем, создаваемых ежемесячно, варьировался в течение 12 месяцев по всем анализируемым проектам.

Звучит дорого, не так ли?

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

Если хотите научиться находить правильный (и обоснованный!) баланс между разными типами работы, приходите к нам на Воркшоп по работе с Бэклогом Продукта.

🔥 Снижение стоимости вашего техдолга на 0.2% окупит тренинг.

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

В Скраме нужно делать релиз в конце Спринта. Правда или ложь?

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

Что это означает в применении к нашему вопросу?

Во-первых, правила игры говорят нам, что нам нужен готовый Инкремент каждый Спринт. Что является готовым Инкрементом, зависит от определения готовности (definition of done, DoD), о котором договорилась Скрам-команда. В разных командах определение может отличаться: где-то это коммит в main-ветку, где-то это подразумевает, что Инкремент продукта находится в руках пользователя. В зависимости от силы вашего DoD вы можете принимать более обоснованные решения по наиболее полной обратной связи. В первом случае обратная связь будет отложена — вам нужно еще произвести действия для того, чтобы новая функциональность оказалась в руках пользователя, во втором случае вы можете уже полноценно собирать обратную связь от пользователя. То есть правила Скрама не заставляют вас выходить в релиз, но вы должны понимать, что без него вы как минимум откладываете момент получения обратной связи.

Также правила Скрама не ограничивают, сколько раз вы поставляете Инкремент вашим пользователям. Если вы технически можете делать поставку более одного раза в Спринт, то можете делать поставку так часто, насколько вам позволяет ваш уровень технического совершенства. В Netflix, например, количество релизов в день исчисляется сотнями, в Google - тысячами.

Подводя итог: Скрам-команда не обязана делать поставку каждый Спринт, но она должна создавать полезный Инкремент, готовый к поставке. Если вы можете делать это несколько раз за Спринт, Скрам вас в этом также не ограничивает.

О том, как работать в настоящей Скрам-команде и как минимум раз в Спринт поставлять полезный Инкремент продукта, мы обучаем на тренинге APS-SD. Ближайший тренинг состоится 18-20 сентября, регистрация уже открыта.

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

Вы выбрасываете 50% своих денег.
А в США софтверным компаниям это обходится в 2.08 триллиона долларов в год. Это стоимость дефектов, согласно исследованию.
А еще добавьте сюда стоимость технического долга, о которой мы писали.

Согласно другому исследованию:
🟡 6.5% ошибок возникают на этапе прояснения требований,
🟡 25% - при проектировании,
🟡 а еще 15% в результате неудачных попыток починить предыдущие дефекты.
🔘 На долю кода приходится всего 25% ошибок.

В январе 2021 года на форуме Software Intelligence Forum компания Accenture признала, что, по ее данным, основанным на 1000 проектах, до 35% дефектов вызваны проблемами с прояснением требований.

При этом многие организации по-прежнему фокусируются на быстром выпуске большого количества фич...

Не хотите терять так много? 🔜 Снизьте свои ожидания от количества поставленных фич вдвое. Инвестируйте это время (и деньги) в продуктовое и техническое качество.

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

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

В этом канале уже была и Пиратская ретроспектива и Пиратская ретроспектива 2.0... Но ко дню рождения канала, я решила, что должна быть еще одна 👀

На этой неделе я читала исследование факторов эффективности скрам-команд и сопутствующие блог посты Либераторов. И один из них был "10 форматов ретроспективы, основанных на модели эффективности скрам-команд". Я решила взять один из форматов за основу для моей ретроспективы.

Как получить ретроспективу в Miro?
🟡Просто скопируйте фреймы на свою доску
⚠️ Чтобы копировать с доски, вы должны быть залогинены в miro.
или
🟡Скачайте файлы для любого другого инструмента

Готово!

🔔 Приглашаю узнать еще больше о ретроспективах на воркшопе. Регистрация открыта, буду рада вас видеть!

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

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

Уже через неделю мы проводим онлайн тренинг Professional Scrum Product Owner Advanced

Это официальный тренинг для Владельцев Продуктов от Scrum.org второй ступени.
После тренинга будет возможность сдать экзамен и получить сертификацию от Scrum.org PSPO II

🍀 8-10 июля
📎 Успевайте занять место

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

«Никому не не нужен Скрам» – как вам такое?

🔜 Организациям нужны не фреймворки, а результаты, которые они могут дать, если они соотносятся со стратегией компании.
⚡️ Наш партнер Роман Дорошенко и Антон Скобин из Слёрм обсуждают эту тему и многое другое в свежем подкасте.

Выбирайте любую платформу для прослушивания https://slurm.mave.digital/ep-54

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

Мы РАЗЫГРЫВАЕМ БИЛЕТ на Летний Agile-ретрит

Мы придумали событие, где можно обменяться опытом и найти вдохновение, расслабиться и встретить единомышленников. Мы назвали его Аджайл-ретритом.
🌸 Вас ждут воркшопы от организаторов и Open Space, где можно заявить и обсудить любую актуальную тему.
📍 Летний Agile-ретрит пройдет 12-13 июля в Подмосковье.

💛 Наших студентов мы приглашаем поучаствовать в розыгрыше билетов на Аджайл-ретрит.
Условия простые: просто напишите в комментариях отзыв на наш тренинг, в котором вы принимали участие.

🌞Среди самых теплых отзывов и выберем победителей 8 июля!

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

Почему “Семерка” так себе команда

За просмотром нового сезона "The Boys" еще раз убедилась, что команда из Семёрки так себе… Начиная с лидерства Homelander, заканчивая корпоративной культурой Vought, в которой они существуют.
Посмотрим на основные проблемы и не будем повторять их в своей организации.

1️⃣Отсутствие доверия: даже скорее, его вообще нет. Суперы постоянно подозревают друг друга, часто действуют в своих интересах и предают друг друга, если это выгодно им.
2️⃣ Корпоративные манипуляции: Семёрка управляются корпорацией Vought, которая манипулирует командой ради собственной выгоды. Это создает токсичную атмосферу цинизма и недовольства среди участников.
4️⃣Различные мотивации и цели: Не помню ни одну "миссию", ни одно задание, вокруг которого сплотились бы все суперы. У членов команды разные мотивы и цели, которые часто противоречат друг другу. Например, Твердыня жаждет абсолютной власти и контроля, в то время как Королева Мейв или Звездочка хотят использовать свои силы для более благородных целей.
4️⃣ Недостаток командной работы: В Семёрке отсутствует настоящая командная работа. Участники редко сотрудничают эффективно и часто действуют независимо друг от друга, что снижает общую эффективность группы.
5️⃣ Эго и конфликты: Личное эго и внутренние конфликты часто мешают работе команды. Твердыня, как лидер, своими действиями усугубляет эти проблемы, вместо того чтобы решать их. Например, его ревность к любому Суперу, который может оказаться сильнее его и желание постоянно доминировать над другими.
6️⃣ Отсутствие процессов и структуры: Команде не хватает четкой, структуры, процессов, да и вообще какой-то цели. Это приводит к хаосу и неэффективности в их действиях. Каждый действует так, как хочет.
7️⃣ Проблемы с управлением и лидерством: Ну и лидерство со стороны Твердыни и влияние Vought приводят к отсутствию четкого направления и стратегического планирования. Плюс к полному отсутствию психологической безопасности.

🙂 Как думаете, к Пацанам тоже стоит присмотреться? Может они настоящая команда?

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

Воркшоп по проектированию гибких организаций на летнем Аджайл-ретрите

🌸 Как спроектировать гибкую организацию?
Мы будем отвечать на этот вопрос с помощью “звездной модели” Джея Гэлбрейта. Она состоит из пяти политик проектирования: стратегия, структура, процессы, награды и HR-политики.

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

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

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

🌺 Летний Аджайл-ретрит пройдет 12-13 июля в Подмосковье
🔴 Регистрация по ссылке

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

Итеративно-инкрементальная разработка - что вообще это такое?

Scrum использует итеративный, инкрементальный подход для оптимизации предсказуемости и контроля рисков (Руководство по Скраму).

Слова “итеративный” и “инкрементальный” перечислены через запятую. Это разные подходы? Можно работать в чистой итеративной разработке и не использовать итерации (Спринты)? Или работать Спринтами, но в чистом инкрементальном стиле? Запутались? Возвращаемся к основам и разбираем разницу между итеративной и инкрементальной разработкой.

📌Что следует учесть при итеративного-инкрементальном стиле разработки? Здесь можно прислушаться к советам Алистера Коберна, одного из подписантов Аджайл Манифеста:
🟡Заранее примите то, что вы неизбежно будете переделывать пользовательский интерфейс и архитектуру вашего продукта. Иногда многократно.
🟡На каждую новую фичу планируйте как минимум 2 переделки пользовательского интерфейса, одну переделку требований и изменение архитектуры.
🟡Учитывайте, что обычно первая переделка занимает 1/3 изначального времени разработки, вторая 1/2.

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

Анти-паттерны менеджера продукта

Собрали для вас 6 частых анти-паттернов поведения менеджеров продуктов, которые встречаем в нашей практике.

✖️ Писатель историй
Согнутая спина, глаза устремлены в монитор, 14-шаговый шаблон в Jira. История, есть. Критерии приемки - есть. Обсуждения с разработчиками и заинтересованными сторонами приводят только к обновлению описания задачи.

✖️ Менеджер проекта
Часто его называют максимизатором производительности. Он покажет вам графики в Jira, он знает все о скорости и предсказуемости, а максимизация производительности и реализация всех фич - его основная задача.

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

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

✖️ Привратник
"Слушай, у меня сейчас нет времени на это, просто прочитай мое вчерашнее письмо и выбери самое важное из бэклога продукта. Также сообщите мне, когда будет готова первая фича, чтобы я мог согласовать ее, хорошо?". Это и есть Привратник – всегда быть промежуточным звеном...

✖️ Менеджер
"Занимаетесь ли вы сегодня веселой, интересной и инновационной работой? Как у всех сегодня с энергией? Все ли мы хорошо себя чувствуем?" Другая крайность, где теряется фокус на коммерческом результате. Менеджер обычно проводит множество бесед один на один с каждым из членов команды.

❓ Замечаете что-то за собой?
⚡️ Приходите к нам на PSPO-A.
Научим управлять результатом, а не Jira или командой. Сразу применим знания на большом сквозном кейсе, чтобы вам было проще забрать 25+ инструментов в свою работу.
📎 Ближайшая группа 8 июля
🔜 Регистрация по ссылке

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

Что такое продуктовый подход и почему о нем все говорят

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

🔵Это способ взглянуть на продукт или услугу с точки зрения клиента и разработать его с учетом его потребностей.
🔵Этот подход фокусируется на самом продукте или услуге, а не на отдельных компонентах, составляющих продукт или услугу.

Создавать востребованные продукты, звучит здорово, правда? Во многом благодаря этому словосочетание «продуктовый подход» можно так часто встретить. Но так ли просто действительно стать продуктовой компанией?

❗️Обратите внимание на формулировку – ⏪способ организации бизнеса⏩. Это значит, что если цель организации – создание коммерчески привлекательных продуктов, в большинстве случаев сохранение организации в ее первоначальном состоянии невозможно.
➡️Поэтому недостаточно нанять людей с продуктовыми компетенциями, внедрить процессы discovery взамен привычной аналитики или переименовать проектных менеджеров в продуктовых.

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

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

⚡️ О продуктовом подходе мы говорим на нашем тренинге. Приходите!⚡️

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

Игровой мастер-класс по психологической безопасности на летнем Аджайл-ретрите

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

С помощью бизнес-игры «Мастер Доверия» мы готовим игровой мастер-класс по безопасности для команды. И уже летом, на нашем Аджайл-ретрите, мы впервые представим специально разработанный сценарий для игровой сессии. Он поможет вам глубже понять и улучшить психологическую безопасность в вашей команде.

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

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

🔴 Аджайл-ретрит пройдет 12-13 июля 2024 года в Подмосковье.
🌸 Регистрация по ссылке.

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

Как генеральный директор Google использовал OKR для создания самого популярного в мире браузера

Согласно принципам Google, если цель выполнена на 70% (в среднем), то это считается успехом. Никто не ждет, что вы получите "зеленый (100%) цвет" по каждому OKR, — это не способствует росту результатов команды. Но существовало внутреннее напряжение, потому что никто не взял бы вас на работу в Google, если вы не были нацелены на успех.

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

Ларри всегда мастерски завышал планку. Он любил повторять определенные фразы. Он хотел, чтобы сотрудники Google чувствовали «некомфортное воодушевление».
Я старался сделать то же самое для команды по разработке продуктов. Мне потребовалось мужество, чтобы написать OKR, который вполне мог провалиться, но другого пути не было, если мы хотели стать великими.
Мы сознательно поставили планку в 20 миллионов еженедельных активных пользователей к концу года, понимая, что это непосильная задача, ведь мы начинали с нуля. Как лидер, вы должны попытаться бросить вызов команде, не заставляя ее чувствовать, что цель недостижима. Я считал, что мы вряд ли достигнем цели в срок. Но я также считал важным продолжать работать на пределе своих возможностей.

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

Продолжение о том, как Google Chrome - с 2008 по 2010 годы они не достигали поставленную цель по количеству пользователей, при этом каждый год только увеличивая планку в нашем блоге.

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

Организация, основная на навыках

или Skills-Based Organization - новый подход, который набирает обороты.

Skills-Based Organization (SBO) — это концепция управления и организации компании, в которой фокус смещен с традиционных должностных ролей на конкретные навыки и компетенции сотрудников. В такой организации главными элементами становятся не должности и иерархия, а индивидуальные навыки, знания и опыт работников.

Суть в том, что компаниям нужно собирать у себя и управлять скорее навыками, а не традиционными понятиями работы, ролей или должностей. Потому что рынок слишком быстро меняется, чтобы выжить, компании нужно быстренько подстраиваться.
🔜 Нет "рабочих мест", есть "работа", которую нужно делать, а для работы нужны скиллы, а не должности или роли.

Основные принципы:
🟡 Фокус на навыках: Задачи и проекты распределяются на основе навыков и компетенций, а не должностных обязанностей - чтобы максимально эффективно использовать знания каждого.
🟡Гибкость и адаптивность: Организации могут быстрее адаптироваться к изменениям и новым требованиям рынка, так как могут перераспределять ресурсы и формировать команды под конкретные задачи.
🟡 Постоянное развитие и обучение: Особое внимание на непрерывное обучение и развитие сотрудников, чтобы они могли приобретать новые навыки и компетенции.
🟡 Проектная работа: Часто задачи и проекты в таких организациях реализуются в рамках временных команд, сформированных на основе необходимых для конкретного проекта навыков.
🟡Управление талантами: Основной фокус на управление талантами и потенциалом сотрудников, что способствует повышению их мотивации.

💬 Концепция привлекательная, но есть и вопросики.
Например, в динамические команды мы не верим вообще.

А что думаете о Skills-Based Organization вы?

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

Почему новые инициативы проваливаются

Наблюдаем уже третью компанию, которая пробует OKR-ы и, разочаровавшись в подходе, откидывает его. Очередная “серебряная пуля" не подошла...

🔜 Посмотрите на модель организационного дизайна Гэлбрейта - это система, состоящая из пяти элементов: стратегия, структура, процессы, награды и HR-политики. Элементы взаимно зависимы и связаны между собой. Изменение в любом из элементов автоматически означает изменения в других.

Основные части системы образуют связное множество, то есть между любыми двумя частями можно найти путь. Ни одна основная часть системы не оказывает независимого влияния на систему, частью которой она является.
Рассел Акофф

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

❓ Что делать?
🔜 Забыть про “серебряные пули” и, закатив рукава, системно подходить к изменениям в организации:
🟣Возьмите инициативу, посмотрите на текущий дизайн организации.
🟣Поймите, как новая инициатива должна повлиять на все части организационного дизайна. Что должно измениться в структурах, процессах, наградах и HR-политиках?
Изменения должны происходить синхронно.

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