Сергей Немчинский — разработчик с большим опытом и основатель учебного центра Foxminded. В мае он запустил короткий цикл из лекций о трех дорогах для развития программиста: эксперта, руководителя и основателя. В зависимости от того, по какой дороге идти, можно легко определять, какие решения принимать в работе и жизни, какие из них будут эффективны, а какие нет.
С разрешения Сергея мы публикуем все три видео и их текстовую расшифровку.
Первый путь — когда вы становитесь более и более экспертным человеком. Финалом этой дороги становится международно признанный авторитет в некоторой области. Такому человеку платят миллионы за то, чтобы он пришел, посмотрел и сказал: «Это вот так».
Дорога руководителя — это дорога, в которой человек все больше и больше полагается на подчиненных. На то, чтобы делегировать свои навыки, чтобы становиться более эффективным в управлении людьми. Итогом такой работы является исполнительный директор какой-то крупной компании. Наемный сотрудник, но исполнительный директор.
Выбрав третью дорогу — основателя, — человек создает собственную компанию и работает на себя. В конце пути — список Forbes.
Но не нужно выбирать эти дороги с точки зрения «на какой дороге я заработаю больше». Заработаете на той, которая лучше вам подходит.
Дорога эксперта
Дорога эксперта — это дорога, которую человек выбирает первой. В принципе, после того, как вы выпустились из учебного заведения, после того, как закончили какие-то курсы или после того, как самообучились, в любом случае на первую работу вы приходите работать просто специалистом. Вы туда приходите просто программистом, просто тестировщиком, просто фрезеровщиком. Эта дорога первая и основная для любого человека. Вы должны понимать, что если вы меняете сферу, в большинстве случаев вы тоже приходите на эту же дорогу. Бывают исключения, когда вы приходите в другую сферу, например, проджект-менеджером — это уже дорога менеджера, руководителя, но все же будем говорить про эксперта.
Дорога эксперта ведет через следующие ступеньки: сначала вы повышаетесь до миддла, потом — до сеньор-специалиста, а дальше путь размыт по большому счету. Во многих компаниях есть такая должность как техлид, но она мало где прописана. В большинстве компаний просто говорят, вот этот человек тимлид, с ним все понятно. А вот техлид aka архитектор. Архитектор — обычный человек, который является техническим лидером для других технических лидеров проекта, т. е. человек, который управляет техническими решениями на многих проектах. Вот техлид на одном проекте — должность довольно специфическая, потому что ее, как правило, нигде не прописывают и максимум, если у вас тимлид нормальный, вменяемый, то это такая должность, которую он вам скажет: «Слушай, ты у меня будешь техлидом. Ты будешь принимать технические решения, я буду во всем с тобой советоваться, а сам стану заниматься менеджментом». И вы становитесь ведущим программистом на проекте. Это круто, это хорошо, это здорово. Очень многие, знаю, гораздо больше любят это направление, чем направление управления людьми. Там сложно, там тяжело, их не очень любят, если они плохо управляют, и очень любят, если они хорошо управляют. Технарей любят все или не любят все, но почему-то большинству программистов кажется, что это классная дорога — идти в архитекторы.
Как стать техлидом? В первую очередь, конечно же прокачивать свои хард-скиллы. Но и софт-скиллы там также важны, также, как и для тимлидов. На самом деле, если вы не умеете обосновать заказчику принятое техническое решение, это будет сложно за вас кому-то сделать. Вас не будут считать сильным специалистом, несмотря на то, что вы классно сообразили и здорово придумали, но вообще не в состоянии обосновать, почему вы так решили и почему будет так. Поэтому, несмотря на то, что вы выбрали дорогу эксперта, думайте над тем, как прокачать софт-скиллы убеждений и публичных выступлений. Более того, чем выше вы будете забираться по этой карьерной лестнице (станете архитектором, может быть, и внешним экспертом, которого будут вызывать для решения сложных проблем), тем больше вам понадобится умение выступать публично. И тем больше потребуется скилл передавать свои знания, навыки и умение договариваться с людьми о том, чтобы они сделали именно так, как вам кажется правильным.
Ваша задача на этой дороге, когда вы достигли уровня сеньор, может, и раньше, но когда достигли сеньор, совершенно точно, начинать прокачивать скил публичных выступлений. Вы должны научиться выступать на конференциях.
В американской традиции, например, принято сеньор-должности давать только тем людям, которые хотя бы раз в год выступают на конференциях. Имейте это в виду, это правильно. Я уверен, что рано или поздно и в нашей бизнес-традиции это будет. Потому что человек, который не выступает, не качает свой навык с такой скоростью, как тот, который выступает. Просто за счет того, что он общается с разными людьми, он видит разные кейсы, он понимает, как это все происходит и т. д.
У вас есть две взаимоисключающие дороги эксперта, вы должны определиться, какая вам больше нравится. Эксперты, как правило, специализируются либо в знании предметной области и становятся шикарными программистами для какой-то предметной области, во многом беря на себя обязанности бизнес-аналитика, которых довольно часто в компаниях просто нет. Когда вы стали программистом, который реально знает, как автоматизировать какую-то херь у заказчика, с вами будут носиться, как с писаной торбой и будут пытаться перетянуть в бизнес. Возможно, это хорошая дорога. В большинстве случаев люди, пошедшие по ней, как раз переходят в бизнес-анализ и там программировать уже бросают.
Второй вариант — можно качать экспертизу в знаниях конкретных фреймворках или архитектуры в целом. В принципе, знания архитектуры в целом, к сожалению, у нас в стране [Украине] вообще пока не востребованы нигде. Это ужасно. Мне стыдно, мне кажется, что это кошмар. Более того, оно нихрена не востребовано на Западе практически, там больше требуется умение презентовать решения, может быть, даже не самые лучшие. Я надеюсь, это изменится, система становится все сложнее и потребность хорошей архитектуры рано или поздно возникнет. Так что вы вполне можете специализироваться на этом, изучая паттерны, изучая энтерпрайз-паттерны, изучая паттерны распределенных вычислений и чего-то еще, т. е. [от вас потребуется] понимание навыков построения сложных архитектур. Это классное направление, если вы в этом действительно станете офигенным экспертом, у вас и зарплата будет соответствующей, компании будут за вас бороться. Может быть, не прямо сейчас, но и вы не сможете это сделать за год, это несколько лет целенаправленной работы на прокачку своих знаний.
Знание конкретных фреймворков — это сейчас очень востребовано. Мега-специалисты, условно говоря, по Hibernate или по Spring Security и т. д. ценятся. Но там есть стеклянный потолок, больше определенной суммы вам все равно не заплатят в отличие от экспертизы в бизнес-анализе, где потолка практически нет. И вв отличие от экспертизы в архитектуре, где пока потолка нет, потому что мало людей, но рано или поздно, я уверен, должность солюшн-архитектора будет очень сильно востребована. Это будет человек, который строит всю огромную систему, всю огромную инфраструктуру. Я знаю, что во многих крупных компаниях такие должности есть, в том же Epam совершенно точно.
Мне дорога экспертизы в конкретном узком фреймворке кажется откровенно ущербной. Хотя, с другой стороны, раз потребность на рынке есть, и если вы хотите, вполне можете попробовать, например, совместить эту экспертизу, т. е. разбираться и в архитектуре, стараясь в основном в это упираться, и досконально изучив один из фреймворков.
В какой-то момент вы можете решить, что вам больше интересна вторая или третья дорога, т. е. стать руководителем. Это уже, соответственно, тимлид, потом проджект-менеджер или дорога предпринимателя с собственной компанией.
Дорога руководителя
Многие программисты считают: «Руководить программистами не надо... Я сяду и напедалю… У меня все будет хорошо». Но если проектом никто не руководит, если нет ответственного, мы получаем ситуацию, когда проект проваливается практически гарантированно. Вариант того, что проект как-то запустился и силами программистов как-то где-то каким-то образом менеджерится и почему-то приходит в результату — скорее, исключение, чем правило. Я бы даже сказал, не «исключение», а, скорее, что я таких ситуаций практически не видел. Бизнес, конечно, к этому попривык.
Если мы говорим про веб-разработку, в которой часто получается, что фирмы предпочитают нанимать не другие фирмы, где есть и руководитель проекта, и все остальное, а нанять фрилансера, то получается, что этим фрилансером руководит представитель заказчика. Фактически сам заказчик становится проджект-менеджером и управляет этим программистом, напоминая ему о сроках, ответственности, что он должен сделать, в каком объеме, поправляя и т. д. То есть делает работу проджект-менеджера.
Дорога руководителя — это фактически дорога человека, который отвечает за свою команду, человека, который делает проект работающим, проект, приходящим к финалу, к завершению, к тому, что становится проектом, а не просто какое-то времяпрепровождение.
У меня несколько раз была ситуация, когда мой ПМ проваливал проект — было видно, что он не занимается этим делом. Меня это очень коцало, причем, надо сказать, что руководителем программистов я стал достаточно быстро. В «Лигу» я пришел в 2001 году в качестве руководителя отдела веб-разработки, мне было 26–27 лет. Это было мое первое место руководителя. Надо сказать, я все профакапил, было бы странно, если бы этого не произошло. Но все же я почувствовал, что руководство людьми — очень важное направление именно из-за того, что человек — существо социальное. Если мы сажаем двух людей на работу, которую выполнял один человек, то она производится: а) быстрее, б) существенно качественней, как правило. Просто за счет того, что люди смотрят на проблему с двух сторон и один замечает то, что не замечает другой, какой-то пропущенный кейс, какие-то ситуации, которых он не сделал и т. д.
Конечно, тут есть и проблемы. Если эти люди плохо друг с другом умеют контактировать, плохо передают друг другу информацию, то во многих случаях работа двоих получается хуже, чем работа одного. Поэтому среди программистов бытует такое мнение: «Я вообще сам бы все написал, а эти чудаки на другую букву, ничего не умеют, да они меня бесят и вот это все». Кошмар, сколько раз я это видел, сколько раз я это слышал и сколько вообще людей продолжает пребывать в этом ошибочном представлении о том, что на самом деле общение с людьми не нужно.
Я увлекся на тот момент методологиями, начал изучать вопросы, связанные с методиками разработки: экстремальное программирование, скрам… Канбан на тот момент еще не появился. Меня настолько это все увлекло, я увидел, что на самом деле даже не связывал это с руководством людьми, я думал, что это просто приведение проекта к финальной точке.
На самом деле это очень здравый подход. В Америке, например, не говорит «руководитель направления», «руководитель группы», они могут так сказать, но чаще используется формулировка responsible person, как я уже говорил, «человек, ответственный за что-то». Если в нашем менталитете говорится «руководитель» подразумевается, что у него есть какие-то подчиненные и он ими руководит, то в американской трактовке это человек, который за что-то отвечает, понимаете? Он отвечает за то, чтобы что-то было выполнено. Есть у него подчиненные, нет у него подчиненных — по большому счету до одного места. Подчиненные — просто инструмент для достижения цели, чтобы нечто сработало, чтобы нечто достигло своей цели. Это суть работы руководителя программистов.
Обычно все-таки программисты идут прямо в тимлиды и очень многие программисты считают, что тимлид — это другая работа, совсем не похожая на работу ПМ. Нет. На самом деле они в чем-то очень близки.
Есть много аспектов, которые должен делать тимлид. Тех, которые не входили в обязанности сеньор-девелопера, причем, некоторые обязанности сеньорного девелопера с тимлида уже спадают. Если вы решили, что переходите с дороги эксперта на дорогу руководителя, и первая ваша руководящая должность — тимлид, вы должны понимать, что как только вы становитесь тимлидом, вы уже только наполовину программист. Т. е. вы сразу теряете половину своих программистских скиллов и приобретаете половину скилов руководителя, менеджера. Вы становитесь чем-то средним между менеджером и программистом.
Поэтому вы не должны на себя назначать супер важные таски, потому что супер важными тасками теперь должны заниматься крутые программисты. Вы уже не крутой программист, вы уже наполовину менеджер, вы на себя должны назначать таски по приоритету не выше медиума. Только задачи с низким и средним приоритетом — никаких «хай приорити», никаких критиков на вас не должно быть назначено. Потому что вас в любой момент может сорвать руководство, вас в любой момент может вызвать представитель заказчика, вы в любой момент можете быть заняты какой-то менеджерской активностью, которая не позволит вам сделать критическую часть, и вся ваша команда будет сидеть и плевать в потолок. Вы уже наполовину как руководитель должны помнить об этой ответственности и не брать на себя такие важные задачи. Такие важные задачи должен решать кто-то другой. Тимлид не обязан быть самым сильным программистом в команде, иначе он будет вынужден тянуть на себе обязанности и тимлида, и техлида.
Я выбирал человека, которому говорил: «Вот ты — наш архитектор команды», это круче звучит, чем техлид, «ты будешь отвечать за все технические решения, а я буду решать менеджерские решения. Я защищаю команду от ПМ, я представляю ваши интересы, вы обращаетесь ко мне, я прикрываю ваши задницы. Вот, собственно говоря, моя работа. Я распределяю задачи, слежу за тем, чтобы никого не обидели, решаю проблемы (условно, монитор не работает или нужно выделить сервер более мощный) я тут за организацию. А вот тебя назначаю самым крутым разработчиком, техлидом, который и решает основные технические проблемы».
Этим убивается два зайца. Первый — если вы не самый крутой программист в команде, чтобы не получилось, что команда разваливается напополам и возникает противостояние между вами и более сильным программистом. Второй момент — вы добиваетесь того, чтобы не разрываться напополам, потому что если вы на себе оставляете техническое руководство, то вы вынуждены делать код ревью. Вы не успеете, потому что времени у вас меньше: у вас совещания и куча такого, вы вынуждены делать тогда самые критические задачи, если вы не выделяете такого техлида и т. д. Это жопа.
Я видел много тимлидов, которые выгорели из-за того, что пытались на себе тянуть заодно и роль техлида. Это не реально, вы просто сгорите, не делайте так. Определитесь: техлид — человек, который идет потом в архитекторы, — это дорога эксперта; тимлид — человек, который потом идет в проджект-менеджеры, — это дорога менеджера.
Как тимлид вы должны помнить о том, что, несмотря на то, что вас и назначили руководить программистами, это не значит, что вы должны на них плевать свысока, рассказывать, что они все делают неправильно, относиться к ним как к говну или, наоборот, бегать за ними и задувать им жопу. Вы должны работать точно так же, как работали до этого, просто теперь у вас добавилась обязанность и, соответственно, добавилось немножко прав. Вы теперь отвечаете за то, чтобы команда работала как единое целое. Поэтому у вас есть некоторые права, чтобы воздействовать на них, например, раздавая и приоретизируя задачи. «Слушай, подожди, вот эту задачу передай, пожалуйста, Мише. Я вижу, что у тебя она немного тяжелее идет, а ты переключайся на вот эту задачу, потому что нам нужно закончить проект вовремя».
ПМ сделать этого не сможет, он не понимает, кто там с какой скоростью работает, за этим следите вы, именно как тимлид и как менеджер. Такой играющий тренер — это ближе к капитану команды, если мы говорим в футбольных терминах, т. е. это человек, который непосредственно бегает по полю, но при этом как бы еще и отвечает за остальных игроков. Ему не обязательно быть самым сильным, но нужно быть уже организатором.
Последнее, что я хотел сказать по поводу руководства программистами, никогда их не обманывайте. Это бессмысленно, вас мгновенно «выкупят», и вы потеряете весь авторитет. А кроме авторитета у вас нет ничего вообще. Все, что у вас есть, — это авторитет перед другими людьми. Люди вас слушают просто потому, что вам верят. Если вам не верят, вас не слушают. Даже если вы формально тимлид, все такие «да, да, да, конечно», но отошли и сказали «тьфу, какую ерунду он говорил, никто делать это не будет». Поверьте мне, это больно и неприятно, завоевать авторитет обратно — очень тяжелая и в большинстве случаев невыполнимая задача.
Поэтому не обманывайте, говорите честно. Люди взрослые, люди все поймут. Это не значит, что если вас руководство попросило что-то не говорить команде, вы пошли и тут же рассказали. Иногда да, а иногда нет. Вы взрослый человек и должны понимать, что бывают ситуации, когда руководство не хочет доносить информацию, потому что оно слегка неправо, но команда нормально воспримет эту информацию. А бывают ситуации, где вы понимаете, что если эту информацию донести до команды, то она сейчас просто бросит работать.
Например, много раз были ситуации, когда с заказчиком какие-то проблемы, заказчик подумывает уйти или смотрит на вас как на команду, не выполняющую свои обязанности. Если вы придете и скажете своей команде — «вот такая история» — они запаникуют. Тогда как менеджер вы понимаете, что нужно делать — просто намекните им, надо постараться.
Дорога основателя
Очень многие программисты в своих «влажных мечтах» думают о том, что они станут владельцами крупной софтверной компании: «мы сейчас как вскочим, как возьмем и заработаем миллионы долларов!»
Но сразу несколько дисклеймеров. Вы должны понимать, что в большинстве случаев как программист в найме вы заработаете больше, чем как руководитель собственной ИТ-компании. Как минимум вы будете меньше зарабатывать руководителем собственной компании на протяжение первых 2–3 лет. К этому надо быть готовым.
Если вы привыкли получать условные свои $3000 и они вам жмут, и на меньшее вы никак не готовы, то имейте в виду: скорее всего, дорога стать предпринимателем для вас будет очень тяжела. Я, например, первые полгода просто проедал свои запасы, а потом привык жить на существенно меньшую сумму. Если вы не готовы урезать свои интересы, то имейте в виду: вам нужно будет очень сильно [сначала] подкрепиться и проедать запасы существенно дольше. Т. е. на те самые $3000 в первое время выйти достаточно сложно.
Уровень стресса у владельца собственной компании в разы выше, чем у программиста или даже у проджект-менеджера. Этот уровень стресса будет вас преследовать всю вашу предпринимательскую жизнь, потому что сегодня у вас хорошо, завтра у вас плохо, тут поменялся рынок, там выпустили новый закон, который вас каким-то образом ограничил и создал ситуацию, когда вы вообще не можете работать. И, наоборот, возможно, что вам привалил какой-то дикий заказ, в который нужно срочно вцепиться зубами и как-то его выгрызть. Вы будете работать 24/7, падая, уставая, попадая в больницу с перенапряжением и т. д.
Можно и не так. Есть разные варианты. Я, например, работал предпринимателем в более лайтовом варианте. Возможно, именно из-за этого наша компания развивалась медленнее, чем могла бы. Но, с другой стороны, я в больницу не попал и вроде как пока не выгорел, что уже тоже само по себе радует.
Говоря о том, как программисту стать предпринимателем, я бы выбрал тут два варианта, два способа того, как это может происходить.
Вариант №1. Вы находите где-то инвестиции или богатого инвестора, или богатого соучредителя, который говорит: «Вот тебе котлета денег, давай вместе что-нибудь устроим». И вы эти деньги благополучно продалбываете. Я ни разу в жизни не видел, чтобы было по-другому, за исключением ситуации, когда ваш соучредитель действительно уже обладает опытом построения фирмы, знает, как это все делать, и он вас взял для просто того, чтобы вы были техническим директором. Но если вы не были до того руководителем, если вы не были хотя бы на уровне проджект-менеджера, то вы факапите эту работу прямо гарантированно. Потому что учиться быть и предпринимателем, и руководителем разработки одновременно — это реальная жопа. Вы себе такой челлендж устраиваете, что Ахиллес отдыхает. Фактически вероятность того, что такой проект взлетит, очень низка.
Если же вы толковый ПМ, умеете общаться с заказчиком, вы умеете все делать и т. д., и вас позвали соучредителем в компанию на должность технического директора, чтобы отвечать за деливери и в принципе за технику, за выпуск, а другой ваш партнер будет заниматься продажами, маркетингом, и HR, то почему нет. Я не вижу тут никакой проблемы, выглядит это вполне работоспособным вариантом.
Если у вас нет опыта предпринимательства, вы эти деньги просрете вот прямо гарантированно, потому что отношение к деньгам у человека, который всю жизнь работал в найме и который умеет строить фирмы, у предпринимателя, кардинально другое в принципе, оно находится даже не в разных плоскостях, а в разных мирах. Собственно говоря, именно эти деньги вы и потратите на то, чтобы перестроить свое отношение к деньгам.
Вариант 2. Я всегда рекомендую идти по другой дороге, которая начинается с фриланса. Может быть, это фриланс не на одного вас, может быть, это фриланс на вашу команду, но в любом случае — это сначала заказ, сначала его выполнение. в идеале — когда этот заказ вы можете выполнять один как разработчик или как верстальщик, или как админ, или как девопс. Вы хватаете этот заказ и выполняете его сами, стараясь сделать его на максимум, не смотря на то, сколько вы назвали денег и какие сроки назначили. Так, чтобы ваш заказчик остался максимально довольным, а лучше больше, чем максимум. Так, чтобы заказчик остался в таком восторге, что пошел рассказывать своим знакомым и друзьям. Первые 10, 15, 20 заказов, которые у вас найдутся — это будут заказы, приведенные по «сарафанке», т. е. от вашего заказчика, довольного вашей работой.
Если вы зафакапите какой-то из этих первых заказов, можете закрываться. Шансов, что другие ваши потенциальные заказчики не узнают о том, как вы факапите заказы, не очень много. Рынок обычно узенький, где-то кому-то как-то намекнет, что «с ним поосторожнее, он уже где-то что-то завалил».Вам будет существенно тяжелее искать заказы, если вы уже что-то факапили. Поэтому первые заказы вы делаете на максимальном уровне. Заботьтесь об этом так, как будто от этого зависит ваша судьба. Фактически так оно и есть.
Потом, когда заказов у вас становится больше, чем вы можете сделать сами, вы зовете к себе друзей. Причем, старайтесь этих друзей звать не в соучредители вашей компании. В соучредители имеет смысл брать только тех людей, которые готовы этим гореть, сжигать себя и работать за бесплатно.
Первые сотрудники, которых вы привлекаете, должны быть друзьями, которые вам доверяют, которым вы передаете заказ, может быть, даже полностью отдавая им их долю, чтобы выйти на рынок, чтобы вас запомнили. Но лучше все-так оставлять себе хотя бы 10, 15, 20, 30%. Причем, это не обворовывание людей. На вас будет очень большая ответственность, потому что именно вы будете выступать лицом вашей команды, которая впоследствии станет компанией. Именно вы будете отвечать перед заказчиками за то, что это исполнится. Именно вы вылетите с рынка, а не они — они пойдут к другим работодателям и будут там спокойненько работать. Именно ваша жопа рискует тем, что мечта не исполнится. Поэтому ваша доля там должна быть, пусть небольшая, но все равно должна.
И договаривайтесь об этой доле на каждый проект, потому что в некоторых проектах вашего участия будет больше, в некоторых меньше. «Вот ты делаешь дизайн, я согласовываю, я выступаю в качестве лица компании, ты делаешь верстку, а я делаю бэк на PHP, например. Мы хорошо сварганили сайтик, продали, хорошо в нем заработали». И дальше старайтесь обрастать этими людьми.
Причем взять в штат и платить людям ежемесячную зарплату вы сможете очень нескоро. Только в тот момент, когда у вас будет постоянный приток этих заказов, и вы уже непосредственно сами не занимаетесь разработкой, а только поиском заказов, вот тогда можно брать людей в штат. Чтобы они постоянно находились у вас в доступе и решали за вас вопросы, связанные с работой вашего софта, вашей разработки. Но пока это достаточно сложная и тяжелая задача для вас.
Предпринимательство — это очень тяжело. Вам в первую очередь придется выяснять, что такое продажи, что такое маркетинг, что такое продакт-менеджмент, что такое позиционирование на рынке, что такое отстраивание от конкурентов, что такое целевая аудитория, что такое связь с целевой аудиторий, что такое 1001 других заморочек. Через некоторое время вы будете готовы по этому поводу читать лекции, как я, например, сейчас.
Если вы уже находитесь на стадии, когда у вас уже есть какие-то заказы, пришедшие по сарафанке, вам пора изучать маркетинг. Даже если вы опытный разработчик, даже если вы опытный ПМ, для вас области маркетинга и продаж будут вообще чем-то небывалым, необычным — тем, о чем вы никогда даже не знали.