Всем привет! Меня зовут Вероника, я фронтенд‑разработчик направления зарплатных проектов в Альфа‑Банке. До этого 4 года разрабатывала корпоративные веб‑приложения и участвовала в запуске стартапа, где ты человек‑оркестр и выполняешь несколько ролей сразу.

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

Карьерные стратегии

Разделю их условно на два направления, что активно обсуждаются в айтишной тусовке:

Хайповое: поднимать свою зарплату раз в год через собеседования и переход на новое место работы (а потом и брать 2 работы, когда зарплатный потолок достигнут).

Консевративное: развиваться внутри одной компании, повышать свою экспертизу, грейд и зарплату.

Моя личная стратегия где‑то посередине: найти место, которое будет нравиться по совокупности признаков, и вложиться в развитие там.

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

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

Ситуация 1. Матрица судьбы или матрица задач?

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

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

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

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

Как я работаю с приоритизацией задач

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

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

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

1. Маленькие команды разработки, есть Product Owner. Это помогает не размывать цели и синхронизироваться с участниками. На моей первой работе был один PO на 40 человек, мы разговаривала один на один всего дважды и совсем не о целях продукта.

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

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

Ситуация 2. Крутить метрики vs делать фичи

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

На моей первой работе оплата труда разработчика рассчитывалась по сложной формуле, в основе которой лежало количество задач, их сложность и затраченное время. На первой неделе ребята с опытом рассказали, что выгоднее делать много фиксов багов, чем какую‑то среднюю задачку на 5-6 часов. Знатоки системы делали как: первую неделю спринта только этим и занимались, а уже после приступали к своей основной цели. Самое забавное, что эффект от незакрытого на 100% спринта нивелировался этим багомарофоном.

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

Тут можно было бы сказать, что история, конечно, забавная, но мне‑то как разработчику какое дело: задачи сделаны, деньги получены. Но не всё так однозначно.

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

Ситуация 3. Гостинг и многоработничество

Называйте как хотите: многоработничество, overemployed (как пишут на Реддите) или сверхзанятость (локализованная версия термина). Суть одна.

Третья ситуация связана с основной темой по касательной, и я сразу обозначу:

• Речь пойдёт, скорее, о двух полноценных фултайм‑работах, не о разовой проектной деятельности.

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

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

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

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

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

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

А что в итоге?

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

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

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

Пока для себя я понимаю «думать с позиции бизнеса» и не забывать о себе так:

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

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

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

• Провожу реалити‑чек рынка: не засиделась ли я, может, уже есть места и получше.

Пишите в комментариях, что для вас «думать с позиции бизнеса» и как с этим складывается на практике? Есть ли у вас лайфхаки, как развивать мотивацию к работе в ИТ и расти по карьере и в зарплате?