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

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

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

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

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

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

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

EDIT: улучшен последний абзац. Спасибо комментаторам за указание на нежелательные интерпретации того, что я написал.

Вы не знаете.

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

у меня и моего менеджера разные ожидания от хороших разработчиков.

Вы не можете иметь только 10 сотрудников. Вам нужно 7s-8s, чтобы не отставать от вещей. Вам решать, как вы используете имеющийся талант. Если вы слишком разборчивы, вы получите магазин для 1 мужчины/женщины. Однако, если вы считаете, что наемные работники — это ерунда, вам нужно обратиться с этими проблемами к вашему менеджеру.

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

Это нелепо. Как вы ожидаете, что 3 разработчика будут идти в ногу с развитием, которое ожидается от команды из 14 человек? Это не имеет никакого смысла.

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

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

Излишне говорить, что динамика команды далеко не сбалансирована. 2 взрослых, 1 средний уровень, 11 юниоров.

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

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

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

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

Он даже пропагандирует «равноправное программирование».

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

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

Как разработчику легко неэффективно работать, если ему не назначены задачи разработки. Задумывались ли вы о том, что люди могут быть «недоученными», потому что они не получают нужного им обучения?

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

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

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

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

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

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

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

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

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

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

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

Промежуток времени это было 2 года. У некоторых парней это повторяющийся процесс, и я не думаю, что они сократят его в долгосрочной перспективе. Они не знают, как задавать правильные вопросы, и я не вижу, чтобы они пытались, потому что нет «настоящих» последствий.

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

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

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

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

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

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

Я сделал перевод в другой дивизион, потому что сейчас ситуация мешает моему постоянному росту.

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

В похожей ситуации находятся и топовые разработчики.

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

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

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

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

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

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

Во-первых, 2 сениора — это даже не половина того числа, которое я ожидал бы от того, чтобы тренировать 11 юниоров. Один сениор в среднем может справиться с 1 мидом и 2 юниорами. Действительно хороший тимлид в лучшем случае может справиться с 2 мидами и 3 джуниорами, и ваш личный вывод кода для него резко уменьшится. Однако именно так вы создаете большие команды. Неважно, какой у вас технический стек, просто не хватает программистов старшего и среднего уровня с опытом работы в вашем технологическом стеке, и их не будет, пока вы их не обучите и не сделаете все необходимое, чтобы их удержать.

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

Во-вторых, только по тому, как вы описали вещи, я могу сказать, что ваши истории слишком велики. Вам нужно разбить их на более мелкие, более управляемые размеры. История, на выполнение которой у программиста среднего уровня уходит более 3 дней, почти всегда можно разбить на более мелкие, более простые для понимания требования. Я стараюсь, чтобы средняя история равнялась примерно 1 дню работы инженера среднего звена. Не бойтесь иметь истории, которые зависят от завершения других историй, прежде чем их можно будет начать, чем больше вы разбиваете вещи, тем легче держать всех накормленными историями, в которых зависимости уже завершены, ветки функций появляются очень быстро. полезно для этой цели. Кроме того, то, как написаны истории, имеет огромное влияние. Самый удачный подход I'

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