В этом году я решил попробовать нестандартные методы для обучения: интенсивы, игры и другие подходы.
Вашему вниманию представлена деловая ролевая игра «Оценка задач», которая готовит проджект-менеджеров ко всем возможным ситуациям в процессе оценки. Рефлексия после каждого «раунда» помогает закрепить материал.
Концепция игры
Что такое «оценка» — это процесс демонстрации продуктом идеи для команды с подготовленными артефактами: прототип и описание того, как идея решает проблему пользователя.
Для кого: для команд разработки и проджектов.
Роли участников: - РО — продукт-оунер, рассказывает идею команде, отвечает на вопросы, хочет получить объективную оценку. - ПМ — руководитель проекта, руководит процессом оценки. - Аналитик — проводит поверхностный анализ задачи и варианты наложения на текущую архитектуру системы. - Дизайнер — отвечает за визуальную реализацию, должен обращать внимание на прототипы, важно обсуждать с фронтендером возможные решения. - Бэкендер — проектирует решение, должен полностью понять, что хочет продукт. - Фронтендер — проектирует реализацию 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 человек, мы сократили разработчиков до одного и убрали дизайнера из возможных ролей. Если будете проводить на продуктовую команду, нужно использовать весь набор.
Выводы после игры
Всем понравилось.
Каждый испытал на себе разные роли, что позволило подойти к заданию творчески.
Прошло нескучно.
Много кейсов было решено правильно.
Во время рефлексии многие вспомнили похожие ситуации, а также проанализировали во время игры, что не получилось.
Были подсвечены проблемные места и что нельзя ПМам делать на такой встрече.
Комментариев пока нет — может, вы будете первым?