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


18

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 ?


20
Jeśli twoje spotkania scrumowe trwają dłużej niż 5-10 minut, nie robisz tego dobrze. Spotkania Scrumowe nie są miejscem do naprawy ani dyskusji. Wszystko, co robisz, to mówisz: co zrobiłem, co robię i co mnie blokuje. Zajmuje 60 sekund i wcale nie powinno być stresujące. Wszelkie dalsze dyskusje powinny odbywać się poza scrum.
Chris Eberle,

3
Czy możesz powiedzieć więcej o korzyściach, jakie uzyskasz (lub masz nadzieję / oczekujesz) z codziennego raportowania?
poolie

9
Nienawidzę punktu 2: nie rozwiązuje żadnego problemu ze strony dewelopera, tylko ze strony menedżera. Dodatkowo oznacza to, że szef nie ufa mi w mojej pracy. Wolę to, co mówi Chris: co zrobiłem, co robię, co mnie blokuje.
mouviciel

5
Upewnij się, że raporty TPS mają poprawną ochronę.
Simon Richter,

2
Czy istnieje powód, aby rozmawiać z innymi formami życia opartymi na węglu, które mają kontrolę źródła zintegrowaną z narzędziem do śledzenia błędów i serwerem CI?
Wyatt Barnett,

Odpowiedzi:


37

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.


6
+1 „Jeśli Twój codzienny stand-up zajmuje więcej niż kilka (15?) Minut, dzielisz się zbyt dużą ilością szczegółów ...” podczas naszego cotygodniowego spotkania (gdzie kontaktujemy się z programistami, którzy są międzystanowi) spróbuj wzmocnić ten typ reguły. Mieliśmy spotkania, które trwały o wiele za długo i odkąd planujemy je przed lunchem ..., no cóż, dostajesz zdjęcie.
James Khoury,

Najdłuższy czas, w którym brałem udział, to 20 minut, a to z powodu napływu ludzi. Mieliśmy nie tylko zespół programistów, ale także stażystów, spółdzielnie i jednego lub dwóch kontrahentów. Nie wszyscy zawsze rozmawiali, ale jeśli wiele osób miało odpowiednie aktualizacje, przekraczało to granice. Po 20 minutach uwagi zaczęły błąkać się, tak że stały się pułapką, aż liczba zmniejszyła się i wróciliśmy do 15 minutowych spotkań. Zazwyczaj jednak 15 minut to dobry czas na strzelanie.
Thomas Owens

Czy uważasz, że może to obniżyć ich wydajność? Tak. lol tak prawda. Dlaczego nie kodujesz? bo piszę raport o kodowaniu.
Anonimowy typ

+1: „Piszę raport o kodowaniu”. Stan mikro to „Dostarczam raport o stanie makr”.
S.Lott,

11

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.


2
+1: „zostały pomalowane”. Pracowałem dla klientów, którzy chcieli codziennego statusu, ale nadal nalegałem na spotkania w celu omówienia go. Jeśli i tak mieliśmy się spotkać, po co to wszystko zapisywać?
S.Lott,

@ S.Lott - może dlatego, że i tak jest spisany - w zasadzie lista rzeczy do zrobienia, z której wiele osób korzysta, aby śledzić swoje postępy. Biorąc pod uwagę, że (z pytania) „nie trzeba stosować żadnego określonego formatu”, chętnie skopiuję i wkleję moją listę rzeczy do zrobienia wraz ze skreślonymi wypełnionymi elementami - zazwyczaj robię to każdego dnia, aby rozpocząć i tak do listy następnych dni. Moje ustne sprawozdanie koncentruje się na tym, co pamiętam i na tym, co myślę, że inni powinni usłyszeć - więc pominie to w porównaniu z pisemnym, ale także spekuluje na temat nadchodzących problemów, które mogą mieć wpływ na innych ludzi.
Steve314,

@ Steve314: „Mój raport mówiony ...” To szlachetny wysiłek, aby jak najlepiej wykorzystać złą sytuację. Bardziej fundamentalnie jednak, po co powielać się? Jeśli pisemny raport po prostu nie jest wykorzystywany do niczego, dlaczego ludzie o to proszą?
S.Lott,

@ S.Lott - jeśli nie jest używany do niczego, to prawda. Ale słyszałem wiele o programistach, którzy myśleli, że wszystko szybko się kończy, a robiono postępy, podczas gdy menedżerowie wpadają w panikę, ponieważ nic nie słyszeli od wieków, więc zakładają, że ludzie milczą, próbując ukryć całkowity brak postęp lub nadchodząca katastrofa. Niech menedżerowie zobaczą odznaczone rzeczy do zrobienia i być może można tego uniknąć. Jeśli chodzi o powielanie, komunikacja ludzka wymaga redundancji - wszyscy zaangażowani są tylko ludźmi.
Steve314,

@ Steve314: „programiści myślą, że wszystko jest w porządku ..., a menedżerowie wpadają w panikę”. Wcale nie o to chodzi. Pisemny raport, który jedynie prowadzi do spotkania w celu omówienia postępów nie został odczytany . Jeśli nie został przeczytany, po co go pisać? Możesz podjąć szlachetny wysiłek, aby naprawić złą sytuację. Ale pisemny raport, który prowadzi tylko do kolejnego spotkania, jest marnotrawstwem pisemnego raportu. Po prostu umów się na kolejne spotkanie. Po prostu codziennie odbieraj kolejne spotkania. Podczas wstawania. I skończ z tym.
S.Lott,

6

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.


+1: robimy to samo. Nie codziennie, ale co tydzień w poniedziałek przez cały tydzień (więc na swój sposób, po prostu w dłuższych ramach czasowych). Nie robimy tego codziennie, ponieważ większość pracowników to studenci i nie ma ich każdego dnia, większość komunikacji odbywa się również za pośrednictwem komunikatora internetowego lub podobnego, więc cotygodniowe spotkanie całego zespołu (około 10) jest wystarczające.
Femaref

6

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.


4

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.


2

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”.


1
Jeśli nie powiesz dokładnie, co masz na myśli przez krótką codzienną wiadomość e-mail o stanie, co najmniej kilka osób będzie codziennie spędzać godziny na martwieniu się, czy robią to dobrze.
Steve314,

@ Steve314, lol prawda, potencjalnie dobry sposób, aby aktywnie dostrzec kolejną rundę ahem redukcje.
Anonimowy typ

2

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.


2

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.


2

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.


2

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.


2

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.