Привет! Меня зовут Александр Ларьяновский, я управляющий партнер Skyeng и онлайн-университета рентабельного образования Skypro. Под катом расскажу о том, как проактивность и погружение в мир бизнеса влияют на профессиональную жизнь разработчиков.

Удивительно, но за жизнь люди тратят больше времени на выбор пиццы или фильма на вечер, чем на то, какое карьерное решение им лучше принять. 

При этом от карьеры в сегодняшнем мире зависит всё: что вы едите, где учатся ваши дети, чем лечатся ваши родители, в каком районе вы живете.

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

Это кажется большим благом: вы всегда найдете работу, вас будут всячески удерживать, вокруг всё так динамично меняется…

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

И в какой-то момент вы обнаружите себя гребцом на галере. Всё то же самое: вы всегда найдете работу, пока не сломаетесь, вас будут удерживать, и мир вокруг будет динамично меняться, только вы… каждый день делаете одно и то же.

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

В итоге когда разработчик просто молча пилит фичи и фиксит баги, он часто упирается в стеклянный потолок. Задачи есть, но все однотипные. Зарплату индексируют, но существенно не поднимают. Скилл не растет, удовольствия от работы всё меньше. 

Работа на веслах самая стабильная — и никогда не закончится.

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

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

Но поговорим о хорошем. 

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

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

Когда разработчик понимает язык и задачи заказчика, работа над проектом становится для него более справедливой.

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

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

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

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

Фулстечность в сторону бизнеса

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

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

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

Дать самую челленджовую, самую интересную задачу другим — как играть в русскую рулетку, то есть иногда даже повезет.  А вот поручить Андрею — надежное решение.

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

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

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

Он лучше понимает, для чего пишет код, может предложить свое решение или указать слабые места в задании. Может скорректировать вектор и выбирать (создавать) интересные для себя задачи. 

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

Хорошие работодатели ценят разработчиков, которые выходят в надсистему и задают вопрос «А почему нужно делать именно эти задачи?».

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

Фулстечность в осознанность

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

Чтобы расти, нужна заинтересованность: какую потребность бизнеса решает эта фича или продукт?

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

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

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

Разработчик не поленился, сходил к руководителям бойцов, которые работают с CRM, и выяснил, что 95% операторов знают базовый английский, а научить остальных 50 необходимым словам — задача простая. В результате мы просто поменяли язык на английский и не стали включать многоязычность, сохранив себе лишний миллион рублей. 

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

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

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

Однажды сервис Skipp для задачи в Skyeng подключил сеньор-разработчика. Он отметился тем, что очень дотошно общался на техревью. Ему важно было разобраться, как устроен проект с точки зрения бизнеса, как бизнес будет на этом зарабатывать.

Казалось бы, ему нужно было просто допилить CMS-систему, но он не приступал к задаче, пока не разобрался, на что именно она будет влиять. Зато в итоге он отлично понимал, что и зачем он делает: у него выросла мотивация и вовлеченность, задача стала не рядовой, а интересной. Важно, что он не боялся задавать вопросы и выглядеть несведущим.

От микроменеджмента к автономности

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

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

Чтобы повышать автономность, заинтересованные разработчики сами идут на контакт: активно запрашивают обратную связь, показывают промежуточный продукт, спрашивают, всё ли с ним в порядке. Тот же Андрей из нашей компании не боится интересоваться, в нужную ли сторону он идет.

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

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

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

В практике Skipp был пример с итальянской платформой для инициатив по КСО. Заказчик сначала самостоятельно и во всех деталях описывал даже самые мелкие задачи: например, как должны работать поля во всех формах. 

Проблема была в том, что он сам он не был разработчиком и часто просил сделать что-то нетипичное. Команда шла на поводу, но результат получался так себе: всё постоянно падало и ломалось.

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

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

Если коротко, то есть такой любимый многими профессионалами анекдот.

«Делаю все сам = 100$

Ты смотришь, я делаю = 200$

Ты говоришь, я делаю = 300$

Я говорю, ты делаешь все сам = 1000$»

Почему так? Потому что микроменеджмент отнимает столько сил и нервов, что никакие дополнительные деньги не нужны. 

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

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

Сравните две задачи.

1. Сделать модуль для системы бухгалтерского учета.

2. Высвободить десятки ночных часов у бухгалтеров. Раньше они тратили это время на бесконечные отчеты, теперь могут посвятить его себе и детям.

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

Но сложно гордиться тем, чего не понимаешь.

В заключение

Вы все прокачиваете свои хард-скиллы с точки зрения разработки. Новые языки, новые фреймворки. Но переход в следующую когорту дает совсем другой хард-скилл — понимание основ бизнеса.

Вы знаете, как функционирует бизнес? Как устроена вся цепочка продукта — от идеи до продажи?

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

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

Итак: для роста дохода вам нужно понимать, как работает бизнес. 

Где и как этому учиться? Самый быстрый и простой способ — нормальные курсы по продакт-менеджменту. Это позволит вам научиться понимать человека, который вам ставит задачи. Что именно он имел в виду, что он хочет получить в результате. 

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

Ну или просто оставаться гребцом.

Видео моего выступления с конференции вы можете посмотреть здесь.

Следующая тимлидская конференция пройдёт этой осенью – 16 и 17 сентября в Санкт-Петербурге. Рекомендую.