Почему одна дата не означает одну договорённость
Представьте такую ситуацию.
В понедельник на планёрке руководитель разработки сказал: «К пятнице будет рабочая версия выгрузки отчётов в Excel».
После совещания менеджер по продажам написал клиенту: «В пятницу сможете выгружать отчёты из личного кабинета».
В пятницу клиент открыл сервис. Выгрузки не было. Он написал менеджеру, что функция недоступна.
Менеджер связался с руководителем разработки. Выяснилось: к пятнице подготовили версию для внутренней демонстрации. Затем планировали тестирование, а выпуск для клиентов — только во вторник.
Одна дата — пятница. Но два разных результата: показать функцию коллегам и дать клиенту возможность ею пользоваться.
В какой момент внутренний срок превратился в обещание клиенту — и почему расхождение не заметили раньше?
Что здесь стоит проверить?
Проще всего сказать: «Ну, менеджер просто не уточнил, что значит „рабочая версия“». Возможно. Но давайте посмотрим шире. Одинаково ли сотрудники представляют результат? Все ли важные сведения прозвучали? И кто вообще может обещать клиенту дату выпуска?
Чтобы в этом разобраться, мы обратимся к исследованиям командной работы. Они помогут нам посмотреть на ситуацию с разных сторон и понять, на что стоит обратить внимание.
1. Одинаково ли люди представляют путь к результату?
Кажется, всё упирается в два слова — «рабочая версия». Но посмотрите, что произошло: руководитель разработки говорил о внутреннем этапе работы, а менеджер пообещал клиенту готовую для него функцию.
Между внутренним показом и запуском для клиентов ещё несколько шагов: протестировать функцию и выпустить её. Поэтому важно не просто назвать дату, а уточнить, что именно будет готово к этому сроку и что ещё предстоит сделать.
У исследователей командной работы для этого есть термин — общие ментальные модели (shared mental models). Проще говоря, речь о том, насколько похоже люди представляют задачу, её этапы и то, как зависят друг от друга их действия (DeChurch & Mesmer-Magnus, 2010).
Это не значит, что менеджер должен разбираться во всём коде, а разработчик — помнить каждое письмо клиенту. Важно, чтобы у них совпадало понимание тех частей работы, от которых зависит общий результат.
А как заметить, что мы по-разному понимаем задачу?
Можно провести совещание, выслушать идеи коллег, дополнить предложения друг друга — и всё равно не заметить, что каждый представляет следующий шаг по-своему.
В исследовании 27 студенческих команд участники рассказали, как у них принято обсуждать разногласия.
Исследователи сравнили их ответы с тем, насколько похоже члены команды представляли задачу. Когда учли и другие формы общения, обнаружилась связь: более высокие оценки обсуждения разногласий сопровождались более похожими представлениями о задаче (Van den Bossche et al., 2011).
Что это значит? В нашей истории расхождение можно было бы заметить простым вопросом: «Рабочая версия — для внутреннего показа или для клиента?» За одной датой стояли два разных ожидания.
Что нам это даёт? Прежде чем считать, что команда договорилась, стоит проверить не только согласие со сроком, но и то, что каждый считает готовым результатом.
2. Какая информация не попала в общее решение?
Но даже если участники одинаково понимают план, у них может быть разная информация.
Возьмём другой вариант нашей истории.
Менеджер по продажам и руководитель разработки оба понимают, что клиент получит нужную функцию только после тестирования. Но руководитель разработки знает: тестирование может задержаться из-за недоступного оборудования. Менеджер об этом не слышал.
На совещании все обсудили ожидаемую дату запуска, но не затронули риск задержки.
Теперь дело не в разных представлениях о результате. Важная информация в команде есть, но до общего обсуждения она не дошла.
А теперь давайте посмотрим на это со стороны. О чём люди говорят дольше: о том, что знают несколько участников, или о том, что известно лишь одному?
В исследованиях группового принятия решений участники нередко дольше обсуждали то, что знали сразу несколько человек. А сведениям, известным только отдельным участникам, уделяли меньше времени (Mesmer-Magnus & DeChurch, 2009).
В этом варианте истории разницу видно сразу: ожидаемую дату обсуждали все, а о возможной задержке тестирования знал только руководитель разработки.
Получается парадокс: команда может иметь все необходимые сведения, но так и не собрать их вместе для принятия решения (Stasser & Titus, 1985).
Причём проблема не обязательно в том, что кто-то скрывает информацию. Важный факт мог просто не попасть в повестку. А может быть и так: о важном сведении сказали, но при принятии решения его не учли.
Поэтому мало спросить: «Все ли понимают наш план?»
Полезно выяснить ещё кое-что: какая важная информация есть только у некоторых участников — и учли ли мы её, когда принимали решение?
3. Кто и как согласовывает обязательства?
Вернёмся к пятнице. Даже если менеджер по продажам знает все этапы разработки, ему ещё нужно понимать, кто подтверждает дату выпуска. А если её перенесут — кто скажет об этом клиенту?
Но даже если все знают нужные факты, это ещё не значит, что они действуют согласованно.
Важна координация: нужно договориться, кто что делает и как одни шаги зависят от других.
Исследователи Герардо Окхёйсен и Бет Бечки предлагают рассматривать координацию через три связанных условия: общее понимание, предсказуемость действий и ясность ответственности (Okhuysen & Bechky, 2009).
Посмотрим на нашу пятницу с этих трёх сторон. Общее понимание — различают ли сотрудники внутренний показ и запуск для клиентов? Предсказуемость — понятно ли, когда пройдут тестирование и выпуск? Ответственность — известно ли, кто вправе подтвердить клиенту срок и кто сообщит о его изменении?
Например, перед тем как назвать дату клиенту, менеджер может согласовать её с тем, кто отвечает за выпуск. А если сроки изменятся, заранее понятно, кому об этом сообщить и кто свяжется с клиентом.
Мы начали с одной пятницы и двух разных ожиданий. Сначала посмотрели, почему важно одинаково понимать не только дату, но и путь к результату. Потом — как важные сведения могут не попасть в общий разговор. И наконец — почему даже при общей картине работы людям нужно согласовать, кто принимает решения и за что отвечает.
Так мы пришли к трём направлениям, на которые стоит обратить внимание.
Что с этим делать руководителю?
Вспомните ближайшее обещание клиенту — например, о запуске нужной функции, поставке или готовом отчёте. Прежде чем назвать дату, можно вместе с коллегами проверить три вещи:
- Результат. Что именно клиент получит к этому дню? Какие шаги ещё впереди?
- Информация. Какие важные сведения, ограничения или риски пока известны не всем? Учли ли их в плане?
- Ответственность. Кто подтверждает срок, а кто сообщит клиенту, если планы изменятся?
Конечно, такая проверка не отменит технических сбоев, задержек и прочих сюрпризов. Но она может помочь заранее заметить, где договорённость ещё не сложилась.
А то бывает: пятница в календаре у всех одна, а пятниц в планах — несколько.

Перед тем как обещать клиенту срок
Одна дата ещё не означает, что все договорились об одном результате.
Я подготовил раздатку с тремя вопросами: о результате, важной информации и ответственности. Она поможет структурировать разговор с коллегами перед тем, как обещать клиенту срок.
Научная кухня для любознательных
Источники
DeChurch, L. A., & Mesmer-Magnus, J. R. (2010). The cognitive underpinnings of effective teamwork: A meta-analysis. Journal of Applied Psychology, 95(1), 32–53. https://doi.org/10.1037/a0017328
Mesmer-Magnus, J. R., & DeChurch, L. A. (2009). Information sharing and team performance: A meta-analysis. Journal of Applied Psychology, 94(2), 535–546. https://doi.org/10.1037/a0013773
Okhuysen, G. A., & Bechky, B. A. (2009). Coordination in organizations: An integrative perspective. Academy of Management Annals, 3(1), 463–502. https://doi.org/10.5465/19416520903047533
Stasser, G., & Titus, W. (1985). Pooling of unshared information in group decision making: Biased information sampling during discussion. Journal of Personality and Social Psychology, 48(6), 1467–1478. https://doi.org/10.1037/0022-3514.48.6.1467
Van den Bossche, P., Gijselaers, W., Segers, M., Woltjer, G., & Kirschner, P. A. (2011). Team learning: Building shared mental models. Instructional Science, 39(3), 283–301. https://doi.org/10.1007/s11251-010-9128-3
















