Jaki jest sens daily przy dużym zespole?

0

Cześć,

Mam taki problem, zespół powiększył się do 20 osób i daily moim zdaniem jest bezsensowne w pracy zdalnej w takim układzie. Ludzie nie słuchają się nawzajem, a dla leadera raportowy charakter też jest ciężki do słuchania, bo za dużo osób do śledzenia. Zespół ciężko podzielić na mniejsze zespoły bo klient potrzebuje dynamiczną liczbe osób per serwis/portal co tydzien/2 tygodnie.

Jakieś pomysły jak to usprawnić?

W mojej głowie przychodzi tylko wyrzucenie daily i pisanie na wspólnym kanale progresu i blokerow i zapotrzebowań pojedynczych członków zespołu.

2

Ale co w tym nietuzinkowego? To dość przewidywalne, że na spotkaniu w pracy, na którym jest więcej niż 5 osób nie będzie jednego tematu, który zainteresuje wszystkich.
Daily to generalnie komunikacja jednostronna, tj. zdawanie raportu do dowódcy. Czy to jest dowódcy potrzebne, to już on musi zdecydować.

4

IMHO stand-upy nie mają wiele sensu nawet w małych zespołach, to kolejny z szeregu nonsensów wprowadzanych przez oderwanych od rzeczywistości reformatorów.

Jakoś projekty open-source'owe, których rozproszeni po świecie developerzy wcale nie widują się twarzą w twarz, potrafią funkcjonować. Wystarczy im zwykły changelog z zapisywanymi w miarę aktualizacji release'ów linkami do PR-ów bądź tasków. Każdy zainteresowany może sprawdzić i śledzić, co się zmieniło od ostatniej wersji.

2

Ja tam widzę, że daily jest potrzebne - duża część programistów, nawet seniorów, szczególnie tych co mają bóg wie ile lat, łatwo leci w maliny - siedzą dłubią tydzień swoje rozwiązanie, które i tak nie ma rąk i nóg, i trzeba na review prostować - a tak da się przynajmniej w porę zareagować, jak komuś coś zajmuje długo dłużej niż powinno.

Ale myślę, że gdyby się miało dobry zespół ad-hoc meetingi pomiędzy członkami i jakieś weekly byłoby wystarczające, ale zwykle przecież w zespołach jest 80 / 20 - 20% tych co ogarniają, i 80% tych co rozumieją składnie :P

3

Jak to, zespół nie potrafi się sam zorganizować na takim daily? ;-) Klient potrzebuje ilość osób? :| A może dostarczoną ilość "czegoś" (funkcjonalności w określonym czasie?)

Rozsądnym wydaje się podzielić te 20 osób na 3 mniejsze zespoły i niech sobie daily robią osobno. Dodatkowo liderzy takich zespołów niech mają raz czy 2 w tygodniu spotkanie synchronizacyjne, a raz w tygodniu spotkanie z liderem tych 20 osób. Częstotliwość takich spotkań i ich długość wyniknie z bieżących potrzeb.

1

20 osób idealnie żeby się podzielić na 2 zespoły...

4

Podzielcie się na więcej zespołów. Nikt nie powiedział, że jeden zespół musi się specjalizować w jednej usłudze. podobno idealna wielkość zespołu to 5-8 osób.
Drugi element absolutna dyscyplina na daily:

  • punktualność, co do sekundy, 9:00:00 zaczynamy, nie ważne czy wszyscy już są, po miesiącu zaczną zdążać
  • przygotowanie - jak ludzie mają z tym problem, to niech sobie robią wcześniej notatki co chcą powiedzieć
  • zero "wczoraj coś tam robiłem, ale trochę mi nie poszło, więc będę robił dalej, a gadam tylko po to, bo coś muszę powiedzieć"
  • raportowane są tylko ukończone prace, przeszkody, potrzeby pomocy
  • absolutne zero technicznych dyskusji "jak coś zrobić", jedynie proste - wiem jak to zrobić, zagadaj po daily
4
Pixello napisał(a):

Ja tam widzę, że daily jest potrzebne - duża część programistów, nawet seniorów, szczególnie tych co mają bóg wie ile lat, łatwo leci w maliny - siedzą dłubią tydzień swoje rozwiązanie, które i tak nie ma rąk i nóg, i trzeba na review prostować - a tak da się przynajmniej w porę zareagować, jak komuś coś zajmuje długo dłużej niż powinno.

Początkujących, juniorów i nowo zatrudnionych trzeba obserwować tak czy inaczej, ale od tego jest z reguły oddelegowana jedna mentorująca osoba, która pilnuje tych ich rozwiązań, odpowiada na ich pytania i regularnie zagląda im przez ramię. Co do reszty, wypadałoby zaufać, że wiedzą jak wykonywać swoje zadania lub komu dać znać, jeśli zderzą się z jakimś blokerem lub muszą przedyskutować design. Co najwyżej potrzebna jest uważniejsza kontrola dla tasków krytycznych (również dlatego, by można informować klienta o statusie prac) oraz tych z widocznym opóźnieniem, ale to spokojnie da się załatwić na bezpośredniej linii architekt/lead - deweloper. Reszty to tak naprawdę nie dotyczy, po cholerę mają stać w kółeczku i słuchać. A seniorzy, którzy "lecą w maliny" to jakaś patologia i oksymoron, albo nie są tak naprawdę seniorami i trzeba ich pilnować jak juniorów, albo może nawet nie nadają się do zespołu, skoro wymagają takiej ciągłej troski?

Sam pracuję już od 2 lat zdalnie, zacząłem jeszcze przed pandemią, która ten tryb upowszechniła, siłą rzeczy żadnej formy stand-upów i innych form szczegółowej kontroli nie ma (co innego, oczywiście, w przypadku mentorowania juniorów/nowo zatrudnionych), co sobie bardzo chwalę.

Mikrozarządzanie to nonsens.

0

Mam opory przed sztywnym dzieleniem ludzi np. na grupy 5 osobowe, 10 osobowe itp. Większy sens ma gdy jest jakieś duże zadanie i po prostu wrzucamy temat grupie osób.

@Spearhead jeśli dobrze rozumiem to z Twojej perspektywy daily to mikrozarządzanie i na poziomie zespołu byś to wyrzucił jako praktyke..

1

Dla mnie te wszystkie sztywne pogadanki są bez sensu. Jeżeli manager nie wie co robi jego zespół to znaczy że system zarządzania zadaniami jest do d**y.

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