Czy to normalne, że programista pracuje nad wieloma projektami jednocześnie [zamknięte]

40

Na bieżącej pracy mam dwa projekty do pracy. Pierwszy to bardzo duży system, a drugi jest mniejszy, ale także duży (pierwszy projekt jest rozwijany przez 12 lat, drugi przez 4 lata).

Początkowo pracowałem tylko nad pierwszym projektem i starałem się do niego przyzwyczaić. Potem zostałem przeniesiony do drugiego projektu i tam wypróbowany, więc moja wiedza na temat pierwszego projektu stała się zacieniona. Teraz muszę pracować nad obydwoma projektami jednocześnie.

Jest to dla mnie bardzo trudne, ponieważ pomimo tego, że obaj używają java, używają różnych frameworków, a ilość kodu i logiki biznesowej do zrozumienia jest bardzo duża, więc naprawdę nie mogę trzymać obu tych projektów w głowie.

Czy to normalne i powinienem się do tego przyzwyczaić, chociaż moja wiedza specjalistyczna stała się bardzo krucha, co nie stanie się, gdybym pracował tylko nad jednym projektem? Czy powinienem zgłosić problem, a może zmienić pracodawcę?

komara
źródło
dla mnie praca nad wieloma projektami bardziej pasuje do terminu „body shop”, co jest złą rzeczą, prawda?
Najgorsze jest to, że nie mogę znieść niepewności, która pojawia się, gdy nie masz zbyt dużego doświadczenia w swoim projekcie. A sytuacja, w której pracuje wiele projektów, uniemożliwia mi silne zrozumienie, co doprowadza mnie do szaleństwa, ponieważ jestem wyciągany ze strefy komfortu życia i pracy.
nie chcę zamykać tego pytania. Tylko dlatego, że moim zdaniem, jeśli pracujesz jako programista, powinieneś dać gwarancję, że Twój kod zmiany nie wpłyną na system. Ale jeśli nie masz specjalistycznej wiedzy na temat systemu, jaką gwarancję możesz zapewnić? Czy sprawdzanie wartości zerowej przy każdym wywołaniu metody „równa się” lub innym obiekcie? - O tak!
Czy wolno ci korzystać z technologii współpracy i zarządzania wiedzą w pracy? (Przykłady: Wiki, narzędzia do sprawdzania kodu, dostęp do dokumentów projektowych, narzędzia do zarządzania projektami, osobiste listy rzeczy do zrobienia, śledzenie błędów, komunikatory itp.) Bez tych technologii praca nad wieloma projektami jest niemożliwa.
rwong
Czy to pytanie „czy ponad 50% firm dopuszcza wielozadaniowość” czy „Czy wielozadaniowość jest dobra czy zła”?
Martin Wickman,

Odpowiedzi:

54

Całkowicie się nie zgadzam, gdy ludzie mówią „tak, wielozadaniowość jest normalna”

To nie jest normalne! Wcale nie jest to bardzo nienaturalne, że programista może wykonywać wiele zadań w kilku projektach (wyjaśnię to później). Z drugiej strony wielozadaniowość jest bardzo powszechna wśród programistów. To zdecydowanie coś, do czego powinieneś się przyzwyczaić. Tak więc prawdziwa odpowiedź na twoje pytanie brzmi: jak wykonywać wiele zadań?

Przede wszystkim nie powinieneś po prostu akceptować swojego losu, ponieważ „jesteś tak doskonałym pracownikiem”, a to oznacza, że ​​musisz podjąć więcej zadań niż jesteś w stanie wykonać. Wcale nie. Czasami ludzie mają wiele zadań, ponieważ nie ma nikogo innego. Czasami menedżerowie nie mogą obsłużyć swojej pracy, więc delegują zadania, wymuszając wielozadaniowość w swoim zespole, ponieważ nie potrafią właściwie obsłużyć harmonogramu projektu. Dlatego zdecydowanie powinieneś spróbować ustalić, czy jesteś proszony o wielozadaniowość, ponieważ jest to część twojej pracy lub dlatego, że inni ludzie są niekompetentni. Tak czy inaczej, możesz sam ocenić, czy jest to do przyjęcia, czy nie. Jeśli nie czujesz się komfortowo [w pracy], są inne miejsca, w których możesz znaleźć pracę. [Ty, deweloper, jesteś towarem. Pracodawcy wiedzą o tym i modlą się, abyś nigdy tego nie rozumiał.]

Jeśli chodzi o wielozadaniowość, nie zgadzam się w 100%, gdy ludzie mówią „tak, po prostu przełączaj się tam iz powrotem i upewnij się, że robisz tyle samo przy każdym projekcie”. Przepraszam, ale to bardzo zła rada.

Najpierw musisz zdać sobie sprawę z tego, jak działa mózg, gdy tworzysz oprogramowanie (wiem, że wiążą się z tym inne zadania, ale skupmy się na tym). Najpierw musisz „podłączyć się”, co oznacza, że ​​musisz się dużo skoncentrować i ustawić umysł w pozycji, w której masz wszystko zmapowane w głowie. Wszystkie nazwy zmiennych i metod, przepływ pracy twojego kodu, model obiektowy, wątki idące obok siebie, wszystko. Zazwyczaj zajmuje mi to 15, 20 minut, aby dostać się do strefy.

Kiedy dojdziesz do tego stanu, naprawdę lecisz i piszesz kod, jakbyś jeździł na rowerze. W chwili, gdy zostaniesz przerwany, możesz wszystko stracić. Jeśli przerwa jest wystarczająco długa (5, 10, może 30 minut), stracisz ten stan umysłu i będziesz musiał zacząć wszystko od nowa.

Wielozadaniowość jest więc okropna, ponieważ zmusza cię do opuszczenia „strefy” i przejścia do czegoś innego. Jeśli ciągle się zmieniasz, oznacza to, że nie jesteś produktywny, ponieważ za każdym razem, gdy zmieniasz się na nowe zadanie / projekt, musisz stracić 15-20 minut na ponowne wejście do strefy (nie wspominając o tym, że powoli topi mózg).

To jak wielowątkowość: w pewnym momencie koszt przełączania kontekstu wątku co kilka cykli jest zbyt wysoki, więc procesor spędza więcej czasu na przełączaniu kontekstów niż na wykonywaniu rzeczywistych zadań.

Bardzo polecam przeczytanie artykułu Joela Spolsky'ego na ten temat:

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

Więc moja rada: spróbuj nauczyć się (nie) wielozadaniowości, ponieważ jest to naprawdę powszechne. Ale upewnij się również, że czujesz się komfortowo. Niektóre osoby mogą poświęcić więcej czasu na koncentrację i cierpią bardziej niż inne, gdy wykonują wiele zadań; i to też jest w porządku. Nie dlatego, że często uważa się to za normalne.

Joel dobrze to ujął, gdy powiedział:

W rzeczywistości prawdziwa lekcja z tego wszystkiego jest taka, że ​​nigdy nie powinieneś pozwalać ludziom pracować nad więcej niż jedną rzeczą na raz. Upewnij się, że wiedzą, co to jest. Dobrzy menedżerowie postrzegają swoją odpowiedzialność za usuwanie przeszkód, aby ludzie mogli skupić się na jednej rzeczy i naprawdę to zrobić.

Alex
źródło
5
Prowadzenie kilku projektów jednocześnie nie oznacza, że ​​kodujesz jednocześnie. To byłaby wielozadaniowość. Oczekiwanie na jeden projekt może być lepsze, ale marzy tylko o La La Land.
JeffO
1
+1 doskonale. Gdyby firmy zdały sobie z tego sprawę, radziłyby sobie znacznie lepiej. Niektórzy jednak tak robią i właśnie tam jutro wygrywają jutro!
Martin Wickman,
Dzięki @Martin. Czuję się zabawnie, że niektórzy ludzie nie rozumieją, że „wielozadaniowość” to to samo, co praca nad wieloma projektami. Nigdy nie mówiłem, że kodowanie jednocześnie jest tym samym, co wielozadaniowość. Skąd masz to z @Jeff? Pijesz kawę i kodujesz? Czy ty żartujesz? Więc jeśli jednocześnie oddychasz i mrugasz, to czy też wielozadaniowość? Przynajmniej przeczytaj cały geez! Link do artykułów Joela ma bardzo podobne pomysły, przeczytaj go przed umieszczeniem tutaj komentarza.
Alex
2
@Alex - @bjarkef i @Jeff mają absolutną rację; mając dwa projekty! = wielozadaniowość. Wpis Joela i twoja opinia o tym, że wielozadaniowość jest kosztowna i marnotrawna, są poprawne, ale niekoniecznie są odpowiednie do pracy nad wieloma projektami.
Nick Knowlson,
5
Załóżmy na przykład, że zdecydujesz się pracować nad dwoma projektami w naprzemiennych dniach. Skąd się bierze koszt zmiany kontekstu? A jak to zakłóca przebywanie w strefie? Może się zdarzyć, że Gasanowi ciągle przeszkadzają awaryjne błędy w innym projekcie, a nawet awaryjne błędy w tym samym projekcie. W tym przypadku wielozadaniowość staje się problemem, ale nie jest nieodłączna od posiadania dwóch projektów i często stanowi problem nawet w przypadku tylko jednego projektu.
Nick Knowlson,
33

Tak, należy się tego spodziewać. I mile widziane

Jest na to kilka sposobów:

  1. Oczekuje się od ciebie wielozadaniowości i skupienie się jest prawie niemożliwe. Powoduje to nieoptymalne procesy inżynieryjne, sporadyczne zamieszanie podczas przełączania się tam i z powrotem, poczucie wyzysku, frustrację, stres itp. To wszystko oczywiście jest negatywne; jednak,

  2. Zaufało ci wiele projektów, co dobrze odzwierciedla uzyskane wyniki i zaufanie pracodawcy do twoich umiejętności. To okazja, aby pokazać im, że zaufanie jest uzasadnione.

Radzę, aby trzeźwo ocenić, które zadania wymagają Twojej natychmiastowej uwagi, a które mogą poczekać. Czasami odpowiedź jest taka, że ​​żaden nie może czekać i trzeba zastosować kreatywne podejście do zapewniania wyników (trochę dla projektu A, potem trochę dla projektu B, następnie spłucz i powtórz). Rozwijaj umiejętności, aby dobrze prosperować w takiej sytuacji.

Zwykle (choć nie zawsze) zostanie to nagrodzone większą odpowiedzialnością, większą liczbą projektów do żonglowania i większymi oczekiwaniami. W pewnym momencie będziesz mógł i spodziewał się, że przekażesz część tej pracy. To miara sukcesu.

Tak więc, nawet jeśli twoje rosnące umiejętności żonglowania są wykorzystywane tylko przez twoją obecną firmę, są to dobre umiejętności, które mają i będą ci dobrze służyć w karierze.

Za to, co jest warte, zwykle pracuję nad dużym projektem, mniejszym, utrzymaniem i obsługą starych projektów oraz zarządzaniem co najmniej jednym innym. To frustrujące, mylące, męczące i jestem bardzo wdzięczny.

tkacz rachunków
źródło
7
Zamiast być posłusznym sługą i nadzieją na bogactwa, być może być asertywnym i wnieść wartość dodaną, wskazując na nieefektywność?
Joppe
6
@Tungano - w żadnym wypadku nie sugeruję bycia „posłusznym sługą”, ale raczej to, że powierzenie wielu równoczesnych obowiązków jest naturalnym efektem ubocznym bycia dobrym w tym, co robisz. Ludzie zwykle polegają na tych, którzy mogą sprawić, że coś się stanie. Podejmowanie kilku obowiązków niekoniecznie jest nieefektywne, niewolnicze lub posłuszne. Jeśli ty (lub @gasan) nie potrafisz skutecznie poradzić sobie z kilkoma sprawami, to z całą pewnością poinformuj swojego pracodawcę, aby nie popełnili błędu myśląc, że możesz. (FWIW, nie mówią nic na temat bogactwa.)
BW
Zapobiega również znudzeniu się projektem, gdy to wszystko, co robisz. Obecnie czeka na mnie około 100 różnych zadań rozłożonych na 17 projektów. Jasne, czasami powoduje to pewną presję, ale czuję się niezadowolony, gdy nie mam nic do roboty oprócz włożenia całej mojej energii w jeden duży projekt.
Htbaa
7
Zdecydowanie nie zgadzam się z tą odpowiedzią. Wielozadaniowość to nie miara sukcesu, to miara niekompetencji twojego menedżera. Umiejętność wykonywania wielu zadań nie jest taka łatwa. PS: Sam opublikowałem odpowiedź, ale trafia ona na koniec linii.
Alex
6
Ta odpowiedź nie ma sensu. Jest to „normalne” w tym sensie, że wiele firm zmusza do tego programistów, ale nadal marnuje zasoby firmy. Gdyby skupili się na jednej rzeczy na raz , skończyłoby się to znacznie szybciej.
Martin Wickman
15

Tak! Jest to całkowicie „normalne” / zwykłe, gdy pracujesz w firmie usługowej xD

Również w przypadku współpracy z projektami typu open source jest to reguła

Może nie jest to idealny stan, ale jest chlebem powszednim.

yeradi
źródło
cóż, tak naprawdę zasmuca mnie poziom wiedzy specjalistycznej, jaki mam. Po prostu nie mam tak dużej pamięci, aby zapamiętać logikę biznesową i techniczną systemów, co wydaje mi się niemożliwe. Przez cały czas, kiedy dostaję zadanie, muszę bardzo mocno szukać i debugować, ponieważ nie znam dobrze tych systemów. Czy mam rację, że programista „nie wiedzący wiele, ale wykonujący wszystkie zadania niezbyt szybko” jest tym, czym powinien być programista, a nie „doskonale znający cały system i naprawiający za kilka godzin facet ninja”?
4
@gasan Wszyscy chcielibyśmy pracować nad „jedną rzeczą na raz”. Jednak praca nad więcej niż jednym projektem, czytanie kodu innych osób i radzenie sobie z różnymi wymaganiami jest ścieżką do ninja-hooda.
bogeymin
12

To jest powszechne. Ale to nie jest dobre z powodów, które przedstawiłeś. Przełączanie kontekstu na produktywność, więc jeśli możesz, spróbuj pracować nad jednym projektem przez dłuższy czas, np. Jeden dzień.

Anthony
źródło
9

Codziennie aktywnie pracuję nad 2–3 różnymi projektami. I utrzymaj kilkadziesiąt innych. Niektóre tygodnie robią się przytłaczające. Niektóre projekty są ogromne, niektóre są tak małe, że zostały zakodowane w ciągu kilku dni i rzadko wymagają zmian. Różni się, ale naraża mnie na różne sposoby myślenia i rozwiązywania problemów, różne technologie i obszary biznesowe. Podoba mi się.

Tak więc, aby odpowiedzieć na twoje pytanie, tak, to jest bardzo częste.

CaffGeek
źródło
więc jesteś typem Shivy? Trudno mi wyobrazić sobie twój wkład w te projekty.
@gasan, śmieszne to niektóre. Małe, ale często krytyczne, części innych. A niektóre muszę tylko utrzymywać, ponieważ pierwotnego programisty już nie ma ... a te są najbardziej czasochłonne.
CaffGeek 27.01.11
8

Zapoznaj się z artykułem zatytułowanym „ Wielozadaniowość” . Ten wykres przedstawia historię:

wprowadź opis zdjęcia tutaj

Innymi słowy, firma marnuje czas, ponieważ programiści pracują nad więcej niż jednym projektem na raz. Przy zaledwie trzech projektach marnotrawstwo wynosi 40%! Resztę czasu dzieli się na trzy projekty.

Powód wielozadaniowości jest często określany jako „robienie więcej rzeczy”. Ale to błędne rozumowanie. Wielozadaniowość powoduje jedynie opóźnienie wszystkich wydań. Ten obraz pokazuje efekt podwójnego zadania i ukończenia jednego projektu na raz:

wprowadź opis zdjęcia tutaj

(Obraz całkowicie ignoruje koszty ogólne. W rzeczywistości stracony czas spowodowałby, że oba projekty byłyby 20% później.)

Martin Wickman
źródło
4

To zależy od firmy. IMO pożądane jest, aby przeważnie pracować tylko nad jednym projektem, ale często nie jest to możliwe, szczególnie w przypadku małych firm.

Oczywiście poprawki błędów itp. Zawsze mogą wystąpić w każdym projekcie.

użytkownik 281377
źródło
masz rację, pracuję teraz w małej firmie, ale wcześniej pracowałem tylko dla dużych, więc może jest to część problemu, mam na myśli to, że nie byłem przyzwyczajony do pracy w małych firmach.
4

Tak, z mojego doświadczenia jest to normalne (nawet jeśli niektóre „projekty” są dość podobne, np. Projekt konserwacji i funkcji tego samego produktu). Aby uniknąć konfliktów i nierealistycznych oczekiwań, uzgodnij z kierownikami projektu i kierownikiem, aby przeznaczyć określone ułamki swojego czasu na każdy projekt (np. Trzy dni na projekt X, dwa na projekt Y na tydzień). Następnie możesz normalnie rozdzielić te przydziały, jak chcesz, np. Od poniedziałku do piątku w dniu X, w czwartek do piątku w dniu Y.

Czasami zdarza się, że jeden projekt „zgłasza wyjątek” i należy go teraz przerobić . Są tutaj dwie rzeczy do zrobienia:

  1. upewnij się, że naprawdę jest to wyjątek, a nie tylko nachalny menedżer projektu: odepnij w tym drugim przypadku.
  2. zamień swoje przydziały czasu, aby nadal pracować z tą samą frakcją dla każdego projektu.
użytkownik4051
źródło
3

Jeśli trudno ci wrócić do frameworku lub logiki biznesowej projektu po powrocie do niego, powinieneś skorzystać z okazji, aby napisać jak najwięcej dokumentacji podczas pracy nad nią. Wyszczególnienie, jak działa złożony system, własnymi słowami, znacznie ułatwi powrót do projektu później. Ponadto ta dokumentacja może być pomocna dla współpracowników, jeśli kiedykolwiek będą potrzebować pomocy.

Jeśli projekt ma już dobrą dokumentację techniczną, nadal warto zapisać swoje przemyślenia podczas pracy w skomplikowanych obszarach. W ten sposób możesz przywołać swój proces myślowy przy następnym przełączeniu.

Matt G.
źródło
1
Dobra rada. Robię szczegółowe notatki, które przydały się niejednokrotnie.
Adam Lear
2

Cóż, to nie powinno być normalne, ale mam wiele projektów na ramionach u mojego obecnego pracodawcy. Przyznaję, że trochę się przyzwyczajam. Najważniejszą wskazówką, jaką mógłbym udzielić, jest zawsze nadawanie priorytetu swojej pracy. Zmuś szefa, aby powiedział ci, jakie jest priorytetowe zadanie i pracuj tylko nad tym. Nie wywieraj presji na osoby, które narzekają na twoje inne projekty. Nie musisz jeszcze aktualizować swojego CV, ale upewnij się, że obciążenie nie zwiększy się poza coś, co można rozsądnie obsłużyć.

ChaosPandion
źródło
2
Rzeczywiście, zmuś szefa, by powiedział ci, co jest ważne. Komunikacja jest bardzo ważna, a jeśli nie jest utrzymywana, może powodować wiele frustracji i rozczarowań dla każdej ze stron.
Htbaa
0

Myślę, że to normalne. Sposób, w jaki obecnie działa moja praca (jestem w firmie z około 40 programistami, całkowita wielkość firmy to około 700). I zwykle mam jeden „długoterminowy” projekt z wieloma małymi biletami / wadami, które zwykle pojawiają się, więc zwykle kończy się to w 50% małymi biletami i 50% pracy nad długoterminowym projektem. Trudne może być to, że ciągłe zakłócenia mogą spowolnić i wykoleić długoterminowy projekt.

Bmw
źródło
0

Myślę, że praca nad wieloma projektami jest normalna. Kluczem jest zaakceptowanie, że na początku będziesz miał do czynienia z pewną dwuznacznością dotyczącą ogólnego obrazu systemu.

Jeśli dążysz do uzyskania większego obrazu, uzyskasz jasność i będziesz w stanie dostrzec ruchome / stałe części w systemie oraz wpływ zmian na system.

Z czasem nauczysz się znajdować wspólne wzorce w różnych systemach, na których pracujesz. Możesz je zastosować do swoich innych projektów, co zmniejszy ilość szczegółowych informacji, które musisz trzymać w głowie na raz.

Pradeep
źródło
0

W każdym nietrywialnym projekcie przypisana jest więcej niż jedna osoba. Oznacza to, że musisz współpracować z innymi i czekać, aż wykonają swoją pracę, a także będą musieli na ciebie czekać.

Zamiast pozostawiać ludzi bezczynnych, często jest aktywnych wiele projektów, aby zawsze było otwarte zadanie do wykonania w razie potrzeby.

Nadal powinieneś pracować w pokaźnych kawałkach nad każdym projektem, abyś mógł „wejść do strefy” i być produktywnym.

użytkownik1249
źródło
-1

Zgadzam się z tymi, którzy mówią, że to normalne / powszechne.

Spójrz na to pozytywnie, staniesz się bardziej przydatny, postrzegany jako elastyczny, idź do faceta, który może załatwić sprawę! Być może bardziej wartościowy, gdy w końcu poznasz 2 systemy od podszewki.

ozz
źródło
-1

IMHO jest nie tylko zwyczajne, ale także pożądane.

Najgorsze zadanie programistyczne, jakie kiedykolwiek miałem, to praca nad tą samą małą częścią tej samej części tej samej aplikacji przez wiele miesięcy. Nuda. A kiedy się nudzisz, odrywasz wzrok od piłki ...

cjmUK
źródło
Jeśli twoja praca jest nudna, być może powinieneś znaleźć inną, bardziej interesującą, zamiast starać się, aby tylko jej część była bardziej interesująca.
Acumenus
Tak, ale myślenie, że każdy aspekt każdej pracy będzie ekscytujący, jest naiwne.
cjmUK
Przepraszam, ale nie mogę empatii. Jako programista uważam, że wszystkie moje przydzielone projekty są interesujące nie tylko w mojej obecnej pracy, ale także w tym, który miałem wcześniej. To nie musi być ekscytujące; to jest inne. Istnieje interesujące spektrum między ekscytacją a nudą.
Acumenus
Więc myślę, że masz wielkie szczęście ... Podejrzewam jednak, że jestem w większej grupie demograficznej, która musi znieść trudność.
cjmUK
-1

Rozumiem, jak się czujesz, ciężko jest sprawić, aby nowi pracodawcy zrozumieli proces rozwoju, którego to dotyczy, szczególnie jeśli pracodawca nie jest skoncentrowany na rozwoju.

Problem polega na tym, że widzą, jak 3 zadania pracują razem więcej niż zarabia więcej niż 1 na raz, a statystyki pokazują 40% spadek wydajności. To 40% utrata zysku.

Wcześniej pracowałem dla organizacji, która pozwoliła mi skupić się na 1 dużym projekcie naraz, z małymi zleceniami pomiędzy, biletami i wsparciem itp. Pracowaliśmy nad umową, w której 8: 00-10: 00 AM było Biletem i wsparciem dla obecnych systemów które przychodzą przez e-mail / telefon / helpdesk, a następnie 10:00 - 16:30 lub czas zakończenia był w pełni solidny. Działało to wyjątkowo dobrze, ponieważ mieliśmy helpdesk do odbierania połączeń i e-maili, mogłem robić bilety rano i rozwijać resztę dnia. Problem polega na tym, że masz słabe zarządzanie. Menedżer sprawia, że ​​wszystko to się dzieje i bez ich wsparcia lub zrozumienia wyzwań, przed którymi codziennie stajesz, nie znają tego faktu.

Byłem wdzięczny, zwłaszcza w mojej ostatniej pracy, za wsparcie i zrozumienie mojego przełożonego, które ułatwiło mi życie, zmniejszyło stres i nadal wykonaliśmy WSZYSTKĄ pracę.

Inną kwestią jest to, że pieniądze szefa Bossa, widzą projekty w pieniądzach, gdy jednocześnie mają 5 projektów za 20 000 funtów (i jesteś samodzielnym programistą), co daje 100 000 funtów w książkach. Wygląda świetnie na papierze, ale może szkodzi reputacji firmy, jeśli nie zostaną dotrzymane, terminy są przekroczone, a systemy są wadliwe z powodu braku koncentracji.

Całkowicie sympatyzuję z tobą, jestem teraz na twojej pozycji.

Steve Church
źródło
Jak to odpowiada na zadane pytanie?
komar
-2

To zależy od tego, jak opisujesz projekt. Zwykle programista pracuje z pewnym problemem, a jeśli w firmie jest więcej niż jeden produkt, niż ty pracujesz z wieloma.

Dainius
źródło
Zapewniamy 2 oddzielne produkty, które dzielą mały fragment kodu. Że produkty są dostosowane do różnych potrzeb użytkowników, ale nadal są w tej samej domenie.
-2

Projekty oprogramowania, takie jak partnerzy miłosni, mogą być liczne i dobre w wielu, ale są dobre tylko wtedy, gdy występują pojedynczo.

Apalala
źródło
-2

Dodając do tego, co powiedział @Martin Wickman, staraj się nie przełączać zbyt wiele zadań. Na przykład popracuj nad projektem A, PM nad projektem B. Powiedz także „nie”, aby dodać funkcje; jest to bardziej bolesne, gdy nie pracujesz nad projektem w pełnym wymiarze godzin.

Brian Carlton
źródło