Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

7 порад для ефективної комунікації з інженерами

Привіт! Мене звати Анна Тєтєріна. Я сертифікована тренерка і фасилітаторка, працюю Training & Development Specialist в Innovecs. Проводжу тренінги і багато вивчаю про soft skills та їх важливість як у житті, так і в професійній діяльності.

Зараз ми з командою сфокусувалися на розробці інтерактивних E-learning курсів, адже їх можна проходити будь-коли і будь-де. Наразі це важлива умова для програмістів. Почали з емоційного інтелекту і вирішили відкрити цей курс для усіх охочих, бо саме емоційний інтелект допомагає триматися в сучасних реаліях.

У цій статті хочу поділитися з вами кількома іншими порадами, які особливо стануть у пригоді, якщо ви працюєте в ІТ і щоденно онлайн чи офлайн спілкуєтеся з програмістами.

Які особливості комунікації з інженерами

Прозора та чітка комунікація — це умова процвітання будь-якої компанії. Є достатньо досліджень, звітів консалтингових компаній та опитувань на підтвердження того, що ефективна командна комунікація впливає на продуктивність, довіру, а також зменшує плинність кадрів.

Відповідно до дослідження McKinsey, в командах, які успішно комунікують між собою, відзначається зростання продуктивності на 20-25%. Водночас 86% працівників переконані, що причиною невдач і провалів на роботі є саме нестача комунікації.

Відтак, прозора й ефективна комунікація є навичкою, яку треба тренувати, особливо, якщо ви працюєте у бізнесі та розвиваєтеся у напрямку Engineering Leadership. Йдеться не лише про лідерів команд, але й розробників, що діляться своїм досвідом з іншими, менторять нових працівників чи беруть участь у вебінарах та IT-конференціях.

Погодьтеся, щонайменше 3 години із 8 робочих ми проводимо, комунікуючи з людьми — беремо участь у командних дзвінках, робочих мітингах, пишемо листи, готуємо технічні завдання тощо. Загалом успіх виконання будь-якого завдання на 50% залежить від точності вимог і побажань. Що точніше поставлене завдання — то ефективніше буде зроблене.

Деякі призначають десятки мітингів, надсилають довгі ланцюги повідомлень і мають стільки дзвінків, що аж «голова кипить». Але успіх комунікації не в кількості, а в ефективності. Як же цього досягнути?

Перш за все визначіться, з якими типами особистості ви маєте справу. Найлегше скористатися DISC моделлю оцінки особистості за Вільямом Марстоном.

DISC Assessment model

Ця модель поділяє людей на чотири типажі: домінантні, впливові, постійні й інструктивні.

  • Домінантні характеризуються такими якостями, як орієнтація на результат, швидкість, проактивність, прямолінійність, вимогливість і конкурентність.
  • Впливові — комунікабельні, життєрадісні, ентузіасти й екстраверти, цінують увагу і співпрацю з іншими.
  • Постійні вирізняються терплячістю, високим рівнем емпатії, надійністю і стабільністю. Вони чудові командні гравці.
  • Інструктивні звикли дотримуватися правил й дуже орієнтовані на деталі. Вони скептичні й критичні, мають аналітичний склад розуму.

Варто зазначити, що домінантні й інструктивні більше сфокусовані на справі, а впливові й постійні — на людях. Звичайно, що цей поділ є досить умовним, адже більшість людей мають змішаний тип особистості.

З досвіду скажу, що найчастіше програмісти більш схильні проявляти якості інструктивного типу. Можливо, через особливість професії, адже робота з кодом вимагає високої сфокусованості, концентрації уваги й структурованості. Дехто так захоплюється своєю роботою, що не хоче й з дому виходити, лише кодити-кодити-кодити 😊

У комунікації з інженерами важливо знати деталі, бути послідовним та вміти уточнювати. Ось кілька важливих рекомендацій, які допомагають в комунікації з інженерами.

Важливо мати глибокі знання з теми

До моїх обов’язків входить проведення тренінгів на різні теми. На таких зустрічах я дуже легко помічаю інженерів — вони ставлять найбільш влучні й найскладніші питання. Найчастіше саме вони уточнюють джерела інформації й просять аргументувати правдивість теорії кількома фактами.

Якщо ж й не встигли уточнити під час мітингу, обов’язково напишуть про це, коли дають зворотний зв’язок. Поки я презентую тему, вони встигають перевірити інформацію у «Вікіпедії», загуглити й знайти альтернативні джерела даних. Тому в комунікації з такою аудиторією важливо знати усі важливі факти й цифри, якими ви можете оперувати під час дискусії.

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

Не бійтеся запитувати

Не забувайте, що інженери можуть бути цінним джерелом інформації. Навіщо винаходити колесо, якщо воно вже існує. Запитайте в програмістів — дізнаєтеся чимало нового і з великою ймовірністю знайдете відповідь на своє питання. Усе, що треба зробити — звернутися до них.

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

Ще одна особливість розробників — вони не відповідають на питання, яких ви не ставили. Не чекайте, що ви отримаєте інформацію лише завдяки одному запитанню, підготуйтеся до серії запитань. Програмісти не завжди багатослівні. Що їх запитують — на те вони й відповідають. Тому буває так, що яке питання — така й відповідь. Сформулюйте питання чітко, від цього залежить, яку інформацію ви зможете отримати.

Ще один важливий аспект: людям притаманно робити припущення замість того, щоб прямо запитати. Часто ці припущення ведуть нас до неправильних висновків, і це може погано позначитися як на робочих взаєминах, так і на бізнес-процесах. Тому краще перепитайте.

Ми не наділені здатністю читати чиїсь думки. Замість того, щоб припускати, чому колега не відповів на e-mail, або чи задоволений клієнт продуктом, чи буде він достатньо вигідним, просто озвучте питання. Розкажіть про те, які факти знаєте, а колега поділиться інформацією, яка вам ще невідома. Є багато компаній, які втратили можливості, не перевіривши свої припущення про продукт чи технологію або зробили це занадто пізно. Запитуйте і дізнаєтеся навіть більше, ніж очікували, а це допоможе розвивати бізнес.

Структуруйте й аргументуйте позицію

Навчіться висловлювати свою позицію чи прохання структуровано. Це важливо як у комунікації з клієнтом, так і в комунікації з програмістами. У цьому може допомогти інструмент «Піраміда Мінто», яку запропонувала консультантка McKinsey Барбара Мінто.

The Minto Pyramid Principles

Спочатку ви чітко окреслюєте причину свого звернення, називаєте проблему, описуєте ситуацію чи ставите питання. Потім пропонуєте рішення, розв’язання проблеми, тоді наводите кілька аргументів, кожен з яких може підкріплюватися цифрами та фактами. У кінці робите висновок. Таким чином ви згруповуєте інформацію і полегшуєте її сприйняття. У презентаціях, дискусіях чи під час пітчингу ідей використовуйте метод дедукції, який допомагає послідовно описати інформацію. Перше твердження описує загальну ситуацію, друге — уточнює суб’єкт, а третє — це висновок.

Готуючись до розмови чи презентації, зробіть короткий список з важливими тезами, які плануєте озвучити. Пишіть лаконічно і вичерпно. Найголовніша інформація має бути на початку, а додаткові деталі — після. Пам’ятайте, що мозок дуже добре запам’ятовує початок і кінець. Попрацюйте над тим, щоб ваш початок був своєрідним гачком, а завершення спонукало до дії.

Навчіться активно слухати

З попереднього пункту витікає ще один — вміння активно слухати. Під час спілкування ставте запитання й озвучуйте проблему, не втрачайте можливості отримати чітку відповідь. Для цього можна використовувати декілька технік активного слухання: запитувати, перефразовувати почуте, підсумовувати необхідні дії тощо.

6 KEY Active Listening skills

Активне слухання належить до категорії soft skills. Згідно з опитуванням PSMJ Resources, яке проводилося серед працівників компанії, бажані якості програміста — хороший слухач, ефективний комунікатор, самоорганізований. Цікаво, що ці якості у переліку вимог піднесли вище, ніж технічний досвід.

Особливо soft skills важливі для тих, хто прагне розвиватися у сфері Engineering Leadership, починає багато комунікувати з клієнтом. Щоб уникнути непорозумінь і неточностей, важливо активно слухати, аби знизити ризик втрати інформації через переклад.

5 рекомендацій для активного слухання

  1. Під час розмови поверніться обличчям до співрозмовника — покажіть свою уважність мовою тіла.
  2. Тримайте зоровий контакт — при цьому обом має бути комфортно. А якщо це онлайн-зустріч, то для підтримки зорового контакту треба дивитися у камеру.
  3. Мінімізуйте зовнішні фактори, які можуть вас відволікати — відкладіть телефон, відсуньте комп’ютер і сфокусуйтеся на розмові.
  4. Слухайте, щоб зрозуміти — не перебивайте людину, поки вона не завершить думку і зачекайте, поки висловиться, перш ніж погодитися або заперечити її позицію.
  5. Будьте залученим — ставте запитання, перефразовуйте окремі аспекти розмови і давайте пораду лише тоді, коли інша людина вас про це попросить.

Невербальна комунікація може бути лише додатковим джерелом інформації, але аж ніяк не базовим. Ніколи не варто робити висновків на основі єдиного жесту чи виразу обличчя, треба оцінювати в цілому. Люди з бізнесу, які володіють майстерною невербальною комунікацією, мають перевагу у своїй сфері діяльності — від демонстрації впевненості до зміцнення авторитету.

Міміка, зоровий контакт, голос, жести — усе це важливо як під час презентації продукту, так і під час переговорів. Тренування невербальної комунікації для представників бізнесу не є таким легким, як здається на перший погляд.

Уточнюйте, яким каналом зручно користуватися

Ви написали інженеру на пошту і немає відповіді? А як часто він переглядає пошту, ви запитували? У кожного з нас є перелік каналів комунікації, з яких є кілька найбільш пріоритетних. Поцікавтеся, якому каналу комунікації віддає перевагу ваш співрозмовник, куди краще звертатися і де можна очікувати відповіді. Пам’ятайте і про різницю у поколіннях.

Зазвичай представники покоління постміленіалів використовують Instagram, Telegram, TikTok, Slack, а покоління міленіалів — більш активні у Facebook, а хтось використовує Viber. Напевно, мережа, яка об’єднує усіх в робочому спілкуванні — LinkedIn, але Senior Engineers не так часто туди заходять, бо їм надокучають десятки повідомлень від рекрутерів. Тож і ваше повідомлення також може там загубитися.

Важливим є не лише канал, але й спосіб. Одному зручніше спілкуватися у месенджері, іншому — через Skype чи Teams або іншу корпоративну мережу, ще іншому — краще зустрітися. Уточнюйте, перш ніж надсилаєте повідомлення.

Навчіться управляти своїми емоціями

Поширеною є думка, що інженери не показують своїх емоцій. Проявити свою радість можуть хіба при успішному запуску продукту. Але Даніель Гоулмен і Пітер Саловей, які популяризували модель емоційного інтелекту, довели, що прояв емоцій допомагає знайти взаєморозуміння. Не приховуйте своїх відчуттів, просто навчіться їх висловлювати, називати те, що відчуваєте.

На роботі бувають непорозуміння, конфлікти. Їх уникнути складно та й не завжди треба, адже конфлікти часто зближують, допомагають зростати за умови, якщо з них правильно виходити. Саме тут важливою є техніка «Я-повідомлень». Якщо у вас є зауваження чи незадоволення до колеги, уникайте «Ти-повідомлень». Краще почніть висловлювати свою емоцію так: «Я відчуваю, що (опишіть свою емоцію), коли (опишіть поведінку чи ситуацію, яка вас тригерить, не переходячи на „ти“)». Потім скажіть, як ситуація чи поведінка мала б виглядати, аби вас це більше не зачепило або не викликало негативних емоцій.

Будьте уважними до себе й до своїх колег. Ставте емпатичні запитання, уточнення, цікавтеся, які є складнощі та в чому потрібна допомога — це дуже цінно та сприяє ефективній взаємодії.

Code review як окремий вид комунікації

Ефективний фідбек має надихати, а не демотивувати. Code review — особлива процедура, яка має свої процеси й стандарти. Часто Team Lead задумується — казати чи писати. Я за те, щоб виправляти код за участі програміста, який його писав, а не мовчки. Обговорювати помилки, пояснювати. Далі, відповідно до процедури, ці коментарі можна зафіксувати. Це хороша можливість обмінятися досвідом та знаннями, знайти найкраще інженерне рішення.

Звичайно, що на це треба бронювати додатковий час для комунікації. Але що краще програміст зрозуміє ваш фідбек і зони покращення коду, то швидше виконає задачу. Це така інвестиція для покращення роботи команди в майбутньому.

Успішність комунікації полягає не в кількості повідомлень, а в їхній якості. Прозорі й налагоджені процеси, швидкість розв’язання задач і чіткість технічних завдань — ознаки компанії з ефективною комунікацією.

Якщо після усього прочитаного у вас виникло бажання розвивати soft skills й інші потрібні корпоративні компетенції, надішліть мені на innocamp@innovecs.com запит на приєднання до наступного курсу. Буде цікаво і корисно. Також, можете звернутися за отриманням запису курсу «4 практичні сфери емоційного інтелекту».

👍ПодобаєтьсяСподобалось11
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Анна, вам не кажется, что в украинском IT и в целом в регионе софт скиллами принято называть совсем не то, что называлось софт-скиллами изначально в США, откуда эта терминология пришла ? Изначально софт-скиллами было умение солдат выполнять задачу, которая не сводилась к владению техникой. Затем этот термин был позаимствован корпоративной средой и означал именно умение достигать результата, коммуникации это лишь один из инструментов достижения результата.
А сейчас я через раз читаю статьи/тренинги вижу где под софт скиллами почти 99% понимают именно умение общаться, а не решать проблему и достигать результата пофиг как: индивидуально, в коллективе, в среде с неопределенностью.

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

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

//не воспримите за критику мои слова, но я говорию о своей картине мира

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

Кстати, рекомендую посмотреть фундаментальную литературу по управлению, в противовес попсовым Бруксам и ПМбукам:
booksonline.com.ua/view.php?book=33532

Эпиграф: Бывают ли столярные мастерские без рубанка, но со сварочым аппаратом? Безусловно. Можно такую мастерскую распознать не заходя в нее? Несомненно. Зайдите на кухню хозяина, найтедте там швейную машинку, или полный ночной горшек.

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

Бухгалтера существуют, по меньшей мере, с 17го века. Считали в уме. Такое умение было и есть хардскилом. Вывод: хардскилы — инструментарий работника, без которого абсолютно нельзя обойтись в профессии. У политрука и командира отдельной бригады это — совсем не умение заряжать те или иные виды патронов.

Что же это за скилы, без которых можно? Инвариантные. Т.е. когда конечный результат слабо зависит от инструмента, которым пользовался работник. Можно применять любой. Если без скилов можно, то зачем они? Ответ отличается, в зависимости от точки зрения. По сути, непринципиальное уменьшение издержек, а по содержанию разные ответы. Индустриалам массового производства 20го века, как и Анне, в работе нужна беззадоринкость. Отсюда все неконфликтностные скилы, лизоприятность, умения получать ответы, не спрашивая и не тратя рабочего времени коллег. Создателям инновационных прорывов вроде вас и Георгия Петровича нужна эффектность. Отсюда фокус на производстве продуктивных идей, поиске и разрешении конфликтов и, неизбежно, кчертовость приятных собеседников.

Спасибо за развернутый комментарий. Нужно осознать.

А есть еще 1 вариант, который успешен на 89.99%:

1. Описываем требования к задаче, указывая что мы хотим получить
2. Дописываем требования качества — что будет успешным ее завершением
3. Указываем то, чего нельзя делать исходя баланса время/качество

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

Владислав, благодарю, что делитесь своими примерами!

Підписатись на коментарі