Мабуть ви не один раз бачили словосполучення “Командний гравець” серед списку вимог на посаду програміста чи іншої суміжної галузі в IT. І якщо даний термін вам не завадить отримати роботу, адже визначити чи ви командний гравець на співбесіді доволі важко, від нього точно залежить те, як легко вам працюватиметься з іншими людьми в команді та швидкість вашого просування далі по кар’єрній драбині програміста.

Якщо ви не працюєте над власним проектом, тоді, швидше за все, ви працюєте в команді з іншими людьми. Якщо ви працюєте на когось, тоді у 99% випадків ви працюєте як частина команди. Зважаючи на те, що програміст, більшу частину своєї кар’єри, працює в команді, думаю, варто поцікавитись що ж означає бути гарним колегою по роботі.

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

***

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

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

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

1. Не пропадайте

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

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

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

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

Спробуйте не з’являтись регулярно і команда просто перестане вам довіряти. А це вже веде до наступного правила…

2. Говоріть правду

Тут я не говорю про відкриту брехню. Думаю, ми з вами добре розуміємо, що це шлях в нікуди.

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

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

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

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

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

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

3. Діліться знаннями

Чи був у вашому житті випадок, коли ви звертались із запитанням до спеціаліста, що знає більше за вас, але не отримували жодної допомоги?

У мене було. Я до сьогодні не знаю в чому причина. Можливо відчуття статусу топ кодера і гординя не давала можливості спуститись до мене простого смертного 🙂 Або можливо він мене просто “не взлюбив” як людину, характерами не зійшлись. Або, можливо, боявся потенційної майбутньої конкуренці із молодшим спеціалістом.

На щастя, цей випадок був єдиним. Загалом, індустрія IT – це одна із небагатьох галузей, де навчати інших, допомагати початківцям та ділитись знаннями, надзвичайно заохочується.

На усіх хороших спеціалістів вакансій вистачить. А той, хто боїться конкуренції, зазвичай, просто перестав вивчати нове і розвиватись далі.

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

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

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

4. Запитуйте про допомогу

Проведіть експеримент із програмістами з вашої команди, або просто серед знайомих. Запитайте, як вони вважають, скільки процентів усіх “знань програмування” вони знають? Після того, як вони витріщаться на вас свої очі і ви трохи пресуватимете, що таки хочете цю точну відповідь, більшість відповідей вкладеться між 2 і 20% 🙂 Принаймні так було з тими, кого я опитував.

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

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

Таким чином, не існує жодної людини яка б знала все про програмування. Це ще було можливо 30-40 років тому, але точно не в наш час.

Бути неправим, шукати допомоги, страх виглядати по дурному – усі ці речі, доволі часто, заважають нам просто підійти до іншого спеціаліста і поставити запитання, попросити допомоги. Особливо, якщо запитання є дуже простим (принаймні ми так думаємо).

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

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

5. Працюйте над спільними цінностями

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

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

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

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

Якщо ви потребуєте допомоги у визначенні та консолідації цінностей вашої власної команди, тоді рекомендую почитати книгу Agile Retrospectives: Making Good Teams Great .

6. Моделюйте поведінку, яку хочете бачити в інших

Будь сам тією зміною, яку хочеш побачити у світі.

Махатма Ганді

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

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

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

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

Коли ви моделюєте нову поведінку, то отримаєте один із 4-х результатів:

1. ваші співпробітники зауважать це і приєднаються;
2. їм це не сподобається, ви їх засмутите і вони залишать команду;
3. їм це не сподобається, ви засмутитесь і ви залишите команду;
4. їм це не сподобається і ви не продовжуватимете впроваджувати нову поведінку.

Звичайно варіант перший є найбажанішим. Інколи все закінчується 4-им варіантом. Зміна не приживається. Швидше за все ви не дуже добре показали переваги нового підходу.

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

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

***

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

Якщо відчуваєте, що хтось в команді, на вашу думку, халявить чи сповідує трохи інші цінності, ніж решта людей, скиньте випадково лінк на дану статтю 😉

Цікаво, що б ви додали до даного списку?