Вважаєте, що вже готові для нової ролі? Або навпаки — заслабкі для підвищення? Але чи це точно так? Зазвичай, ми схильні переоцінювати або додумувати недоліки і переваги лідерських позицій. І нам точно бракує розуміння, з чого насправді складається день наших старших колег.
Саме з цією думкою ми прийшли до Олександра Гілєвого, техліда команди Marketing Redskins, і розпитали про його кар’єрний шлях, звичні обов’язки й важливі навички для позиції техліда. Що з цього вийшло — читайте в матеріалі нижче.
Саша, скільки часу ти вже техлід? Розкажи, як виглядає твій типовий день?
На цій посаді я майже три роки. В мене є два типи тижнів, а не днів. Власне, ці два тижні складають наш спринт.
Перший тиждень спринту ми повністю інвестуємо в розробку запланованого функціоналу. Це дейлі зранку, зустрічі впродовж дня, сесії парного кодингу, зустрічі сам на сам з учасниками команди й під кінець дня — робота програміста.
Другий тиждень веселіший, бо він закінчується двома важливими активностями: демо поточного спринта та плануванням наступного.
Наша мета — зробити так, щоб система працювала настільки гарно, щоб QA плакав, а стейкхолдери аплодували
Щоби на демо «все зрослось», ми працюємо над якісним завершенням усіх задач. Наша мета — зробити так, щоб система працювала настільки гарно, щоб QA плакав, а стейкхолдери аплодували. Щоправда, так не завжди виходить. Тому іноді, після виконання всього беклогу спринта, ми ще виконуємо вправу відладки всього написаного (бо тести вже показують, що щось пішло не так).
Планування — ще одна цікава активність, до якої спочатку готується команда бізнесу, а я підключаюсь до пропрацювання концепцій пізніше, якщо це необхідно. Далі наші спільні результати презентуються команді, й ми вже всі разом декомпозуємо епік на завдання й готуємо спринт відповідно до поставленої цілі.
Типова робоча ситуація — на дейлі хтось каже, що в нього нічого не вийшло і потрібна допомога друга. Друга типова ситуація — на дейлі хтось каже, що все зробив, у нього все працює як ніколи, і не зрозуміло, чому це завдання на 3 SP, якщо воно вийшло за 0,5. Тут зазвичай теж потрібна допомога. Насправді я не часто відразу біжу допомагати. Наша команда доросла до такого рівня, коли кожен може сам вирішити ледь не будь-яку проблему. І подібні ситуації стають здебільшого винятками.
Цей день — такий собі технічний Діснейленд.
Якщо все пройшло, як по маслу, останній день спринта — технічний день. Кожен учасник команди займається, чим хоче. Точніше ми завжди попередньо маємо якісь побажання чи нереалізовані очікування від продукту. От у цей день кожен намагається розігнати улюблений пайплайн, оптимізувати найповільніший ендпоінт чи прикрутити Rmq туди, де його так не вистачало в тестовому середовищі. Цей день — такий собі технічний Діснейленд.
А як ти прийшов до цієї посади?
На третій тиждень випробувального терміну я вирішив, що можу робити більше, ніж просто навчатися, й знайшов місце для покращення в нашому коді. Зібрав необхідні інструменти, зробив простий прототип і показав своєму ментору. В той момент це виглядало дуже зухвало, але виявилося ефективним. І тут, як кажуть, “Остапа понесло”.
Мені часто хотілось більшого ніж просить бізнес; я знаходив можливості, які навряд колись потраплять в беклог, і реалізовував їх в робочий та позаробочий час - просто для себе, для фану. Це були різні інструменти моніторингу, масового обслуговування клієнтів, збір статистики, різні оптимізації швидкодії та ресурсів.
Кількість помилок не перевищує 0.05%. 5 років тому для нас це була якась магія.
А восени 2018 наша команда пішла на .NET Fest, де почула від одного розумного хіпстера про існування K8S і як цей стек забезпечує тисячі й десятки тисяч стабільних операцій за секунду. На той момент ми таким похвалитися не могли. Три місяці читання документації й гугла від “що таке .NET Core” до “навіщо в поді кілька контейнерів” і в нас з'являється мрія кожного студента — робочий фізичний прототип! Це три ноути на вінді, на яких крутиться наш сервіс, ми його навантажуємо, перезапускаємо фізично ноути, й кількість помилок не перевищує 0.05%. Тоді для нас це була якась магія. Цей пропотип прийняв в роботу бізнес і ми інвестували кілька місяців на те, щоб переключити роботу команди на новий стек. Закінчення цього проекту збіглося з ростом і нашої команди, і кількості обов'язків, і створенням нової команди в нашому підрозділі. Я отримав підвищення в межах своєї команди. Хлопці жартували, що нарешті я техлід офіційно.
Ти хотів бути техлідом? Твої очікування від позиції збіглися з реальністю?
Так, хотів. Мене цікавив не стільки статус, скільки можливість вибору технологій та процесів розробки. Про підвищення я не просив. Річ у тім, що в нашій компанії немає звичних рангів, як-то Junior, Middle, Senior; є розробники і TechLead. І я зовсім не був впевнений, що можу зайняти таку посаду. Але тим часом активно (й без дозволу) шукав можливості технічних покращень.
Підвищення було несподіваним і приємним; мене до нього не готували, не вчили ніяким кльовим «техлідським штукам», які я буду використовувати, коли «виросту».
Мене цікавив не стільки статус, скільки можливість вибору технологій та процесів розробки.
Від посади я очікував… нічого не очікував. Насправді перший робочий день у ролі ліда був такий же, як останній у ролі розробника. У мене вже була налагоджена комунікація з колегами з інших підрозділів і департаментів, тому я робив усе теж саме, просто тепер не як ініціативний розробник, а офіційно як техлід.
Був ще один цікавий сигнал: у моїй команді був розробник з більшим досвідом і він був старший за віком. Так от, майже відразу він почав ставитися до мене як до старшого товариша, хоча сам колись мене багато чому навчив у нашому продукті.
З яких ролей складається ваша команда і яка функція кожного? Як це відрізняється від стандартного скраму?
Наша команда ідеальна. Це 4 розробники, Automation QA, бізнес аналітик, Product Leader, а віднедавна ще Product Owner. Також наш улюблений і незмінний протягом багатьох років Scrum-майстер.
До складу розробників входжу і я. Ми займаємося реалізацією всього, що придумали представники бізнесу. Це проробка концептів рішень, створення архітектурних дизайнів, імплементація нових і підтримка й покращення наявних фіч (іноді десятки разів). А під час техднів команда розробки сама пропонує покращення продукту й сама їх реалізовує. По суті, ми показуємо бізнесу фічу вже в готовому вигляді: “дивіться, тут ми економимо 30 хвилин на кожній ітерації розробки/виконання процесу/серверного часу. Так, ми класно придумали, дякуємо”
Дивіться, тут ми економимо 30 хвилин на кожній ітерації розробки/виконання процесу/серверного часу. Так, ми класно придумали, дякуємо.
Product Leader, Product Owner і Вusiness Аnalyst нашої команди — це супер-експертки, які вміють гадати на статистиці та кастомер войсах, і знають, чого не вистачатиме цьому світові рівно в той день, коли ми закінчимо поточну фічу. Суть їхньої роботи — це пошук незаповнених ніш на ринку, опис потреб клієнтів та кінцевих користувачів такою мовою, щоби вони були зрозумілими одночасно і стейкхолдерам, і нашій команді розробки.
Product Leader займається більш глобальною візією розвитку продукту, довгостроковими планами та комунікацією з нашими партнерами щодо технічної та юридичної взаємодії.
Product Owner бере цю глобальну візію й деталізує її. Так вона створює епіки, які зможуть давати неперервний і стабільний інкремент продукту.
А Вusiness Аnalyst наповнює епіки супер точними технічними нюансами й деталями. Наприклад, як найкраще показати підказку користувачу так, щоби вона була зручна, привертала достатню, але не надмірну увагу, була повноцінна й не перевантажена текстом. Або який ендпоінт краще використовувати в черговій інтеграції, бо їй самій було цікаво, як це працює, і вона вже проговорила це з партнером до нашого першого рефайнмента.
Scrum-майстер — це людина, яка стежить, щоби «все, що має бути зроблено, було зроблено». А потім це показали на демо, провели ретроспективу й наступного разу зробили краще, ніж зараз. Continuous improvement наяву ☺️. А ще він займається покращеннями нашого життя, на які в нас немає або часу, або повноважень: організація тімбілдингів, збільшення потужностей локальної інфраструктури, мотивація в усіх проявах.
Що тебе радує або засмучує в роботі?
Найбільш щасливим мене зараз роблять дві ситуації: чорна п’ятниця й нові дуже вимогливі клієнти. Ми займаємось маркетинговими розсилками, тому чорна п’ятниця для нас — сезон підвищеного навантаження. Іноді в цей час ми збираємось біля дашборда моніторинга з пивом і піцою, дивимось, як тече трафік, як скейляться сервіси і як у нас знову нічого не зламалось. А нові клієнти — це завжди класно. У всіх різні вимоги, іноді бувають випадки, коли клієнт змушує нас швидко стабілізувати сервіс до навантажень, які ми раніше вважали нереальними й недосяжними протягом кількох років. Так було літом 2021. Ми підвищили пропускну здатність у 30 разів і цього вистачило на один день, бо новий клієнт затребував ще х50. Обожнюю завдання з оптимізації і стабілізації.
Ми підвищили пропускну здатність у 30 разів і цього вистачило на один день, бо новий клієнт затребував ще х50.
Найгірша ситуація, яку я пам’ятаю: джун, якого я менторив, виріс, але на той момент в нас не вийшло знайти якісне застосування його амбіціям. Тому він пішов працювати техлідом в іншу компанію. Це дуже круто й дуже сумно одночасно. На фінальній зустрічі ледь не плакали вдвох.
Які групи скілів і обов’язків має саме техлід? Які з них пріоритетні?
Здебільшого, аби стати техлідом, треба дуже серйозна технічна база. У нас в компанії техлідами стають ті, чиї імена починають асоціюватися з певними частинами системи чи технологіями. Тобто якщо тобі потрібна консультація по якійсь функції чи технології, ти йдеш до конкретної людини, а не до команди.
Але неофіційно цього спілкування дуже багато: з усім, з чим у команди не складається, ти допомагаєш домовитися й організувати.
Також, зі сторони може здатися, що на цій позиції не дуже потрібні софти. Наприклад, ”по книжці” техлідам не потрібно багато спілкування з людьми. Але неофіційно цього спілкування дуже багато: з усім, з чим у команди не складається, ти допомагаєш домовитися й організувати. Особисто я не знаю ні одного техліда, який би був не комунікабельним, або був неприємною особистістю.
Як найкраще розвивати скіли?
Я прихильник того, щоб навчатися з людьми, бажано офлайн. Наприклад, коли нашій команді захотілося якось розвиватися, ми зібрали так звані “Технічні літературні вечори”. Все в найкращих традиціях літературних клубів: один читає з першого по п’ятий розділ, інший з п’ятого по десятий і так далі. Але оскільки ідея взята з Бійцівського клубу, там має бути трохи “домінування і приниження”. Тому в своїх розділах ти шукаєш такі нюанси, в яких скоріш за все не розібрався ніхто з учасників клубу. І на зустрічі ти намагаєшся “завалити” своїх колег. Домовлятися до початку зустрічі не можна! Таким чином книжку на 1400 сторінок ми прогортали за півроку від А до Я. При цьому, почали гуглити, шукати щось таке, щоб все таки почеленджити колег.
Все в найкращих традиціях літературних клубів: один читає з першого по п’ятий розділ, інший з п’ятого по десятий і так далі. Але оскільки ідея взята з Бійцівського клубу, там має бути трохи “домінування і приниження”
Як зрозуміти, що ти готовий бути техлідом?
В мене в команді є один розробник, який п’ять років задавав купу питань: “Як? Що? Коли? Навіщо?”. І часто питання звучали досить незріло, хоча цей хлопець технічно дуже грамотний. А потім сталася така ситуація, коли він залишився єдиним старшим в команді. В якийсь момент він зрозумів, що більше нікого спитати, а відповідальність за всю команду покладена на нього. І раптом йому стало все чудово вдаватися.
Тому мораль: ти готовий стати техлідом, якщо ти не очікуєш ні від кого допомоги і розумієш, що все що треба вирішити, ти можеш вирішити сам. Більше того, ти готовий брати на себе відповідальність за результат цілої команди, допомагати колегам у розв’язанні складних питань і налагоджувати взаємодію з різними командами та департаментами.