Наверняка вы не раз попадали в такую ситуацию: срочно нужно что-то уточнить по проекту, звонишь разработчику или менеджеру, а в ответ – тишина. Или хуже того: трубку поднимают, но по голосу сразу понятно, что звонок совсем не к месту. Почему же айтишники так недолюбливают телефонные разговоры? Тут дело не в упрямстве или нежелании общаться. У этого явления есть свои, довольно глубокие причины, как профессиональные, так и психологические. Давайте вместе попробуем разобраться, как устроена коммуникация в разработке, и поищем такой баланс, который устроит всех.
Почему разработчики избегают звонков: профессиональные причины
Для начала стоит понять, чем большинство своего рабочего времени занят разработчик. Это совсем не монотонный набор текста. Их работа требует огромного умственного напряжения, глубокого погружения, того самого состояния «потока». Представьте, чтобы полностью сконцентрироваться и максимально продуктивно работать, разработчику нужно около 10-15 минут. Это то самое «состояние потока». И любая мелочь – звонок, сообщение, даже простой вопрос коллеги – тут же его рушит. Чтобы вернуться, снова понадобится те же 10-15 минут. Выходит, один-единственный звонок легко отнимает 20-30 минут по-настоящему продуктивного времени.
А если таких звонков несколько за день, общая эффективность падает буквально катастрофически. Кроме того, разработка – это работа со множеством тонких деталей: архитектура системы, имена переменных, как взаимодействуют разные части кода. Когда специалист сидит над кодом, у него в голове строится целая, очень сложная ментальная модель всей системы. Звонок же выдергивает его прямо из этого контекста. И после разговора нужно не просто «продолжить работу», а заново собрать в уме всю эту сложнейшую конструкцию.
Это не только неприятно, но и требует серьезных умственных и физических усилий. Да и в целом, IT-работа асинхронна по своей природе. Задачи ставятся, их обсуждают в чатах, фиксируют в системах учета, а разработчик выполняет их в своем собственном ритме, по мере приоритета. Звонок же – это всегда синхронное общение, требующее, чтобы оба собеседника были доступны здесь и сейчас. Это просто ломает привычный для любого айтишника рабочий ритм.
Почему разработчики избегают звонков: психологические причины
Помимо чисто рабочих моментов, есть и вполне человеческие, психологические факторы. Заказчики часто их не учитывают. Во-первых, разработчики привыкли, что каждое решение должно быть где-то зафиксировано. В чате или в задаче всегда остается текст, к которому можно вернуться хоть через неделю, хоть через месяц. А в телефонном разговоре все договоренности существуют только в памяти. Знакомая фраза «Мы же это по телефону обсуждали!» часто повергает менеджера проектов в холодный пот, потому что доказать или опровергнуть что-либо потом практически невозможно.
Еще один момент – время на обдумывание. Письменное общение дает возможность все взвесить, перепроверить, уточнить. А по телефону нужно отвечать сразу. Специалист может не помнить наизусть все нюансы текущей задачи, но от него почему-то ждут мгновенного ответа. Это создает напряжение и ощущение, что тебя поставили в неловкое положение.
И, наконец, стоит признать, что в IT-сфере действительно много людей с интровертными чертами характера. Они часто предпочитают обдуманную письменную переписку спонтанным устным разговорам. Это вовсе не значит, что они не любят людей или избегают общения. Просто их энергия устроена по-другому, и частые, непредсказуемые звонки для них – серьезный источник стресса.
Плюсы созвонов: когда телефон незаменим
Конечно, было бы несправедливо говорить, что звонки не нужны вовсе. У живого общения есть свои неоспоримые плюсы, о которых забывать нельзя. Взять, к примеру, скорость согласования сложных вопросов. Когда нужно обсудить архитектурное решение, выбрать один из нескольких подходов или срочно урегулировать какой-то конфликт, переписка может растянуться на много часов, а то и дней. Пятнадцатиминутный созвон тут легко заменит десятки сообщений. Еще звонки помогают снизить риск недопонимания. В тексте нет интонации, нет эмоций, нет того самого контекста. Сообщение вроде «давайте сделаем так» может быть воспринято и как приказ, и как просьба.
В живом разговоре всегда можно тут же переспросить, уточнить, уловить истинный смысл. Это особенно важно на этапе обсуждения требований, когда любое недопонимание потом выливается в недели доработок. И, конечно, живое общение помогает строить доверие и укреплять отношения. Долгосрочные проекты держатся именно на доверии между заказчиком и командой. Если общаться только через чаты и трекеры, все становится обезличенным. Регулярные созвоны, даже короткие, дают возможность «увидеть» человека, а не просто исполнителя. Это снижает напряжение и делает коммуникацию гораздо более открытой.
Наконец, есть темы, которые лучше обсуждать напрямую. Разговоры о сдвигах сроков, перерасходе бюджета, критических ошибках – такие вещи лучше обсуждать вживую. В письменном виде они часто только нагнетают обстановку: сообщения могут прозвучать как обвинения, а паузы в ответах – как игнорирование.
Минусы созвонов: когда телефон мешает работе
Но у устного общения есть и обратная сторона. Заказчику важно ее понимать.
Самая большая проблема звонков – отсутствие фиксации. Договоренности нигде не остаются. После разговора менеджеру проекта приходится тратить время на то, чтобы записать все итоги и разослать их. Если этого не сделать, очень скоро можно услышать: «мы же договаривались», «нет, я имел в виду совсем другое».
Еще звонки часто нарушают приоритеты. Звонок от клиента или заказчика нередко воспринимается как сигнал «срочно, бросаем все!». Даже если вопрос не требует немедленного решения, он выдергивает специалиста из его текущей задачи, вынуждая переключаться. А это сказывается на общей продуктивности всей команды. И нельзя забывать про невозможность подготовиться.
Внезапный звонок застает врасплох. У разработчика может не оказаться под рукой нужной информации, он может не помнить всех деталей задачи, над которой работал неделю назад. В итоге обсуждение получается неэффективным, а потом все равно приходится доуточнять письменно.
И, конечно, масштабирование. В проекте с одним разработчиком звонки еще могут работать. Но когда в команде пять, десять или двадцать человек, каждый звонок по какому-то частному вопросу отвлекает либо всю команду, либо требует постоянного «перебрасывания трубки». Это просто неэффективно в большой команде.
Как организовать эффективную коммуникацию: золотые правила
Идеальный вариант – не отказываться от звонков совсем, а выстроить такую систему, где всем будет удобно. Вот несколько основных принципов, которые хорошо работают на практике.
- Вместо спонтанных звонков лучше завести регулярные созвоны. Например, ежедневный утренний 15-минутный стендап, чтобы быстро свериться по статусам. Или еженедельный часовой-полуторачасовой созвон для обсуждения планов, демонстрации сделанного, согласования сложных вопросов. Внеплановые звонки – только для по-настоящему критических ситуаций, которые никак не могут ждать до следующей встречи.
- Все важные решения, принятые на любом созвоне, должны быть зафиксированы письменно. Кто-то из участников, обычно это менеджер проекта, записывает: что обсуждали, к чему пришли, кто и что делает, в какие сроки. Это резюме потом отправляется в общий чат или прикрепляется к задаче в трекере. Так исключаются любые разночтения и создается прозрачная история решений. Очень важно уважать время, когда человек глубоко погружен в работу. Если видите, что разработчик давно не появлялся в общем чате, скорее всего, он занят важной задачей. Не отвлекайте его звонком без крайней необходимости. Для срочных вопросов лучше использовать выделенный канал, например, чат с менеджером проекта, который уже сам решит, нужно ли дергать специалиста.
- К созвонам обязательно нужно готовиться. У каждой встречи должна быть четкая повестка – список вопросов, которые планируется обсудить. Это дает всем участникам возможность подготовиться, и сам созвон проходит гораздо более структурированно, не затягиваясь. Повестку, кстати, лучше публиковать заранее, хотя бы за пару часов.
- И, конечно, выбирайте правильный инструмент. Для коротких вопросов, где не нужно показывать экран, подойдет голосовой звонок в мессенджере. А вот для обсуждения интерфейса, показа кода, совместной работы – лучше использовать видеозвонок с демонстрацией экрана (Zoom, Яндекс.Телемост, Discord). Для удаленных команд видеосвязь вообще незаменима: когда видишь собеседника, проще улавливать эмоции и меньше устаешь от общения.
- Хорошо, когда есть разделение ролей. У заказчика обычно один основной контакт – это менеджер проекта или аккаунт-менеджер. Все вопросы и звонки идут через него. Он уже сам решает, что можно решить сразу, где нужен разработчик, а что лучше отложить до планового созвона. Это защищает команду от хаотичных отвлечений, а заказчику дает понятную, единую точку входа.
Особые случаи: когда без частых созвонов не обойтись
Бывают, конечно, и особые случаи, когда без частых созвонов действительно не обойтись. И это нормально, к таким периодам нужно быть готовым.
Например, на этапе прототипирования и согласования дизайна. Когда обсуждаются интерфейсы, пользовательские сценарии, визуальные решения, текстовое общение становится малоэффективным. Здесь нужно показывать экраны, комментировать, тут же видеть реакцию. На таком этапе нормально, если созвонов будет несколько в неделю. После того как прототип утвержден, их частота, конечно, снижается.
Или сложные интеграции, технические стыковки. Если ваше приложение должно интегрироваться с внешними системами (скажем, CRM, платежной системой или 1С), то без совместной работы технических специалистов с обеих сторон не обойтись. Тут созвоны нужны по мере возникновения вопросов, а не строго по расписанию.
Ну и, конечно, критические инциденты. Если сайт или приложение внезапно перестает работать, клиенты не могут оформить заказ, данные куда-то пропадают – это та самая ситуация, когда молниеносная коммуникация важнее любых правил. В таких случаях звонки, общие экстренные созвоны, чаты – это просто жизненная необходимость.
Коротко о главном: как договориться с командой о формате общения
Самый надежный способ избежать недопонимания — обсудить правила коммуникации в самом начале проекта, до того как начнется разработка. Вот вопросы, которые стоит согласовать:
- Как часто будут проходить плановые созвоны? Кто участвует? Какая повестка?
- Кто является основным контактным лицом со стороны исполнителя для срочных вопросов?
- В каких случаях допустимы внеплановые звонки?
- Как и где фиксируются итоги созвонов?
- Какой канал связи используется для текущих вопросов (Telegram, Slack, email)?
- В какое время дня лучше не беспокоить разработчиков звонками?
Когда правила прозрачны и согласованы заранее, у заказчика нет ощущения, что от него «прячутся», а у команды — что их «дергают». Коммуникация становится предсказуемой и комфортной для всех.
Вывод. Нелюбовь айтишников к телефонным звонкам – это не блажь, а следствие их работы. Глубокая концентрация требует защиты от отвлечений, а привычка все фиксировать – необходимость для управления сложными проектами. Но это вовсе не повод совсем отказываться от созвонов. При грамотной организации – регулярные, заранее спланированные встречи, четкая повестка, фиксация итогов, понятные роли и каналы связи – устное общение может стать мощным и эффективным инструментом. Главное – договориться обо всем в самом начале и уважать рабочие ритмы друг друга.
