Чи нормально програмісту працювати над кількома проектами одночасно [закрито]

На сьогоднішній роботі я маю два проекти, над якими працюю. Перша - дуже величезна система, друга - менша, але також велика (перший проект розробляється на 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% пізніше.)

Це залежить від компанії. IMO бажано здебільшого працювати лише над одним проектом, але це часто неможливо, особливо з невеликими компаніями.

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

Так, на мій досвід, це нормально (навіть якщо деякі з "проектів" є досить схожими, наприклад, проект технічного обслуговування та функціонування на одному продукті). Щоб уникнути конфліктів та нереальних очікувань, домовтеся з керівниками проекту та вашим менеджером виділити певні частки вашого часу кожному проекту (наприклад, три дні на проект X, два на проект Y на тиждень). Зазвичай ви можете розподіляти ті виділення, як вам подобається, наприклад, Пн-Ср на X, Чт-Пт на Y.

Там іноді буде час , коли один проект «кидає виняток» і потрібно працювати в даний . Тут можна зробити дві речі:

1. переконайтесь, що він справді є винятком, а не лише наполегливим менеджером проектів: відштовхуйтесь в останньому випадку.
2. поміняйте свої розподіли часу, щоб ви все одно працювали однаковою частиною над кожним проектом.

Якщо вам важко відновити швидкість за допомогою проекту або логіки бізнесу, коли ви переходите на нього, ви повинні скористатися можливістю написати стільки документації, скільки зможете, працюючи над цим. Детально про те, як працює складна система, вашими власними словами, набагато простіше повернутися до проекту пізніше. Крім того, ця документація може бути корисною вашим колегам, якщо вони коли-небудь потребують допомоги.

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

Ну, це не повинно бути нормально, але у мене багато робочих проектів у мого нинішнього роботодавця. Зізнаюся, потрібно трохи звикнути. Найважливіша порада, яку я міг би дати, - це завжди надавати пріоритет своїй роботі. Примусьте свого начальника сказати вам, що є пріоритетним завданням, і працюйте над цим тільки. Не тисніть на тих, хто скаржиться на ваші інші проекти. Вам не обов’язково оновлювати своє резюме, але переконайтеся, що навантаження не переростає за рамки чогось, з чим ви з розумом можете впоратися.

Я думаю, що це нормально. Те, як працює зараз моя робота (я в компанії з 40 розробниками, загальний розмір компанії - близько 700). І зазвичай у мене є один "довгостроковий" проект із безліччю маленьких квитків / дефектів, які виникають, тому він, як правило, складає 50% малих квитків та 50% роботи над довгостроковим проектом. Що може бути складно, це те, що постійні перерви можуть сповільнити і зірвати проект на довший термін.

Я думаю, що це нормально працювати над кількома проектами. Головне - визнати, що спочатку ви будете стикатися з деякою неоднозначністю щодо загальної картини системи.

Якщо ви прагнете отримати більшу картину, ви отримаєте чіткість та зможете помітити рухомі / нерухомі частини в системі та як ваші зміни впливають на систему.

За певний проміжок часу ви навчитеся знаходити загальні зразки в різних системах, над якими працюєте. Це ви можете застосувати до інших ваших проектів, що дозволить скоротити кількість детальної інформації, яку потрібно тримати в голові за один раз.

У будь-якому нетривіальному проекті призначено більше однієї людини. Це означає, що вам потрібно співпрацювати з іншими і чекати, коли вони виконують свою роботу, а також вони повинні чекати на вас.

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

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

Я згоден з тими, хто каже, що це нормально / звичайно.

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

ІМХО - це не тільки звичайно, але й бажано.

Найгірша робота з розвитку, яку я коли-небудь мала, працювала над тим же невеликим розділом тієї ж частини тієї самої програми протягом місяців. Тедіум. А коли вам нудно, ви знімаєте погляд з кулі ...

Я розумію, як ви почуваєтесь, важко змусити нових роботодавців зрозуміти процес розвитку, особливо якщо роботодавець не орієнтований на розвиток.

Проблема полягає в тому, що вони бачать, що на 3 робочих місцях працюють більше, ніж виробник грошей, ніж один за один раз, а статистика показує зниження ефективності на 40%. Це 40% втрат прибутку ..

Я попередньо працював над організацією, яка дозволила мені зосередитись на одному великому проекті одночасно з невеликими робочими місцями, квитками та підтримкою тощо. які надходять через електронну пошту / телефон / службу довідки, то 10:00 - 16:30, або ваш час закінчення був повноцінним розвитком. Це спрацювало extreemley добре, тому що у нас була служба підтримки, щоб приймати дзвінки та електронні листи, я змогла зробити квитки вранці та розробити решту дня. Проблема полягає в тому, якщо у вас погане управління. Менеджер змушує це все статися, і без їхньої підтримки та розуміння викликів, з якими ви стикаєтесь щодня, вони не знають цього факту.

Я був особливо вдячний за свою останню роботу за підтримку та розуміння з боку мого менеджера, це полегшило мені життя, менше стресу, і ми все-таки отримали ВСІ роботи.

Інша проблема полягає в коханні грошей Боса, вони бачать проекти в грошах. Коли у них є 5 проектів за 20 000 фунтів стерлінгів одночасно (і ви є сольним розробником), то 100 000 фунтів стерлінгів у книгах. Чудово виглядає на папері, але може завдають шкоди репутації компанії, коли їх не дотримуються, терміни пропущені, а системи нестабільні через відсутність концентрації.

Я повністю співчуваю вам, я зараз на вашому становищі.

Це залежить від того, як ви описуєте проект. Зазвичай розробник працює з якоюсь проблемою, і якщо в компанії більше одного продукту, ніж ви працюєте з декількома.

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

Додавши до того, що сказав @Martin Wickman, постарайтеся не переключати задачі сильно. Наприклад, працюйте AM над проектом A, PM над проектом B. Також скажіть "не" для додавання функцій; це болісніше, коли ви не працюєте над проектом повний робочий день.