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

Question

У меня есть два проекта с одинаковыми приоритетами и рабочим временем, а также один разработчик. Два возможных подхода:

1. Сначала доставьте один проект.
2. Разделите время разработчика и доставьте оба позже.

Я не вижу никакой причины, по которой люди выбрали бы второй подход. Но они делают. Можете ли вы объяснить мне, почему?

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

«Мы оставим другого на потом», часто это не приемлемый ответ, хотя это приводит к задержкам для обоих проектов.

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

• LM

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

В конечном счете, если у вас есть один ресурс, у вас есть естественное узкое место.

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

Answer 9

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

Answer 10

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

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