Керівник відповідає за те, яким вийде кінцевий продукт, стежить за термінами та наявністю всіх необхідних ресурсів. Однак найголовніше й водночас найскладніше завдання управлінця — перетворити групу людей з різними навичками, запитами та амбіціями на злагоджений механізм. Це передбачає і найм, і онбординг, і цілепокладання, і розвиток своєї команди.
У матеріалі розглядаємо найпоширеніші труднощі, з якими зіштовхуються тимліди, й намагаємося розібратися, як їх подолати. Перелік допоміг сформулювати Олександр Барило, Front-end Team Lead в Boosters. Він уже півроку керує командою з шести розробників, яка розвиває продукт для вивчення іноземних мов Promova.
Особисто у мене не було ситуації, коли потрібно вивчати нову технологію, аби розібратися, як влаштований продукт. Майже усі проєкти я починав самотужки, тому розумію, як влаштований той чи інший інструмент, принаймні на базовому рівні. Для цього достатньо хоч трохи попрацювати з кожним — і ухвалювати рішення та розподіляти навантаження між членами команди стає простіше.
Нещодавно я консультувався з СТО однієї з компаній екосистеми Genesis, і він пояснив, що потреби досконало знати, як працює кожна дрібниця, немає. Ідеально, коли в команді є спеціалісти, які відповідають за конкретні напрямки, тож питання по реалізації (що і як працює) адресуватимуться саме цим фахівцям.
У нашому продукті є кілька напрямів, за кожен з яких відповідає окрема людина. Вона розуміє, як саме розробляла фічу, що потрібно допрацювати, що додати, де які фреймворки та бібліотеки. Якщо раптом розробник випадає з процесу — наприклад, через відпустку чи хворобу — іншим буде важко підхопити завдання, пов’язані з цими фічами та доробити функціонал.
Це bus-фактор — показник, яким вимірюють залежність бізнесу від конкретних людей. Не можу сказати, що за відсутності одного зі спеціалістів у нас все зламається, проте внести зміни буде складно. Аби нівелювати ризики, ми впроваджуємо документацію, де фіксуємо всі нюанси пов’язані з кодом, архітектурою, функціями та іншими аспектами проєкту.
Подібне трапляється, якщо в компанії є декілька технічних команд, але вони не достатньо обізнані в зонах відповідальності одне одного та не бачать, що робиться по сусідству. Поясню на прикладі нашого продукту. Ми працюємо над застосунком для вивчення мов Promova. Коли людина заходить в особистий кабінет, вона бачить декілька секцій. Є функціонал для самостійного навчання, є розділ, де можна бронювати заняття та навчатися з вчителем, є секції для того, щоб проходити тести. Окремо йдуть головна сторінка та статті блогу. Це все — абсолютно різні напрями, за які відповідають різні люди.
І от певна кнопка, візуальний компонент чи логіка можуть бути спільними для декількох секцій. Однак розробники різних відділів можуть не знати, що працюють над однаковими компонентами й мають змогу перевикористати те, що уже реалізовано. Подібні похибки вирішуються документацією чи дизайн-системою. Ми обрали другий шлях: винесли окремо всі компоненти, що повторюються, аби їх можна було перевикористати. Поки що все працює не ідеально, однак, думаю, що завдяки деталізації процесів та комунікації ми повністю позбавимося проблеми в майбутньому.
Буває так, що цілі на півроку сформовані, декомпозовані та розподілені на команду — і начебто все йде за планом. Однак минає кілька місяців — і ми розуміємо, що робимо геть інакшу роботу. На борді зафіксована купа різних тасок, але вони зовсім не збігаються з першочерговими цілями.
Виходить, що більш пріоритетні завдання витіснили першочергові цілі — і вони так і залишилися «на папері». За таких обставин виникає питання: «Чи справді це було важливо для бізнесу? Чи насправді вони необхідні для нашого функціонування, якщо кожного дня знаходилося щось важливіше?»
Тимлід має не лише розподіляти навантаження, давати рекомендації для покращення роботи та стежити за дедлайнами, а й ставити цілі своїй команді та дбати про розвиток людей.
Зазвичай програмісти не ставлять цілі самі собі, однак підвищення до тимліда передбачає нове завдання: стратегічні цілі потрібно декомпозувати в індивідуальні. Завдання із зірочкою — зробити так, щоб вони надихали команду та збігалися з особистими цілями кожного. Без досвіду подібний процес може бути складним та болючим.
Іноді складнощі в цілепокладанні спричинені оргструктурою. Наприклад, наша технічна команда розподілена на скводи відповідно до напрямів роботи бізнесу. На практиці різні люди з команди працюють над різними частинами проєкту. Хтось відповідає за функціонал для користувачів, хтось — за адмінку для тьюторів, за SEO або за фінанси та платежі. Минулого разу довелося постаратися, аби встановити цілі для людини у певному скводі, адже продакта, який міг сформулювати стратегічне бачення, куди ми рухаємося, не було.
На позиції розробника легко виміряти свою результативність — наприклад, у кількості завершених задач або написаного за один день коду. Однак якщо ви тимлід, усе складніше. Трапляється так, що увесь робочий день минає на зустрічах та обговореннях — і наприкінці здається, що нічого важливого зробити не вдалося.
Однак тут я знайшов для себе рішення. По-перше, результат тимліда полягає не лише в тому, що зробив безпосередньо він, а й у тому, до яких результатів прийшла команда під його керівництвом. По-друге, в деяких випадках написання коду взагалі не входить до обов’язків тимліда, він фокусується суто на управлінні людьми.
Коли розробник стає тимлідом, його робота та графік очікувано змінюються. Завдання програміста — розібратися у задачі, яку йому поставили, та зробити її якомога краще. Так, увесь робочий день можна витратити на написання коду, отримавши повідомлення від декількох людей щонайбільше.
На позиції тимліда інший челендж. Начебто так само є завдання, до яких потрібно підступитися, але зустрічі починають займати більшу частину календаря — і їхня кількість постійно зростає. Паралельно є купа повідомлень у чатах — і на них потрібно відповідати. У результаті до написання коду або вирішення технічних задач виходить дістатися в найостаннішу чергу.
Втім, тут потрібно зробити власний вибір та розставити пріоритети: розвиватися у бік people management чи ставати техлідером і поглиблювати технічні знання. Для мене вибір був неочевидним: з одного боку, подобалося вирішувати технічні завдання, а з іншого — я бачив перспективи у позиції тимліда.
