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

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

Напоминаю, что:
1️⃣ все изменения мы проводим с тестами, и они должны оставаться “зелеными”. Это помогает нам быть уверенными, что система работает, как и прежде.
2️⃣ нужно четко разделять фазы написания кода и рефакторинга, апологеты экстремального программирования (XP) говорят о двух шапках рефакторинга.

Итак, когда же нужно рефакторить?

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

2️⃣После написания кода. Вы написали кусок кода, он делает то, что нужно, позаботьтесь о тех, кто будет с ним работать потом. Как любит повторять Кент Бэк, автор XP:

"Make it work, make it right, make it fast"

3️⃣Правило трёх. Удивительно, но разработчики тратят больше времени на чтение кода, а не на его написание. Дядя Боб Мартин, говорит про соотношение 10:1. Поэтому, если вы можете сделать код более читаемым, сделайте это, однако, правило трёх гласит, что не нужно бросаться менять неудачный код сразу же, (помните про экономику?) если наткнулись на него в первый раз, запомните, если во-второй - подготовьтесь, в третий - можно смело рефакторить.

4️⃣При разработке через тесты (TDD). Когда вы работаете по TDD, рефакторинг уже заложен в процесс:
❌ пишете “красный” тест
✅ необходимый код для того чтобы тест “позеленить”
🔄 рефакторинг. Важно отметить, что вы можете изменять как структуру кода, так и тестов, в этом случае код вам будет помогать убеждаться что ничего не сломалось в поведении.

О том как применять рефакторинг и другие инженерные практики, используя фреймворк Скрам, мы обучаем на нашем самом инженерном тренинге по Скраму и самому скрамному тренингу для инженеров - Applying Professional Scrum for Software Development (APS-SD). Ближайший тренинг в сентябре 📆, регистрация тут.

Приходите сами и приводите с собой свою команду!

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

Как продакту стать предпринимателем или продакт, который смог...

Это гостевой пост от канала Фари @Xuyanet (РОСЛОВЕЦ, если быть точным)

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

1. Риски. Мой спектр рисков и отношение к ним сильно поменялся. Когда ты продакт, ты на 80 процентов ощущаешь риски иначе, чем собственник бизнеса. Как говорит наш друг семьи "когда ты открываешь компанию, ты уже преступник". Юридические, финансовые, репутационные, риски связанные с интеллектуальной собственностью - все это то, чем забита голова ежедневно. И продакт в них варится отчасти. Продакт о них заботиться по остаточному принципу. ОН как минимум о них думает меньше...

2. Бумажки. Проблемы в пункте 1 вытекают в пункт 2. Мне кажется, что на старости лет я могу стать договорником))) я буду бабкой ,которая цепляется в бумагах ко всему и ржет от лиц всех присутствующих))))) В день с бумагами разного толка я сталкиваюсь раз 5 минимум. Кто-то это называет "операционкой". Я же называю это "ад на земле".....у меня ощущение, что меня все равно где-нибудь наебут как бы я не старалась))))

3. Кстати, никто не отменяет и того, что помимо всего прочего вам ваще-то надо ПРОДАВАТЬ! Кто сказал, что когда вы создали компанию, вы будете, как тот математик что пишет красивые формулы на прозрачном стекле? Думаете теперь будете только и делать, что думать о стратегии, росте, технологии и коде? ХАХАХАХАХАХА - вы это делать будете между делом бл...хотя это то ради чего мы собственно и собрались в этой компании. Поэтому работать мы будем в свободное от этой "ОПЕРАЦИОНКИ" время))))) я утрирую немного конечно, но из за пунктов 1 и 2 я не успеваю полноценно заниматься продуктом так как бы я этого хотела...

..Поэтому наконец-то я вспомнила уроки, которые я получила на МБА по построению системы. Но это другая история. О ней я когда нибудь напишу, когда мы получим в инженерке осязаемый результат по построению систем в бизнесе. В целом некая система у нас в Инженерке вырисовывается по одному из направлений

4. Теперь я понимаю почему некоторые фаундеры сходят с ума и начинают обращаться ко всяким ведуньям))))))))) это такая форма отчаяния)))) Никакой анализ рынка (привет продакты!) не дадут вам гарантию, что продукт полетит и у вас как фаундера в этом пункте чувства сильно обостряются))))) То есть, как продакт головой я это всегда понимала и защищала идеи продуктов перед бизнесом довольно таки успешно понимая все болевые точки бизнеса, но...когда я стала фаундером, я понимаю, что я сейчас вложу миллион, а анализ рынка с его инсайтами и выводами не гарантирует мне хоть какой либо возврат средств))))))

Фаря - Co-founder и CPO inzhenerka.Tech-тренажеры для инженеров. Сейчас живет во Франции и ведет канал о том, чем отличается головная боль продакта и предпринимателя, как строить и растить свой IT продукт, а также про работу айти во Франции.

Вот посты, которые мне понравились и с которых рекомендую начать знакомство с каналом:

👨‍💻Продакт vs предприниматель
👨‍💻Как мы сэкономили на разработке MVP
👨‍💻Конкурент о котором забывают
👨‍💻Как меняется мировозрение продакта, когда он становится предпринимателем

Переходите на канал @xuyanet и подписывайтесь 🤼‍♀

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

20 вопросов, чтобы выявить ценность

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

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

⚡️ Скачивайте 20 вопросов, которые помогут в этом.
Нашла их тут.

⭐️ Больше о работе с продуктом на наших тренингах:
🟡PSPO
🟡PSPO Advanced

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

SEAGULL или чайка-менеджер (от англ. "Senior Executive that Always Glides in, Unloads and Leaves Loudly") описывает менеджера, который внезапно появляется в последний момент, врывается на совещание, разрушает всю проделанную работу своими критическими замечаниями, а затем исчезает, оставляя проект под угрозой срыва.

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

Что делать с SEAGULL:
Подумайте, как бы вы реагировали на птиц, и адаптируйте эти практики для офиса.

🟢Признайте существование SEAGULL: осознайте и обсудите случаи, когда руководитель внезапно вмешивался в процесс работы. Проанализируйте последствия таких вмешательств для проекта и команды.
🟢Не кормите чайку: оставайтесь спокойными и не поддавайтесь на провокации.
🟢Установите четкие границы: определите, на каком этапе можно вносить комментарии и предложения. Старайтесь избегать внезапных изменений в последний момент.
🟢Установите циклы обратной связи: проводите регулярные встречи и обсуждения, чтобы чайка была в курсе прогресса и могла вносить свои предложения постепенно, а не в последний момент.
🟢Держите фокус на решении: при критике со стороны чайки сосредоточьтесь на поиске решений, а не на исправлении ошибок. Задавайте вопросы, чтобы выяснить, как можно улучшить работу, а не просто угодить чайке.
🟢Создайте атмосферу, в которой сотрудники чувствуют себя уверенно и защищено, даже при наличии критики.

🤔 Есть ли в вашем окружении менеджер с репутацией чайки?

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

Все одержимы идеей создания высокоэффективных команд. И мы тоже!
Очередная книга "Социальный мозг: Психология успешных групп" посвящена этой теме.

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

Делюсь тремя выводами из книги.

📖 Вывод 1 - Размер имеет значение
Когда мы думаем о командах, мы думаем об их цели, сплоченности, развитии и т.д. А вот о их размере думаем не всегда. Может ли команда быть неправильного размера, чтобы справиться с задачей? Когда команда становится слишком большой? Токсичные культуры, которые бывают в организациях - менталитет "мы и они" - могут быть объяснены размером группы? Да!
➡️ Гипотеза заключается в том, что размер мозга вида и доступное время ограничивают размер социальных групп этого вида. Для людей максимальный естественный уровень составляет 150 человек. После этой цифры взаимодействие так себе. Это число Данбара и может быть эволюционным пределом значимых социальных отношений, которыми человек может управлять в любой момент времени.
Мы можем поддерживать связи с:
🔸 нашими близкими (1 или 2),
🔸 близкими друзьями (5),
🔸 лучшими друзьями (15),
🔸 хорошими друзьями и нашим основным кругом общения (50),
🔸 хорошими знакомыми (150),
🔸 знакомыми (550),
🔸 лицами, чьи имена мы можем вспомнить (1500),
🔸 и людьми, которых мы узнаем, но не можем вспомнить имена (5000).

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

📖 Вывод 2 - Шесть элементов для достижения групповой производительности
Социальные связи являются основополагающими для благополучия и продуктивности человека, потому что наш мозг настроен на формирование социальных связей, которые имеют решающее значение как для индивидуального, так и для группового успеха. Лидеры могут использовать это понимание, создавая среду, в которой члены команды чувствуют себя связанными и ценными. Существует шесть факторов, на которых лидеры должны сосредоточиться, чтобы повысить эффективность работы и благополучие команды:
🔸 сплоченность
🔸 принадлежность
🔸 общие ценности
🔸 общая цель
🔸 культура
🔸 возможности для развития

📖 Вывод 3 - Роль доверия и сопереживания
Доверие и эмпатия - самое важное для успешных команд. Доверие снижает стресс и способствует чувству безопасности, а эмпатия помогает понять и удовлетворить потребности и проблемы членов команды. Лидеры должны сосредоточиться на создании доверия, будучи прозрачными, последовательными и проявляя искреннюю заботу о благополучии своей команды. Эмпатию можно развить, активно слушая и оказывая поддержку в трудные времена.

#книги

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

4 совета по созданию более сплоченных команд

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

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

1️⃣ Работайте вместе, по-настоящему.
Самый работающий способ!
🟡 Создайте общую цель. Ту, на которую каждый будет влиять. Тогда и координация между людьми для достижения общей цели возникнет. Вкладывайтесь в определение целей спринта и целей продукта, если работаете по Скраму или в квартальную цель, если она есть.
🟡 Если поставить общую цель слишком сложно, работайте над какой-то задачей в совместном формате:
🔜 Сворминг
🔜 Пары
🔜 Мобинг

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

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

4️⃣ Подавайте пример.
Наконец, подайте пример, сами сделав все вышеперечисленное. Вы можете добавить название команды в приглашения в календаре. Вы можете сесть пару с другими или пригласить других составить пару с вами. Вы можете принести угощения, чтобы отпраздновать свой недавний успех. А еще вы можете использовать планирование спринта и Ежедневный Скрам, чтобы побудить участников работать вместе, а не порознь.

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

Scrum - про продукт

⏪В обновленном в 2020 году в Scrum Guide появилось определение продукта.

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

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

1️⃣ Ограниченное проблемное пространство - трудно начать работу, если у вас безграничные возможности. Знание границ своего продукта устанавливает для команды определенные ограждения.
2️⃣ Знание своей аудитории - в процессе создания продукта участвует множество заинтересованных сторон, пользователей и клиентов. Четкое понимание границ проблемного пространства позволяет командам найти заинтересованные стороны.

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

Тридцать лет назад господствовали подходы к управлению проектами и методологии разработки программного обеспечения. Использование слова "продукт" отличает Скрам от других подходов. Раньше оно хорошо подходило для первых последователей Scrum, которые в большинстве своем были продуктовыми компаниями. Но за последние тридцать лет, по мере того как внедрение Scrum выросло, это слово внесло дополнительную ясность, и если вы серьезно относитесь к этой идее, она может также сфокусировать внимание, способствуя лучшему согласованию Скрам-команд с клиентами, пользователями и результатами.

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

Использование слова "продукт", как и многих других слов в Скрам, дает возможность пересмотреть то, как вы работаете, и то, в какой среде вы работаете.
🔜 Вместо того чтобы спорить о том, является ли это продуктом, проектом, услугой или каким-то другим видом работы, используйте это как возможность помочь определить рамки работы, лучше согласовать команду с результатами и подумать о ценности.⏩

Дейв Вест, СЕО scrum.org

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

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

☀️ Сколько денег вы теряете на багах?
Ужасающие данные исследования. Инвестируйте время (и деньги) в продуктовое и техническое качество.

☀️ Большая волосатая дерзкая цель, цель, которая вовлечет людей и захватит до глубины души. Есть ли такая у вас?

☀️ Пример реализации риска отложенной интеграции, который “сломал” аэропорты, авиалинии, банки, платежные системы, телекомпании. Учитесь управлять рисками.

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

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

☀️ За кулисами написания Agile Манифеста или о том, как творилась история.

☀️ Скрам-мастер есть, а результата нет? О том, что влияет на работу СМ.

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

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

А где в реальной жизни работает всё то, о чем вы рассказываете?
Самый популярный вопрос на наших тренингах.

И как же приятно приводить примеры знакомых нам компаний.

У Сorporate-rebels нашла большую статью про ВкусВилл. Посмотрим, как устроено управление у них.

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

1️⃣ Отсутствие руководителей среднего звена.
Власть радикально децентрализована. Команды управляют своими магазинами так, как будто это их собственные магазины. Это позволяет им нести ответственность за свой магазин. Магазины сами нанимают и увольняют своих сотрудников. Нанимая своих коллег, ВкусВилл делает так, чтобы магазины сами брали на себя ответственность. Они ищут новых людей, проводят с ними собеседование и верят, что новый сотрудник будет приносить пользу команде. Если окажется, что это не так, они могут винить только себя.

2️⃣ Принцип "дублирования".
Когда компания начала стремительно расти, они внедрили принцип "дублирования". Подобно дублированию клеток в нашем организме, ВкусВилл пытается дублировать все в компании и вокруг нее.
Например, сотрудников. Если для одного сотрудника слишком много работы, он "дублирует" себя, нанимая нового человека в помощь. В результате работу могут разделить два человека, которые остаются равными, что исключает иерархию.
По такому же принципу "дублируются" и отделы. Например, в ВкусВилл есть два юридических отдела, и у сотрудников есть выбор работать в одном из них. Таким образом, между отделами возникает здоровая конкуренция, направленная на создание как можно большей ценности.

3️⃣ Система “обещаний”.
Для того чтобы расти, не опираясь на традиционную иерархию, ВкусВилл принял систему саморегулирования, основанную на "обещаниях".
Система обещаний начинается с так называемых "основных обещаний". Это обещания, которые компания дает покупателю - предлагать свежие и здоровые продукты, доступные и удобные. Затем сотрудники магазинов обязуются выполнять ряд "вспомогательных обещаний", направленных на выполнение основных обещаний. А люди в штаб-квартире обязуются выполнять набор "периферийных обещаний", чтобы поддержать две другие категории обещаний.
В этой системе обещаний все имеют внутренних или внешних клиентов, и все несут ответственность за ценность, которую они предоставляют. Например, сотрудники магазинов должны выполнять свои обещания перед покупателями, предлагая свежие и полезные продукты, а производители должны быть уверены в своевременной доставке заказов.

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

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

Приходите учиться работать с Бэклогом продукта

🟡 Пройдем путь от Цели Продукта до оценок элементов
🟡 Каждый инструмент попробуем на практике
🟡 Сертифицируем от Scrum.org

⚡️ Осталось 1 место
🔜 Успевайте присоединиться!

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

Хотите проверить, есть ли в вашей компании Карго-культ Agile?

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

1️⃣ Скачайте чек-лист и раздайте его своим коллегам.
2️⃣ Попросите их отметить все пункты, которые относятся к вашей организации.
3️⃣ Проанализируйте их отзывы и оцените набранные баллы:
🔵 0-2: Как вам удалось это сделать? Срочно поделитесь своим опытом с другими организациями.
🔵 3-5: Молодцы! Вы на правильном пути.
🔵 6-8: Есть места для улучшений.
🔵 9-14: Если вы еще не начали свой гибкий путь, то, вероятно, пришло время изменить свой подход.
🔵 15-20: Начните сначала - точно ли вы понимаете, что такое Agile? Это не про вашу организацию.
🔵 21-25: Либо вы еще не начали переход в Agile. Либо вы ярые последователи карго-культа. ☹️

⭐️ Цель этого упражнения - начать разговор о том, какая часть ваших подходов работает успешно, а где необходимо что-то изменить. И конечно же, это упражнение имеет смысл, если ваша цель - стать адаптивной организацией.
Не поддерживаем карго-культ - такая цель нужна не всем!

⚡️ Совсем скоро у нас стартует тренинг Professional Scrum Master Advanced (PSM II)
🔜 На нем мы не разбираем базовый Скрам, а фокусируемся на работе Скрам-мастера с организацией, Владельцем продукта и разработчиками.
💬 Присоединяйтесь!

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

Как связаны островитяне Меланезии и современные организации?

Когда шли бои между США и Японией во время второй мировой войны, военные базы США расположились на островах Меланезии. На эти базы доставляли оружие, еду, одежду и другие грузы. Часть этих вещей доставалась коренным жителям этих островов, которые никогда раньше не видели банок тушенки, складных ножей, одежды, да и остальных предметов цивилизованного мира.

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

Когда война закончилась и военные уехали, “дары небес”, доставляемые на самолетах, — внезапно исчезли без видимых причин. Местные решили, что если скопировать поведение американских военных, то боги сжалятся и снова подарят племенам те блага, которые дарили раньше.
Коренные жители стали активно копировать действия американцев. Они мастерили ружья из дерева, наносили на грудь надпись «U.S.A» и даже строили самолеты из соломы. Туземцы делали наушники из кокосов, брали самодельные указки и имитировали приземление самолета на импровизированном аэродроме.

Сargo cult (культ грузов) — это религия «поклонения грузам».

Карго-культ - это чрезмерная увлеченность видимостью действия вместо самого действия; или же «магическое мышление» — убежденность, что все придет само, нужно только подождать.

Думаете карго-культ свойственнен только аборигенам? Если бы…

🔜 Имитация фреймворков. Многие считают, что работают по Scrum только потому, что дали каждому по новой роли, проводят “церемонии/ритуалы” и используют Бэклог.
🔜 Копирование процессов других компаний. Все хотят быть, как Яндекс, Гугл, Убер, Спотифай… Но процесс, который годами нарабатывался и устаканивался и хорошо работает в одной компании, зачастую просто неуместен в другой.
🔜 Следование модным трендам. Применение чего-то новенького просто потому, что это на слуху, без оценки реальной необходимости и пользы для конкретной организации. У кого-то еще нет AI? 🙂

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

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

При чем здесь G.O.A.T. Месси?

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

📍 У вас есть идея. Вы превратили ее в осмысленную цель. Возможно, даже сформулировали ее по S.M.A.R.T. Что еще сделать, чтобы повысить шансы получить результат?

Необходимо проверить, что на достижение цели никто внешний, например, другая команда или подразделение не влияет, то есть вы самостоятельно можете ее достичь. А еще хорошо бы проверить, что ваших сформулированных целей достаточно.
⭐️И тут приходит на помощь принцип МЕСЕ:

🔠utually
🔠xclusive
🔠ollectively
🔠xhaustive
или
🔸Взаимно
🔸Исключающий
🔸Коллективно
🔸Исчерпывающий

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

Collectively Exhaustive значит, что достижения ваших целей в сумме достаточно для получения необходимого вам результата.

✏️ Как использовать принцип МЕСЕ?
✔️ Выпишите цель
✔️ Проверьте, что вы сможете достичь ее самостоятельно, что вам не нужна помощь и нет зависимостей
✔️ Проверьте, что если вы выполните цель, то получите тот самый результат, которого ждете

⭐️Больше о целеполагании на нашем тренинге Certified OKR Practitioner
14-16 августа
Регистрация по ссылке

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

Скрам-мастер есть, а результата нет?

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

✖️ Недооценка роли и найм неопытных специалистов.
Организации часто нанимают неопытных Скрам-мастеров из-за бюджетных ограничений и/или недостаточного понимания этой роли. Во многом работа Скрам-мастера схожа с работой СОО. Хороший СОО пойдет на зарплату в 100 000 рублей? Не думаю.

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

✖️ Скрам-мастер уговаривает, а не принимает решения.
Скрам-мастера могут предлагать изменения, но не принимать окончательные решения. Это усложняет их работу, так как им приходится “продавать” свои идеи, убеждать занятых менеджеров, у которых могут быть другие приоритеты, страхи перед изменениями, другое мнение. Можно ли быстро получить результат, если полномочий нет, а у лиц, которые принимают решения, трансформация не в приоритете? Не думаю.

✖️ Влияние менеджеров.
Скрам-мастера сильно зависят от своих менеджеров, их открытости к изменениям. Хорошие менеджеры могут значительно повысить эффективность Скрам-мастера, поддерживая культуру экспериментов и делегирования. Если менеджер не готов к изменениям или боится потерять контроль, может ли Скрам-мастер эффективно работать? Не думаю.

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

💬 Верьте в своих Скрам-мастеров. Дайте им полномочия. Они могут принести результат!

🔜 А если Скрам-мастеров нет или ваши не справляются, то возьмите нашего в аренду.
Мы умеем работать, как СОО 🙂

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

❔ Что делает скрам-команды эффективными?

Большинство книг, подкастов и блогов предлагают советы на основе личного опыта. Однако, этот опыт не всегда применим ко всем командам. Либераторы (The Liberators) провели исследование среди 2000 скрам-команд, чтобы определить, что действительно влияет на эффективность команд.
Прочитала исследование и делюсь выводами исследования.

5 факторов эффективности скрам-команды.

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

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

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

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

⚠️ Авторы исследования советуют проводить регулярную диагностику команд как минимум по пяти основным факторам: частота релизов, сотрудничество со стейкхолдерами, автономномия, непрерывное улучшение и поддержка менеджмента. Это поможет определить слабые места и сферы для улучшения. Для этого можно использовать Scrum Team Survey.

🔍 Какой фактор хотели бы добавить вы?

#успешные_команды

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

Professional Scrum Master Advanced (PSM II) через неделю!

Вторая ступень сертификациии от scrum.org для крепеньких Скрам-мастеров.

🔥 Осталось одно место, успевайте его отхватить.
🔜 Регистрация тут

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

Технический аудит

Открыватель и автор книги про Экстремальное программирование (XP) Кент Бек предлагает таким образом осуществлять внедрение инженерных практик в организации:

Берите по одной за раз, все время находя наиболее насущную проблему. И как только она будет решена переходите к следующей проблеме.

Рецепт просто замечательный, но как найти эту проблему? И как понять что это действительно самая большая проблема для вас?

⚡️ Чтобы привнести внешний, независимый взгляд на инженерку со стороны, мы сделали наш продукт - “Технический аудит”.

Зовите нашего инжеренерного коуча Сергея Лобина! Он придет и проведет подробное исследование вашего процесса разработки "до последней гайки".

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

✏️ Записаться на бесплатную консультацию можно вот тут .

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

Планируете внедрить OKR в своей компании? Подумайте еще раз.

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

3 признака почему OKR вам не подойдут

✖️ Ваша компания руководствуется метриками производительности
Если для вас сам процесс важнее результата, то, скорее всего, OKR станут пустой тратой времени.
OKR должны помочь измерить влияние вашей работы, а не саму работу.
Например, если ваша цель - повысить уровень удержания клиентов, ваши ключевые результаты должны отвечать на вопросы: "Удалось ли нам повысить уровень удержания клиентов?", а не "Удалось ли нам выпустить все те блестящие функции, которые, по нашему мнению, повысят уровень удержания клиентов?".

✖️ Вы не умеете отслеживать метрики
Если в вашей компании не очень любят следить за изменением метрик, то OKR будут для вас нелегким испытанием. OKR про измерение результатов. Если вы не можете отследить свой прогресс, как вы можете узнать, достигли ли вы своих целей?
Что происходит, когда у вас нет метрик для измерения отдачи от вашей работы? Вы правильно догадались - вы начинаете измерять саму работу (вернемся к пункту 1).
🔜 Вместо того чтобы сразу переходить к OKR, используйте свободное время на то, чтобы дать командам возможность определить свои ключевые показатели и создать соответствующие механизмы для их отслеживания.

✖️ У вас слишком много слоев иерархии
Вы работаете в компании с шестью уровнями иерархии между командами и топ-менеджерами. Когда вы используете OKR, каждый менеджер в цепочке хочет отразить свои приоритеты в OKR, которые будут переданы вниз по каскаду.
К тому времени, когда эти цели и ключевые результаты доходят до команд, они смешиваются и умножаются, превращаясь в беспорядочный список запутанных (и часто противоречащих друг другу) целей.
При таком сценарии командам остается только гадать, какие OKR являются наиболее важными.
🔜 Если вы хотите внедрить OKR в подобной компании, постарайтесь сделать так, чтобы OKR не были простым отражением иерархической структуры.
Вместо того чтобы просто спускать OKR на каждый уровень, вы можете способствовать развитию культуры более совместного согласования и использовать руководство в качестве проводников, помогающих командам понять, как лучше согласовать свою работу со стратегическими целями компании.

⚡️ Вывод
Если все вышеперечисленное показалось вам слишком знакомым, возможно, вам лучше обойтись без OKR.

🙂 А может, и нет.

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

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

Как Владельцу Продукта не порваться, когда у него много команд

Золотое правило Профессионального Скрама: Владелец Продукта и Бэклог Продукта остается всегда один в независимости от количества команд.
Часто возникает вопрос - как один Владелец Продукта в LeSS, Nexus или другом фреймворке на много команд, может посещать все события?
🙂 Кажется, Гермиона решала этот вопрос маховиком времени…
Если у вас его нет, давайте разбираться, как Владельцу Продукта не порваться.

🔜 Вы удивитесь, но в масштабируемом Скраме мы требуем от Владельца Продукта уделять событиям не более 6-8 часов на двухнедельный Спринт. Удивлены?
Простая математика:
🟡 Sprint Planning часть 1 - 1 час
🟡 Overall PBR - 1 час
🟡 Sprint Review - 2 часа
🟡 Overall Retrospective 1.5 часа

Итого 6 часов на двухнедельный Спринт.
Ну даже 8, если вы любите чуть затянуть время событий.

❓ В чем подвох?

🔜 Владелец Продукта не присутствует на второй части Планирования, а также не занимается детальным уточнением элементов Бэклога Продукта на мульти-командных PBR-ах.

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

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

Приходите разбираться, как Scrum работает на много команд к нам на тренинг Certified LeSS Practitioner
✏️ 4-6 сентября
📌 Регистрация на нашем сайте

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

Как измерить успех Скрам-мастера?

Обращаемся к первоисточнику:

Scrum Master несет ответственность за применение Scrum в соответствии с Руководством по
Scrum. Они делают это, помогая всем понять теорию и практики Scrum, как внутри Scrum Team, так
и в организации.
Scrum Master отвечает за эффективность Scrum Team. Он делает это, помогая Scrum Team
улучшать свои методы работы в рамках фреймворка Scrum.
Руководство по Scrum 2020

✔️ Первая часть про понимание теории и применение ее на практике. Кажется просто - надо всех научить. Но тут дело не только в том, чтобы убедиться, что люди "следуют правилам Scrum". Истинный смысл заключается в понимании того, что стоит за элементами Скрама и правилами, которые связывают их.

✔️ Вторая часть про эффективность работы Скрам-команды. Самое интересное.
СМ не "главный". СМ не может указывать команде, как работать (это подорвет ответственность и самоорганизацию). СМ не может контролировать других людей.
Да и вообще есть много факторов, которые “влияют” на работу СМ.

На тренинге Scrum.org Professional Scrum Master мы используем слайд. Он помогает передать всю сложность темы измерения успеха Скрам-мастера.

❓Надежно ли команда обеспечивает качественные и ценные инкременты? В этом и заключается суть Scrum, и именно это обеспечивает преимущества гибкости бизнеса.
❓ Есть ли понимание основ, теории и ценностей Scrum? Следуем ли мы эмпирическому подходу? Отсутствие этого приводит к карго-культу Scrum.
❓ Высокий ли моральный дух у нашей команды? Вовлеченные, мотивированные команды, скорее всего, будут поддерживать рост и продолжать совершенствоваться, эффективнее справляться с проблемами и быть более устойчивыми, когда они сталкиваются с трудностями. Любые внешние успехи, основанные на результатах, могут легко сойти на нет, если люди испытывают низкий моральный дух, особенно в течение длительного периода времени.
❓ Улучшается ли качество продукта, повышаются ли компетенции команды, расширяются знания о бизнесе или области, радуются ли клиенты, улучшается ли сотрудничество, появляется ли больше инноваций, быстрее ли достигается результат?
❓Есть ли у нас самоподдерживающийся Scrum, или все рушится, если Scrum-мастер уходит в отпуск?

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

Ближайшие тренинги для Скрам-мастеров:
✔️ PSM I для начинающих
✔️ PSM II для крепеньких
🔜 Приходите учиться настоящему Скраму.

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

Что такое сплоченная команда?

Сплоченность - или социальная сплоченность - широко изучается социальными психологами.

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

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

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

Что делает одни группы более сплоченными, чем другие?

⭐️ Первый фактор - это то, насколько людям нравится быть частью своей группы или насколько их привлекает эта группа. Думаю, мы все сталкивались с примерами - "звездной команды". Такие команды обладают сильной идентичностью, они успешны и многие хотят быть их частью.

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

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

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

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

Ближайшие тренинги Scrum.ru

⭐️ 14-16 августа Certified OKR Practitioner (C-OKRP®)
Учим выстраивать целеполагание в организации.

⭐️ 22-23 августа Professional Scrum Master
Разбираем базовый Scrum и работу Скрам-мастера.

⭐️ 22-23 августа Professional Scrum Master Advanced
Углубляемся в работу Скрам-мастера, учимся работать с организацией целиком.

⭐️ 28-30 августа Designing Agile Organizations
Разбираем, как трансформировать компанию в гибкую организацию.

Обучение на осень уже можно забронировать на нашем сайте.

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

⚡️ Даем скидку при покупке двух тренингов.

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

Опыт ВкусВилл. Продолжение.

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

Интересно, что у них никогда не было ИТ-отдела. Все IT-разработки выполняются сторонней компанией, с которой у них тесные и дружеские связи. Действительно, каждый сотрудник ВкусВилл может отправить запрос сторонним программистам, которые постараются воплотить его надежды и мечты в жизнь.

5️⃣ Деловой ритм.
Работа в ВкусВилл и ее постоянное совершенствование осуществляется в соответствии с четким деловым ритмом, ориентированным на то, чтобы слушать, учиться и действовать в соответствии с отзывами клиентов. Этот ритм поддерживается двумя еженедельными встречами: по понедельникам и вторникам.

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

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

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

6️⃣Ценность ошибок
Одна из главных сильных сторон ВкусВилл - бросать вызов статус-кво с помощью культуры инноваций. Этому способствует то, что ошибки не наказываются, а ценятся. В компании создана культура, в которой люди признают ошибки, а затем анализируют, что именно пошло не так. Они стараются рассматривать ошибки как опыт обучения. Это мотивирует людей пробовать новое и экспериментировать, чтобы повысить ценность для клиентов.

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

Вместо этого они пытаются разобраться в причинах ошибок.

"Мы пытаемся понять причину. Были ли это намеренные действия? Или в системе есть ошибка, которая позволила им принять неверное решение? Если виновата система, мы ее меняем. Если налицо явный умысел сотрудника, мы его увольняем".

Прочитать полную версию статьи можно по ссылке.

ВкусВилл, вы огонь.❤️

P.S. А кто-то из наших подписчиков работает во ВкусВилл? Поделитесь в комментариях, у вас всё по-прежнему так?

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

"Я написал нужный код и он работает у меня - давайте выпускать! Что может пойти не так?"

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

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

Циклы обратной связи в экстремальном программировании (XP):
1️⃣ Совместная работа: Работа в паре, мобе способствует немедленной обратной связи от коллег, улучшая качество кода и обмен знаниями.
2️⃣ Автоматическая сборка (Auto Build): Автоматизация процесса сборки снижает риск и позволяет быстро обнаруживать ошибки, если приложение не собирается, то мы быстро это увидим и сможем исправить ошибку.
3️⃣ Тестирование и тесты:
🔘 Модульное тестирование (unit testing): Написание тестов для каждого отдельного модуля позволяет убедиться, что логика работы модуля работает как мы задумывали.
🔘 Приемочное тестирование (acceptance testing): Проверка того, что программное обеспечение соответствует требованиям к продукту и удовлетворяет ожидания пользователя.
4️⃣ Непрерывная интеграция: Частая интеграция кода в общую ветку (несколько раз в день) позволяет быстро обнаруживать и исправлять ошибки, которые могут возникнуть при слиянии результатов работы нескольких человек.
5️⃣ Непрерывная поставка: Автоматизация процесса поставки программного обеспечения и встроенные в этот процесс проверки, обеспечивает возможность обнаруживать и исправлять проблемы поставки продукта в боевую среду.

⚡️ На нашем тренинге "Applying Software Development for Software Development" студенты уже в первом спринте сталкиваются с вопросом поставки качественного ПО. Они изучают практики экстремального программирования и DevOps, чтобы поставлять качественный продукт каждый спринт или даже чаще.
📎 Ближайший тренинг состоится в сентябре.
🔜 Успейте забронировать себе место!

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

Как структурировать гибкую организацию

Большинство организаций структурируют себя с помощью функциональных направлений: СЕО, под ним VP департаментов, под ними департаменты (маркетинг, продажи, закупки, риски, IT и т.д.).
И это ок!
Вот только если у вас нет цели стать быстрой, адаптивной организацией.

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

Со всем этим тяжело рассчитывать на чудеса скорости и гибкости на уровне компании.

⚡️ Организации, которые стремятся к адаптивности и скорости, создают продуктовые группы — кросс-функциональные подразделения с PnL (profits & loss) ответственностью, которые возглавляют Владельцы Продуктов.

🟡Продуктовые группы создаются вокруг продуктов с общими характеристиками и внутренними частями: семейств продуктов или продуктовых линий.
🟡В продуктовую группу входят все ресурсы, необходимые для реализации бизнес-стратегии.

Например, если ваша организация занимается созданием мебели, в продуктовую группу должны войти все функции, необходимые для создания, продажи и поставки “дивана” клиенту:
🔘 Оффлайн продажи (розница)
🔘 Онлайн продажи (e-commerce)
🔘 Дизайн
🔘 Маркетинг
🔘 Конструкторы мебели
🔘 Обучение
🔘 Служба качества
🔘 Логистика

🟡Часть функций, которые прямо не влияют на создание продукта, может быть общей - например, HR, Финансы и т.п.

▶️Без изменения структуры, значительной прибавки к скорости вы не получите.
Чудес не бывает.

Хотите узнать больше о том, как создавать адаптивные организации и проектировать продуктовые группы?
🔜 Приходите к нам на тренинг Designing Agile Organizations (DAO).
📌 Ближайшая группа 28-30 августа.
⭐️ Регистрация на нашем сайте.

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

8 шагов гембы

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

Митикадзу Танака, ученик Тайити Оно

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

⭐️ Мы можем найти сильные стороны и области улучшения вашей организации
🔜 Запишитесь на консультацию

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

⚡️ Срочно в номер! ⚡️
По всему миру глобальные сбои. Не работают аэропорты, авиалинии, банки, платежные системы, телекомпании.

Нет, это не сюжет книги, это реальность сегодняшнего дня!
Решение для обеспечения безопасности поссорилось с сервисами Microsoft, что привело к такому результату.

"…Корейское издание Money Today цитирует попросившего не называть его имени эксперта в сфере информационной безопасности, который назвал в качестве возможной причины сбоя проблемы с программным продуктом Falcon Platform американской компании CloudStrike.

По его мнению, в ходе обновления этой программы, использующей облачные технологии и применяющейся для блокировки кибератак, мог возникнуть конфликт с операционной системой, который и привел к сбою. И поскольку данное ПО устанавливается преимущественно крупными компаниями и организациями, то проблемы с работой информационных систем затронули именно их." - TG Канал @bbbreaking

🔜 Мы с вами наблюдаем типовую реализацию риска отложенной интеграции, увы далеко не первый и не последний раз. Вспомнить, хотя бы, катастрофу Boeing 737-MAX.

🔥 Не забывайте, что в продуктовой разработке существует как продуктовый, так и технологический риск.

Хотите научиться управлять рисками и ограничивать их стоимость?
🔜 Приходите к нам на Professional
Scrum Product Owner.

🙂 Существенно дешевле, чем потерять 15,61% стоимости акций, как Crowdstrike или 1,99%, как Microsoft.

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

Воркшоп по декомпозиции через неделю!

Тренируем навык разбиения больших задач так, чтобы их можно было завершить за спринт или ещё раньше

🗓 24 июля
➡️ Регистрация по ссылке
💙 Скидка 10% от нашего инженерного тренера по промокоду LOBIN

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

В чем разница между продуктом и проектом?

Проект обычно определяется как совместное предприятие, часто включающее исследование или проектирование, которое разрабатывается для достижения определенной цели.

"Продукт" определяется как "нечто, произведенное в результате работы или усилий" или как "результат действия или процесса" и ведет свое происхождение от латинского глагола produce(re), "заставлять существовать".

🔜 То есть, если проект - это процесс с началом и концом, то продукт - это результат процесса.

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

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

Бесконечная игра
В книге "Бесконечная игра" есть интересная мысль:
"Если конечная игра имеет конец и явного победителя, как спорт, политика и война, то бесконечные игры, как наша жизнь, страны, карьера, - не имеют четкого и определенного конца и победителя.
В конечную игру играют ради победы, в бесконечную - ради продолжения игры.
Многие проблемы, с которыми сталкиваются организации, существуют просто потому, что их лидеры играют с конечным мышлением в игру, которая не имеет конца. Лидеры, которые принимают бесконечное мышление, напротив, строят более сильные, более инновационные, более вдохновляющие организации".
Проекты - это конечные игры, а продукты - бесконечные игры.

Это адаптированный перевод статьи Джока Торреса.

Наши тренинги по работе с продуктом:
⭐️ Professional Scrum Product Backlog Management Skills
⭐️ Professional Scrum Product Owner
⭐️ Professional Scrum Product Owner Advanced

⚡️ Даем скидку при покупке двух и более тренингов

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

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

Big Hairy Audacious Goal (BHAG) (произносим bee-hag) - это концепция, введенная Джимом
Коллинзом и Джерри Поррасом в книге «Построенные навечно: Успех компаний, обладающих видением»

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

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

Примеры BHAG
🔵Microsoft в 1980-х годах ставил цель "компьютер на каждом столе и в каждом доме".
🔵 Цель SpaceX "колонизировать Марс" до сих пор движет Маском и его командой.
🔵 У Meta несколько BHAG: «сделать мир более открытым и связанным» и «дать каждому возможность поделиться чем угодно с кем угодно»
🔵 Google по-прежнему хочет "организовать мировую информацию и сделать ее универсально доступной и полезной

Почему BHAG важны?
1️⃣ Мотивация
2️⃣ Фокус
3️⃣ Инновации

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

⭐️Если такой "большой, волосатой, дерзкой" цели нет, то может быть самое время ее создать?

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