Junior, Middle, Senior — у чому різниця та куди далі?

2 лютого 2018
Junior, Middle, Senior — у чому різниця та куди далі?

Привіт всім! Мене звати Олександр Демура, в IT я працюю з 2004 року, зараз керую центром розробки DataArt у Одесі (сам я з Пітера, але це — окрема історія). До моїх безпосередніх обов'язків входять найм та розвиток наших фахівців, тому міркування на тему «синьйoрності» співробітників і якостях, необхідних для тієї чи іншої ролі, для мене є актуальними і звичними. Дозволю собі традиційний дисклеймер — у цій статті викладений мій персональний погляд (на щастя, у DataArt так можна — необов'язково всім ходити строєм лінійкою). Написаний мною текст не претендує на істину в останній інстанції та навряд стане одкровенням для людей, які вже розбираються у питанні. Зате він буде корисний тим, хто тільки починає шлях в IT або не дуже розуміє, як і куди розвиватися далі, відчуває себе недооціненим або просто хоче розширити кругозір.

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

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

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

ІНТЕРН

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

  1. Хороша англійська.
  2. Розуміння обраного інструменту та вміння ним користуватись.

Вимога до знання англійської у нас, насправді, загальна для всіх. DataArt — міжнародна організація, більшість наших замовників знаходяться у США та Західній Європі, і навіть внутрішні комунікації вже все більше ведуться англійською. Якщо людина є грамотним технічним фахівцем, ми допоможемо розговоритися та підтягнути мову — для цього існують корпоративні курси та купа додаткових ініціатив. Але якщо людина без технічного досвіду (а інтерн якраз і є таким), ще й слабо знає англійську, їй потрібно володіти унікальними якостями, які перекриють обидва цих недоліки.

Думка про інструмент мені теж здається простою. Якщо ви приходите на роль програміста, інструментом для вас є мова програмування із засобами розробки, якими потрібно вміти користуватися. Якщо потенційний інтерн хоче розробляти на .NET, але не може пояснити, що робить CLR, чим “Equals” відрізняється від “==” або реалізувати найпростіший алгоритм — шансів у нього немає ніяких. Приходити з нульовими знаннями та сподіватися, що всьому навчать на місці, паралельно виплачуючи зарплату, марно — надто великий конкурс. За плечима багато кандидатів мають професійні курси, вони з легкістю відповідають на всі теоретичні запитання і навіть мають досвід програмування “для себе”. Звичайно, таких людей беруть в першу чергу.

Junior

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

Для джуна важливі такі якості:

  1. Бажання розвиватися та вчитися (а на своїх помилках — особливо).
  2. Енергія та цілеспрямованість.
  3. Здатність спокійно ставитися до критики.

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

Middle

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

Таким чином:

  1. Мідл-розробник розуміє, що саме робить додаток. Це дозволяє глибше зрозуміти задачу, а, значить, точніше її оцінити та якісніше реалізувати. Якщо вимоги не повністю покривають якийсь сценарій, хороший розробник зверне на це увагу на етапі планування. А не тоді, коли додаток почне валитися при будь-якій нестандартній дії користувача.
  2. Мідл-розробник знайомий зі стандартними шаблонами та рішеннями при побудові програми у своїй галузі, розуміє, навіщо вони потрібні, та вміє їх застосовувати. Стандартизація рішень має велике значення при колективній розробці коду, тому що дозволяє новій людині швидше розібратися, що до чого, та мінімізує кількість помилок. Розуміння структури типового додатку робить задачу його побудови з нуля досить тривіальною, дозволяє розміркувувати про принципи правильної реалізації та відрізняти хороший код від поганого.
  3. Мідл-розробник розуміє, що працює не один. Він вміє взаємодіяти з іншими членами команди: може обговорити складний момент із дизайнером, уточнити в бізнес-аналітика неповні вимоги або узгодити якесь важливе технічне рішення з архітектором проекту (якщо такий є) і, звісно, володіє відповідними інструментами колективної розробки.

Senior

Синьйор — досвідчений розробник, який побач багато коду, набив купу шишок і зумів зробити з цього правильні висновки. Основне завдання синьйора — приймати правильні технологічні рішення у проекті. “Правильні” — це такі, що приносять максимальну користь бізнесу та мінімізують витрати. Хороший синьйор не лише розуміє, що розробляє команда, але думає, які задачі має вирішити готовий додаток. Розробляючи майданчик для аукціону, синьйор завжди задається запитанням про пікове навантаження і намагається передбачити спроби конкурентного запису до таблиць БД. Він заздалегідь думає про вузькі місця системи, про можливості її масштабування, пам'ятає про уразливість і проблеми, викликані неправильним використанням інструментів.

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

Трохи поміркувавши, ми можемо сформулювати ряд особливостей синьйор-розробника:

  1. Здатність вирішувати декілька більш складних задач, робити це ш
  2. Звання синьйора неможливо отримати швидко. Потрібно напрацювати великий досвід і зрозуміти, що відрізняє добре зроблений продукт від тяп-ляп-розробки, як проявляє себе технічний борг, скільки коштує рефакторинг, навіщо насправді потрібні патерни, і чи такими вже необхідними є нескінченні рівні абстракції. Необхідно самостійно прийняти важливі рішення і дати їм пройти випробування часом, інакше оцінити їх не вийде.
  3. Синьйору необхідні хороші комунікативні навички, тому що він повинен не лише запропонувати правильне рішення, але й переконати у своїй правоті замовника та команду. Якщо ви не змогли відстояти хороше рішення і замість нього було прийнято погане, звинувачувати в цьому доведеться самого себе. Варіант “я ж казав” на рівні Senior вже не працює. З командою те саме — мало знати, як треба, потрібно ще й уміти це дохідливо пояснити. Тоді команда швидко зростає і набирається досвіду, уникаючи хворобливих помилок. Авторитарний підхід (“робіть, як я сказав”) часто призводить до внутрішніх конфліктів, і ситуацію на проекті аж ніяк не покращує — потрібно намагатися цього уникати.
  4. Синьйор не може обійтися без розуміння пристрою бібліотек і фреймворків. Якщо інструмент розробки для вас є чорним ящиком, і ви складаєте програму з готових частин, не знаючи, що в кожної з них під капотом, продукт завжди буде нестійким і непередбачуваним.

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

ЩО ДАЛІ?

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

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

Куди ж розвиватися синьйорам? Багато програмістів люблять розмірковувати про “стелю” — коли внутрішній рейт (тобто гроші, які ви отримуєте за роботу) наближається до зовнішнього (рахунку, виставленим клієнту за вашу роботу) з мінімальною маржинальністю. Вони вважають, що в цьому випадку подальше зростання фахівця стає недоцільним для роботодавця. Однак це не так, є безліч способів і далі збільшувати свою цінність (принаймні в DataArt). Тому позицію Senior Developer варто розглядати не як кар'єрне плато, а як плацдарм для подальшого розвитку, наприклад, в одному з наступних напрямків.

Технічний експерт

Статус технічного експерта передбачає глибоке знання окремої та специфічної області. Наприклад, можна бути експертом в Azure / AWS і знати різноманітні сервіси, які надають ці платформи. Вміти робити Machine Learning або Computer Vision, знати все про уразливості в інтернеті, розуміти, як працюють криптовалюти або як правильно готувати Sharepoint. Такі завдання зустрічаються не щодня, але, коли з'являються, настає зоряний час технічних експертів. Без них подібні проекти були б просто неможливими, і компанія часто готова доплачувати за ці унікальні знання.

Індустріальний експерт

DataArt старається розвиватись у певних доменних областях (подорожі, фінанси, охорона здоров'я тощо). У кожному проекті програмісти не лише набувають власне технічних знань, але й отримують можливість зазирнути до бізнесу замовника, зрозуміти, як влаштована індустрія, дізнатися характерні для неї проблеми та рішення. Чого коштує побудувати свою платіжну систему на зразок PayPal? Навіщо потрібна система Sabre? Або що таке HIPAA, та які обмеження вона накладає на розробку рішень у галузі охорони здоров'я у США? Люди, які володіють подібними знаннями, часто формують кістяк проекту та приносять компанії і клієнту величезну додаткову користь. Тому їхня компенсація може перевищувати зовнішній рейт — компанії самі готові доплачувати таким людям більше рахунку, виставленого замовнику проекту.

Фронтмен

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

Тімлід

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

Архітектор

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

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

ДОДАТКОВО: РОБОТА БЕЗ ПОСЕРЕДНИКІВ

Я хочу окремо написати про роботу без посередників, яку дехто сприймає як Святий Ґрааль для програміста. Здавалося б, все логічно: знаходимо замовника, надаємо йому свої послуги безпосередньо, весь рейт забираємо собі — профіт! Однак потрібно розуміти, що, крім прибутків, на програміста в цьому випадку падають всі супутні ризики. Потрібно уважно читати пункт контракту про відповідальність сторін, знати законодавчу та податкову базу, придумувати механізм отримання грошей, діяти, якщо клієнт не заплатив або несподівано згорнув роботу. В DataArt ці питання вирішують спеціально навчені люди (продавці, юристи, бухгалтери), і навіть якщо замовник розорився і вийшов з бізнесу з божевільними боргами, розробники все одно отримають гроші вчасно та спокійно перейдуть у наступний проект. При роботі безпосередньо — кожен сам за себе. Крім того, більшість компаній витрачають досить відчутні бюджети на залучення нових клієнтів, тому прямі відносини з замовниками, яких знайшла компанія, заборонені контрактом з того чи іншого боку.

На цьому мені хочеться закінчити на сьогодні, якщо є нові ідеї для статей — пишіть!