4 простых правил для эффективной работы в большой и очень большой команде

Я работаю менеджером IT продуктов в корпорациях с 2013 года и среди моих проектов были «проекты-гиганты», которые подразумевали большую рабочую группу. Очень большую рабочую группу. Я хочу поделиться с вами своим опытом работы в одной из таких рабочих групп, где, несмотря на количество людей (около 40 активных участников) , удалось запустить продукт. Надеюсь, мой опыт поможет вам не растеряться и максимально быстро наладить эффективную работу команды любой величины.

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

Невозможно в одиночку создать и запустить большой работающий сервис или продукт в корпорации, которая (например) обслуживает 50 млн клиентов, где даже для того, чтобы оценить экономическую эффективность будущего проекта необходимо привлекать людей из фин. отдела, HR, проектного офиса, службы поддержки клиентов, коллег отвечающих за инфраструктуру и закупки, и еще много кого. Уже на этом этапе я стала испытывать напряжение, ведь это было еще даже не начало работы над созданием самого продукта, но уже пришлось несколько десятков раз рассказать и подискутировать об идее продукта, который я предлагала. Несмотря на то, что в какой-то момент уже показалось, что этот этап никогда не закончится, у меня все получилось: финансовый кейс по затратам и потенциальной прибыли сошелся, идею продукта утвердили на всех комитетах, руководство компании дало добро и я решила, что можно приступать к разработке. По крайней мере, мне так показалось, ведь уже была утверждённая идея будущего классного продукта, план график работ и, главное — деньги. Этот момент и стал самым удивительным для меня – я наблюдала как разрастается круг интересующихся моим продуктом. И выглядело это пугающе. Мне на почту стало сыпаться бесконечное количество писем от незнакомых, до этого момента, людей с вопросами о планах и деталях продукта, с приглашениями на встречи, всевозможные предложения и требования. В том числе требования – включить того или иного (еще раз отмечу!) незнакомого мне человека в рабочую группу. Так, моя команда из нескольких понятных сотрудников, с которыми мы все придумывали, обсуждали, рассчитывали, проводили исследования и, как ни странно, наладили качественную во всех смыслах коммуникацию разрослась до огромной рабочей группы. В ней я мало кого знала лично (они так же, о моем существовании не подозревали), их работа и функции были мне ясны лишь частично и, как ни странно, не со всеми сложилось комфортное общение и хорошее впечатление с первого взгляда первой встречи/разговора/переписки.

Если вы хоть раз писали рабочее письмо на группу более 10 человек, то вы знаете во что это иногда превращается. У меня, в тот моменты, были письма на 20, 30, 40 коллег. Очень быстро, уровень безумия и моего отчаяния возрос до максимума, так как я в течение одного дня могла увидеть, как потенциальная стоимость продукта вырастала в несколько раз, а сроки разработки и дата старта работ сдвигались чуть ли не на год.

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

Справочник контактов по проекту, где собраны все имена, роли, зоны ответственности, способы связаться, а в идеале и системы/сервисы за которые человек отвечает – это Must Have! Возможно, вы сейчас разочаровались, увидев именно это правило первым. Но я вам скажу, не торопитесь делать выводы. После того как 30 раз ответите на письмо с текстом «А кто у вас отвечает за …?» вот тогда и вспомните это правило.Так что, как только в команде появляется более 5 человек, которые досконально знают не только имена с фамилиями и кто за что отвечает, но даже могут подменить друг друга – это сигнал к действию – делай справочник!Ни ты, ни другие члены команды не смогут держать эту важную информацию в голове, а с учетом ее неизбежных обновлений (в большой рабочей группе будут заболевать/уходить на другие проекты и увольняться старые участники и появляться новые участники) – задача не выполнима вовсе.

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

Сколько полей будет в твоем справочнике – решать тебе. Главное не превратить его в архив досье, а сделать простым, полезным и доступным инструментом.

Еще одно правило, которое может сэкономить вам уйму времени, а выглядит не очень-то важным (по началу) – создать и обновлять глоссарий проекта.

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

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

Тем более, что делается это очень просто:1. слышишь слово, аббревиатуру, название системы или технологии значение которой не знакомо или вызывает сомнение2. узнаешь значение3. вносишь в глоссарий. И тебе проще запомнить, и другим членам команды полезно (а новеньким вообще, как спасательный круг) .

*из личного опыта: Стала постоянно слышать от разных людей из рабочей группы слово «Ансамбль» (имелась ввиду Ensemble system — комплексный продукт, сочетающий в себе СУБД, сервер приложений, интеграционною шину предприятия (ESB), BPM систему и технологию разработки аналитических приложений(BI)). Некоторое время не решалась спросить, что они имеют в виду. Сама для себя интерпретировала это слово как «Группу систем», по аналогии с «музыкальным ансамблем», который про коллектив музыкантов, объединенных общей целью. Понимаете какой бред иногда получается просто потому, что кто-то постеснялся или не успел спросить, что значит то или иное слово.

Место глоссарию там же, где и справочнику контактов по проекту.

На сколько я помню, в нашем здании не было переговорной комнаты, в которой смогла бы поместиться вся наша рабочая группа. Но даже если бы такая и была, то первая общая встреча могла бы оказаться последней. Считаю так, потому что не раз видела битвы в переписках на 30 - 40 человек. Пока это происходит в почте, есть сдерживающий фактор (письмо – это улика) и люди стараются выбирать выражения. На личных встречах этот сдерживающий фактор порой отказывал. Это я к чему: собирать ВСЮ рабочую группу вместе интересная, но очень опасная идея. Если есть возможность информировать всех письменно, то пользуйтесь этим. А собрать всех вместе сможете по случаю удачного запуска или другого позитивного «тимбилдингового» повода.

Разделите большую рабочую группу на функции, по принципу решения конкретной задачи или типов задач. Принцип разделения выбирайте логичный и соответствующий рабочим задачам (не на красивых и умных или неконфликтных и сумасшедших).Чем более конкретная задача стоит перед людьми и чем сильнее они могут повлиять на ее решение, тем быстрее она (задача) решается.Как это работает хорошо видно, когда на встрече появляется человек, который не понимает, о чем идет речь, но очень интересуется и «хочет все знать». Он будет задавать много вопросов не по существу, вносить «гениальные» идеи и, что самое страшное, делать не верные выводы, которыми будет делиться с другими участниками рабочей группы (и не только). Этого можно избежать, если собирать на встречи только действительно важных участников, а не всех желающих.

!в случае, если кто-то хочет прорваться на встречу, а вам не ясен смысл присутствия этого участника – не стесняйтесь спрашивать: «Чем ты можешь быть полезен при решении этой (та ради которой собираются) задачи?». Если человеку необходимо знать лишь итог/решение по итогам встречи, то его присутствие необязательно.

Однако, после каждой такой встречи «не на всех» необходимо писать о результатах и достигнутых договорённостях уже на более широкий круг рабочей группы. Скорее всего, даже на всех. Те, кому не интересно - пропустят, те кому важно – получат желаемое. Это обязательное условие.

В итоге:

1. Есть задача/тип задач

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

3. Собираете только эту часть рабочей группы и решаете только эту задачу/тип задач

4. Оповещаете всю рабочую группу о достигнутых результатах и договорённостях

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

*Протоколы таких встреч тоже можно заносить в общее пространство проекта, чтобы любой интересующийся член рабочей группы мог понять, когда и почему было приято то или иное решение. Об этом и будет заключительная часть этой статьи.

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

По итогу любой (в основном) рабочей встречи или переписки у нас должны оставаться артефакты: вопросы (которые требуют выяснения), принятые решения, спорные моменты, предложения, поручения и т.п. Если не фиксировать эти артефакты, то их никто не запомнит, не сделает, не примет к сведению, не возьмет в работу. Это Факт!А когда мы говорим о работе большой рабочей группой, то все это еще усложняется тем, что не все приуставали на встрече, забыли, не так поняли, интерпретировали по-своему и т.д. Не дайте этому хаосу разрушить рабочий процесс. Для этого надо:

1. После каждой встречи составляйте протокол (не путать со стенограммой). В нем должно быть зафиксировано самое важное:

• Перечисление участников

• Достигнутые решения/договоренности

• Вопросы к размышлению, исследованию (с именами задавших вопроси и тех, кто должен ответить) с требуемой датой ответа

• Поручения с требуемой датой исполнения

Такой протокол надо делать и рассылать всей рабочей группе. Это создаст максимально прозрачную картину дел.

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

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

3. Никакие требования, запросы, ответы на спорные принципиальные вопросы не принимаются в устной форме. Хочешь что-то получить: напиши письмо! Это можно пренебрежительно называть бюрократией и как угодно, но только такой формат коммуникации зафиксирует «Что/Кто? Где? Когда?». Это не предостережет вас от недопониманий и срыва сроков/невыполненных задач/открытых вопросов, но сократит их количество в несколько раз.

При выполнении всех пунктов 4-го правила не бойтесь выглядеть занудой. Какая разница, зануда вы или нет, если ваш полезный продукт стартовал и зарабатывает деньги?

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