Как объяснить издержки общения между разработчиками в команде?

Question

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

Answer 1

Все зависит от того, кто ваша аудитория.

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

Вот схема того, как это будет выглядеть:

Answer 2

Попросите менеджера проекта представить себя в конференц-зале. Ее попросили спроектировать автомобиль с нуля, вплоть до последнего болта, за 10 недель. Если мы поместим в комнату еще 9 человек, закончится ли дизайн за одну неделю? Вероятно, нет.

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

Answer 3

Если руководителю проекта нужно это объяснить, тогда есть большая проблема. Недостатком эффективности команды является общение, контроль и координация. Вы можете легко объяснить, что от 1 до 2 человек - необходимый контроль кода, координация продвижения, точки интеграции и общий подход к проекту / кодированию - переход с 4-5 немного сложнее - это масштаб командных изменений, который действительно вопросы (переход от 150 к 151 мало влияет) ... узнайте подробности, получите предварительную историю в вашей компании в отношении проектов для одного человека для командных проектов - основывайте ответ на конкретных показателях, если можете.

Вот хорошая статья для справки:

• http://www.stevemcconnell.com/articles/art06.htm - меньше - больше

Answer 4

Давайте вынесем рамки проекта

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

Так, чтобы использовать известную цитату

Команда должна быть быстрой, но не спешить

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

Answer 5

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

i.e., Adding people to a late project will only make it later.

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

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

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

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

Answer 6

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

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

Answer 7

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

Управление двумя разработчиками похоже на то, что А разговаривает с B, а B разговаривает с A. Добавление C даже нормально, так как разговор достаточно мал, чтобы каждый мог идти в ногу.

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