Привет! Меня зовут Александр Ларьяновский, я управляющий партнер Skyeng и онлайн-университета рентабельного образования Skypro. Под катом расскажу о том, как проактивность и погружение в мир бизнеса влияют на профессиональную жизнь разработчиков.
Удивительно, но за жизнь люди тратят больше времени на выбор ��иццы или фильма на вечер, чем на то, какое карьерное решение им лучше принять.
При этом от карьеры в сегодняшнем мире зависит всё: что вы едите, где учатся ваши дети, чем лечатся ваши родители, в каком районе вы живете.
Для айтишников ситуация усугубляется тем, что дефицит кадров многим помогает просто плыть по течению, не задумываясь о том, какой вектор направления для себя выбрать.
Это кажется большим благом: вы всегда найдете работу, вас будут всячески удерживать, вокруг всё так динамично меняется…
Но есть и большой минус: так плыть по течению очень легко. Вам просто не надо думать над карьерой, всё складывается само.
И в какой-то момент вы обнаружите себя гребцом на галере. Всё то же самое: вы всегда найдете работу, пока не сломаетесь, вас будут удерживать, и мир вокруг будет динамично меняться, только вы… каждый день делаете одно и то же.
Многие разработчики думают, что их работа сводится к тому, чтобы приходить на стендапы и брать задачки из таск-трекера. Им кажется, что нужно просто писать красивый код (или больше кода), а карьерный рост, бонусы и премии к этому приложатся автоматически.
В итоге когда разработчик просто молча пилит фичи и фиксит баги, он часто упирается в стеклянный потолок. Задачи есть, но все однотипные. Зарплату индексируют, но существенно не поднимают. Скилл не растет, удовольствия от работы всё меньше.
Работа на веслах самая стабильная — и никогда не закончится.
Кажется, все понимают, что быть лучшим гребцом — это не путь из трюма на верхнюю палубу. Но… продолжают ходить по всё тому же замкнутому кругу: больше кода, лучше код. Совершенствовать греблю.
Это закономерный исход, когда специалист не интересуется ничем, кроме собственной текущей задачи. Он не думает, откуда она пришла, почему в таком виде, что она изменит. В итоге не понимает контекста, в котором работает, и не может на него влиять.
Но поговорим о хорошем.
Возможность перехода в другую когорту существует, можно зарабатывать ощутимо больше и больше удовольствия получать от работы.
Тут я хочу сделать одну важную оговорку: я не считаю, что все хотят роста, не для всех карьера — важная часть жизни. Я говорю о тех и для тех, кто недоволен своей карьерой и хочет что-то поменять, но не знает как.
Когда разработчик понимает язык и задачи заказчика, работа над проектом становится для него более справедливой.
Во-первых, у него появляется рычаг влияния, чтобы проекты не застревали и доводились до конца. Это особенно актуально в аутсорсе, когда проект может сорваться в любой момент. Если разработчик просто пишет код, то он полностью во власти изменений. Но если он погружается в задачу и ведет активный диалог с заказчиком, то может помочь решить проблему, найти новое решение. И в итоге довести проект до конца, а не положить месяцы работы в стол.
Во-вторых, он лучше понимает свою ценность и может договариваться о более выгодных условиях оплаты. Если работает в штате, то обоснованно просить повышения, а не просто ждать его. Если работает на аутсорсе, то договариваться о бо́льшем гонораре за проект. Потому что не просто пишет код, а решает важные задачи.
Хочу рассказать несколько историй о том, как проактивность и погружение в мир бизнеса повлияли на профессиональную жизнь разработчиков.
Я помню каждую из них не только потому, что у меня хорошая память. Но и поскольку редко кто решается перейти из трюма на верхнюю палубу.
Фулстечность в сторону бизнеса
У нас в компании есть разработчик Андрей. Когда он только пришел, был уверенным миддлом — не самым сильным или опытным программистом в команде. Но это не мешало ему включаться в задачу.
Он постоянно просил обратную связь, спрашивал, не фигню ли он делает, придумывал решения и пытался внедрять что-то новое. При этом он не забывал об основной своей задаче и писал адекватный код.
Его начали приглашать на митинги, обсуждать с ним продуктовые решения. Когда вставал вопрос, кому поручить ответственную задачу, его имя приходило на ум первым. Потому что все понимали: он включится, разберется и сделает, как надо.
Дать самую челленджовую, самую интересную задачу другим — как играть в русскую рулетку, то есть иногда даже повезет. А вот поручить Андрею — надежное решение.
Из-за такой активности его статус в компании начал расти. А вместе с ним — роль в команде, оклад и опционы.
Чтобы перейти в следующую когорту, вам нужно понимать, как ваш труд влияет на то, сколько бизнес будет зарабатывать.
Когда разработчик выделяет время, чтобы разобраться в бизнес-смысле задачи, потребностях бизнеса и сути продукта, всё начинает меняться.
Он лучше понимает, для чего пишет код, может предложить свое решение или указать слабые места в задании. Может скорректировать вектор и выбирать (создавать) интересные для себя задачи.
Почему директор получает больше денег, чем инженер? Он же не больше работает, он даже ничего своими руками не создает. Ответ простой: у него больше ответственности. От него больше зависит, он берет на себя больше рисков — и за этот риск он получает свою огромную надбавку.
Хорошие работодатели ценят разработчиков, которые выходят в надсистему и задают вопрос «А почему нужно делать именно эти задачи?».
Такого разработчика чаще вовлекают в обсуждение продукта, к его мнению прислушиваются. Его статус в компании растет, а вместе с этим — доход и удовольствие от работы.
Фулстечность в осознанность
Незаинтересованные разработчики заботятся о четком и понятном плане своей загрузки: над чем они будут работать сегодня, над чем — завтра.
Чтобы расти, нужна заинтересованность: какую потребность бизнеса решает эта фича или продукт?
Например, нужен ли рефакторинг с точки зрения бизнеса. Хороший разработчик понимает, когда в нем нет смысла, когда речь об MVP, когда важна скорость. И наоборот, если это ядро — если будет большая нагрузка. То есть разработчик не делает, чтобы просто попробовать новую технологию, — он осознаёт, какой результат это даст, какие будут проблемы.
В результате если вы понимаете, чего хотят от таска, вы можете осмыслить его и понять, как решить эту проблему лучше. Причем те, кто ставит задачу, могут вообще не знать, что ее можно решить как-то по-другому. Они могут в целом не подумать о ситуации — и в этот момент вы увеличиваете стоимость своего труда.
Вот пример. У нас возникла потребность перевести внутреннюю собственную CRM на несколько языков, потому что к команде присоединились люди из разных стран. Менеджер проекта поизучал готовые решения, выбрал один с оптимальной стоимостью и сделал таск на интеграцию.
Разработчик не поленился, сходил к руководителям бойцов, которые работают с CRM, и выяснил, что 95% операторов знают базовый английский, а научить остальных 50 необходимым словам — задача простая. В результате мы просто поменяли язык на английский и не стали включать многоязычность, сохранив себе лишний миллион рублей.
Конечно же, менеджеру в этот момент не просто радостно, ему прямо самому хочется заплатить экстрапремию разработчику. Потому что любая взаимоприемлемая сумма премии много меньше сэкономленного ляма.
Нужно понимать продукт, с которым вы работаете, и суть бизнеса, в котором вы работаете. Разберитесь, как он зарабатывает деньги — и как текущий таск на это может повлиять.
Это позволит вам делать задачу осмысленно и приоритизировать задачи, выступая в этом смысле «защитой от дурака». Потому что поток задач от бизнеса может быть большим — и выделять в нем главное — очень важно.
Однажды сервис Skipp для задачи в Skyeng подключил сеньор-разработчика. Он отметился тем, что очень дотошно общался на техревью. Ему важно было разобраться, как устроен проект с точки зрения бизнеса, как бизнес будет на этом зарабатывать.
Казалось бы, ему нужно было просто допилить CMS-систему, но он не приступал к задаче, пока не разобрался, на что именно она будет влиять. Зато в итоге он отлично понимал, что и зачем он делает: у него выросла мотивация и вовлеченность, задача стала не рядовой, а интересной. Важно, что он не боялся задавать вопросы и выглядеть несведущим.
От микроменеджмента к автономности
Чем глубже разработчик погружается в задачу и общается с бизнесом, тем меньше требуется микроменеджмента.
Заказчики склонны следить за мелочами, когда считают, что они лучше знают, что нужно сделать, — то есть почти всегда. Они не верят в самостоятельность разработчика, поэтому будут постоянно уточнять статус и влезать в работу.
Чтобы повышать автономность, заинтересованные разработчики сами идут на контакт: активно запрашивают обратную связь, показывают промежуточный продукт, спрашивают, всё ли с ним в порядке. Тот же Андрей из нашей компании не боится интересоваться, в нужную ли сторону он идет.
Но тут можно впасть в другую крайность — начать забрасывать заказчика вопросами, стать назойливым занудой. Что может спасти от этого: умение задавать правильные вопросы на языке бизнеса. Учитесь говорить на этом языке.
Тогда у менеджера постепенно пропадает желание контролировать каждое действие, он знает: если что-то пойдет не так, разработчик сам первым к нему придет. В итоге все могут спокойно работать.
Когда разработчик постоянно молчит, а в самый последний день показывает сырой продукт и рассказывает обо всех проблемах, с которыми столкнулся, никакого доверия он не заслужит. Как следствие — никакой автономности.
В практике Skipp был пример с итальянской платформой для инициатив по КСО. Заказчик сначала самостоятельно и во всех деталях описывал ��аже самые мелкие задачи: например, как должны работать поля во всех формах.
Проблема была в том, что он сам он не был разработчиком и часто просил сделать что-то нетипичное. Команда шла на поводу, но результат получался так себе: всё постоянно падало и ломалось.
Разработчики решили обсудить с ним этот процесс, получше узнать требования. И объяснили, почему стоит не изобретать каждый раз велосипед, а использовать готовые модули и универсальные компоненты. Договорились, что заказчик будет ставить верхнеуровневые задачи, а команда — самостоятельно находить решение.
В итоге от нагромождений и нетипичных решений отказались, заказчик перестал заниматься микроменеджментом, мотивация разработчиков выросла, они стали больше заботиться о коде. А продукт стал более работоспособным и полезным для клиента.
Если коротко, то есть такой любимый многими профессионалами анекдот.
«Делаю все сам = 100$
Ты смотришь, я делаю = 200$
Ты говоришь, я делаю = 300$
Я говорю, ты делаешь все сам = 1000$»
Почему так? Потому что микроменеджмент отнимает столько сил и нервов, что никакие дополнительные деньги не нужны.
Понимание бизнеса добавляет гордости за продукт.
Разработчик видит в себе уже не простого исполнителя — а становится полноценной частью команды и ценит свой вклад в работу.
Сравните две задачи.
Сделать модуль для системы бухгалтерского учета.
Высвободить десятки ночных часов у бухгалтеров. Раньше они тратили это время на бесконечные отчеты, теперь могут посвятить его себе и детям.
Когда разработчик понимает, что не просто пишет код, в его работе появляется более глубокий смысл. Таким продуктом можно гордиться.
Но сложно гордиться тем, чего не понимаешь.
В заключение
Вы все прокачиваете свои хард-скиллы с точки зрения разработки. Новые языки, новые фреймворки. Но переход в следующую когорту дает совсем другой хард-скилл — понимание основ бизнеса.
Вы знаете, как функционирует бизнес? Как устроена вся цепочка продукта — от идеи до продажи?
Продажа означает, что придуманный и созданный продукт кому-то нужен, кто-то готов платить за него свои деньги. Если очень упрощать: продукт обладает вот такими-то свойствами, поэтому мы его делаем, затраты на его производство вот такие, цена вот такая, цена минус затраты это наша прибыль.
В том же Skipp ставка разработчика на проекте зависит от сложности проекта. Но на сложные проекты обычно берут не просто тех, кто знает технологию или много лет отработал в нужном стеке, а тех, кто точно с такой задачей справится. Обычно это как раз разработчики, которые стремятся разобраться в задаче, а не просто закрыть таски.
Итак: для роста дохода вам нужно понимать, как работает бизнес.
Где и как этому учиться? Самый быстрый и простой способ — нормальные курсы по продакт-менеджменту. Это позволит вам научиться понимать человека, который вам ставит задачи. Что именно он имел в виду, что он хочет получить в результате.
Резюмирую. Расти за счет лет стажа сложно: максимум, на который можно рассчитывать, — это ежегодная индексация. А вот за счет роста сложности проектов расти намного легче. Но чтобы повышать сложность, нужно начинать разговаривать с заказчиком на одном языке и не бояться брать ответственность.
Ну или просто оставаться гребцом.
Видео моего выступления с конференции вы можете посмотреть здесь.
Следующая тимлидская конференция пройдёт этой осенью – 16 и 17 сентября в Санкт-Петербурге. Рекомендую.
