Перевод статьи «Tips for Good Communication in Software Development Teams».
Не важно, о чем идет речь: о просмотре пул-реквестов или какой-то другой форме обратной связи – то, как вы это делаете, имеет огромное значение.
Проработав около семи лет разработчиком ПО, я утвердился во мнении, что коммуникационные навыки не менее важны, чем технические.
Мы проводим часы, пытаясь разобраться в новом фреймворке, который «вы просто должны изучить!», но при этом мы довольно редко работаем над улучшением взаимодействия с нашими товарищами по команде.
Коммуникация влияет на людей, поэтому так важно коммуницировать правильно. И это умение не из разряда «хорошо бы его иметь, но в целом это опционально». По этой причине каждый менеджер должен следить за тем, чтобы коммуникация в команде была налажена должным образом.
Умение хорошо взаимодействовать это навык
Люди могут не верить в это или не осознавать этого, но могу сказать по своему опыту: отсутствие умения взаимодействовать с людьми во многих случаях является причиной отсутствия карьерного роста.
Коммуникация это огромная тема, так что я ограничу то, о чем пойдет речь в этой статье. Я не буду говорить о том, как нужно взаимодействовать с людьми, чтобы выглядеть умником или чтобы подготовить важную для вас презентацию, или чтобы лучше подать свой личный проект.
Вместо этого я сосредоточусь на эмоциональном интеллекте и том, как он применим в решении ежедневных задач, в которых коммуникация играет ключевую роль.
Почему коммуникация имеет такое большое значение?
Хорошее взаимодействие это непростое дело для любой команды: на него влияют несколько аспектов, выходящих далеко за пределы написания кода. Мы в первую очередь люди, а не программисты. И поэтому у нас у всех разные личностные качества, воспитание, ценности, культура и язык.
Но несмотря на все различия, которые могут существовать между членами команды, я считаю, что мы можем найти способы общаться и работать более слаженно.
Что я подразумеваю под словом «коммуникация»
Прежде всего, говоря о коммуникации, я не имею в виду, что вам непременно следует социализироваться или начинать свой день с разговора с коллегами о своих планах на выходные и подробного перечисления того, что вы делали вчера.
Если ваши коллеги не возражают, – пожалуйста! Но суть не в этом. Чтобы быть хорошим членом команды, вам не нужно дружить с коллегами, вам просто нужно быть хорошим человеком.
В этой статье мы поговорим о том, как коммуницировать с коллегами таким образом, чтобы:
- давать им возможность высказывать свое мнение,
- выражать уважение к ним, независимо от старшинства (или чего-либо еще),
- не запугивать их,
- помогать им (и себе тоже) совершенствоваться в своем деле.
Коммуникация в конфликтных ситуациях
Мы, программисты, по нескольку раз на день участвуем в обсуждениях разных вещей, и порой это приводит к конфликтам. Давайте рассмотрим несколько распространенных сценариев из нашей повседневной жизни и то, как хорошая коммуникация приводит к созданию лучшей и более здоровой рабочей обстановки. А исходя из моего опыта, более здоровая рабочая обстановка также является и более эффективной.
Самые сложные ситуации, в которые я попадал за время своей карьеры, это определенно просмотры пул-реквестов. Это может быть очень пугающим опытом, особенно для разработчиков-джуниоров.
К сожалению, подобный сценарий конфликтных ситуаций довольно распространен даже в крупных и известных open source сообществах, из-за чего многие программисты воздерживаются от участия в Open Source.
Зачем мы делаем ревью пул-реквестов?
Распространенными причинами для проверки пул-реквестов являются следующие:
- выявление багов до попадания их в основную ветку,
- предложение улучшений и обсуждение изменений,
- чтобы изучать чужой код и быть в курсе актуального состояния кодовой базы.
Мне приходилось встречать разработчиков, которые совершенно упускали из виду суть и цель проверки кода других разработчиков. Таких, конечно, меньшинство, но тем не менее.
Большинство людей, с которыми мне доводилось работать, прекрасно понимали саму идею ревью, но их реализация этой идеи была совершенно неправильной. И я тоже этим грешил.
За свою карьеру я совершил массу ошибок, которые начал осознавать только по мере накопления опыта. Когда ты по сути еще ребенок, знающий все о последнем фреймворке, это классно, но несколько туманит голову.
После нескольких лет работы, размышлений, исследований и, вероятно, просто повзрослев, я обнаружил несколько вещей, изменивших мое отношение к коллегам и – особенно – к коду, с которым я работаю.
Нужно задавать вопросы
Ревью и технические споры всегда связаны с некоторой нервозностью, но мы можем попытаться ее минимизировать.
Прежде всего, я считаю, что каждый должен поступать следующим образом. Если вы думаете, что по какому-то вопросу может быть и другое мнение, – всегда выражайте свои сомнения в виде вопроса.
Возьмем пример. Скажем, вы хотели бы указать на возможность улучшения производительности. Этот комментарий можно сформулировать двумя способами:
- в виде вопроса
- в виде приказа.
Приказ
Вопрос
Как думаете, какой вариант оказал бы лучшее влияние на ваш пул-реквест?
Рассмотрим другой пример:
Приказ
Вопрос
В чем разница между этими двумя подходами?
- Используя приказной стиль, ревьюер предполагает, что он уже знает, что автор кода пытался или не пытался сделать. Он не предлагает лучшего способа сделать это или какого-либо решения на основе своих знаний. Это вам никого не напоминает? Думаю, да…
- Используя вопросительный стиль, ревьюер запрашивает разъяснения, не предполагая, что уже все знает о коде. Также он предлагает решение, не отвергая альтернативные аргументы.
Речь не о том, чтобы быть «милым»
Приведенные советы могут навести вас на мысль, что я предлагаю лгать или строить из себя добрячка перед коллегами. Вовсе нет. Я советую вам давать вашим коллегам возможность извлечь выгоду из сомнений и дать им шанс выразить свою точку зрения на свой собственный код.
В общем, я бы посоветовал вам помнить, что:
- ваш коллега действует из лучших побуждений,
- у вас нет контекста, вы работаете с маленьким diff,
- вы даже можете не знать чего-либо и научиться на этом примере.
Не «ты», а «мы»
Никогда в таких ситуациях не употребляйте местоимение «ты». Вместо этого говорите о коде как о продукте команды, а не отдельных людей.
- Если вы будете использовать «ты», автор кода скорее примет комментарии на свой счет.
- Используйте местоимения «мы», «наш». Всё должно быть ответственностью команды, а не отдельного человека.
Пересматривайте свое отношение
Самая большая проблема, с которой я сталкивался, работая с сотнями программистов, это их отношение к людям. У меня тоже была такая проблема. Порой единственное, что людей волнует, это работа, и в результате такого подхода им кажется, что работа сама по себе достаточно их характеризует.
- Они злятся на коллег за то, что те не так хороши, как они сами.
- Они не говорят комплиментов их опасений, что это их как-то унизит.
- Они всегда уверены в своей правоте.
В результате все сводится к конкуренции и гонкам, а это рецепт токсичного рабочего окружения. Если сказанное относится и к вам, пересмотрите свое отношение к людям.
- Выражайте признательность. Никто не говорит, что нужно ежедневно осыпать всех комплиментами, но не забывайте поблагодарить людей, когда считаете, что они хорошо выполнили свою работу, или когда заметите улучшение в их навыках. Люди любят комплименты, а комплименты бесплатны.
- Код, который вы пишете, – ваш? Скорее всего, нет. Не привязывайтесь к коду и старайтесь избавляться от чувства, что он ваш (конечно, кроме случаев, когда вы собственник компании).
- Иногда побеждайте. Иногда проигрывайте. Перестаньте стремиться к тому, чтобы всегда выглядеть (и быть) правым. Программисты любят быть правыми и свою правоту могут доказывать часами. Но иногда лучшее, что можно сделать, это выйти из дискуссии без того, чтобы казаться правым.
- Вы не написанный вами код. Ваш код это не то, что вы есть, он не представляет ваш интеллект или ваши человеческие качества. Иногда комментарии коллег могут быть обидными. Порой это будет справедливо, порой – нет, но не воспринимайте это как личную обиду.
Разрешайте конфликты как команда
Если у вас возник конфликт с коллегой, очевидная стратегия – поговорить и решить все вопросы между собой. Но все мы знаем, что зачастую это неподходящий вариант, поскольку каждый из вас свято верит, что правда на его стороне.
Однако дело в том, что это проблема не только вас двоих, это проблема всей команды. Это та ситуация, когда решение должны принимать демократическим путем все члены команды.
- Поставьте свою команду в известность о наличии конфликта.
- Обговорите ситуацию и примите решение, которое устроит всех.
- Сделайте решение стандартом для всех последующих аналогичных случаев.
Сделайте так, чтобы ваш код было легко проверять
Теперь давайте рассмотрим, как можно улучшить коммуникацию со стороны автора кода. Вот список того, что может помочь ревьюерам, особенно ворчунам:
- Маленький размер предпочтительнее. Делайте как можно более мелкие пул-реквесты и отсылайте их часто. Не буду приводить конкретных цифр, это сложная тема. Если вы пишете HTML-код, размер diff будет намного больше, чем в коде на Javascript или CSS. Просто придерживайтесь разумного размера.
- Ревью лучше делать раньше, чем позже. Пускай ревью начинаются с самого старта! Если ревьюер оставит 30 комментариев на один пул-реквест, обсуждать и исправлять изменения будет сложно. А если вы дадите возможность ревьюеру проверять маленькие отрывки кода, все будет гораздо проще.
- Документация. Предоставляйте документацию и комментируйте собственные пул-реквесты, чтобы пояснить части, которые, по вашему мнению, может прокомментировать ревьюер. Разные части рефакторинга разносите по разным тикетам, чтобы ревьюер лучше понимал границы и ход ваших мыслей.
- Обращайтесь за помощью. Если сомневаетесь, попросите о помощи или спросите мнение коллеги, прежде чем отправлять пул-реквест. Большинство людей любят помогать другим, как бы они ни были заняты.
- Поверяйте свой код самостоятельно. Почитайте и проверьте ваши diff, прежде чем сделать коммит. Если в вашей компании есть какие-то стандарты и соглашения, убедитесь, что ваш код им соответствует.
Заключение
Большинство «сложных» программистов, с которыми я работал, не имели плохих намерений. Они были невероятно увлечены своим делом, а это, пожалуй, причина №1, по которой у нас бывают конфликты с коллегами.
Сфера технологий, несомненно, страдает от повышенной токсичности, и многие люди прикладывают к этому руку тем или иным способом. Твиты, форумы, GitHub-ревью – я все это наблюдаю ежедневно. Но программисты по большей части не являются изначально плохими людьми. Просто мы очень специфический подвид рабочей силы: нам действительно не все равно.
Конечно, следование этим советам не предотвратит появление конфликтующих мнений в команде. Конфликты это часть нашей работы, они всегда будут существовать. Но благодаря эффективной коммуникации мы имеем возможность свести их к минимуму или (что даже лучше) более умело управлять ими. В результате мы сможем работать в более эффективной, мирной и здоровой атмосфере.
Наконец, когда члены команды способны сопереживать друг другу, у них повышается производительность, они лучше учатся и выпускают отличные продукты, да и вообще это помогает получать удовольствие от работы.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]