В этом году я решил попробовать нестандартные методы для обучения: интенсивы, игры и другие подходы.
Вашему вниманию представлена деловая ролевая игра «Оценка задач», которая готовит проджект-менеджеров ко всем возможным ситуациям в процессе оценки. Рефлексия после каждого «раунда» помогает закрепить материал.
Концепция игры
Что такое «оценка» — это процесс демонстрации продуктом идеи для команды с подготовленными артефактами: прототип и описание того, как идея решает проблему пользователя.
Для кого: для команд разработки и проджектов.
Роли участников:
- РО — продукт-оунер, рассказывает идею команде, отвечает на вопросы, хочет получить объективную оценку.
- ПМ — руководитель проекта, руководит процессом оценки.
- Аналитик — проводит поверхностный анализ задачи и варианты наложения на текущую архитектуру системы.
- Дизайнер — отвечает за визуальную реализацию, должен обращать внимание на прототипы, важно обсуждать с фронтендером возможные решения.
- Бэкендер — проектирует решение, должен полностью понять, что хочет продукт.
- Фронтендер — проектирует реализацию UI, должен ограничивать полёт фантазии дизайнера.
- Тестировщик — оценивает объём тестирования, возможные риски решения и подводные камни.
Концепция игры:
1. Создание ситуации оценки задач продукта.
2. Участники должны быть в неестественных ролях, например, разработчик получает роль аналитика или тестировщика.
3. У каждой роли есть антипаттерны поведения, которые участник разыгрывает в ситуации.
4. Задача участника с ролью руководителя проекта — преодолеть все антипаттерны поведения, выдержать встречу в рамках и добиться результата.
Итоги игры: ПМ сделал всё хорошо, если:
1. Встреча прошла структурно.
2. Конфликты удалось погасить или избежать.
3. Задача была декомпозирована и оценена.
4. РП справился с антипаттернами поведения.
5. Оценка задачи имеет обоснование на своё существование.
6. Встреча прошла в заложенный тайминг.
Процесс проведения
Начинается сама игра:
1. Ведущий рассказывает правила: 3 оценки, каждый будет в роли ПМа и в роли одного из участников оценки: аналитика, разработчика, тестировщика.
2. Назначается первый ПМ, раздаются роли индивидуально остальным. Даются пояснения.
3. Когда все готовы — объявляется старт первого раунда. Засекается таймер на 15 минут.
4. Руководитель QA, он же играет роль Product Owner, запускает демонстрацию экрана с первой продуктовой задачей.
5. Модерация встречи полностью переходит к играющему ПМу.
6. Оценка проходит согласно нашему процессу разработки.
7. Оценка заканчивается. Объявляется стоп-игра.
8. Проджект-менеджер пытается угадать, с кем он только что оценивал задачи.
9. Дальше рефлексия всех участников первой итерации.
10. Повторяется для ещё 2 сценариев.
11. В конце рефлексия по всей игре: начинает приглашённый на роль Product Owner, дальше остальные участники. В конце ведущий проговаривает важные нюансы и основные ошибки, которые были допущены. Обсуждается, как их в дальнейшем не допускать и исправлять.
Как прошла игра
Игра была проведена между всеми проджект-менеджерами нашей компании, всего их трое. Был приглашён руководитель тестирования на роль Product Owner. Я был ведущим, но при этом отыгрывал одну из ролей из списка, следил за выполнением условий игры и подмечал моменты, которые нужно было вынести на обсуждение.
3 ситуации, при которых каждый проджект примерил на себя роль ПМа и провёл встречу по оценке задач, а также ещё одну из ролей: аналитик, разработчик, тестировщик.
Так как нас было 5 человек, мы сократили разработчиков до одного и убрали дизайнера из возможных ролей. Если будете проводить на продуктовую команду, нужно использовать весь набор.
Выводы после игры
Всем понравилось.
Каждый испытал на себе разные роли, что позволило подойти к заданию творчески.
Прошло нескучно.
Много кейсов было решено правильно.
Во время рефлексии многие вспомнили похожие ситуации, а также проанализировали во время игры, что не получилось.
Были подсвечены проблемные места и что нельзя ПМам делать на такой встрече.
