«Позови меня тихо по имени» или общение на удаленке глазами разработчика

Задумывались ли вы, что навык общения в чате может быть так же важен для проекта, как и ваши hard-скиллы?

Я по природе эмпатичный человек. Прежде чем отправить сообщение коллеге, я всегда спрашиваю себя: «Как это прочитает человек по ту сторону экрана? Не заденет ли его что-то в моих словах?». Часто слышу в ответ: «Не усложняй!», «Ты не психолог», «Работа есть работа».

Но что если одно неосторожное «Очевидно же!» в общем чате заставит джуна неделю бояться задавать вопросы?

Меня зовут Саша Голиков, я разработчик в департаменте ‭«1C» в КОРУСе. В этой статье я поделился теми основными принципами осознанной коммуникации, которые помогают мне выстраивать контакт с коллегами. Надеюсь, что эти мысли помогут читателям улучшить атмосферу в своих командах.

При удаленном формате работы в переписке с коллегами вы лишены невербальных сигналов: нет возможности пользоваться языком тела или передать интонацию в сообщении. Представьте, что вам приходит сообщение «Ок» или «Не воспроизводится». Такие сухие минималистичные ответы в первую очередь порождают недопонимание, раздражение и замедляют общение. Давайте разберем, почему подобная сухость опасна (в особенности для удаленного формата работы):

• Усиление изоляции: такие короткие и безличные ответы могут увеличить дистанцию между коллегами. Люди начинают чувствовать себя просто винтиками механизма, а не частью сплоченной дружной команды;

• Потеря контекста: в офисе можно точнее понять коллегу благодаря мимике или быстро переспросить. В чате же зачастую требуется еще один «раунд» переговоров для расшифровки сообщений, а это может замедлить работу;

• Риск неверной интерпретации: фраза «Занят» может быть расценена как нежелание помогать, а «Никогда так не делай» – как отчитывание вместо обычного совета;

• Эффект «холодного» общения: сухие сообщения создают ощущение недружелюбия или незаинтересованности, даже если отправитель просто сосредоточен;

• Сложности адаптации: новым членам команды вдвойне тяжело разбираться в процессах и отношениях, если общение сводится к голым фактам и коротким однозначным ответам.

Теперь давайте на примерах рассмотрим, как можно изменить ответы, чтобы избежать вышеописанных эффектов. Это НЕ про болтливость или снижение технической точности. Это про добавление ясности и человечности:

1. Описание контекста

Вместо: «Не работает»

Лучше: «В базе А под пользователем Б не работает автоматическое создание документа В при нажатии на кнопку Г. Можно воспроизвести на примере документа Д. Вот текст ошибки: (скриншот)»

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

2. Объяснение причин (особенно в отказах или вопросах):

Вместо: «Нельзя так сделать». Лучше: «Предложенный подход А может вызвать проблему Б в будущем из-за ограничений версии платформы. Давай рассмотрим вариант В, он избегает этого риска»

Вместо: «Зачем тебе это?» (может ощущаться как агрессия). Лучше: «Чтобы точнее понять задачу и предложить решение, расскажи, пожалуйста, в какой ситуации тебе нужны эти данные/функционал?»

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

3. Использование «мягких» формулировок:

Вместо: «Ты не прав»

Лучше: «Я понимаю твою логику, но давай проверим случай, когда этот реквизит будет не заполнен. Мне кажется, там может возникнуть проблема при печати» или «У меня есть сомнения насчет типа реквизита, потому что при построении отчета может возникнуть ошибка. Как думаешь?»

Почему: снижает эффект «защитной стойки», фокусирует на проблеме, а не на личности.

4. Ясность намерений:

Вместо: «Посмотри тут» (ссылка на код без пояснений)

Лучше: «Привет! Столкнулся с (описание проблемы) в (указание места). Посмотри, пожалуйста, мою доработку: я добавил обработку случая А в процедуру Б в модуле В. Не уверен, что это лучший способ, хотел бы услышать твое мнение»

Почему: четко говорит, что нужно сделать (проверить код), зачем (решить проблему), какой вклад уже сделан, и что конкретно нужно от коллеги (мнение).

5. Признание неопределенности:

Вместо: Молчание или «Не знаю»

Лучше: «Пока не уверен в причине, но проверяю гипотезу А. Дам знать, как только разберусь, ориентировочно к (время)» или «У меня пока нет полного ответа, мне нужно исследовать кое-что. Обязательно отпишусь, как появится информация»

Почему: управляет ожиданиями, показывает прогресс, дает прозрачность.

Помните: сухой ответ экономит 10 секунд вашего времени, но крадет 10 минут у команды.

Представьте: программист весь день бьется над багом. В 18:30 он наконец пишет в чат: «Фух, пофиксил». И получает в ответ: «Ок». А мог бы увидеть вот такое сообщение: «Вау, @Иван, ты герой! Спасибо, что спас прод! Иди отдыхай - заслужил!». Разница между этими ответами - в 300% мотивации на завтра.

Это не просто вежливость, это важная составляющая общения. Обращения по имени и добрые пожелания повышают удовлетворенность работой, чувство принадлежности к команде, а также готовность помогать коллегам. А вот безликое и пустое «Ок», наоборот, может вызвать стресс и то самое ощущение «винтика».

Несколько рекомендаций:

1. Старайтесь быть вежливее и как можно чаще обращаться по имени, даже в мелочах.

Вместо: «Задачу сделал, проверяй»

Лучше: «Анна, я сделал задачу, можешь проверить, когда будет удобно. Спасибо!»

2. Добавляйте контекстные пожелания:

Утро: «Привет, Анна! Передаю тебе задачу Х. Хорошего продуктивного дня!»

Обед: «Иван, напиши мне, как вернешься с перерыва. Приятного обеда!»

Конец дня: «Анна, спасибо за оперативность! Хорошего вечера!»

Пятница/предпраздничные дни: «Всем отличных выходных! Вы –большие молодцы!»

Болезнь коллеги: «Иван, передаю статус по задаче. Выздоравливай!»

3. Используйте «эмпатические триггеры»:

Узнали про отпуск коллеги: «Анна, классного отпуска! Ждем фото! :)»

Знаете про сложную задачу: «Удачи в разработке, Иван! Уверен, ты справишься!»

После больничного: «Рады тебя видеть, Анна! Как твое здоровье?»

Но и даже в этом можно допустить некоторые ошибки:

1. Писать в общий чат каждый день одно и то же «Доброе утро». Такое «роботизированное» действие скорее является спамом.

2. Пожелать «отличных выходных» коллеге, которого вы в пятницу вечером загрузили задачами и попросили сделать к понедельнику.

3. Пожелать коллеге-мусульманину «Счастливой Пасхи!». Узнавайте традиции коллег или используйте нейтральные «Хорошего дня/отдыха!».

Помните: написать «@Анна, спасибо! Хороших выходных!» стоит нескольких секунд, но при этом вносит немалый вклад в лояльность.

Публичное признание заслуг – это «эмоциональное топливо» для удаленных команд. Работающие не в офисе сотрудники лишены некоторых микропризнаний ценности своего труда. Никто не скажет «спасибо» на перерыве у кофемашины, а эмоции коллег надежно спрятаны за аватарками. В результате разработчики начинают чувствовать себя просто винтиками в системе, а не ценными участниками.

Итак, что же может помочь внедрить культуру признания? Рассмотрим несколько способов:

• Больше конкретики при похвале. Так вы покажете, что вклад замечен и осмыслен.

Вместо: «Хорошая работа!»

Лучше: «@ИвановИван, архитектура подсистемы получилась очень крутой! Особенно удачно, что большинство методов вынесены в программный интерфейс, это поможет нам сэкономить большое количество часов разработки в будущем! Спасибо!»

• Пишите похвалу не только в личку, но и в общие чаты с упоминанием роли разработчика и задачи. Например, «Благодаря внимательному код-ревью @ИвановИван мы нашли неявную ошибку до того, как она попала в прод. Сэкономили команде потенциальную неделю отладки».

• «Спасибо» от нетехнических ролей. Например, аналитик может похвалить разработчика: «@ИвановИван, спасибо тебе большое! Твоя обработка сократила мою рутину с 4 часов до 10 минут! Ты просто волшебник!». Это станет очень мощным мотиватором для разработчика.

Также хочу «подсветить» возможные ошибки, которые могут произвести обратный эффект:

• Формализм: автоматические «спасибо» каждую пятницу в 17:00;

• Неравенство: хвалить только «звезд», которые решают крупные сложные задачи;

• Невнимательность: похвала за задачу, которую делал другой разработчик («Руководство даже не помнит, что я сделал»).

Помните: самый дешевый способ повысить продуктивность - говорить «спасибо» вовремя и искренне.

Это критически важный аспект, поддерживающий психологическую безопасность и эффективность команды на удаленке. Просто представьте, например, ситуацию, когда программист публично «высмеивает» ошибку коллеги в общем чате – это не просто плохой тон, а серьезная угроза для всей команды. Вместо поиска решения и улучшения кода фокус смещается на унижение человека.

Почему это особенно разрушительно на удаленке:

1. Усиление публичного унижения. Общий чат – это «площадь». Человек не может мгновенно объясниться или отреагировать лично, как в офисе. Он чувствует себя выставленным на всеобщее посмешище без возможности защиты. Стыд усиливается.

2. Потеря доверия. Коллеги начинают бояться допускать ошибки (что неизбежно!) и скрывать их. Это ведет к более серьезным багам в будущем. Доверие между членами команды разрушается.

3. Фокус на личности, а не на проблеме. Токсичные комментарии «Как можно было такое написать?», «Это же очевидная глупость!» атакуют автора, а не код. Это вызывает оборонительную реакцию, а не желание исправить ошибку.

4. Создание враждебной среды. Люди начинают опасаться задавать вопросы, предлагать идеи или рефакторить код, боясь стать следующей жертвой.

5. Подрыв авторитета код-ревью. Здоровый код-ревью – основа качества. Токсичность превращает его из инструмента улучшения в инструмент запугивания и демонстрации превосходства. Коллеги начинают воспринимать ревью как угрозу.

Общие принципы конструктивной обратной связи (этикет код-ревью):

• Критикуй код, а не человека: фокус на что не так и почему это может быть проблемой, а не на кто это написал;

• Конкретика вместо обобщений: не «код ужасен», а «эта процедура имеет очень высокую когнитивную сложность, предлагаю разбить ее на несколько отдельных»;

• Предлагай решения или альтернативы: не просто указывай на проблему, а помоги найти выход («Может, использовать шаблон X здесь?» или «Есть ли причина не использовать библиотеку Y для этого?»);

• Хвали публично, критикуй наедине (или в соответствующем чате): серьезные замечания лучше выносить в персональный чат или специальный чат ревью, а не в общий. Признание хорошей работы – наоборот, стоит делать публично;

• Используй вопросы вместо утверждений: «Как ты думаешь, что произойдет, если здесь придет null?» звучит менее обвинительно, чем «Ты не предусмотрел null!»;

• Проверь контекст: прежде, чем критиковать, уточни, может быть, это легаси-код или срочный хотфикс, а может, и вовсе автор уже знает о проблеме и чинит ее.

Давайте рассмотрим конкретный пример:

Токсично (в общий чат со скриншотом): «ВАУ! @ИванИванов, посмотри, что ты натворил! Боже, как вообще можно было написать такой костыль? Это же прямая дорога к падению прода!».

Почему плохо: Публичный позор, обвинение личности, унизительные выражения, нет конкретики по исправлению, создает атмосферу страха.

Конструктивно (в личный чат или канал ревью): «Привет, @ИванИванов. В процессе ревью заметил потенциальную проблему в общем модуле А (строка 45): там нет проверки на тип документа. В некоторых случаях это может вызвать ошибку при получении значений реквизитов. Может, стоит добавить условие по типу значения документа? Давай обсудим!».

Почему хорошо: приватно/в уместном месте, фокус на коде, конкретное указание места ошибки, объяснение риска, предложение решений, открытый вопрос для диалога.

Хочу еще раз подчеркнуть, что уважение в критике – ключевой элемент высокоэффективных удаленных команд. Люди должны чувствовать себя в психологической безопасности, чтобы признавать ошибки, задавать «глупые» вопросы и учиться.

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

Если вдруг вы столкнулись с проявлением токсичности по отношению к вам, вот несколько выходов из ситуации:

• Не отвечайте в эмоциональном порыве. Возьмите паузу. Не стоит вступать в открытый конфликт.

• Переведите в конструктивное обсуждение. Напишите коллеге в личном чате: «Спасибо, что заметил ошибку. Давай обсудим, как лучше ее исправить?».

• Обратитесь за поддержкой. Если критика явно токсична и публична, сообщите о сложившейся ситуации тимлиду.

Высокое техническое мастерство не оправдывает токсичное поведение. Настоящий профессионализм разработчика на удаленке проявляется не только в умении писать чистый код, но и в уважительном взаимодействии с коллегами, даже когда находишь их ошибки. Культура конструктивного код-ревью, где ошибки рассматриваются как возможности для улучшения кода и обучения, а не как повод для унижения, – это залог долгосрочного успеха, устойчивости и психологического комфорта всей удаленной команды.

Помните: код можно переписать. Доверие – сложнее.

С какими проблемами может столкнуться разработчик в ситуации, когда ему необходима помощь? На мой взгляд, одни из самых неприятных ошибок от более опытных коллег:

• Раздражаются на «базовые» вопросы («Как это можно не знать?»);

• Экономят время в ущерб объяснениям («Просто скопируй этот код, не вникай»);

• Не видят прогресса коллег-джунов («Он уже месяц не может разобраться!»).

Подобное отношение может привести к тому, что разработчик:

• Не перенимает опыт, так как не видит, как опытные коллеги решают задачи и не может подсмотреть подходы.

• Боится спросить что-либо, так как будет ожидать неприятной реакции вместо получения необходимой помощи.

• Выпадает из контекста без обмена мнениями по разным задачам.

В конце концов младшие разработчики перестают проявлять какие-либо инициативы, могут вообще уволиться из-за отсутствия менторской поддержки, а старшие разработчики могут потратить несколько часов на исправление «костыля» джуна и разгребание последствий вместо того, чтобы в свое время потратить 30 минут на объяснения.

Приведу несколько практических советов, которые помогут построить культуру поддержки.

Для опытных разработчиков:

1. Замените «Это очевидно!» на «Давай разберемся».

Вместо: «Ты что, не знаешь, как работает соединение в запросах?»

Лучше: «Иногда соединения бывают сложноватыми для понимания! Вот шпаргалка + давай созвонимся, покажу на примере»

2. Принимайте незнание как норму. Каждый из нас когда-то был новичком, поэтому необходимо спокойно к этому относиться.

3. Старайтесь критично относиться к собственной помощи. Если, например, джун задает один и тот же вопрос больше 3 раз, возможно, проблема не в нем, а в вашем объяснении.

Для тимлидов и команды в целом:

1. Внедрите «менторские часы». Например, каждый опытный разработчик 2-3 часа в неделю выделяет на помощь джунам. Это может сократить время их время адаптации, а также ускорить развитие.

2. Создайте «безопасные» каналы для вопросов. Например, закрытый чат «Тупые вопросы», где запрещены насмешки. Даже опытные разработчики иногда впадают в ступор с каким-нибудь банальным моментом.

3. Хвалите публично, корректируйте приватно:

В общем чате: «Отличная работа, @ИвановИван с оптимизацией запроса!»

В личке: «Обнаружил ошибку в твоем коде, давай по возможности обсудим»

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

Помните: на удаленке сильные команды строят не гении-одиночки, а наставники, готовые делиться знаниями без упреков.

Все, что описано выше:

— Не про «вежливость», а про профилактику выгорания;

— Не про «лишние слова», а про ускорение работы (меньше ошибок – меньше переделок);

— Не про менторство, а про устойчивость команды.

Ваше сообщение с именем, объяснением или благодарностью – это не шум. Это сигнал сквозь цифровой шум, который кричит: «Ты – не безликий винтик. Ты – человек». Помните: в мире, где код живет в облаках, а коллеги – за тысячу километров, только одно важно: чувствует ли человек себя увиденным.