Как уменьшить повторяющиеся споры между зависимыми командами

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

От общих претензий — к точке передачи

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

Для разбора выберите один недавний случай, который обе стороны могут описать. Уточните, какие действия наблюдались, какие решения принимались и на какую информацию опирались участники. Отделяйте наблюдаемое от объяснения: «файл пришёл после согласованного срока» — описание события; «коллеги не ценят нашу работу» — его интерпретация. Объяснения могут быть важны, но их лучше проверять вопросами, а не принимать за установленный факт.

Сделать ожидания видимыми

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

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

Не сводите объяснение конфликта только к личным качествам. В исследовании кросс-функциональных проектных команд, опубликованном в 2016 году, Xiaoyan Huo, Lianying Zhang и Haiyan Guo рассматривали предшествующие факторы межличностного конфликта. Среди факторов, положительно связанных с ним, названы разнообразие внутри команды, неопределённость проектной задачи, различия организационных культур и неподходящее поведение. Это не означает, что любой спор вызван именно ими, но напоминает: неясность задачи и различия рабочих норм тоже заслуживают внимания.

Договориться о небольшом изменении

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

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

Проверять результат без обвинений

Через заранее согласованный промежуток обсудите несколько новых передач задач. Стало ли понятнее, что передавать и когда? Где всё ещё возникают задержки или переделки? Не сработало ли правило в исключительных случаях? Смотрите не только на число споров, но и на причины повторных уточнений, ожидания ответа и возвраты результата.

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

Источники

  1. Antecedents of Relationship Conflict in Cross-Functional Project Teams