Сейчас в сфере 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. Будьте вежливы
Этот пункт, наверное, самый банальный и очевидный, но тем не менее. Я считаю, что если кто-то обращается к вам за помощью, никогда нельзя отвечать токсично, использовать сарказм, грубить человеку. Конечно, это не всегда получается, но даже если человек очень назойлив, нужно все равно быть профессионалом и общаться конструктивно. Что еще стоит помнить:
Пишите грамотно. Многих людей раздражает или отвлекает неграмотное написание, да и просто приятно читать текст, написанный без орфографических ошибок.
Айтишники любят общаться непринужденно, но старайтесь не материться много в чатах или разговорах. С какого-то момента это начинает создавать негативную атмосферу в коллективе.
Если вам помогли – всегда говорите спасибо.
Я думаю, можно перечислить еще много всего, но я постарался собрать то, что мне показалось важным. Очень круто, если вы сами чувствуете себя уверенно и стараетесь при общении уважать время и чувства своих коллег. Всем желаю позитивного взаимодействия на работе, пишите в комментарии свои советы, как сделать его лучше.
Комментарии (12)
bahanov
02.11.2022 08:49+2Возможно ли переделать человека, который болтает слишком много воды? Прекратить общаться не вариант, так же как и напрямую сказать ему об этом. Намёков не понимает)
vassabi
02.11.2022 12:23+1перечитал советы.
Понял, что мне для такой работы нужна секретарша - чтобы она быстро отвечала, а я писал код не отвлекаясь. И чтобы она в общем чате вела блог о том, что я спрашивал у коллег.
Еще можно было бы попросить её - написать вежливое письмо или сделать колл в офис смежников по поводу "странного кода их АПИ".
В общем - пишите еще, очень интересно!
sentimentaltrooper
02.11.2022 15:59Про емейлы. В письмах, в поле Кому обычно указывают тех от кого ожидается какое-то действие. В Копии - тех кому просто ознакомиться, действие не ожидается.
Пишите информативные заголовки - не Re:Re:Re:FWD: Re:Re
В длинных письмах я обычно пишу одной строчкой Executive Summary. Так же четко указываю что, от кого и когда мне надо. Типа: я отсылаю это заказчику вот в таком виде в пятницу, поэтому от Максима мне нужен финальный вариант такого-то документа к четвергу, а если у дирекции есть возражения или пожелания - есть время высказаться до среды.
Или наоборот: в пятницу встреча с новым клиентом мне для нее нужно от CEO то-то, по итогам команда получит это и устроим разбор нового проекта на след. неделе. Все в курсе чего ждать.
idkill71rus
02.11.2022 19:17Что значит - "..не надо бояться высказать свое мнение, даже если вы неправы."?? То-есть я заранее знаю, что не прав, но всё равно буду топить за не верную точку зрения или неверное решение вопроса?
Admz
03.11.2022 13:26Одна из частых проблем в компаниях - "НИКТО НЕ ЧИТАЕТ РУКОВОДСТВА ПОЛЬЗОВАТЕЛЯ!".
Даже если вы внедрили систему по которой человек не получит должность пока не ознакомится и даже сдаст экзамен по должностным инструкциям - всё равно не читают руководства. Может и читают - но это "чтение на вылет". Пробежались по знакомым словам, покивали головой и через минуту забыли всё прочитанное.
Ivan_Strife
04.11.2022 11:25Очень хороший материал, и данные советы после небольшой модернизации (оптимизации под конкретный процесс) можно легко внедрять в качестве рекомендаций в любой сфере.
Лично я взял его за основу и сделал что-то типа рекомендаций по общению в радиоэфире на предприятии.
Жаль мой рейтинг не позволяет поставить лайк за отличный материал
JuryPol
Попытался себе эту ручку представить. Дальше читать не смог. Думал…
kolyanty Автор
Я понимаю, что написано довольно абстрактно, но что вас смущает в этой фразе? Это же довольно стандартное слово, когда говорят про API, например
JuryPol
Пункт 10 в вашей статье... "Учитывайте погруженность"... Статья совершенно общего плана, она ведь не подразумевает обязательного опыта использования API? А Гуугл выдает в первой строчке ссылку на программистский сленг, а зато в следующих - ссылку на Али, где предлагается к покупке аж 309 вариантов "ручек сервиса", не говоря уж о ремонте ручек Паркер...
Ну и зачем провоцировать непонимание? Это статье не противоречит?
Mirzapch
На этом моменте подумал, что читаю перевод. Но упоминания первоисточника нет...
Admz
Это называется
"Излагайте мысли структурированно"