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

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

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

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

Существуют три основных способа реализации межкомандной работы:

1. Временное добавление пользователей из разных команд в команды, с которыми есть взаимодействие.

2. Создание общего совместного проекта и добавление взаимодействующих пользователей из разных команд в этот проект.

3. Передача задач из проекта в проект.

Давайте рассмотрим все достоинства и недостатки каждого из описанных подходов.

1. Временное добавление пользователей в команды друг друга

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

Почему в этом способе мы заостряем внимание на слове “Временное”? Этот способ самый быстрый. Он фактически сразу может дать все необходимые инструменты взаимодействия. 

Но, у этого способа также есть существенные недостатки:

1. Нарушается принцип “единственного отношения пользователя к команде”. Т.е. для таких пользователей очень усложняется получение ответа на вопрос: “К какой конкретно команде относится этот пользователь”. Следствие - нарушение отчетности, регламентных процедур (например, расчет премий команды). Может потребоваться дополнительная настройка учетных инструментов, чтобы не “поплыла” статистика. 

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

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

Итак, подытожим:

Плюсы:

• Скорость запуска взаимодействия;

• Малое количество ограничений для взаимодействующих пользователей.

Минусы:

• Нет понимания к какой команде относятся такие пользователи;

• Лишние доступы к задачам, не относящимся к взаимодействию;

• Требуется администрирование как на старте такого взаимодействия, так и по завершению.

2. Создание совместного проекта

Этот способ гораздо более хорош во всех отношениях по сравнению с предыдущим. На схеме это можно изобразить так:

В этом способе автоматически появляется аналитический разрез “Проект” для отслеживания такого взаимодействия в статистике и отчетности. У вас всегда будет информация о том, на какие проекты участник команды был отвлечен и насколько.

Вторым большим достоинством является полная изоляция такого взаимодействия от скопов внутренних задач. У вас в “домашнем” проекте команды не возникает никаких изменений, которые могли бы привести к нарушению безопасности или ошибкам.

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

Также важным считаем, что этот способ не требует “уборки” после окончания взаимодействия.

Итак, плюсы и минусы:

Плюсы:

• Всегда есть аналитика и статистика по взаимодействию;

• Не разрушается система контроля доступа к командным пространствам;

• Не требуется “уборка” по завершению;

• Малое количество ограничений для взаимодействующих пользователей.

Минусы:

• Минус мелкий и только один: требуется поддержка в трекере (как минимум возможность пользователю быть участником нескольких проектов).

3. Передача задач из проекта в проект

Этот способ мы считаем альтернативным предыдущему. У него есть ряд преимуществ, но, к сожалению, и недостатки. Выглядеть это может так:

Давайте сначала рассмотрим плюсы этого подхода:

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

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

Из недостатков можно отметить то, что не все трекеры поддерживают изменение команд/проектов в задаче. 

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

Итогом можно отметить, что в ряде конкретных сценариев этот подход хорош, а в других, может быть неуместен.

Выводы такие:

Плюсы:

• Простота и наивность “процесса”;

• Не страдает аналитика и статистика;

• Не требуется сложная настройка;

• Очень хорошо подходит для задач, которые повторно не возвращаются в команды (поддержка, администрирование, маркетинг).

Минусы:

• Требуется поддержка трекером;

• Не подходит для “постоянно путешествующих задач”, например, взаимодействия архитекторов и разработчиков, если они участники разных команд.

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

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

Спасибо за внимание! Желаем вам простого, качественного, прозрачного учета и высокой эффективности. Тратьте больше времени на созидание!