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

1. інтерн
2. Що далі?
3. технічний експерт
4. Індустріальний експерт
5. фронтмен
6. тімліда
7. архітектор
8. Додатково: робота без посередників

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

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

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

інтерн

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

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

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

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

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

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

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

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

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

Таким чином:

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

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

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

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

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

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

Що далі?

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

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

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

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

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

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

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

фронтмен

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

тімліда

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

архітектор

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

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

Додатково: робота без посередників

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

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