Наверное, нет большего деструктива в процессах команд, предполагающих большие объемы взаимодействия, чем «встречи ради встреч». Именно в рамках борьбы с ними, у меня когда-то и оформилась компиляция принципов 7Ps Framework Джеймса Макануфо и допилок фреймворка под себя, которые я вынесла из работы в командных проектах в UIS.
В целом, в этом подходе мне импонирует то, что он, по сути, прост и базируется на здравом смысле относительно командных мероприятий, к которому рано или поздно приходят все менеджеры проектов, модераторы встреч и другие причастные специалисты.
Проблема и решение
Встречи затягиваются, коллеги ворчат про «очередную бесполезную встречу», цель не ясна и вообще непонятно, а зачем было нужно встречаться. Все это ведет к тому, что участники демотивируются и не хотят принимать хоть какое-нибудь участие в процессе. Качество решений, если они и принимаются, снижается.
«Назначая встречу, вы обязаны позаботиться о том, чтобы ее участники потратили свое время с пользой для компании и для себя» — тот профит, которого удается добиться с помощью фреймворка 7Ps
Собственно, 7Ps:
- Purpose. Цель встречи. Зачем собираться? Если не можете четко ответить для себя на этот вопрос, то встречу проводить не стоит.
- People. Кто участвует во встрече и кто нужен для достижения ее цели?
- Product. Какой результат должен получиться? Как измерить, что результат встречи достигнут?
- Process. Повестка встречи и формат принятия окончательного решения. К примеру, вы можете собрать мнения всех участников встречи, но решение принять единолично, но важно, чтобы такой сценарий понимали и осознавали все.
- Pitfalls. Продумайте возможные проблемы и риски, которые могут возникнуть на встрече и то, как ими управлять и устранять их.
- Prep. Нужно ли специально подготовиться к встрече? Может быть, участникам нужно дать «домашнее задание» или почитать что-то дополнительно.
- Practical Concerns. Где и во сколько будет проходить встреча? Какое оборудование или помещение нужно, прочие организационные моменты.
Каждое «P» влияет на другие. К примеру, отсутствие правил (плохо проработанный Pitfalls) встречи может повлиять на Process и Product
Дополнительные советы
- Сообщайте участникам о встрече и ее длительности заранее (желательно за несколько дней), так как у них могут быть свои планы
- Получите от всех подтверждение об участии
- Напомните о встрече за пару дней до начала
- Перед началом встречи договоритесь о перерывах. К примеру, можно использовать правило 50 на 10 — 50 минут встреча, 10 минут перерыв
- На старте согласуйте организационные правила: к примеру, никаких телефонов и ноутбуков, никаких обвинений в адрес друг друга и т.п.
Где почитать больше
Детальнее в 7Ps Framework можно погрузиться с книгой Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers
Как это выглядит в живую у вас? КАк получилось зашить это в систему?
Вживую это упражнение, которое совершает каждый из команды, кто "владелец" встречи. У нас это могут быть разные люди, которым нужно собрать остальных в рабочие группы по своим зонам ответственности. Именно в регламент какой-то это не зашито, и потому бывают, конечно, проколы и кто-то, например, забывает дать "домашнее задание" к встрече и т.п. Но потом на ретроспективе по спринту (мы работаем в скраме) его за это журят и все это освежается в голове. Думается, ты прав и надо задуматься о том, чтобы зашить в систему. Спасибо за мысль!