В чем преимущества разделения времени разработчика между двумя проектами?

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

Я думаю, что лучше всего иметь 2-3 текущих проекта; один основной и 1-2 других проекта, которые не являются такими строгими временная шкала.

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

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

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

"мы оставим для позже", много раз, не является приемлемым ответом, хотя это приводит к задержкам для обоих проектов.

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

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

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

Если вы идете, что в Великой и святой книге "peopleware",вы должны держать своего программиста на одном проекте за раз.

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

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

надеюсь, что помогает :)

• LM

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

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

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

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

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

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

таким образом, с точки зрения развития 1 является лучшим вариантом, но с точки зрения обслуживания клиентов 2, вероятно, лучше.

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

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

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

в конечном счете, хотя, если у вас есть один ресурс, то у вас естественным препятствием.

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

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

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

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

1. специализация: выполнение или консультирование по работе, требующей аналогичных специализированных знаний в обоих проектах.

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

3. Лучшее использование команды: в редких случаях, когда один из проектов временно приостанавливается в ожидании дальнейшего ввода.

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

наличие разработчика для работы в одиночку над несколькими проектами разработки программного обеспечения сводит на нет преимущества специализации (в данном случае их нет), согласованности и обмена знаниями.

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

переключение контекста-очень интересный зверь: вопреки его названию, подразумевающему осторожное изменение, процесс всегда постепенный. Есть различные степени наличия контекстной информации в голове: 10% контекста (мелкий), 90% (глубокий). Оно принимает меньше времени отмел-переключает в отличие от fully-switch; однако существует прямая корреляция между количеством загруженного контекста (концентрация на задаче) и качеством вывода.

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

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

предположим, что оценка для обоих проектов составляет 3 месяца каждый. Делая это последовательно, один за другим, вы сможете доставить первый проект через 3 месяца, второй проект через 3 месяца (т. е. через 6 месяцев). Но, по мере развития программного обеспечения, есть вероятность, что первый проект столкнется с некоторыми проблемами, поэтому вместо этого потребуется 12 месяцев. Или, что еще хуже, отправляется в" используемое, но никогда не законченное " чистилище. Второй проект начинается поздно или даже никогда!

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

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

Это в основном моя профессиональная жизнь в миниатюре :-)