Общий язык не появляется сам

Вместе с Иваном Удовиным я занимался подготовкой So Stuffy — команды по спортивному программированию. На таких соревнованиях участникам нужно находить решения алгоритмических задач и превращать их в работающие программы. В моей части подготовки была вполне конкретная работа: помочь человеку изложить ход мысли так, чтобы товарищ смог его запрограммировать. Отдельного внимания требовали споры внутри команды.

Этот опыт заставляет меня проверять простую вещь: что стало понятно остальным после того, как один участник всё понял сам? Между найденной идеей и общим результатом есть работа, которую легко пропустить. Автор решения уже видит, как всё устроено, и может считать объяснение почти формальностью.

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

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

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

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

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

У руководителя есть соблазн постоянно оставаться переводчиком между всеми. Каждый спор проходит через него, и без его участия работа останавливается. Это может выглядеть как подтверждение важности. Для меня такая зависимость — повод внимательнее посмотреть на устройство общения. Возможно, людям не хватает контекста, который сосредоточен у одного человека.

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

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

Поэтому время на объяснение я считаю частью работы команды. Оно окупается для меня в тот момент, когда участники могут двигаться дальше без постоянного посредника. Чужая сильная сторона тогда становится доступной всем, кто работает рядом.