Я разработчик программного обеспечения и в настоящее время с радостью возглавляю свою команду, состоящую из одного... меня.
Проблема в том, что мои обязанности и объем работы начинают раздуваться, и я боюсь, что вскоре они станут неуправляемыми и пострадает качество работы. Я твердо верю, что смогу создать команду для этого.
Я полагаю, вопрос заключается в том, как бы вы представили своим директорам, что, по вашему мнению, вы можете эффективно выполнять свою работу и создавать лучшие продукты, которые нужны вашей команде из одного человека для роста?
Вы просите нас считать само собой разумеющимся, что увеличение рабочей силы — это хорошая идея. По причинам, которые я опишу ниже, я ранее считал, что рост команды в ответ на «раздувание» рабочей нагрузки часто является первым признаком проблем. Если бы я был на вашем месте, я бы попытался поговорить со своим менеджером о том, почему работа раздувается, и попытаться выработать некоторые четкие спецификации программного обеспечения, варианты использования, тесты и планирование функций, которые должны охватывать область работы. это должно быть вашей ответственностью. Если вы можете работать с вашим боссом, чтобы ограничить и ограничить незапланированный рост проекта, ограниченный продукт обычно будет намного лучше.
Мне нравится думать об этом как о городе, сажающем несколько деревьев вдоль тротуара Мейн-стрит. Вы можете позволить дереву расти беспрепятственно, и в этом случае оно может сломать кучу тротуаров и потребовать от вас нанять группу людей для поддержания побочных эффектов роста. Или вы можете привязать молодое деревце к столбу и направлять его рост с помощью сурового и безжалостно жесткого плана развития — и вы получите красивые прямые деревья с меньшим риском поломки тротуара.
Более того, в некоторых широко цитируемых книгах по передовому опыту в области программного обеспечения, таких как «Мифический человеко-месяц» и « Peopleware », часто описывается как заблуждение, что добавление большего количества рабочей силы к программному проекту даст хорошие результаты.
Очевидно, что существуют ограничения возможностей, связанных с тем, что может сделать один человек. Но выяснить, когда и как расширить команду, не так уж и просто — и расширять команду только потому, что разработчик (или группа) «чувствует, что» работа становится неподдерживаемой, — не всегда хорошая идея.
Без архитектурного плана того, как работа будет расти и меняться в будущем, добавление большего количества поваров на кухню обычно создает проблемы. Во-первых, первоначальная стоимость нового человека обычно намного выше, чем предусмотрено в бюджете. Здесь я имею в виду прием и обучение новых людей. И даже после того, как человек набирает обороты и начинает добавлять чистый положительный эффект производительности (несколько месяцев спустя), у вас появляется дополнительный канал связи, который снижает общую производительность каждого — и у вас есть дополнительные управленческие накладные расходы.
В общем, поскольку существует N*(N-1)/2 двусторонних соединений между N людьми, это означает, что накладные расходы на связь растут пропорционально квадрату размера команды. Часто управленческая бюрократия растет с той же скоростью или даже быстрее. Вскоре первоначальные аргументы о нехватке рабочих часов будут усиливаться в цикле обратной связи, в результате чего добавление людей для уменьшения давления рабочей нагрузки, таким образом, вызовет достаточное давление новой рабочей нагрузки, чем предельная ценность нового члена команды будет слишком низкой (или даже отрицательной!) сделать это.
Многие люди наивно думают, что это происходит только тогда, когда вы говорите о масштабных проектах НАСА с сотнями инженеров. Но на самом деле это может произойти и в команде всего из 2-5 человек. Все зависит от инфраструктуры, потребностей разработки и архитектурного плана того, для чего нужны программные роли.
Я бы сказал, чтобы прочитать две книги, упомянутые в верхней части этого ответа. Подумайте о том, как вы могли бы «спроектировать» план атаки для проекта, каким вы его видите сейчас, стараясь учесть как можно больше различных (возможно, непредвиденных) направлений будущего роста. Почитайте об ошибках планирования . А затем попытайтесь синтезировать все это в действенный план развития команды.
Тулли2003
Майк