Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

«Бути штурманом — це важлива роль». Engineering-менеджер Nubank — про особливості своєї посади та реакцію на «божевільні ідеї» розробників

Ми випускаємо перший епізод нового подкасту про Engineering-менеджмент — Going Beyond Development, у межах якого запрошуватимемо досвідчених Engineering-менеджерів з різних куточків світу. У цьому випуску ми занурилися у сутність позиції Engineering-менеджера, дослідили, чим саме він займається та які виклики й можливості є на цій посаді.

Ми поспілкувалися із Тьяго Гісі, Engineering-менеджером в Nubank. У випуску Тьяго пояснив, чому обрав цю роль, і розповів про свій типовий робочий день.

👉🏼 Підписуйтесь на YouTube, щоб не пропустити нові епізоди

«Я став сполучною ланкою між програмістами та проджект-менеджерами». Про те, чому став Engineering-менеджером

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

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

Коли я повністю перейшов на посаду Engineering-менеджера, життя стало набагато простішим, тому що я все ще був Senior-програмістом, відповідав за свої завдання, але й виконував багато функцій Engineering-менеджера, бо мені це вдавалося.

«Engineering-менеджер — це той, хто матиме здоровий глузд і скаже: „Я бачу, що це складно“». Про те, чим займається Engineering-менеджер

Ця позиція відрізняється від позиції проджект-менеджера. Engineering-менеджер відповідає за чотири великих виміри:

  • По-перше — це платформа, йдеться про технічні навички людей, але вони мають інший фокус.
  • По-друге — це продукт або доставка продукту.
  • По-третє — процес (про поєднання усього, що ви збираєтеся використовувати).
  • І останній пункт — управління людьми. Це вже стосується розвитку фахівців, проведення зустрічей.

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

Якщо порівнювати з проджект-менеджером або традиційним TPM (Technical Program Manager), вважаю, що позиція інжиніринг-менеджера більше сфокусована на делівері та процесі, а не на управлінні людьми та платформами. І коли я говорю про платформу, то маю на увазі когось із технічних спеціалістів, але не того, хто пише код. Це хтось, хто буде мотивувати.

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

Якщо хтось прийде з божевільною ідеєю, Engineering-менеджер — це той, хто матиме здоровий глузд і скаже: «Я бачу, що це складно. Це проєкт не на один тиждень, а місяці на три, тому що є такі й такі причини». Ця людина бачить загальну картину.

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

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

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

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

Я вважаю, що гарні TPM здатні керувати платформою та людьми, але вони не несуть за це відповідальність. Це складніше завдання. Деякі TPM здатні впоратися з цим і можуть стати Engineering-менеджерами, змінивши деякі налаштування. Але, на мою думку, основна відповідальність TPM — реалізація процесу розробки, його розуміння. ТРМ має розуміти користувацький досвід, ризики для зацікавлених сторін, особливості внесення змін, усі залежності між змінними.

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

А ще — виправити незначні помилки. Залежно від розміру ланцюжка, Еngineering-менеджер може навіть виконати деякі невеликі технічні функції. Натомість проджект-менеджери здебільшого не вміють правильно налаштувати ідентифікацію; не знають, як запустити термінал.

У цьому різниця. Розробники не мають такого досвіду, щоб усе поєднувати. Engineering-менеджер — це той, хто пройшов цей шлях, скажімо, від Junior, Middle до Senior, а потім, можливо, і до керівних ролей. І він може допомогти програмістам розвиватися, давати їм завдання, які дещо виходять за межі їхньої зони комфорту, щоб спонукати проявляти ініціативу.

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

Якщо у вас є глибокі знання; ви знаєте, що відбувається в житті співробітників, то як гарний TPM ви зможете краще ставити завдання, що відповідає їхнім пошукам, мотивації, враховує те, чого фахівці хочуть навчитися. І я думаю, у ТРМ та Engineering-менеджерів різні фокуси під час побудови відносин сам на сам.

«Я помітив, що сьогодні багато компаній більше не мають TPM». Про те, які компанії потребують Engineering-менеджера

Я помітив, що сьогодні багато компаній більше не мають TPM. У них є Engineering-менеджер і, можливо, продакт-менеджер. Ці двоє здатні охопити весь спектр задач. Є команди, де є лише проджект-менеджер, технічний проджект-менеджер, розробники. Вони приходять, щось роблять, потім переходять до наступного проєкту. Така закономірність.

Інший варіант, коли продакт-менеджер вміє створювати користувацький інтерфейс, дорожню мапу тощо. Engineering-менеджер може керувати проєктом як TPM, а також дивитися на платформу, на людей, і в майбутньому це може добре працювати.

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

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

«Мета Engineering-менеджера — створити гарне середовище». Про те, яким є типовий робочий день Engineering-менеджера

Кілька років тому я прочитав книгу «168 годин» Лаури Вандеркам. Авторка запропонувала відстежувати особистий час кожні 15 хвилин, не лише під час роботи.

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

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

Я робив це як Engineering-менеджер ще у 2019–2020 роках. І щодня витрачав час на... перегляд звичайного коду. Якщо поглянути на чотири виміри, про які я згадував, думаю, 33% робочого часу йде на особисті зустрічі з фахівцями. Не лише з прямими підлеглими, а й з колегами з інших відділів, а також з менеджерами чи керівництвом.

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

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

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

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

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

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

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

«Ви маєте йти попереду змін». Про управління продуктивністю

Є ще два важливих моменти. Перший — управління продуктивністю. Тобто постановка цілей з фахівцями на індивідуальному рівні та на рівні команди, планування дорожньої карти. І для платформи, і для продукту. Як Engineering-менеджер ви також обмірковуєте та готуєте документи про те, що відбуватиметься протягом наступних шести місяців.

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

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

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

Як Engineering-менеджер ви маєте пересвідчитися, що у вас є стратегія розгортання. Що станеться, якщо нам потрібно буде відмовитися від цього? Як зробити відкат або дізнатися, чи можна збільшити трафік? Чи впливає це на бізнес? Це обговорюєте із зацікавленими сторонами. Також потрібно фільтрувати все, що до вас надходить, щоб керівник ланцюга не відволікався.

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

«Якщо раніше ви щоденно програмували, ви ніколи цього не забудете». Про технічний розвиток Еngineering-менеджера

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

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

Але головне — ви все ще зможете це робити. І цим треба буде займатися, але не щодня. У вас фокус інший.

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

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

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

Інша модель, яку я бачив: Engineering-менеджери, які займаються парним програмуванням, але вони ставлять себе на друге місце. Річ у тім, що менеджеру легко сказати: «О, привіт, Джоне, давай разом покодимо». А тоді Джон виконує роботу, а ви просто спостерігаєте як штурман.

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

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

Я спостерігав тенденцію переходу СТО до ІС (individual contributor’а). Не знаю, наскільки вона тривала. Думаю, що горизонтально переміщуватись набагато простіше, оскільки шляхи штатного програміста та Engineering-менеджера перетинаються. Нещодавно співзасновник Nubank, наш технічний директор, повернувся на посаду програміста, оскільки він майстер в цьому.

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

Підписуйтесь на наш YouTube, щоб не пропускати нові випуски.

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному1
LinkedIn

Схожі статті




Немає коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Підписатись на коментарі