Коммуникация: советы для разработчиков

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

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

Умение хорошо взаимодействовать является навыком

Люди могут в это не верить или могут этого не осознавать, однако эксперты полагают, что отсутствие возможности взаимодействовать с людьми часто приводит к отсутствию и карьерного роста.

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

Почему коммуникация столь важна?

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

Говоря о коммуникации, мы не имеем в виду, что вам нужно непременно социализироваться или начинать день с разговоров с вашими коллегами, касающихся планов на выходные, либо с подробного перечисления того, чем вы вчера занимались. Естественно, если ваши коллеги не возражают, вы можете именно так и начинать разговор, однако суть далеко не в этом. Чтобы стать хорошим членом команды, не требуется дружить с вашими коллегами, просто достаточно быть хорошим человеком.

Коммуникация среди сотрудников команды

Наша цель – выяснить, как общаться с нашими коллегами таким образом, чтобы:

- они имели возможность высказывать свое мнение;

- выражать к ним всегда уважение, вне зависимости от их возраста или чего-то еще;

- не запугивать коллег;

- оказывать им помощь в том, чтобы они могли совершенствоваться в своей работе.

Общение в конфликтной ситуации

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

Наиболее сложными ситуациями являются просмотры пул-реквестов. Они могут стать довольно пугающим опытом, в особенности для разработчиков-джуниоров. Такой сценарий конфликтных ситуаций распространен сегодня довольно сильно даже в open source сообществах, из-за чего многие программисты предпочитают не участвовать в Open Source.

Зачем делаются ревью пул-реквестов?

Среди распространенных причин проверки пул-реквестов:

- определение багов до того, как они попадают в основную ветку;

- предложение улучшений, а также обсуждение изменений;

- изучение чужого кода, возможность узнать об актуальном состоянии кодовой базы.

Некоторые разработчики совершенно упускают из виду те цели, которые они должны преследовать во время проверки кода других разработчиков. Да, таких разработчиков меньшинство, но все же они встречаются. Есть и те люди, которые прекрасно осознают саму идею ревью, однако их реализация данной идеи совершенно неправильная. И вы тоже наверняка за свою карьеру совершите множество ошибок, осознавать которые вы начнете уже по мере накопления вашего опыта.

Необходимо задавать вопросы

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

Пример. Допустим, вы хотите указать на возможность улучшить производительность. Комментарий этот вы можете сформулировать либо как вопрос, либо как приказ. Приказ: «Ты должен оптимизировать это». Вопрос: «Для данной части рабочего процесса критически важным значением обладает производительность. Возможно, этот алгоритм стоит оптимизировать? Возможно, есть смысл использовать цикл for, а не for-Each?». Понятно, что второй вариант окажет лучшее влияние на пул-реквест.

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

Речь не идет о том, чтобы стать «милым»

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

Прежде всего, советуем помнить:

- ваш коллега исходил из лучших побуждений;

- вы не имеете перед глазами контекста, а работаете только с маленьким diff;

- вы можете чего-то не знать и научиться на примере этого кода.

Не говорите «ты», говорите «мы»

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

Работа в команде

Старайтесь пересматривать свое отношение. Одна из главных проблем современных программистов – то, как они относятся к людям. Порой единственное, что волнует программистов – их работа. Из-за такого подхода они начинают думать, что их работа сама по себе характеризует их достаточно. Они могут злиться на коллег из-за того, что их коллеги не столь хороши, как они сами. Они могут не говорить комплиментов, боясь, что комплименты унижают их самих. При этом такие люди еще и всегда уверены в собственной правоте. В результате все приводит к гонкам и конкуренции, а это уже ведет к токсичности рабочего окружения. Если все сказанное – про вас, тогда вам необходимо пересмотреть ваше отношение к окружающим вас людям.

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

Вы пишете код – он ваш? Скорее всего, не ваш. Тогда и не привязывайтесь к коду, старайтесь избавляться от ощущения, что это код ваш (исключение составляет случай, когда вы являетесь собственником компании).

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

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

Решение конфликтов в команде

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

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

Коммуникация между программистами

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

Прежде всего, предпочтительнее небольшой размер. Нужно стараться делать самые по возможности мелкие пул-реквесты и отправлять их часто. Конкретных цифр мы не приводим, потому что это довольно сложная тема. Но если пишется HTML-код, то размер diff уже будет гораздо больше, нежели в коде на CSS или Javascript. Просто лучше стараться придерживаться разумного размера.

Ревью старайтесь делать как можно раньше. Лучше, если они вообще с самого старта начинаются! Если ревьюер будет оставлять 30 комментариев на каждый пул-реквест, то обсуждать эти изменения и исправлять их будет достаточно сложно. А вот если вы предоставляете ревьюеру возможность проводить проверку небольших отрывков кода, то все уже будет намного проще.

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

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

Поверяйте ваш код своими силами. Читайте и проверяйте ваши diff до того, как делать коммит. Если у вас в компании присутствуют некие стандарты и соглашения, необходимо убедиться, что ваш код отвечает им.

Заключение

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

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

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