Сколько одновременных проектов может выполнять старший разработчик за один раз?

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

В настоящее время у меня есть предложение для модели:

Младшие разработчики - будут работать только по одному проекту за раз (причина: в основном, что они не могут контролировать свое использование времени).
Промежуточные разработчики - будут работать в основном по одному проекту за 50% и более, но могут быть 50-50 по двум проектам
Старшие разработчики - будут работать максимум по 3 проектам одновременно; процент может быть, например, 50%, 30% и 20%.

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

Вопрос в том, может ли старший управляет 3 проектами за один раз (он будет нанят с учетом этого - я не обману, чтобы кто-то поверил, что они будут писать код в 100% случаев и в итоге на 20%), или это слишком много? EDIT: пожилых людей, которых я планирую использовать для наставников, не ожидается, что они вообще будут кодироваться. Они будут сосредоточены на наставничестве и обучении, например. в новых и будущих технологиях.

У меня такое ощущение, что 2 проекта лучше, чем 3? Или? Что, если старшему нужно 50% на "младший проект" и 30% на анализ и дизайн на другой проект. Может ли он справиться с еще одним проектом с последними 20%?

(И нет времени для обучения, кофе и т.д. не будет частью 100%. Я уже сократил "реальный" объем рабочего времени с учетом этого).

Ответ 1

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

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

P.S. Это также помогает держать старших людей от скуки.

P.P.S. Группа молодых людей - это верный рецепт катастрофы. Вам нужно получить хотя бы одного старшего рабочего времени на каждый такой проект.

Ответ 2

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

Я могу наставником и тренером 5-10 других проектов без каких-либо проблем. Зависит от глубины участия.

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

Ответ 3

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

Что касается вашего конкретного вопроса, я думаю, что неразумно, чтобы люди работали сразу на нескольких вещах; проекты могут тянуть людей в том или ином направлении, и баланс "50/50" или "33/33/33" никогда не произойдет в действительности. Проблемные проекты или назойливые менеджеры получат 100% ресурсов, которые они хотят.

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

Ответ 4

Это зависит от человека. Зная природу программных проектов, дерьмо БУДЕТ поразить поклонника рано или поздно, и когда все три старших проекта становятся кислыми одновременно, и три команды юниоров кричат о руководстве, как вы поможете своему старшему руководителю

Ответ 5

Это действительно зависит, если вы хотите наивысшего качества за наименьшее количество времени, тогда ответ один.

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

Ответ 6

Есть цитата, в которой говорится, что 9 женщин не могут произвести ребенка через месяц.

Я думаю, что это применимо здесь. Если разработчик разбивает свое время на 50/50 по двум проектам, могут ли проекты планироваться так, чтобы разработчик работал на 100% на одном, а затем, когда он закончил работу на 100% на втором?

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

как обычно, "это зависит"

это зависит от сложности проекта; действительно сложные проекты/проблемы могут, как правило, поглощать каждый бодрствующий момент старших разработчиков независимо от того, какое теоретическое распределение планируется; некоторые проблемы просто сложны (или действительно действительно интересны).
это зависит от старшего разработчика - некоторые могут процветать только на роль наставничества, другие могут впадать в депрессию, если не разрешают код
это также зависит от качества младших команд -
- юниоры, которые задают старшим каждый маленький вопрос, который появляется в их головах ( "как мне закодировать цикл в java? почему мой браузер MessageBox не отображается в браузере?", который я звоню, чтобы установить Интернет на моем компьютере "что мой пароль?" ) собираются истощить мозг даже самого терпеливого и доброжелательного старшего,
- в то время как юниоры, которые должны выяснить все для себя, будут спокойно позволить проекту умереть, пока они бьют головой опечатку, которые они... просто... не... видят.

Короче говоря, все старшие разработчики не равны (например, для младших/средних), лучше поговорить с каждым отдельно и построить совместимую команду для каждого проекта. Что является лучшей стратегией: предоставление клиенту цены, которая привлекательна, или предоставление команды, которая может выполнять эту работу? Понимание того, что все программисты взаимозаменяемы, является огромной частью проблемы офшоринга в США, но если вы упаковываете кучу юниоров по выгодной цене, вы продолжаете это восприятие и, вероятно, побеждаете свою заявленную цель. Лучше делать работу правильно или вообще не для долгосрочной жизнеспособности.

Ответ 10

Исследования в дизайне кабины самолета показывают, что люди могут одновременно выполнять 5 + или - 2 задачи. В идеале вам нужно держать его ниже 5, чтобы не допустить, чтобы пилот потерял контроль над ситуацией. Я думаю, что этот принцип хорошо воплощается во всем: от дизайна графического интерфейса до управления задачами на других рабочих местах.

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

Ответ 11

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

Ответ 12

Я бы сказал, что столько, сколько вы можете поместиться на жесткий диск. Хотя это субъективно, потому что вы просто ныряете с кем-то временем/усилиями между проектами.

Ответ 13

Я полностью согласен с ответом Ильи. Переключение контекстов или задач резко снижает производительность. Джоэл написал интересный article об этом явлении на своем веб-сайте.