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