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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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