Czy codzienne raporty mogą zmniejszyć produktywność programisty? [Zamknięte]

W innym pytaniu zapytałem o to, dlaczego deweloperzy mogą nie lubić codziennego scrum . Rozmawialiśmy z programistami i postanowiliśmy nie wstrzymywać przez pewien czas codziennego scrum (aby spróbować i dostosować scrum za pierwszym razem). Jest to wynik konsultacji bezpośrednio z programistami.

Z drugiej strony nie chcemy stracić dobrych części codziennego scrumu, takich jak codzienna koordynacja programistów lub obserwowanie postępu pracy, jak kluczowy wskaźnik wydajności, w celu wczesnego podjęcia działań.

Jako alternatywę dla codziennego scrum, myślimy o proszeniu programistów o codzienne raporty z następującymi warunkami:

1. Nie trzeba stosować żadnego określonego formatu. Każdy format jest akceptowany.
2. Nawet jeśli praca nie zostanie wykonana, chcemy usłyszeć postęp.
3. Nie trzeba wspominać o czasie poświęconym na każde zadanie.
4. Należy wspomnieć o przeszkodach rozwojowych i wymaganiach dotyczących koordynacji.
5. Codzienne raporty nie wymagają obsesji. To nie jest tak surowe.

Czy uważasz, że może to obniżyć ich wydajność? Czy miałeś / aś jakieś codzienne raporty? Czy masz dla nas jakieś sugestie, abyśmy mogli upewnić się, że nie zarządzamy mikromaningiem ?

Jako alternatywę dla codziennego scrum, myślimy o proszeniu programistów o codzienne raporty z następującymi warunkami:

Co za okropny pomysł.

Czy uważasz, że może to obniżyć ich wydajność?

Tak.

Dlaczego? Ustna prezentacja na spotkaniu łączy pisanie i n „osób” czytających raport w jedno równoległe działanie. Mówienie plus słuchanie. Koniec i koniec. Odpowiedzi na pytania od razu.

Pisanie raportu to strata czasu, ponieważ pojawią się pytania i będziesz musiał przejrzeć raport z ludźmi, którzy (a) mają pytania i (b) tak naprawdę go nie przeczytali.

Codzienne raporty nie będą czytane. Szybko przechodzą w hałas w skrzynce.

„Nie trzeba mieć obsesji na punkcie codziennych raportów”. W takim razie dlaczego?

Czy masz dla nas jakieś sugestie, abyśmy mogli upewnić się, że nie zarządzamy mikromaningiem?

Tak. Codziennie stój. To potrwa kilka minut i gotowe.

Jeśli Twoje codzienne wstawanie zajmuje więcej niż kilka (15?) Minut, dzielisz się zbyt dużą ilością szczegółów i musisz zaplanować osobne spotkania dla tych szczegółów. Codzienne wstawki są łatwe do zrobienia. Po 2-minutowym podsumowaniu wszystko inne jest prawdopodobnie szczegółami, nie dla całego zespołu, i musi zostać przekazane na kolejne spotkanie. Spotkanie przechodzi do następnego dnia.

Robiłem to w przeszłości, ale rano, w przeciwieństwie do końca dnia. Zazwyczaj wypełnienie zajęło mniej niż pięć minut, więc nie, nie widzę, jak nastąpiłby spadek wydajności programisty. Zaletą robienia tego rano jest to, że zastanawiasz się, co będziesz robić przez resztę dnia.

Powiedziawszy to ...

Odkryliśmy, że było to więcej razy niż nie, nie była to najskuteczniejsza metoda komunikowania tego, co zrobiliśmy poprzedniego dnia i co zamierzamy pracować tego dnia. Dlaczego? Ludzie na ogół ich nie czytali. Było to zaplanowane zadanie programu Outlook, więc wszyscy wysyłali je każdego dnia, ale albo zostały nadpisane, albo po prostu całkowicie pominięte (inne niż przez potencjalnych klientów lub kierownictwo).

Odkryliśmy, że codzienne wstawki były o wiele bardziej wartościowe, ponieważ ludzie mieli tendencję do słuchania się nawzajem. Ponadto, gdyby doszło do nieporozumienia, zostanie ono wypłukane tu i tam, co jest bardziej prawdopodobne niż ktoś, kto odpowiada na codzienny e-mail z pytaniem o dalsze pytania.

Szczerze mówiąc, pozwalanie każdemu na zgłaszanie się bez ograniczeń wydaje się odrobinę zbyt daleko w stosunku do liberalnej strony równania. Tam, gdzie pracuję, chodzimy w kółko, a każdy programista zapewnia:

1. Co zrobiono poprzedniego dnia. Nie wszystkie drobne szczegóły, ale ogólnie.
   • Jeśli powyższe nie zostanie zakończone, jeśli nie, co jest potrzebne do ukończenia i jak długo to potrwa.
   • Jeśli powyższe zostanie zakończone, jakie jest następne zadanie, co jest wymagane i ile czasu to zajmie.
2. Blokery Jeśli pracujesz nad Foo, która zależy od paska, a pasek nie jest ukończony, należy to wyjaśnić.

Ustanowienie ogólnego schematu dla wszystkich do naśladowania może ułatwić przeglądanie danego raportu. Możesz łatwo skonfigurować jakąś metodę otrzymywania wiadomości e-mail z codziennymi raportami, a tym samym pozwolić każdemu dowiedzieć się, co się dzieje.

IMO każdego rodzaju codziennych spotkań / raportów zmniejsza produktywność, ponieważ, szczerze mówiąc, śmierdzi mikrozarządzaniem. Tak, wiem o Scrumie itp. I nie są one takie złe, pod warunkiem, że mają krótkie aktualizacje statusu („Hej, jak idzie projekt X?”), Ale mocno wierzę, że obrażanie profesjonalnych programistów jest obraźliwe nas na tak niskim poziomie; przypomina korzystanie z kart czasowych, aby upewnić się, że jesteśmy w biurze 8 godzin dziennie, lub upewnienie się, że nie ma ścian, więc możesz szpiegować komputery ludzi, aby zobaczyć, jakie okna mają otwarte w danym momencie.

Jeśli musisz mieć na oku wszystkich, aby upewnić się, że działają, oznacza to, że im nie ufasz. Jeśli im nie ufasz, w pracy jest większy problem niż ten, o który się martwisz.

Mój zespół robi scrum od około roku. Wcześniej mieliśmy dwa spotkania w tygodniu, podczas których każdy członek zespołu informował o swojej aktywności w ciągu ostatnich 2, 3 dni. Każde spotkanie trwało od 30 minut do 1 godziny. W przypadku, gdy musieliśmy wymieniać informacje i koordynować naszą pracę, po prostu chodziliśmy do naszych kolegów i rozmawialiśmy z nimi (co oczywiście nadal robimy).

Teraz, gdy robimy scrum, często mamy wrażenie, że jedno spotkanie dziennie (choć trwa tylko 15 minut) to za dużo. Często sprawozdania niektórych członków sprowadzają się do: „Nic nowego od wczoraj”. Często mieliśmy wrażenie, że schemat 2 spotkań tygodniowo był bardziej skuteczny.

Kolejną wadą jest to, że codzienne spotkanie jest zaplanowaną przerwą (patrz np . Artykuł Paula Grahama , punkt 1. Unikaj rozpraszania uwagi): ponieważ wiesz, że przerwa ta nadejdzie, nie zaczniesz nic trudnego przed spotkaniem (codzienne spotkania mogą odbywać się półtorej godziny po rozpoczęciu pracy).

Wreszcie, choć wczesne informacje zwrotne mają zalety („Och, pracujesz nad tym problemem, powinniśmy go przedyskutować!”), Czasem bardziej efektywne jest rozpoczęcie dyskusji tylko wtedy, gdy już masz uporządkowane pomysły w głowie , masz konkretne pytania i czujesz się gotowy do dyskusji. Zamiast tego codzienne raporty mogą szybko spowodować wiele niepotrzebnych i nieuporządkowanych burz mózgów. Uważaj więc na zbyt wczesne informacje zwrotne: może to Cię pomylić i spowolnić.

Tak więc: w niektórych przypadkach codzienne raporty zmniejszały naszą wydajność. Średnio nie mam wrażenia, że ​​sprawili, że nasza praca była bardziej efektywna.

AKTUALIZACJA

Pierwszą odpowiedź napisałem kilka lat temu, a tymczasem zmieniłem zespoły. W moim obecnym zespole robimy codzienne spotkania na żądanie, tj. Gdy czujemy, że potrzebujemy krótkiej aktualizacji statusu. Tak więc każdego dnia istnieje możliwość takiego spotkania, ale nie robimy tego, jeśli nikt o to nie poprosi. Mamy cotygodniowe spotkanie retrospektywne. Jest to w zasadzie bardzo podobne do podejścia, które pierwotnie stosowaliśmy w moim poprzednim, nie zwinnym zespole: ustalono cotygodniowe spotkania plus dodatkowe spotkania na żądanie w pozostałej części tygodnia.

Jeśli naprawdę chcesz mieć szorstki status i zanotować wszelkie przeszkody, najlepiej poprosić ich o krótki „codzienny e-mail o statusie”. Jeśli położysz na to zbyt duży nacisk lub sporządzisz listę tego, co powinien / nie powinien zawierać, to przynajmniej niektórzy z twoich twórców spędzą dodatkowy czas na tworzeniu go, aby spełnić wymagania. Zamiast tego poproś o prosty e-mail. Kiedy nadchodzi dzień, powiedz „och, umieść to w e-mailu na koniec dnia”, a jeśli otrzymasz naprawdę długi e-mail na koniec dnia, powiedz od niechcenia: „nie musisz być tak szczegółowy każdego dnia”.

Bardzo pomocne jest jasne określenie celu każdego spotkania lub raportu, zwłaszcza każdego każdego dnia. Mówisz, że powodem jest:

nie chcemy stracić dobrych części codziennego scrumu, takich jak codzienna koordynacja programistów,

Co rozumiesz przez koordynowanie programistów ? Jakiego rodzaju praca wymaga koordynacji i nie jest koordynowana ad hoc przez programistów i ich menedżerów w razie potrzeby? Czy jest jakiś sposób na zidentyfikowanie zadań wymagających koordynacji i komunikowanie się tylko w tych przypadkach?

lub obserwując postęp pracy jak kluczowy wskaźnik wydajności, aby szybko podjąć działania.

Wiele dobrych wskaźników KPI (takich jak czas reakcji witryny lub liczba krytycznych błędów) będzie mierzalnych mechanicznie i nie musisz nakładać na nich kosztów.

Musiałem robić codzienne raporty w kilku różnych formatach w miejscu pracy. Ogólnie rzecz biorąc, myślę, że codzienne raporty przynoszą wartość dodaną tylko menedżerom, a nie samym deweloperom. Podczas gdy menedżerowie czerpią korzyści z codziennych raportów, ponieważ są w stanie określić ogólny stan każdego projektu i zadania każdego pracownika w krótkim czasie, z mojego doświadczenia wynika, że ​​większość programistów nie zawraca sobie głowy czytaniem raportów o stanie innych.

Wydaje się jednak, że nie wymuszając formatu dziennych raportów, utrudniasz ich czytanie i przetwarzanie zarówno menedżerom, jak i innym programistom, co pogarsza problem straconego czasu programisty.

Jeśli zdecydujesz się przejść do codziennych raportów dla programistów, czy mogę zasugerować użycie wewnętrznej wiki zamiast raportów e-mail? W ten sposób nie spamujesz skrzynek odbiorczych użytkowników, zachowując historię codziennych statusów wszystkich osób.

To świetny pomysł, aby dostosować metody Agile, aby były dla Ciebie odpowiednie - więc pochwały za to.

Tak więc, zamiast codziennych raportów, powiedziałbym, że to nie jest dużo lepsze niż codzienne spotkanie, wciąż jest to to samo podejście „powiedz mi, co robisz”, po prostu kazałeś wszystkim zapisać to, niż mówić.

Oto alternatywne podejście: zamiast korzystać z technik „odpytywania”, w których pytasz każdego dewelopera o jego status, zamiast tego używasz techniki „push”. Jeśli deweloper nie ma nic do zgłoszenia, nie powinien, powinien zgłosić wszelkie problemy i postępy, gdy tylko się pojawią. Więc kiedy ukończą moduł, powinni wysłać e-mailem do całego zespołu, który zakończył, że jest w SCM, gdzie można znaleźć dokumentację oraz krótkie streszczenie tego, co to jest, jak to działa i / lub jak używać to. Jeśli mają problem, powinni wysłać e-mail do zespołu z prośbą o poradę, pomoc lub wskazówki. (tak, jak za dawnych czasów, kiedy zespoły komunikowały się dobrze bez mikrozarządzania, które dziś cierpimy)

przekonasz się, że jest to o wiele bardziej produktywne i konstruktywne. Nie dostaniesz dla nich bezsensownych raportów i zyskasz bardziej zmotywowany zespół, ponieważ każdy lubi informować swoich współpracowników o swojej pracy.

Zgadzam się również, że złym pomysłem jest zastąpienie codziennych stand-upów raportem. Codzienny stand-up to świetne miejsce do wyrażania pomysłów i problemów. Jest to jeden z powodów, dla których lubię starą dobrą tablicę (której używamy wraz z Jira + Greenhopper). Tablica jest miejscem, w którym grupa „gromadzi się” i dzieli się informacjami, wszystko tam jest, wszystko jest widoczne, wszyscy się poruszają i zmieniają kleje, nad którymi pracowali, to także świetna zabawa.

Nie możesz wyodrębnić tych informacji z innych narzędzi?

• Nad czym aktualnie pracujsz? Bilety, które przypisałem.
• Jakie są twoje postępy? W przypadku biletów, które mam dłużej niż 1 dzień, zobacz komentarze w biletach lub zatwierdzaj wiadomości oddziału. Bilety mam krótsze: prawdopodobnie zrobione jutro (nie robisz dużych biletów na 5+ dni, tak?)
• Jaki jest ogólny postęp? patrz stosunek liczby otwartych / zamkniętych biletów
• Co trzeba zorganizować? bilety, które otrzymałeś z powrotem, z potrzebną informacją zwrotną o stanie i wszystko omówione na IRC twojego zespołu, w pokoju ogniska, cokolwiek.

Kiedy masz bardziej szczegółowe pytania, dostrzegam potrzebę konkretnych raportów, ale bez tego twoje raporty wyglądają trochę jak cel sam w sobie.