Рабочие команды постоянно коммуницируют друг с другом, чтобы выполнять запросы бизнеса. Если взаимодействие выстроено неправильно, задачи сыплются хаотично, сотрудники не понимают, что важнее, — в итоге рушатся процессы, а бизнес получает результат позже, а иногда и хуже.
Привет! На связи команда Kaiten. Наши клиенты часто сталкиваются с ситуациями недопонимания между командами. Расскажем, как можно выстроить взаимодействие отделов в разных сценариях коммуникации.
В компаниях есть три типа взаимодействия команд: горизонтальное — между командами на одном уровне, вертикальное — от команды руководителей к командам подчиненных, межсервисное — коммуникация нескольких команд с одной другой (сервисной). Рассмотрим, как решать проблемы коммуникации в каждом случае.
Горизонтальное взаимодействие. Что делать, если дисконнект у команд, которые работают на одном уровне
Горизонтальное взаимодействие — паттерн, когда одна команда передает наработки другой, та передает следующей и так по цепочке. Дизайнер нарисовал изображения для сайта и дальше передал команде, которая заверстает это на странице.
Бывает так, что 80% работы, которую делает одно подразделение, оно передает для дальнейшего использования другому. Дальше наработки должны пройти через все отделы, чтобы получилась готовая фича или выполненный клиентский запрос. При такой коммуникации всегда есть уточнения, и чем больше подразделений, тем больше вопросов, которые нужно решать.
Кто может помочь в выстраивании коммуникации
Наименьший общий руководитель — это руководитель отдельного департамента или даже генеральный директор, который отвечает за всю цепочку реализации. Ему подчиняются подразделения, через которые сквозным образом проходят задачи.
Service delivery manager (SDM) — отдельный специалист, который отвечает за поставку и налаживание процессов. Он не всегда явно обозначен этой должностью, эту роль может занимать, например, генеральный директор, операционный руководитель или начальник по производству.
Есть четыре основных шага, чтобы выстроить коммуникацию между горизонтальными командами:
Шаг 1. Выровнять приоритеты. У стыкуемых команд должны быть задачи, которые можно передавать друг другу, не меняя их. Например, цель разработчиков — написать код, тестировщиков — проверить функциональность. Это две разные задачи на уровне команд, но они могут быть частями одного клиентского запроса.
Стоит организовать процесс так: для всей цепочки формулировать задачи на языке клиента и добавлять к ним подзадачи — например, чек-листами внутри команд. Если есть цель разработать регистрацию на сайте, ее подзадачи — реализовать авторизацию на фронтенде, соединить с алгоритмом на бэкенде, протестировать.
Чтобы выстроить такой процесс в трекере, нужно соединить отдельные Канбан-доски команд в одну и создавать там клиентские задачи для каждой команды. Тогда все подзадачи будут связаны между собой и прогресс будет легко отследить.
Шаг 2. Согласовать равномерное планирование задач. В горизонтальной цепочке команд почти всегда есть узкое звено: отдел, который работает медленнее всего. Например, разработчики разрабатывают фичи дольше, чем аналитики пишут, а тестировщики проверяют. Получается так, что работа скапливается у разработчиков. Если в этот момент аналитики наберут много задач, они всё равно не будут завершены, потому что упрутся по цепочке в разработчиков.
Важно брать ровно столько новых клиентских запросов, сколько может реализовать вся система, и определять это количество по самому медленному звену.
Полезно для каждой команды в цепочке ограничивать количество незавершенной работы: задачи распределятся более равномерно между и не будут скапливаться в узком звене. У команд появится свободное время, которое можно потратить с пользой.
Шаг 3. Занять высвободившиеся подразделения правильными задачами. Здесь работает простое правило: если не можете помогать, займитесь налаживанием своих процессов. Можно навести порядок в документации, сделать рефакторинг или улучшить качество выполнения текущих задач. Так повысится общий уровень качества в системе.
Шаг 4. Выстраивать коммуникацию поэтапно. Сразу пытаться организовать взаимодействие всех в цепочке практически невозможно, лучше действовать последовательно. Если сейчас основная проблема — взаимодействие разработчиков и тестировщиков, нужно в первую очередь состыковать эти команды, а потом добавить в систему аналитиков и по частям собрать общую цепь взаимодействия (value stream).
Вертикальное взаимодействие. Как действовать, если задерживается большая задача, которой занимаются несколько команд?
Вертикальное взаимодействие — паттерн, когда в рамках большого проекта команды решают более мелкие задачи. Например, вы открываете магазины по всей России. В процессе открытия участвуют разные подразделения. Они ответственны за свою зону работ и делают небольшие задачи для того, чтобы этот магазин открылся.
В вертикали работа может выглядеть так: сначала одна команда изучает 10 локаций и выбирает площадку для торговой точки, далее работают юристы, которым нужно заключить пять договоров на обслуживание выбранной локации. Когда всё готово, задача переходит на следующий этап — начинается стройка.
Таким образом, для каждой команды задача ограничивается конкретным аспектом, а не созданием целого магазина. При этом подразделение может параллельно работать над задачами по открытию нескольких магазинов: искать локации в разных городах, готовить документы для нескольких будущих магазинов.
Получается двухуровневая система:
1-й уровень — уровень магазина и жизненный цикл того, как открывается магазин. Этот уровень наблюдают руководители проекта.
2-й уровень — команды с операционными задачами на уровне выбора локаций, ремонта, подбора сотрудников.
В случае вертикального взаимодействия команд есть два ключевых решения для налаживания коммуникации и процессов.
Назначить главного руководителя. У каждой команды есть свой руководитель: директор команды развития, которая ищет площадки, начальник юридического подразделения. При этом руководители — главные в своей команде, но на верхнем уровне они — исполнители. Чтобы эффективно использовать ресурсы команд, нужен самый главный человек — например, директор по развитию сети, который будет следить за процессами на уровне открытия магазинов и обсуждать способы ускорить процесс создания филиала на встречах с лидерами отдельных команд.
Смотреть на приоритеты. В вертикальном взаимодействии главное — верхнеуровневая задача. В нашем примере это открытие магазина. Для бизнеса важно открыть филиал в новом городе, а не выбрать площадку или подписать договор. Именно поэтому следить за выполнением всех задач нужно на верхнем уровне.
В формате Канбан-досок это будет выглядеть так: есть верхнеуровневая доска, на которой собраны задачи по открытию филиалов. В ней отображаются общие статусы — например, в Краснодаре и Иркутске идет этап подбора локации. У команд второго уровня свои доски: на них задачи могут перемешиваться — рядом будут цели по заключению договоров в Кемерове и Ярославле.
Общий темп выполнения задач определяется на верхнем уровне: именно там нужно ставить лимиты на количество задач.
Ограничивайте не количество локаций, которые ищет команда развития, а число магазинов, которые в данный момент находятся на стадии поиска локации. Размер лимита при этом определяется пропускной способностью команд нижнего уровня.
Доска с верхнеуровневыми задачами помогает понять, в каком состоянии находится проект и на чем нужно сконцентрироваться. Если по каким-то причинам продукт тормозит на поздних стадиях, его надо завершать в первую очередь.
Межсервисное взаимодействие. Как коммуницировать, если команды работают по принципу «заказчик — исполнитель»?
Межсервисное взаимодействие — паттерн, когда есть одна команда с четким стеком задач, к которой приходят с запросами коллеги из других команд. Например, к команде биллинга приходят разные проектные группы, чтобы решить проблемы с оплатами у своих клиентов.
Это самый сложный способ организации взаимодействия: чаще всего сервисные команды выполняют заказы от большого количества других отделов и при этом все постоянно от них что-то хотят.
Самостоятельно сервисная команда не может определять приоритеты и сроки входящих задач — она всегда будет виноватой для тех, чьи запросы еще не выполнены. Чтобы решить проблему, нужно договориться на уровне руководителей команд-заказчиков о порядке выполнения запросов. Есть два варианта, как это можно сделать:
Устроить «конкурс красоты». На встрече руководители команд-заказчиков будут продвигать свои запросы и доказывать их приоритетность. Такие обсуждения редко строятся на реальных цифрах и статистике, поэтому напоминают субъективный конкурс красоты. При этом встреча запустит обсуждение, и в конце концов руководители договорятся о порядке выполнения задач.
Провести квотирование. Этот способ поможет избежать постоянных встреч обсуждений. Нужно собраться один раз и определить квоты для каждой команды: например, для B2C-направления можно делать три задачи за период, а для B2B — только две. Лимит квот также определяется обсуждением и может пересматриваться раз в квартал или полгода.
В обоих случаях важно ограничивать общее количество одновременно выполняемых запросов возможностями сервисной команды, так как больше она не выполнит физически.
Вместо выводов
При проблемах в коммуникации команд опирайтесь не на отношение к руководящим лицам, а на статистику: данные смогут наглядно показать, где чаще всего возникают блокировки или медленнее выполняются клиентские запросы.
Чтобы решать трудности на конкретном уровне взаимодействия, разбивайте все коммуникации в компании на отдельные паттерны: определяйте, какие команды связаны горизонтальной цепочкой, какие работают в вертикали, а какие подразделения работают со всеми межсервисно. Когда удалось разделить команды на группы по паттернам, выявляйте проблемы там.
Если вы хотите узнать подробнее о вариантах решения сложностей в каждом типе, смотрите запись нашего вебинара на YouTube.
А если хотите рассказать о своих проблемах во взаимодействии команд и их решении — заходите в комментарии, обсудим вместе.