Як спілкуватися в новій команді: 6 порад джунам, перевірених часом

На початку кар’єри вам може здатися, що комунікація в IT ні до чого. Але це не так. В усіх IT-спеціалістів, незалежно від напрямку роботи, навички ефективного спілкування цінуються на рівні з технічними скілами. У когось задач, пов’язаних із комунікацією більше, в когось — менше, та вони однозначно є.

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

У цій статті я зібрав базові поради, як ви вже зараз може покращити комунікацію в команді й адаптуватися в проєкті.

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

• «Я ж початківець, що я можу запропонувати? Досвідчені розробники і так усе знають».
• «Якщо поставлю питання, всі подумають, що я некомпетентний».
• «А що тут думати? Все і так зрозуміло!».

Насправді всі знають, що співробітник — початківець. Команда ставиться до нього лояльно та налаштована допомагати. На старті кар’єри можуть і мають виникати питання. Це невід’ємна частина навчання. Так що відкиньте будь-які сумніви щодо цього. Чим раніше ви розговоритеся, тим швидше станете фахівцем.

Обговорюйте завдання на старті

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

Намагайтеся не допустити ситуації, коли по-своєму зрозуміли для себе вимоги, написали код, а виявилося, що все зовсім не так.

Подібної самодіяльності бути не повинно. Тут згадується фраза: «Краще запитати і побути дурнем 5 хвилин, ніж промовчати і залишитися ним на все життя».

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

Не замовчуйте проблеми

На початку шляху труднощі та помилки дають можливість навчитися робити так, як треба, і в перспективі посилюють наявні навички. Звичайно, не треба при першому ж ступорі заявляти про «проблему» менеджеру або техліду. Спробуйте розібратися самі.

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

Будьте ініціативними

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

Поважайте час колег

Якщо менеджер запитує, як ваші справи, його справді може це цікавити. Але скоріш за все він має на увазі виконання поставлених перед вами завдань. Тому одразу введіть колегу в контекст. Опишіть, чим займаєтеся, які успіхи вже маєте, чи вкладаєтесь у терміни, які подальші плани тощо.

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

Розкажіть, що можна покращити в проєкті

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

Припустимо, ви хочете додати редактор тексту. Можна обрати якесь популярне рішення, «прикрутити» його — і на цьому все. А можна презентувати ідею більш ґрунтовно:

• прийти до менеджера з кількома прикладами редакторів і розповісти про їх переваги та недоліки;
• потім попросити передати свої пропозиції клієнту, щоб він обрав те, що йому підходить.

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

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

Показуйте, що в розробці можна зробити краще та як від цього виграє бізнес. Замовник завжди оцінить дбайливе ставлення до свого дітища.

А це вже підвищить лояльність до компанії та шанси на те, що вас порекомендують іншим.

Не комунікацією єдиною: що ще допоможе знайти спільну мову з колегами

Ви дізналися про головні, на мій погляд, нюанси ефективної комунікації. Але ніхто не скасовував хард-скіли — те, що ви як розробник зобов’язані робити добре. Цим ви значно допоможете колегам і заслугуєте їхню довіру.

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

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

Читайте також: Компаніям потрібні ваші софт-скіли: 7 найважливіших навичок сучасного розробника