Jak przydzielacie czas na zadania

Załóżmy że zespół ma do zrobienia jakąś aplikacje lub dodanie funkcjonalności do już istniejącej.
Mam 3 osobowy zespół i naturalnym wydaje mi sie zeby wspolnie przeanalizować probelm, podzielić go na jakieś mniejsze części gdzie mozna by w przyblizeniu okreslić ile takie podzadania mogą zająć. Suma czasow tych podzadan dała by przyblizony czas całego zadania (do tego dodać jeszcze jakies 30% bufora czasowego).
Tak bym to widzial. A jest u mnie zupełnie inaczej.

PM, człowiek nietechniczny, rzuca jakis temat i sam narzuca czas realizacji od razu całego tematu. Zawsze po takiej rozmowie ten czas udaje sie nieco zwiekszyc ale dalej to jest czas z d**y nie majacy w niczym pokrycia. To jest takie przebijanie wartosci, bo nie daje nam czasu zeby usiasc zespołem przeanalizować problem i spróbować określić przybliżony czas, tylko wszystko ustala sie na jednogodzinnym spotkaniu. On rzuca swój czas, my podbijamy sowimi wartościami i on z tego w końcu wyciąga jakąś wartość z d**y, raczej zbliożoną do jego propozycji. Najlepsze ze my próbujemy podać czas samego kodowania a dla niego nie ma dyskusji tylko jest to czas łącznie z zaprojektowaniem, programowaniem i przetestowaniem. Najlepsze jest to ze jescze nic nie udało sie dowieźć w tym jego czasie i wtedy jest mocno rozczarowany.
To chyba nie jest normalna sytuacja? Jak u was sie odbywa szacowanie czasu projektu? Firma zajmuje się intergracją rozwiązań IT(głównie wsparcie i integracja systemów ERP, utrzymanie i tworzenie aplikacji u klientów itp). Projekty mamy raczej małe i średnie, często trafia sie utrzymanie i grzebanie w technologiach, których zespół nie zna.

To chyba nie jest normalna sytuacja?

Trafia temat na stół. Obgadywana jest funkcjonalność (historyjka, czy ich grupa) i każda z osobna wyceniona przez zespół developerski. Potem na tzw. sprint trafia tyle mięsa ile się da przerobić bazując na poprzednich sprintach.

Nie sztuką jest zaplanować sobie zadań nie wiadomo ile i potem 2/3 nie dowieźć, tylko tak zaplanować aby zrealizować wszystko.

Najlepsze jest to ze jescze nic nie udało sie dowieźć w tym jego czasie i wtedy jest mocno rozczarowany.

Jak koleś nie wyciąga wniosków, to dla mnie jest idiotą oderwanym od rzeczywistości.

Wieje trochę patologią i jedyne co możesz zrobić poza wywiezieniem gościa do lasu, to się zwolnić. Po co kopać się z koniem?

To, że klient, czy ogólnie osoba nietechniczna, oczekuje, że podasz mu czas na całość, łącznie z projektem i testowaniem to nic dziwnego.
Wyobraź sobie, że dajesz auto do mechanika, opisujesz w ciągu pół godziny, co się dzieje, albo co jest do zrobienia, on Ci mówi, że robota zajmie 1 dzień, a jak przychodzisz kolejnego dnia, bo potrzebujesz już auto, to okazuje się, że 1 dzień to sama zmiana części miała być, ale jeszcze potrzebuje czas na znalezienie przyczyny, zamówienie części, dostawę części, jazdę próbną, poprawki po jeździe próbnej itp. Nie tego oczekujesz, Ciebie obchodzi to, że na 99% odbierzesz auto w tym tygodniu. Nawet jak jest to typowa sprawa, typu wymiana oleju, to widząc starszy albo nieznanej sobie marki samochód, dobry mechanik powie, że może się okazać, że np. korek jest zapieczony itp. i wtedy to wg niego potrwa o tyle dłużej ale da znać jak się upewni.

A co do naszych estymacji, to jeżeli robimy coś, czego w projekcie jeszcze nie robiliśmy, albo np. mamy do użycia nową bibliotekę, to praktycznie zawsze dogadujemy z klientem, że najpierw będzie zadanie na research, a potem damy odpowiedź o wielkości zadania. Im więcej niewiadomych, tym większe zadanie na research, ale nigdy nie będzie się miało 100% informacji, więc też nie może takie szukanie złożoności zadania trwać np. 2 tygodnie, po prostu w pewnym momencie dajemy jakąś wartość powiększoną o te 30-50% na niespodziewane przypadki, które zawsze występują.
I nawet w tym momencie siedzę na spotkaniu, gdzie wspólnie z klientem podjęliśmy decyzję, że jedna rzecz będzie odłożona, bo mamy za mało informacji i pomysłów, a kolega prezentuje wynik research, w poszukiwaniu odpowiedniej biblioteki do zadania i opowiada jakie są wady i zalety różnych rozwiązań i ile wg niego zajmie wdrożenie każdej z nich.

Kwestia też relacji jakie są - zazwyczaj widziałem takie patologie, kiedy nie było zaufania na linii klient-zespół. Jak nie ufa, że mówicie mu realne wartości, to po prostu będzie rzucał jak najmniejsze, z nadzieją, że po prostu pod presją dowieziecie jak najwięcej.

Jest też ten mały procent patologii i niereformowalnych ludzi, ale wg mnie częściej się okazuje, że to nie patologia, tylko problemy, które wynikają z jakichś wcześniejszych doświadczeń, albo konfliktów.

PM, człowiek nietechniczny, rzuca jakis temat i sam narzuca czas realizacji od razu całego tematu.

To walisz mu luja ogłuszacza i mówisz ze jak jest takim kozakiem to niech siada i zaklepie w tym czasie.

Estymacje tasków technicznych należą do programistów a nie do PMa, szczególnie nie-technicznego.

W okrótkich słowach: masz w firmie pato PM który w dodatku wydaje się być nierefolmowalny. Są trzy opcje:

• Albo wywalą pato PM
• Albo przywykniesz
• Albo zmienisz pracę

Tak, wiem ze to zalatuje patolą. Ale liczyłem że podzielicie się jak to wygląda u was. Jestem ciekawy czy w innych firmach integratorskich też to tak wygląda.

Jestem ciekawy czy w innych firmach integratorskich też to tak wygląda.

Nie pracuję w firmie integratorskiej ale wygląda to tak że Produkt Owner daje story, team ma pytania, na groomingu są interesariusze (w uproszczeniu klienci) którzy wiedzą jak to ma być zrobione. Męczymy ich pytaniami tak długo aż nie mamy pytań. Potem PO uruchamia pokera. Jak jest równa estymata przez wszystkich to PO to wpisuje. Jak ktoś się wybija w górę to PO pyta się go czemu tak dużo. Często wybijający się przekonuje resztę zespołu że to musi być tak dużo

kalimata napisał(a):

Najlepsze jest to ze jescze nic nie udało sie dowieźć w tym jego czasie i wtedy jest mocno rozczarowany.

Jak to jedyne co was spotyka to nie ma sie czym przejmować. W mojej poprzedniej robocie jak ktoś spoza zespołu próbował wpływać na estymaty to spotykał się ze znacznym sprzeciwem.

Jestem ciekawy czy w innych firmach integratorskich też to tak wygląda.

W żadnej normalnej tak to nie wygląda

U mnie nikt nie bawi sie w jakieś szczegółowe estymacje czasowe a już na pewno nie żaden manager. Product Owner / Project Scientist wyznacza priorytet ficzerów w backlogu, a my siadamy zespołem i rozkminiamy co jesteśmy w stanie dowieźć przez następne 2 tygodnie a potem komunikujemy to, a pod koniec sprintu robimy demo.

U mnie jak już ktoś sie bawi w czasowe estymaty to czy coś zajmie poniżej tygodnie, 1-2 tygodnie lub powyzej 3 tygodni.
Ale zazwyczaj to są SP bo po parunastu sprintach wiadomo ile jest SP per menday.

A przy takije patologi to trzeba mówić czas na zadanie + 30% i obstawiać przy swoim jak ktoś ci mowi ze mniej to mówisz okay tyle mozesz sobie zapisać ale mi zajmie to więcej. Chyba to jest najszybszy sposob nauczenia takich niereformowalnych. Mówienie ile ci to zajmie a co on zrobi z tą wiadomościa to ty już to miej w dupie.

W poprzedniej firmie miałem tak, że PM był od ustalania

• czego chcą od nas stakeholderzy
• jak bardzo to na nich wpłynie, jeśli to zrobimy / jeśli tego nie zrobimy
• za który ficzer bierzemy się w pierwszej kolejności, a co może poczekać na lepsze czasy

PM nie był od nieustannego poganiania i narzucania estymat na taski techniczne. Estymowanie ficzerów - owszem, na zasadzie "dużo roboty" / "mało roboty", a jak już wiedzieliśmy co ma być do zrobienia, to pytał orientacyjnie, jaki termin byłby osiągalny, żeby dać znać stakeholderom. No i tak nam się jakoś utarło, że zamiast widywać PMa raz w tygodniu na planowaniu i demo, to w miarę możliwości uczestniczył w daily i też dawał nam update, mieliśmy od czasu do czasu Zooma ad-hoc żeby coś przegadać - przynajmniej my w miarę szybko dowiadywaliśmy się, co w trawie piszczy, PM nie dowiadywał się o blokerach po tygodniu, jak mu programiści wyskoczyli spod kamienia i ogłosili, że bloker.

Natomiast nie są mi obce sytuacje, gdzie nawet nie wiadomo, co jest do zrobienia, wymagania dopiero gdzieś tam są wymyślane, ale już, już trzeba obiecać na kiedy się dowiezie - przy czym obowiązuje wariant optymistyczny. IMO to nie jest zdrowa sytuacja - no bo jak niby masz estymować nie wiedząc, czy masz zbudować drewutnię czy 30-piętrowy blok? :D Można próbować zakomunikować, że jest zbyt wiele niewiadomych, by powiedzieć cokolwiek.

Razy dwa i jednostka na wieksza :P A na serio i tak sie okazuje ze czlowiek siedzi tydzien nad taskiem za 2, bo sa zaleznosci do innych zespolow, bo security, bo cos nie dziala itp...

Generalnie:
– Słuchaj, jesteś developerem. Powiedz, dlaczego tak często nieprawidłowo szacujecie czas na stworzenie softu?
– Wyobraź sobie, że musisz rozładować ciężarówkę. Ile czasu to zajmie?
– Parę godzin.
– To Kamaz.
– 8 godzin.
– Kamaz załadowany piaskiem.
– 12 godzin
– Nie masz łopaty i narzędzi, tylko ręce.
– 2 dni.
– Na dworze –40.
– 4 dni.
– Kamaz stoi pod wodą.

Kurcze, jakbym czytał w swoich myślach, ale miałem to samo... W sumie w tej nowej firmie co teraz jestem mam to samo. PM z góry w zespole nieraz zakłada że coś powinno trwać np 2 tygodnie i programiści się godzą przez co nieraz po ten widzę że robią nadgodziny za darmo :( sam też tak mam. To już jest patologia, łatwo się mówi że rynek pracownika ale z drugiej strony ciężko się też postawić. Tym bardziej że to się dzieje nawet w normalnych firmach często i takie tematy jak Twój powstaja na tym forum dość często...

Edit, znalazłem sam zakładałem kiedyś podobny wątek bo miałem dość (Jak sobie radzić z presją menedżera jako programista?)