Анализ стейкхолдеров проекта

Несмотря на то, что в базовом варианте работа agile-команды не предполагает такую процедуру как Управление проектом (как и саму роль менеджера проекта), часто бывает полезно применять хорошие практики, наработанные в рамках стандартных процедур управления проектами.

Одна из них — анализ стейкхолдеров проекта.

https://telegra.ph/Analiz-stejkholderov-proekta-10-02

Как проводить встречи, если вы менеджер и все ждут вашего решения?

Интересный вопрос, который нам задали на тренинге.

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

Что делать?
1. Как руководителю, нужно менять культуру: максимально вовлекаться в процесс работы команды и лично ходить на встречи. Чтобы команда начала воспринимать вас не как начальника, а как человека, который участвует в процессе работы и готов способствовать ему.

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

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

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

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

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

Вышла новая версия Scrum 2020

Коротко: это все тот же Scrum. Если вы не занимаетесь процессами на ежедневной основе, кардинальные отличия заметить будет непросто.

Однако есть несколько важных вещей, которые обновились, и мы очень хотим обсудить их с вами:

1. Владелец продукта и Разработчики стали единой командой.
2. Владелец продукта и Скрам-мастер — больше не роли.
3. Владелец продукта может выступать Разработчиком.
4. У продукта, который разрабатывает команда, должна быть определена цель.
5. Уменьшена детализация инструментов фреймворка.

Подробности по каждому пункту в статье на нашем сайте: https://onagile.ru/trends/agile/scrum-2020

4 способа совместить в спринте работу по проекту и поддержку

Многим ИТ-командам знакома ситуация: берем задачи в спринт и не успеваем их завершить, потому что часть времени ушла на поддержку уже существующего продукта.

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

Для этого есть четыре основных паттерна:

1. Выделить процент из объема задач, которые команда выполняет за спринт. (Объем оценивается, например, в сторипойнтах.) Соотношение в каждом проекте будет свое и определяется экспериментально.

Соответственно, на планировании спринта мы берем в бэклог задачи суммарным объемом, например, в 70% производительности команды. А 30% оставляем на поддержку.

2. Зарезервировать время. Это не обязательно фиксированные часы — просто мы понимаем, что, например, 2 часа в день уходят на поддержку. Значит на новые фичи остается 6 часов.

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

3. Выбрать «дежурного по багам». То есть участника команды, который в данном спринте фиксит всё. При планировании спринта мы этого человека не учитываем в командной производительности.

4. Провести отдельное ретро и всей командой порассуждать, почему у нас столько инцидентов? Можем ли мы уменьшить их количество?

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

А как вы учитываете поддержку при планировании?

Как договариваться со стейкхолдерами о сроках в agile-среде

Итак, команда начинает работать инкрементами и от традиционного планирования переходит к гибкому. Стейкхолдеров же по-прежнему интересует, когда будет поставлен тот или иной функционал. Как быть?

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

🔹Команда мыслит инкрементами и ориентируется на Цель продукта.
Это позволяет крупными мазками наметить, как мы будем двигаться к продуктовой цели.

🔹Создаем роадмап — например, на полгода. И отражаем на ней все ключевые точки/инкременты. То есть мыслим не числами (когда будет поставлен конкретный функционал), а очередностью.

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

Занимается созданием и актуализацией роадмап Владелец продукта. Очередность инкрементов определяется вместе со стейкхолдерами.

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

Пример, как может выглядеть дорожная карта продукта

Нужен ли технический бэкграунд Скрам-мастеру?

Короткий ответ - зависит от этапа развития команды.

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

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

А что делать при найме Скрам-мастера?

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

Даже компаниям в активной фазе трансформации, когда сразу формируются десятки команд и соответственно десятки вакансий, мы рекомендуем набирать Скрам-мастеров не всем скопом (частый аргумент здесь — «потому что в Сбере их сотни»), а все-таки ориентируясь на конкретные команды и их состав.

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

Нужен ли Скрам-мастеру технический бэкграунд (продолжение)

Предыдущий пост на эту тему вызвал активное обсуждение. Вопрос действительно многогранный, давайте разбираться дальше;) О деталях выбора Скрам-мастера рассказывает старший консультант OnAgile Consulting Артём Гринякин.

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

Скрам-мастер выбирается или назначается из участников команды (совмещение с ИТ-позицией):

❎ Минусы:

· Непонимание своей роли и недостаточная погруженность в Agile-подходы

· Потенциальные конфликты в команде по принципу «почему он, а не я?»

· Отсутвие опыта в решении конфликтных ситуаций

· Невозможность предоставить сервис поддержки Владельцу продукта

· Отсутствие навыков фасилитации, коучинга, обучения

· Отсутствие ответов на базовые вопросы, которые часто возникают у новых команд

· Необходимость постоянно балансировать между ИТ-ролью и Скрам-мастерством

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

✅ Плюсы:

· Погруженность в предметную область

· Более эффективное использование ресурсов с точки зрения бизнеса


Скрам-мастер привлекается со стороны:

❎ Минусы:

· Временное непонимание предметной области

· Время на адаптацию и первоначальный анализ

✅ Плюсы:

· Новые знания, подходы, которые раньше не присутствовали в организации

· Навыки фасилитации, коучинга, обучения

· Вариативность в методах и практиках

· Уменение ответить на базовые вопросы

· Отсутствие конфликта интересов

· Возможность погрузиться в процесс развития команды и организации

· Предоставление сервиса поддержки Владельцу продукта

· Возможность балансирования Бизнеса и ИТ

· Умение решать конфликты

· Возможность взять до 3 команд (актуально для LeSS и производных от SAFe, где считается оптимальным использование одного Скрам-мастера на 3 команды. В немасшабируемом Scrum такой подход не приветствуется)

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

ТОП-менеджер в роли РО: особенности работы

Бывает, что развитие продукта курирует стейкхолдер из ТОПов. Может ли он являться Владельцем продукта? Какие особенности возникают в такой ситуации? Давайте разбираться.

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

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

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

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

Значительная часть усилий Владельца продукта в такой схеме будет заключаться в синхронизации со стейкхолдером. Отличный инструмент для этого — роадмап: с его помощью удобно договариваться по ключевым фичам и выстраивать ожидания.
https://t.me/agilethinking/185

HR – двигатель внутренних изменений в мире Agile?

Рассуждаем об HR с точки зрения сервисной парадигмы и использования agile-практик:
https://onagile.ru/trends/talents/agile-practices-for-hr

⚡️Ближайшие тренинги

1️⃣ Фундаментальный Certified Agile Professional — основной курс по гибким подходам, включающий Scrum и Kanban.
👉 26-28 мая, 28-30 июня, 28-30 июля 2021

2️⃣ Продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, командный коучинг и фасилитация.
👉 7-9 июля 2021

3️⃣ Продвинутый курс для Владельцев продуктов Advanced Product Ownership — проектирование и развитие продукта, управление ожиданиями заказчиков, работа в agile-команде.
👉 25-27 августа 2021

4️⃣ Управление проектами их эволюционирование в гибкой среде — Agile Project Management.
👉 23-25 июня 2021

5️⃣ NEW Agile in HR — развитие HR-сервисов, мотивационной стратегии и организационной структуры с использованием agile-подходов.
👉16-18 июня 2021

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

Тренинги проходят онлайн: в zoom и miro. Три дня по 4/4,5 часа.
Количество мест ограничено: мы работаем группами до 16 человек.

👉Бронируйте участие заранее

Как ускорить найм крутых сотрудников более чем в 2 раза

За 3 месяца удалось:
- повысить скорость закрытия вакансий более чем в 2 раза
- наладить коммуникацию между бизнесом, командами и HR
- организовать прозрачный процесс с отслеживанием метрик

Для этого использовали Канбан систему, а работу HR организовали по аналогии с продуктовой командой.

Подробности трансформации HR в финтех-компании:
https://onagile.ru/trends/business-agility/transforming-hr-service-in-profeelab

Мотивация Agile-команд (нефинансовая)

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

Так как же перейти от группы специалистов к команде мотивированных профессионалов?

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

Автономность, т.е. возможность самостоятельно принимать решения на своем уровне и нести за них ответственность.

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

И это второй фактор: мастерство. «Выполняя свою ежедневную работу, я как профессионал становлюсь все круче и круче».

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

И третий, критически важный, аспект — понимание цели. «Зачем я делаю ту или иную работу?»

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

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

Как выбрать пилотную команду

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

1. В команде должны быть все компетенции, необходимые для создания конкретного продукта.
Смысл в том, чтобы команда как можно меньше зависела от внешних факторов (поставщики, согласование и тд) — работа будет продвигаться быстрее.
Важно также, чтобы Владелец продукта имел право принимать решения: так мы тоже уйдем от потери времени на согласования.

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

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

3. Команда должна быть плоской. Мы не добьемся преимуществ командной работы, если фактически сохранится распределение ролей «начальник - подчиненные».

Желательно, чтобы в команде были один язык и один или близкие часовые пояса — чтобы было проще общаться.

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

Кто делает декомпозицию задач на User Story?

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

Один из таких вопросов нам часто задают на тренингах: кто проводит декомпозицию задач на пользовательские истории?

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

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

- Скрам-мастер может предоставить примеры, опыт и понимание, как эта практика работает.
- А бизнес-контекст добавят аналитик и Владелец продукта.

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

Если история настолько большая, что она не помещается в спринт, стоит рассмотреть ее отдельно: нужно понять, что внутри происходит, и декомпозировать, насколько это возможно.

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

Частый вопрос на наших тренингах;) Если говорить про классические подходы, например Scrum, то в них есть только Владелец продукта — проджект-менеджеров нет.

А дальше зависит от подхода:

- В NEXUS и LeSS тоже самое, что и в Scrum — только Владелец продукта.
- В классическом SAFe есть иерархия: на программном уровне находится продукт-менеджер, который работает с Владельцами продукта (до 4 человек, под каждым РО одна — максимум две команды) и является своего рода их руководителем.
- Проджект-менеджеры есть в Disciplined Agile.

Владелец продукта и проджект-менеджер могут существовать параллельно, если компания используют кастомные решения (например, модель Spotify). Тогда часть команд будет работать по agile-подходам — и в них будет Владелец продукта, а часть будет фокусироваться на проектном подходе, и у них останутся проджекты.

Что делать проектному менеджеру, если его компания начинает внедрять agile? Во-первых, не волноваться;) Потребность в вашем профессионализме не пропадает, а только меняет форму.

Часто проджекты во время трансформации превращаются во Владельца продукта или, если компания большая, а человек очень опытный, становят RTE — Release Train Enginee. Также можно занять позицию Скрам-мастера.

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

- Переквалифицируется во Владельца продукта — и главным фокусом его внимания станет развитие продукта, а не поставка.
- Того, кто решит стать Скрам-мастером, должен интересовать не столько контроль, сколько максимальная помощь команде и фокус на том, чтобы развивать ее (можно сравнить с играющим тренером).
- На RTE переход самый простой с точки зрения восприятия: здесь вы по сути помогаете командам взаимодействовать и делаете все возможное, чтобы комадны не сошли с тех «рельс», которые построили на PI-планировании. Собственно, RTE и проводит PI-планирование.

Scrum или Канбан — что выбрать?

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

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

Scrum хорошо себя проявляет, когда вы можете четко выделить продукт.

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

Но есть ситуации, когда может не хватать людей или отдельных компетенций.

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

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

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

Стоит ли оценивать задачи всей командой?

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

Нам говорят: смотрите, в команде много разных специалистов — iOS разработчик, специалист по Android, back-end, тестировщик. Каждый занимается своей задачей в рамках своих компетенций и не сможет верно оценить трудозатраты не по своей задаче.

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

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

Через 2-4 недели работы в таком формате каждый человек уже более-менее легко и точно сможет оценить работу коллеги – потому что очень глубоко в курсе подробностей задачи.

Что дает совместная оценка задач?

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

Как найти нужных людей в команду?

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

Ключевой вопрос не «где найти сотрудников», а «как захантить "своих" людей».

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

Написали в блог, как можно обойти эти сложности: https://onagile.ru/trends/talents/headhunting

А как у вас сейчас обстоят дела с пополнением команды?