8 приемов коммуникации для программистов

Кевин Болл — разработчик, ставший коучем. На своих тренингах он фокусируется на навыках коммуникации и лидерства. Также у него есть сайт speakwritelisten.com, где он и опубликовал статью «8 Key Communication Skills for Coders», перевод которой мы вам представляем. Эта статья написана Кевином на основе подкаста JSParty #93, где он и его коллеги — Джерод, Дивья и Феросс — обсуждали приемы, которыми могут пользоваться разработчики в рамках коммуникации с коллегами, заказчиками и пользователями.

Приемы коммуникации

1. Комментарии должны давать читателю контекст кода

Этот пункт отлично пояснил Феросс:

«Комментарии не должны быть на том же уровне, что и код. Безусловно, простое повторение кода не имеет никакой ценности. Я считаю, что комментарии должны быть более высоко- или низкоуровневыми, чем код.

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

Комментарии более низкого уровня тоже имеют смысл. Мне такие попадались. Скажем, у вас есть имя переменной, не описывающее значения. Возможно, у вас функция получает аргумент, а вы не знаете, что именно в нее передается и каковы валидные значения. Перед вами встают вопросы: «Может ли это быть null? Может ли быть undefined?» и т. д. Комментарий, поясняющий такие вещи, я бы назвал более низкоуровневым, чем код. Он сообщает вам детали, которых нет в самом коде».

2. Используйте документацию для объяснения крупного плана картины

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

По словам Дивьи, Vue.js подходит к своей документации совсем иначе:

«Документация Vue была написана так, чтобы служить, по сути, введением в Vue. То есть, вы можете прочесть документацию, и к концу чтения вы хорошо понимаете, как именно все работает.

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

3. Фидбэк и расстановка приоритетов

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

Дивья поделилась отличной техникой под названием «лестница обратной связи», которой она пользуется в Netlify:

«Например, если что-то нужно исправить в рамках PR, ставится приставка «булыжник» («boulder»). Также бывает «гора» («mountain») — огромное изменение, требующее отдельного разговора. Затем идет собственно «булыжник», означающий «Изменение, которое нужно внести до того, как мержить этот PR».

Дальше идет «галька» («pebble») — небольшое изменение, может, стилистическое. И, думаю, «песчинка» («sand») это самый мелкий вариант, часто оставляемый на усмотрение автора кода. Это замечание типа «Делай, как знаешь. Можешь менять, можешь не менять»».

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

Разница в пунктах фидбэка

4. Создавайте быстрые циклы обратной связи с руководством (заказчиками)

Многие из нас имеют печальный опыт: работаешь над чем-нибудь неделю или две, а затем слышишь от начальника (заказчика), что это вообще не то, что он имел в виду.

Джерод предложил простое решение данной проблемы:

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

5. Воспроизводите и суммируйте ваше понимание проблемы

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

В подкасте я объяснил это следующим образом:

«Это не то же самое, что получить указания в письменном виде. Скорее это можно назвать «активным слушанием».

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

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

6. Старайтесь понять цели собеседников

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

Джерод светил основные способы понять цели собеседника:

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

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

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

Активное слушание - прием коммуникации

7. В разговоре отталкивайтесь от слов собеседника

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

Дивья поясняет:

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

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

8. Выясняйте проблемы пользователей, мягко отказываясь от предлагаемых решений

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

Более детально этот пункт осветил Джерод:

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

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

Конечно, вы не обязаны угадывать проблему с первого предложения. Нужно работать с обращениями, чтобы понять, какую именно проблему человек пытается решить. При этом следует вежливо отклонять само решение (ну, потому что решения пользователей очень часто бывают плохи) и предлагать по возможности более очевидный или лучший вариант. Или хотя бы говорить «Я свяжусь с вами и сообщу о способах решения этой проблемы»».

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх