Эффективно ли «хирургическая бригада» Фреда Брукса справляется с автобусным фактором?

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

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

За три дня, с тех пор как мы начали работу, я заметил две вещи:

1. Другие неопытные члены команды выполнили около 1 или менее задачи каждый.

2. Закон Брука в действии: я потратил около половины своего времени на оказание помощи (пытаясь научить их использовать компоненты). В результате я только закончил 2 задачи самостоятельно, вместо ожидаемых 5 или 6.

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

1. Ограничьте фактор грузовика / автобуса - накапливая эти навыки у других разработчиков сейчас, чтобы в будущем любая работа могла быть отдана кому угодно, а не только мне.
2. Устранить «узкое место» (меня) и сделать работу быстрее.

Чтобы быть ясным, у меня нет проблем с: а) тратить время на обучение, б) люди, касающиеся моего кода, или в) обеспечение работой. Фактически, я регулярно советую руководителю группы обучать других разработчиков определенным аспектам базовой кодовой базы, чтобы снизить риск.

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

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

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

Подобные вопросы:

• Как увеличить шинный фактор и одновременно специализироваться?
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

На самом деле, я бы сказал, что вы следуете модели «хирургической команды». Счастливчик!

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

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

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

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

Опыт - это просто имя, которое мы даем нашим ошибкам.

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

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

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

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

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

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

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

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

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

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

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

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

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