🟡 Бути тім-лідом: очікування та реальність

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

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

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

Як уявляв роль: 4 зони відповідальності та “червоні прапори” тім-ліда

Основне завдання тім-ліда – повне розуміння, куди рухається проєкт і хто за що відповідає. Для цього всі справи можна поділити на чотири зони відповідальності:

1. Відповідальність за напрямок розробки на проєкті. Розподіляти, хто чим займатиметься за часовою шкалою: пріоритезація завдань, контроль якості.
2. Комунікація в команді – розв’язання проблем усередині команди. І щодо взаємодії між командами розробки всередині, і навіть членами однієї команди. Завдання тут – налаштування до рівня, коли все може функціонувати і без тім-ліда до 2-3х тижнів.
3. Комунікація із замовником: тім-лід пояснює всі завдання, вміє розповідати все зрозуміло і ввічливо, навіть якщо доводиться повторювати кілька разів. Доносити ризики, слухати побажання і вносити корективи. Частково виконує роль проджект-менеджера, але по техчастині.
4. Верхньорівневе розуміння проєкту: навіщо робиться, куди йде, де зараз перебуває. Дивитися на нього з погляду не тільки розробки, а й бізнесу: вчасно помічати і превентивно вирішувати проблеми, спілкуючись з усіма членами команди, працювати з ризиками.

Також розмірковував про те, що ж таке поганий тім-лід. Згадав те, що не подобалося мені самому, коли в мене були тім-ліди:

1. На будь-яке питання відповідь “Читай доку”, навіть якщо цього там немає.
2. Головне, щоб у поточному спринті ми зробили все заплановане, а що буде потім – неважливо.
3. Погано побудований процес розробки продукту, як наслідок – продукт у майбутньому складно підтримувати.
4. Кожна проблема стає несподіванкою.

М’який вхід = маленька команда + покрокове занурення

Попросіть команду до 5 осіб.

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

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

Доводьте свою цінність поступово

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

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

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

Коли приходите в проєкт, не треба говорити:

“Я тім-лід і я буду все вирішувати”, – такого все одно за фактом не буде, тому що в хороших компаніях вирішує вся команда, спільно, а за вами може бути фінальне рішення, але тиранізм тут точно не допоможе.

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

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

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

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

Тепер розповім докладніше про те, що криється під верхнім шаром “завдань”. Складні точки прояву тім-ліда, завдяки яким усе починає працювати злагоджено.

Завдання 1. Балансуйте якість і терміни; або пам’ятайте про те, що існують QA

Дилема і розробника, і тім-ліда: функціональність або якість. Гадаю, усім знайома проблема, коли 2-3 спринти робиться одне й те саме завдання “до ідеалу” або документація пишеться довго і надто детально, – і терміни зриваються. З одного боку, це нормально, тому що означає, що хлопці круто роблять і глибоко занурюються. Але завжди є терміни – відповідальність перед продуктом, його запуском і замовником.

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

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

Якщо ж будете топити за функціональність – заслужите недовіру клієнта. Уявіть, що вам за півтора місяця не показують нічого нового, а все обіцяють на словах – ви теж на його місці подумали б “що за х***я”, і що варто перевірити роботу команди. Починаються багатогодинні обговорення завдань, що жере багато-багато часу і нервів у всіх, а продукту ніяк не допомагає.

Завдання 2. Захищайте команду перед клієнтом і усувайте слабкі місця в процесах

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

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

Як вирішити проблему, якщо людина не тягне:

Спочатку просто зателефонувати і запитати, у чому складність. Можливо, буде достатньо доступно пояснити принцип розв’язання задачі і порадами або прикладом – важливо: не готовим кодом! – спрямувати в потрібне річище.

Якщо не допомогло:

• Під приводом терміновості та важливості передати завдання більш досвідченому/зацікавленому члену команди, або взяти на себе, оскільки проєкт завжди в пріоритеті;
• Провести 1-на-1 з цією людиною і з’ясувати її цілі та прагнення. Можливо, їй слід а) змінити проєкт, б) запропонувати відпустку: раптом вона просто сильно втомилася, в) мотивувати її: наприклад, чіткіше спланувати шлях зростання підвищення грейду до наступного ступеня і відповідно ЗП.

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

Завдання 3. Прогнозуйте ризики і не бійтеся відстоювати свою позицію

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

Через суму чинників і непідготовленості не зловили потрібний момент збільшення команди, наприклад, підключення того ж аналітика, QA і фронтів. Думали: так коли вони тут потрібні, коли ставити? Не було впевненості зараз чи потім. А виявилося, що треба було ще раніше, ніж ми почали про це думати. Це призвело до деяких незручностей у майбутньому: уявіть, за два тижні нам довелося збільшити команду з 4 до 12 осіб!

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

Завдання 4. Не ставте завдання, а налаштовуйте роботу так, щоб завдання ставилися командою самі

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

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

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

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

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

Хороший тім-лід – це не тиран, а консультант.

Підсумок

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

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