7 упереджень тімліда-початківця

Оригінал статті опубліковано на DOU.

Вітаю! Я Ігор Степанов, Senior Team Lead у Plarium. Зараз я керую командою тім- та техлідів і відповідаю за технічний стан клієнтської частини проєкту Raid: Shadow Legends. Коли три роки тому я став тімлідом команди розробки, то мав розмите уявлення про те, які складнощі можуть чекати на новій позиції.

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

Матеріал буде корисним як досвідченим розробникам, які розмірковують над стратегією кар'єрного зростання, так і тімлідам-початківцям, яким хотілося б оминути усім відомі «граблі».

Упередження № 1: тімлід має бути технічно сильнішим за всіх учасників команди

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

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

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

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

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

Показник роботи тімліда – не лише успіхи окремих співробітників, а й функціонування команди як єдиного організму. Усвідомлення сильних і слабких сторін кожного фахівця дозволяє не вдаватися в окремі ділянки детально, а довіряти та орієнтуватися, хто з колег може швидше і якісніше розв'язувати проблему.

Упередження № 2: суперництво йде команді на користь

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

Дізнавшись щось цікаве, співробітник замість того, щоб швидше розповісти про це, шукатиме спосіб спочатку застосувати знання особисто, заробивши очки за рахунок інших.

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

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

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

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

Упередження № 3: тімлід може витрачати стільки ж часу на програмування, як і раніше

У ролі тімліда у вас більше не буде можливості виділяти на програмування стільки ж часу, скільки на позиції розробника. Нові обов'язки можуть «не пустити» вас програмувати день, два, а іноді й цілий тиждень.

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

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

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

Але це не так страшно, як здається. Керівна позиція дозволяє реалізувати більше ідей, ніж можна здійснити наодинці. По суті ви отримуєте можливість виробляти більше коду, який відповідає вашим стандартам якості.

Упередження № 4: овертайми ефективні

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

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

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

Крім того, коли ви працюєте, не жаліючи себе, свідомо або підсвідомо починаєте вимагати такої ж віддачі від інших. Будь-яка помилка починає сприйматися крізь призму недобросовісності: «Чому я маю правити ці дрібниці до дванадцятої ночі, якщо Олегу було ліньки затриматися на 5 хвилин і внести правки у свою ж роботу?»

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

Упередження № 5: ніхто не зробить так якісно, як я сам

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

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

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

Можна довго розповідати, як і що має працювати, але краще запам'ятовуються власні «ґулі». Якщо ви дозволите співробітникові зробити помилку, а потім разом із ним її виправите, шанси, що він більше її не припуститься, будуть у рази вищі, ніж коли ви говоритимете, що і як робити. Головне – не кидати людину в центр океану, очікуючи, що вона сама навчиться плавати. Враховуйте можливості та бажання співробітника, контролюючи виконання завдання відповідно до його рівня. Почніть із басейну :)

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

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

Упередження № 6: «милиці» – це завжди погано

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

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

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

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

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

Якщо терміни не горять, але з наслідками рішення доведеться регулярно стикатися і це критично для бізнесу, обов'язково донесіть важливість питання до керівництва. Необхідно виділити додатковий час на якісний аналіз проблеми та з повною відповідальністю підійти до опрацювання завдання. Як донести цю важливість? Оперуйте основними KPI та поточним чи потенційним впливом технічної проблеми на них. Цифри – найкращі помічники в оцінюванні й аргументації важливості будь-якого завдання.

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

Упередження № 7: гарний тімлід повинен сам з усім справлятися

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

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

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

Чи варті були мої зусилля одержаного результату? Я думаю, вони були корисні для проєкту. Але я міг би отримати 90% вигоди, витративши вдвічі менше нервів і життєвих сил, якби врахував усі вищеописані упередження, особливо №4 і №5:)

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

Обов'язково поділіться переживаннями та труднощами зі своїм керівником, іншими тімлідами, HR BP вашої команди. Сильний співробітник не той, хто не має проблем, а той, хто вміє їх виявляти, знаходить у собі сили визнати, вирішити і зробити висновки на майбутнє.

Висновок

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

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

Усім гарного тімлідства!