Spotkanie po projekcie stratą czasu?

W moim miejscu pracy odczuwaliśmy poważny ból. Przeszliśmy z zespołu programistów od 3 do 10, a sama firma wzrosła w ubiegłym roku o 30%. Pod większością pomiarów mamy się dobrze. Niestety ucierpiała jakość naszego oprogramowania.

Na dzisiejszym spotkaniu z kierownikiem mojego oddziału zaproponowałem spotkanie zespołu projektowego dzień lub dwa po wprowadzeniu produktu na rynek. Mogliśmy omawiać obawy dotyczące budżetu, zakres, co poszło nie tak i co poszło dobrze. Najlepiej byłoby uczyć się na własnych błędach. Tworzymy witryny / aplikacje dla innych osób, więc nasz czas jest rozliczany z opłatami niepodlegającymi rozliczeniom. Takie spotkanie podlegałoby temu drugiemu.

Mój menedżer zastrzelił go niemal natychmiast: „Ten czas nie jest fakturowany. Sprawi, że będziemy mieć zaległości w realizacji innego projektu, ponieważ tracimy czas na jego zakończenie”. Ta logika tak mnie zaskoczyła, że ​​nawet nie zadałem sobie z tym trudu.

Więc moje pytanie: widzę, że wartością są spotkania po projekcie, ale on nie. Czy istnieje udokumentowany dowód spotkań po projekcie, który pomaga zaoszczędzić czas i pieniądze w długim (lub krótkim) okresie? Intuicyjnie myślę, że tak będzie, ale najwyraźniej bardziej martwi go niewielka ilość niezliczonych godzin od 5 osób, które musiałyby tam być.

Patrząc wstecz, patrząc w przyszłość byłoby blisko udokumentowanego dowodu na ten pomysł. Projekt Post-Mortem: A Valuable Tool for Continuous Improvement byłby postem na ten temat na blogu.

Art of the Post-Mortem ma następujący punkt na temat idei:

Początki sekcji zwłok pochodzą od wojska, które rutynowo stosuje ten rodzaj procesu do przesłuchiwania ludzi na linii frontu. Ale jego aplikacja do zarządzania jest niezbędna dla każdej wysoce wydajnej, uczącej się organizacji.

Twój menedżer nie rozumie pojęcia Długu Technicznego .

Spotkania po projekcie są inwestycją, a nie kosztem. Tak musicie je sprzedać. Celem każdego spotkania jest wymiana pomysłów na temat oszczędzania pieniędzy i długoterminowej realizacji celów firmy .

Twój kierownik jest menedżerem, ponieważ zajmuje się tymi długoterminowymi celami. Moim zdaniem są dwie możliwe prawdy: twój menedżer chce mieć całą kontrolę nad sobą, albo twój menedżer nie wykonuje swojej pracy. Jeśli firma ma historię i filozofię robienia rzeczy „we właściwy sposób” i inwestowania we własny sukces, rozważ wzięcie sprawy ponad swojego kierownika.

Jest to zasadniczo przegląd po działaniu , który jest szczególnie przydatny w wielu różnych kontekstach, nie tylko w wojsku.

Mój własny cykl rozwoju obejmuje analizę zarówno tego, co należy zrobić w następnej iteracji lub projekcie, jak i tego, co można zrobić lepiej w poprzednim projekcie. Nawet jeśli projekt jest odkładany na jakiś czas na półkę, posiadanie listy rzeczy do pracy pomaga, gdy schodzi on z półki (lub palnika ...) i ponownie jest projektem aktywnym. Następnym razem, gdy go dotknę, nie muszę poświęcać tyle czasu na przeglądanie tego, co muszę zrobić.

Ponadto, przeglądając projekt i znajdując ciekawe sztuczki, które ja lub inni wdrożyłem, są one rozpowszechniane, a następny projekt lub kolejna iteracja jest o wiele lepsza. (Może to nie dziwić, że często myślę w kategoriach iteracji).

Wartość tego jest prosta logika i z natury oczywista. Jak możesz ulepszyć przyszłe projekty, jeśli nigdy nie uczysz się na błędach z poprzednich projektów?

Chociaż nie jest to konkretnie dokumentacja, przegląd procesu (podczas lub po zakończeniu) jest głównym składnikiem prawie każdego opartego na standardach systemu kontroli jakości, jaki znam, szczególnie CMMI i Lean 6 Sigma.

Może mógłbyś zaproponować to jako zobowiązanie, coś, co jest robione dobrowolnie podczas lunchu lub coś takiego? Są duże szanse, że spora część twojego zespołu programistów chętnie przyjdzie i spróbuje nowych rzeczy ... więc jeśli potrafisz wymachować przynajmniej pierwszym, wyniki będą mówić same za siebie.

Możliwe, że Twój menedżer jest pod presją budżetu. To musi budzić duże obawy, jeśli w krótkim czasie nastąpi rozwój z 3 do 10 programistów. Jeśli tak jest, to prawdopodobnie dobrym pomysłem jest po prostu pominąć na razie spotkania pośmiertne i zasugerować je ponownie za kilka miesięcy, kiedy, mam nadzieję, natychmiastowe problemy z budżetem nie będą tak pilne.

Jednym z powodów cierpienia jakości jest to, że komunikacja między 10 osobami jest znacznie większym problemem niż komunikacja między 3 osobami: 3! << 10 !. Chociaż prawdopodobnie możesz przez jakiś czas się marnować, w końcu będziesz musiał wprowadzić pewne zmiany, aby sprzyjać lepszej komunikacji między programistami i upewnić się, że zasady ustalone przez pierwszych 3 programistów zostaną rozpowszechnione w nowszych i zaktualizowanych, aby działały dobrze w nowej, większej grupie. Jednym ze sposobów jest zorganizowanie sekcji zwłok; okresowe przeglądy kodu są kolejnym. Nie zaszkodzi wskazać, że spotkania pośmiertne są kluczowym elementem poprawy jakości w branżach od medycyny po produkcję.

Trudno sobie wyobrazić, że Twój menedżer wierzy, że może powiększyć swój zespół programistów, po prostu zatrudniając dodatkowe osoby. Absolutnie muszą być jakieś inwestycje w szkolenie i budowanie zespołu; bez tego Twoja organizacja upadnie pod własnym ciężarem. Jeśli zaczekasz chwilę, Twoja organizacja może zacząć doświadczać konkretnych problemów, które można bezpośrednio przypisać słabej komunikacji. W tym momencie Twój menedżer prawdopodobnie powie: „Musimy umieścić wszystkich na tej samej stronie! Umów się na spotkanie ze wszystkimi programistami!” A jeśli to pomoże, prawdopodobnie powie: „Powinniśmy to robić po każdym projekcie!” ;-)

Bądź więc cierpliwy, ale bądź wytrwały.

Pokonam trend: zgadzam się z kierownikiem.

Uważam, że przeglądy po projekcie są w dużej mierze bezcelowe, ponieważ jest za późno, aby zrobić wiele, aby naprawić ujawnione problemy.

Najbardziej poleciłbym okresowe retrospekcje przeprowadzane podczas projektu. Raz lub dwa razy w miesiącu zespół mówi o tym, co poszło dobrze, a co nie; co robić więcej, co robić mniej. Zrób to podczas projektu , abyś mógł natychmiast zastosować sugestie i zobaczyć, jak dobrze działają.

Spójrz na formalizację spotkania. Wiele spotkań po projekcie to fiesterzy, a twój kierownik ma absolutną rację, że ich nie wspiera.

Zaproś do zarządzania spotkaniem (poproś go, aby przewodniczył / moderował), rozesłał porządek obrad i miał konkretne wyniki. Jako menedżer może wtedy zobaczyć wartość na spotkaniu.

Używamy i polecam proces recenzji „6 Thinking Hats” de Bono ( patrz Wikipidia ). Rezultatem jest kilka (2 lub 3) punktów działania, które spotkanie określa jako najważniejszy nauczony powód. Przez pierwsze kilka razy mamy problemy z wyjściem z bloków początkowych, ale kiedy już się do tego przyzwyczaimy, nie wrócę.

Nieprzeprowadzenie przeglądu po zakończeniu projektu skazuje cię na takie same błędy, jakie popełniono w poprzednim projekcie.