Zarządzanie projektem a wypalenie

Hej, zastanawiałem się czy macie jakieś refleksje na temat tego jak projekt był zarządzany i jak na was to osobiście wpływało.

Na początku kariery miałem o wiele mniejsze projekty, które można było zrobić w 1-2os więc tam pojawiał się często waterfallowy sposób prowadzenia projektu. Mimo wszystko przy zamknięciu tematu/etapu to zawsze było na swój sposób nagradzające i czuło się pewną ulgę, dużą motywację do domykania wszystkiego. Nie ukrywam, że to też dość podobne do sposobu pracy w którym obracałem się wcześniej w innych branżach.

Przez większosć swojego stażu w IT pracuję w pseudo scrumach, agile'ach i szczerze mówiąc jestem kompletnie nieproduktywny w tym podejściu, denerwuje mnie wszystko począwszy od daily statusów, standupów, refinementów, retro i tym podobnych - wybijanie z flow, marnowanie czasu. Może jestem w to słaby, ale nigdy jeszcze nie wyrobiłem się w sprincie na kompletne zamknięcie jakiegoś grubszego tematu i w zasadzie jedyne co czuję w tym systemie to napieprzanie jak na taśmie, bez jasnego momentu zakończenia tematu - 0 nagrody, motywacji. Po prostu task za taskiem do tego często ciągnące się nie wiadomo ile i przekraczające sprinty, bo tu ktoś blokuje, tam trzeba czekać na QA, byle robić jak najwięcej z puli tego co jest dostępne i to co damy rade, to wrzucimy z ew. naciskiem na cele sprintu. Ogólnie jestem dość rozczarowany prowadzeniem projektów w tym stylu, czuję się mocno wyssany z motywacji przez taką pracę. Nie ważne jak mocno przyciśniesz, to w dłuższej perspektywie i tak pojawi się milion kolejnych tasków więc w zasadzie staranie się dla mnie nie ma sensu.

Czy ktoś z was jest obecnie zadowolony z jakiegokolwiek sposobu zarządzania u niego w projekcie i chce się podzielić wrażeniami?

Ja pracuję w pseudoscrumie od dobrych kilku lat (głównie w korpo). Moje obserwacje:

• scrum nic nie daje, bo management i tak ma sztywne terminy, więc ostatecznie żaden sprint nie jest skończony
• scrum jest przez część biznesu traktowany jako wymówka do wrzucania zmian w połowie sprintu, ale oczywiście bez przesuwania innych terminów
• ponieważ 95% czasu to walka z ciągłymi zmianami (bo "BA team is also agile" xD), narasta dług techniczny, który nigdy nie jest priorytetm, bo "no business value"
• większość zespołu ma poczucie, że jeśli zrobią 150% to nikt im nie podziękuje, ale za to wiecznie są pytania dlaczego taski się opóźniają

Ze względu na wiek nie miałem szansy zobaczyć jak jest w waterfallu. Założenia są dość specyficzne, ale w korpoprojektach sprawdziłyby się pewnie lepiej niż scrum.
Tu jest ciekawy wątek o scrumie -> Jak obiektywnie ocenić pracę Scrum Mastera?

@clonazepam: Wszystko zależy od sposobu zarządzania firmą, tego ile jej klienci płacą, czego oczekują i na kiedy. Scrum nic tu nie zmienia, jeśli czujesz się wypalony to zmieniaj firmę. W każdej firmie w której pracowałem było inaczej, są setki zmiennych wpływających na to czy programiści się wyrabiają. Jeśli nie wyrabiasz się w 2 tygodnie to za dużo bierzecie, albo na spotkaniach osoby odpowiedzialne nie wyjaśniają co jest do zrobienia. Jeśli rozmowy na spotkaniach są wyczerpujące to znaczy że jest dużo do ustalenia i są potrzebne, no chyba że każdy chce przeciągnąć linę na swoją stronę a nie ma znaczenia które rozwiązanie przyjmiecie to znaczy, że decyzje powinny zapadać na górze a nie angażować was wszystkich i na tych spotkaniach powinni wam tylko wytłumaczyć co macie robić. Scrum w całości to się wdraża w małych zespołach 3 osobowych. W korposach to się robi tylko pseudoscrum z potrzebnymi elementami. Kijem wisły nie zawrócisz, łatwiej znaleźć firmę, która pasuje do Twojego sposobu pracy.

• "nigdy jeszcze nie wyrobiłem się w sprincie na kompletne zamknięcie jakiegoś grubszego tematu"
  To skoro wiesz ze sie nie wyrabiasz to czemu deklarujesz, że tyle zrobisz ? Brak umiejętności szacowania zadań czy mówienia nie ?
• "często ciągnące się nie wiadomo ile i przekraczające sprinty, bo tu ktoś blokuje, tam trzeba czekać na QA"
  Blokery czy testy to jest nowość u was i pojawia się nagle ? Raczej nie jest to normalna kolej rzeczy. Więc problem nie jest tu metodologia tylko brak jasnej komunikacji, złego planowania czy analiza zadań. Bo skoro często występuja blokery tzn, że wgl nie analizujecie tych zadań. Bo rozumiem, jak pojawia sie coś zaskakującego niespodziewanego w projekcie. Ale jeśli w każdym sprincie jest coś zaskakującego tzn, że problem lezy w zespole.

Ja znów mam odwrotne doświadczenia w przypadku waterfallu zawsze miałem styczność z niedoszacowanymi projektami. W różnego rodzaju agilu (aktualnie pracuje w SAFe) zawsze czuje sie swobodniej bo nie stresuje sie czasem.

@Bonanzaa: Mam pełen scrum nawet jego dość mocno hardkorową wersję gdzie w produkcie pracuje > 100osób i wiele zespółów z przeróżnych dziedzin.

Mam dokładnie takie same odczucia, najlepszy model to wiele małych waterfalli, to jest najbardziej satysfakcjonujące dla developerów i dla klientów (także wewnętrznych). Sprzedanie ściemy że agile jest lepszy dla developerów i dla klientów to być może największe kłamstwo w IT po 2000 r. To są po prostu brednie. Nawet w trybie time & materials klient woli płacić za miniprojekty niż ładować się w niekończący się scrum. Co oczywiście nie oznacza, że waterfall nie jest bagnem, bo jak jest wyceniony za nisko to kończy się crunchem. Ale można trafić dobrze z wyceną, w scrumie nawet jak się trafi dobrze z wyceną, to jest to tylko okazja żeby 100 razy zmienić zakres projektu i dosypać 2x tyle tasków.

Czego nauczyłem się na własnej skórze (bolało):

• Generalnie nic sam nie zmienisz. Firma tak działa, zaakceptuj to lub poszukaj lepszej firmy (takie są, ale nie tak łatwo się tam dostać i/lub warunki $$$ potrafią być gorsze).
• Jako wróg bezmyślnego agile: Agile został wymyślony przez konsultantów dla konsultantów. Jakbyś był konsultantem i taksował od h to byś docenił, tu mam X ticketow z JIRY, Y $$$ się należy. A to że projekt idzie w h** wie jakim kierunku? No za to mi nie płacą...
• Niedoświadczonych/naiwnych/głupich (wybrać jedno) pracowników często bierze się na tak zwany "deadline", teraz się mówi koniec sprintu. Zobowiązaliście się (mimo że estymaty to czysta fikcja poza najbardziej curderskimi crudami) więc MUSICIE dowieść. Prawda jest taka że nic nie musisz, umawiałeś się z pracodawcą na 40h więc robisz średnio 40h. To że projekt się opóźnia to wina managementu który ma odpowiadać za to że projekt zostanie dowieziony (za to im przecież płacą!). Wrzuć więc na luz, rób swoje, rób to dobrze tak jak np. żołnierz zwiadowca dumy ze swoich umiejętności, ale wiec że losy wojny od pojedynczego żołnierza nie zależą...
• Ad. ostatni punkt, jeżeli zależy Ci na awansie to niestety trzeba się bardziej wysilić.

To tyle z mądrości ogólnych. U Ciebie OPie jest inny rodzaj przegięcia, nazwijmy to "leniwym SCRUMEM".
Symptomy:

• Kładziemy lachę na estymatach. Nie rozbijamy tasków więc ciągnąć się przez Sprinty.
• Zależności do QA która NIE JEST CZĘŚCIĄ ZESPOŁU
• Brak "definition of done" i nieprofesjonalnie prowadzone standupy i retro

Obawiam się że sam niewiele tu zdziałasz. Możesz iść po ścieżce pro Agile i powiedzieć że np. zostaniesz Scrum Masterem i pewne rzeczy zaczniesz poprawiać:

• Standup max 15 min. Standup to nie spowiedź z tego co kto robił, tylko sync na temat tego jak dzisaj chcemy sie zbliżyć do celi sprintu.
• Retro, na początku warto obgadać action item's (a więc rzeczy które obiecaliśmy poprawić ostatnio). Potem 3 proste pytania: Co nam przeszkadza? Co nam pomaga (i chcemy tego więcej)? Co się udało zrobić (motywacyjne na poprawę humoru)? Potem wybierz 3 rzeczy o których chcesz pogadać i jeżeli to potrzebne zrób z nich action itemy.
• Taski nie mogą być za małe i ale nie powinny być też za duże. Jako wróg SCrUMA nie chce mi się nawet tego tematu poruszać, w sieci znajdziesz dużo materiałów. Czasami warto zrobić sobie spike (prototyp żeby zbadać temat i wyjść z designem).

Na serio to nie liczę na jakąkolwiek poprawę. Ja sam pracuję w trochę innym modelu popularnym bardziej za ocenem a opartym o design docki, RFC i strong ownership. Pracuje się o niebo lepiej, ale to raczej nie jest tryb pracy dla początkujących. Np. projekt pod tytułem wdrożenie nowego protokołu kompresji może się ciągnąć i 3 miechy od pierwszych researchów aż po wdrożenie na produkcje i monitoring. Inna sprawa że odpowiadasz wtedy za wszystko. Jak coś spier** to nie ma że mgr zły, cała wina idzie na Ciebie. Jak się uda - to wiadomo sukces ma wielu ojców (i matki) :P

Niestety nie mam czasu zeby pogadać na ten temat, może po COVID na jakimś DevDayu czy coś...

Wspominasz, że w 2-3 os praca szła szybciej, a teraz to w scrumie macie opóźnienia. Może to nie jest wina samego scruma, a samej firmy. Ogólnie im większa firma to niezależnie od sposobu zarządzania, komunikacja jest trudniejsza, projekty są bardziej złożone, no też to rzutuje na długość i poziom skomplikowania prac, także tego typu rzeczy to niekoniecznie rzecz jaka wynika z samego scruma, a raczej specyfiki projektów na dużą skalę.

Ogólnie warto też uważać z krytyką scruma, ja tego typu rzeczy wolę zachować dla siebie, bo ogólnie konfrontancja na temat zarządzania gdy jesteś jeszcze devem budzi zwyczajny brak uznania dla firmy dla jakiej pracujesz. Sam scrum jest tylko spoiwem tego jak firma łączy zarządzenie projektem, ludźmi i ogólnie klientem. Wszelkie dziury jakie widzisz to niekoniecznie może być ten "zły scrum", ale ogólnie jakieś słabości/braki jakie ma sama firma, nie warto tego typu rzeczy wytykać, ponieważ to w niczym nie pomaga, tak samo jak pytanie "kto wam tak projekt zrypał?" :-)

Jeśli masz spadki motywacji to być może zbyt wiele wymagasz od siebie lub też zbyt osobiście odbierasz sytuacje w pracy. Jakkolwiek by nie było, to o ile jesteś devem, to pomagasz przy rzeczach technicznych, a nie zarządzeniu ludźmi. Jeśli team nie wyrabia się z pracami to nie martw się, to nie jest Twój problem. To jest to problem leada czy scrum mastera, to oni się na tym znają i to ponoszą za to odpowiedzialność, a nie Ty. Także wyluz i pomagaj rozwiązywać problemy.

Tutaj dodam taką rzecz, że projekty gdzie jest scrum ja akurat lubię ze względu na lajt jaki w nich panuje. Takie projekty są bardziej przewidywalne, są mniej obciążąjące, łatwo przy nich o dobry work life balance.

Dla porównania popatrz na sytuacje z wyceną zadań. W scrumie masz jakieś numerki, poker co by nie było jest trochę dziwne z perspektywy deva, natomiat pomyśl jakby wyglądała Twoja praca gdybyś musiał określić się w godzinach i jeśli przekroczysz czas to dalej robisz frajer. Przy takim zestawieniu scrum wypada nieźle, bo jeśli pomylisz się wycenia to nikt nie robi Ci problemu.

Albo pomyśl jakby Ci się pracowało gdybyś po przekroczeniu terminu ponosił jakieś surowe kary. Jakby się zmienił Twój sposób programowania? Bo ja np. po sobie widzę, że rozwiązania jakie robię najlepsze są wtedy gdy mogę spokojnie o nich pomyśleć, gdy nie ma presji i gdy dobrze orientuje się jak wygląda sytuacja w projekcie. W sytuacji gdzie wszyscy pracują bezmyślenie pod wpływem presji i terminu praca wyglądałaby strasznie, nie raz pewnie musiałbym projekt kończyć w nocy i nie byłby to żaden powód do dumy.

Także bez scruma, i ogólnie takiej rozmytej odpowiedzialności to nie wiem czy mógłbym patrzeć w kierunku bardziej wymagających projektów, i przede wszystkim nie wiem czy dałbym sobie radę z tym na b2b, bo jeśli ilość okazji do kar by się zwiększyła to już wolałbym w ramach pracy komercyjnej klepać jakieś drobne rzeczy do cmsów. Także hejtowany scrum moim zdaniem otwiera drogę do ciekawszych projektów.

Ej, ja tak tylko dodam od siebie, bo widzę że temat spotkań był ruszony, w tym daily.

Jeśli macie daily trwające 15 minut i faktycznie przez te 15 minut omawiacie tematy robocze - jest coś serio nie tak i się nad sobą zastanówcie. Albo jest słaba komunikacja w trakcie dnia (albo jest super komunikacja i się rozgadujecie w trakcie sprintu. Wtedy jest super, tylko nie taki jest cel daily), albo jest Was na tym daily za dużo, albo robicie sobie z daily spowiedź (a potem część teamu może czuć się wręcz zestresowana przed każdym spotkaniem, bo przy spowiedzi czuje się osądzana za efekty i tak dalej). Wy macie pogadać na szybkości żeby było wiadomo, że każdy wie co ma robić. Macie iść do przodu, a nie rozpamiętywać porażki w wielkim gronie, elo i powodzenia w projektach.

Wina jest po twojej stronie, jezeli nie wyrabiasz sie z terminami i nie przekazujesz informacji, ze sie nie wyrobisz albo, ze nie wiesz ile ci to zajmie. Jezeli pojawia sie termin, to mow, ze nie zrobisz tego w takim terminie. Pamietaj, ze Twoje zdanie jest rownie wazne, co jakiegos korpo managera. Ba u mnie sami szacujemy czas, a jezeli ktos go szacuje to mnie to kompletnie nie obchodzi, bo wiem, ze za 1 miesiac moge pracowac gdzie indziej. Gdzie nie bedzie niedoszacowywania projektow przez korpo managerow. Przez nie wyrobienie sie dostalem chyba, ze 3 skargi juz. Stad moim zdaniem bierze sie twoje wypalenie. Poza, tym mam podobne odczucia co do spotkan, zbyt czestych spotkan. One psuja flow w pracy. Obecnie kontakt mam z szefem raz w tygodniu, gdzie moge w pelni sie skupic na zadaniu, a nie odrywac sie niepotrzebnie. Zreszta jezeli ciagle czujesz, ze jestes kontrolowany i ci to przeszkadza i z czasem nikt nie ma do ciebie wiekszego zaufania to zmien firme. Poza tym jezeli nie podoba ci sie retro standup itd, mow o tym na retro po to jest komunikacja.

Wypalenie według mnie bierze się z tego, że czym efektywniej pracujesz w scrumie (tak osobiście i jako cały zespół) tym bardziej jesteś zawalany dodatkową robotą. Zamiast dostawać nagrody, dostajesz natychmiastowe kary. W moim otoczeniu widzę, że dużo bardziej opłaca się nie dotrzymywać terminów, niż dotrzymywać, bo można skończyć robiąc 3x więcej niż inni w tym samym czasie z kolejką chętnych na dorzucanie zadań. Ja niestety tak skończyłem i jest to moja wina bo jestem nauczony robić wszystko w terminie (naleciałość z projektów z project planem). Tak działa agile bo nie ma tam prawdziwego zarządzania projektem, tylko upychanie tasków na wcisk. Trzeba zrobić bagno na wczoraj, to wy to weźcie bo już przecież kończycie.

@The Pontiff: totalnie się zgadzam, pytanie tylko jaka metodyka zarządzania zapewnia wystarczającą ilość pracy bez nagradzania programistów kolejnymi taskami za szybko wykonaną pracę.
Nigdy nie pracowałem w scrumie który działał, ale w idealnym świecie wrzutki w trakcie sprintu nie powinny mieć miejsca, a czas wolny programisty powinien być spożytkowany na techniczne taski, których programista sam się chce podjąć, bo mu przeszkadzają (typu drobny refactoring), ale sprawiają jakąś satysfakcję i są odskocznią od niekończących się tasków biznesowych.

I tak i nie, jeśli zespół zrobił wszystkie taski zaplanowane na sprint to wg scruma znaczy że wziął za mało (co z tego, że taki właśnie scope był ustalany z project managerem i takie właśnie są oczekiwania) więc można legalnie dorzucić kolejne zadania. Najlepiej od innego zespołu, któremu dodanie jednego pola do bazy zajmuje 3 dni.

W waterfallu nigdy czegoś takiego nie doświadczyłem, bo nadgonienie terminów skutkowało po prostu tym, że posuwało się dalej w project planie i ostatecznie developerzy byli nagradzani tym, że pod koniec projektu nie było spiny żeby zdążyć ze wszystkim, albo mogli się skupić na porządnym testowaniu. Nie dało się przerzucać tasków między zespołami w połowie trwania projektu, bo to psuło założony wcześniej project plan którego wszyscy się trzymali, więc nieroby były poganiane żeby nadgonić opóźnienie (mam na myśli prawdziwych nierobów, nie jakieś nieprzewidziane trudności czy źle wycenione taski). Ale w scrumie project plan nie istnieje, są tylko niekończące się taski dorzucane do wora w nieskończoność. +oczywiście cała patologia związana z brakiem analizy wymagań w scrumie, bo po co to robić, skoro można zostawić jednozdaniowy opis zadania developerom.

Aha, tylko w scrumie spotkałem się z tym, że można zarządzać rocznym projektem na 4-5 zespołów przy pomocy tabelki w mailu.

My mamy fajnie to zrobione-> co kwartal planuje sie zgodnie z roadmapa co bierzemy jako zespol do zrobienia przez najblizsze 3 miesiace (uczestniczy w tym caly zespol, scrum i wyceny sa po to zebysmy byli w stanie oszacowac ile rzeczy mozemy zabrac ). Oczywiscie trzeba opracowac zaleznosci od innych zespolow, ryzyka, zrobic dekompozycje itp. Uwzglednia sie przy tym urlopy, jakis zapas na rzeczy ktore moga wpasc, utrzymanie itp. tak zeby nie zaladowac sie taskami pod korek. Taski przypisujemy do sprintow, ale to bardziej po to by bylo wiadomo co w jakiej kolejnosci robic, jak nie ma pilnych priorytetow mozna swobodnie zmieniac. Wazne zeby po 3 miesiacach dowiezc to do czego sie zespol zobowiazal. Spotkania sprowadzaja sie do tego ze mamy daily, ktore jest sensowne, zajmuje tyle co trzeba. Raz w tygodniu godzinne spotkanie nazwijmy to na poziomie departamentu, synchronizacja, ogloszenia, co sie dzieje itp. Jak zespol uzna ze warto, to czasami sobie zrobimy retro (raz na pare miesiecy, bo staramy sie zajmowac problemami na biezaco). Generalnei to naprawde fajnie dziala.

Pracowałem kiedyś w chyba takim "prawdziwym" Scrumie.

Było tak :)

Projekty to były modyfikacje obecnie działającego produktu - serwerek telekomunikacyjny, wszystko w Asemblerze. Modyfikacje te były zamawiane przez klienta i specyfikowane przez (nie wiem jak to nazwać, więc nie wiązać się tego sztywno) OPO o dużej wiedzy technicznej nt. produktu. Następnie każda taka modyfikacja była rozbierana na sub-taski także przez tych OPO-sów z kilkunastoletnim doświadczeniem.
Ja jako Juniorek siadałem z Teamem, braliśmy taski, które Ci sami OPO-si ubierali w ramy czasowe i po prostu robiliśmy je. Tolerancja co do godzin poświęconych na task była spora, ważne, żeby projekt dojechał na czas. Wszystko logowaliśmy na tool-u pisanym przez studentów na praktykach, który był po prostu stronką internetową z tablicą Scrumową.

Każdy taki task składał się z kilku etapów.

1. Kodzenie
2. Code review
3. Functional Tests
4. Integation Test
5. Documentation
6. "Pakowanie" paczki do klienta i ostatnie testy na labie klienta.

Pracowało się super. Wiadomo było z czym zaczynamy, do czego zmierzamy a Sprint trwał dokładnie tyle ile zostało wyestymowane na projekt. Czasem 3 tygodnie, czasem 3 miesiące plus Stand-upy co drugi dzień chyba - 15 min zupełnie niewybijające z pracy - reszta co było potrzebne dogadywane na bieżąco.

Nie wiem czy to był Scrum, ale pomimo starej technologii do dzisiaj wspominam jakie to było wspaniałe i dawało satysfakcję z "dowożenia" projektów :P