В чем отличается взгляд на карьеру у разработчика и его руководителя
Жизнь полна противоречий. Даже свет не может определиться, кто он – частица или волна.
В мире разработки софта противоречий между действующими лицами вагон и маленькая тележка. Давайте рассмотрим пару – разработчик и руководитель разработки (это может быть руководитель проекта, технический менеджер, тимлид). Как выяснится, эти двое зачастую по-разному смотрят на вещи и вообще стремятся в разные стороны.
Чего хочет разработчик
Все хотят разного. Но поскольку без обобщений нам не обойтись, возьмем сферического в вакууме разработчика уровня middle. Он в меру ленив, в меру любопытен и ему в целом нравится его профессия. Ему бы только сроки помягче, процессы получше, задачи поинтереснее.
Как он хочет развиваться? А вот так:
- Изучать новые технологии
- Решать более интересные задачи
- Участвовать в новых проектах
- Поменьше заниматься деятельностью, не связанной с разработкой
- Принимать решения самостоятельно
В то же время его руководитель хочет:
- Чтобы разработчик хорошо знал используемые технологии
- Чтобы разработчик хорошо справлялся с поставленными задачами: с должным качеством и в установленный срок
- Чтобы разработчик был ответственным и всегда завершал то, за что взялся
- Чтобы разработчик давал адекватные оценки задачам
- Чтобы разработчик имел понимание потребностей бизнеса и продукта в целом
- Чтобы разработчик своевременно сообщал о проблемах
Хотите знать, как добиться компромисса? Добро пожаловать под кат.
Итак, что мы имеем. Налицо полное противоречие в интересах.
Разработчик хочет узнавать новое, а руководитель хочет, чтобы он хорошо умел пользоваться привычными инструментами.
Разработчик хочет решать интересные задачи, а у руководителя мешок обычных задач, которые кто-то должен делать.
Разработчик хочет участвовать в новых проектах, а руководителю нужно, чтобы кто-то поддерживал уже имеющиеся.
Разработчик не хочет заниматься ничем кроме разработки, а руководителю нужно, чтобы код был документированным, чтобы процесс разработки был прозрачным и управляемым, чтобы выполнялись планы, выдавались релизы и т.д. Для этого он просит давать оценки, проводит стендапы, ретроспективы, заставляет планировать свою деятельность.
Разработчик хочет принимать решения самостоятельно (он же знает, как правильно), а руководитель требует, чтобы о выявленных проблемах сообщали ему, чтобы он мог проконтролировать принятие решения.
Неудивительно, что многие руководители разработки имеют плохую репутацию среди своих разработчиков – они не дают делать то, что хочется, а наоборот, заставляют заниматься тем, от чего тошнит.
Причины
Причина на мой взгляд очень проста. У разработчика и его руководителя – разные цели.
Цель разработчика — быть более востребованным на рынке труда.
Цель руководителя — сдать проект в срок.
И все же, несмотря на столь радикальные отличия, можно добиться компромисса, устраивающего обе стороны.
Попробуем разобраться более детально.
Разработчик
Изучать новые технологии
Это действительно интересно и воодушевляюще. На начальном этапе становления специалиста полезно иметь широкий взгляд на индустрию и понимать – какие вообще есть возможности для развития. Однако со временем количество должно переходить в качество.
Не знаю как вы, а я часто настороженно отношусь к резюме разработчика (с опытом 2-4 года), в котором перечислены десятки языков, фреймворков и библиотек. Это может быть сигналом того, что человек занимался всем понемногу, но глубоко ничего не знает (хотя встречаются исключения). Предпочтительнее встретить человека, который знает не так много, но зато знает это наверняка. А для этого необходим значительный практический опыт применения технологии. Тогда появится понимание её тонкостей и границ применения, а это крайне важно.
Таким образом, изучать новые технологии важно и нужно, но крайне желательно, чтобы за этим стояла реальная практика. Даже если вы разрабатываете pet-project, сделайте так, чтобы технология использовалась не для галочки, а реально решала бизнес-задачу.
Решать более интересные задачи
Я думаю, каждый знаком с понятием “рутина”. Никто не хочет постоянно заниматься одним и тем же. Однако здесь есть очень важная деталь. Несправедливо хотеть новых интересных задач, если вы со старыми неинтересными едва справляетесь. Любое мастерство имеет ступени, и нельзя перескакивать через них – рано или поздно это приведет к болезненному падению.
В целом все как в компьютерной игре. Чтобы перейти на новый уровень – нужно хорошо пройти предыдущие. Прежде чем требовать от руководителя интересных задач – научитесь решать текущие задачи быстро и качественно, тогда станет очевидно, что вы достойны большего.
Участвовать в новых проектах
Очевидно. Довольно мало людей с воодушевлением занимаются поддержкой проекта на регулярной основе. Исправлять баги свои и своих товарищей, пока они разрабатывают что-то новое, обидно.
Но ведь именно на поддержке зачастую приобретается понимание нужд бизнеса, которое жизненно необходимо любому проекту. Разработчик учится смотреть на свой софт глазами пользователя – а это один из самых ценных навыков для программиста. Кроме того, появляется умение разбираться в существующем коде, аккуратно рефакторить его, не ломая всю систему. Эти навыки пригодятся не только на поддержке, но и при разработке нового проекта — не повторять прошлых ошибок, поддерживать кодовую базу в пристойном состоянии, бороться с техническим долгом.
Не отказывайтесь поддерживать проекты, которые вы разрабатывали – это бесценный опыт, который может дать значительное ускорение вашей карьере.
Поменьше заниматься деятельностью, не связанной с разработкой
Немало найдется разработчиков, которые считают написание документации, планерки, ретроспективы, общение с заказчиком – пустой тратой времени. Главное ведь – написать код? Чтобы все было аккуратно, красиво, соответствовало гайдлайнам.
Нет. Главное – чтобы софт делал то, что от него требуется – решал проблемы бизнеса. Кроме этого, сильно желательно, чтобы разработка уложилась в сроки и бюджеты. Если нет – вполне возможно, что наш идеальный код никогда не будет работать.
Нужно ясно осознавать, что для сколько-нибудь сложной разработки необходим план, регулярная синхронизация участников проекта (включая заказчика), качественная документация и другие вещи, не являющиеся написанием кода.
Если вы хотите быть важным и полезным участником проекта – вы должны иметь понимание тех процессов, которые происходят на проекте и стараться следовать им. Это еще один полезный опыт, который должен иметь каждый.
Руководитель
Хорошо знать используемые технологии
Справляться с поставленными задачами: с должным качеством и в положенный срок
Руководителю необходимы люди, на которых можно положиться. Если задача поставлена – она должна быть решена. Неважно, было интересно разработчику этим заниматься или это для него тягостная рутина. Так получается, если «решать проблемы по мере их поступления» и «жить сегодняшним днем». Но чтобы разрешить противоречие, нужно действовать иначе. Постоянно обучая разработчиков новому и передавая им опыт решения существующих задач, мы повышаем их уровень. Получая дополнительные знания, опыт и широту кругозора, они будут решать существующие задачи гораздо быстрее, а возможно предложат улучшение процесса. Такие изменения, инициированные «снизу», ценны не только своим прямым результатом, но также замечательно мотивируют разработчиков искать и предлагать новое.
Выделяя людям время на самостоятельное изучение новых технологий или обучая их, вы можете получить высокопроизводительную и мотивированную команду.
Быть ответственным и всегда завершать то, за что взялся
Я думаю, все согласятся, что профессиональное программирование – это в первую очередь достижение результата. Чтобы достичь успеха, все участники проекта должны выполнять свои задачи. В итоге не важно, насколько крут разработчик технически, если он ни одной задачи не может завершить и бросает все на полпути. Универсальная истина, которую постулируют великие программисты – задача должна быть решена максимально простым способом. Возможно, это вообще самое главное качество разработчика – уметь решать задачи без лишних сложностей. Усложнять — легко, упрощать – сложно.
Не побоюсь утверждать, что именно такие люди больше всего ценятся на реальных проектах. И руководитель, и товарищи по проекту знают, что на человека можно рассчитывать, что он не подведет.
Воспитание в людях именно таких профессиональных установок — одна из важных задач руководителя. Важнейшим механизмом в этом деле является поощрение достижения результата. В результате вы получаете не просто команду разработчиков, а команду единомышленников, каждый из которых заинтересован в том, чтобы достичь общей цели.
Давать адекватные оценки задачам
У многих разработчиков наверняка появлялась мысль – а зачем с меня постоянно требуют оценок, как сделаю, так сделаю, все равно раньше, чем я закончу – ничего не появится. Оценки кажутся унизительным механизмом контроля. Однако, посмотрим на это глазами руководителя.
Как я уже писал, чтобы проект был успешен, у руководителя должен быть план. Существуют счастливые исключение, но в общем случае без плана разработка превращается в хаос. Даже если план календарно не выполняется, он все равно приносит пользу – руководитель видит, где проблема и может перестроить его, чтобы проблему решить. Чтобы составить план, руководителю нужны оценки. Даже если разработчик недооценил или переоценил задачу – для руководителя это лишь повод ввести поправочный коэффициент. Таким образом, имея оценки от разработчиков и исторически подтвержденные поправочные коэффициенты, руководитель может построить план близкий к реальности.
Разработчики часто недооценивают необходимость планирования, потому что сконцентрированы на разработке. Но как мы знаем, успешный проект – это не только разработка. Необходимо тестирование, документирование, выдача заказчику, организация UAT и т.д. Команда должна действовать согласованно, планирование и следование плану обеспечивают такую согласованность.
Поскольку успех проекта – это и успех каждого участника, для достижения собственного успеха разработчику необходимо уметь адекватно оценивать задачи.
Именно руководитель должен дать разработчикам понимание всех процессов, происходящих за рамками разработки. Объяснить смысл каждого действия и принимаемого решения, важность планирования, коммуникации. Осознанность — ключ к успеху.
Иметь понимание потребностей бизнеса и продукта в целом
Довольно часто разработчики фокусируются на написании кода, оставляя без внимания бизнес-задачу, которую они решают. К сожалению, это свойственно не только начинающим, но и вполне состоявшимся и титулованным специалистам.
Как я уже писал, главной задачей программирования я считаю решение задач бизнеса. Поэтому, естественным образом, хорошим программистом может считаться только тот, кто может эти задачи эффективно решать. Для этого жизненно необходимо ясно понимать, что происходит в бизнесе, который мы автоматизируем.
Таким образом, желание руководителя, чтобы разработчик разбирался в потребностях бизнеса и каждую задачу рассматривал в первую очередь с этой точки зрения (какую бизнес-задачу мы решаем и зачем) – более чем естественное желание. Только так разработчик может достичь настоящего мастерства. А значит, настоящие интересы руководителя и разработчика здесь совпадают.
Как и в предыдущем пункте, обязанность руководителя — внятно и доходчиво объяснить разработчику, что требуется бизнесу и почему. Кроме этого, необходимо донести простую истину — ценится тот, кто может вникнуть в предметную область и решить конкретную проблему, а не тот кто просто пишет красивый код.
Своевременно сообщать о проблемах
Для обеспечения успеха проекта руководителю жизненно необходимо своевременно получать информацию о проблемах с выполнением задач. Разработчик же зачастую, напротив, предпочитает до конца бороться с проблемой и сообщать о ней только тогда, когда все разумные сроки прошли. Следует сказать, что желание самостоятельно разобраться в проблеме всегда похвально. Однако для блага проекта нужно сообщать руководителю о проблемах, которые могут увеличить сроки решения задачи, для того, чтобы он мог учесть это в плане.
Важнейший навык разработчика – умение своевременно и открыто коммуницировать с другими участниками проекта. Своевременное сообщение о проблеме – важная часть коммуникации.
При этом руководитель не должен сразу кидаться решать проблему. Разумнее дать разработчику время разобраться самому, принять нужные решения и предъявить результат. Это даст ему уверенность в своих силах, привычку полагаться на себя и в то же время избавит от страха сообщать о проблемах своевременно.
Подведем итог. Как сочетать интересы разработчика и его руководителя?
Разработчику
- Успех проекта – это успех каждого его участника. Каждый успешный проект – это шаг вперед в вашей карьере. На любом собеседовании вы наберете гораздо больше очков, если будете иметь за спиной успешно сданные проекты.
- Решение бизнес задач – основная цель разработки. Если проект провален – не важно, насколько хороша была архитектура и насколько был красив код.
- Развитие – это не только изучение новых технологий: ответственность, навыки коммуникации, фокус на решение реальных проблем, понимание потребностей бизнеса – все это ценится ничуть не меньше.
- Проекты не делаются в одиночку, это командная работа. Чтобы команда работала эффективно, необходима постоянная координация участников. Без актуального плана такая коммуникация невозможна. Чтобы план был актуальным, разработчики должны участвовать в его построении и адекватно оценивать свои задачи.
- Поддержка проекта – это не бесконечная рутина, а возможность глубоко разобраться в потребностях бизнеса и пользователей, а также посмотреть свежим взглядом на технические решения, принятые на этом проекте ранее, оценить их эффективность и, возможно, что-то улучшить.
Руководителю разработки
- Думайте не только об успехе проекта, но и о развитии своих людей. Проектов много, пусть разработчики растут с каждым новым проектом. Займитесь регулярным обучением своих людей.
- Объясняйте разработчикам потребности бизнеса и смысл задач, требований и процессов.
- Объясняйте важность процессов и следите за тем, чтобы им следовали.
- Прислушивайтесь к мнению разработчиков по улучшению процессов.
- Поощряйте ответственность и организованность.
- Позволяйте разработчикам самостоятельно решать возникшие проблемы.
