Общался недавно с миддлом из команды разработки, которая состояла из 6-ти сеньоров и одного миддла. По словам миддла, расти в этой команде было очень сложно по ряду причин:
Одновременно с этим были установлены высокие требования по скорости выпуска продуктов, что с учетом факторов, приведенных выше, приводило к перманентному перенапряжению всех разработчиков.
Послушав этого миддла, я заинтересовался тем, как обстоят дела с балансированием команд разработки специалистами разного уровня, есть ли смысл создавать команды, состоящие из одних сеньоров, и как повышать свой уровень в таких командах на примере компаний из, например, Кремниевой Долины.
В результате я наткнулся на статью, перевод которой приведен под катом.
Прошу участников сообщества привести в комментариях свои мысли, как бы они действовали, будучи в описанной позиции миддла: как обучаться, как вести себя с другими членами команды и любые другие ваши мысли.
Переведено @middle_java
Согласно опросу разработчиков StackOverflow за 2016 год, участие в программе наставничества сильней коррелирует с зарплатой, чем наличие кандидатской степени, а разработчики больше ценят изучение новых вещей по сравнению с другими мотиваторами, такими, как создание нового, вера в миссию компании и продвижение по службе.
Хорошие наставники могут помочь в решении большинства основных проблем, стоящих перед разработчиками, в том числе:
Старшие наставники играют в командах разработки незаменимую роль. Но трудно найти настоящих, квалифицированных старших разработчиков с опытом, которые могут нормально руководить командой.
Взгляните хорошенько на свою команду. Есть у кого-нибудь более чем 6-ти-летний опыт создания масштабных промышленных приложений? Чувствуют ли члены вашей команды, что у них есть надежный гид и наставник, который постоянно подталкивает их к совершенствованию своего мастерства?
Если ответы будут «нет», то вы действительно многое упускаете из виду.
Есть много причин, по которым хороших наставников трудно найти и удержать, но все начинается с управления командой. Можно многое сделать для создания гораздо более эффективной и хорошо организованной команды, к которой разработчики будут рады присоединить на долгие годы.
В Кремниевой Долине многие инженеры либо переходят в управление, либо вообще уходят. Это плохо не только для старших разработчиков. Это плохо для работодателей.
Это плохо влияет на командную культуру и настрой. Это плохо сказывается на производительности команды. И это плохо для разработчиков младшего и среднего уровня, которые лишены больших возможностей наставничества.
Если вы занимаетесь разработкой очень долго, то, возможно, чувствовали давление, заставляющее вас перейти в управление. Если вы решили, что вы хотите выбрать именно этот маршрут, эта статья поможет составить представление о том, как построить оптимальную команду и соответствующую ей культуру.
Создание хорошо сбалансированной команды является важным элементом построения высокоскоростной команды разработчиков.
Если вы хотите создать что-то великое, то начните с великих людей. Построить команду — это нечто гораздо большее, чем просто нанять людей с нужными навыками. Это также значит найти людей, которые будут вписываться в остальную команду и балансировать ее.
Для менеджера может быть заманчиво рассматривать других членов команды, как винтики машины. Было бы удобно, если можно было бы поставить их на любую позицию и ожидать, что они будут действовать в соответствии с вашими ожиданиями для этой позиции.
К счастью для всех, настоящие команды работают не так, поэтому ваша первая задача — научиться распознавать в себе соблазн оценивать членов команды по количеству тикетов, которые они закрывают.
Эта ошибка является первопричиной проблемы номер один, с которой сталкиваются разработчики: Нереалистичные ожидания. Когда вы фокусируетесь на подсчете количества закрытых тикетов, вы игнорируете более широкий контекст работы над проектом и нормальную динамику команды, что может привести к катастрофическим результатам: моральной подавленности, высокой текучке разработчиков и снижению продуктивности.
На самом деле существует два различных типа разработчиков, и для достижения оптимальной производительности вашей команде нужны они оба:
Не все индивидуальные разработчики являются младшими разработчиками. Многие из них являются талантливыми старшими разработчиками, которые просто предпочитают фокусироваться на разработке нового функционала и исправлении ошибок, а не погружаться в сложную кухню наставничества, формирования менеджерских ожиданий и лидирования людей.
Культура стартапов в районе залива Сан-Франциско старается объединить всех в группу 2. Это недальновидно и расточительно. Сейчас разберемся почему.
Давайте разберемся с парой определений:
«Старший» — не значит больше в годах. Я встречал разработчиков с 15-ти-летним опытом, которых я бы классифицировал, как младших разработчиков с точки зрения формирования команд, и других, у которых есть 2-3-х-летний опыт, которым бы я доверил создание нового приложения с нуля.
Тем не менее «старший» — это определенно не то, что происходит за одну ночь, а шкала навыков — это широкий градиент, не что-то бинарное. Ничто не может заменить уроки, полученные за годы работы. В книге Малкольма Гладуэлла «Outliers: The Story of Success» предполагается, что правило 10_000 часов может применяться ко многим навыкам: Чтобы достичь мастерства в своем ремесле, требуется 10_000 часов практики. Это означает, что разработчику требуется около 6 лет практики, чтобы овладеть этим ремеслом. Это звучит для меня абсолютно верно.
Однако просто опыта недостаточно для обеспечения прогресса. В статье «Peak: Secrets from the New Science of Expertise» Андерс Эриксон и Роберт Пул объясняют, что практикующие специалисты должны часто заниматься осознанной практикой, при которой обучающийся постоянно работает на грани своих способностей — это та приятная точка, в которой ощущается и сложность и уверенность.
Плюс к этому, как наставник и учитель, я обнаружил много других аспектов, которые могут радикально улучшить эффективность обучения разработчиков. В частности:
Если вы хотите, чтобы ваша команда совершенствовалась быстро, нужно поощрять эти практики.
Некоторые члены команды отличаются своими знаниями и способностями к созданию архитектуры и служат хорошим примером для остальных членов команды. Когда они вовлечены в эту деятельность, их вклад является фактором умножения эффективности, увеличивающим продуктивность всей команды.
Кроме того, эти участники могут видеть более универсальные решения общих проблем и разрабатывать инструменты, которые помогут остальной части команды быть более продуктивной. (Другие члены команды тоже смогут, но, возможно, не так часто).
Если в команде из шести человек один сотрудник является сильным наставником с коэффициентом умножения эффективности = 2, то это означает, что оставшиеся пять человек выполнят работу десяти. Возможно, вы слышали термин десятикратный разработчик. Наставничество — это самый реалистичный способ внести десятикратный вклад.
Возможно, вы думаете, что моя математика сейчас ошибочна, ведь разве другие участники не заслуживают похвалы за свой однократный вклад? Возможно, некоторые, но все не так просто. Реальное количество разработчиков, которым нужно помочь, чтобы достичь десятикратной производительности, лежит где-то между 5-10.
Давайте копнем немного глубже. Эту часть многим людям трудно понять или оценить в полной мере:
Младший или средний разработчики в состоянии закрывать тикеты. Может быть даже быстро. Однако младшему разработчику не хватает видения и опыта, чтобы понять, как тот технический выбор, который он делают сегодня, повлияет на продуктивность всей команды в будущем. Другими словами, безнадзорный младший разработчик может быть дробным фактором эффективности, что создает помехи для производительности всей команды.
Оставленные без присмотра младшие разработчики будут выпускать быстрые фиксы в общем направлении по каждой проблеме, с которой они сталкиваются, регулярно упуская первопричины, часто повторно вызывая проблемы и пожары, и оставляя после себя кучу технических долгов.
Младшие разработчики также часто борются со сложными проблемами, отвлекая для помощи других разработчиков от их работы.
Разработчики среднего уровня (как правило, с 2-5-ти-летним опытом работы. Это то, что во многих вакансиях в районе залива называется «старшими») придумают рабочие решения сложных технических вопросов, но эти решения, как правило, будут сложными сами по себе и трудными для понимания другими членами команды, что также создает нагрузку на продуктивность команды.
Опытные старшие разработчики часто придумывают обманчиво простые решения сложных проблем и учат других разработчиков делать то же самое.
Так что, не надо нанимать младших разработчиков, верно? Не верно. Младший разработчик может быть очень умным и быть очень хорошим учеником. Просто отсутствие опыта и понимания создает отрицательное сопротивление.
Но прием на работу младших разработчиков без привлечения к их ориентированию старших наставников — это все равно что закладывать бомбы замедленного действия по всей кодовой базе.
Когда команда разработчиков сталкивается с проблемами производительности и большими техническими долгами, возникает соблазн обвинить в этом отдельных разработчиков.
Первопричиной технического долга является ориентация менеджмента на краткосрочную микропродуктивность в ущерб долгосрочной макропродуктивности. Когда вы позволяете побочному продукту накапливаться достаточно долго, в конце концов он засорит механизм.
Менеджеры часто ошибаются, думая, что скорость обработки тикетов может быть использована для оценки эффективности отдельных участников. Это просто неправда.
Люди не работают в вакууме. Они работают друг с другом. Ваши самые знающие сотрудники быстро станут теми наставниками, к которым все обращаются с вопросами, и это хорошо.
Этот наставник/старший разработчик отвечает за поддержание механизма чистым и хорошо смазанным, предотвращая засоры, которые пустят под откос всю команду.
Но старшие наставники не закрывают много своих собственных тикетов. Вместо этого они будут сосредоточены на код-ревью, разблокировке остальной части команды, когда она столкнется с новыми проблемами, и работе над оптимизацией долгосрочной продуктивности всей команды.
Дело в том, что инженерные лидеры должны понимать, что ваши самые продуктивные члены команды часто закрывают наименьшее количество тикетов.
Вам не нужно, чтобы ваши наставники быстро закрывали тикеты. Вы не хотите, чтобы ваши наставники быстро закрывали тикеты. Последнее, что вы хотите сделать в качестве инженерного руководителя, это оказать на них давление для этого.
Вам нужно, чтобы они помогли остальным разработчикам научиться разрабатывать приложения таким образом, чтобы команда в целом поддерживала более плавную скорость.
Стартапы в Заливе правильно придают большУю ценность скорости и гибкости, но там совершенно не понимают, как построить культуру, где скорость и гибкость процветают естественным образом.
Они слишком сосредоточены на закрытии конкретных тикетов сегодня, вместо осознания того, что именно культура обучения и наставничества обеспечит долгосрочное здоровье и стабильность совокупной скорости и продуктивности команды в будущем.
Еще один отличный способ убедиться в том, что ваши наставники работают продуктивно — это посмотреть на их деятельность по код-ревью. Они должны проводить много код-ревью, полных отличных советов о том, как код может быть улучшен конкретными способами на архитектурном уровне.
Неопытный рецензент больше сосредоточен на несущественных стилистических вопросах (точки с запятой, заглавные буквы, пробелы и т. д.). Великий наставник будет обучать концепциям разработки программного обеспечения, не подверженных влиянию времени, шаблонам проектирования и тому, как писать код, который легче читать и поддерживать другим разработчикам.
Каждая компания хочет иметь «старших» разработчиков, потому что правильно считается, что старшие разработчики будут лучше понимать, как написать приложение, которое само по себе будет устойчивым к меняющимся требованиям заказчиков и менеджеров продуктов.
Старшие разработчики сами по себе менее склонны создавать горы технических долгов, поскольку они закрывают тикеты и большинству из них требуется меньше усилий, чтобы быстро освоиться с новой кодовой базой.
Стандарты того, что подразумевается под «старшим разработчиком», с годами изменились. Когда я только начинал работать профессиональным программистом, очень часто приходилось видеть вакансии на старшие позиции, требующие минимум 5, 7 или 10 лет опыта.
Сегодня в Сан-Франциско вы увидите аналогичные позиции, требующие минимальный опыт работы 2-3 года. Отчасти причина этих изменений заключается в том, что на рынке труда ощущается нехватка разработчиков, которые не только обладают требуемым опытом в годах, но и знаниями и умениями, необходимыми для выполнения этой работы.
Но вакансии все еще не закрыты. Поэтому мы нанимаем людей с чуть меньшим опытом, называем их «старшими разработчиками» и надеемся, что все получится. Не получится.
Как я уже упоминал, опыт — это еще не все, но когда речь заходит о роли старшего наставника, опыт все равно имеет большое значение. Есть вещи, которым нельзя научиться, кроме как прожив жизнь.
Между старшим разработчиком на бумаге и реально старшим разработчиком действительно большая разница. Разработчик с 3-х-летним опытом не имеет реального жизненного опыта создания нескольких промышленных масштабных приложений. Он просто не работал на достаточном количестве ролей достаточно долгое время, чтобы увидеть, как это происходит более одного или двух раз.
Это означает, что он не знает всех или даже наиболее распространенных проблем, с которыми сталкиваются команды разработчиков.
Но мы все равно их нанимаем. Потому что они отлично справляются с разработкой всяких штук и исправлением ошибок, а этого почти всегда достаточно на какое-то время.
Как я только что объяснил, многие «старшие» таланты, нанятые в районе залива Сан-Франциско, на самом деле не являются старшими. Это менее опытные разработчики, готовые работать за гораздо меньшую зарплату, чем настоящие старшие разработчики, которые в Сан-Франциско рассчитывают заработать более 150 тысяч долларов США в год.
Трехлетний разработчик будет счастлив, зарабатывая 130 тысяч долларов США в год. Медианная зарплата разработчика в Сан-Франциско составляет чуть более 110 тысяч долларов США в год.
(Замечание для неместных: это выглядит как будто много, но в Сан-Франциско вы не разгуляетесь после того, как заплатите аренду за жилье).
Многие технические основатели в районе залива сами молоды. Когда вы молоды и свободны от привязанностей, вы можете позволить себе делить квартиру с четырьмя соседями по комнате и приносить домой небольшую зарплату, пока вы бегаете в поисках финансирования и пытаетесь нанять других людей.
Молодому основателю может показаться безумным нанять «недосягаемого» разработчика за ту же цену, которую он заплатит за двух менее опытных «старших» разработчиков, а для CEO может показаться возмутительным платить старшему разработчику больше, чем он сам будет приносить домой. Молодые стартапы обычно рассматривают зарплату настоящего старшего разработчика как «дорогую».
Корпоративная культура компаний Сан-Франциско часто ориентирована на молодых работников, включая изнурительный режим и частые мероприятия во внерабочее время, такие как вечеринки, ужины, выпивания, вечерние викторины, турниры по пинг-понгу и барбекю. Сотрудники с семьями часто не чувствуют себя частью компании, когда они решают вернуться домой к семьям вместо того, чтобы посещать такие мероприятия.
Работа в молодом стартапе — не единственный вариант для старших разработчиков. Опытные компании, такие как Adobe, Google, IBM и Microsoft, ценят таланты старших разработчиков и готовы платить за это премии.
Google, как известно, заманивает разработчиков успешных приложений компенсациями в миллионы долларов.
Microsoft признает, что ей нужны как старшие, так и младшие разработчики и агрессивно набирает и тех и других.
Некоторые старшие разработчики разочаровываются в рынке труда района залива и уходят оттуда, предпочитая создавать собственные приложения или небольшие агентства по разработке программного обеспечения.
Другие просто недоумевают, почему стартапы в Долине их недооценивают и изо всех сил пытаются найти работу.
Когда вы относитесь к каждому разработчику, как к старшему разработчику, которому вы можете доверять в условиях его полной самостоятельности, в итоге вы получаете команду, в которой сотрудники не могут учиться друг у друга и расти совместно в навыках и производительности.
Когда вы нанимаете младших разработчиков, вы воспринимаете как должное, что нужно создавать культуру обучения, чтобы была возможность развивать младших разработчиков и распределять опыт по всей команде.
Эта культура увеличивает объем парного программирования, ведет к более тщательному и продуктивному код-ревью (в отличие от тривиальной придирки к мелочам) и гораздо меньшему изолированию знаний.
Когда члены команды часто занимаются обучением друг друга, это убирает из головы их индивидуальную работу, что дает лучшее представление о том, как их работа вписывается в более широкий контекст приложения.
Одна из больших проблем, с которыми сталкиваются команды разработчиков, заключается в том, что индивидуальные разработчики, как правило, специализируются на небольшой области приложения (что приводит к повышению продуктивности, когда они работают в этой области). Но они делают это ценой снижения продуктивности, когда другие члены команды пытаются работать над этой частью приложения.
Помимо этих преимуществ, команды нуждаются в младших разработчиках, потому что никто не сообщил младшему разработчику, что существует что-то невозможное. Они возьмутся за невозможное и иногда смогут найти решение, и они не завязнут со словами «мы всегда так делали.»
Возможно, самая важная причина для найма младших разработчиков заключается в том, что трудно найти старших разработчиков, которые действительно знают, что они делают. Охота за хорошим старшим разработчиком может занять много месяцев и важно сбалансировать затраты на переезд сейчас по сравнению с переездом через шесть месяцев.
Почему так трудно найти хороших старших разработчиков?
Потому что мы не поощряем достаточно младших разработчиков в системе. То, что мы делаем сейчас, неприемлемо в долгосрочной перспективе.
И если не ценить настоящих старших разработчиков, кто будет наставлять новобранцев? Как мы передадим глубокие знания следующему поколению?
Переведено @middle_java
- отсутствие техлида. Формально техлид был. С очень высоким техническим уровнем. Но как руководитель, который мог заниматься ведением и развитием своей группы, он был полный ноль: не умел декомпозировать задачи, распределять их в соответствии с уровнем каждого члена, не занимался обучением группы, контроль деятельности группы осуществлялся в диктаторском режиме, софт скиллы отсутствовали и т.п.
- большой разрыв между скиллами миддла и сеньорами. То, что было непонятно миддлу, приходилось изучать на 95% самостоятельно, потому что у сеньоров не было времени и желания помогать миддлу в обучении, отсутствовало парное программирование (при этом код-ревью было отличным с технической точки зрения), в результате скорость работы миддла не удовлетворяла руководство, хотя качество его кода было высоким.
- отсутствие командного духа. Обстановка в группе была нездоровой, общение не партнерское или менторское, а с унижениями, насмешками, ошибки на этапе разработки были непростительны и т.п.
Одновременно с этим были установлены высокие требования по скорости выпуска продуктов, что с учетом факторов, приведенных выше, приводило к перманентному перенапряжению всех разработчиков.
Послушав этого миддла, я заинтересовался тем, как обстоят дела с балансированием команд разработки специалистами разного уровня, есть ли смысл создавать команды, состоящие из одних сеньоров, и как повышать свой уровень в таких командах на примере компаний из, например, Кремниевой Долины.
В результате я наткнулся на статью, перевод которой приведен под катом.
Прошу участников сообщества привести в комментариях свои мысли, как бы они действовали, будучи в описанной позиции миддла: как обучаться, как вести себя с другими членами команды и любые другие ваши мысли.
Переведено @middle_java
Базовое руководство по созданию сбалансированных команд разработчиков
Согласно опросу разработчиков StackOverflow за 2016 год, участие в программе наставничества сильней коррелирует с зарплатой, чем наличие кандидатской степени, а разработчики больше ценят изучение новых вещей по сравнению с другими мотиваторами, такими, как создание нового, вера в миссию компании и продвижение по службе.
Хорошие наставники могут помочь в решении большинства основных проблем, стоящих перед разработчиками, в том числе:
- Нереалистичные ожидания (за счет понимания того, когда и как сдвигать ожидания и в целом управлять ими, когда процесс управления перестает работать)
- Плохая документация
- Неэффективные процессы разработки
- Слабая кодовая база
Старшие наставники играют в командах разработки незаменимую роль. Но трудно найти настоящих, квалифицированных старших разработчиков с опытом, которые могут нормально руководить командой.
Взгляните хорошенько на свою команду. Есть у кого-нибудь более чем 6-ти-летний опыт создания масштабных промышленных приложений? Чувствуют ли члены вашей команды, что у них есть надежный гид и наставник, который постоянно подталкивает их к совершенствованию своего мастерства?
Если ответы будут «нет», то вы действительно многое упускаете из виду.
Есть много причин, по которым хороших наставников трудно найти и удержать, но все начинается с управления командой. Можно многое сделать для создания гораздо более эффективной и хорошо организованной команды, к которой разработчики будут рады присоединить на долгие годы.
В Кремниевой Долине многие инженеры либо переходят в управление, либо вообще уходят. Это плохо не только для старших разработчиков. Это плохо для работодателей.
Это плохо влияет на командную культуру и настрой. Это плохо сказывается на производительности команды. И это плохо для разработчиков младшего и среднего уровня, которые лишены больших возможностей наставничества.
Если вы занимаетесь разработкой очень долго, то, возможно, чувствовали давление, заставляющее вас перейти в управление. Если вы решили, что вы хотите выбрать именно этот маршрут, эта статья поможет составить представление о том, как построить оптимальную команду и соответствующую ей культуру.
Создание хорошо сбалансированной команды является важным элементом построения высокоскоростной команды разработчиков.
Все начинается с людей
Если вы хотите создать что-то великое, то начните с великих людей. Построить команду — это нечто гораздо большее, чем просто нанять людей с нужными навыками. Это также значит найти людей, которые будут вписываться в остальную команду и балансировать ее.
Для менеджера может быть заманчиво рассматривать других членов команды, как винтики машины. Было бы удобно, если можно было бы поставить их на любую позицию и ожидать, что они будут действовать в соответствии с вашими ожиданиями для этой позиции.
К счастью для всех, настоящие команды работают не так, поэтому ваша первая задача — научиться распознавать в себе соблазн оценивать членов команды по количеству тикетов, которые они закрывают.
Самая большая ошибка, которую я наблюдал у техлидов — определение ценности отдельных членов команды по количеству закрываемых ими тикетов.
Эта ошибка является первопричиной проблемы номер один, с которой сталкиваются разработчики: Нереалистичные ожидания. Когда вы фокусируетесь на подсчете количества закрытых тикетов, вы игнорируете более широкий контекст работы над проектом и нормальную динамику команды, что может привести к катастрофическим результатам: моральной подавленности, высокой текучке разработчиков и снижению продуктивности.
На самом деле существует два различных типа разработчиков, и для достижения оптимальной производительности вашей команде нужны они оба:
- Старшие наставники с глубоким пониманием архитектуры приложений и продуктивности команды разработчиков и способностью обучать этому других.
- Младшие, средние разработчики, а также индивидуальные разработчики, чья работа заключается в разработке нового функционала или исправлении ошибок при ведущей роли своих старших наставников.
Не все индивидуальные разработчики являются младшими разработчиками. Многие из них являются талантливыми старшими разработчиками, которые просто предпочитают фокусироваться на разработке нового функционала и исправлении ошибок, а не погружаться в сложную кухню наставничества, формирования менеджерских ожиданий и лидирования людей.
Культура стартапов в районе залива Сан-Франциско старается объединить всех в группу 2. Это недальновидно и расточительно. Сейчас разберемся почему.
Давайте разберемся с парой определений:
- Старший разработчик (сеньор) — Человек с глубоким пониманием и подтвержденным опытом создания реальных масштабных приложений.
- Младший разработчик (джуниор) — Человек с ограниченным опытом или знаниями, желающий обучаться и повышать свое мастерство.
«Старший» — не значит больше в годах. Я встречал разработчиков с 15-ти-летним опытом, которых я бы классифицировал, как младших разработчиков с точки зрения формирования команд, и других, у которых есть 2-3-х-летний опыт, которым бы я доверил создание нового приложения с нуля.
Тем не менее «старший» — это определенно не то, что происходит за одну ночь, а шкала навыков — это широкий градиент, не что-то бинарное. Ничто не может заменить уроки, полученные за годы работы. В книге Малкольма Гладуэлла «Outliers: The Story of Success» предполагается, что правило 10_000 часов может применяться ко многим навыкам: Чтобы достичь мастерства в своем ремесле, требуется 10_000 часов практики. Это означает, что разработчику требуется около 6 лет практики, чтобы овладеть этим ремеслом. Это звучит для меня абсолютно верно.
Однако просто опыта недостаточно для обеспечения прогресса. В статье «Peak: Secrets from the New Science of Expertise» Андерс Эриксон и Роберт Пул объясняют, что практикующие специалисты должны часто заниматься осознанной практикой, при которой обучающийся постоянно работает на грани своих способностей — это та приятная точка, в которой ощущается и сложность и уверенность.
Плюс к этому, как наставник и учитель, я обнаружил много других аспектов, которые могут радикально улучшить эффективность обучения разработчиков. В частности:
- Совместное / парное программирование
- Код-ревью
- Наставничество один на один
Если вы хотите, чтобы ваша команда совершенствовалась быстро, нужно поощрять эти практики.
Почему вашей команде нужны сильные наставники
Некоторые члены команды отличаются своими знаниями и способностями к созданию архитектуры и служат хорошим примером для остальных членов команды. Когда они вовлечены в эту деятельность, их вклад является фактором умножения эффективности, увеличивающим продуктивность всей команды.
Кроме того, эти участники могут видеть более универсальные решения общих проблем и разрабатывать инструменты, которые помогут остальной части команды быть более продуктивной. (Другие члены команды тоже смогут, но, возможно, не так часто).
Если в команде из шести человек один сотрудник является сильным наставником с коэффициентом умножения эффективности = 2, то это означает, что оставшиеся пять человек выполнят работу десяти. Возможно, вы слышали термин десятикратный разработчик. Наставничество — это самый реалистичный способ внести десятикратный вклад.
Возможно, вы думаете, что моя математика сейчас ошибочна, ведь разве другие участники не заслуживают похвалы за свой однократный вклад? Возможно, некоторые, но все не так просто. Реальное количество разработчиков, которым нужно помочь, чтобы достичь десятикратной производительности, лежит где-то между 5-10.
Давайте копнем немного глубже. Эту часть многим людям трудно понять или оценить в полной мере:
Младший или средний разработчики в состоянии закрывать тикеты. Может быть даже быстро. Однако младшему разработчику не хватает видения и опыта, чтобы понять, как тот технический выбор, который он делают сегодня, повлияет на продуктивность всей команды в будущем. Другими словами, безнадзорный младший разработчик может быть дробным фактором эффективности, что создает помехи для производительности всей команды.
Оставленные без присмотра младшие разработчики будут выпускать быстрые фиксы в общем направлении по каждой проблеме, с которой они сталкиваются, регулярно упуская первопричины, часто повторно вызывая проблемы и пожары, и оставляя после себя кучу технических долгов.
Младшие разработчики также часто борются со сложными проблемами, отвлекая для помощи других разработчиков от их работы.
Разработчики среднего уровня (как правило, с 2-5-ти-летним опытом работы. Это то, что во многих вакансиях в районе залива называется «старшими») придумают рабочие решения сложных технических вопросов, но эти решения, как правило, будут сложными сами по себе и трудными для понимания другими членами команды, что также создает нагрузку на продуктивность команды.
Опытные старшие разработчики часто придумывают обманчиво простые решения сложных проблем и учат других разработчиков делать то же самое.
Так что, не надо нанимать младших разработчиков, верно? Не верно. Младший разработчик может быть очень умным и быть очень хорошим учеником. Просто отсутствие опыта и понимания создает отрицательное сопротивление.
В среде наставничества с частым парным программированием и код-ревью, даже начинающие разработчики быстро становятся отличными участниками.
Но прием на работу младших разработчиков без привлечения к их ориентированию старших наставников — это все равно что закладывать бомбы замедленного действия по всей кодовой базе.
Настоящая опасность
Когда команда разработчиков сталкивается с проблемами производительности и большими техническими долгами, возникает соблазн обвинить в этом отдельных разработчиков.
«Этот разработчик закрывает 1/5 от тех тикетов, которые закрывает другой, так что ясно, что в этом проблема, верно?» Не верно.
Первопричиной технического долга является ориентация менеджмента на краткосрочную микропродуктивность в ущерб долгосрочной макропродуктивности. Когда вы позволяете побочному продукту накапливаться достаточно долго, в конце концов он засорит механизм.
Менеджеры часто ошибаются, думая, что скорость обработки тикетов может быть использована для оценки эффективности отдельных участников. Это просто неправда.
Люди не работают в вакууме. Они работают друг с другом. Ваши самые знающие сотрудники быстро станут теми наставниками, к которым все обращаются с вопросами, и это хорошо.
Этот наставник/старший разработчик отвечает за поддержание механизма чистым и хорошо смазанным, предотвращая засоры, которые пустят под откос всю команду.
Но старшие наставники не закрывают много своих собственных тикетов. Вместо этого они будут сосредоточены на код-ревью, разблокировке остальной части команды, когда она столкнется с новыми проблемами, и работе над оптимизацией долгосрочной продуктивности всей команды.
Дело в том, что инженерные лидеры должны понимать, что ваши самые продуктивные члены команды часто закрывают наименьшее количество тикетов.
Множители усилий в команде будут терять время (и ваше, и остальной команды), если они будут действовать как индивидуальные разработчики, пытаясь быстро закрыть свои собственные тикеты.
Вам не нужно, чтобы ваши наставники быстро закрывали тикеты. Вы не хотите, чтобы ваши наставники быстро закрывали тикеты. Последнее, что вы хотите сделать в качестве инженерного руководителя, это оказать на них давление для этого.
Вам нужно, чтобы они помогли остальным разработчикам научиться разрабатывать приложения таким образом, чтобы команда в целом поддерживала более плавную скорость.
Стартапы в Заливе правильно придают большУю ценность скорости и гибкости, но там совершенно не понимают, как построить культуру, где скорость и гибкость процветают естественным образом.
Они слишком сосредоточены на закрытии конкретных тикетов сегодня, вместо осознания того, что именно культура обучения и наставничества обеспечит долгосрочное здоровье и стабильность совокупной скорости и продуктивности команды в будущем.
Если вы хотите определить ценность старшего разработчика или наставника, вместо того чтобы смотреть на индивидуальную скорость обработки тикетов, спросите других разработчиков в команде, насколько полезен этот наставник.
Еще один отличный способ убедиться в том, что ваши наставники работают продуктивно — это посмотреть на их деятельность по код-ревью. Они должны проводить много код-ревью, полных отличных советов о том, как код может быть улучшен конкретными способами на архитектурном уровне.
Неопытный рецензент больше сосредоточен на несущественных стилистических вопросах (точки с запятой, заглавные буквы, пробелы и т. д.). Великий наставник будет обучать концепциям разработки программного обеспечения, не подверженных влиянию времени, шаблонам проектирования и тому, как писать код, который легче читать и поддерживать другим разработчикам.
Почему каждая компания хочет иметь старших разработчиков
Каждая компания хочет иметь «старших» разработчиков, потому что правильно считается, что старшие разработчики будут лучше понимать, как написать приложение, которое само по себе будет устойчивым к меняющимся требованиям заказчиков и менеджеров продуктов.
Старшие разработчики сами по себе менее склонны создавать горы технических долгов, поскольку они закрывают тикеты и большинству из них требуется меньше усилий, чтобы быстро освоиться с новой кодовой базой.
Почему мало у каких стартапов есть настоящие старшие разработчики
Стандарты того, что подразумевается под «старшим разработчиком», с годами изменились. Когда я только начинал работать профессиональным программистом, очень часто приходилось видеть вакансии на старшие позиции, требующие минимум 5, 7 или 10 лет опыта.
Сегодня в Сан-Франциско вы увидите аналогичные позиции, требующие минимальный опыт работы 2-3 года. Отчасти причина этих изменений заключается в том, что на рынке труда ощущается нехватка разработчиков, которые не только обладают требуемым опытом в годах, но и знаниями и умениями, необходимыми для выполнения этой работы.
Но вакансии все еще не закрыты. Поэтому мы нанимаем людей с чуть меньшим опытом, называем их «старшими разработчиками» и надеемся, что все получится. Не получится.
Как я уже упоминал, опыт — это еще не все, но когда речь заходит о роли старшего наставника, опыт все равно имеет большое значение. Есть вещи, которым нельзя научиться, кроме как прожив жизнь.
Между старшим разработчиком на бумаге и реально старшим разработчиком действительно большая разница. Разработчик с 3-х-летним опытом не имеет реального жизненного опыта создания нескольких промышленных масштабных приложений. Он просто не работал на достаточном количестве ролей достаточно долгое время, чтобы увидеть, как это происходит более одного или двух раз.
Это означает, что он не знает всех или даже наиболее распространенных проблем, с которыми сталкиваются команды разработчиков.
Вы можете наполнить океан теми вещами, о которых 3-х-летний разработчик даже не подозревает, что он их не знает.
Но мы все равно их нанимаем. Потому что они отлично справляются с разработкой всяких штук и исправлением ошибок, а этого почти всегда достаточно на какое-то время.
Почему большинство компаний изо всех сил пытаются удержать старших разработчиков
Как я только что объяснил, многие «старшие» таланты, нанятые в районе залива Сан-Франциско, на самом деле не являются старшими. Это менее опытные разработчики, готовые работать за гораздо меньшую зарплату, чем настоящие старшие разработчики, которые в Сан-Франциско рассчитывают заработать более 150 тысяч долларов США в год.
Трехлетний разработчик будет счастлив, зарабатывая 130 тысяч долларов США в год. Медианная зарплата разработчика в Сан-Франциско составляет чуть более 110 тысяч долларов США в год.
(Замечание для неместных: это выглядит как будто много, но в Сан-Франциско вы не разгуляетесь после того, как заплатите аренду за жилье).
Многие технические основатели в районе залива сами молоды. Когда вы молоды и свободны от привязанностей, вы можете позволить себе делить квартиру с четырьмя соседями по комнате и приносить домой небольшую зарплату, пока вы бегаете в поисках финансирования и пытаетесь нанять других людей.
Молодому основателю может показаться безумным нанять «недосягаемого» разработчика за ту же цену, которую он заплатит за двух менее опытных «старших» разработчиков, а для CEO может показаться возмутительным платить старшему разработчику больше, чем он сам будет приносить домой. Молодые стартапы обычно рассматривают зарплату настоящего старшего разработчика как «дорогую».
По иронии судьбы, что действительно дорого, так это управлять командой без хороших наставников. Наставники повышают ROI (рентабельность инвестиций) всей вашей команды разработчиков.
Корпоративная культура компаний Сан-Франциско часто ориентирована на молодых работников, включая изнурительный режим и частые мероприятия во внерабочее время, такие как вечеринки, ужины, выпивания, вечерние викторины, турниры по пинг-понгу и барбекю. Сотрудники с семьями часто не чувствуют себя частью компании, когда они решают вернуться домой к семьям вместо того, чтобы посещать такие мероприятия.
Работа в молодом стартапе — не единственный вариант для старших разработчиков. Опытные компании, такие как Adobe, Google, IBM и Microsoft, ценят таланты старших разработчиков и готовы платить за это премии.
Google, как известно, заманивает разработчиков успешных приложений компенсациями в миллионы долларов.
Microsoft признает, что ей нужны как старшие, так и младшие разработчики и агрессивно набирает и тех и других.
Некоторые старшие разработчики разочаровываются в рынке труда района залива и уходят оттуда, предпочитая создавать собственные приложения или небольшие агентства по разработке программного обеспечения.
Другие просто недоумевают, почему стартапы в Долине их недооценивают и изо всех сил пытаются найти работу.
Почему каждой компании нужны младшие разработчики
Когда вы относитесь к каждому разработчику, как к старшему разработчику, которому вы можете доверять в условиях его полной самостоятельности, в итоге вы получаете команду, в которой сотрудники не могут учиться друг у друга и расти совместно в навыках и производительности.
Когда вы нанимаете младших разработчиков, вы воспринимаете как должное, что нужно создавать культуру обучения, чтобы была возможность развивать младших разработчиков и распределять опыт по всей команде.
Эта культура увеличивает объем парного программирования, ведет к более тщательному и продуктивному код-ревью (в отличие от тривиальной придирки к мелочам) и гораздо меньшему изолированию знаний.
Когда члены команды часто занимаются обучением друг друга, это убирает из головы их индивидуальную работу, что дает лучшее представление о том, как их работа вписывается в более широкий контекст приложения.
Одна из больших проблем, с которыми сталкиваются команды разработчиков, заключается в том, что индивидуальные разработчики, как правило, специализируются на небольшой области приложения (что приводит к повышению продуктивности, когда они работают в этой области). Но они делают это ценой снижения продуктивности, когда другие члены команды пытаются работать над этой частью приложения.
Помимо этих преимуществ, команды нуждаются в младших разработчиках, потому что никто не сообщил младшему разработчику, что существует что-то невозможное. Они возьмутся за невозможное и иногда смогут найти решение, и они не завязнут со словами «мы всегда так делали.»
Возможно, самая важная причина для найма младших разработчиков заключается в том, что трудно найти старших разработчиков, которые действительно знают, что они делают. Охота за хорошим старшим разработчиком может занять много месяцев и важно сбалансировать затраты на переезд сейчас по сравнению с переездом через шесть месяцев.
Заключение
Почему так трудно найти хороших старших разработчиков?
Потому что мы не поощряем достаточно младших разработчиков в системе. То, что мы делаем сейчас, неприемлемо в долгосрочной перспективе.
Если все нанимают только старших разработчиков, то откуда берутся новые старшие разработчики?
И если не ценить настоящих старших разработчиков, кто будет наставлять новобранцев? Как мы передадим глубокие знания следующему поколению?
Переведено @middle_java
