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

Перехід з розробника до технічного ліда: навички та скіли, які варто розвивати

Привіт, мене звати Владислав Кушней, я працюю на позиції Salesforce Technical Lead у компанії Newage. У цій статті хочу поділитись своїм досвідом і розкрити деякі аспекти ролі техліда, а також поділитись своїм баченням, які навички потрібні для цієї ролі.

Початок роботи і прихід на позицію ліда

Станом на сьогодні у мене 7+ років досвіду роботи з Salesforce, останні 3 роки на позиції техліда.

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

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

Наш Salesforce відділ налічував максимум 8-9 розробників, час від часу набирали трейні, навчали їх, і з часом люди розходились, хто куди. Модель роботи була така, що кожен розробник мав закріпленого консультанта з Нідерландів, який ставив задачі з розробки. Проєкти в основному були малі — від пів року до року, по 1-2 розробники на проєкті.

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

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

Різні варіанти командної роботи

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

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

Так я опинився у своїй нинішній компанії. 15-хвилинне знайомство з CTO в середу ввечері, наступного вечора — співбесіда і офер. Компанія запускала напрям Salesforce з нуля і шукала людину, яка очолить його. Ми зібрали команду з п’яти розробників, двох тестувальників, бізнес-аналітика, менеджера і сапорт-інженера.

Роль техліда в команді, зібраній з нуля

Нашим першим клієнтом був існуючий партнер компанії, якому була потрібна CRM-система для нової трейдингової платформи. Ми взяли готовий проєкт, зроблений на аутсорсі іншою компанією, поміняли процес розробки з ANT на sfdx, побудували власний CI процес, підняли якість коду, включивши статичний аналізатор PMD і форматтер Prettier в CI процес. Тут мені вперше довелось розбиратись із Gitlab CI, оскільки на попередніх проєктах або був уже готовий налаштований процес, або його не було, але і потреби в ньому також.

Моя роль кардинально відрізняється від поперднього досвіду, тому що тут треба будувати експертизу з нуля. У всіх попередніх компаніях уже була встановлена певна культура роботи, певні принципи за якими ведуться проєкти, була сформована спільнота з певним рівнем стандартів. У мене нарешті з’явилася можливість застосувати best practices, про які читав в книжках, але яких не було на попередніх проєктах.

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

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

За цей час я добре зрозумів, що хороший техлід — це передусім експерт, який не боїться імпровізувати, вчитись на ходу, адаптовуватися до різних ситуацій і т. д. Відома цитата «A smooth sea never made a skilled sailor», дуже влучно описує роль техліда , хіба що не sailor, а captain.

Коли ти працюєш у ролі розробника, є перелік задач, які ти маєш виконувати, а твоя зона відповідальності — від user story в jira до гілки в репозиторії. Коли ти в ролі техліда, твоя зона відповідальності — весь проєкт. (В деяких командах є ролі «архітектор», «тимлід», «техлід», але в цій статті в термін «техлід» я вкладаю усі три, і кордони між ними прибираю). Потрібно розуміти проєкт на різних рівнях.

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

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

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

Які навички розвивати техліду

Спираючись на свій досвід, я сформулював наступний список навичок та принципів, які необхідно розвивати технічному ліду:

  1. Закласти в команді правильну філософію (джерело — книжка «Pragmatic programmer», розділ 1. Прагматична філософія, розділ 2. Прагматичний підхід). Коли техлід і команда на одній хвилі, то працювати набагато легше.
  2. Усім розробникам я рекомендую прочитати книжку «Pragmatic programmer» — це нестаріюча класика, це філософія і принципи, які не змінюються з часом. Розкажу деякі пункти коротко. Розробка ПЗ — це більше садівництво, аніж будівництво будинку, де немає поступових етапів, а є код, який постійно еволюціонує і змінюється. Ентропія завжди збільшується. Потрібно знати, до чого призводять «розбиті вікна», треба шукати баланс між «ідеально» і «достатньо добре для реального світу».
  3. Проактивність. Є така приказка: «Під лежачий камінь вода не тече», так ось це — на 100% відображає позицію техліда. Чому так — пояснювати не стану, якщо цікаво, шукайте статті про це в інтернеті, цей принцип застосовується до всіх лідерів, не тільки в розробці ПЗ.
  4. Стресостійкість і стійкість в цілому. Не піддаватись тиску клієнта, який просить додати ще одну фічу в реліз, якщо це вплине на якість продукту в цілому; адекватно сприймати випадки, які можуть нести якийсь емоційний фон (наприклад команда тиждень не може пофіксити баг, задачі вилазять за рамки попередніх оцінок). Якщо є код, який потрібно рефакторити перед тим, як розробляти новий функціонал, то команда має зробити рефакторинг в першу чергу і розуміти для чого це. Проєкт повинен мати здоровий розвиток і не піддаватись кліматичним умовам, бо будуть «розбиті вікна» — ви вже маєте знати, до чого вони приводять.
  5. Знати, чому проєкти помирають; чому важливо закласти правильну архітектуру на початку проєкту; як розробляти продукт, який не піддається старінню; чому інтерфейс користувача має посилатись на бізнес правила, а не навпаки; що таке сильна і слабка зв’язність; принципи дизайну ПЗ і тд. Про це уже написана ціла книжка, тож переписувати її тут не буду. «Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin Series)». Цей пункт чимось перетинається з першим, але перший більшою мірою про філософію в команді. Натомість цей — про досвід попередніх розробників і знання, які є в індустрії, незалежно від технології.
  6. Вміння делегувати. Останній у списку, але не за важливістю, пункт. Незважаючи на бажання завжди зробити все ідеально, потрібно прийняти той факт, що часу на все не вистачить, ідеально усе зробити неможливо, і розробники, яким техлід делегує задачі, можуть мати інше бачення і зроблять по-іншому. Тому, треба знати, кому які задачі можна давати, як передавати своє бачення реалізації, і чого очікувати.

Замість висновків

І ще кілька слів про мотивацію.

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

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

Я знаю, що таких проєктів не існує, що це — утопія, але принаймні до того варто прагнути. Shoot for the moon. Even if you miss, you’ll land among the stars.

Наостанок, мої рекомендації літератури:

  1. Andy Hunt, Dave Thomas — The Pragmatic Programmer.
  2. Robert C. Martin — Clean Architecture.
  3. Jim C. Collins — Good to Great.
👍ПодобаєтьсяСподобалось9
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
твоя зона відповідальності — від user story в jira до гілки в репозиторії

Щодня бачу таку «зону відповідальності» в результатах роботи багатьох програм. Іноді хочеться когось буцнути. Чимось важким.

Моя позиція — зона відповідальності джуна може обмежуватись «від user story в jira до гілки в репозиторії», зона відповідальності команди розповсюджується і на UX. Тобто, треба хочаб трішечки розуміти юзера, інтерфейс і як воно все має взаємодіяти. І, якщо ти бачиш хаос і нонсенс, треба про це як мінімум сказати на колі з командою, якщо команда згодна — на колі з клієнтом.

Іноді це навіть працює і вдається внести зміни на краще. Це краще, ніж обмежуватись зонами відповідальності (по суті така зона відповідальності — це обмеження власної відповідальності і дозвіл на безвідповідальність — мені сказали так зробити, я так і зробив, хоча розумію, що це призведе до проблем). IMHO.

Якби всі робили «як правильно» а не «на, відчепись» («я зробив як в тасочці написано»), то і проблем з софтом було б менше. IMHO.

Коли начальник не погоджується на правильно, наступного разу будуть робити на відчепись

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

Дякую за коментар, саме в Salesforce не можу виділити чогось особливого про архітектуру. Загальні принципи ті ж, що і всюди: починати з порядку в коді, зменшувати звʼязність між компонентами, там не її не потрібно, керувати залежностями — користувацький інтерфейс залежить від бізнес-правил, а не навпаки. Що стосується інтеграцій з іншими системами — СФ з коробки має стандартний API, плюс можна доробляти кастомний. Основне — use right tool for the job. А так, не доводилось ще працювати на проектах із великою складною архітектурою, або там де вищезгадані принципи не працюють. А малювати чи не малювати діаграми — це залежить від того, які процеси на проекті. Раніше бачив і прості проекти з діаграмами, і складні проекти без діаграм, без діаграм звісно трохи важче. А так в цілому UML рекомендую вивчити.

Мотивація повинна в першу чергу бути пов’язана з любов’ю до своєї справи.

Саме так! Того, в кого горять очі, можна навчити і мови, і фреймворків і чого завгодно. А той, хто може це все вже і знає, але йому пофігу — проєкт не витягне.

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