Как распределять способности между командами?

9

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

Морган Херлокер
источник
Похоже на это: programmers.stackexchange.com/questions/76890/… .
S.Lott
@Lott Похоже, но это относится к проверке чрезмерно доминирующего разработчика, если я правильно помню.
Морган Херлокер
2
Большинство приличных систем персонажей позволяют вам периодически перераспределять очки талантов.
FrustratedWithFormsDesigner
1
Извините, слишком много Mass Effect 2 (и других игр) в эти дни. : P
FrustratedWithFormsDesigner

Ответы:

11

Есть несколько известных рисков с A-командами, но если динамика будет правильной, то я думаю, что да, я бы поставил своих самых сильных людей на самые важные проекты вместе с младшим разработчиком (ями) с наибольшим потенциалом. Для ваших проектов с более низким приоритетом вам нужен хороший лидер команды, если это вообще возможно, чтобы они не уходили далеко от рельсов. Технический долг случится несмотря ни на что. Не весь технический долг равен; стоимость / ответственность технического долга в первую очередь пропорциональна деловой ценности проекта, поэтому, хотя у ваших проектов с более низким приоритетом может быть больше бородавок, их стоимость, вероятно, все еще намного меньше, чем существенные проблемы в ваших приоритетных проектах. быть.

Джереми
источник
7

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

По сути, история пошла следующим образом:

Группа программистов была разделена на группы по способностям: худшие программисты были сгруппированы вместе, следующие - сгруппированы вместе и т. Д., А самые лучшие - сгруппированы вместе.

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

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

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

Эд Джеймс
источник
1
Да, это одна из основных проблем A-Team, но сделать вывод, что это универсально применимо ко всем командам, основанным на этом исследовании, было бы ошибкой.
Джереми
Согласен: не все одинаковы, равно как и эквивалентные группы не будут иметь одинаковую динамику, но, тем не менее, это хороший анекдот!
Эд Джеймс
1
Ну, соберите кучу разработчиков, которые все пишут только алгоритмы поиска пути, и это то, что вы получаете ...
Стивен Эверс
лол - вы не можете найти газету, скорее всего, потому что профессор только что придумал историю на месте. ;-)
Стивен А. Лоу
Это не удивило бы меня: D
Эд Джеймс
3

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

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

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

Карл Билефельдт
источник
Из вашего первого абзаца я могу только предположить, что вы не работаете в среде, где спрос на разработчиков превышает предложение. Многие из нас делают. :-)
Carson63000
3

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

Кроме того, что произойдет, если опытные люди решат уйти? Кто возьмет свои проекты?

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

Ладислав Мрнка
источник
3

Те, которые не могут научить, делают ...

Я думаю, что есть больше факторов, чтобы рассмотреть.

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

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

dietbuddha
источник
Я согласен, но в то же время вы можете учиться из кода, написанного другими разработчиками. Если старшие разработчики не являются частью вашей команды, вы не можете учиться у них таким образом.
Ладислав Мрнка
@Ladislav Mrnka: Я не говорю, что вы не должны распределять старших разработчиков по различным командам. Способность учиться на коде будет отличаться. Это также предполагает, что разработчикам потребуется время для изучения кода, который многие не делают.
dietbuddha
2

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

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

Джим С
источник
1

С другой стороны, я думаю, что имеет смысл сохранять команды, которые могут «идти в ногу» друг с другом. Программисты типов A-Team не хотят ждать, пока типы B-Team выполнят свои задачи. Типы вашей B-Team могут быть сопоставлены с рабочим процессом в стиле A-Team.

Уайетт Барнетт
источник