Як Unity-розробнику побудувати кар'єру: розбираємо на прикладі команди RAID: Shadow Legends

Оригінал статті опубліковано на DOU.

Привіт! Я Ігор Степанов, Senior Team Lead у Plarium. Я керую командою тім- та техлідів та відповідаю за технічний стан клієнтської частини проєкту RAID: Shadow Legends.

На старті кар'єри я не мав повного уявлення про варіанти розвитку Unity-розробника. Перші проєкти були невеликі, а теоретичні знання не давали розуміння, що потрібно для вирішення складніших завдань.

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

На прикладі команди клієнтського розроблення Raid: Shadow Legends я опишу варіанти розвитку для Unity Developer. Погнали!

З чого почати будувати кар’єру

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

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

Припустімо, у нас є розробники Боб, Джо та Ларрі. У точці «0», на старті кар'єри, кожен з них почав із базового горизонтального та вертикального рівня. Боба цікавило виключно вертикальне зростання, Джо – горизонтальне, а Ларрі хотів оптимального розвитку кар'єри.

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

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

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

Глобальний вектор розвитку – локальні кроки в компанії

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

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

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

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

Горизонтальний розвиток

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

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

Стежте за своїм станом і періодично ставте собі такі запитання:

• Чи виконую я завдання на стабільно високому рівні?
• Чи згодні з цією оцінкою мій керівник і команда?
• Які ще є потреби проєкту та компанії?
• Чим із цього мені б було цікаво займатися?

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

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

Які є варіанти горизонтального розвитку

Для нашої команди ми окреслили варіанти розвитку у форматі спеціалізацій. Це дозволяє об'єктивно та прозоро відстежувати процес розвитку кожного розробника.

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

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

Як відбувається адаптація в новій спеціалізації

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

На кожній спеціалізації у нас є мінімум 2–3 розробники. Це дозволяє планувати навантаження так, щоб у разі відпусток, лікарняних та форс-мажорних ситуацій у нас не з'являлося прогалин, які немає кому закрити.

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

Спрощена візуалізація моїх рекомендацій щодо організації стратегії горизонтального зростання:

Вертикальний розвиток

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

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

• технічні виклики та активний розвиток хард скілів;
• менеджерські виклики та активний розвиток софт скілів.

Жоден із напрямів не виключає розвиток в іншому. Вибравши напрямок тімліда, ви не перестаєте розвиватися технічно. А обравши напрямок техліда, ви в будь-якому разі будете розвивати адміністративні навички.

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

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

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

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

Візуалізація щодо організації стратегії вертикального зростання:

Як отримати навички для вертикального зростання

Менторство

Якщо в перспективі ви хочете стати тех- або тімлідом, то менторство нових співробітників або адаптація розробників у нових спеціалізаціях – це демоверсія.

Менторство – чудова можливість спробувати вивести адміністративні та технічні навички на новий рівень. Під час процесу пояснення ви самі вчитеся структурувати знання. А відповідальність за результати роботи іншого фахівця допомагають оцінити та прокачати свою готовність до вертикального зростання.

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

Фіча-лід

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

Обовʼязки фіча-ліда передбачають:

• оцінювання, декомпозицію та реалізацію фічі у встановлені терміни;
• організацію та розподіл роботи між собою та розробниками;
• взаємодію з командами та фахівцями, що беруть участь у процесі: Project Managers, QA, Technical Artists, Game Designers.

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

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

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

Які є варіанти вертикального розвитку

Тімлід

Позиція тімліда передбачає менеджмент команди розробників. Тімлід бере відповідальність за релізи, розвиток команди та вдосконалення процесів.

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

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

Поясню на такому прикладі. Розробник шукає оптимальний спосіб виконати завдання, а тімлід попередньо має зʼясувати, чому зараз саме це завдання – найкращий спосіб розвʼязати проблему. Product owner своєю чергою визначає, які проблеми має сенс вирішувати та з яким пріоритетом.

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

До ваших обов'язків належатиме побудова стратегії розвитку кожного зі співробітників. Одним із найважливіших показників якості роботи буде стан та прогрес вашої команди.

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

Техлід

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

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

Вам потрібно розв'язати проблему, а тімліду – ефективно залучати та розвивати команду. Разом, обговорюючи потреби та пріоритети команди та проєкту, ви зможете побудувати оптимальний план для ефективної роботи департаменту та проєктів.

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

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

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

Ротації

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

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

У нас у компанії є успішні випадки ротацій із Technical Artist, QA і локалізатора в розробники, а також навпаки – з розробників у Technical Artist або просто в інші департаменти. Деякі Unity-девелопери переключались на серверну частину або кардинально змінювали область діяльності.

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

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

Ваша кар'єра – це ваша відповідальність

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

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

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

Усім прозорого та стрімкого розвитку!