Как решить проблемы межотдельской коммуникации: налаживание обмена информацией и эскалации
Когда работа между отделами стопорится, сначала найдите пробел. Не дошла ли информация до тех, кому она нужна? Получили ли они ее, но поняли иначе? Или все понимают проблему, но никто из участников не может принять необходимое решение? Очередное напоминание может помочь в первой ситуации. Однако оно не способно прояснить неоднозначный результат или дать разрешение на изменение обязательств.\n\nНачните с одной совместной задачи. Сохраняйте актуальную запись о ней там, где ваша команда уже привыкла работать, опишите, что изменилось и кого это касается, а также укажите, какой ответ вам требуется. Если нерешенный вопрос выходит за рамки полномочий участников, направьте это же описание по установленному маршруту эскалации. Это практичная отправная точка, позволяющая обойтись без внедрения новых встреч или ПО.
Найдите место сбоя после фразы «Я уже отправил(а)»
Рассмотрим наглядный пример: команда дизайна переносит сдачу графических материалов для мероприятия со среды на четверг. Операционный отдел продолжает планировать их проверку на среду, поскольку обновление появилось только в канале дизайнеров. Непосредственная проблема здесь — распространение информации. Отправьте сообщение об изменении тем, чья работа от него зависит, прикрепив ссылку на актуальную запись.
Теперь представьте, что операционный отдел увидел сообщение, но посчитал, что «готово» означает уже утвержденные материалы, тогда как дизайн имел в виду первый черновик. Здесь требуется уточнить критерии готовности результата. В третьем варианте обе команды знают, что из-за переноса остается слишком мало времени на проверку, но ни одна из них не может сдвинуть само мероприятие. Это проблема принятия решений. Если во всех трех случаях списать всё на нежелание сотрудничать, это лишь усложнит дальнейший диалог и не поможет определить следующие шаги.
Разберите реальную задержку с помощью тех же вопросов. Изучите само сообщение, предполагаемого получателя, обещанный результат и нерешенное решение. Отделите то, что зафиксировано в фактах, от ваших предположений о чьих-либо мотивах.
Храните актуальный итог в одном доступном месте
Используйте существующий документ проекта или задачу, чтобы зафиксировать результат, согласованную дату, ответственного и зависимости. Когда что-то меняется, опишите разницу: «Утвержденные изображения переносятся со среды на четверг. Текст без изменений. У операционного отдела теперь на один день меньше для проверки». Это дает следующему сотруднику основу для действий без необходимости восстанавливать всю историю переписки.
Тред в чате может привлечь внимание, а короткий разговор — устранить неопределенность. Зафиксируйте полученный итог обратно в общей записи. В публичном руководстве по коммуникации GitLab описано документирование решений, принятых офлайн; их практика служит полезным примером того, как сохранять решения доступными для поиска. При этом правила доступа вашей организации по-прежнему определяют, кто может видеть материалы. Общая запись не означает, что документ должен быть общедоступным для всех подряд.
Запрашивайте именно тот ответ, который действительно необходим для работы
Некоторым получателям нужно просто быть в курсе. Другим необходимо подтвердить скорректированные обязательства. Лицу, принимающему решения, может потребоваться выбрать один из вариантов. Добавление всех подряд в копию с припиской «к сведению и для поддержки» оставляет эти разные зоны ответственности размытыми.
Сделайте запрос конкретным: «Пожалуйста, подтвердите, позволит ли получение утвержденных изображений в четверг завершить проверку к утру пятницы. Если нет, укажите, сколько времени или каких вводных данных не хватает». Установите срок ответа с учетом последующих зависимостей и рабочих часов. Подтверждение от каждого получателя не требуется, если никому из них не нужно менять свою работу.
В руководстве Atlassian по коммуникации с заинтересованными сторонами исполнители отделяются от тех, на кого работа влияет, а затем определяются необходимая информация, каналы связи и периодичность обновлений. Примените это разделение к текущему проекту. Регулярные обновления полезны, когда условия постоянно меняются; для стабильной же зависимости может потребоваться уведомление только в том случае, если меняются согласованные условия.
Эскалируйте выбор, требующий полномочий
Когда разногласие невозможно разрешить в рамках полномочий команд, обратитесь к установленному маршруту. Предоставьте соответствующему лицу, принимающему решения, суть проблемы, проверенные ограничения, возможные альтернативы и последствия. Сохранить дату мероприятия с меньшим стартовым набором материалов и сохранить все материалы, сдвинув дату мероприятия — это разные решения. Опишите компромиссы, не пытаясь представить предпочтительный для вас вариант как единственный возможный.
Предупредите вторую команду о том, что вы инициируете эскалацию, и точно зафиксируйте суть имеющихся разногласий. Руководство Atlassian по экологичной эскалации рекомендует разобраться в вариантах и проинформировать другую сторону, прежде чем привлекать соответствующее лицо, принимающее решения. Следуйте установленным в вашем проекте правилам по срокам и оценке влияния; предлагаемая внешними регламентами длительность не является универсальным сроком ожидания.
Закрывайте цикл там, где происходит исполнение
После принятия решения обновите исходную запись, указав утвержденный план, лицо, принявшее решение, ответственного за исполнение и срок вступления в силу. Оповестите затронутых сотрудников и четко отмените прежние договоренности. Статус «Просмотрено» подтверждает факт прочтения, но не означает автоматически, что кто-то принял новый результат в работу.
На следующей контрольной точке проверьте, исчез ли сам сбой. Находят ли сотрудники актуальную информацию? Знают ли они, какой ответ от них требуется? Дошло ли решение до нужного человека и началась ли работа по скорректированному плану? Если четкого обновления и одного необходимого обсуждения для этого достаточно, сохраняйте процесс настолько же лаконичным.