Концепция Временного Владельца продукта (Temporary Product Owner)
Одна из самых больших сложностей при создании новой Agile команды - это поиск правильного кандидата на роль Владельца продукта.
Особенно эта проблема актуальна для крупных компаний, где ответственность за продукт распределена между несколькими стейкхолдерами и поэтому невозможно найти одного человека, который бы:
а) полностью разбирался в продукте и всех процессах вокруг него;
б) обладал необходимыми компетенциями, в первую очередь в понимании рынка, потребности клиентов и видения создаваемого продукта.
Но команду запускать нужно, и на вакантную роль волевым решением руководителей назначается, как правило, либо текущий менеджер проекта, либо эксперт, максимально широко знающий предметную область.
Заинтересованные лица начинают ждать значимых продуктовых и бизнес-результатов. Эти результаты не всегда расходятся с ожиданиями, но, очевидно, риски велики.
В LeSS есть отличное решение - концепция Временного Владельца продукта.
Как раз для таких случаев, когда в моменте создания команды еще нет идеально подходящего человека на роль Владельца продукта.
Важно:
- У команды есть человек, хорошо знающий предметную область (и знающий людей внутри компании, которые могут помочь найти ответы на вопросы)
- Главная задача Временного Владельца продукта и команды - перейти на новый процесс работы (например, Scrum) и наладить стабильную и предсказуемую поставку результата за первые несколько спринтов.
- За это время компания сможет найти/нанять/обучить уже постоянного Владельца продукта, обладающего всеми необходимыми для этой роли компетенциями. И дать ему быстро работающую, слаженную команду для создания крутого продукта.
И главное - правильно сформированные ожидания у все участников процесса.
Одна из самых больших сложностей при создании новой Agile команды - это поиск правильного кандидата на роль Владельца продукта.
Особенно эта проблема актуальна для крупных компаний, где ответственность за продукт распределена между несколькими стейкхолдерами и поэтому невозможно найти одного человека, который бы:
а) полностью разбирался в продукте и всех процессах вокруг него;
б) обладал необходимыми компетенциями, в первую очередь в понимании рынка, потребности клиентов и видения создаваемого продукта.
Но команду запускать нужно, и на вакантную роль волевым решением руководителей назначается, как правило, либо текущий менеджер проекта, либо эксперт, максимально широко знающий предметную область.
Заинтересованные лица начинают ждать значимых продуктовых и бизнес-результатов. Эти результаты не всегда расходятся с ожиданиями, но, очевидно, риски велики.
В LeSS есть отличное решение - концепция Временного Владельца продукта.
Как раз для таких случаев, когда в моменте создания команды еще нет идеально подходящего человека на роль Владельца продукта.
Важно:
- У команды есть человек, хорошо знающий предметную область (и знающий людей внутри компании, которые могут помочь найти ответы на вопросы)
- Главная задача Временного Владельца продукта и команды - перейти на новый процесс работы (например, Scrum) и наладить стабильную и предсказуемую поставку результата за первые несколько спринтов.
- За это время компания сможет найти/нанять/обучить уже постоянного Владельца продукта, обладающего всеми необходимыми для этой роли компетенциями. И дать ему быстро работающую, слаженную команду для создания крутого продукта.
И главное - правильно сформированные ожидания у все участников процесса.
Почему в банках так мало хороших разработчиков
Мы очень много работаем с банками и телекомом, постоянно видим острую нехватку хороших разработчиков в компаниях этих секторов.
Понятно, что большинство уже работает в технологических компаниях, поэтому в классический банк их никогда не переманить.
По какой-то причине в банках, которых начинают развивать диджитал направление, часто считают, что дело в хорошем офисном пространстве тех же Яндекса или Мейла - пуфики, бесплатные снеки и соки, спортзал, барбершоп и тп. Наверное, какая-то часть правды в этом тоже есть.
Но основное ведь в другом, в свободе принятия решений и интересных, развивающих тебя как профессионала задачах.
Процитирую Оливера Хьюза, Председателя правления «Тинькофф банка»:
«Вот почему нужно идти в технологии: если вы будете дальше говорить банковскими терминами — проценты дохода, комиссионные доходы… 99% моих коллег в «Тинькофф» не понимают такие слова.
Вы не привлечёте технологических людей: аналитиков, технологов и так далее, они просто не пойдут к вам работать. Они пойдут в технологические компании, потому что там интересно.
И это проблема, с которой мы боремся. Наши люди не думают про «Тинькофф» как про финансовую организацию, тем более банк — это хорошо.
Если мы их не привлечём, у нас не будет лучших интерфейсов в России, мы не сможем конкурировать с «Яндексом», Mailru, «Сбербанком», которые уже экосистемы, а также, разумеется, с зарубежным Big Tech, когда он наконец придёт. А он придёт.»
Мы очень много работаем с банками и телекомом, постоянно видим острую нехватку хороших разработчиков в компаниях этих секторов.
Понятно, что большинство уже работает в технологических компаниях, поэтому в классический банк их никогда не переманить.
По какой-то причине в банках, которых начинают развивать диджитал направление, часто считают, что дело в хорошем офисном пространстве тех же Яндекса или Мейла - пуфики, бесплатные снеки и соки, спортзал, барбершоп и тп. Наверное, какая-то часть правды в этом тоже есть.
Но основное ведь в другом, в свободе принятия решений и интересных, развивающих тебя как профессионала задачах.
Процитирую Оливера Хьюза, Председателя правления «Тинькофф банка»:
«Вот почему нужно идти в технологии: если вы будете дальше говорить банковскими терминами — проценты дохода, комиссионные доходы… 99% моих коллег в «Тинькофф» не понимают такие слова.
Вы не привлечёте технологических людей: аналитиков, технологов и так далее, они просто не пойдут к вам работать. Они пойдут в технологические компании, потому что там интересно.
И это проблема, с которой мы боремся. Наши люди не думают про «Тинькофф» как про финансовую организацию, тем более банк — это хорошо.
Если мы их не привлечём, у нас не будет лучших интерфейсов в России, мы не сможем конкурировать с «Яндексом», Mailru, «Сбербанком», которые уже экосистемы, а также, разумеется, с зарубежным Big Tech, когда он наконец придёт. А он придёт.»
Прекрасный пример применения Agile в организации учебного процесса студентов.
https://onagile.ru/trends/business-agility/laboratoria
https://onagile.ru/trends/business-agility/laboratoria
OnAgile Consulting
Спринты вместо семестров и вовлеченные команды вместо скучающих слушателей лекций.
Применение Agile и Scrum в образовании 💎 — OnAgile Consulting
Приятно видеть, как в мире развивается экосистема для предпринимателей.
Пять лет назад, для примера, в России любое действие с регистрацией/бухгалтерией/банковским обслуживанием было квестом. С кучей потерянного времени, заполненных бумажек, походов в банк, комиссий и дополнительных сотрудников на выполнение рутинных, ненужных бизнесу операций.
Помню, одними из первых, кто увидел свободную нишу, были МодульБанк с Точкой, а в итоге стали подтягиваться даже Альфа со Сбербанком, выстраивая свои сервисы вокруг потребностей предпринимателей.
Сейчас это норма, но в 2014 году открыть счет для ИП через приложение без поездки в банк (!) и сразу получить на него деньги от клиента - это было очень круто!
Именно Agile подход помогает крупным компаниям фокусироваться на потребностях клиентов больше, чем на внутренних процедурах.
Пять лет назад, для примера, в России любое действие с регистрацией/бухгалтерией/банковским обслуживанием было квестом. С кучей потерянного времени, заполненных бумажек, походов в банк, комиссий и дополнительных сотрудников на выполнение рутинных, ненужных бизнесу операций.
Помню, одними из первых, кто увидел свободную нишу, были МодульБанк с Точкой, а в итоге стали подтягиваться даже Альфа со Сбербанком, выстраивая свои сервисы вокруг потребностей предпринимателей.
Сейчас это норма, но в 2014 году открыть счет для ИП через приложение без поездки в банк (!) и сразу получить на него деньги от клиента - это было очень круто!
Именно Agile подход помогает крупным компаниям фокусироваться на потребностях клиентов больше, чем на внутренних процедурах.
Перевыполнить план на 45% с помощью применения agile подхода всего за 3 месяца? Почему бы и нет 🙂
Отличный получился кейс с компанией из большой тройки, когда в результате запуска agile команд напрямую улучшились бизнес-показатели.
Прочитайте кейс и спрашивайте подробности, с удовольствием поделимся деталями.
https://onagile.ru/industries/telecommunication/agile-in-telecom
Отличный получился кейс с компанией из большой тройки, когда в результате запуска agile команд напрямую улучшились бизнес-показатели.
Прочитайте кейс и спрашивайте подробности, с удовольствием поделимся деталями.
https://onagile.ru/industries/telecommunication/agile-in-telecom
Принятие решений в Agile-команде — коллективное или экспертное?
Экспедиция в горы как хорошая аналогия к работе Agile-команд, где есть бизнес-цель (вершина) и различные риски, в том числе технологические (необходимость вернуться обратно живыми).
В обоих случаях для этих двух типов задач команда — и ее лидер — должны выбирать разные подходы к решению, и это не всегда про демократию и консенсус.
https://onagile.ru/trends/leadership/teamwork-and-climbing-expeditions-experience
Экспедиция в горы как хорошая аналогия к работе Agile-команд, где есть бизнес-цель (вершина) и различные риски, в том числе технологические (необходимость вернуться обратно живыми).
В обоих случаях для этих двух типов задач команда — и ее лидер — должны выбирать разные подходы к решению, и это не всегда про демократию и консенсус.
https://onagile.ru/trends/leadership/teamwork-and-climbing-expeditions-experience
OnAgile Consulting
Принятие решений: в каких условиях наиболее эффективно коллективное обсуждение, а в каких полезнее иерархическое управление?
Командная работа: чему нас может научить опыт высокогорных экспедиций 💎 — OnAgile Consulting
О приоритизации бэклога.
Один из самых популярных вопросов у менеджеров продукта/Product owner-ов про приоритизацию бэклога. Какой из инструментов самый лучший? Прежде чем ответить на этот вопрос, хочется обратиться к математике.
Есть такой класс математических задач, которые называются NP-полными. Практически это означает, что не существует алгоритма, который может решить эту задачу за полиномиальное, т.е. какое-то реальное и адекватное время.
Одна из таких задач — об укладке ранца. Суть ее такова: есть ранец, и известен некий максимальный вес, который вы можете поднять и унести в нем. И есть набор коробок, отличающихся весом и ценностью. Задача заключается в том, чтобы найти способ наиболее эффективно разместить коробки в рюкзаке так, чтобы можно было унести максимальную ценность.
И кажется, этот пример очень близок задаче приоритизации бэклога 😉
Конечно, можно возразить, что приоритизация более простая вещь, потому что есть такие параметры, как дедлайны или зависимости, существенно упрощающие процесс. Но проблема в том, что если по условиям задачи про ранец вы точно знаете ценность коробки и ее вес, то в случае приоритизации все предположения о «value» или сложности элемента бэклога достаточно приблизительны.
Таким образом, можно сделать околонаучное допущение, что задача о приоритизации также не решается. А значит, все запросы на нахождение инструмента, который единственно правильным и магическим образом упорядочит backlog являются немного наивными.
Остается забыть о поисках серебряной пули и, как обычно в любой непонятной ситуации, просто-напросто думать.
Ну или использовать "жадные" алгоритмы, но про них в следующем посте.
Один из самых популярных вопросов у менеджеров продукта/Product owner-ов про приоритизацию бэклога. Какой из инструментов самый лучший? Прежде чем ответить на этот вопрос, хочется обратиться к математике.
Есть такой класс математических задач, которые называются NP-полными. Практически это означает, что не существует алгоритма, который может решить эту задачу за полиномиальное, т.е. какое-то реальное и адекватное время.
Одна из таких задач — об укладке ранца. Суть ее такова: есть ранец, и известен некий максимальный вес, который вы можете поднять и унести в нем. И есть набор коробок, отличающихся весом и ценностью. Задача заключается в том, чтобы найти способ наиболее эффективно разместить коробки в рюкзаке так, чтобы можно было унести максимальную ценность.
И кажется, этот пример очень близок задаче приоритизации бэклога 😉
Конечно, можно возразить, что приоритизация более простая вещь, потому что есть такие параметры, как дедлайны или зависимости, существенно упрощающие процесс. Но проблема в том, что если по условиям задачи про ранец вы точно знаете ценность коробки и ее вес, то в случае приоритизации все предположения о «value» или сложности элемента бэклога достаточно приблизительны.
Таким образом, можно сделать околонаучное допущение, что задача о приоритизации также не решается. А значит, все запросы на нахождение инструмента, который единственно правильным и магическим образом упорядочит backlog являются немного наивными.
Остается забыть о поисках серебряной пули и, как обычно в любой непонятной ситуации, просто-напросто думать.
Ну или использовать "жадные" алгоритмы, но про них в следующем посте.
В прошлый раз мы остановились на «жадных алгоритмах» ⬆⬆⬆.
https://telegra.ph/Behklog-i-matematika-07-03
https://telegra.ph/Behklog-i-matematika-07-03
Telegraph
Бэклог и математика
Внести в процесс приоритизации конкретику и объяснить иерархию задач в понятных числах может помочь система оценки WSJF — Weighted Shortest Job First. Как видно из названия, чем выше коэффициент WSJF, тем приоритетнее задача. Где: Ценность для клиента/бизнеса…
Небольшой анонс программ обучения на сентябрь, созданных в партнерстве с International Consortium for Agile.
Мы разработали полный курс обучения, состоящий из трех уровней погружения в Agile и Scrum.
От понимания, как работает Agile и что нужно сделать для внедрения Scrum в команде, до детального изучения подходов к созданию востребованных продуктов.
👨🎓 Международный сертификат от консорциума ICAgile каждому участнику.
Посмотреть программу и зарегистрироваться можно здесь ➡️ www.onagile.ru/trainings
Мы разработали полный курс обучения, состоящий из трех уровней погружения в Agile и Scrum.
От понимания, как работает Agile и что нужно сделать для внедрения Scrum в команде, до детального изучения подходов к созданию востребованных продуктов.
👨🎓 Международный сертификат от консорциума ICAgile каждому участнику.
Посмотреть программу и зарегистрироваться можно здесь ➡️ www.onagile.ru/trainings
Несколько советов, как работать с молодыми сотрудниками и помочь раскрыть их потенциал.
Даже мы, в небольшой, казалось бы, компании, уже смогли почувствовать разницу поколений 🙂
https://vc.ru/hr/75600-pokolenie-z-v-agile-komandah-kak-s-nimi-rabotat
Даже мы, в небольшой, казалось бы, компании, уже смогли почувствовать разницу поколений 🙂
https://vc.ru/hr/75600-pokolenie-z-v-agile-komandah-kak-s-nimi-rabotat
vc.ru
Поколение Z в Agile-командах — как с ними работать? — Карьера на vc.ru
Первое полностью цифровое поколение уже заканчивает университеты и становится частью рабочих команд. Как выстраивать с ними эффективное взаимодействие?
В чем отличие Agile от Lean?
Люди, знакомые с Lean или работающие в компаниях, где он применяется, часто спрашивают нас, а в чем отличие Agile от Lean? Вроде бы очень похожие подходы по ценностям и некоторым инструментам.
Тем не менее разница значительная.
1. Lean стремится устранить неэффективные способы работы, а Agile ищет более эффективные пути разработки продуктов с помощью инкрементального подхода.
2. Lean концентрируется на повышении продуктивности процесса и сокращении затрат, Agile нацелен на повышение ценности создаваемого продукта для клиента.
Если вы уже сталкивались с подобным обсуждением, поделитесь с коллегами 👉
Люди, знакомые с Lean или работающие в компаниях, где он применяется, часто спрашивают нас, а в чем отличие Agile от Lean? Вроде бы очень похожие подходы по ценностям и некоторым инструментам.
Тем не менее разница значительная.
1. Lean стремится устранить неэффективные способы работы, а Agile ищет более эффективные пути разработки продуктов с помощью инкрементального подхода.
2. Lean концентрируется на повышении продуктивности процесса и сокращении затрат, Agile нацелен на повышение ценности создаваемого продукта для клиента.
Если вы уже сталкивались с подобным обсуждением, поделитесь с коллегами 👉
Вакансия.
Мы ищем человека, который займется развитием открытых тренингов в OnAgile Academy.
Это и про улучшение клиентского опыта, и про развитие направления в целом.
Хочется проводить больше тренингов, обучать больше участников и все идеально организовывать 🙂
Важное условие - предпринимательский майндсет. Мы бы не хотели вам говорить, что и как нужно делать, но, конечно же, поможем видением, опытом и советом.
Понимание организации процесса обучения и наличие соответствующего опыта - обязательно.
Москва, м. Автозаводская, наш светлый и уютный офис с прекрасной кофемашиной.
Присылайте резюме и пару строк, почему вам эта вакансия интересна, будем рады познакомиться!
info@onagile.ru
Мы ищем человека, который займется развитием открытых тренингов в OnAgile Academy.
Это и про улучшение клиентского опыта, и про развитие направления в целом.
Хочется проводить больше тренингов, обучать больше участников и все идеально организовывать 🙂
Важное условие - предпринимательский майндсет. Мы бы не хотели вам говорить, что и как нужно делать, но, конечно же, поможем видением, опытом и советом.
Понимание организации процесса обучения и наличие соответствующего опыта - обязательно.
Москва, м. Автозаводская, наш светлый и уютный офис с прекрасной кофемашиной.
Присылайте резюме и пару строк, почему вам эта вакансия интересна, будем рады познакомиться!
info@onagile.ru
#разборкейса
Срочные задачи — бросать все и делать?
Ситуация, с которой сталкиваются почти все команды, особенно на этапе становления процесса по Канбан-методу: завели доску и все визуализировали, определили условия передвижения задач из столбца в столбец, определили WIP-лимиты. Согласовали с заказчиком приоритеты, чтобы понимать, в какой последовательности брать задачи. Все отлично, работаем.
И тут, уже после сессии расстановки приоритетов (replenishment meeting), от заказчика приходит новая срочная задача. А потом еще одна. Что обычно делает команда? Откладывает все и берется за новые задачи. И скорее всего, совершает ошибку.
Уже скоро выяснится, что запланированные задачи повисли незавершенными, и если новые команда тоже не успела доделать — сложится впечатление, что не сделано вообще ничего, хотя усилия затрачены. Команда расстроена, заказчик недоволен, и аргумент «Мы же переключились на новые срочные задачи», скорее всего, не сработает. Более того, все начинание по внедрению Agile может показаться неэффективным, хотя Канбан-метод просто сделал существующие проблемы видимыми.
Что делать? Вспомнить про принцип эволюционного развития и «вытягивания» новых задач по мере мере продвижения текущих. Прежде чем браться за любое внеплановое задание, стоит обсудить с заказчиком текущую ситуацию: что уже находится в работе, на какой стадии, действительно ли новая задача требует отставить все остальное в сторону или она сможет подождать до завтра/ послезавтра, когда будет завершена текущая?
В этот момент полезно еще раз проговорить правила взаимодействия заказчика с командой и порядок вытягивания задач из очереди — чтобы все понимали, почему делается так или иначе.
Срочные задачи — бросать все и делать?
Ситуация, с которой сталкиваются почти все команды, особенно на этапе становления процесса по Канбан-методу: завели доску и все визуализировали, определили условия передвижения задач из столбца в столбец, определили WIP-лимиты. Согласовали с заказчиком приоритеты, чтобы понимать, в какой последовательности брать задачи. Все отлично, работаем.
И тут, уже после сессии расстановки приоритетов (replenishment meeting), от заказчика приходит новая срочная задача. А потом еще одна. Что обычно делает команда? Откладывает все и берется за новые задачи. И скорее всего, совершает ошибку.
Уже скоро выяснится, что запланированные задачи повисли незавершенными, и если новые команда тоже не успела доделать — сложится впечатление, что не сделано вообще ничего, хотя усилия затрачены. Команда расстроена, заказчик недоволен, и аргумент «Мы же переключились на новые срочные задачи», скорее всего, не сработает. Более того, все начинание по внедрению Agile может показаться неэффективным, хотя Канбан-метод просто сделал существующие проблемы видимыми.
Что делать? Вспомнить про принцип эволюционного развития и «вытягивания» новых задач по мере мере продвижения текущих. Прежде чем браться за любое внеплановое задание, стоит обсудить с заказчиком текущую ситуацию: что уже находится в работе, на какой стадии, действительно ли новая задача требует отставить все остальное в сторону или она сможет подождать до завтра/ послезавтра, когда будет завершена текущая?
В этот момент полезно еще раз проговорить правила взаимодействия заказчика с командой и порядок вытягивания задач из очереди — чтобы все понимали, почему делается так или иначе.
В крупных компаниях нередки встречи и совещания, на которых одновременно присутствуют 20 человек, при этом в течение часа или двух обсуждаются вопросы, для принятия решений в которых достаточно всего четырех человек.
Ну, вы знаете, наверняка в таких участвовали 🙂
Подслушали недавно у клиента забавный термин, описывающий такие мероприятия, — togethering (тугезэринг, буквально: делание чего-то вместе)
А как у вас называются встречи, на которых переговорка битком, но при этом половина людей сидит в ноутбуках и телефонах?
Ну, вы знаете, наверняка в таких участвовали 🙂
Подслушали недавно у клиента забавный термин, описывающий такие мероприятия, — togethering (тугезэринг, буквально: делание чего-то вместе)
А как у вас называются встречи, на которых переговорка битком, но при этом половина людей сидит в ноутбуках и телефонах?
Возможно ли организовать эффективную работу распределенной команды, и на что при этом обратить внимание? Несколько полезных практик из нашего опыта➡
https://vc.ru/hr/77384-ofis-vs-udalennaya-rabota-v-agile-komande
https://vc.ru/hr/77384-ofis-vs-udalennaya-rabota-v-agile-komande
vc.ru
Офис vs удаленная работа в Agile-команде — Карьера на vc.ru
Плюсы и минусы удаленной работы. И 5 практик, которые помогут запустить распределенные Agile-команды, от консультантов OnAgile Consulting.
Обратная связь внутри команды
Для всесторонней оценки работы команды мнения только руководителя или Scrum-мастера может быть недостаточно. Много ценной информации также способна дать обратная связь от коллег по команде — они, в отличие от руководителя, наблюдают за работой друг друга каждый день. К тому же такие комментарии сопровождаются меньшим стрессом, чем когда работу оценивает человек, принимающий решение о размере премии.
Регулярная практика обратной связи с коллегами (peer feedback) помогает процессу постоянного улучшения. Вот несколько простых правил, которые помогут наладить фидбэк без лишнего стресса:
🔹 Базовые принципы обратной связи — обсуждение один на один, и только когда коллега готов ее услышать.
🔹Анонимная обратная связь — «часть нашей команды считает, что...» — работает хуже. Гораздо полезнее для всего рабочего процесса создать среду, в которой возможны открытые и честные отзывы.
🔹Контекст: обратная связь всегда относится к ситуации, а не к человеку. Описывая ситуацию со своей точки зрения, мы улучшаем взаимопонимание.
🔹Наблюдения вместо простого перечисления фактов. «Я заметил, что...»
🔹Чувства важны: описывая, как ситуация влияет на нас, мы даем понять, чем мотивирован фидбэк, и фокусируем разговор на важности изменений.
🔹Предложения: как можно улучшить ситуацию? как избежать повторения подобных сценариев? Даже если коллега не воспользуется ими буквально, это хорошая возможность еще раз сверить ориентиры.
🔹Диалог: обратная связь не должна превращаться в монолог, который неизбежно поставит одного члена команды выше другого. Важно узнать, как сам коллега видит ситуацию, с чем согласен, а с чем — нет.
🔹Для формулирования обратной связи можно воспользоваться акронимом OSCAR (observed, situation, consequence, alternative, resulting): «Я наблюдал.., особенно в этой ситуации…, возможные последствия… Я предлагаю следующую альтернативу… В результате...»
А в вашей команде принято делиться мнениями о работе друг друга? С какими сложностями при этом сталкивались?
Для всесторонней оценки работы команды мнения только руководителя или Scrum-мастера может быть недостаточно. Много ценной информации также способна дать обратная связь от коллег по команде — они, в отличие от руководителя, наблюдают за работой друг друга каждый день. К тому же такие комментарии сопровождаются меньшим стрессом, чем когда работу оценивает человек, принимающий решение о размере премии.
Регулярная практика обратной связи с коллегами (peer feedback) помогает процессу постоянного улучшения. Вот несколько простых правил, которые помогут наладить фидбэк без лишнего стресса:
🔹 Базовые принципы обратной связи — обсуждение один на один, и только когда коллега готов ее услышать.
🔹Анонимная обратная связь — «часть нашей команды считает, что...» — работает хуже. Гораздо полезнее для всего рабочего процесса создать среду, в которой возможны открытые и честные отзывы.
🔹Контекст: обратная связь всегда относится к ситуации, а не к человеку. Описывая ситуацию со своей точки зрения, мы улучшаем взаимопонимание.
🔹Наблюдения вместо простого перечисления фактов. «Я заметил, что...»
🔹Чувства важны: описывая, как ситуация влияет на нас, мы даем понять, чем мотивирован фидбэк, и фокусируем разговор на важности изменений.
🔹Предложения: как можно улучшить ситуацию? как избежать повторения подобных сценариев? Даже если коллега не воспользуется ими буквально, это хорошая возможность еще раз сверить ориентиры.
🔹Диалог: обратная связь не должна превращаться в монолог, который неизбежно поставит одного члена команды выше другого. Важно узнать, как сам коллега видит ситуацию, с чем согласен, а с чем — нет.
🔹Для формулирования обратной связи можно воспользоваться акронимом OSCAR (observed, situation, consequence, alternative, resulting): «Я наблюдал.., особенно в этой ситуации…, возможные последствия… Я предлагаю следующую альтернативу… В результате...»
А в вашей команде принято делиться мнениями о работе друг друга? С какими сложностями при этом сталкивались?
Product owner и скрам-мастер: почему важно разделять эти роли
Когда компания начинает внедрять Scrum, две новые роли — владелец продукта и скрам-мастер — часто решают назначить одному человеку. Обычно это менеджер проекта или тимлид. Но это так не работает.
Скрам-мастер — это не только тот, благодаря кому встречи команды наконец-то начинают укладываться в отведенное для них время. Его задача — помогать команде придерживаться правил фреймворка и, главное, самоорганизовываться: понимать, как прийти к заданной цели, вовремя обнаруживать проблемы и находить их решения.
Product owner в это время должен развивать продукт, чтобы тот удовлетворял потребности потребителей и приносил прибыль компании. Он отвечает за видение продукта, за понимание потребностей клиентов, обеспечивает коммуникации между стейкхолдерами и командой и формирует бэклог, над которым будет работать команда.
По сути, product owner говорит команде, что нужно делать, но не навязывает свое видение, как этого добиться. А скрам-мастер помогает команде научиться работать максимально эффективно, постоянно улучшая процесс своей работы. И если обе этих роли соединить в одном человеке, мы вернемся к модели работы классического менеджера, и наши Agile и Scrum превратятся в просто наклеивание стикеров и постоянные встречи.
Когда компания начинает внедрять Scrum, две новые роли — владелец продукта и скрам-мастер — часто решают назначить одному человеку. Обычно это менеджер проекта или тимлид. Но это так не работает.
Скрам-мастер — это не только тот, благодаря кому встречи команды наконец-то начинают укладываться в отведенное для них время. Его задача — помогать команде придерживаться правил фреймворка и, главное, самоорганизовываться: понимать, как прийти к заданной цели, вовремя обнаруживать проблемы и находить их решения.
Product owner в это время должен развивать продукт, чтобы тот удовлетворял потребности потребителей и приносил прибыль компании. Он отвечает за видение продукта, за понимание потребностей клиентов, обеспечивает коммуникации между стейкхолдерами и командой и формирует бэклог, над которым будет работать команда.
По сути, product owner говорит команде, что нужно делать, но не навязывает свое видение, как этого добиться. А скрам-мастер помогает команде научиться работать максимально эффективно, постоянно улучшая процесс своей работы. И если обе этих роли соединить в одном человеке, мы вернемся к модели работы классического менеджера, и наши Agile и Scrum превратятся в просто наклеивание стикеров и постоянные встречи.
Анализ продуктов конкурентов
Когда product owner задумывается о развитии продукта и повышении его ценности для клиентов, сравнение обычно идет с тем, что предлагают конкуренты. И вот почему этого недостаточно:
Клиент не делает буквальный выбор между продуктами А и Б — он хочет решить свою задачу. И для этого у него может оказаться гораздо больше возможностей, чем кажется при анализе текущей ситуации на рынке.
Простой пример. Допустим, наша компания производит сушилки для обуви: мы много работаем над дизайном, бьемся за снижение энергопотребления и делаем провод, который не перегрызет собака. Мы смотрим на сушилки конкурентов и стараемся сделать лучше.
А теперь представьте, что вы попали под дождь. Не впервые за это лето, и в этот раз пообещали себе точно не забыть купить сушилку. Но тут вам на глаза попадается газета, из тех что вечно оказываются в почтовом ящике, — и это тоже способ решить вашу проблему. И вот уже бесплатная газета становится конкурентом сушилок производителя А, и Б, и С. А еще можно поставить обувь к батарее — не самый бережный метод, но и это тоже конкурентный способ решить проблему клиента.
Поэтому мы рекомендуем при разработке стратегии развития продукта, помимо анализа текущего поведения пользователей и сравнения с предложениями конкурентов, учитывать любые альтернативы, которые позволят клиенту решить свои задачи.
❓ А какие неочевидные альтернативы есть у вашего продукта?
Когда product owner задумывается о развитии продукта и повышении его ценности для клиентов, сравнение обычно идет с тем, что предлагают конкуренты. И вот почему этого недостаточно:
Клиент не делает буквальный выбор между продуктами А и Б — он хочет решить свою задачу. И для этого у него может оказаться гораздо больше возможностей, чем кажется при анализе текущей ситуации на рынке.
Простой пример. Допустим, наша компания производит сушилки для обуви: мы много работаем над дизайном, бьемся за снижение энергопотребления и делаем провод, который не перегрызет собака. Мы смотрим на сушилки конкурентов и стараемся сделать лучше.
А теперь представьте, что вы попали под дождь. Не впервые за это лето, и в этот раз пообещали себе точно не забыть купить сушилку. Но тут вам на глаза попадается газета, из тех что вечно оказываются в почтовом ящике, — и это тоже способ решить вашу проблему. И вот уже бесплатная газета становится конкурентом сушилок производителя А, и Б, и С. А еще можно поставить обувь к батарее — не самый бережный метод, но и это тоже конкурентный способ решить проблему клиента.
Поэтому мы рекомендуем при разработке стратегии развития продукта, помимо анализа текущего поведения пользователей и сравнения с предложениями конкурентов, учитывать любые альтернативы, которые позволят клиенту решить свои задачи.
❓ А какие неочевидные альтернативы есть у вашего продукта?