«Давай ты будзеш лідзіць». Куды расці сеньёру і ці трэба — тлумачыць Павел Вейнік

Хто такі сеньёр

Давайце вызначымся з паняццем «сеньёр». У маім разуменні гэта «дасведчаны дзядзька», здольны выканаць самую або амаль самую складаную задачу на праекце. Ён здольны пагутарыць з пастаноўшчыкам задач, спраектаваць і давесці задачу да прадакшану, пакрыць яе тэстамі і г. д.

Што ён робіць

Калі мідл выконвае толькі кавалачак задачы, то сеньёр, як правіла, адказвае за задачу цалкам. Гэта ж і робіць яго сеньёрам.

Яшчэ сеньёр можа ментарыць, дзяліцца досведам, але галоўнае — ён у стане выканаць складаную задачу ў рамках сістэмы. Ён разумее мэту праекта, архітэктурныя прыёмы, знае кантэкст сістэмы і, зыходзячы з гэтага, прымае рашэнні.

Чаго не робіць

Сеньёр не размяркоўвае задач і не праектуе ўсёй сістэмы — толькі невялікія яе кампаненты. Ён, як правіла, не вядзе камунікацыі з бізнэсам, зона камунікацыі сеньёра — цімлід, продакт оўнар, аналітык, каманда.

Ці трэба яму расці?

Наогул дык неабавязкова.

Але што, калі развівацца ўсё ж такі хочацца

Тады ў сеньёра ёсць два шляхі:

1. Менеджарскі: цімлід — інжынірынг-менеджар — кіраўнік аддзела — кіраўнік напрамку і г. д.
2. Тэхнічны: сеньёр — умоўны тэхлід / very important распрацоўшчык / хтосьці такі (тэхнар яшчэ мацнейшы, чым сеньёр, але ўсё яшчэ займаецца большай часткай кодам) — архітэктар — СТО.

Што не так з кар’ерай менеджара

Часта інжынеры думаюць, што раз яны паспяхова працуюць у камандзе, то папросту могуць ёю кіраваць. Я пра кейсы, калі маладыя амбіцыйныя сеньёры, жадаючы стаць важнымі людзьмі, бяруцца за ролю цімліда і за год выгараюць — такіх я бачыў шмат. Калі ў неспрактыкаванага цімліда без кіраўнічых скілоў нешта атрымліваецца інстынктыўна, то яму знатна пашанцавала.

Праблема ў тым, што ў распрацоўшчыка няма ні менеджарскага досведу, ні разумення, што такое менеджмент у прынцыпе. Бо ў цімлідзе палова ад сеньёра, палова ад менеджара. І навыкі, неабходныя цімліду, знаходзяцца ў квадраце неўсвядомленага невядомага.

Але калі ў вас добра атрымліваецца кіраваць і каманда расце, то з цімліда можна вырасці ў інжынера і кіраваць ужо некалькімі камандамі, забяспечваючы іх сінхранізацыю, матывацыю і г. д. Па гэтай сцежцы можна расці даволі доўга.

Што праўда, ёсць нюанс. Калі чалавек дарос да сеньёра, значыць, у яго нармальныя інжынерныя здольнасці. Выбіраючы менеджарскую галіну, ён ступае на новы кар’ерны шлях, адмаўляючыся ад росту ў тэхнічным плане. Свядома такі выбар робяць нямногія.

Чаму тэхнічная галіна прывабнейшая (суб’ектыўна)

Большасць сеньёраў выбіраюць іншую галіну — тэхнічнага развіцця. У яе як мінімум дзве перавагі. Па-першае, яна хутчэй за ўсё адпавядае ўжо наяўнай прафдэфармацыі характару сеньёра. Па-другое, моцныя інжынеры атрымліваюць прыкметна больш за інжынераў-менеджараў.

На тэхнічную галіну часта вяртаюцца і тыя, хто паспрабаваў сябе цімлідам і зразумеў, што гэта не яго. Часта на гэтым этапе сеньёр яшчэ не разумее, куды і як расці. цімлідства яму больш не хочацца: грошы тыя ж, гемарою больш, цікавасці менш. Але душа чагосьці просіць: больш складаных задач, грошай, цікавых праектаў.

Дагэтуль сеньёр рос, вывучаючы тэхналогіі, базы даных, фрэймворкі для праектаў. І вось ён разумее, што можна вывучыць яшчэ пяць фрэймворкаў, тры базы даных, пакарыстацца яшчэ адным клаўдам, але зместу і сэнсу працы гэта ніяк не зменіць. Так узнікае шкляная столь — перш за ўсё скіловая. Бо скілы за кошт асваення новых тэхналогій наогул не растуць — яны застаюцца тымі ж, проста прымяняюцца да іншых рэчаў.

Як узляцець вышэй за столь

Столь можна пераадолець, узяўшы на сябе больш адказнасці. Дапусцім, задрайвіць нейкую вялікую крос-камандную фічу.

Калі рашэнне пачынаюць рэалізоўваць, такому «вялікаму і тлустаму» сеньёру могуць выдзеліць Program Manager, які будзе сачыць за тым, каб розныя аспекты фічы былі злітыя ў адно.

Так сеньёр дзеля інтарэсаў бізнэсу выходзіць па-за межы сваёй каманды і ператвараецца ў тэхліда / Staff Engineer / Principal Engineer / Very Important Engineer. І далей развіццё ідзе ў бок Software Architect, Solution Architect — аж да СТО.

Камунікацыя

На гэтым шляху інжынеру неабходна камунікаваць, камунікацыя ў яго працы займае больш часу, чым тэхнічныя рашэнні. Прычым камунікацыя не менеджарская, а тэхнічная. І чым далей сеньёр будзе прасоўвацца па тэхнічным шляху развіцця, тым больш у яго будзе камунікацыі, як гэта ні парадаксальна.

Важная частка софт-скілоў такога спецыяліста — павялічваць імпакт, змяняць арганізацыю або сістэму, у якой ён працуе. Ён бярэ на сябе адказнасць і за кошт сваёй энергіі рухае нейкія фічы.

Кругагляд

Акрамя камунікацыі тэхліду патрэбныя новыя архітэктурныя навыкі — сістэмны дызайн і інструменты: базы даных, чэргі, кэшы, балансіроўшчыкі. Ён мае разумець, як звязаць розныя часткі сістэмы, каб яна і працавала, і падтрымлівалася. Да важных скілоў адносіцца і праца з вялікай нагрузкай, бо такія задачы, як правіла, узнікаюць на вялікіх сістэмах.

Прычым тэхлід мае не вывучаць базу даных або фрэймворк дасканала, а ўяўляць, якія наогул ёсць інструменты, тэхналагічныя прыёмы, шаблоны, абмежаванні розных падыходаў. Яго задача — правільна абраць інструменты, а каманды ўжо вывучаць (калі яшчэ не) іх дэталёва.

Сеньёр выбірае знаёмую базу даных або фрэймворк, таму бо яму так камфортна. Яму здаецца, што звычайная рэляцыйная база даных спатрэбіцца, хоць насамрэч калоначная або Key-value падыдзе лепш. Але ён пра гэта не ведае, бо досвед нават наймацнейшага сеньёра рэдка перавышае веданне 5-7 баз даных, уключаючы воблачныя.

Яшчэ — разнастайныя in memory кэшы, балансіроўшчыкі, сэрвісы, заснаваныя на DNS-інфраструктуры, сістэмы для размеркаванай апрацоўкі і захоўвання даных, інфраструктурныя рашэнні для балансавання і эластычнасці, шаблоны праектавання размеркаваных сістэм, падыходы, якія працуюць з кансістэнтнасцю даных. Гэтыя рэчы трэба вывучаць мэтанакіравана і загадзя.

Што пашырае кругагляд? Чытанне артыкулаў, кніг, абмеркаванне Building Data Intensive Applications, сайты Марціна Клепмана і Марціна Фаўлера, Reddit, у рэшце рэшт. Але важная структура гэтых ведаў. Не проста «я ведаю 250 тэрмінаў, давайце прыменім з іх выпадковыя» — трэба разумець абмежаванні кожнага падыходу, як маштабаваць сістэму і зрабіць з яе BASE (Basically Available, Soft state, Eventually consistent).

Калі сеньёр за кошт софт-скілоў і кругагляду пераскоквае на ўзровень тэхліда / Staff Engineer, у яго адкрываюцца магчымасці расці далей, на ўзровень Solution Architect.

Solution Architect

Solution Architect — гэта чалавек, які разумее бізнэс. Ён можа паразмаўляць з бізнэсам на яго мове, потым за кошт разумення архітэктуры размеркаваных сістэм пераўтварыць гэтую размову ў тэхнічныя задачы, стварыць design праекта (або даручыць яго) і, нарэшце, растлумачыць усё камандзе.

Маштаб задач у яго большы, чым у тэхліда. Калі тэхлід працуе з вялікімі кавалкамі сістэмы, то Solution Architect праектуе сістэму цалкам. Яго праца ітэратыўная. Яму патрабуюцца і навыкі камунікацыі, і stakeholder management, і кіраванне патрабаваннямі, і system design, і ўменне абгрунтаваць выбар рашэння.

Solution Architect можа расці, прапаноўваючы ўсё маштабнейшыя рашэнні для бізнэсу. Вось ён ужо робіць не проста карпаратыўную сістэму на 250 карыстальнікаў, а SAAS-сэрвіс на 250 запытаў на секунду, і гэтая сістэма сусветнага маштабу.

Далей магчымы рост у тэхналагічную стратэгію ўсёй кампаніі. Архітэктар разумее, што яго сістэма праз тры гады будзе вось такой, таму закладвае вось такія магчымасці, узгадняючы іх з мэтамі, прыярытэтамі і рызыкамі бізнэсу.

Тут ён падбіраецца да ролі Chief Information Officer або Chief Technical Officer. Для яе патрэбны не толькі кругагляд і ўменне абгрунтоўваць аптымальны выбар, але і ўменне працаваць у вялікіх арганізацыях.

У каго яшчэ можа вырасці сеньёр

Ён можа стаць проста вельмі моцным сеньёрам, distinguished інжынерам, спазнаўшы нейкія рэчы да глыбінь, напрыклад, за колькі мілісекунд дае водгук Amazon ElastiCache і як гэта можна выкарыстоўваць. Пры гэтым ён застаецца сеньёрам, бо не валачэ нейкіх змен у рамках кампаніі, а проста крута рэалізуе складаныя рэчы.

Часам я вылучаю яшчэ адну разнавіднасць сеньёра на шляху да тэхліда — Software Architect. Ён падобны на distinguished інжынера, гэтак жа глыбока знае тэхналогію, пры гэтым яшчэ і праектуе архітэктуру невялікай задачы.

Як правесці мяжу

На практыцы межы паміж статусамі сцёртыя. У розных кампаніях пад адным і тым жа тайтлам разумеюць рознае. Мы можам звацца сеньёрам, а выконваць функцыі архітэктара. Або звацца Staff Engineer, а насамрэч быць сеньёрам. Цімлід можа адначасова быць і менеджарам, і архітэктарам, і сеньёрам, і бізнэс-аналітыкам. Такое таксама бывае. Але на шляху ад сеньёра да тэхліда ёсць прынцыповы скачок. І важны не тэрмін, а прынцыповыя адрозненні паміж ролямі.

У якіх кампаніях лепш расці і як

Любы сеньёр пры наяўнасці амбіцый можа развівацца самастойна, займаючыся самаадукацыяй і праяўляючы ініцыятыву. Але не ва ўсякай кампаніі ёсць патрэба ў архітэктурных рашэннях. Тады трэба шукаць кампаніі, дзе патрэба ёсць, а архітэктара яшчэ няма, або ж расці разам з кампаніяй.

Тэхлід, які можа намаляваць архітэктуру невялікай задачы/сістэмы, патрэбны як правіла ўжо ў адной камандзе. Нават калі ён называецца цімлідам або сеньёрам, па сутнасці, ён выконвае ролю архітэктара маленькай сістэмы.

У кампаніі з 3-5 камандамі мае вылучыцца моцны тэхлід або архітэктар, які будзе прамалёўваць архітэктуру.

У кампаніі на 50+ чалавек без архітэктара абысціся ўжо складана. Калі супрацоўнікаў ужо 150+, то сярод архітэктараў выдзяляюцца моцныя Staff Engineers. У кампаніі на 500-800+ чалавек магчыма некалькі ўзроўняў архітэктараў:

• якія адказваюць за свой кампанент сістэмы;
• якія дапамагаюць рэалізоўваць вялікія фічы;
• агульны архітэктар (больш пра стратэгію, чым пра рэалізацыю і system design);
• моцныя сеньёры, якія робяць архітэктуру не вельмі вялікіх фічаў.

Прадуктовы бізнэс, які прыйшоў не з ІТ, часта лічыць, што архітэктары — гэта проста дзядзькі, якія ядуць грошы. Я не раз бачыў такое стаўленне: ой, няхай архітэктуру вызначаюць сеньёры. Да таго ж у прадуктовай кампаніі складана пашырыць кругагляд: сеньёр там будзе добра разбірацца ў сваім стэку, але пра іншыя падыходы без усвядомленых намаганняў хутчэй за ўсё не даведаецца.

Прасцей вырасціць кругагляд у аўтсорс-кампаніях, бо там часцей мяняюцца праекты.

Альтэрнатыва арганічнаму росту — пайсці на курсы, дзе веды даюцца сістэмна.

Навошта гэта ўсё ў крызіс

Я б не сказаў, што крызіс скараціў попыт на добрых стаф-інжынераў і архітэктараў. Так, мідлы, а часам і сеньёры пад ударам. Звальненне стаф-інжынера менш верагоднае, бо ён рэальна рухае бізнэс. Такія спецыялісты рэдкія і каштоўныя.

Пра лёс сеньёра, які не можа / не хоча развівацца

У далёкую дакрызісную эпоху сеньёр мог сядзець роўна, і ўсё ў яго было добра. Цяпер тых, хто не рухаецца, наганяюць змены. І ім міжволі даводзіцца варушыцца — прэвентыўна або ўжо па факце, калі яны выяўляюцца незапатрабаванымі.

Што чытаць для пашырэння кругагляду. Спіс ад Паўла Вейніка

• Прасякнуцца, якія базы наогул ёсць:
• Сайт Марціна нашага Фаўлера, апошнім часам ён шмат піша пра арганізацыю распрацоўкі, а не толькі пра архітэктуру.
• Сайт Марціна нашага Клепмана, ён глыбока лезе ў дэталі алгарытмаў, часам занадта акадэмічны, хоць прадакшан-досвед у яго таксама ёсць. Калі вы карыстаецеся RedLock, то пачытайце гэта. Дарэчы, RedisRaft яшчэ не production.
• Калі вы ўпэўненыя, што вашая БД працуе як трэба, то паспрабуйце знайсці яе аналіз вось тут: магчыма, выявіцца, што база наводзіць багі.
• Ёсць рэсурс, прысвечаны дызайну і гісторыі розных сістэм, напрыклад, гэты. Асцярожна, яны нядаўна змянілі дызайн, і цяпер там можа быць крыва.
• Вось тут можна знайсці, якія стэкі выкарыстоўваюцца на праектах, а таксама водгукі пра тэхналогіі і інструменты.

Добрых рэсурсаў вельмі шмат, але ніводны з іх не дае структурнай інфармацыі, куды і як сеньёру расці далей, акрамя майго курса, вядома ;)

Накідайце ў каментах рэсурсы, якія дапамагаюць праектаваць сістэмы вам.