Организация совместной работы: зоны ответственности, правила коммуникации, инструменты и внедрение

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

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

Как организовать совместную работу?

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

Организация сводится к восьми элементам:

1. Зоны ответственности: кто за какую область отвечает

2. Единое рабочее пространство: где лежат задачи и файлы

3. Правила коммуникации: где что обсуждается и за какой срок отвечают

4. Процесс работы с задачами: через какие статусы проходит задача

5. Регламенты: как записаны повторяющиеся правила

6. Обмен знаниями: куда складываются решения и документы

7. Синхронизация: как и когда команда сверяет состояние дел

8. Управление доступом: кто что видит

Четыре из них отвечают на вопрос «о чём договорились»: зоны ответственности, правила коммуникации, регламенты и управление доступом. Остальные четыре отвечают на вопрос «что видно каждому».

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

Определить зоны ответственности

Зона ответственности фиксируется письменно и в одном месте: область, фамилия, что входит и что не входит. Устная договорённость «ну ты же этим занимаешься» зоной ответственности не является, потому что её нельзя открыть и перечитать.

Стандартный инструмент фиксации это матрица RACI. Четыре буквы означают роли: Responsible, тот кто делает; Accountable, тот кто отвечает за результат и имеет право сказать «да» или «нет»; Consulted, с кем советуются до решения; Informed, кого извещают после.

В методических материалах по RACI есть правило: у каждой задачи ровно один Accountable. Формулировка звучит так: «There must be one, but only one, "A" for each action or decision». Это общепринятая практика, а не пункт стандарта: в Body of Knowledge Ассоциации управления проектами аббревиатуры RACI нет вообще.

Про происхождение метода стоит сказать отдельно, потому что в интернете гуляет с десяток взаимоисключающих версий. Ни одна не подтверждается: названные «авторы» либо не существуют в библиографических каталогах, либо не имеют к теме отношения. Английская Википедия раздела истории не содержит вовсе.

Документирован предок метода. Линейная карта ответственности описана в статье Кливленда и Мансея «Who Works With Whom?» в Harvard Business Review за ноябрь-декабрь 1967 года и развита в их книге по системному анализу годом позже.

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

Выглядеть это может так:

Три столбца вместо четырёх, потому что на старте «делает» и «отвечает» обычно совпадают. Разделять их имеет смысл, когда появится задача, где отвечает один, а делает другой.

У распределения ответственности есть последствие, о котором редко пишут в статьях про командную работу. Мелвин Конвей сформулировал его в 1968 году в статье «How Do Committees Invent?»: организации, проектирующие системы, вынуждены создавать решения, копирующие структуру коммуникаций этих организаций.

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

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

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

В таск-менеджере зона ответственности живёт в поле исполнителя: оно видно всей команде, а фильтр «Задачи без исполнителя» показывает незакрытые места одним кликом. Если распределение упирается в нежелание отпускать контроль, стоит разобраться с делегированием.

Выбрать единое рабочее пространство

Единое пространство означает, что задачи, файлы, обсуждения и документы лежат в одном месте, а не расходятся по почте, чатам и личным дискам. Критерий простой: новый сотрудник может найти нужное сам, не спрашивая коллег.

Разбросанность стоит дороже, чем кажется. Когда задача обсуждается в мессенджере, файл лежит на диске, а срок назван голосом на созвоне, состояние дела не существует нигде целиком. Собрать его можно только опросом.

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

Отдельный вопрос, как устроено пространство именно у продуктовой команды: как выстроить рабочее пространство IT-команды разобрано отдельно.

Определить правила коммуникации

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

Рабочий минимум выглядит так:

• обсуждение задачи идёт в комментариях к этой задаче, не в мессенджере

• решение, принятое в переписке, переносится в задачу тем, кто его принял

• срок ответа в рабочее время: до конца следующего рабочего дня

• в личные сообщения уходит только личное, рабочие вопросы в общее место

• срочное это то, что ломает работу сегодня, остальное не срочное

Смысл правил не в дисциплине, а в стоимости переключения. Исследование фрагментированной работы, представленное на конференции CHI в 2005 году, показало: если человек возвращался к прерванной задаче в тот же день, между отвлечением и возвратом проходило в среднем 25 минут 26 секунд. Непрерывный отрезок работы составлял около 11 минут.

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

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

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

У этого вывода есть законный оппонент, и его стоит назвать честно. Agile-манифест прямо утверждает обратное: «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды». Это официальный русский перевод с сайта манифеста, не пересказ.

Противоречие снимается разделением по типу вопроса. Всё, где нужно согласовать позиции и услышать возражения, идёт голосом: манифест прав. Всё, где нужно передать факт, статус или решение, идёт текстом в задачу: там живое общение только отвлекает и не оставляет следа.

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

Настроить процесс работы с задачами

Процесс это набор статусов, через которые проходит задача, и правила перехода между ними. Минимальный набор: поставлена, в работе, на проверке, закрыта. Больше четырёх статусов на старте заводить не стоит.

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

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

Регламентировать совместную работу

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

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

Проверка усвоения важнее самого текста. В Strive к регламенту прикрепляется тест, и видно, сколько человек его прошли. Регламент, который никто не открывал, ничем не отличается от его отсутствия.

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

Организовать обмен знаниями

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

Документация устроена как дерево вложенных страниц: разделы разворачиваются, у каждой страницы есть список участников с доступом, комментарии и история изменений. Страницу можно закрыть замком, открыть по ссылке или выгрузить в PDF и Markdown.

Правило простое: если объяснение заняло больше десяти минут переписки, оно становится страницей документации. Как выстроить ведение документации целиком, разобрано отдельно.

Синхронизировать команду

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

Формат встреч стоит держать под контролем, потому что совещания дорожают незаметно. По данным Harvard Business Review за 2017 год, руководители проводят на совещаниях почти 23 часа в неделю против менее чем 10 часов в шестидесятые. В опросе примерно двухсот руководителей лишь 17% назвали свои совещания продуктивным использованием времени.

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

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

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

Разделять стоит два разных типа встреч. Ежедневная синхронизация отвечает на вопрос «что сейчас мешает», разбор процесса отвечает на вопрос «что менять». Смешивать их не нужно: первый формат короткий и про факты, второй длинный и про выводы.

Второй формат это ретроспектива, и у неё свои правила проведения: как проходит ретроспектива и что на ней говорить, разобрано отдельно.

Настроить управление доступом

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

В Strive роли распределены по двум уровням. В организации это владелец, администратор, участник и читатель. В пространстве три роли: читатель, инициатор и участник. Роль определяет, что человек может делать с проектами, задачами, регламентами и документацией.

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

Какими способами организовать совместную работу?

Способа два: договорённостями без инструмента и через таск-менеджер. Разница не в удобстве, а в том, где хранится состояние дел.

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

Как организовать совместную работу без инструмента?

Алгоритм состоит из четырёх шагов:

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

2. Завести таблицу с задачами, исполнителями и сроками

3. Раз в день собирать статусы в чате или на планёрке

4. Руками обновлять таблицу по результатам сбора

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

Как организовать совместную работу через таск-менеджер?

Тот же алгоритм, но каждый ручной шаг заменяется настройкой:

1. Договорённость о зонах ответственности становится полем исполнителя в задаче

2. Таблица становится доской, где задача сама показывает свой статус

3. Сбор статусов не нужен: исполнитель двигает задачу, остальные это видят

4. Обновление не нужно: доска и есть текущее состояние

Исчезает не работа, а посредник между работой и знанием о ней. Никто не пересказывает состояние дел, потому что оно записано там же, где делается.

Какие функции таск-менеджера нужны для совместной работы?

Список короткий, каждая функция закрывает один из восьми элементов:

• назначение исполнителя: закрывает зоны ответственности

• комментарии в задаче: закрывают правила коммуникации

• настраиваемые колонки и автоматизация: закрывают процесс

• регламенты с тестом: закрывают повторяющиеся правила

• документация: закрывает обмен знаниями

• доска задач и статистика: закрывают синхронизацию и прогресс

• роли и права доступа: закрывают управление доступом

• уведомления: связывают всё перечисленное с людьми

Как распределять задачи между сотрудниками?

Исполнитель назначается в самой задаче и получает уведомление. Уведомления настраиваются и приходят в интерфейс, в push, в Telegram и в MAX, включая напоминания о дедлайнах.

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

Как обсуждать задачи внутри команды?

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

Ценность не в самой функции комментариев, а в том, что решение лежит рядом с работой. Договорённость из чата теряется при первом же поиске, договорённость в задаче находится вместе с задачей.

Как видеть общий прогресс команды?

Прогресс смотрят в трёх местах. Доска задач показывает текущее состояние проекта. Раздел «Все задачи» собирает задачи всего пространства с группировкой по проектам, датам или исполнителям. Статистика пространства показывает по каждому сотруднику выполненные, отклонённые и задачи в работе за выбранный период.

Отдельно работают индикаторы: «Огонёк» помечает задачу, вышедшую за срок, «Улитка» помечает неактивную от одного до семи дней с настраиваемым порогом, «Требует внимания» выделяет задачу красной плашкой.

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

Как разграничить доступ к проектам?

Доступ разграничивается ролями на уровне пространства, а не отдельными галочками на каждом проекте. Читатель видит и не меняет, инициатор создаёт задачи, участник работает с ними полноценно.

Практическое следствие: подрядчика или стажёра добавляют в отдельное пространство с ролью читателя, а не в общее с ограничениями. Так проще объяснить и невозможно ошибиться.

Как внедрить совместную работу в команде?

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

Первая неделя. Один проект, один процесс. Возьмите одну команду и один реальный проект. Заведите четыре статуса и назначьте исполнителей. Ничего больше: ни регламентов, ни ролей, ни документации.

Вторая неделя. Перенос обсуждений. Договоритесь, что обсуждение задач идёт в задачах. Ломается этот шаг чаще всего, поэтому нужен человек, который будет отвечать в мессенджере одной фразой: «перенеси в задачу, отвечу там».

Третья неделя. Правила и доступы. Запишите правила коммуникации на одну страницу. Раздайте роли. К этому моменту уже понятно, кому что реально нужно видеть, а на старте это было бы гаданием.

Четвёртая неделя. Знания и разбор. Заведите документацию и перенесите туда первые повторяющиеся ответы. Проведите разбор: что прижилось, что нет, что мешает.

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

• Статус спрашивают реже: вопрос «как там дела с этим?» задаётся не каждый день

• У задач есть исполнители: фильтр «Задачи без исполнителя» почти пуст

• Решения находятся: спор двухмесячной давности удаётся поднять за минуту

• Новичок стартует сам: первую неделю ему не нужен постоянный сопровождающий

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

Почему на второй неделе становится хуже

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

Объяснение даёт модель развития команды Такмана, предложенная в 1965 году: команда проходит стадии forming, storming, norming и performing. Пятую, adjourning, автор добавил в пересмотре 1977 года в соавторстве с Дженсен.

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

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

Пользоваться моделью как объяснением полезно, ссылаться на неё как на закон не стоит. Разногласия на второй неделе вы увидите независимо от того, насколько строго доказана схема.

Что делать с сопротивлением

Фраза «нам это не нужно, мы и так справляемся» почти всегда означает, что человек не видит своей выгоды, а видит только новую обязанность. Отвечать на неё стоит не аргументом, а фактом из его работы: сколько раз за неделю у него спрашивали статус.

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

Третий случай самый тихий. Люди формально соглашаются, заводят задачи, но продолжают решать всё в личных сообщениях. Признак: в трекере ровные статусы, а сроки срываются внезапно и без предупреждения.

Что чаще всего идёт не так?

Инструмент внедрили, а договорённости нет. Самая частая ошибка. Задачи заводятся, но кто за что отвечает по-прежнему решается голосом. Инструмент показывает беспорядок точнее прежнего, и его в этом обвиняют.

Статусы означают разное для разных людей. Для одного «на проверке» значит «я закончил», для другого «уже проверено». Лечится одной строкой рядом с названием статуса.

Обсуждение живёт в мессенджере, а задача в трекере. Половина контекста остаётся в переписке, и через месяц восстановить логику решения невозможно. Признак: в задаче две строки, а в чате двести сообщений.

Регламент написали и забыли. Документ, который никто не открывал после первой недели, не регулирует ничего. Проверяется тестом или простым вопросом на встрече.

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

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

Последняя ошибка глубже остальных, поэтому про неё подробнее. Google в исследовании, известном как проект «Аристотель», изучил более 180 своих команд и выделил пять факторов эффективности: психологическая безопасность, надёжность, структура и ясность, значимость работы, влияние работы. Первый фактор компания назвала самым важным и подпирающим остальные четыре.

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

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

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

Что с этим делать, показывает то же исследование Harvard Business Review про совещания. Команды, которые пересобрали формат встреч, получили рост психологической безопасности на 32% и результативности на 28%. Правила встреч и готовность говорить о проблемах оказались одним и тем же рычагом, а не двумя разными.

Отдельная тема, к которой это приводит, если ничего не менять: чем заканчивается хаос в задачах для самих сотрудников.