Карьера — Из продажника в программисты


Содержание

Карьера — Из продажника в программисты?

Я знаю минимум десять программистов, которые в свое время пробовали заниматься бизнесом. Знакомых, которые занимаются бизнесом в той или иной степени гораздо больше, а именно программистов-бизнесменов примерно столько. Плохая новость заключается в том, что 90% из них потерпели фиаско на бизнес-поприще. Почему? Потому что можно быть только в одной сфере деятельности профессионалом — либо быть хорошим программистом, либо быть хорошим продажником. Это связано и с необходимым временем для накопления опыта порядка 10 тысяч часов, о котором я писал, и с психологическими составляющими. Тип личности хорошего программиста полностью противоречит типу личности хорошего продажника. Первый полностью погружен в процесс, четко представляет каждую его составляющую и программную архитектуру, а второй открыт для всех окружающий, пытается угадать все их желания и почти не тратит время на изучение архитектуры программного продукта. Безусловно, в любом правиле есть исключения, но в этом случае исключения только подтверждают правило, которое гласит: хороший программист не может быть хорошим продажником. А без хорошего продажника невозможно создать успешный бизнес.

Если вернуться к моим знакомым хорошим программистам, которые пытались создать свои бизнесы, то через какое-то время — иногда это год, иногда три года, человек полностью выматывается и возвращается туда, откуда начал свой бизнес, а именно программная разработка. Он устраивается в какую-то компанию и дальше совершенствуется в области программной разработки. Возникает вопрос: а чего собственно он хотел добиться? Наверное, хотел получить независимость, хотел работать сам на себя, хотел сам общаться с клиентами и выявлять их потребности. Ведь с виду работа менеджеров по продажам очень простая: ты звонишь клиентам, встречаешься с ними, подписываешь договора, ставишь задачи и сдаешь выполненные работы. Что может быть проще? Однако, коммуникация с клиентом, как и любая другая сфера деятельности, является особым искусством. Нужно уметь правильно подойти к клиенту, задать правильные вопросы, правильно спросить о его прошлых выходных, уметь вовремя сделать скидку, чтобы клиент не сорвался с крючка, или наоборот продавить свою цену, приведя правильные доводы. Вывод: продавать нисколько не проще и не сложнее, чем программировать. Если говорить о самом бизнесе, то помимо общения с клиентом и выбивания заказов, это еще и бухгалтерская и налоговая отчетность, определенные риски, связанные с кассовым разрывом и еще очень много вещей. Если человек занимается всем этим один, то ему либо некогда продавать и тогда оборот в компании пропадает, либо ему некогда разрабатывать, так как он постоянно общается с клиентом.

Что же делать амбициозным программистам? Идти в интересные IT-компании и ни в коем случае не пробовать заниматься своим бизнесом и тем более продавать. Вернее продавать можно, но только если программирование сидит у вас в печенках, и вы точно хотите сменить сферу деятельности. В плане удовлетворения амбиций существуют свои стартапы, которые можно делать и в рамках деятельности некоторых компаний, например, таких как Zavod it-стартапов.

Хотите стать боссом в корпорации? Начните карьеру в стартапе

— советует Александр Горный

В фильме «Хатико» собака девять лет ждала хозяина на вокзале. Образец любви и верности. Одним из элементов фона для сюжета был продавец, который на том же вокзале все эти девять лет торговал хот-догами. Утром приехал, развернул ларёк и весь день кричит: «Хот-доги, горячие хот-доги!» Вечером свернулся и уехал. Вчера, сегодня, завтра. Девять лет. Такого эпизода в фильме не было, но, предположим, на шестой год продавец прошёл обучение и научился работать с новой моделью терминала для приёма карт. Вот и весь его профессиональный рост. Если вдуматься, большая часть людей и в мире, и в России строят карьеру примерно так же.

При трудоустройстве компания проверяет кандидата на наличие навыков, достаточных для выполнения рабочих задач. Естественно, именно эти задачи и поручают сотруднику. На новом месте могут быть какие-то особенности, но, в принципе, рекрутер всегда ищет человека, который имеет максимально близкий опыт. На место кассира подбирают бывшего кассира, вакансию PHP-программиста закрывают PHP-программистом, а идеальный директор по маркетингу — директор по маркетингу ближайшего конкурента. Новоприбывший сотрудник решает те задачи, которые умел решать изначально. Через три, пять или десять лет он выходит на рынок труда с теми же навыками, что и в прошлый раз.

Да, конечно, существует и такая штука, как карьерный рост. Когда освобождается место начальника, его может занять не варяг, а лучший человек в отделе. Но происходит такое, допустим, раз в пять лет — и кандидатов на повышение тоже оказывается пятеро. В итоге в среднем за 12 с половиной лет человек дорастает до начальника группы. Можно самому стать варягом: показать горящие глаза, согласиться на зарплату пониже и добиться новой должности в другой компании. Однако для подчинённых уходящего начальника в этом случае счастливых билетов на повышение не окажется вовсе.

И это закономерно. Экономика России (и мира) растёт на несколько процентов в год. Значит, и новых задач появляется примерно столько же. Ещё пару процентов «освобождают» молодым те, кто уходит на пенсию или уезжает из страны. Нам, российским интернетчикам, ещё везёт — с поправкой на инфляцию Рунет растёт ежегодно процентов на десять. С другой стороны, и на пенсию выходить пока некому — все относительно молодые. Несколько процентов новых задач так или иначе распределяются между людьми, на эти несколько процентов в год и происходит в среднем профессиональный рост — а следовательно, и денежный с карьерным.

Те же тренды видны на микроуровне. Возьмём некий департамент большой компании: директор, три его зама, десять начальников отделов и сто рядовых сотрудников. Что с ними со всеми может случиться через пять лет? Арифметика безжалостна, подавляющее большинство из них будут делать то, что делают: прежние должности, прежние задачи, прежние (с поправкой на инфляцию) зарплаты.

Некоторые компании применяют принцип «расти или умри»: лучших поднимаем, остальных увольняем. Здесь, конечно, каждый из оставшихся похвастается прогрессом — но только оставшихся будет те же 5% от пришедших, законы сохранения не обмануть.

Российским интернетчикам ещё везёт — с поправкой на инфляцию Рунет растёт процентов на десять в год. Но и на пенсию у нас пока выходить некому

Картина получается безрадостная. Но на ней есть яркие пятна — стартапы. Они по определению растут быстро. Не просто быстро, а стремительно, молниеносно, ракетой. Никто не знает, не обанкротится ли Snapchat, вернёт ли деньги инвесторам Uber и останется ли в памяти поколений Pinterest, но все они уже прошли путь от гаража до гигантских компаний за пять-десять лет. И в каждом стартапе сотрудники делают головокружительные карьеры!

Марисса Майер пришла в Google инженером в 1999 году, а покинула его в 2012-м, будучи уже вице-президентом. Сравните это с моими мысленными экспериментами в предыдущих абзацах. Фокус в том, что пришла она в корпорацию сотрудником №21 — и примерно такое же место в табели о рангах она занимала при уходе. При появлении новой задачи, новой ответственности, новых бюджетов основатели Google Сергей Брин и Ларри Пейдж отдавали ресурсы кому-то из тех, кто уже работал рядом с ними. Если Майер нанимали единственным программистом интерфейсов поисковика, то при расширении команды следующий человек автоматически стал её помощником, а после прихода третьего она уже была руководительницей группы. В нормальной компании это удаётся каждому пятому за пять лет, в стартапе случилось почти само собой за полгода или год.

Конечно, и в Google продвигали не всех: кому-то не хватало квалификации, кому-то везения, кому-то ещё чего-то, но дорога была. Аналогично программисты моей команды в Mail.Ru образца 2005 года, когда компания по всем признакам ещё была стартапом, почти все лет за пять стали техническими директорами проектов. Ну а как они могли ими не стать, если проектов запускалось больше, чем у нас было людей?

Важно, что стартап не просто обеспечивает звучные должности — человек растёт и профессионально. Когда Майер приняла оффер Google, она была хорошим программистом, не более того. Появление первого помощника дало ей опыт руководящей работы. Эксперименты с главной страницей превратили айтишника в менеджера продукта. Работа в позднем Google — в ещё растущем, но уже гиганте — на практике открыла Майер правила управления большими корпорациями. В 2011 году CEO Google Эрик Шмидт произнёс знаменитую фразу: «Думаю, Ларри Пейдж уже готов». Варясь внутри Google, Пейдж получил достаточно опыта, чтобы стать CEO, и более не нуждался в услугах Шмидта в этой роли. Точно так же «были уже готовы» и его ближайшие сподвижники: они стали топ-менеджерами не только по должностям, но и по навыкам.

Работодатель ожидает от соискателя комбинации личностных качеств и наработанных навыков. С первой половиной уравнения сделать что-то трудно. Ясность ума, коммуникативные способности, нацеленность на результат и подобные качества даются от природы или развиваются самостоятельно — никакой Uber вам с этим не поможет. А вот с навыками всё гораздо проще. Чтобы приобрести новый опыт, надо ответить на вызов, с которым раньше не сталкивался. С сотрудником стартапа такое происходит регулярно.

То, что в большой компании удаётся каждому пятому раз в пять лет, в стартапе случается почти само собой за полгода или год

Стартап позволяет расширить квалификацию, освоить новые технологии и предметные области. В стабильной корпорации процессы организованы хорошо, и люди мало отличаются от винтиков — это, собственно, определение процесса. Каждый занят своим делом, обязанности прописаны, деятельность регламентирована, постановка задач формализована. Невозможно представить, чтобы в Oracle или SAP серверный программист на недельку подменил продажника. А в стартапе подобное случается сплошь и рядом, потому что людей вечно не хватает, а организация труда — никакая. Сегодня ты здесь, завтра — там. И каждый день даёт новый опыт, новые знания, новые ключевые слова в резюме.

А ещё стартап непрерывно растёт. Вчера у него было 10 клиентов, сегодня 11, завтра будет 12, а сотрудники при этом те же самые. На инвестиционные деньги они делают ошибки (как же без них), изобретают велосипеды, но к концу недели справляются с наплывом из 20 покупателей, а к концу года обслуживают уже 100. Навык получен, записан на подкорку и в резюме — можно уходить на новую работу в корпорацию. Или подождать год и научиться работать с тысячей клиентов, а не с сотней.

Самое любопытное, что наёмный сотрудник этот фантастический карьерный лифт получает практически бесплатно. Основатели рискуют деньгами и репутацией, бросают опционы и бонусы в корпорации, иногда питаются дошираком и продают квартиры. Рядовой программист или менеджер по продажам за участие в стартапе получает рыночную зарплату и рыночные условия труда. Разве что офис не такой блестящий, как в условном «Газпроме», хотя встречаются и исключения.

В худшем случае стартап через год провалится и сотрудник опять пойдёт по собеседованиям. Что ж, безработицы для профессионалов в России нет — он найдёт работу за неделю или две. Всей платой за попытку будет стресс в этот период и иногда невыплаченная зарплата за последний месяц. Кажется, что это не так много. В стартапах, запускаемых в рамках Mail.Ru Group или другой корпорации с похожим подходом к развитию, нет и этого риска — материнская компания всегда выплатит всё, что положено по закону, и ещё немножечко сверху.

Хатико не покидал вокзал, потому что верил, что дождётся хозяина. Он боролся за своё счастье. Что держало там же продавца хот-догов? Человеческая верность куда удивительнее собачьей.

У «Секрета фирмы» появился канал в «Яндекс.Дзене». Подписывайтесь!

Карьера — Из продажника в программисты?

Имя уроженца Екатеринбурга Никиты Шамгунова нечасто встретишь в российских деловых СМИ. Между тем его карьера — образец пути «глобального русского» предпринимателя 2010-х годов. ​Переехав в США для работы в Microsoft и Facebook, Шамгунов со временем стал сооснователем собственного бизнеса — ускорителя баз данных MemSQL.

В октябре 2020 года знаменитый американский акселератор Y Combinator собрал рейтинг 100 своих самых успешных выпускников-стартапов. Критерием служила капитализация или оценка непубличных компаний инвесторами. 40-е место в списке занял MemSQL, разработчик системы управления базами данных (СУБД). Компания никогда не раскрывала, во сколько ее оценивают венчурные капиталисты, но судить о масштабе бизнеса можно по соседям в рейтинге: № 39, стартап WePay, в конце 2020-го был поглощен инвестбанком JP Morgan Chase за $400 млн, а № 41, Weebly, — в начале 2020-го сервисом Джека Дорси Square за $365 млн.

Один из основателей, а ныне и гендиректор MemSQL — 40-летний уроженец Екатеринбурга Никита Шамгунов. Компанию он создал в 2011 году вместе с бывшими коллегами по Facebook и Microsoft Эриком Френкелем и Адамом Праутом. MemSQL помогает корпоративным клиентам ускорять работу баз данных: вычисления происходят быстрее, и бизнес может масштабироваться максимальными темпами. Потенциал технологии за семь лет оценили десятки крупных заказчиков: услугами MemSQL пользуются как компании с богатой историей, от телеком-холдинга Comcast до ИТ-гиганта Dell EMC, так и локомотивы новой экономики, стартапы-«единороги» Uber, Pinterest и другие. Модель бизнеса привлекает и венчурный капитал: в совокупности в MemSQL вложили уже $110 млн (последний раунд на $30 млн закрыт в мае 2020-го). Среди инвесторов сплошь звезды — Accel Partners, Khosla Ventures, GV, Юрий Мильнер, Эштон Кутчер и другие фонды и бизнес-ангелы.

Журнал РБК поговорил с Никитой Шамгуновым, его учителями, коллегами и конкурентами и выяснил, как уральский программист добился признания в Кремниевой долине и почему о бизнесе стоимостью под $400 млн так мало знает массовая аудитория.

Выделенка от Сороса

Карьера Шамгунова-программиста началась в Научно-учебном центре Уральского государственного университета (СУНЦ УрГУ). Этот аналог лицея при главном вузе региона был основан в 1988 году и за 30 лет выпустил десятки известных предпринимателей, ученых и менеджеров, а расцвет заведения пришелся на 1990-е (Шамгунов — выпускник 1995 года).

Популярность СУНЦа во многом обеспечивала развитая инфраструктура, вспоминает другой выпускник, руководитель сервиса «Яндекс.Вертикали» Антон Забанных: «Важной фичей был доступ в интернет. Быстрый — выделенка, а не модем. Компьютеры тоже были хорошие. Если правильно помню, покупали их на гранты [фонда] Сороса». Он также выделяет атмосферу, не свойственную другим школам: «Мы попали в уникальное время и уникальное место — нас не грузили чужими проблемами или пропагандой, а наполняли фундаментальным понятием свободы».

Шамгунов уже в СУНЦе увлекся алгоритмами и структурой данных. По окончании центра поступил в УрГУ на матмех и начал активно заниматься спортивным программированием, участвовать и побеждать в олимпиадах по математике. Параллельно преподавал на курсах для абитуриентов СУНЦа. Там познакомился с еще одним известным впоследствии выходцем из уральской ИТ-индустрии — Леонидом Волковым, в прошлом предпринимателем, ныне оппозиционным политиком и соратником Алексея Навального. Среди учеников молодых преподавателей также есть известные программисты, например главный разработчик поисковика Bing от Microsoft Денис Расковалов.

Волков и Шамгунов вошли в состав сборной УрГУ по спортивному программированию. Главным достижением команды стала бронза на чемпионате мира в 2001 году. Шамгунов одновременно стажировался в крупном разработчике софта «СКБ Контур», куда был приглашен тренером сборной Евгением Штыковым. Под его началом Шамгунов участвовал в создании программы АМБа (сейчас «Контур.Зарплата»). «Фамилии ведущих разработчиков АМБы — Штыков, Шифман и Шинкарев. Потом к ним присоединился Никита. Мы шутили про отдел Ш-программистов», — вспоминает Волков.

Шамгунов разрабатывал для АМБы систему обработки информации. «Это нечто вроде системы управления базами данных, с помощью которой можно легко конструировать приложения», — объяснял он журналу «Контур Инсайд» в 1999-м. А заодно рассказывал об увлечении Linux. «С будущим я еще не вполне определился, но от компьютеров [мне] уже никуда не деться», — резюмировал программист. Уйдя из «Контура», он устроился в «УралРелком», где в компании еще одного тренера по сборной УрГУ, Сергея Герштейна, участвовал в разработке новостного сайта е1.ru («Екатеринбург Онлайн»).

На форуме е1.ru, а точнее на его 37-й ветке, быстро сформировался программистский кружок, который Волков аттестует как адский гадюшник и троллятник. Архивы доступны и сегодня: например, в одном из тредов Шамгунов выигрывает проставу пивом от Волкова — предлагает самое эффективное решение задачи по упаковке разрозненных данных в единую структуру. Другие участники импровизированного конкурса — Александр Якунин (сейчас ведущий разработчик сервиса Quora) и Евгений Кобзев (сооснователь сервиса «Кнопка»).

В интервью журналу РБК Шамгунов признается, что регулярное участие во всевозможных профессиональных соревнованиях не только помогло улучшить навыки написания кода, но и сильно расширило горизонты: «Живя в Екатеринбурге, я и не представлял, какой мир огромный!» Первым карьерным шагом за пределы родного города стало поступление в аспирантуру петербургского Университета ИТМО.

Софт для морского боя

С деканом факультета ИТ и программирования ИТМО профессором Владимиром Парфеновым Шамгунов познакомился еще на соревнованиях в Екатеринбурге. «Мне уже тогда нравились и раунды [соревнований], которые проводились в Петербурге, и сам город — лучше только Сан-Франциско. [Позднее] позвонил Владимир Глебович [Парфенов]: «Тебя приняли, приезжай. С работой поможем», — рассказывает сооснователь MemSQL.

В Петербурге Шамгунов защитил кандидатскую и устроился на работу в компанию «Транзас» — производителя навигационных систем и морских тренажеров. Научный руководитель предпринимателя в ИТМО Анатолий Шалыто в книге к юбилею кафедры особо выделял диссертацию Шамгунова как первую программистскую. «Кандидатская для Никиты, как и для меня, была естественным продолжением [карьеры]. Но всерьез оставаться в науке никто из нас не собирался», — говорит Волков. ИТМО он считает «лучшим местом [в России] для диссертации по теоретической информатике».

«Транзас» в 2000-х бурно рос за счет спроса на внешнем рынке. Шамгунов разрабатывал софт для сбора информации о перемещении судов в Балтийском море. Программа умела на лету вычислять характеристики передвижения кораблей и других участников морского трафика.

«Например, [программа могла определить], в каком порту сейчас больше всего британских судов», — описывал Шамгунов результаты своей работы в заметках к слайдам презентации Microsoft StreamInsight. Там же он рассказал о проблеме, решение которой было близко к будущей специализации в американской части его карьеры: «При попытке в реальном времени загрузить данные в SQL Server в компании обнаружили, что скорость поступления данных слишком велика и СУБД не справляется. Мы решили задачу, хотя решение и было не очень простым и элегантным».

Автобусный тандем

В 2005-м выручка «Транзаса» впервые перевалила за $100 млн, но Шамгунов новый этап развития компании уже не застал. По рекомендации одного из бывших коллег он отправился на собеседование в Microsoft и успешно его прошел. «Интервью оказалось не таким сложным, за исключением языковой части», — говорит предприниматель. В том же году он перебрался из Петербурга в Сиэтл. В Microsoft Шамгунов стал старшим разработчиком Microsoft SQL Server и участвовал в разработке ядра программы.

Технология SQL (structured query language) предназначена для управления базами данных. Аббревиатура обозначает структурированный язык запросов — с его помощью разбросанную по разным таблицам информацию можно объединить в единый запрос и вывести на экран. Полученные данные — результат обсчета всех конфигураций между строками и столбцами. Чем элементов больше, тем дольше время выдачи информации пользователю. Базы, использующие SQL, строго структурированы — например, каждая позиция имеет уникальный идентификатор.

В Microsoft Шамгунов проработал пять лет, до 2010-го. В 2009-м его начал активно хантить Facebook. «Поначалу я не совсем понимал, что буду там делать. Но в 2010-м меня все-таки уговорили, и я перешел. За какую-то огромную кучу денег», — вспоминает Никита. На лекции «Гуру Урала» в 2012 году он вспоминал, что перебирался в Калифорнию с ожиданием увидеть новую ментальность и культуру. «В планах было поработать в компании, взять у них все самое полезное и найти партнера, с которым я смогу основать свою компанию», — не скрывал Шамгунов.

Мечта о собственном бизнесе появилась еще на второй год работы в Microsoft, но долгое время Шамгунов понимал, что не готов к решающему шагу. Ключевым препятствием ему виделось отсутствие делового партнера, с которым можно было бы разделить риски и которому можно было бы довериться. «Я думал, что [на поиски партнера] уйдет пара лет. Но [в Facebook] партнера встретил в первый же день», — говорит предприниматель. Идеальным соратником для Шамгунова оказался программист Эрик Френкель. Они познакомились, когда проходили обучение в кампусе Facebook, и быстро стали близкими друзьями. Тандему не помешало даже попадание в разные отделы, приятели ездили на работу на одном автобусе, писал журнал Wired в 2013 году.

Спустя несколько месяцев они подали первую заявку в Y Combinator. «Хотели посмотреть, как бывает на практике», — объясняет Шамгунов. В акселератор они пришли с идеей сервиса по поиску квартир в Сан-Франциско. И хотя изначально Шамгунов не хотел уходить в подобный проект из Facebook, партнеры прошли все предварительные интервью и добрались до финального собеседования с основателем Y Combinator Полом Грэмом.

«Мы рассказали о проекте, нас поблагодарили и предложили подождать вердикта. В YC все очень быстро происходит: о результате узнаешь в тот же день», — вспоминает предприниматель. По его словам, после разговора с Грэмом Френкель купил бутылку самого дорогого шампанского и они уселись перед телефоном, готовые праздновать. Но звонок так и не раздался. А на следующее утро стартаперы получили письмо: акселератор уведомил об отказе.

Собеседование о гранатометах

Несмотря на неудачу, Шамгунов и Френкель тут же отправились придумывать новые идеи. Оба вспомнили, что Microsoft и Facebook активно инвестируют в технологию in-memory — хранение данных в оперативной памяти. Работа с подобными базами в разы быстрее, чем с жесткими дисками и твердотельными накопителями, но есть и минус — система не оставляет информацию, если оказывается обесточена или выключена. Тем не менее партнеры решили сосредоточиться на модели ускорителя баз данных, из этой идеи позднее родился MemSQL.

С формальной подачей заявки предприниматели на этот раз опоздали, но им удалось найти лазейку, чтобы поступить на курс 2011 года. Помогла поддержка экспертов: ключевым лоббистом проекта стал бывший главный разработчик Gmail Пол Бекхайт. Тогда он ушел из Google, основал компанию FriendFeed и присоединился к команде Y Combinator. «Мы нашли его аккаунт в Facebook, и на аватарке был автомат, — вспоминает Шамгунов. — Так что Эрик перед интервью изучил вопрос: в итоге из 60 минут встречи 20 мы посвятили стартапу, а 40 — ружьям, автоматам и гранатометам». С подачи Бекхайта MemSQL стал резидентом Y Combinator вне конкурса.

После этого для Шамгунова и Френкеля настал тяжелый момент — нужно было решиться уйти из Facebook. Причем первому одновременно приходилось расстаться с возможностью получить опцион в форме пакета акций соцсети стоимостью $2 млн. «Если уходишь из компании, акции необходимо оставлять на столе. Нужно было сказать себе: моя компания стоит дороже $2 млн», — отмечает Шамгунов.

Первое время партнеры работали на два фронта и размышляли о целесообразности участия в Y Combinator. «Я говорил Эрику: «Давай я сам стану твоим акселератором, дам тебе те же $17 тыс., в чем проблема? ..» — смеется Шамгунов. Рассеяли сомнения лишь инвесторские деньги. Первым на помощь пришел Юрий Мильнер: основатель фондов DST передал стартапу $150 тыс. Френкель в интервью американскому Forbes (журнал включил его в ренкинг 30 самых перспективных молодых предпринимателей в ИТ) в 2012 году вспоминал: «В тот момент Мильнер был в России, и хорошие новости доставил робот Segway с приделанной к нему веб-камерой и экраном. Никогда бы не подумал, что получу деньги от робота».

Средства пришлись как нельзя кстати: стартап уже подписал часть специалистов из команды Microsoft SQL Server. Для некоторых решающим фактором стал именно шанс пройти через Y Combinator, подчеркивает Шамгунов. Первым сотрудником MemSQL стал Адам Праут. Его переманили статусом сооснователя и пакетом в 6,6% при традиционных для должности старшего программиста 1–2%.

Вторым пришел Александр Скиданов, хорошо знакомый Шамгунову по работе в Microsoft. «Никита работал в Microsoft в 2008-м и спонсировал чемпионат Урала [по спортивному программированию], который я выиграл, там и познакомились. Он помог попасть в Microsoft, а оттуда я ушел к нему в MemSQL», — рассказывает Скиданов. Тестировать продукт на первых порах Шамгунову бесплатно помогала жена Скиданова Мария. «Предложив ей присоединиться к команде, мы решили сразу две проблемы — получили в штат крутого разработчика и спасли Машу от скуки», — смеется Шамгунов.

Первое время после выпуска из Y Combinator команда работала на съемной квартире. Офис за $100 тыс. арендовали после выхода первой версии. А сегодня компания готовится переезжать в новое пространство — уже за $1,5 млн.

HipHop от Цукерберга

Технологии в основе бизнеса MemSQL Шамгунов создавал «руками» вместе со Скидановым и Праутом, они являются соавторами 11 из 12 патентов, закрепленных за компанией. СУБД MemSQL была призвана системно решать проблемы языка SQL — недостаточную скорость вычислений и масштабирования. MemSQL перед выполнением SQL-запроса переводит его на C++ и позволяет масштабировать операцию на несколько серверов. Благодаря этому та исполняется быстрее.

За перевод отвечает JIT-компилятор (Just in Time) — эта часть софта превращает языки в набор нулей и единиц. Компилятор MemSQL — разработка на основе аналогичных инструментов HipHop и Scuba от Facebook. Собственный JIT-компилятор, например, и у соцсети «ВКонтакте» — KPHP (его разработчики — бывшие соперники Шамгунова на турнирах по спортивному программированию Николай Дуров и Андрей Лопатин).

Софт от MemSQL позволяет находить ошибки в коде, не жертвуя скоростью. Он совмещает две модели конвертации данных — интерпретацию и компиляцию. Первая последовательно переводит каждую инструкцию в понятный машине двоичный код и выполняет ее. Вторая переводит и выполняет все инструкции сразу. Микс моделей нивелирует их минусы — автоматически отыскивает и обходит баги, не требуя вмешательства программиста.

СУБД MemSQL хранит основные данные в оперативной памяти (RAM) — на жесткий диск заносится только результат совершенных операций. Риск потери данных из-за обесточивания нивелируется за счет постоянного обновления лога операций — файла небольшого размера, в котором отражены все изменения базы. Информация в первых итерациях СУБД все равно иногда терялась, но клиенты не обращали внимания — скорость с лихвой компенсировала этот недостаток, говорил Шамгунов в 2012-м. Сократив время на обработку запросов, его команда добилась существенного прогресса по сравнению с классической имплементацией СУБД на SQL: скорость работы выросла в десятки раз.

«Базы данных должны быть простыми и максимально функциональными, как автомат Калашникова», — постулирует Шамгунов в интервью журналу РБК. Система MemSQL как раз из этого ряда, заверяет он. В основе структуры любых современных сайтов или приложений — обычные строки и столбцы с данными, напоминает предприниматель. Например, в «скелете» онлайн-магазина таблица с наименованием и ценой товара взаимодействует с таблицей покупателей, когда один из них решает приобрести товар. Эти данные взаимосвязаны и вместе создают базу данных, построенную на этих отношениях, — реляционную. Ровно такими базами и управляет MemSQL,

Расхититель Microsoft

Большой проблемой для MemSQL на первых порах был поиск квалифицированных кадров. «Инженеры в Долине — боги», — констатирует Шамгунов. Стартапу нанять программистов высокого уровня невероятно сложно: конкуренцию, как правило, выигрывают корпорации масштаба Facebook, Google и Twitter. Но и тут основатели MemSQL нашли выход. «Мы выбрали путь спонсирования соревнования TopCoder и переманивания сотрудников из Microsoft», — делится предприниматель.

TopCoder компания спонсирует с 2011-го, практически с момента своего основания (среди других спонсоров — Facebook и Intel). В первый год на соревнованиях высадился десант в составе Френкеля и Скиданова. Они привезли не только формальные предложения о трудоустройстве, но и приз для турнира по покеру — MacBook Air. Финал из-за нехватки времени пришлось проводить прямо во время ланча в последний день TopCoder — участвовали знаменитые программисты из России и Белоруссии Петр Митричев и Геннадий Короткевич.

Россия вообще остается важным поставщиком кадров для MemSQL. Например, научный руководитель Шамгунова Анатолий Шалыто в интервью «Хабру» в 2020-м рассказывал, как туда устроился двукратный чемпион мира по спортивному программированию, выпускник ИТМО Михаил Кевер. Профессор также вспоминал, что Шамгунов говорил ему о больших перспективах студентов Массачусетского технологического института: «Они такие же, как ваши, немного сильнее».

Наконец, колыбель кадров MemSQL — Microsoft. Шамгунов откровенно рассказывал в 2012 году: «Мы нарушили патенты, которые есть у Microsoft, мы увели у них несколько сотрудников. Плюс я нарушил договор не работать на конкурентов. В каждом случае Microsoft может нас засудить». Однако по последнему пункту судебных разбирательств не ведется, а в остальном репутационные и финансовые потери от тяжбы превысят эффект от победы, уверял предприниматель.

Цукерберг рекомендует:  Стили для изображений


Он и сегодня уверен в бывших работодателях: «У нас никогда не было с ними проблем. Более того, с Microsoft мы обсуждаем возможное сотрудничество». По словам предпринимателя, корпорации патентуют технологии не для подачи исков к стартапам, а для борьбы с патентными троллями. Собственные технологии MemSQL при этом прилежно патентует. «Важно подать заявку в патентное бюро и встать в очередь. В таком случае, если возникнут сложности, на руках у компании есть бумага, которая закрепляет право на использование технологии», — объяснял он во время одного из публичных выступлений.

Microsoft, как и Google, в последнее время действительно патентует технологии для защиты, а не исков, подтверждает партнер фонда Gagarin Capital Николай Давыдов. По его словам, в Калифорнии очень мягкие законы: сотруднику нельзя запретить конкурировать и переманивать людей. «Если компания и правда нарушала договоры и патенты, то проблемы могут начаться во время бурного роста или продажи конкурентам — до этого размер судебных издержек превышает пользу от выигранного процесса», — добавляет эксперт.

Подобная тактика — это жизнь в большом городе, считает Шамгунов. По его словам, все компании копируют успешный опыт конкурентов, этим и хороша Долина: «Здесь постоянно происходит обмен знаниями».

Развитие бизнеса в 2011 году все же вынудило Шамгунова расстаться с Facebook: «Один из друзей убедил меня, что если не уйду, то никто не решится участвовать в MemSQL на полноценной основе. Я уволился в пятницу и выходные провел в плохом настроении: $2 млн есть $2 млн».

Долго грустить не пришлось: рынок быстро оценил серьезность намерений Шамгунова, и уже в понедельник с основателями MemSQL связался помощник известного американского инвестора Рона Конвея. Спустя 20 минут переговоров с Конвеем на счет стартапа упали $200 тыс. Еще столько же в компанию через помощника Феликса Шпильмана вновь вложил Юрий Мильнер.

Первых клиентов MemSQL нашел в акселераторе. Один из резидентов набора-2011 очень быстро рос — команда нуждалась в технологиях для масштабирования инфраструктуры, вспоминал Френкель в интервью TechCrunch в 2013-м.

Его навыки также помогли в расширении базы инвесторов. Если венчурный рынок после удачного 2011 года настигло похмелье в форме оттока денег, то MemSQL удалось сохранить интерес к себе, говорит Шамгунов: в проект тогда вложились фонды GV (бывший Google Ventures) и In-Q-Tel, связанный с ЦРУ, а также актер и бизнес-ангел Эштон Кутчер и сооснователь PayPal, уроженец Киева Макс Левчин.

Запуск со слезами на глазах

Публичный релиз MemSQL состоялся все в том же 2011-м. Для бесплатного ознакомления с программой компания выпустила специальную версию с ограничениями. «Спустя несколько дней у нас было 10 тыс. скачиваний. Пробивало на слезы — мы вложили в релиз 16 месяцев тяжелой работы», — делится Шамгунов. По его словам, демоверсией пользовались даже компании из списка Fortune 500: «После связывались с нами и спрашивали: «У нас ваша программа работает на одной машине, будет ли работать на нескольких?»

Тогда рынок баз данных, на который нацеливались основатели MemSQL, оценивался в $60 млрд в год. «Нам не страшно было запускать бизнес по двум причинам: дешевая память (за несколько тысяч долларов можно приобрести терабайт) и растущий сегмент больших данных, который требует подобных решений. У Microsoft этих решений нет — мы знаем, мы там работали», — говорил Шамгунов в 2012-м.

По его словам, главное в b2b-софте — широкий ассортимент предложений для всех категорий клиентов. «В самом начале мы экспериментировали: называли разным людям разные цифры и следили за реакцией», — вспоминает предприниматель. Шесть лет назад он называл $25 тыс. в год за стандартный набор услуг MemSQL и $5 тыс. за каждый новый узел в системе. Эти расходы потянули десятки крупных компаний, встроивших систему MemSQL в свою ИТ-инфраструктуру. СУБД участвует в цепочках расчетов производителя продуктов Kellog’s, Cisco, Samsung Electronics и других игроков глобального масштаба.

Поначалу шум на рынке вызвали бравурные заявления стартапа о создании самого быстрого продукта в сегменте, который якобы работает в 30 раз быстрее ближайшего конкурента. Позже Шамгунов признался в маркетинговой уловке: «Любой инженер скажет, что сравнение скорости некорректно, так как компании часто используют выгодные им инструменты замера».

Публично оппонировал MemSQL бывший коллега Шамгунова и Френкеля по Facebook Домас Митузас. В личном блоге он раскритиковал заявление стартапа и аргументировал выводы примерами из системы конкурента — MySQL. «Прошло всего ничего после запуска, посреди ночи мне звонит Эрик и спрашивает, видел ли я пост Домаса. Мы сели готовить ответ», — говорит Шамгунов. Оказалось, Митузас неправильно составил запрос, ориентируясь на логику MySQL, отличную от MemSQL.

Так или иначе, но шум поднялся капитальный и о новом стартапе узнали на рынке, заключает предприниматель. Количество скачиваний в день скандала зашкалило, утверждает он. Шамгунов пришел в комментарии под постом Митузаса и в деталях объяснил природу ошибки: «Это победило выводок троллей. На следующий день мы опубликовали пост, в котором объяснили методику нашего подсчета и поставили точку в дискуссии». Шамгунов уверен, что пережить стрессовый период компании помогло философское отношение: «Гораздо проще убедить противника, чем человека, которому все равно».

Время и open source

Со временем функции MemSQL расширились. Продукты компании ее клиенты сегодня используют и для мониторинга состояния инфраструктуры, и для проектов в перспективной нише интернета вещей, и для бизнес-аналитики на лету. «MemSQL — это аналитическая платформа. Акцент на in-memory давно исчез. Многие таблицы сегодня не в памяти», — рассказывает Александр Скиданов, покинувший стартап.

Продукт менялся вместе с трендами на рынке, объясняет он: оригинальная стратегия не предполагала создания инструмента для работы с транзакционными базами данных, в которых каждая запись означает отдельную операцию. Изменили стратегию довольно быстро: уже в 2012-м Шамгунов рассказывал о популярности больших данных и необходимости работы с ними: «Все одержимы аналитикой, а мы предлагаем делать ее в реальном времени».

MemSQL также поддерживает отслеживание локации пользователей, на его основе можно построить приложения с высокими запросами. А один из последних кейсов — быстрые базы данных для приложений, способных распознавать предметы на фотографиях с помощью искусственного интеллекта. Этим занимается один из клиентов MemSQL — немецкая компания Everybag.

Среди конкурентов Шамгунов выделяет решения от Amazon (AWS Aurora), Google (Spanner) и Oracle. «В сегменте много новых баз данных, мы ждем их консолидации в нечто крупное», — прогнозирует предприниматель. Рынок, по его словам, «очень горячий»: на фоне глобальной цифровой трансформации и растущих объемов информации любая, даже самая крупная компания может мгновенно растерять преимущество «из-за агрессивных конкурентов».

MemSQL как бизнес чувствует себя уверенно, подчеркивает предприниматель. $30 млн инвестиций, привлеченных в мае, тратятся на развитие инфраструктуры и расширение команды: по подсчетам Y Combinator, компания создала уже около 80 рабочих мест. «Мы пока работаем в убыток, но точно находимся ближе к окупаемости, чем конкуренты из корпоративного сегмента», — считает Шамгунов. По его словам, на IPO компания не собирается.

За восемь лет существования проекта его преимущества практически не изменились: компания предлагает быстрый и недорогой по сравнению с конкурентами набор решений для работы с данными, возможность использовать для развертывания любое облачное решение и обработку информации практически в реальном времени, перечисляет Шамгунов. Сам он продолжает вкладывать немало усилий в масштабирование бизнеса — Эрик Френкель отошел от оперативного управления, чтобы посвящать больше времени семье.

Шамгунов не скрывает гордости за свое детище: «Мы многого достигли. Когда начинали, было трудно представить, что такой сложный софт можно написать такой небольшой командой». Размышлять в сослагательном наклонении о перспективах подобного бизнеса на родине он не хочет: «Преуспеть можно где угодно, в жизни нет четких правил. Если бы мы запускались в России, времени ушло бы больше и проект пришлось бы делать по модели open source».

Как программисту найти компанию мечты?

Рассказывает Вячеслав Муханов, .NET Developer в DD Planet

В начале карьеры далеко не каждый программист понимает, какой формат работы ему подходит. В результате он часто меняет места работы, пока не находит идеальную компанию. Куда и почему лучше идти работать — в небольшой стартап, в компанию, которая создает софт для себя, или в команду, специализирующуюся на разработке для сторонних организаций?

Найти идеальные условия, в которых бы хотелось работать изо дня в день, — главная задача программиста. Чтобы понять, какая обстановка вам ближе, рассмотрим несколько распространённых бизнес-стратегий.

Небольшие группы людей, которые работают над собственным проектом

Обычно команды стартапов состоят из руководителей и менеджеров по продажам. При этом на проекте обязательно есть один или два технически грамотных специалиста или даже программиста, которые отвечают за общую организацию разработки продукта и распределяют задачи между привлечёнными фрилансерами.

Если программиста берут в команду на фултайм, значит его оценивают, как важный актив. От него будут ждать полного погружения в проект и большой отдачи. Соглашаясь на такой формат работы, специалист должен быть готов к тому, что общий результат будет зависеть от его умения «сколотить команду» и заставить её трудиться. Фрилансеры обычно слабо организованы и не представляют себе, как выстроен целостный процесс разработки продукта. Их нужно постоянно контролировать: формулировать задачи, устанавливать сроки, корректировать действия.

Фултайм-разработчик в стартапе выполняет задачи, связанные с построением архитектуры ПО, а также занимается технической реализацией идей руководства и менеджеров по продажам. Это прекрасная возможность развить потенциал IT-специалиста. Особенно, если он уже приобрёл достаточный опыт работы в профессии и горит желанием создавать новый продукт. Работа идеально подойдёт программисту, которому нравится общение не только с «коллегами по цеху», но и с менеджерами. Это поможет развить управленческие навыки.

Главный плюс таких команд в том, что здесь обычно приветствуют внедрение новых подходов, технологий, языков разработки и фреймворков. Можно экспериментировать и учиться, развивать навыки оперативного решения нестандартных задач.

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

Компании, которые делают проекты на заказ

Иногда стартапы окончательно разочаровываются в своей бизнес-идее, но, сохранив костяк персонала и получив хороший опыт разработки, начинают брать проекты на заказ. Появляется стабильное финансирование, формируется более-менее постоянный коллектив. Но и здесь не всё гладко. Рынок диктует свои условия: почти всем клиентам полностью готовый продукт нужен «ещё вчера». К тому же работа с заказчиками всегда стрессовая: придётся запастись терпением, научиться обосновывать свою позицию, работать с возражениями.

Для программиста начинается рутина. Сегодня он занят своим проектом, а завтра всеми силами пытается помочь коллегам, которые не успевают сдать продукт в срок. Ну а в редкие свободные минуты приходится заниматься оценкой временных затрат на очередной потенциальный проект и работать не с кодом, а с таблицами Excel. Новые технологии приветствуются, только если они помогают сократить объём рутины и автоматизировать стандартные процессы. Посидеть и обдумать эффективность кода получается редко. Перфекционистам в такой обстановке придётся нелегко.

И всё же есть свои плюсы: программист научится делать всё. Конечно, поначалу будет тяжело переключаться с бэкенда на фронтэнд, а в перерывах проектировать базы данных. Зато появится шанс сделать наработки на будущее — накопить множество шаблонов проектов-заготовок под любые задачи. Ещё один плюс: работая в таком ритме, придётся постоянно следить за развитием актуальных языков и фреймворков.

Компании, которые работают над собственным экономически успешным проектом

Чаще всего такой продукт создаётся годами. Закономерно, что компания-разработчик накапливает огромный legacy-код своего продукта — неповоротливый и скучный, но стабильный и предсказуемый.

Программисту не придётся делать что-то в спешке: все задачи — глубокие, на внимание. Процессы давно отлажены. Нужно лишь кропотливо внедрять интеллектуальную функциональность, улучшать производительность, заниматься масштабированием продукта. Запускать тесты и продумывать мониторинг. Именно здесь разработчику пригодятся фундаментальные знания алгоритмов и математики. Будет лучше досконально изучить какое-то одно направление или фреймворк и использовать его максимально эффективно.

Работая над живым и масштабным проектом с тысячами пользователей, можно приобрести уникальный опыт. Например, научиться создавать алгоритмы машинного обучения или качественно анализировать Big Data. Это прекрасный фундамент для успешной и долгосрочной карьеры.

Наконец, это оптимальный вариант для интроверта: не нужно отвечать на внезапные вопросы клиентов и менеджеров. Текучки персонала в таких компаниях почти нет, и коллеги могут стать «второй семьёй».

Компании, которые работают над собственными проектами и параллельно делают работы на заказ

Компания, успешно развивающая собственный крупный продукт, может похвастаться опытными руководителями, грамотными исполнителями и мощной технологической базой. Это позволяет бизнесу расширяться и брать в разработку сторонние проекты. Чаще всего такую бизнес-стратегию выбирает тот, кто хочет снизить риски за счёт диверсификации.

Для компании внешние проекты — прекрасная тестовая площадка. Здесь можно «обкатать» новые технологии, а затем внедрить их в собственный продукт. Для программистов клиентские заказы — возможность периодически переключаться с поддержки основного проекта на разработку нового.

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

В компании, которая специализируется на внешней и внутренней разработке, раскрыть свой потенциал сможет и новичок, и профессионал. Ведь у программиста всегда есть возможность заняться тем, что ему интересно. И для этого вовсе не обязательно менять место работы.

Вместо заключения

Задумываясь о трудоустройстве, честно ответьте себе на вопрос, какой путь вам ближе: участие в стартапе, многозадачность и постоянная динамика или стабильная команда и работа над фундаментальными задачами, анализ больших данных, поддержка проектов с историей и возможность стать высококвалифицированным специалистом?

Идеальный вариант, когда темп и подход компании сочетаются с темпераментом программиста и его представлениями об идеальной организации процесса разработки.

Жизнь после кода. Из программистов в бизнес-консультанты, менеджеры, продавцы

Меня зовут Михаил Завилейский. Формально я — генеральный директор DataArt. Но, на самом деле, просто из один многочисленных руководителей компании — ведь самого главного начальника у нас нет. В DataArt я отвечаю за организационное развитие. До прихода сюда 10 лет работал в IT — в основном программистом, но также немного и менеджером.

В этой статье мы поговорим о карьере. Я расскажу, что происходит с программистами, которые почему-то хотят перестать работать инженерами. Сказанное будет относиться также к тестировщикам, инженерам качества, автоматизаторам и другим смежным специалистам. Мы посмотрим, куда могут двигаться такие специалисты.

Причины перехода

Я полагаю, что причины того, что многие люди со временем меняют специализацию, — это возрастные изменения нашего мозга. Согласно разным научным исследованиям, логический интеллект у большинства с возрастом слабеет и мало у кого усиливается. Так, в современной математике и физике большая часть самых важных открытий делается в молодом возрасте, и опыт не может заменить возрастное снижение живости ума.

Опыт, тем не менее, помогает лучше угадывать, что нужно клиенту; также растет эмоциональный интеллект, развивается лучшее понимание мира и отрасли — оказывается, такие навыки могут отлично пригодиться в других областях IТ-индустрии.

Наша индустрия развивается от содержательно сложных проектов к разнообразно сложным. Почти все содержательно сложные проекты (когда ясно, что именно нужно сделать, но сделать это трудно) были реализованы в IТ-индустрии уже много раз: так, было создано много хороших бухгалтерий, банковских систем; встроенные программы работают в машинах, самолетах — всё это уже есть.

Сегодняшние же задачи характеризуются тем, что мир становится разнообразней и понять, что нужно делать, становится всё сложнее, ведь не всегда понятно, чем отличается одно от другого. Так, если вы пишете интернет-магазин в своей жизни, вам не совсем понятно, чем он должен отличаться от предыдущих Или кто-то делает очередную социальную сеть, и важно понять, чем она должна отличаться от других, чтобы она взлетела. Таким образом, умение понимать, что нужно сделать, становится всё более важным.

И вот здесь можно совершить переход от программирования к тем специальностям, которые помогают понять, что нужно сделать.

Карьера инженера

Вот типичный карьерный путь программиста, тестировщика или другого IT-специалиста:

Итак, кто-то начинает работать с младшей позиции. На самом деле, джуниор отличается от синьора главным образом тем, что обычно получает часть компенсации своего труда не деньгами, а опытом и обучением. Таким образом, на джуниорах компании зарабатывают больше, а джуниор выбирает компанию правильно, если там может многому научиться. По сути, отличия между джуниором и синьором на 80% — в психологических качествах, и лишь на 20% — в знаниях и опыте.

Пожалуй, самый лучший совет по развитию в себе «синьорности» — всегда думать не о том, что я делаю, а о том, кто мой клиент и кого я обслуживаю. Синьор — тот, кто всё понимает и делает сам, не требует никакого присмотра, сам собой управляет и умеет себя продавать. Если с вами удобно работать, и от вас всегда получают хороший предсказуемый результат, у вас будет репутация синьора. Если вы умнее всех, но взбалмошны — останетесь гениальным джуниором.

Продуктовым компаниям приходится бороться за удержание синьоров, так как последние обладают действительно большим объёмом навыков, но устают, им надоедает заниматься одним и тем же. Сервисные же компании могут предоставить разнообразие, но на синьорах очень трудно заработать — их всегда не хватает, зарплаты всегда очень рыночные, и синьор находится в балансе с окружающей средой.

Конечно, синьору может быть интересно бесконечно долго, но, как показывает опыт, многие из них перемещаются на другие позиции:
— Эксперт;
— BC — business consultant (бизнес-консультант);
— PM — project manager (менеджер проектов);
— SM — sales manager (менеджер по продажам);
— AM — account manager (аккаунт-менеджер);
— OM — operations manager (операционный менеджер).

Перемещение инженеров на такие позиции происходит, как правило, естественным путём — когда в компании появляется возможность делать то, чего ты не делал раньше.

А теперь попробую рассказать, как управлять сменой своей профессии, и поделюсь наблюдениями, какие ключевые факторы определяют развитие в том или ином направлении.

Репутация, а затем квалификация

Как я себе представляю профессионала? На мой взгляд, профессионал состоит из двух частей:
1) Квалификация — умения, опыт, навыки;
2) Репутация — то, что о нем знают окружающие.


По моим наблюдениям, большая часть профессионалов предпочитает качать квалификацию. Они изучают новые движки, читают книги по программированию, участвуют в состязаниях программистов — в общем, повышают профессиональную квалификацию всеми возможными способами. Большинство представляют свою карьеру именно так: «Я всему научусь, окружающие увидят, как хорошо я всё делаю, и меня повысят». Но, как показывает опыт, обычно людей не слишком интересуют другие люди (разве что, другими интересуются профессиональные менеджеры, ответственные за развитие персонала). Люди обычно полагают, что всё, что происходит без их прямого вмешательства, происходит само собой. Например, если вы написали идеальный код, — ну, вам повезло, просто так получилось. И вашей заслуги в этом никто не увидит, если только вы сами не расскажете о трудностях, которые пришлось преодолеть.

Как вас видят другие — очень важно для карьерного развития. А другие воспринимают вас через свой непосредственный опыт, а не через то, что вы сами о себе знаете. Это значит, что всё время нужно заниматься самопиаром и делать это даже вперед профессионального развития.

Отсюда — первое правило развития: Репутация должна опережать квалификацию.

Проявить себя

По-настоящему мы учимся, только делая что-нибудь. А чтобы нам доверили что-нибудь делать, нам должны поверить, чтобы мы с этим справимся. У компании и у людей новые навыки появляются тогда, когда их «по ошибке» просят сделать что-нибудь такое, что они еще до этого никогда не делали. Конечно, так делать не надо (это рискованно), но иногда что-нибудь новое мы учимся делать именно так. И, если мы хотим быстро развиваться, можем эти ошибки провоцировать, чтобы нам доверили что-то сложное. Именно по такому пути зачастую происходит самое интересное карьерное развитие в компании.

Я могу это смело утверждать, потому что довольно редко, по моим наблюдениям, хорошие инженеры становятся хорошими менеджерами легко. Менеджером может стать и хороший, и плохой программист. Однако у не очень хорошего программиста будет выше мотивация перейти в менеджеры. Сейчас я забегу немного вперед и проиллюстрирую это примером пути продавца.

Итак, однажды у нас в компании появился не очень хороший коллега-программист. Я познакомился с ним, когда он вызвал команду ОС «удалить всё из текущего каталога» из сервера приложений (тогда это был ASP) — так он удалил из «system32» всё, что можно было удалить. После этого сервер продолжал работать какое-то время (файлы, которые в тот момент использовались, не удалились), но он никогда не перезагрузился бы и скоро упал, как только захотел бы сделать что-нибудь новое и загрузить какой-нибудь dll из system32.

Я уже не помню, чем закончилась эта история. Но, как бы то ни было, этот коллега продолжил развиваться в компании, но сильных технических задач ему уже не доверяли. Зато ему всегда больше всех было надо, чтобы всё было хорошо: он никогда не верил, что нельзя сделать хорошо ту или иную вещь, или что заказчик не может быть удовлетворен. Таким образом, его репутация складывалась из так называемых soft skills, социальных навыков. Мы знали, что мышление у него не слишком инженерное, но зато клиент-ориентированное, результат-ориентированное, в чем-то то перфекционистское, — при этом он отличный партнер, который помогал команде показывать лучший результат. Теперь, по прошествии 18 лет, этот человек, Алексей Миллер, сидит в Нью-Йорке, возглавляет все продажи в DataArt.

Бывает, что мы можем проявить себя гораздо лучше не в кодировании, а в чем-то другом. Это совершенно нормально — в современном IТ-мире для этого есть очень много возможностей.

Изменение мотивации

Однако на этом пути нас подстерегают некоторые ловушки. Несмотря на то, что я никогда не был очень хорошим программистом, я никогда в жизни не был счастливее от работы, чем в те времена, когда работал просто инженером. Почему? Потому что когда после долгой и трудной работы у меня всё запускалось и работало отлично, я испытывал яркое и естественное удовольствие. При этом я знал, что это сделал именно я, и сделал хорошо.

Есть чудесный цикл, поддерживающий всех профессионалов счастливыми, который я назвал «do-check-enjoy» («сделать-проверить-радоваться»). Мы что-то делаем, мы можем это проверить, и нам даже не нужно постороннее мнение — мы видим, что мы это сделали круто. Такие события, повышающие самооценку, случаются постоянно. Один из моих любимых авторов, Дэвид Майстер, писал, что самооценка у всех профессионалов исходно занижена — именно это из-за этого профессионалы несчастливы на простой работе, а постоянно стараются учиться чему-то новому, создавать для себя новые вызовы и что-то себе доказывать. Я могу сказать, что это совершенно точно относится ко мне и к большому количеству моих коллег. Цикл «do-check-enjoy» действительно дает много счастья. И чем больше ты начинаешь смещаться в сторону более сложных и коллективных ролей, тем меньше остается возможностей наслаждаться этим циклом.

У меня нет хорошего примера на этот счет из области IТ, но я могу привести отличный пример из области медицины, который приводят все врачи, когда читают лекции по деонтологии (медицинской этике). Однажды известного врача, впервые в мире сделавшего пересадку сердца и сделавшего много таких операций впоследствии, Кристиана Барнарда, спросили: «Доктор, спасли ли вы чью-либо жизнь наверняка?» Доктор Барнард ответил, что не знает, но всё-таки одну жизнь он точно уж спас. Он рассказал, как в молодости поехал лечить одного фермера, болеющего пневмонией и находящегося в тяжелом состоянии. Жена фермера не верила в благоприятный исход и хотела прибегнуть к народному средству: убить козу и завернуть фермера в ее шкуру. Однако доктор Барнард сказал, что сначала он всё же еще попытается спасти жизнь фермера средствами общепринятой медицины. В итоге доктор Барнард сумел за одну ночь спасти фермера, и, выйдя наутро из дома, проходя мимо козы, которую хотели убить, произнес: «Коза, я спас тебе жизнь!»

Этот пример показывает, как непросто быть врачом: нужно тешить себя мыслям, что ты действительно помогаешь людям, хотя обычно даже не знаешь, наверняка это или нет. А если ты инженер, точно знаешь, что такой-то код заработал в 10 раз быстрее, — и это факт. Если же ты менеджер, продавец или аналитик (а это — командная работа), увидеть результат своих действий вне взаимодействия с большим количеством людей невозможно. Если никто ничего не слил, всё получилось, все молодцы, и ты, наверное, тоже. А когда что-то пошло плохо, иногда знаешь, что это точно твоя вина.

Таким образом, потеря ощущения, что ты делаешь свою работу точно хорошо, — главный демотивирующий фактор при перемещении с роли программиста на другие позиции в IТ. Это важно понимать. Если при переходе на коллективную работу мы будем тешить себя иллюзиями, что всё, что сделано хорошо, сделано мной — будем плохими менеджерами, плохими руководителями и плохими консультантами. Вместо этого нам нужно осознавать, что мы работаем в коллективе, и это — данность. Как доктор Барнард, мы должны понимать, что мы, может быть, когда-нибудь сможем спасти жизнь козы, но не более того.

Это качественное изменение — с представлением, что мы сами себя сможем продолжать оценивать и гордиться собой, придется проститься. Другими словами, нужно распрощаться с инженерским комплексом неполноценности, который толкал нас что-то себе постоянно доказывать. Вместо этого нужно будет развивать уверенность в себе, и это — самое важное при переходе с программистской позиции на менеджерскую.

Путь эксперта

Одна из самых сладких для разработчиков возможность — стать экспертом. Роль идеального IТ-эксперта лежит где-то на пересечении трех возможных ролей:

Decision maker — тот, кто принимает решения. Эти люди берут на себя ответственность.

Узкий эксперт — тот, кто знает, как работают те или иные вещи. Или, что даже важнее, часто эксперты знают очень много про то, как вещи не работают. Ведь есть много способов делать вещи заведомо неправильно. И хороший эксперт, как минимум, должен помочь избежать заведомых ошибок. Эксперты, как правило, помогают вне ключевой компетенции той деятельности, в который вы работаете, то есть вам нужен эксперт там, где вы не разбираетесь сами. Эксперт, как и decision maker, берет на себя ответственность в значительной степени, ведь он рискует репутацией.

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

В IТ в работе с бизнес-заказчиками нужна, в идеале, роль, которая лежит на пересечении этих трех, — и это самая сложная роль. Такого рода людей очень мало.

Например, мы разрабатываем для какой-либо компании индустриальное программное решение. В этом случае есть много областей, где клиент более компетентен, чем мы. Тогда мы должны выступать в роли консультанта, не грузить клиента лишними переживаниями, а способствовать процессу принятия решения — это во многом социальная роль.

В более технической же области, где вы компетентны более, чем заказчик, взять на себя ответственность и принять решение должны именно вы. То есть вы должны выступить в роли эксперта. Если же вы предоставите заказчику набор возможных вариантов и посоветуете ему принимать решение самому, в случае незрелого клиента, это будет манипуляцией, потому что он будет выбирать между вариантами, отличия которых ему самому не очень понятны. В итоге он окажется ответственным за непонятный ему самому выбор. Зрелый же клиент просто откажется так работать.

Если же ситуация предполагает большое количество людей, важно помочь правильно определить границы ответственности, и это — самое трудное. Сейчас самые развитые компании, работающие в IТ, стараются перейти от продажи часов и усилий к продаже решений. Связано это с тем, что мы никогда не произведем столько же часов, сколько производится в Индии или Китае, ведь часы работы, которые стоят в 5 — 10 раз дороже, чем те же часы в Азии, продать очень трудно. Поэтому все компании хотят, чтобы цена формировалась в зависимости от ценности услуги для клиента, а не количества потраченных часов. И здесь, конечно, границы ответственности, о которой нужно договориться заказчику и исполнителю заказа, — большой вопрос. Умение нащупывать эту границу — высший уровень в бизнесе и управлении.

Теперь еще пара комментариев, кто такой эксперт. Есть неправильное понимание эксперта — когда считают, что эксперт — это просто тот, кто самый умный или просто что-то лучше знает. Но это не всегда так. Чтобы быть экспертом, нужно знать очень много в какой-то узкой области.

Также важно, что эксперт — не соревновательная роль. Эксперт — не тот, кто самый упрямый, не тот, кто всех всегда переспорит (хотя такой человек и может сделать себе репутацию эксперта, но такие люди играют разрушительную для компании роль). Эксперт — тот, кто опытен, уверен, но, несмотря на это, остается восприимчивым, может быстро менять своё мнение, если узнает, что он неправ.

Цукерберг рекомендует:  Оригинальные checkbox на jQuery

Наконец, эксперт должен быть позитивен — не в том смысле, конечно, что он всегда улыбается. Позитивный человек в данном случае — тот, кто дает конструктивные формулировки, видит положительные возможности, а не только проблемы и трудности.

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

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

Путь менеджера проектов

Роль менеджера проектов — самая естественная для бывших программистов. К ней иногда приходят через промежуточную роль лидера команды. Менеджер проектов должен уметь огромное количество вещей. Картинка, которую я нашел в интернете, описывает необходимые навыки менеджера проектов:

Однако самое главное среди этих слов я не наше. Чем отличается управление проектами от любого другого менеджмента? Тем, что проект однажды заканчивается, у него есть конечная цель. Поэтому основная роль менеджера проектов — добиться конечной цели проекта. Конечная же цель проекта — получить одобрение заказчика, попасть в его ожидания.

Поэтому управление ожиданиями — самая главная функция менеджера проектов, в отличие от остальных менеджеров в сфере IТ.

Таким образом, менеджер проектов всегда думает о конце проекта, о том, попадет ли он в ожидание. Ожиданиями нужно управлять, двигать их, потому что редко ожидания, что были в начале проекта, останутся такими же и к концу проекта. Ведь откуда появились гибкие методы разработки? Когда проекты длятся много месяцев, в современном мире за это время всё меняется. Соответственно, меняются и ожидания. Работа современного менеджера проекта — гонка за движущейся целью.

Менеджер проектов это не тот, кто нарисовал план и строго ему следует, а талантливый человек, который понимает, что ожидаемый результат подвижен, будучи зависим от разных факторов, и в соответствии с этим постоянно вносит изменения в план и управляет ресурсами, стараясь попасть в цель на пересечении многих изменчивых факторов. Менеджер проектов — не тот, кто просто управляет подчиненными (хотя сейчас идеальная команда — team of peers, команда равных, где нет явных начальников), а тот, кто влияет на огромное количество людей вокруг и на их представления, что нужно делать, — так, чтобы они сошлись в одной точке и остались довольны друг другом. Это — самое важное.

Если мы строим дом и постоянно меняем требования, дом получится странным и дело, скорее всего, добром не кончится. Если мы работаем с материальным миром, мы должны держать план более или менее устойчивым. В разработке же ПО у нас есть достаточно много свободы, и очень редко получается, чтобы длительный проект оставался стабильным. Чаще всего это — постоянный поток возможностей что-то изменить.

Например, я, когда был менеджером проектов, всегда начинал с того, что проверял степень свободы, — старался выяснить, что могу поменять. Для этого старался немного поменять план проекта, спросить об изменениях в бюджете, чуть-чуть подвигать сроки, чтобы просто посмотреть, как на это реагируют клиент и все остальные. Это позволяло быть готовым к тому, чтобы действительно что-то поменять, когда изменения нужно будет внести. Если это становится нормой, можно сохранять хорошие отношения в ходе проекта и легко вносить нужные изменения.

Если же клиент воспринимает любые изменения в штыки, нужно быть устойчивым и обстоятельным по отношению к любым просьбам об изменении объема проекта. Если идти на поводу у таких просьб, всё для этого проекта может закончиться плачевно. Например, в гибкой методологии разработки один из главных принципов — «fail early», согласно которому неуспех должен случиться как можно раньше. В общении с клиентами из бизнес-культуры очень важно как можно быстрее проверить все возможные засады, которые могут привести к разрушению отношений.

Для менеджеров проектов понимание, что они влияют на огромное количество людей вокруг и занимаются широкой координацией, а не управлением и защитой изначального плана, — главный вызов сегодняшней индустрии. Ведь многие ребята, которые пытаются стать менеджерами проектов, полагают, что хороший план проекта, хорошие оценки затрат, правильные процедуры защитят их от неопределенности окружающего мира. Нет, не защитят. Вместо этого мы должны учиться извлекать из неопределенности достаточное количество преимуществ, чтобы они компенсировали случающиеся у нас проблемы.

Путь продавца

Это — самый трудный путь и, по моим наблюдениям, самый непопулярный среди бывших программистов. Во-первых, это связано с тем, что продавец не обязан быть компетентным в инженерном деле, и поэтому продавцы часто приходят с других позиций и мест. Во-вторых, у инженера, в отличие от продавца, эффективность труда намного выше. Хороший инженер не может себе позволить допускать большой процент брака, на мой взгляд, у хорошего инженера более 90 % работы выполняется очень успешно. У продавца же производительность труда намного меньше: при большом количестве потенциальных покупателей лишь немногие что-то у вас покупают. В норме подписывают контракт менее 10 % контактов, попавших в поле зрения продавца. Поэтому инженеру обычно психологически очень трудно перейти в продажи, не насмотревшись на процесс продаж и не привыкнув.

Поэтому в роли продавца, как нигде, чрезвычайно важна ни на чем не основанная крепкая уверенность в себе и вера, что то, что ты делаешь, — правильно. Другими словами, важно, чтобы самооценка продавца не слишком зависела от успехов и неудач, да и вообще от чего-либо определенного — ведь самооценку, зависящую от чего-либо, всегда можно чем-либо подорвать. Для всех менеджерских ролей, и особенно для роли продавца, очень важен принцип доктора Хауса, который не всегда прав, но всегда уверен в себе, потому что по-другому ему трудно работать.

Так что перед тем как перейти на позицию продавца, очень важно запастись уверенностью в себе — тем более, чтобы понять, насколько вы хороший продавец, понадобится не менее двух лет (тогда как синьор в одной технологии может стать пусть не самым лучшим, но всё же синьором в другой технологии всего за три-шесть месяцев).

Путь аккаунт-менеджера

Есть огромное количество вещей, которые происходят в аккаунт-менеджменте. Это передний рубеж, на которым узнают, что нужно сделать, чтобы заработать денег. Аккаунт-менеджмент связан, в первую очередь, не с развитием каких-то навыков и умений, а с тем, как вы думаете, как используете воображение.

Классическая инженерная команда держит в фокусе внимания программное решение, которое она разрабатывает. Команда же аккаунт-менеджеров стремится развить индустриальное понимание. Если, например, мы имеем дело с разработкой банковской системы, она должна обладать такой-то производительностью, такой-то надежностью, должна быть совместима с такими-то протоколами — иначе она не взлетит. Индустриальное знание помогает понимать, как это обычно работает и чего от нас ждут. Обычно от нас ждут какой-то функциональности и помощи конкретному бизнесу в конкретной индустрии, ждут решения типичных бизнес-задач, которые были сформулированы и описаны в спецификациях, а не идеального кода в больших объёмах.

Самое крутое — бизнес-мышление, которое позволяет думать вместе с клиентом или даже без клиента, как сделать хорошо. Бизнес-мышление позволяет делать внешние и внутренние стартапы, получать бюджеты там, где их не было, позволяет убедить клиента сделать что-то большое и новое и рискнуть чем-то. Часто говорят, что бизнес-мышление присуще людям, которые в конце видят деньги и понимают, как до них дойти. В каком-то смысле это верно, но в современном мире денег всё больше, но в то же время всё больше и страхов отсутствия взаимопонимания. Поэтому те, кто работает в аккаунт-менеджменте на высшем уровне, производят смыслы: задаются вопросом «а какой смысл делать такой-то проект?». Если привести аргументацию, что смысл в этом есть, все делают этот проект.

Умение находить и создавать смыслы — главный атрибут бизнес-мышления. Если вы хотите убедить человека что-то делать, попробуйте рассказать ему, в чем смысл. Если люди понимают, что вы предлагаете, и соглашаются с этим, видят в этом смысл, вы производите смыслы и можете двигаться к высотам аккаунт-менеджмента. А большинство старается выяснить смысл, думая, что он есть у кого-то в голове. Это чуть ниже бизнес-мышления — индустриальный уровень.

Путь операционного менеджера

Наконец, меньшинство из коллег становятся руководителями компании — операционными менеджерами. Как говорил мой преподаватель с физфака, «мы производим большое количество обученных физике людей и воспроизводим небольшое количество себе подобных, которые двигают науку вперед». Руководители, менеджеры компании тоже этим занимаются. Они производят большое количество инженеров (это похоже на обучение и развитие), и определенное количество попадает на операционные должности.

На операционных должностях важно понимать, какова культура компании и чего от вас ждут. В очень простой классификации, все операционные менеджеры, на мой взгляд, делятся на три категории: хозяева, начальники и сервисы.

Хозяин — тот, кто упрощает жизнь остальным менеджерам и бизнесменам компании. Он закрывает свою зону ответственности, он — главная и часто единственная точка контакта. С ним можно договориться, и на него можно положиться — всё просто и хорошо. Это не всегда эффективно, так как хозяин зачастую не желает выносить сор из избы, не использует оптимально все ресурсы компании, плохо взаимодействует с другими функциями, но зато упрощает жизнь других менеджеров компании.

Начальник — классическое иерархическое лицо, указания которого выполняешь, а затем отсылаешь ему отчёты о проделанной работе. Иерархии в нашей жизни работают, и ничего плохого в этом нет. Но, к сожалению, с начальником, чаще всего, возникает деструктивная игра — если мы делаем всё хорошо, у нас возникает представление: «Это именно я всё делаю, а он только командует». Если мы сделали что-то плохо, думаем: «Я-то делаю всё хорошо, просто это он дурацкие указания дает».

В психологическом смысле начальник нам полезен — мы присваиваем заслуге себе, а ответственность за неудачи переносим на него. Элементы этой психологической игры я вокруг встречаю постоянно. Многие даже стараются найти начальников вокруг себя. Я и на себе ощущаю это давление — от тебя ждут, что ты включишься в эту игру. Включаться или не включаться — выбор каждого, так как каждому удобно работать по своей модели.

Сервис — это менеджер, который просто помогает сотрудникам делать их работу. Я считаю, что в IТ для многих продвинутых компаний сервисная модель — самая привлекательная. Согласно этой модели, на компанию, занимающуюся разработкой заказного ПО, можно смотреть как на компанию, которая сводит инженеров с потребителями их работы, и обслуживает весь этот процесс. Поэтому всё, включая управление капиталом, корпоративное управление, кадровое управление, финансы и т. д. — просто сервисы, которые обеспечивают сотрудникам рабочий процесс. Это, конечно, радикальная модель, но мне она нравится — при ней ты не делаешь ничего лишнего, пока тебя не попросили.

Но, конечно, на самом деле всё не так просто: нужно всё же объяснять людям, что можно попросить и зачем, убеждать людей пользоваться сервисами, иначе ничего работать не будет. Мне кажется, что сервисный взгляд на корпоративные функции выглядит перспективным и интересным, хотя и имеет свои издержки — всем нравится, когда нас обслуживают, и, если совсем впасть в сервисную моду, есть опасность, что все будут пытаться сесть друг другу на шею. Поэтому к вопросу нужно подойти цивилизованно — научить людей «правильно» пользоваться сервисами, что важнее всего в реализации сервисного подхода.

В любой компании все вышеупомянутые функции могут сочетаться, разные люди будут ближе к той или иной роли, но, если вы движетесь к руководящей позиции, такая классификация поможет вам разобраться с точки зрения самоидентификации, где вам удобнее. Если вам неудобно командовать, вы вышли из управления проектами, где использовали влияние на окружающих, вам подойдёт сервисная модель. Если же вам хочется вернуть себе радость от мысли, что именно я сделал то или иное хорошо, быть вам хозяином. А начальником вы и так станете, если не будете делать ничего особенного: ведь выстраивание иерархий — самое естественное поведение в корпоративном мире, которое складывается само собой.

Как программисту попасть в крупную компанию? Советы HR-специалиста

Специалист по подбору IT-персонала Юлия Гадалина, ведущий IT рекрутер HR-PROFI, рассказывает типичные ошибки программистов при трудоустройстве, и как в 2020 году позиционировать себя.

С каждым годом IT сфера растет и развивается и, наверное, у каждого есть такой знакомый, который вдруг ни с того ни с сего захотел стать разработчиком. Откуда берутся подобные тренды? И почему такая узконаправленная специальность постепенно становится мейнстримом?

Ответ на поверхности – большие заработные платы и чрезвычайная востребованность. Очевидно, что каждый разработчик хоть раз думал о Microsoft или Google. Но как попасть в такую корпорацию и насколько это реально? Давайте попробуем разобрать основные вопросы.

С чего стоит начинать?

Я имею опыт подбора IT специалистов разного уровня от Junior до TeamLead и работала как с российскими компаниями, такими как Яндекс и Avito, так и с международными компаниями, Alphabet Inc (Google, Nest, Calico), продуктовыми швейцарскими компаниями. Попасть в такие корпорации не так сложно, но здесь нужно учитывать несколько важных факторов:

1. Английский язык. Самый логичный способ попасть в крупную зарубежную компанию — изучать английский язык. Как минимум для того, чтобы работать в распределенных командах и общаться с иностранными коллегами.

Уровень английского будут оценивать на первых этапах собеседования, поэтому важно уметь изъяснить свои мысли и представить себя как специалиста. Не думайте, что если вы хороший специалист, то можно “забить” на английский. Знание языка сейчас требуют и в российских компаниях, но дальше – больше.

2. Высшее образование. Да, как ни странно, но в зарубежных компаниях смотрят на диплом. Зачастую к нам в рекрутинговое агентство приходят заявки на подбор, и клиент указывает на то, что специалистов без высшего образования не следует рассматривать.

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


3. Коммуникация. Принято считать, что разработчики — безнадежные интроверты, и мир это понял и принял. Но если на старте кандидат проявляет доброжелательность и приветливость — это существенно повышает его шансы на трудоустройство. К тому же, контактность косвенно может повлиять на уровень дохода.

Коммуникабельных сотрудников быстрее продвигают по должности и поднимают заработную плату. Объясняется это тем, что руководящие должности предусматривают собой управление, чтобы координировать командой, нужно сначала уметь находить с ней общий язык.

Программисты vs продажники

Жил был один менеджер по продажам. Пошел устраиваться на работу. Долго
ли коротко ли резюме рассылал, а как-то пришел в одну контору на
собеседование с генеральным директором. И шло у них собеседование шесть
часов. Уже и директор взмок, и менеджер три раза воды просил. А все
никак не могут договориться. Начинали с двухсот баксов в месяц — а уже
за два с половиной килобакса спорят, и проценты, и бонусы, и какие-то
еще там спортзалы, мобильные связи, обеды, подъемные, страховки, отпуск,
командировочные, машину служебную, ноутбук, кучу всякого менеджер себе
выбил. Сдался в итоге генеральный директор, все условия выполнил. Все,
что менеджер просил — дал.

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

Потому что это был, сука, очень хороший менеджер по продажам.

MatrosoV AleXXXand_R

(0) «Почему, те кто создают(инженеры, изобретатели, учёные) имеют меньше денег, чем те которые продают плод творчества выше перечисленной группы?»

А кого с кем сравнивать? Продажник запросто может заработать больше программиста, если есть голова на плечах и желание работать

Жизнь после кода. Из программистов в бизнес-консультанты, менеджеры, продавцы

Меня зовут Михаил Завилейский. Формально я — генеральный директор DataArt. Но, на самом деле, просто один из многочисленных руководителей компании — ведь самого главного начальника у нас нет. В DataArt я отвечаю за организационное развитие. До прихода сюда 10 лет работал в IT — в основном программистом, но также немного и менеджером.

В этой статье мы поговорим о карьере. Я расскажу, что происходит с программистами, которые почему-то хотят перестать работать инженерами. Сказанное будет относиться также к тестировщикам, инженерам качества, автоматизаторам и другим смежным специалистам. Мы посмотрим, куда могут двигаться такие специалисты.

Причины перехода

Я полагаю, что причины того, что многие люди со временем меняют специализацию, — это возрастные изменения нашего мозга. Согласно разным научным исследованиям, логический интеллект у большинства с возрастом слабеет и мало у кого усиливается. Так, в современной математике и физике большая часть самых важных открытий делается в молодом возрасте, и опыт не может заменить возрастное снижение живости ума.

Опыт, тем не менее, помогает лучше угадывать, что нужно клиенту; также растет эмоциональный интеллект, развивается лучшее понимание мира и отрасли — оказывается, такие навыки могут отлично пригодиться в других областях IТ-индустрии.

Наша индустрия развивается от содержательно сложных проектов к разнообразно сложным. Почти все содержательно сложные проекты (когда ясно, что именно нужно сделать, но сделать это трудно) были реализованы в IТ-индустрии уже много раз: так, было создано много хороших бухгалтерий, банковских систем; встроенные программы работают в машинах, самолетах — всё это уже есть.

Сегодняшние же задачи характеризуются тем, что мир становится разнообразней и понять, что нужно делать, становится всё сложнее, ведь не всегда понятно, чем отличается одно от другого. Так, если вы пишете 25-й интернет-магазин в своей жизни, вам не совсем понятно, чем он должен отличаться от предыдущих 24-х. Или кто-то делает очередную социальную сеть, и важно понять, чем она должна отличаться от других, чтобы она взлетела. Таким образом, умение понимать, что нужно сделать, становится всё более важным.

И вот здесь можно совершить переход от программирования к тем специальностям, которые помогают понять, что нужно сделать.

Карьера инженера

Вот типичный карьерный путь программиста, тестировщика или другого IT-специалиста:

Итак, кто-то начинает работать с младшей позиции. На самом деле, джуниор отличается от синьора главным образом тем, что обычно получает часть компенсации своего труда не деньгами, а опытом и обучением. Таким образом, на джуниорах компании зарабатывают больше, а джуниор выбирает компанию правильно, если там может многому научиться. По сути, отличия между джуниором и синьором на 80% — в психологических качествах, и лишь на 20% — в знаниях и опыте.

Пожалуй, самый лучший совет по развитию в себе «синьорности» — всегда думать не о том, что я делаю, а о том, кто мой клиент и кого я обслуживаю. Синьор — тот, кто всё понимает и делает сам, не требует никакого присмотра, сам собой управляет и умеет себя продавать. Если с вами удобно работать, и от вас всегда получают хороший предсказуемый результат, у вас будет репутация синьора. Если вы умнее всех, но взбалмошны — останетесь гениальным джуниором.

Продуктовым компаниям приходится бороться за удержание синьоров, так как последние обладают действительно большим объёмом навыков, но устают, им надоедает заниматься одним и тем же. Сервисные же компании могут предоставить разнообразие, но на синьорах очень трудно заработать — их всегда не хватает, зарплаты всегда очень рыночные, и синьор находится в балансе с окружающей средой.

Конечно, синьору может быть интересно бесконечно долго, но, как показывает опыт, многие из них перемещаются на другие позиции:

Эксперт;

BC — business consultant (бизнес-консультант);

PM — project manager (менеджер проектов);

SM — sales manager (менеджер по продажам);

AM — account manager (аккаунт-менеджер);

OM — operations manager (операционный менеджер).

Перемещение инженеров на такие позиции происходит, как правило, естественным путём — когда в компании появляется возможность делать то, чего ты не делал раньше.

А теперь попробую рассказать, как управлять сменой своей профессии, и поделюсь наблюдениями, какие ключевые факторы определяют развитие в том или ином направлении.

Репутация, а затем квалификация

Как я себе представляю профессионала? На мой взгляд, профессионал состоит из двух частей:

  1. Квалификация — умения, опыт, навыки;
  2. Репутация — то, что о нем знают окружающие.

По моим наблюдениям, большая часть профессионалов предпочитает качать квалификацию. Они изучают новые движки, читают книги по программированию, участвуют в состязаниях программистов — в общем, повышают профессиональную квалификацию всеми возможными способами. Большинство представляют свою карьеру именно так: «Я всему научусь, окружающие увидят, как хорошо я всё делаю, и меня повысят». Но, как показывает опыт, обычно людей не слишком интересуют другие люди (разве что, другими интересуются профессиональные менеджеры, ответственные за развитие персонала). Люди обычно полагают, что всё, что происходит без их прямого вмешательства, происходит само собой. Например, если вы написали идеальный код, — ну, вам повезло, просто так получилось. И вашей заслуги в этом никто не увидит, если только вы сами не расскажете о трудностях, которые пришлось преодолеть.

Как вас видят другие — очень важно для карьерного развития. А другие воспринимают вас через свой непосредственный опыт, а не через то, что вы сами о себе знаете. Это значит, что всё время нужно заниматься самопиаром и делать это даже вперед профессионального развития.

Отсюда — первое правило развития: Репутация должна опережать квалификацию.

Проявить себя

По-настоящему мы учимся, только делая что-нибудь. А чтобы нам доверили что-нибудь делать, нам должны поверить, чтобы мы с этим справимся. У компании и у людей новые навыки появляются тогда, когда их «по ошибке» просят сделать что-нибудь такое, что они еще до этого никогда не делали. Конечно, так делать не надо (это рискованно), но иногда что-нибудь новое мы учимся делать именно так. И, если мы хотим быстро развиваться, можем эти ошибки провоцировать, чтобы нам доверили что-то сложное. Именно по такому пути зачастую происходит самое интересное карьерное развитие в компании.

Я могу это смело утверждать, потому что довольно редко, по моим наблюдениям, хорошие инженеры становятся хорошими менеджерами легко. Менеджером может стать и хороший, и плохой программист. Однако у не очень хорошего программиста будет выше мотивация перейти в менеджеры. Сейчас я забегу немного вперед и проиллюстрирую это примером пути продавца.

Итак, однажды у нас в компании появился не очень хороший коллега-программист. Я познакомился с ним, когда он вызвал команду ОС «удалить всё из текущего каталога» из сервера приложений (тогда это был ASP) — так он удалил из «system32» всё, что можно было удалить. После этого сервер продолжал работать какое-то время (файлы, которые в тот момент использовались, не удалились), но он никогда не перезагрузился бы и скоро упал, как только захотел бы сделать что-нибудь новое и загрузить какой-нибудь dll из system32.

Я уже не помню, чем закончилась эта история. Но, как бы то ни было, этот коллега продолжил развиваться в компании, но сильных технических задач ему уже не доверяли. Зато ему всегда больше всех было надо, чтобы всё было хорошо: он никогда не верил, что нельзя сделать хорошо ту или иную вещь, или что заказчик не может быть удовлетворен. Таким образом, его репутация складывалась из так называемых soft skills, социальных навыков. Мы знали, что мышление у него не слишком инженерное, но зато клиент-ориентированное, результат-ориентированное, в чем-то то перфекционистское, — при этом он отличный партнер, который помогал команде показывать лучший результат. Теперь, по прошествии 18 лет, этот человек, Алексей Миллер, сидит в Нью-Йорке, возглавляет все продажи в DataArt.

Бывает, что мы можем проявить себя гораздо лучше не в кодировании, а в чем-то другом. Это совершенно нормально — в современном IТ-мире для этого есть очень много возможностей.

Изменение мотивации

Однако на этом пути нас подстерегают некоторые ловушки. Несмотря на то, что я никогда не был очень хорошим программистом, я никогда в жизни не был счастливее от работы, чем в те времена, когда работал просто инженером. Почему? Потому что когда после долгой и трудной работы у меня всё запускалось и работало отлично, я испытывал яркое и естественное удовольствие. При этом я знал, что это сделал именно я, и сделал хорошо.

Есть чудесный цикл, поддерживающий всех профессионалов счастливыми, который я назвал «do-check-enjoy» («сделать-проверить-радоваться»). Мы что-то делаем, мы можем это проверить, и нам даже не нужно постороннее мнение — мы видим, что мы это сделали круто. Такие события, повышающие самооценку, случаются постоянно. Один из моих любимых авторов, Дэвид Майстер, писал, что самооценка у всех профессионалов исходно занижена — именно это из-за этого профессионалы несчастливы на простой работе, а постоянно стараются учиться чему-то новому, создавать для себя новые вызовы и что-то себе доказывать. Я могу сказать, что это совершенно точно относится ко мне и к большому количеству моих коллег. Цикл «do-check-enjoy» действительно дает много счастья. И чем больше ты начинаешь смещаться в сторону более сложных и коллективных ролей, тем меньше остается возможностей наслаждаться этим циклом.

У меня нет хорошего примера на этот счет из области IТ, но я могу привести отличный пример из области медицины, который приводят все врачи, когда читают лекции по деонтологии (медицинской этике). Однажды известного врача, впервые в мире сделавшего пересадку сердца и сделавшего много таких операций впоследствии, Кристиана Барнарда, спросили: «Доктор, спасли ли вы чью-либо жизнь наверняка?» Доктор Барнард ответил, что не знает, но всё-таки одну жизнь он точно уж спас. Он рассказал, как в молодости поехал лечить одного фермера, болеющего пневмонией и находящегося в тяжелом состоянии. Жена фермера не верила в благоприятный исход и хотела прибегнуть к народному средству: убить козу и завернуть фермера в ее шкуру. Однако доктор Барнард сказал, что сначала он всё же еще попытается спасти жизнь фермера средствами общепринятой медицины. В итоге доктор Барнард сумел за одну ночь спасти фермера, и, выйдя наутро из дома, проходя мимо козы, которую хотели убить, произнес: «Коза, я спас тебе жизнь!»

Этот пример показывает, как непросто быть врачом: нужно тешить себя мыслям, что ты действительно помогаешь людям, хотя обычно даже не знаешь, наверняка это или нет. А если ты инженер, точно знаешь, что такой-то код заработал в 10 раз быстрее, — и это факт. Если же ты менеджер, продавец или аналитик (а это — командная работа), увидеть результат своих действий вне взаимодействия с большим количеством людей невозможно. Если никто ничего не слил, всё получилось, все молодцы, и ты, наверное, тоже. А когда что-то пошло плохо, иногда знаешь, что это точно твоя вина.

Таким образом, потеря ощущения, что ты делаешь свою работу точно хорошо, — главный демотивирующий фактор при перемещении с роли программиста на другие позиции в IТ. Это важно понимать. Если при переходе на коллективную работу мы будем тешить себя иллюзиями, что всё, что сделано хорошо, сделано мной — будем плохими менеджерами, плохими руководителями и плохими консультантами. Вместо этого нам нужно осознавать, что мы работаем в коллективе, и это — данность. Как доктор Барнард, мы должны понимать, что мы, может быть, когда-нибудь сможем спасти жизнь козы, но не более того.

Это качественное изменение — с представлением, что мы сами себя сможем продолжать оценивать и гордиться собой, придется проститься. Другими словами, нужно распрощаться с инженерским комплексом неполноценности, который толкал нас что-то себе постоянно доказывать. Вместо этого нужно будет развивать уверенность в себе, и это — самое важное при переходе с программистской позиции на менеджерскую.

Путь эксперта

Одна из самых сладких для разработчиков возможность — стать экспертом. Роль идеального IТ-эксперта лежит где-то на пересечении трех возможных ролей:

Decision maker — тот, кто принимает решения. Эти люди берут на себя ответственность.

Узкий эксперт — тот, кто знает, как работают те или иные вещи. Или, что даже важнее, часто эксперты знают очень много про то, как вещи не работают. Ведь есть много способов делать вещи заведомо неправильно. И хороший эксперт, как минимум, должен помочь избежать заведомых ошибок. Эксперты, как правило, помогают вне ключевой компетенции той деятельности, в который вы работаете, то есть вам нужен эксперт там, где вы не разбираетесь сами. Эксперт, как и decision maker, берет на себя ответственность в значительной степени, ведь он рискует репутацией.

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

Цукерберг рекомендует:  Вакансии Чемпионат

В IТ в работе с бизнес-заказчиками нужна, в идеале, роль, которая лежит на пересечении этих трех, — и это самая сложная роль. Такого рода людей очень мало.

Например, мы разрабатываем для какой-либо компании индустриальное программное решение. В этом случае есть много областей, где клиент более компетентен, чем мы. Тогда мы должны выступать в роли консультанта, не грузить клиента лишними переживаниями, а способствовать процессу принятия решения — это во многом социальная роль.

В более технической же области, где вы компетентны более, чем заказчик, взять на себя ответственность и принять решение должны именно вы. То есть вы должны выступить в роли эксперта. Если же вы предоставите заказчику набор возможных вариантов и посоветуете ему принимать решение самому, в случае незрелого клиента, это будет манипуляцией, потому что он будет выбирать между вариантами, отличия которых ему самому не очень понятны. В итоге он окажется ответственным за непонятный ему самому выбор. Зрелый же клиент просто откажется так работать.

Если же ситуация предполагает большое количество людей, важно помочь правильно определить границы ответственности, и это — самое трудное. Сейчас самые развитые компании, работающие в IТ, стараются перейти от продажи часов и усилий к продаже решений. Связано это с тем, что мы никогда не произведем столько же часов, сколько производится в Индии или Китае, ведь часы работы, которые стоят в 5 — 10 раз дороже, чем те же часы в Азии, продать очень трудно. Поэтому все компании хотят, чтобы цена формировалась в зависимости от ценности услуги для клиента, а не количества потраченных часов. И здесь, конечно, границы ответственности, о которой нужно договориться заказчику и исполнителю заказа, — большой вопрос. Умение нащупывать эту границу — высший уровень в бизнесе и управлении.

Теперь еще пара комментариев, кто такой эксперт. Есть неправильное понимание эксперта — когда считают, что эксперт — это просто тот, кто самый умный или просто что-то лучше знает. Но это не всегда так. Чтобы быть экспертом, нужно знать очень много в какой-то узкой области.

Также важно, что эксперт — не соревновательная роль. Эксперт — не тот, кто самый упрямый, не тот, кто всех всегда переспорит (хотя такой человек и может сделать себе репутацию эксперта, но такие люди играют разрушительную для компании роль). Эксперт — тот, кто опытен, уверен, но, несмотря на это, остается восприимчивым, может быстро менять своё мнение, если узнает, что он неправ.

Наконец, эксперт должен быть позитивен — не в том смысле, конечно, что он всегда улыбается. Позитивный человек в данном случае — тот, кто дает конструктивные формулировки, видит положительные возможности, а не только проблемы и трудности.

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

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

Путь менеджера проектов

Роль менеджера проектов — самая естественная для бывших программистов. К ней иногда приходят через промежуточную роль лидера команды. Менеджер проектов должен уметь огромное количество вещей. Картинка, которую я нашел в интернете, описывает необходимые навыки менеджера проектов:


Однако самое главное среди этих слов я не наше. Чем отличается управление проектами от любого другого менеджмента? Тем, что проект однажды заканчивается, у него есть конечная цель. Поэтому основная роль менеджера проектов — добиться конечной цели проекта. Конечная же цель проекта — получить одобрение заказчика, попасть в его ожидания.

Поэтому управление ожиданиями — самая главная функция менеджера проектов, в отличие от остальных менеджеров в сфере IТ.

Таким образом, менеджер проектов всегда думает о конце проекта, о том, попадет ли он в ожидание. Ожиданиями нужно управлять, двигать их, потому что редко ожидания, что были в начале проекта, останутся такими же и к концу проекта. Ведь откуда появились гибкие методы разработки? Когда проекты длятся много месяцев, в современном мире за это время всё меняется. Соответственно, меняются и ожидания. Работа современного менеджера проекта — гонка за движущейся целью.

Менеджер проектов это не тот, кто нарисовал план и строго ему следует, а талантливый человек, который понимает, что ожидаемый результат подвижен, будучи зависим от разных факторов, и в соответствии с этим постоянно вносит изменения в план и управляет ресурсами, стараясь попасть в цель на пересечении многих изменчивых факторов. Менеджер проектов — не тот, кто просто управляет подчиненными (хотя сейчас идеальная команда — team of peers, команда равных, где нет явных начальников), а тот, кто влияет на огромное количество людей вокруг и на их представления, что нужно делать, — так, чтобы они сошлись в одной точке и остались довольны друг другом. Это — самое важное.

Если мы строим дом и постоянно меняем требования, дом получится странным и дело, скорее всего, добром не кончится. Если мы работаем с материальным миром, мы должны держать план более или менее устойчивым. В разработке же ПО у нас есть достаточно много свободы, и очень редко получается, чтобы длительный проект оставался стабильным. Чаще всего это — постоянный поток возможностей что-то изменить.

Например, я, когда был менеджером проектов, всегда начинал с того, что проверял степень свободы, — старался выяснить, что могу поменять. Для этого старался немного поменять план проекта, спросить об изменениях в бюджете, чуть-чуть подвигать сроки, чтобы просто посмотреть, как на это реагируют клиент и все остальные. Это позволяло быть готовым к тому, чтобы действительно что-то поменять, когда изменения нужно будет внести. Если это становится нормой, можно сохранять хорошие отношения в ходе проекта и легко вносить нужные изменения.

Если же клиент воспринимает любые изменения в штыки, нужно быть устойчивым и обстоятельным по отношению к любым просьбам об изменении объема проекта. Если идти на поводу у таких просьб, всё для этого проекта может закончиться плачевно. Например, в гибкой методологии разработки один из главных принципов — «fail early», согласно которому неуспех должен случиться как можно раньше. В общении с клиентами из бизнес-культуры очень важно как можно быстрее проверить все возможные засады, которые могут привести к разрушению отношений.

Для менеджеров проектов понимание, что они влияют на огромное количество людей вокруг и занимаются широкой координацией, а не управлением и защитой изначального плана, — главный вызов сегодняшней индустрии. Ведь многие ребята, которые пытаются стать менеджерами проектов, полагают, что хороший план проекта, хорошие оценки затрат, правильные процедуры защитят их от неопределенности окружающего мира. Нет, не защитят. Вместо этого мы должны учиться извлекать из неопределенности достаточное количество преимуществ, чтобы они компенсировали случающиеся у нас проблемы.

Путь продавца

Это — самый трудный путь и, по моим наблюдениям, самый непопулярный среди бывших программистов. Во-первых, это связано с тем, что продавец не обязан быть компетентным в инженерном деле, и поэтому продавцы часто приходят с других позиций и мест. Во-вторых, у инженера, в отличие от продавца, эффективность труда намного выше. Хороший инженер не может себе позволить допускать большой процент брака, на мой взгляд, у хорошего инженера более 90 % работы выполняется очень успешно. У продавца же производительность труда намного меньше: при большом количестве потенциальных покупателей лишь немногие что-то у вас покупают. В норме подписывают контракт менее 10 % контактов, попавших в поле зрения продавца. Поэтому инженеру обычно психологически очень трудно перейти в продажи, не насмотревшись на процесс продаж и не привыкнув.

Поэтому в роли продавца, как нигде, чрезвычайно важна ни на чем не основанная крепкая уверенность в себе и вера, что то, что ты делаешь, — правильно. Другими словами, важно, чтобы самооценка продавца не слишком зависела от успехов и неудач, да и вообще от чего-либо определенного — ведь самооценку, зависящую от чего-либо, всегда можно чем-либо подорвать. Для всех менеджерских ролей, и особенно для роли продавца, очень важен принцип доктора Хауса, который не всегда прав, но всегда уверен в себе, потому что по-другому ему трудно работать.

Так что перед тем как перейти на позицию продавца, очень важно запастись уверенностью в себе — тем более, чтобы понять, насколько вы хороший продавец, понадобится не менее двух лет (тогда как синьор в одной технологии может стать пусть не самым лучшим, но всё же синьором в другой технологии всего за три-шесть месяцев).

Путь аккаунт-менеджера

Есть огромное количество вещей, которые происходят в аккаунт-менеджменте. Это передний рубеж, на которым узнают, что нужно сделать, чтобы заработать денег. Аккаунт-менеджмент связан, в первую очередь, не с развитием каких-то навыков и умений, а с тем, как вы думаете, как используете воображение.

Классическая инженерная команда держит в фокусе внимания программное решение, которое она разрабатывает. Команда же аккаунт-менеджеров стремится развить индустриальное понимание. Если, например, мы имеем дело с разработкой банковской системы, она должна обладать такой-то производительностью, такой-то надежностью, должна быть совместима с такими-то протоколами — иначе она не взлетит. Индустриальное знание помогает понимать, как это обычно работает и чего от нас ждут. Обычно от нас ждут какой-то функциональности и помощи конкретному бизнесу в конкретной индустрии, ждут решения типичных бизнес-задач, которые были сформулированы и описаны в спецификациях, а не идеального кода в больших объёмах.

Самое крутое — бизнес-мышление, которое позволяет думать вместе с клиентом или даже без клиента, как сделать хорошо. Бизнес-мышление позволяет делать внешние и внутренние стартапы, получать бюджеты там, где их не было, позволяет убедить клиента сделать что-то большое и новое и рискнуть чем-то. Часто говорят, что бизнес-мышление присуще людям, которые в конце видят деньги и понимают, как до них дойти. В каком-то смысле это верно, но в современном мире денег всё больше, но в то же время всё больше и страхов отсутствия взаимопонимания. Поэтому те, кто работает в аккаунт-менеджменте на высшем уровне, производят смыслы: задаются вопросом «а какой смысл делать такой-то проект?». Если привести аргументацию, что смысл в этом есть, все делают этот проект.

Умение находить и создавать смыслы — главный атрибут бизнес-мышления. Если вы хотите убедить человека что-то делать, попробуйте рассказать ему, в чем смысл. Если люди понимают, что вы предлагаете, и соглашаются с этим, видят в этом смысл, вы производите смыслы и можете двигаться к высотам аккаунт-менеджмента. А большинство старается выяснить смысл, думая, что он есть у кого-то в голове. Это чуть ниже бизнес-мышления — индустриальный уровень.

Путь операционного менеджера

Наконец, меньшинство из коллег становятся руководителями компании — операционными менеджерами. Как говорил мой преподаватель с физфака, «мы производим большое количество обученных физике людей и воспроизводим небольшое количество себе подобных, которые двигают науку вперед». Руководители, менеджеры компании тоже этим занимаются. Они производят большое количество инженеров (это похоже на обучение и развитие), и определенное количество попадает на операционные должности.

На операционных должностях важно понимать, какова культура компании и чего от вас ждут. В очень простой классификации, все операционные менеджеры, на мой взгляд, делятся на три категории: хозяева, начальники и сервисы.

Хозяин — тот, кто упрощает жизнь остальным менеджерам и бизнесменам компании. Он закрывает свою зону ответственности, он — главная и часто единственная точка контакта. С ним можно договориться, и на него можно положиться — всё просто и хорошо. Это не всегда эффективно, так как хозяин зачастую не желает выносить сор из избы, не использует оптимально все ресурсы компании, плохо взаимодействует с другими функциями, но зато упрощает жизнь других менеджеров компании.

Начальник — классическое иерархическое лицо, указания которого выполняешь, а затем отсылаешь ему отчёты о проделанной работе. Иерархии в нашей жизни работают, и ничего плохого в этом нет. Но, к сожалению, с начальником, чаще всего, возникает деструктивная игра — если мы делаем всё хорошо, у нас возникает представление: «Это именно я всё делаю, а он только командует». Если мы сделали что-то плохо, думаем: «Я-то делаю всё хорошо, просто это он дурацкие указания дает».

В психологическом смысле начальник нам полезен — мы присваиваем заслуге себе, а ответственность за неудачи переносим на него. Элементы этой психологической игры я вокруг встречаю постоянно. Многие даже стараются найти начальников вокруг себя. Я и на себе ощущаю это давление — от тебя ждут, что ты включишься в эту игру. Включаться или не включаться — выбор каждого, так как каждому удобно работать по своей модели.

Сервис — это менеджер, который просто помогает сотрудникам делать их работу. Я считаю, что в IТ для многих продвинутых компаний сервисная модель — самая привлекательная. Согласно этой модели, на компанию, занимающуюся разработкой заказного ПО, можно смотреть как на компанию, которая сводит инженеров с потребителями их работы, и обслуживает весь этот процесс. Поэтому всё, включая управление капиталом, корпоративное управление, кадровое управление, финансы и т. д. — просто сервисы, которые обеспечивают сотрудникам рабочий процесс. Это, конечно, радикальная модель, но мне она нравится — при ней ты не делаешь ничего лишнего, пока тебя не попросили.

Но, конечно, на самом деле всё не так просто: нужно всё же объяснять людям, что можно попросить и зачем, убеждать людей пользоваться сервисами, иначе ничего работать не будет. Мне кажется, что сервисный взгляд на корпоративные функции выглядит перспективным и интересным, хотя и имеет свои издержки — всем нравится, когда нас обслуживают, и, если совсем впасть в сервисную моду, есть опасность, что все будут пытаться сесть друг другу на шею. Поэтому к вопросу нужно подойти цивилизованно — научить людей «правильно» пользоваться сервисами, что важнее всего в реализации сервисного подхода.

В любой компании все вышеупомянутые функции могут сочетаться, разные люди будут ближе к той или иной роли, но, если вы движетесь к руководящей позиции, такая классификация поможет вам разобраться с точки зрения самоидентификации, где вам удобнее. Если вам неудобно командовать, вы вышли из управления проектами, где использовали влияние на окружающих, вам подойдёт сервисная модель. Если же вам хочется вернуть себе радость от мысли, что именно я сделал то или иное хорошо, быть вам хозяином. А начальником вы и так станете, если не будете делать ничего особенного: ведь выстраивание иерархий — самое естественное поведение в корпоративном мире, которое складывается само собой.

«Там, где ты не крутой — не заработаешь». Как построить карьеру в IT

Сооснователь Alef Development

Программистами не рождаются, ими становятся. Это не совсем профессия, а скорее навык, который можно прокачать. Сооснователь IT-студии Alef Development Стас Гольденшлюгер рассказал, кому противопоказано идти в эту сферу, и разобрал варианты карьерного пути от молодого специалиста до профессионала.

А я точно хочу в IT?

Если у тебя возник такой вопрос, то нет, ты не хочешь в IT. Вот так просто. Вероятно, ты решил, что IT — перспективная сфера, где водятся деньги, и собрался их заработать. К сожалению, ты опоздал лет на 20.

Когда мне было 10 лет и я увлекся программированием, мои родители не были этому рады. В то время бытовало мнение, что нужно идти в экономисты: их сметали на рынке труда и они много зарабатывали. Папы и мамы отдавали детей учиться на финансы или банковское дело. Спустя 10 лет в стране было полно экономистов, а спрос сохранился на том же уровне. Раньше на 2000 вакансий приходилось 1000 специалистов, а теперь на 3000 вакансий метили 100 000 человек. Зарплаты упали до $500, а большая часть «востребованных» финансистов и банкиров так и не смогли найти работу по специальности.

Гнаться за модой точно бесполезно — не угонишься. Лучше займись тем, что нравится. Только в любимом деле ты сможешь стать крутым.

Там, где ты не крутой — не заработаешь. Да, сейчас программисты получают хорошие деньги, но не факт, что такое положение сохранится через 10 лет. Скорее всего, рынок уже будет переполнен. Да, на высоких должностях сохранятся космические зарплаты, но конкуренция возрастет в разы.

Хочешь писать на темы предпринимательства, образования и технологий? Стать автором Rusbase Young может каждый. Узнать как

Люди, которые любят программирование, не то чтобы прямо решали становиться программистами. Я, например, никогда не думал, что это будет какой-то профессией, и в детстве рассуждал так: «Мне посмотреть мультики или попрогать? Пойду попрогаю, это интереснее». Среди моих знакомых все профессионалы выросли примерно таким же образом.

Как собрать портфолио и найти клиентов

Одним словом — мучительно. Двумя словами — мучительно и долго. Пока у тебя нет портфолио, скорее всего, нет и опыта. Значит, никто не будет доверять тебе проекты. А если и доверят, то ты их, вероятно, провалишь.

Самый первый, даже нулевой этап, — делать какие-то программы для себя. Придумай простенькую игрушку и выложи ее в App Store. Может быть, она даже принесет тебе пару тысяч долларов, но это не главное.

Если она не будет глючить и вылетать, то ты сможешь показывать ее потенциальным клиентам. Говорить при этом нужно следующее: «Смотрите, я молодой, но очень крутой, и я могу доказать, что я крутой. Вот я сделал игру. Правда, у меня нет портфолио, поэтому я согласен работать дешево. Вам конкретно повезло».

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

Какие варианты развития карьеры есть

Самый очевидный — устроиться на работу в большую фирму. Например, Google буквально сметает всех подряд в поисках стажеров. Если ты способен прокачивать навыки на примере более опытных коллег и чтить корпоративную культуру, то будешь расти внутри компании. Но со мной не все согласятся. HR-tech предприниматель Арина Егорова считает, что пойти в огромную корпорацию типа Google — худшее, что может сделать специалист в начале своего карьерного пути. «Представь, ты попадаешь в подразделение, которое отвечает за Google Поиск. Твоей задачей будет увеличить точность выдачи информации на 0,00000001. Можно похоронить свой талант прогера на такой работе, а заодно и умение мыслить широко и объемно», — говорит она. Лучшим путем для старта Арина называет средний бизнес ($50-200 млн по западным меркам) с небольшой командой и задачами адекватного уровня сложности.

Другая история — пойти в малый или средний бизнес. Там есть свои плюсы и свои минусы. С одной стороны, у тебя больше свободы и пространства для роста. Нет умных старших товарищей, которые все знают, все умеют и разрешают тебе закручивать одну гаечку. Все гораздо интереснее: ты один в поле воин, который должен сделать «космолет», и никто тебе не поможет. Такая работа даст тебе колоссальный опыт, при условии что ты способен учиться на своих же ошибках.

Следующий вариант самый экстремальный — фриланс. Он собрал все минусы: здесь и недопонимание в общении с клиентами, и постоянная нервотрепка из-за количества заказчиков, которых то много, то мало, и ненормированный рабочий график. Зато есть один существенный плюс. Потенциально именно из фрилансера можно вырасти в предпринимателя: ты постепенно обзаведешься клиентской базой, наймешь первого, второго помощника. Брать и сразу делать девелоперскую компанию я не советую никому. Без клиентов и опыта в специфических вещах вроде написания ТЗ, тестирования, утверждения дизайна получится, что ты просто спустишь деньги в никуда.

Взять кредит на 20 млн рублей и организовать фирму — самая плохая идея, которая может у вас возникнуть.

Заключительный и очевидный вариант — стать стартапером. Придумать классный сервис, поехать в Кремниевую долину, получить миллион долларов инвестиций, потратить миллион долларов инвестиций. Я не знаком с людьми, которые бы таким образом разбогатели. Инвестиции, которые ты получаешь, идут не тебе, а в компанию, и тратить их можно только специфическим образом. Велика вероятность, что идея не взлетит и ты просто потратишь год или несколько лет жизни впустую. Стартаперский путь подходит людям, готовым к лотерее: может получится, а может и нет. Для меня это слишком рисковая история.

Есть также менее тривиальные варианты развития карьеры. Самые большие деньги, как известно, обитают на стыке разных профессий. Отец моего друга увлекался программированием и при этом имел медицинское образование. Он не был лучшим программистом или лучшим врачом, но разбирался в обеих сферах. В итоге он собрал команду и стал делать прошивки для аппаратов МРТ. Этот бизнес сделал его очень богатым. И таких необычных комбинаций профессий масса, на стыке разных индустрий всегда можно найти свободную денежную нишу.

Какие ошибки могут разрушить карьеру программиста

Если ты работаешь управляющим в банке и совершаешь ошибку — тебя увольняют и ты лишаешься репутации. В IT по-другому: здесь нет репутации, зато есть навыки.

Если программист сделал работу плохо, то ему заплатят меньше или просто не порекомендуют друзьям.

Может быть, уволят, и тогда он пойдет в другую компанию на такую же должность. Если программист круто справился со своей работой, то к нему придут новые клиенты, а в случае работы по найму — его повысят или перекупят в другую фирму. Получается, что ошибок, которые могут разрушить карьеру программиста, — нет. Есть ошибки, которые не дают толчок к росту.

«Если код написан безалаберно, бесполезно лезть в бутылку и пытаться убедить работодателя в обратном, – считает Арина Егорова. – Человек видит результат вашей работы, он его не устраивает. Окей, значит нужно дать другое решение, посмотреть шире».

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

Материалы по теме:

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Накодить миллион. Программисты догоняют инвестбанкиров по уровню зарплат

Хотите зарабатывать «миллион долларов США»? Тогда срочно начинайте учить какой-нибудь язык программирования. Не верите, что программисты получают такие деньги? $983 000 — именно эта цифра, по данным сервиса Paysa.com, значится в графе максимальный годовой доход на позиции principal software development engineer в штаб-квартире Amazon в американском Сиэтле (средний размер — $470 000). Совсем недавно такие доходы получали, пожалуй, только лишь на Wall Street. Что ж, пора констатировать: времена изменились. Программисты — это новые инвестбанкиры. И так думаю не только я.

Технологии правят миром. А технологические компании и их CEO — новые рок-звезды, быть причастным к которым хотят все больше молодых профессионалов. По данным Стэнфордской бизнес-школы, в технологические компании отправилось работать 33% выпускников MBA 2015-2020 годов, хотя еще в 2010-2011 годах этим компаниям удалось привлечь лишь 13% выпускников. Доля финансовой отрасли за этот период снизилась — с 36% до 31% для класса 2015-2020 годов. В MIT Sloan School Amazon — второй по значимости наниматель выпускников MBA (23 человека из потока в 406 человек), он уступает только традиционной McKinsey & Company (26 человек). Кроме них, Bain&Company и Boston Consulting Group в пятерку лидеров входит также Google. В отрасль software/internet отправилось работать 23,9% выпускников MIT Sloan School против 4,7% в инвестбанкинге. Средняя базовая годовая зарплата первых — $120 000, что на $5000 меньше, чем у банкиров, но зато максимальная зарплата — $165 000 против $150 000. В этих цифрах не учитываются пакеты акций технологических компаний, которые они обычно предлагают сотрудникам в составе компенсационного пакета (на несколько десятков тысяч долларов или 50-100% базовой зарплаты), а ведь они могут еще и неплохо вырасти по прошествии нескольких лет, отмечает Михаил Наринский, старший технологический консультант нью-йоркского офиса Google (выпускник MBA MIT Sloan).

Вакансия software engineer, пожалуй, самая востребованная на данный момент в США. По данным портала Indeed.com, сейчас в стране открыто свыше 200 000 таких позиций. Колледжи в спешном порядке разворачивают бакалавриат по специальности computer science. А Microsoft, например, регулярно проводит четырехмесячные оплачиваемые (из расчета $100 000 в год) учебные лагеря (boot camp), успешных выпускников которых принимает на работу. Профессия software developer занимает 13-е место в топ-25 лучших работ в США 2020 года в рейтинге U.S. News. По его данным, в этой сфере всего 2% безработных, средняя зарплата составляет $98 260, а количество открытых вакансий — 135 300.

«Инвестбанковская отрасль становится все менее привлекательной, а технологическая — с каждым годом расширяется, открывается все больше возможностей для карьерного роста и решения новых глобальных задач», — рассуждает Альберт Маликов, который променял успешную карьеру в российском офисе инвестбанка UBS на работу в финтех-команде голландского офиса Uber (получив перед этим MBA в MIT Sloan). По его словам, все больше банкиров переходят на работу в технологии, где они видят потенциал роста, возможность принести пользу обществу и применить свои лидерские навыки, что сложнее сделать в устоявшейся финансовой индустрии.

Финансовая индустрия сейчас и сама проходит технологическую революцию, открытых позиций становится все меньше, поэтому навыки программирования точно помогут выделиться среди конкурентов, особенно в тех фондах, что практикуют quantitiative research, считает Денис Толкачев, инвестиционный аналитик американской инвестгруппы Capital Group. На Wall Street, ввиду нескольких факторов (ужесточение регулирования, технологические инновации, большой наплыв таланта в начале 2000-х), очень сильно изменилась динамика спроса и предложения на профессионалов. Спрос упал, а предложение только после 2009 года начало медленно, но верно понижаться. Это привело к снижению оплаты труда, рассуждает Толкачев.

У программистов же возможностей стало намного больше: спрос постоянно растет в связи с структурными изменениями практически во всех индустриях (ритейл, банки идут в online), везде автоматизация, которая требует программирования. Например, в сегодняшнем автомобиле Ford GT 10 миллионов строчек программного кода — в пять раз больше, чем в боевом самолете Lockheed Martin F-22 Raptor 2005 года выпуска. Но специалистов по-прежнему не хватает, приходится рассчитывать на иммигрантов, пример тому — полнейший интернационал в Сан-Франциско и Кремниевой долине, отмечает Толкачев.

При этом, в программировании существует (возможно, пока что) довольно-таки средний по сравнению с Wall Street «потолок» зарплат/бонусов. И upside у программистов — это работать на будущий Facebook, Instagram или создавать своего «единорога». Но таких, кто объединяет в себе навыки программирования, бизнес-чутье и способность к управлению людьми, — единицы, и именно они сегодняшние рок-звезды в бизнес-мире, считает Толкачев.

Зарплаты программистов пока, конечно, не сопоставимы с инвестбанковскими (разве что в Америке и на топовых должностях), но в целом движение идет в этом направлении, согласен Сергей Булатов, директор английской рекрутинговой компании Regency Advisers. Зарплаты даже в $1 млн еще сравнительно редки, но по мере роста важности технологий в той же банковской отрасли, будут расти и заработки топовых программистов. «В каком-то смысле мы наблюдаем разнонаправленное движение доходов «финтеховцев» и инвестбанкиров, этот процесс начался не вчера и завершится не сегодня, но он идет все более явно — важность человеческого фактора падает, технологий — растет, увеличивается и value ее создателей», — отмечает Булатов. Конечно, банкиру еще не надо уметь кодить, но многие финтеховцы — финансисты только на 30%, а на 70% — уже программисты, и эта тенденция будет нарастать. В то же время, в банковской отрасли доходы после кризиса 2008 года в мире снизились на 30-50%, а в России упали в два-три раза, резюмирует Булатов.

Продвинутые девушки уже давно обратили внимание на технологические кадры — чего стоит недавний брак топ-модели Миранды Керр и CEO Snapchat Эвана Шпигеля, или союз теннисистки Серены Уильямс с сооснователем Reddit Алексисом Оганяном. Как сообщали американские СМИ, последний преподнес прославленной спортсменке помолвочное кольцо с 10-каратным бриллиантом за $2 млн.

Думаю, немало «охотниц за капиталами» следят и за аккаунтами основателя «ВКонтакте» и Telegram Павла Дурова, где то и дело появляются атрибуты его красивой жизни — вояж на частном самолете из Санкт-Петербурга в Венецию или чекин в парижском Ritz. «Почему-то мне кажется, что программисты должны быть менее «транзакционны» в отношениях с девушками, чем инвестбанкиры, у последних — профессиональная деформация», — комментирует в Facebook топ-менеджер Тинькофф Банк Георгий Чесаков.

Но кодинг — это тоже не гарантия бутерброда с икрой, предупреждает известный хедхантер Алена Владимирская в своем Facebook. Учитесь кодить только в приличных местах, работайте в самых передовых или восстребованых «стеках», имейте в багаже два активных языка, учитесь работать с открытым кодом и понимайте экономику, маркетинг, учет и управление людьми, советует она: «Тогда в вашей кодерской жизни будет хорошо долго».

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих