Нормально ли для программиста работать над несколькими проектами одновременно [закрыто]

40

На текущей работе у меня есть два проекта для работы. Первая - очень большая система, а вторая - меньше, но она также большая (первый проект разрабатывается в течение 12 лет, второй - в течение 4 лет).

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

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

Это нормально, и я должен привыкнуть к этому, хотя мой опыт стал очень слабым, что не произойдет, если я буду работать только над одним проектом? Или я должен выразить беспокойство или, возможно, сменить работодателя?

комара
источник
для меня работа над несколькими проектами больше подходит для термина «кузовной ремонт», что не так, не так ли?
Хуже всего то, что я не выношу неуверенности, которая возникает, когда ты не очень опытен в своем проекте. И ситуация с несколькими проектами, над которыми я работаю, не дает мне обрести глубокое понимание, и это меня бесит, потому что я выхожу из своей комфортной жизни / рабочей зоны.
не хочу закрывать этот вопрос. Просто потому, что, на мой взгляд, если вы работаете программистом, вы должны предоставить гарантию, что ваши изменения не повлияют на систему. Но если вам не хватает опыта в системе, какую гарантию вы можете предоставить? Поставить нулевую проверку при каждом вызове метода equals или других объектов? - Да, черт возьми!
Вам разрешено использовать технологии совместной работы и управления знаниями на работе? (Примеры: Wiki, инструменты проверки кода, доступ к проектной документации, инструменты управления проектами, личные списки дел, отслеживание ошибок, обмен мгновенными сообщениями и т. Д.) Без этих технологий работа над несколькими проектами невозможна.
rwong
Является ли этот вопрос «разрешают ли более 50% компаний многозадачность» или «Многозадачность хороша или плоха»?
Мартин Уикман

Ответы:

54

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

Это не нормально! Вовсе нет, для разработчика очень неестественно многозадачность в нескольких проектах (я объясню подробнее позже). С другой стороны, многозадачность очень распространена среди разработчиков. Это определенно то, что вы должны привыкнуть. Таким образом, реальный ответ на ваш вопрос: как многозадачность?

Прежде всего, вы не должны просто принимать свою судьбу, потому что «вы такой отличный работник», а это значит, что вам нужно выполнять больше задач, чем вы можете справиться. Вовсе нет. Иногда людям дают несколько заданий, потому что больше никого нет. Иногда менеджеры не могут справиться со своей работой, поэтому они делегируют, применяя многозадачность в своей команде, потому что они не могут правильно обрабатывать график своих проектов. Таким образом, вы должны определенно попытаться определить, если вас просят многозадачность, потому что это часть вашей работы или потому, что другие люди некомпетентны, В любом случае, вы сами можете судить, приемлемо это или нет. Если вам не комфортно [с вашей работой], есть другие места, где вы можете найти работу. [Вы, разработчик, являетесь товаром. Работодатели знают это и молятся, чтобы вы никогда этого не осознали.]

Что касается многозадачности, я не согласен на 100%, когда люди говорят: «Да, просто переключайтесь назад и вперед и убедитесь, что вы делаете одинаковое количество для каждого проекта». Извините, но это очень плохой совет.

Сначала вы должны понять, как работает ваш мозг при разработке программного обеспечения (я знаю, что есть другие задачи, но давайте сосредоточимся на этом). Сначала вам нужно «подключиться», а это значит, что вам нужно сконцентрироваться и сосредоточиться на том, чтобы у вас все было в голове. Все имена переменных и методов, рабочий процесс вашего кода, объектная модель, потоки, идущие рядом, все. Обычно у меня уходит 15 или 20 минут, чтобы попасть "в зону".

Когда вы попадаете в это состояние, вы действительно летите и пишете код, как будто вы едете на велосипеде. В тот момент, когда вас прерывают, вы можете потерять все. Если перерыв достаточно продолжительный (5, 10 или 30 минут), вы потеряете это состояние ума и вам придется начинать все сначала.

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

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

Я настоятельно рекомендую прочитать статью Джоэла Спольски по этому вопросу:

http://www.joelonsoftware.com/articles/fog0000000022.html

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

Джоэл хорошо выразился, когда сказал:

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

Алекс
источник
5
Одновременный запуск нескольких проектов не означает, что вы пишете код одновременно. Это было бы многозадачностью. Предполагается иметь один проект за раз, может быть предпочтительнее, но просто мечтает о La La Land.
JeffO
1
+1 Отлично. Если бы компании поняли это, у них было бы намного лучше. Некоторые делают, хотя, и это, где завтра победители!
Мартин Уикман
Спасибо @Martin. Мне смешно, что некоторые люди не понимают, что «многозадачность» - это то же самое, что работать над несколькими проектами. Я никогда не говорил, что кодирование одновременно - это то же самое, что и многозадачность. Откуда вы взяли это у @Jeff? Пить кофе и кодировать? Ты шутишь, что ли? Так что, если вы дышите и одновременно моргаете, многозадачность ли вы тоже ??? По крайней мере, прочитайте весь пост Боже! Ссылка на статьи Джоэла имеет очень похожие идеи, пожалуйста, прочтите ее, прежде чем оставлять свой комментарий здесь.
Алекс
2
@Alex - @bjarkef и @Jeff абсолютно правы; имея два проекта! = многозадачность. Пост Джоэла и ваша статья о том, что многозадачность дорогая и расточительная, верны, но они не обязательно имеют отношение к работе над несколькими проектами.
Ник Ноулсон
5
Например, предположим, что вы решили работать над двумя проектами поочередно. Откуда берется стоимость переключения контекста? И как это прерывает пребывание в зоне? Это может быть случай, когда gasan постоянно прерывается аварийными ошибками в другом проекте или даже аварийными ошибками в том же проекте. Вот где многозадачность становится проблемой, но она не присуща двум проектам для работы, и часто это проблема даже с одним проектом.
Ник Ноулсон
33

Да, этого следовало ожидать. И приветствовал.

Есть несколько способов взглянуть на это:

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

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

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

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

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

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

ткач
источник
7
Вместо того, чтобы быть послушным слугой и надеяться на богатство, возможно, быть напористым и повышать ценность, указывая на неэффективность?
Joppe
6
@Tungano - я ни в коем случае не предлагаю быть «послушным слугой», а скорее то, что наделение несколькими параллельными обязанностями является естественным побочным эффектом хорошего в том, что вы делаете. Люди склонны полагаться на тех, кто может заставить вещи случиться. Выполнение нескольких обязанностей не обязательно неэффективно, подчинено или послушно. Если вы (или @gasan) не можете эффективно справиться с несколькими вещами, то обязательно сообщите об этом вашему работодателю, чтобы он не ошибся, думая, что вы можете. (FWIW, я не сказал ничего о богатстве.)
мт
Это также не дает вам скучать по проекту, когда это все, что вы делаете. В настоящее время у меня есть около 100 различных задач, ожидающих выполнения, распределенных по 17 проектам. Конечно, иногда это вызывает некоторое давление, но я расстраиваюсь, когда нечего делать, кроме как вкладывать всю свою энергию в один большой проект.
Htbaa
7
Я категорически не согласен с этим ответом. Многозадачность - это не мера успеха, а мера некомпетентности вашего менеджера. Знать, как выполнять несколько задач, не так просто. PS: я отправил ответ сам, но он идет до конца строки.
Алекс
6
Этот ответ не имеет смысла. Это «нормально» в том смысле, что многие компании принуждают программистов к этому, но это все еще пустая трата ресурсов компании. Если бы они сосредоточились на одной вещи за раз , это было бы закончено намного быстрее.
Мартин Уикман,
15

Да! Это совершенно «нормально» / обычно, когда вы работаете в сервисной компании xD

Также, если вы сотрудничаете с проектами с открытым исходным кодом, это правило

Может быть, нет и идеального состояния, но это хлеб повседневного.

yeradis
источник
Что ж, на самом деле меня огорчает тот уровень экспертизы, который я имею в результате. У меня просто нет такого большого количества памяти, чтобы помнить как системную бизнес, так и техническую логику, это кажется мне невозможным. Все время, когда я получаю задание, мне приходится очень тяжело искать и отлаживать, потому что я плохо знаю эти системы. Прав ли я в том, что программистом «должен знать не много, но выполнять все работы не очень быстро», а не «прекрасно знать всю систему и исправлять ее за пару часов, ниндзя, парень»?
4
@gasan Мы все хотели бы поработать над «одной вещью за раз». Тем не менее, работа над несколькими проектами, чтение чужого кода и работа с различными требованиями - путь к ниндзя.
Богеймин
12

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

Энтони
источник
9

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

Итак, чтобы ответить на ваш вопрос, да, это очень часто.

CaffGeek
источник
так ты что-то вроде Шивы? Я с трудом представляю количество вашего вклада в эти проекты.
@ gasan, смешные суммы для некоторых. Небольшие, но часто критические части других. И некоторые из них мне просто нужно поддерживать, потому что первоначальный разработчик ушел ... и они занимают больше всего времени.
CaffGeek
8

Посмотрите статью под названием Многозадачность . Этот график рассказывает историю:

введите описание изображения здесь

Другими словами, компания тратит время на то, чтобы программисты работали над несколькими проектами одновременно. Всего с тремя проектами отходы составляют 40%! Остальное время разделено на три проекта.

Причиной многозадачности часто называют «добиться большего». Но это ошибочное рассуждение. Многозадачность только приводит к задержке всех выпусков. Это изображение показывает эффект двойного задания по сравнению с завершением одного проекта за раз:

введите описание изображения здесь

(Изображение полностью игнорирует накладные расходы. В действительности потраченное время сделает оба проекта на 20% позже.)

Мартин Уикман
источник
4

Это зависит от компании. ИМО желательно работать в основном только над одним проектом, но это часто невозможно, особенно в небольших компаниях.

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

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

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

Там иногда будет время , когда один проект «бросает исключение» и нужно работать в настоящее . Здесь нужно сделать две вещи:

  1. убедитесь, что это действительно исключение, а не просто напористый руководитель проекта: отодвиньтесь в последнем случае.
  2. поменяйте местами время, чтобы вы по-прежнему работали с одинаковой долей в каждом проекте.
user4051
источник
3

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

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

Мэтт Дж
источник
1
Отличный совет. Я делаю подробные записи, и они пригодились мне не раз.
Адам Лир
2

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

ChaosPandion
источник
2
Действительно, заставь своего босса сказать тебе, что важно. Общение очень важно, и если оно не поддерживается, оно может вызвать большое разочарование и разочарование у любой из сторон.
Htbaa
0

Я думаю это нормально. Как работает моя работа прямо сейчас (я работаю в компании с 40 разработчиками, общий размер компании около 700). И у меня обычно есть один «более долгосрочный» проект с множеством мелких билетов / дефектов, которые появляются, так что обычно это 50% маленьких билетов и 50% работы над долгосрочным проектом. Что может быть трудным, так это то, что постоянное прерывание может замедлить и сорвать долгосрочный проект.

BMW
источник
0

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

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

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

Прадип
источник
0

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

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

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

user1249
источник
-1

Я согласен с теми, кто говорит, что это нормально.

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

Ozz
источник
-1

ИМХО, это не только обычно, но и желательно.

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

cjmUK
источник
Если ваша работа скучная, возможно, вам следует найти другую, более интересную, вместо того, чтобы пытаться сделать лишь часть ее более интересной.
Acumenus
Я сделал - но думать, что каждый аспект каждой работы будет захватывающим, наивно.
cjmUK
Извините, но я не могу сопереживать. Как программист, я нахожу все мои назначенные проекты интересными, не только в моей нынешней работе, но и в той, что у меня была раньше. Это не должно быть захватывающим; это другое. Существует интересный спектр между захватывающим и скучным.
Acumenus
Тогда я думаю, что вам очень повезло ... Тем не менее, я подозреваю, что я нахожусь в более широкой демографической группе, которая должна принять грубое с гладким.
cjmUK
-1

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

Проблема заключается в том, что они видят, что 3 Джобса работают вместе над созданием денег, а не 1 одновременно, а статистика показывает снижение производительности на 40%. Это потеря 40% прибыли.

Ранее я работал в организации, которая позволила мне сосредоточиться на одном крупном проекте за раз с небольшими рабочими местами, билетами, поддержкой и т. Д. Мы работали над соглашением, где 8: 00-10: 00 утра был билет и поддержка текущих систем которые приходят по электронной почте / телефону / службе поддержки, затем 10:00 - 16:30, или ваше время окончания было полным твердым развитием. Это работало хорошо, потому что у нас была служба поддержки, чтобы принимать звонки и электронные письма, я смог сделать билеты утром и подготовить остаток дня. Проблема в том, что у вас плохое управление. Менеджер делает все это возможным, и без его поддержки или понимания проблем, с которыми вы сталкиваетесь ежедневно, они не знают этого факта.

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

Другая проблема заключается в том, что любовные деньги Босса, они видят проекты в деньгах, когда у них есть 5 проектов за 20 000 фунтов стерлингов в одно и то же время (и вы являетесь индивидуальным разработчиком), что составляет 100 000 фунтов стерлингов в книгах. Отлично смотрится на бумаге, но может наносить ущерб репутации компании, когда они не соблюдаются, сроки не соблюдены, а системы глючат из-за недостатка концентрации.

Я сочувствую вам полностью, я сейчас на вашем месте.

Стив Черч
источник
как это отвечает на заданный вопрос?
комнат
-2

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

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

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

апалала
источник
-2

В дополнение к тому, что сказал @Martin Wickman, старайтесь не переключать задачи. Например, работа AM в проекте A, PM в проекте B. Также скажите «нет» добавлению функций; это более болезненно, когда вы не работаете над проектом все время.

Брайан Карлтон
источник