Общение - это наше всё!
Сейчас в сфере IT и не только много говорят о том, как важны так называемые soft skills. Не уверен, что есть какое-то четкое определение этого понятия, думаю, что каждый понимает его по-своему. Но точно можно сказать, что сейчас работа в сфере IT невозможна без эффективного взаимодействия между людьми. Системы, над которыми работают разработчики, постоянно усложняются, поэтому создавать что-то в одиночку становится практически невозможно.В этой небольшой статье я постарался собрать некоторые советы, которые могут помочь в общении на работе, увеличат эффективность выполнения задач, а также просто улучшат атмосферу в коллективе.
1. Пишите в общий чат, чтобы узнать что-то важное
Да, понятно, что какую-то мелочь можно выяснить и в личных сообщениях, но если вы спрашиваете, например, о том, как работает что-то в каком-то сервисе, то:
Эта информация может быть полезна не только вам, поэтому лучше обсудить это в общем чате, чтобы другие люди тоже увидели ее. Плюс вы избавите себя от того, что потом вам будут по очереди писать коллеги и узнавать информацию, которую вам передал человек в личных сообщениях. В связи с этим постарайтесь задать вопрос так, чтобы и человеку, который недостаточно погружен в проблему, было понятно, о чем идет речь.
Человек, который отвечает на ваш вопрос, может не знать все, что вам нужно, может ошибаться в чем-то, поэтому в общем чате его могут поправить или дополнить его ответ.
Обсуждение идет намного медленнее в личных сообщениях, если человек, которому вы пишете, перенаправляет вас к другому человеку по вашему вопросу.
Поэтому считаю, что рабочие вопросы желательно всегда обсуждать в общих чатах. Разумеется, стоит соблюдать какие-то рамки и не писать в чат на 1000 человек по какому-то вопросу, который поймет всего пара человек.
2. Уточняйте, зачем что-то нужно, когда спрашиваете
Когда вы что-то спрашиваете у человека, например "где достать данные о категории товара?", лучше всегда уточнять, зачем это нужно и где хотите использовать.
Человек ответит вам более точную информацию, если будет лучше понимать контекст и о чем идет речь. Если не уточнить, для чего вам эта информация, он может ответить неверно, потому что не поймет, о чем идет речь, и додумает сам.
Может оказаться, что вам вообще не нужно то, о чем вы спрашиваете, а нужно совсем другое, либо есть какой-то более простой способ решения проблемы – человек может об этом знать, а вы нет. Например, вы хотите разработать то, что уже сделано до вас – такое тоже бывает.
Например, вы хотите регулярно доставать какие-то данные из сервиса. Тогда вы можете сильно поднять нагрузку на него, и человек, ответственный за сервис, должен об этом знать.
3. Не предполагайте что-то, не уточнив у другого человека
Например, когда вам нужно воспользоваться каким-то сервисом, вы можете предположить "мне нужна вот эта ручка сервиса", не зная точно, за что она отвечает. Ну вроде бы название и параметры выглядят похоже на то, что мне нужно, воспользуюсь ей. В таком случае могут возникнуть проблемы. А что, если эта ручка не поддерживается? А что, если на самом деле она возвращает не то, что вы предположили?
Прежде чем предполагать что-то, поищите информацию в документации, в похожих сообщениях в чатах и тому подобное.
Если информацию найти не удалось, всегда лучше лишний раз уточнить ее у человека, который отвечает за сервис, к тому же иногда он может вам рассказать какие-то детали, о которых вы не знали.
4. Не бойтесь задавать вопросы
Считаю, что это очень большая проблема IT-специалистов и студентов. Да, к сожалению в работе попадаются токсичные люди, к которым не хочется обращаться за вопросом, либо просто не хочется показывать им свое незнание. Например, в начале своей карьеры можно вообще не знать, что такое git. На самом деле, все через это проходили, и человек (например, ваш руководитель) скорее хуже отнесется к вам, если вы весь день проведете, пытаясь выяснить что-то самостоятельно, чем потратите 5 минут, просто задав вопрос.
Тем не менее, стоит иметь в виду следующее. Часто ответ на вопрос, который вы хотите задать, можно найти в поисковике по первой же ссылке. Также в компаниях часто бывают внутренние wiki, где тоже можно найти нужную информацию. Поэтому не стоит лишний раз беспокоить других людей и спрашивать то, что вы можете найти сами. Тем более, для любого специалиста это очень важный навык – искать информацию самостоятельно.
Теперь поговорим про случаи, когда информацию самостоятельно найти не удалось. Если не спрашивать то, что вам нужно для работы, можно потратить очень много времени – вы можете не знать, как именно найти нужную информацию. Чтобы найти ее, иногда нужно обладать знанием о контексте и о чем вообще речь хотя бы примерно. А иногда нужной информацией обладают только ваши коллеги.
В большинстве случаев ваш вопрос не глупый, и дело не в вас, а просто люди вокруг сами боятся узнавать что-то у других людей, потому что думают, что к ним станут хуже относиться, но это не так.
Иногда нужно обращаться к человеку много раз, чтобы что-то узнать, и не нужно этого бояться. Если это наискорейший или единственный путь решения вашей проблемы, то будьте максимально вежливы и просто напишите / поговорите с человеком, у всех возникала такая ситуация, и это нормально.
5. Не бойтесь оспорить чье-то мнение
Когда идет обсуждение какой-то задачи, не надо бояться высказать свое мнение, даже если вы окажетесь неправы. Даже если это вышестоящий по должности человек, он ждет от вас, что вы будете спорить и высказывать свое мнение. К тому же нередко случаются такие ситуации, когда все неправы, а один человек прав.
Конечно, важно сначала обдумать свою точку зрения и сформулировать свою мысль, а не озвучивать все, что придет в голову.
В любом случае, чтобы быть ценным игроком, а не просто исполнителем задач, важно высказывать свое мнение. А страх со временем будет пропадать и вы приобретете уверенность.
6. Держите в уме, что другой человек мог сделать свою задачу не идеально
Бывает, что вы задумываетесь о какой-то детали вашей задачи. Например, обрабатывается ли какой-то необычный случай в коде вашего коллеги. Вы думаете, что раз он это делал, то подумал об этом, и все хорошо. Но, к сожалению, ошибаются все.Я считаю, что этот пункт тоже нужно отнести к проблемам в общении, т.к. вы всегда можете уточнить у человека, подумал ли он, когда писал код, о каком-то необычном случае, что будет происходить в этом коде и нет ли ошибки. Если этого не сделать, это может повлечь снежный ком из ошибок.
7. Не скрывайте свой факап
Например, вы увидели, что выкатили баг и пытаетесь быстро это починить, пока никто не узнал. Это может вызвать бОльшие проблемы для окружающих вас коллег, чем если вы просто объясните им проблему как есть.
Люди вокруг могут указать на то, как не повторить такую ситуацию.
Если ваши коллеги будут понимать проблему, скорее всего вы сможете быстрее исправить свой факап, ведь они смогут помочь вам.
Иногда бывает так, что на самом деле проблемы нет, но вы можете этого не осознавать.
Другой человек может тоже заметить, что что-то сломалось, и пытаться найти, в чем проблема. Если вы расскажете о своей ошибке, то он поймет, в чем дело, и не будет тратить свое время попусту.
На самом деле, вы покажете намного больший профессионализм, если будете в таких ситуациях говорить все как есть и ничего не скрывать.
8. Старайтесь помогать другим, когда можете
Допустим, вы видите чей-то вопрос в чате на 500 человек и знаете ответ на него. Часто люди игнорируют это и просто оставляют человека без ответа. В идеале так делать не надо, вот почему:
Помогая другим, вы делаете окружение лучше: разные компоненты вашего продукта работают правильнее и эффективнее, люди вокруг обладают бОльшим знанием, люди не допускают ошибки и не портят жизнь вам.
Когда вы помогаете другим, вы можете узнать что-то новое сами. Как говорится, "если хочешь что-то понять – объясни это".
9. Старайтесь отвечать на сообщения быстро
Понятно, что бывает мало свободного времени, чтобы ответить кому-то. Иногда можно забыть, что вообще кто-то что-то просил, и не отвечать человеку несколько дней. Думаю, что это тоже плохой тон и надо стараться избегать таких ситуаций.
Если не можете ответить прямо сейчас, всегда можно написать человеку, что ответите позже, он поймет, что вы хотя бы увидели его сообщение и не игнорируете его. То же самое, если для ответа на его вопрос вам нужно узнать что-то у кого-то другого – просто скажите человеку "я сейчас узнаю у коллеги, жду пока он ответит, потом отвечу тебе".
Если человек вас что-то спросил, а вы даже не знаете, что ответить, не надо тянуть время, просто скажите ему правду – вы не знаете. Это будет лучше, чем если человек будет ждать в неведении.
Если происходят такие ситуации, что вы забываете ответить человеку – ставьте себе напоминалку, например эта функция есть во многих мессенджерах.
10. Учитывайте погруженность другого человека в вопрос
Часто, когда разработчик объясняет что-то, например, project manager'у или другому разработчику, он не думает о том, насколько этот человек погружен в проблему.
Например, вы говорите человеку "У нас на прошлой неделе была проблема с X, поэтому не работает Y", где X и Y – непонятные слова для человека не из вашей команды.
Подумайте, прежде чем что-то рассказывать, а понимает ли собеседник, о чем вообще речь?
Возможно, стоит сначала погрузить его в контекст: "В нашей системе есть сервис A, в котором есть компонента Y, она отвечает за ... Там есть функционал X, который обеспечивает работу... Мы обнаружили там проблему, из-за которой не работало...". Это будет понятнее для него и обсуждение пойдет быстрее.
11. Излагайте мысли структурированно
Чтобы собеседник лучше вас понимал, обязательно нужно излагать свои мысли максимально структурированно, будь то письменная или устная форма. Бывает, люди пишут много воды, перепрыгивают с одной задачи на другую и тому подобное.
Основное правило – из большого текста / рассказа должно быть быстро понятно, о чем идет речь и какой тезис. Например, если вы рассказываете про свою задачу, должна быть понятна проблема, которую вы решали и какой результат решения проблемы.
Если форма письменная – не должно быть сплошного текста, в тексте нужны пункты, ссылки, картинки, заголовки и тому подобное.
Человек, который читает ваше сообщение, не должен перепрыгивать с одной ссылки на другую, лучше сразу предоставить всю информацию в одном месте (настолько, насколько это возможно). Особенно, если это руководитель, у которого скорее всего мало свободного времени.
Если вы рассказываете что-то в устной форме – не говорите очень быстро и без остановки. Разбейте свою речь на пункты и последовательно убедитесь, что собеседник понял каждый пункт.
Если придерживаться этих правил, то почти всегда вы потратите меньше времени, объясняя что-то другому человеку. И не менее важно, ваш коллега также потратит меньше времени, пытаясь вникнуть в то, что вы рассказываете.
12. При написании кода ориентируйтесь также на его понятность
Когда пишешь код, надо думать о том, чтобы другой человек смог понять его, желательно вообще не задавая вопросы автору кода. Я думаю, что это тоже относится к общению, потому что непонятный код будет работать, но оформление кода – форма взаимодействия.
Старайтесь добавлять комментарии, документацию к коду, чтобы было понятно, что где в коде происходит.
Опишите какие-нибудь примеры, с которыми работает ваш код.
Тут еще много всего можно сказать, но общая суть понятна. Другой человек скорее всего рано или поздно будет разбираться в вашем коде (как минимум, код-ревьюер), поэтому стоит подумать о нем и сделать код максимально читаемым.
13. Обсуждайте на встрече то, для чего она предназначена
Например, вы общаетесь на рабочей встрече по какой-то задаче, где обсуждаете, что сделано, что собираетесь сделать, какой план и т.д.
В таких ситуациях часто бывает, что люди начинают обсуждать детали, которые не относятся к цели встречи.
Надо помнить, для чего предназначена встреча, а детали, если нужно, обсуждать потом, иначе вы просто потратите чужое время и сделаете встречу неэффективной.
Если вам нужно обсудить что-то подробнее, просто договоритесь об отдельной встрече, где вы спокойно сможете обсудить проблему.
14. Будьте вежливы
Этот пункт, наверное, самый банальный и очевидный, но тем не менее. Я считаю, что если кто-то обращается к вам за помощью, никогда нельзя отвечать токсично, использовать сарказм, грубить человеку. Конечно, это не всегда получается, но даже если человек очень назойлив, нужно все равно быть профессионалом и общаться конструктивно. Что еще стоит помнить:
Пишите грамотно. Многих людей раздражает или отвлекает неграмотное написание, да и просто приятно читать текст, написанный без орфографических ошибок.
Айтишники любят общаться непринужденно, но старайтесь не материться много в чатах или разговорах. С какого-то момента это начинает создавать негативную атмосферу в коллективе.
Если вам помогли – всегда говорите спасибо.
Я думаю, можно перечислить еще много всего, но я постарался собрать то, что мне показалось важным. Очень круто, если вы сами чувствуете себя уверенно и стараетесь при общении уважать время и чувства своих коллег. Всем желаю позитивного взаимодействия на работе, пишите в комментарии свои советы, как сделать его лучше.
Комментарии (10)
oleg_shamshura
15.11.2022 03:15А где советы по сути, а не по форме? Например, не козли, будь человеком? Или главное - улыбочку держать?
dimoff66
15.11.2022 03:25Системы, над которыми работают разработчики, постоянно усложняются, поэтому создавать что-то в одиночку становится практически невозможно.
Все наоборот, с усложнением систем увеличивается скорость разработки, и разработать что-то в одиночку вполне реально. Просто командой разрабатывать еще быстрее, но к сложности систем это отношения не имеет.
Mirzapch
15.11.2022 03:59Опять "ручка сервиса".
https://habr.com/ru/post/696880/
Меня уже начинают посещать мысли тоже этот текст опубликовать. Авось из песочницы вылезет... Но делать это я конечно не буду.
sgjurano
15.11.2022 06:23-1А что с ручкой не так? :)
Достаточно распространенный профессиональный сленг, да и удобнее чем "метод API сервиса".
karabanov
15.11.2022 20:02Ручка это скорее изменяемый параметр в конфиге, то что тут называется "ручка сервиса" - это эндпоинт, или метод API
Mirzapch
15.11.2022 20:59Это вторично. Но правила сайта говорят нам:
Каждый автор имеет свою индивидуальность, потому если вы уже где-то видели подобную статью, это не значит, что в сообщении нет ничего нового и интересного. Вчитайтесь и вдумайтесь — поймите авторское мнение.
"Перечитал", даже diff сделал. Ничего кроме добавленного заголовка, и по-другому объединённых абзацев не нашёл.
JuryPol
15.11.2022 08:42+3Достаточно распространенный профессиональный сленг, да и удобнее чем "метод API сервиса".
А вы уверены, что это именно профессиональный сленг? Мне кажется, что это удел тех, кто всего лишь мнит себя профессионалом.
Иначе придется считать профессионалами малолетних пижонов из анекдотов про "А у меня вчера мама сгорела"...
sgjurano
15.11.2022 10:09+1В моей среде очень многие так говорят — это инженеры из Яндекса, Авито и других крупных российских IT-компаний, думаю этого вполне достаточно для того, чтобы сленг считался профессиональным.
Столь смелые предположения о квалификации незнакомых вам людей на основе использования ими той или иной лексики — это конечно же признак высочайшей квалификации :)
funca
15.11.2022 10:19+1Первый раз услышал про ручки, за которые дёргают или трогают ReST APIs наверное лет 10 тому назад от сотрудников Яндекса, когда делали для этой компании проект. Там все так говорили, с кем мне довелось общаться, и слово попало в мой русскоязычный лексикон тоже. Звучит легче, чем хэндлер или эндпоинт. А метод и так перегружен смыслами, что приходится постоянно переспрашивать, что имеется ввиду. Более строго, в терминологии OpenAPI, это Paths and Operations.
tandzan
Хаб "Машинное обучение", это нейросеть уже такие статьи пишет?