Komunikacja między zespołami

Cześć!

Pracuję w projekcie monolicie jako dev, w którym aktualnie mamy dwa zespoły podzielone po 9 osób. Ostatnio zarówno w jednym jak i drugim zespole działamy w tych samych obszarach aplikacji. Problem jest taki, że jest bardzo słaba synchronizacja/komunikacja między zespołami.

Każdy coś tam działa na swoim podwórku i to generuje chaos w projekcie. Te rozdzielenie na zespoły było głównie po to, żeby nie tracić za dużo czasu na daily. Team leadzi zastanawiają się teraz nad opcją złączenia dwóch zespołów w jeden 18 osobowy. Szczerze to nie jestem do końca przekonany, bo jakoś praca w mniejszych zespołach wydawała mi się lepszą opcją.

Rozmyślam nad opcją, żeby organizować jakieś synchro meetingi pomiędzy zespołami zamiast robić jeden wielki zespół.

Miał ktoś z was podobne doświadczenia i orientuje się jaka jest najlepsza opcja w takim przypadku?

Obstawiam, że macie na tyle dużo ludzi, że przestało to generować zyski, a zaczęło generować straty. Choć tego może lepiej im nie mówić, bo jeszcze pójdą po rozum do głowy i pozwalniają połowę zespołu (co pewnie byłoby racjonalną decyzją).

Rozmyślam nad opcją, żeby organizować jakieś synchro meetingi pomiędzy zespołami zamiast robić jeden wielki zespół.

Zobacz sobie np. event storming. Ogólnie ludzi z wielu zespołów i specjalizacji wrzuca się do jednego pomieszczenia i mogą na karteczkach (specjalnie zakodowanych kolorem) pisać różne elementy projektu i potem wszyscy to widzą, mogą na to jakoś wpływać itp.

Przy czym myślę, że to nie musi być aż tak zaawansowane (wprowadzenie na siłę konkretnej techniki z konkretnymi zasadami, gdzie nawet kolory karteczek są ściśle określone, nie musi być konieczne, ale to, co warto wynieść, to sposób komunikacji i to, że wszystko każdy może zobaczyć to, co ważne z perspektywy innych).

nie do końca rozumiem - to cały jeden zespół pracuje nad jednym taskiem??? Nie macie tego podzielonego na małe fragmenty tak, żeby sobie nie wchodzić w drogę? Ja rozumiem, że od PRa do merga może minąć 3-4 dni ale bez przesady.

abrakadaber napisał(a):

nie do końca rozumiem - to cały jeden zespół pracuje nad jednym taskiem??? Nie macie tego podzielonego na małe fragmenty tak, żeby sobie nie wchodzić w drogę? Ja rozumiem, że od PRa do merga może minąć 3-4 dni ale bez przesady.

Nie, ale chodzi o to, że PBI się pokrywają i np. team A ma coś do zrobienia z dokumentami a potem team B też. No i ja miałem taska z dokumentami i w sumie tylko dzięki testerowi się dowiedziałem, że z teamu A ktoś restrukturyzacje logiki z całymi dokumentami robił w projekcie. Do tego team A ma swoja praktyke kodowania a team B swoja i sie robi taki chaos w kodzie. Po prostu nie ma podziału odpowiedzialności między zespołami i mimo, ze na dwa podzieleni jesteśmy to i tak robimy development w tych samych obszarach. Mam nadzieję, że teraz bardziej rozumiesz.

Powiedziałbym, żeby eskalować problem do przełożonych. Ale to może skończyć się zwolnieniami (po mojemu to za dużo pracowników tam macie i być może najbardziej rozsądna decyzja to pozwalniać z połowę). Jednak wasze szczęście, że ktoś was niepotrzebnie zatrudnił i że procesy są ważniejsze od interakcji (Te rozdzielenie na zespoły było głównie po to, żeby nie tracić za dużo czasu na daily. :D To brzmi jak "stwórz problem i zaproponuj jego rozwiązanie").

No i ja miałem taska z dokumentami i w sumie tylko dzięki testerowi się dowiedziałem, że z teamu A ktoś restrukturyzacje logiki z całymi dokumentami robił w projekcie.

A gdzie jest PM czy ktoś podobny, kto powinien ogarniać, że kilka osób robi coś podobnego? Piszesz, że są tam "team leadzi" - to dlaczego nie skumali, że kilka osób robi to samo?

Ciekawy case, bo ten zespół to wygląda trochę, jakby nikt tym nie zarządzał. Czyli idealny zespół:

• żeby się opieprzać w pracy
• ew. żeby przejąć pałeczkę lidera

Może powinniście się sami organizować? Robić jakieś oddolne spotkania synchronizujące? Nie patrzyć na liderstwo, którego de facto nie ma?

Dalej nie rozumiem - jeśli PBI się pokrywają między teamami to TL/PM/... jest dupa i to nie jest problem podziału zespołów tylko podziału zadań. Co więcej nawet w tym samym teamie mogą być zadania, które są zależne od siebie i nie da się ich robić jednocześnie. Skoro macie jakieś PBI to nie macie planowania, które robicie? Każdy sobie bierze takie, jakie mu pasuje i robi?

PiotrLub napisał(a):

Miał ktoś z was podobne doświadczenia i orientuje się jaka jest najlepsza opcja w takim przypadku?

Podział na zespoły ma sens, jeśli pracują nad innymi rzeczami. Jeśli wszyscy robią to samo, to podział nie ma sensu.

PiotrLub napisał(a):

Rozmyślam nad opcją, żeby organizować jakieś synchro meetingi pomiędzy zespołami zamiast robić jeden wielki zespół.

Jeśli ustawisz jeden zespół to z czasem pojawią się wewnętrzne kanały komunikacji i może się zdarzyć że wypadniesz z obiegu bo znajdziesz się poza tymi nieformalnymi kanałami (robiąc zdalnie to bardzo realny scenariusz) a stąd już tylko krok żeby znalazł się w roli wykonawcy a nie decydenta/projektanta (tip: ci pierwsi są wymienni).

Za to jak zorganizujecie sobie zespoły tak żeby nakładały im się obszary odpowiedzialności to i liczba tasków się zwiększy (a więc i metryki) a i dodatkowo menedżer będzie happy bo będzie czuł się przydatny przy rozwiązywaniu konfliktów.

No i ciężej będzie wytyczyć granice przy ew. zwolnieniach.

PiotrLub napisał(a):

Pracuję w projekcie monolicie jako dev, w którym aktualnie mamy dwa zespoły podzielone po 9 osób. Ostatnio zarówno w jednym jak i drugim zespole działamy w tych samych obszarach aplikacji. Problem jest taki, że jest bardzo słaba synchronizacja/komunikacja między zespołami.
Każdy coś tam działa na swoim podwórku i to generuje chaos w projekcie. Te rozdzielenie na zespoły było głównie po to, żeby nie tracić za dużo czasu na daily.

A wiecie, co jeszcze bardziej oszczędza czas na robieniu daily? Nie robienie daily…

Bez sensu? A dlaczego? Czyżby dlatego, że bez takich spotkań ludzie nie będą wiedzieć, co robią inne osoby? Teraz też nie wiedzą, bo każdy ma kontakt z co najwyżej połową.

Taka już jest naturalna kolej rzeczy — żeby ludzie wiedzieli, co się dzieje, trzeba im powiedzieć. Żeby mogli coś przedyskutować, muszą się spotkać. Ograniczenie komunikacji ogranicza zrozumienie. Ograniczenie dyskusji ogranicza porozumienie. Można planować pod to, żeby nie było potrzeba aż takiego zrozumienia — znacznie drobniej podzielić zadania tak, żeby były bardziej samowystarczalne, więc nie było potrzeby rozumienia, czy i jak zrealizowane są inne; co wymaga spędzenia czasu na odpowiednim zaplanowaniu wszystkiego z góry, co przy okazji trochę usztywni projekt. A można mieć też mniej planowania i więcej improwizacji, ale wtedy ludzie muszą wiedzieć, i muszą rozumieć, i muszą się dogadać, i muszą się porozumieć — zatem masz więcej spotkań z większą liczbą osób, co przy okazji spowolni projekt, bo trudno jest przewidzieć w takiej sytuacji, kto faktycznie się na tym spotkaniu przyda, więc ludzie będą odrywani od realizacji zadań częściej, niż to ściśle potrzebne — albo, co gorsza, rzadziej niż to potrzebne, przez co ich praca będzie psu na buty, bo nie będzie pasować do reszty.

A kanał na slacku nie wystarczy?

To zróbcie tak żeby na dokumentami siedział jeden zespół i ewentualnie dobierał rzeczy. Wydzielcie obszary per zespół a nie podział na pół i wolna amerykanka.

bagietMajster napisał(a):

To zróbcie tak żeby na dokumentami siedział jeden zespół i ewentualnie dobierał rzeczy.

Problem plecakowy? Plecak jest zawsze za mały.