Как сделать дело для дорогих программистов?

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

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

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

Разница в том, что опытные программисты создают меньше ошибок, а их код более стабилен и т. Д. Начинающие программисты тратят много времени на всех остальных (PM, клиенты и т. Д.). Но они значительно дешевле.

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

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

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

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

После 6 месяцев основного проекта, я занял пост менеджера по развитию. Как только я исправил несколько гигиенических факторов, проблема качества кода осталась. У меня был некоторый запас бюджета и я нанял очень опытного программиста (ну, скорее, архитектора решений) с неординарными навыками общения и прошлой жизнью тренера по C # (язык, на котором был написан проект). Идея состояла в том, чтобы улучшить качество других кодеров, предоставляя наставничество и фактически бесплатное обучение.

Через месяц или два стало до боли очевидно, что даже это не сработает, поэтому первоначальная команда была удалена из проекта и добавлена ​​еще пара программистов высшего уровня. Они представили проект, который оригинальная команда полностью не смогла выполнить за 8 с лишним месяцев попыток в 3 месячных спринтах, начиная с нуля, потому что исходный код был неисправим.

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

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

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

TL; DR Хорошие программисты - сделка. Трудно найти их и создать достаточно привлекательную рабочую среду, чтобы сохранить их.

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

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

В крайнем случае, найдите фотографию Red Adair , известного пожарного, которого вызвали в крупной катастрофе после нескольких неудачных попыток менее опытных парней. Его знаменитая цитата:

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

... заслуживает того, чтобы быть напечатанным в цвете и размещенным на видном месте на двери вашего офиса, чтобы все понимали, о чем это все ;-)

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

Во-первых, в ответе Маккоттла подразумевается тот факт, что ниже определенного уровня квалификации некоторые проблемы просто невозможны. К сожалению, способ, которым вы узнаете это, - ваша команда пытается и терпит неудачу, что оченьдорогой. После неудачи, есть два возможных урока, чтобы извлечь из этого. Один из вариантов - вы узнаете, что вам нужно больше компетентных разработчиков, и поэтому вы нанимаете их, и вы выполняете проект значительно сверх бюджета и по графику, но, по крайней мере, вы готовы в будущем. Другой вариант заключается в том, что такой проект «слишком сложен» для вашей команды, и такие вещи не следует предпринимать в будущем, т. Е. Вы отказываетесь от проекта и, по сути, от любых подобных. Конечно, это редко будет формулироваться как «мы слишком глупы, чтобы делать это», но вместо этого будет рационализировано как «наши системы очень сложны» или «у нас много устаревшего кода» или некоторых других. Этот последний взгляд может существенно изменить взгляд компании на то, что возможно и как долго / дорого должно быть развитие. "

Вопрос в том, каков план вашей компании? Хорошо, они будут нанимать дешевых младших программистов. Прошло три года, что теперь? Что они делают с разработчиком, который был с ними в течение этих трех лет? Они просто никогда не давали ему / ей повышение? Варианты здесь следующие:

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

Вторые два случая подразумевают значительную текучесть кадров, что означает потерю знаний компании и постоянную оплату наемным работникам. Во втором случае вы, по сути, выбираете плохих разработчиков, и поэтому затраты будут расти в виде увеличения графика. В этом случае все будет хорошо в проекте X, пока вдруг Джим не уйдет, кто был одним из лучших разработчиков, потому что он не получил повышение в течение двух лет, теперь «по понятным причинам» проект займет значительно больше времени, так как вам нужно нанимать и обучать новых младших разработчиков, которые (по-видимому) не будут так хороши, как Джим. Это то, как вы перекалибруете ожидания.

Даже в том случае, если предоставляются конкурентные повышения, если все, что у вас есть, это младшие разработчики, где и как они должны учиться? В основном вы надеетесь, что один из них самостоятельно изучит передовой опыт, несмотря на свою рабочую среду, и в конечном итоге станет наставником для других (в отличие от ухода на более зеленые пастбища). Было бы гораздо больше смысла «заправлять насос» некоторыми хорошими разработчиками. Скорее всего, вы будете развивать культуру начинающих экспертов . В результате вы в конечном итоге будете платить старшим разработчикам людей, которые лишь немного лучше, чем младшие разработчики и культурно токсичны.

Я удивлен, что никто другой не упомянул одно преимущество, особенно очень хороших разработчиков, - они могут легко стать мультипликативным фактором. Вполне может быть, что младший разработчик и старший разработчик тратят одинаковое количество времени на создание таблицы. Однако хороший разработчик этого не сделает. Они создадут генератор таблиц, который сократит время на то, чтобы каждый мог создать стол. Альтернативно / дополнительно, они поднимет потолок того, что возможно для каждого . Например, разработчики, которые внедрили Google MapReduce Framework, были, вероятно, чрезвычайно квалифицированными, но даже если пользователиMapReduce совершенно не в состоянии сделать массово распределенную версию своего алгоритма самостоятельно, теперь они могут легко с MapReduce. Часто эта динамика менее вопиющая. Например, улучшенные методы контроля версий, тестирования и развертывания делают всех лучше, но отследить конкретного человека может быть сложнее.

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

Это не та или иная ситуация.

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

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

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

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

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

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

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

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

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

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

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

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

Теперь, очевидно, рынок может ошибаться, может быть, его 3,5 или 5x, но если вы не цифровое агентство, конкурирующее с рынком или что-то подобное, неважно.

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

Ваш второй вопрос PM против разработчика бюджета. Я бы сказал, что разработчик может обойтись без PM, но PM не может обойтись без разработчика. Сначала рассортируйте ваш движок разработки, а затем попросите премьер-министра забрать администратора из своих рук.

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

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

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

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

1. Они точно оценили, насколько сложным является программное обеспечение, которое вы создаете? Похоже, они не думают, что вы делаете очень сложно, так зачем нанимать лучших людей? Вы сделали случай, когда ошибки сделаны и как лучшие решения и производительность могли бы приносить деньги? Экономия времени - это здорово, но многие компании предпочитают тратить целую неделю на программиста, а не тратить деньги на покупку коврика для мыши.
2. Ваша компания привлекательна для хороших программистов? Способны ли они идентифицировать их? Нет ничего хуже, чем нанять старшего разработчика, заплатить им больше денег, и они затягивают всю команду из-за недостатка навыков и / или лидерства.
3. Может ли ваша компания использовать хорошего программиста? Если все, что они собираются сделать, - это бросить на них дрянные спецификации и просто сказать им, чтобы они просто пошли и создали его, какой смысл? Собираются ли они дать им свободу делать вещи по-своему? В конце концов, хороший программист по определению знает, как лучше использовать свое время. Они влияют на окружающих и улучшают работу других программистов. Они внедряют лучшие дизайны и архитектуры, которые основаны на том, чтобы сделать продукт намного лучше.

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