Czy to normalne ze trzeba managerowi 100 razy zgłaszać te same rzeczy nad którymi pracujemy?

1

Sytuacja wygląda tak, ze pracuję sobie nad jakimś tematem i kilka razy w tygodniu dzwoni do mnie manager pytając nad czym siedzę, co zrobiłem a co planuję robić. Nie byłoby to dziwne gdybym nie musiał tez uzupełniać w systemie które taski zrobiłem, które są w trakcie. Poza tym co najmniej raz w tygodniu przychodzi to naszego pokoju i pyta o te same rzeczy. Czy on nie jest zbyt nadgorliwy? Wszystkie te jego zabiegi nic nie wnoszą, nic nie przyspieszają, tylko przeszkadzają. Pytałem o to kiedyś po co to wszsytko jak moze sobie na spokojnie w sytemie przeczytać, to mówił, że musi wiedzieć co się w tematach dzieje :D

3

Czemu mu tego nie powiesz co tu napisałeś? Że wszystko jest w jirze i tylko przeszkadza swoimi pytaniami. Jak chce zmienić system pracy, to możecie o tym porozmawiać, ale teraz ma wszystko w jirze i pytanie nic mu nie da.

1

A nie możecie się umówić na konkretne spotkania o określonej godzinie / dniu tygodnia? Wtedy nie będzie stresu, że nagle się odezwie znienacka i będziesz nieprzygotowany.

i kilka razy w tygodniu dzwoni do mnie manager pytając nad czym siedzę, co zrobiłem a co planuję robić.

I tak dobrze, bo standardem w firmach są takie pytania codziennie na standupach.

2
kalimata napisał(a):

Sytuacja wygląda tak, ze pracuję sobie nad jakimś tematem i kilka razy w tygodniu dzwoni do mnie manager pytając nad czym siedzę, co zrobiłem a co planuję robić. Nie byłoby to dziwne gdybym nie musiał tez uzupełniać w systemie które taski zrobiłem, które są w trakcie. Poza tym co najmniej raz w tygodniu przychodzi to naszego pokoju i pyta o te same rzeczy. Czy on nie jest zbyt nadgorliwy? Wszystkie te jego zabiegi nic nie wnoszą, nic nie przyspieszają, tylko przeszkadzają. Pytałem o to kiedyś po co to wszsytko jak moze sobie na spokojnie w sytemie przeczytać, to mówił, że musi wiedzieć co się w tematach dzieje :D

Na bank ma presje z góry żeby tak odwalać.

Wiem, bo kierownikowałem w kilku firmach i tak to wyglądało. Często czułem się z tym źle, ale presja była żeby tak robić z góry i tyle. Nie chciało mi się walczyć z wiatrakami to robiłem.

1
kalimata napisał(a):

Sytuacja wygląda tak, ze pracuję sobie nad jakimś tematem i kilka razy w tygodniu dzwoni do mnie manager pytając nad czym siedzę, co zrobiłem a co planuję robić. Nie byłoby to dziwne gdybym nie musiał tez uzupełniać w systemie które taski zrobiłem, które są w trakcie. Poza tym co najmniej raz w tygodniu przychodzi to naszego pokoju i pyta o te same rzeczy.

Manager od "zarządzania" przez chaos, czyli wcale...
Bywa i tak.

Czy on nie jest zbyt nadgorliwy?

Z jego punktu widzenia wszystko jest OK.

Wszystkie te jego zabiegi nic nie wnoszą, nic nie przyspieszają, tylko przeszkadzają. Pytałem o to kiedyś po co to wszsytko jak moze sobie na spokojnie w sytemie przeczytać, to mówił, że musi wiedzieć co się w tematach dzieje :D

Takim nadgorliwcom wysyłam linka do JIRA gdzie jest wszystko napisane czarno na białym.
Jak pyta na żywo, to mówię że nie mam nic więcej do dodania ponadto, co tam napisano.
Jak pyta znowu, to znowu wysyłam linka.

To jest tzw. pętla Briana opisana w książce "Wykrywacz prawdy. Praktyczny przewodnik agentów FBI." ;-)

8

Micromanagement pełna parą widzę. Ja bym nie wytrzymał psychicznie takiego pytania non-stop o status.

3

Jeżeli więcej niż raz na dzień to bym pogadał, albo się zwolnił.

3

Jak mnie jedna managerka (Hiszpanka) tak męczyła co 2-3 dni, to raz jej na teamsach napisałem, że musimy zoptymalizować jakieś tam komponenty m.in. "flux capacitor". Ona to do klienta dalej przekazała (jako status update). Jak jej potem ktoś powiedział, o co chodzi, to już miałem z nią spokój. Teraz innymi PM-om takie coś wysyłam (w mejlach gdzie jest dużo osób na CC): https://ifunny.co/picture/news-parrot-is-learns-how-to-say-how-s-progress-tcrahjpg8 oczywiście wszystko w ramach żartów ;)

4

Po to są właśnie standupy (czy jak je tam nazwać) żeby między innymi każdy zainteresowany miał wgląd w to co się dzieje. Manager którego opisujesz wydaje się mikro zarządzać i nie ufać zespołowi. Na początek najlepiej zaproponuj codziennie spotkania zespołu.

1

Ostatnio poruszałem temat ten temat wśród znajomych co robią w korporacjach m.in kuzynka robi jako AML Specialist, znajomy jako Accountant, jeszcze jeden znajomy jako Finance Analyst i jak powiedziałem im o tych estymacjach i mówieniu statusu codziennie to robili wielkie oczy. Kuzynka jako AML Analyst ma spotkania w zespole raz na tydzień. Znam też DevOpsow co mają podobnie. Nie wiem skąd się wziął taki trend by aż taka presję na Devach wywierać.

2

Nie. To patologia.

4

to atak DoS, gdy manago wysyła z zapytaniem też podwładnych, to atak DDoS

1

Odpowiadaj numerami z jiry czy czego tam używacie. I czasami dawaj randomowe numery aby sprawdzić czy sprawdza xD.

0

A jak macie codzienne standupy to i tak musicie uzupełniać statusy w systemach? Po co to w takim razie jak to ciągłe powtarzanie tej samej roboty. No chyba ze manager nie uczestniczy w tym .

1

Tak. Sa bardziej wkurwiające rzeczy np musze wpisac w 3 systemach 8h w kazdym dniu. Jeden system na podstawie którego wyplacana jest pensja, drugi na podstawie którego idze faktura do klienta a 3 system jest u klienta. Żeby było śmieszniej dość często mi sie coś nie zgadza bo sie machnę przy przepisywaniu np wolnych albo zapomne w ktoryms tygodniu wpisac wszedzie 8 xD.

1

To nie jest normalne. Zwykle narzekamy w drugą stronę, że menago traci kontakt z zespołem przez nadmiar spotkań.

Może wystarczy mu dać coś do zrobienia?

3

Ja to mam wrażenie, ze ta branża jest chora psychicznie. Pracowałem przez prawie dwa lata w różnych projektach z takim co dzwonił do wszystkich przed standupem, 45 minut standupu, dzwonił do wszystkich po standupie żeby się upewnić czy dobrze zrozumiał albo żeby wyjasnic bo nie zrozumiał. Do tego jeszcze w ciągu dnia, bo misi wiedzieć jaki status. A spróbuj pójść na obiad i nie odebrać to 10 nieodebranych gwarantowane + SMS ze pilnie trzeba porozmawiać. Dzwonił te czasami poinformować ze wysłał mIla, właściwie to często dzwonił po to samo a później się dziwił czemu tak powoli idzie praca.

Ten typ był ekstremum, ale właściwie zdecydowana większość menagerow robi niepotrzebne (hehehe, nie mogę z tej nazwy) ceremonie. Daily, grooming, planing techniczny, retro, f2f i pełno gowna które nie wiadomo po co jest.

Ja się czasem zastanawiam czym programiści zawinili, czemu wszystkie pozostałem branże tego nie maja, a programiści zawsze. Czy nasi dziadkowie zawinili zbytnim leczeniem w kulki, czy może ktoś wymyślił ze t doskonały sposób na leczenie autyzmu. Nie wiem. Jestem załamany tym, ze to wyglada jak wyglada i nie ma szans na poprawę

6

Ludzie, gdzie Wy znajdujecie takie sadystyczne środowiska pracy?

Daily to nie jest duży problem, to 15 minut maksymalnie, planowanie/grooming z raz w tygodniu jest raczej niezbędne, jeśli nie chce się być klepaczem, wiedzieć co się robi i nie być zaskoczonym robotą. PM na daily czasami bywa, na spotkaniach technicznych nie, bo po co?

W ogóle z PMem gadałem chyba tylko raz jak dołączył do firmy i dzwonił po wszystkich członkach zespołu, żeby się po prostu przedstawić i przywitać.

4

Jeśli pracujesz w scrumie to tak, patologia. A tak całkiem poważnie, codzienne statusowanie jest raczej chlebem powszednim (daily). Jeśli to mu nie wystarcza, to warto poruszyć temat na retro i spróbować znaleźć konsensus.

0
szprotki_w_oleju napisał(a):

Ten typ był ekstremum, ale właściwie zdecydowana większość menagerow robi niepotrzebne (hehehe, nie mogę z tej nazwy) ceremonie. Daily, grooming, planing techniczny, retro, f2f i pełno gowna które nie wiadomo po co jest.

@szprotki_w_oleju:
Ale zdecydujcie się w końcu. Albo wyścig szczurów i estymowanie zadań w mandayach przez management, albo zespół je estymuje. I jak niby ma być robiona ta estymacja bez spotkania? PO ma się domyśleć? Później płacz na forum bo manager mówi, że pracuję za wolno. A jeżeli masz szansę pracować w scrumie gdzie się gra zespołowo i nie liczysz mandayów tylko zespół sam podaje estymaty w storypointach i jest czas na refaktoring to znowu płacz bo trzeba rozmawiać z kolegami z pracy i mieć jakieś retrospektywy.

Weźcie może przeczytajcie w końcu jakąś książkę o zarządzaniu projektami IT, a nie popisujcie się swoją ignorancją. Czasy piwniczaków się skończyły. Jesteście dinozaurami.

7

Ale zdecydujcie się w końcu. Albo wyścig szczurów i estymowanie zadań w mandayach przez management, albo zespół je estymuje.

@twoj_stary_pijany: to lepiej menagement niech przeczyta jakąś książkę. Skoro zespół decyduje to, po co jest tech leader, team leader, scrum master i PM? Po co robią demo, na którym to programiści pokazują co zrobili? Po co robią daili skoro na żywo widza na tablicy postęp? Ach pewnie po to, żeby każdy mógł powiedzieć czy napotkał jakieś problemy jednocześnie wprowadzając zakaz rozmowy o problemach, bo 15 minut? Wiesz co mi powiedział kiedyś scrum master jak powiedziałem, że nie wiem jak coś zrobić zadanie? "Jak zamierzasz rozwiązać ten problem? Nie wiem, nie umiem tego, nie wiem o co chodzi. Kto ci może pomóc? nie wiem, nie rozumiem o co chodzi, nie znam technologii. Spróbuj znaleźć kogoś, kto ci pomoże, ale po daili, lecimy dalej" - jak wybronisz potrzebą posiadania takiej osoby?

Biznes powinien dać priorytety i czekać na wycenę, a zespół powinien sam sobie wycenę zrobić. Ale tak się nie dzieje, to jest rzadko spotykana sytuacja. Oni wszyscy w większości się wpierdalają i grają w jakieś korpo gierki trując życie.

Ja teraz codziennie mam jakieś scrumo agilowe spotkanie poza daili. I nie rozumiem po co jestem wołany na godzinę, bo w jednym zadaniu mają jakiś problem i nie wiadomo jak rozwiązać. Po co tech lead jest w takim razie, po co architekt? Po co jest scrum master skoro codziennie jest losowany programista, który udostępnią ekran z tablicą, po co jest tablica skoro i tak ciągle się spowiadasz z postępu? Po co jest PM skoro i tak często musisz samemu się domyślać/dowiadywać bo te ich opisy są często zbyt ogólne?

Ja wiem jaka jest teoria, szkoda, że niewiele ma wspólnego z życiem. Wiem, że mogę zmienić pracę, nawet zmieniłem, teraz mam 3 spotkania po 30 minut dziennie zamiast jednego ponad godzinę. Może źle trafiłem? Możliwe, szkoda, że 4 na 5 firm źle mi się trafiło.

Nie wiem czemu mówisz pwniczaki o programistach, ale w przypadku menadżerki czy ogólnie "biznesu" nie mówisz o uzależnieniu od spotkań i potrzebie wykazania się wszelakim kosztem? Czemu ludzie dostrzegają bezsensowność owocowych wtorków, ciastowych śród i zupnych czwartków, ale nie dostrzegają bezzasadności scuma? Kanapkowe poranki też są doskonałe w teorii, ale w praktyce nie przekładają się na nic poza kolejkami w kuchni

0
szprotki_w_oleju napisał(a):

Ale zdecydujcie się w końcu. Albo wyścig szczurów i estymowanie zadań w mandayach przez management, albo zespół je estymuje.

? Wiesz co mi powiedział kiedyś scrum master jak powiedziałem, że nie wiem jak coś zrobić zadanie? "Jak zamierzasz rozwiązać ten problem? Nie wiem, nie umiem tego, nie wiem o co chodzi. Kto ci może pomóc? nie wiem, nie rozumiem o co chodzi, nie znam technologii. Spróbuj znaleźć kogoś, kto ci pomoże, ale po daili, lecimy dalej" - jak wybronisz potrzebą posiadania takiej osoby?

Posiadanie takiej nieporadnej osoby faktycznie ciężko jest wybronić, ja bym na pewno nie zatrudnił gdybym usłyszał tę historię na rekrutacji.

3

Trzeba podkreślić, że etat scrum mastera nie jest pernamentny. Takiego osobnika zatrudnia się z reguły do max 6 msc, żeby nauczył zespół samoorganizacji i "dobrych praktyk".
Scrumem też gardzę, ale nie można zaprzeczyć, że jego implementacja różni się w każdej firmie. W jednych działa sprawniej w innych gorzej. Te natłoki spotkań to nie wina scruma, tylko samej organizacji (a raczej dezorganizacji).

4
szprotki_w_oleju napisał(a):

Skoro zespół decyduje to, po co jest tech leader, team leader, scrum master i PM? Po co robią demo, na którym to programiści pokazują co zrobili? Po co robią daili skoro na żywo widza na tablicy postęp?

Tech lead jest od tego, żeby mieć decydujący głos w wyborze technologii. Scrum Master jest od tego, żeby ludzie się dogadywali. Demo jest od tego, żeby wszyscy mieli świadomość, że dostarczają coś co działa i ma jakąś wartość dla biznesu, bez tego wielu fajnych ludzi po prostu odchodzi z pracy bo mówią, że nie widzą rezultatów swojej pracy.

Nie jestem fanem pozycji typu team leader oraz PM więc nie będę o nich opowiadał.

Ach pewnie po to, żeby każdy mógł powiedzieć czy napotkał jakieś problemy jednocześnie wprowadzając zakaz rozmowy o problemach, bo 15 minut?

Ta zasada ma bardzo mądre uzasadnienie. Scrum Master ma czuwać nad balansem rozmowy, żeby każdy miał szansę się wypowiedzieć, a nie, żeby jeden @szprotki_w_oleju dominował rozmowę.

Wiesz co mi powiedział kiedyś scrum master jak powiedziałem, że nie wiem jak coś zrobić zadanie? "Jak zamierzasz rozwiązać ten problem? Nie wiem, nie umiem tego, nie wiem o co chodzi. Kto ci może pomóc? nie wiem, nie rozumiem o co chodzi, nie znam technologii. Spróbuj znaleźć kogoś, kto ci pomoże, ale po daili, lecimy dalej" - jak wybronisz potrzebą posiadania takiej osoby?

Nawet gdyby ten Scrum Master znał odpowiedź to jego pomoc powinna wyglądać tak jak to opisałeś. To dlatego ponieważ dając Ci odpowiedź na tacy by produkował kolejnego bezmyślnego juniora, któremu trzeba pokazać palcem co ma zrobić i nawet jak skończy zadanie to zrobi to źle bo zawsze bierze wszystko dosłownie zamiast wykazać się inicjatywą. Zamiast tego, Twój Scrum Master chciał stworzyć z Ciebie lidera, a nawet nie potrafiłeś tego docenić.

Nie wiem czemu mówisz pwniczaki o programistach, ale w przypadku menadżerki czy ogólnie "biznesu" nie mówisz o uzależnieniu od spotkań i potrzebie wykazania się wszelakim kosztem?

Nawet nie wiesz jak tępię w pracy tych wszystkich, którzy, żeby iść do kibla potrzebują zorganizować spotkanie na 20 osób. Trudność polega na tym, że po jednej stronie mam developerów, którzy krytykują scruma bo mają za dużo spotkań, a po drugiej mam management, który krytykuje scruma bo nie wiedzą co się dzieje i chcą więcej spotkań. Obie strony odsyłam do literatury. Scruma jest najprościej wytłumaczyć. Wyobraź sobie, że miałbym wprowadzić jakiś swój własny framework w środowisku w którym nikt nie czyta w ogóle książek o zarządzaniu. Po prostu nie potrafisz się postawić w położeniu osób, które krytykujesz. Ja nie jestem w Twoim projekcie więc nie będę adwokatem Twoich leadów. Mówię po co są te wszystkie rzeczy. To, że u Ciebie panuje kult cargo to nie jest moja wina. U mnie wszystkie spotkania mają swoje uzasadnienie i jestem w stanie do każdej zasady podać uzasadnienie, a także książkę która mówi dlaczego coś jest tak, a nie inaczej.

Czemu ludzie dostrzegają bezsensowność owocowych wtorków, ciastowych śród i zupnych czwartków, ale nie dostrzegają bezzasadności scuma? Kanapkowe poranki też są doskonałe w teorii, ale w praktyce nie przekładają się na nic poza kolejkami w kuchni

Problem z kanapkowymi czwartkami jest taki, że programiści są tak głupi, że to działa. Nie moja wina, że ludzie sprzedają swoją godność za darmowe jabłko raz na tydzień. Jednego programistę złapiesz na ubezpieczenie medyczne, drugiego na obiady, trzeciego na bonus uznaniowy, a czwartego na udziały warte 0 zł 0 gr.

6
szprotki_w_oleju napisał(a):

Ja to mam wrażenie, ze ta branża jest chora psychicznie.

Trochę masz rację, trochę nadinterpretujesz. Problem leży w tym, że większość managerów w IT nie ma zielonego pojęcia o IT. Nie piszę o tym, że nie potrafią zrobić tego co ich ludzie, ale zwyczajnie nie mają żadnej praktycznej wiedzy o wytwarzaniu oprogramowania. Mieli jakieś stanowisko w wytwórni konserw, zrobili kurs z zarządzania projektami IT i zwyczajnie błądzą po omacku. Ogólnie siedzę w aktualnej firmie i nie wybieram się nigdzie głównie z powodu, że ryzyko trafienia na szefa-debila jest równe zero. Miałem już w swojej karierze całkiem sporą liczbę managerów-mew. Wszędzie przyleci, wszędzie nasra i nic nie zrobione bo musi lecieć dalej.

Pracowałem przez prawie dwa lata w różnych projektach z takim co dzwonił do wszystkich przed standupem, 45 minut standupu, dzwonił do wszystkich po standupie żeby się upewnić czy dobrze zrozumiał albo żeby wyjasnic bo nie zrozumiał.

Patrz wyżej - jak jest ślepy, to dzwoni po ludziach, żeby się dowiedzieć czego nie rozumie. Zwykle to i tak niczego nie daje, bo na aktualnym poziomie wiedzy, zwyczajnie nie jest w stanie zrozumieć, dlaczego musisz się zająć np. problemem z repozytorium, a nie dostarczeniem jakiegoś super ważnego ficzera. A nawet jak się akurat tym ficzerem zajmujesz, to nie zrozumie dlaczego coś tak prostego, że był w stanie to ogarnąć (albo mu się tak wydaje), może wymagać dużo pracy.

Do tego jeszcze w ciągu dnia, bo misi wiedzieć jaki status. A spróbuj pójść na obiad i nie odebrać to 10 nieodebranych gwarantowane + SMS ze pilnie trzeba porozmawiać. Dzwonił te czasami poinformować ze wysłał mIla, właściwie to często dzwonił po to samo a później się dziwił czemu tak powoli idzie praca.

Odbierasz i grzecznie mówisz, że tak, robisz i jesteś 30 minut dalej niż 30 minut temu, kiedy pytał poprzedni raz. Następnie obiecujesz, że gdyby wystąpiły jakieś poważne przeszkody, to niezwłocznie dasz mu znać.

Ten typ był ekstremum, ale właściwie zdecydowana większość menagerow robi niepotrzebne (hehehe, nie mogę z tej nazwy) ceremonie. Daily, grooming, planing techniczny, retro, f2f i pełno gowna które nie wiadomo po co jest.

"Ceremonia" to niestety bardzo dobre określenie. Bo w większości przypadków "ceremoniał", czy "liturgia" ma większe znaczenie, niż wykonanie jakiejś konkretnej roboty. To nie oznacza, że ta praca jest zbędna i bez sensu, a jedynie, że jest wykonywana w sposób nieefektywny (lub wcale). Ogólnie uważam, że warto robić takie rzeczy jak:

  • bieżące sprawdzanie czy ktoś z czymś nie walnął w ścianę, nie potrzebuje pomocy i wie co ma robić
  • przeczytać, przegadać i uzupełnić historyjki, żeby wiedzieć co ma zostać zrobione
  • przegadanie ogólnego kształtu systemu, uzgodnienie jakich narzędzi, metod, bibliotek należy użyć
  • okresowe przegadanie co jest najbardziej zrąbane w projekcie i uzgodnienie działań w celu usunięcia tych przeszkód

To są prawdziwe cele tych "ceremonii". Te rzeczy trzeba, albo przynajmniej warto robić. Problem w tym, że wyskakuje ci z tym pomysłem ktoś, kto go nie zrozumie, a przeczytał jedynie jakiś komiks i próbuje dorosłych ludzi wciągać w zabawy rodem z przedszkola i to z innego kręgu kulturowego. Możliwe, że u hindusów, czy amerykanów trzeba jakoś delikatnie naprowadzać na temat karteczkami, kalamburami itp. u nas zwykle nikt nie ma większego problemu z przyjęciem na klatę bezpośredniej krytyki. Ogólnie problem z tymi spotkaniami jest taki, że "facilitator" i często uczestnicy nie mają zielonego pojęcia po co to się robi i zamiast siąść i "get the shit done" bawią się w jakieś głupoty właściwie nie wiadomo po co. Z drugiej strony mając takie retro, warto wyskoczyć z problemem typu "połowa mojego czasu to czytanie managerowi co jest napisane w dźirze".

Ja się czasem zastanawiam czym programiści zawinili, czemu wszystkie pozostałem branże tego nie maja, a programiści zawsze. Czy nasi dziadkowie zawinili zbytnim leczeniem w kulki, czy może ktoś wymyślił ze t doskonały sposób na leczenie autyzmu. Nie wiem. Jestem załamany tym, ze to wyglada jak wyglada i nie ma szans na poprawę

Są szanse na poprawę. Trzeba zwyczajnie użyć dostępnych narzędzi (masz ich w nadmiarze nawet) do wyciągnięcia problemów na wierzch.

--edit
Jeszcze praktyczna rada, jak sobie radzić z nadmiarem zainteresowania ze strony managera. Miej przygotowaną listę tematów, w których oczekujesz od niego pomocy. Dostęp do czegoś, licencja na coś, zakup sprzętu, skontaktowanie się z kimś tam po coś tam, pytania biznesowe. Jak do ciebie dzwoni, to przy okazji zlecaj mu takie prace i pytaj o postępy z tym co zleciłeś wcześniej.

2
  1. Znajdź 20 różnych firm, w których każdy projekt używa Scrum'a i ma Scrum mastera
  2. Rzuć jakiś temat
  3. Dostań 20 różnych odpowiedzi.
5

Tak w ramach ciekawostki trochę w temacie.
Pracowałem kiedyś w projekcie, w którym było kilka mocno nietechnicznych, niezorientowanych w projekcie osób, ale miały duże parcie na to żeby być na bieżąco ze wszystkim. Na moje nieszczęście pracowałem stacjonarnie.

No i tak. Jem sobie obiad w kuchni. Jedyny moment kiedy chcę w ciszy pooglądać w samotności śmieszne koty na telefonie i do nikogo się nie odzywać.

Dosiada się TL z obiadem... zaczyna coś pieprzyć o projekcie
Dosiada się devops, zaczyna pieprzyć o projekcie (ten sam obszar)
Przychodzi PM - przyłącza się do rozmowy, wywiązuje się bardzo burzliwa dyskusja i burza mózgów.

W końcu PM: "to słuchajcie chłopcy, jak już nam się zrobiło tu takie fajne spotkanie o konkretach to zadzwonię jeszcze po Łukasza."

Przychodzi Łukasz.

<już tłok jak sk**syn> burza mózgów, a ja nie mam kiedy widelca do ryja wsadzić, bo ciągle coś pytają.

W końcu od PM pada magiczne: "dobrze chłopcy to musimy KONIECZNIE ZROBIĆ SPOTKANIE. Wszyscy mają czas o 13:00?"

I to taka sytuacja jedna z wielu :)

Incepcje spotkaniowe, spotkania, na których planowano inne spotkania, które ewoluowały w kilka mniejszych spotkań xD

Tam to nie wiem czy 30% czasu to była faktyczna praca, bo od spotkania do spotkania zawracanie d**y i omawianie całymi grupami byle gówien zajmowały większość czasu, a wiadomo, że po takim spotkaniu chcesz chwilę odpocząć, zapalić kiepa, wypić kawę, co kto lubi.

Wykończyłbym się w takim czymś na dłuższą metę.

3
Fanquilen napisał(a):
szprotki_w_oleju napisał(a):

Ale zdecydujcie się w końcu. Albo wyścig szczurów i estymowanie zadań w mandayach przez management, albo zespół je estymuje.

? Wiesz co mi powiedział kiedyś scrum master jak powiedziałem, że nie wiem jak coś zrobić zadanie? "Jak zamierzasz rozwiązać ten problem? Nie wiem, nie umiem tego, nie wiem o co chodzi. Kto ci może pomóc? nie wiem, nie rozumiem o co chodzi, nie znam technologii. Spróbuj znaleźć kogoś, kto ci pomoże, ale po daili, lecimy dalej" - jak wybronisz potrzebą posiadania takiej osoby?

Posiadanie takiej nieporadnej osoby faktycznie ciężko jest wybronić, ja bym na pewno nie zatrudnił gdybym usłyszał tę historię na rekrutacji.

Pytanie jest jeszcze jak duża jest przepaść technologiczna. Jak zadanie jest z Javy a programista JavaScriptu i nie umie wykonać zadania to znaczy że jest nieporadny? A jak zadanie jest z Reacta a programista Angulara i nie umie wykonać zadania to nzaczy że nieporadny?

Jak zwykle wraca pytanie ile można oczekiwać od programisty. Czy programista Javy ma bez mrugnięcia okiem brać taska w Pythonie, JS, Lua, Bashu czy innym C# bo akurat taki wpadł i trzeba zmienić coś w mini aplikacji towarzyszącej?

Ja niby programistą Scali teraz jestem, no ale jak jest coś w Pythonie to mam zmienić, i jak jest coś w Lua to mam zmienić, i jak jest coś w Bashu to mam zmienić, i jak jest coś w PgSQLu to mam zmienić itd itp Dobrze że w JSie nie musze jeszcze robić bo bym tym rzucił w cholerę :D

BTW ja już w innym temacie pisałem że miałem kilka miesięcy temu zadanie niewykonalne. przypadkowo przeszło grooming-sruming i dopiero jak się spojrzało w technikalia to było widac że niewykonalne. testerka-scrummasterka cisneła że zadanie trzeba dowieść przed wydaniem wersji. Dopiero jak lider się jej spytał jak ma zamiar to przetestować to stwierdziła że niewykonalne. Wprowadziło to pewną konsternację na daily a potem odbyło się milion spotkań z klientem o co właściwie mu chodzi.A zadanie zostało nawet wyestymowane na 3 SP bo to przecież prosty raport jest

3
KamilAdam napisał(a):

Pytanie jest jeszcze jak duża jest przepaść technologiczna.

IMO to nie jest coś co decyduje. Z jednej strony jest zespół, ma swoje umiejętności. Z drugiej strony jest biznes, projekt ma swoje wymagania i potrzeby. Przykład - coś się zrąbało w bazie danych, albo trzeba pilnie zrobić jakąś stronkę. Nikt w zespole nie ma pojęcia "jak", ale przecież nie będziemy czekać 3-4 miesiące aż być może uda się zatrudnić kogoś, kto się zna. Ważne, żeby zrobić to z głową, czyli z jednej strony nie zmuszać kogoś do robienia jakiegoś zbuka, od którego wszyscy uciekają, z drugiej zdawać sobie sprawę, że jak ktoś powiedział "OK, spróbuję, nie mam pojęcia ile czasu mi to zajmie", to nie zobowiązał się, że mu się uda to zrobić. Ważne jest wytworzenie w zespole przestrzeni na błędy i w miarę komfortowego środowiska do powiedzenia "dobra panie i panowie, poległem, potrzebuję pomocy". W agile za dostarczenie wartości odpowiada zespół i dla mnie nie jest to frazes. Sytuacja w której komuś wciska się robotę na siłę, mówi "dasz radę", a później się go ściga, bo jednak nie dał, jest mocno toksyczna. Ogólnie nie polecam tworzenia środowiska pracy, w którym ktoś zostaje porzucony sam z problemem.

BTW ja już w innym temacie pisałem że miałem kilka miesięcy temu zadanie niewykonalne. przypadkowo przeszło grooming-sruming i dopiero jak się spojrzało w technikalia to było widac że niewykonalne. testerka-scrummasterka cisneła że zadanie trzeba dowieść przed wydaniem wersji. Dopiero jak lider się jej spytał jak ma zamiar to przetestować to stwierdziła że niewykonalne. Wprowadziło to pewną konsternację na daily a potem odbyło się milion spotkań z klientem o co właściwie mu chodzi.A zadanie zostało nawet wyestymowane na 3 SP bo to przecież prosty raport jest

Grooming jest potrzebny. Z moich obserwacji wynika, że w miarę zdobywania doświadczenia, przeszliśmy od "no dobra, mniej-więcej wiadomo o co chodzi, dopytamy w trakcie", do poziomu mocno technicznego, czyli historyjka jest ogarnięta, jeżeli jest potrzeba, to jest w niej też zapisane co i jak konkretnie zrobić.

3

Nie. W normalnej firmie nie jest normalne. Obstawiam bez czytania wątku, że Twoim managerem jest polaczek... Ja bym uciekał.

1 użytkowników online, w tym zalogowanych: 0, gości: 1