Jak śledzisz to, nad czym ty i twój zespół pracujesz na co dzień?

Mam problem z tym, jak śledzić, co ja i ludzie w moim zespole faktycznie robią każdego dnia. Dostaję dobry ogólny obraz, przeglądając co tydzień wypełnione karty i stójki trochę pomagają, ale wydaje mi się, że nie mam dobrego zdania na temat codziennej pracy mojego zespołu. Karty pozostaną w toku przez wiele dni bez aktualizacji przy codziennym stand-upie, a niektórzy inżynierowie z mojego zespołu nie są najbardziej komunikatywni.

Myślałem o wprowadzeniu jakiegoś codziennego zapisu, który każdy wypełnia (za pośrednictwem listy adresowej lub udostępnionego dokumentu google), ale wydaje się to dość kłopotliwe i ręczne.

Monitorowanie aktywności GitHub wykonuje dobrą robotę, ale może być nieco przytłaczające ilością e-maili wysyłanych codziennie. Myślałam o tym, aby spróbować zbudować system podsumowania, ale nie mam czasu do stracenia.

Jakie strategie wdrożyłeś, aby być na bieżąco z tym, co robi Twój zespół codziennie, abyś mógł mierzyć pracę nad zadaniami „w toku”?

Rozmawiam z nimi.

Technologia nie może rozwiązać problemów społecznych. Masz krótkie poranne wstawki. Co robiłeś wczoraj? Co dzisiaj robisz? Jakieś przeszkody?

Jeśli coś brzmi podejrzanie (lub jestem ciekawy), zatrzymuję się i zadaję pytania: „Pracowałeś wczoraj nad XYZ, jak to się potoczyło?”. Zmusza to ludzi do zwracania uwagi i faktycznego wiedzieć, co się dzieje. Utrzymuje również przewagę zespołu w pętli (zwracając uwagę i wiedząc, co się dzieje). To musi być na czas i krótkie ( maksymalnie 10 minut ). Wszystko inne i ludzie nie będą „odkładać” pracy. Zatrzymają się i zaczekają na awans, a następnie poświęcą trochę czasu, aby zacząć od nowa. Niektórzy i tak to zrobią, ale w dużej mierze jest to nieuniknione.

Po południu zatrzymuję się przy biurku wszystkich. Nie każdego popołudnia (choć może być więcej niż każdego popołudnia dla nowych ludzi), nie w tym samym czasie, ale mniej więcej w tym samym czasie (więc jest to zarówno nieformalne, jak i regularne). „Jakieś problemy? Jakieś przeszkody?”

Zdziwisz się, jak często napotykasz problemy, gdy ludzie są jeden na jednego.

Jeśli ludzie nie mają problemów, świetnie; Wracaj do pracy. Jeśli nie mają problemów przez cały tydzień ? Problem. Nie stawiacie im wystarczających wyzwań, albo się nie otwierają. Zapytaj, jak idzie XYZ (wspomniane w standupie). Niech wyjaśniają.

To nie jest mikrozarządzanie. Nie mówisz im, jak wykonywać swoją pracę. Nie opiekujesz się nimi. Jesteś tutaj, aby usunąć przeszkody z ich codziennego życia. Potrzebujesz do tego informacji. Tak długo, jak trzymasz swój zespół z dala od spotkań, a kierowników projektu z dala od ich kostek, tak długo jedna osoba wpadająca do pomocy raz dziennie nie będzie powodować smutku. Ale wszystkie te interakcje muszą pochodzić z żyły „Jestem tu, aby ci pomóc”.

Kolejną rzeczą, którą zrobię, jest przeglądanie zestawów zmian (osobiście, nieformalnie). Następnie mogę zobaczyć, jak często ludzie się meldują, jak duże są ich zestawy zmian, jak to pasuje do tego, co zgłosili, jak często robią różne rzeczy, ile mają poprawek błędów i tak dalej. Element pracy zmieniający status na „wykonany” jest prawie bez znaczenia. Spójrz na kod. Czy to wygląda na zrobione?

uwaga: jedna bardzo poważna strona: jak duży jest twój zespół? Czy to więcej niż 7 osób? Oczywiście nie będziesz w stanie śledzić wszystkiego, jeśli twoja drużyna jest zbyt duża.

Nie zarządzaj mikro programistami!

Produktywne tworzenie oprogramowania wymaga długiego wysiłku skoncentrowanego wysiłku umysłowego. Nie jest realistyczne oczekiwanie, że będą wytwarzać stałą wydajność. Jeśli zaczniesz je mierzyć codziennie, zrestrukturyzują oni swoją pracę, tak aby zawsze tworzyli dostrzegalne artefakty, które możesz zobaczyć każdego dnia. To może, ale nie musi mieć pozytywnego wpływu na jakość oprogramowania. Prawie na pewno będzie to miało negatywny wpływ na wydajność programistów.

Jak sugeruje Robert Harvey , nie zarządzaj mikro zespołem. Daj zespołowi kilka priorytetowych zadań o konkretnej wartości biznesowej i pozwól swojemu zespołowi dowiedzieć się, jak zapewnić tę wartość biznesową.

Jeśli zespół zapewnia wartość biznesową, powinieneś być szczęśliwy. To, jak robią, upewniając się, że zapewniają wymagane funkcje, powinno zależeć od nich.

Jednak:

Karty będą działać przez wiele dni bez aktualizacji przy codziennym stand-upie

Może to wskazywać na brak procesu.

Może to być zespół, który tak naprawdę nie funkcjonuje jako zespół i nie wkracza, aby pomóc sobie nawzajem, gdy utknie. Może to być także komunikacja z biznesem. Zadania są zbyt duże, więc trudno jest ustalić, co jest potrzebne. Specyfikacje nie są jasne.

Możliwe też, że nie ma w ogóle prawdziwego problemu. Być może zespół po prostu dobrze działa z kartami przedstawiającymi główne prace, których wykonanie zajmuje kilka dni, a może zespół działa dobrze, aby to osiągnąć.

Uważam, że można wykorzystać retrospektywę jako platformę do wyrażania swoich obaw. Czasami dobrze jest otrzymywać obserwacje z zewnątrz.

Ale pozwól zespołowi dowiedzieć się, czy jest jakiś problem i jaka jest jego przyczyna. I bądź gotowy zaakceptować, że być może musisz dostosować sposób dostarczania zadań do zespołu.

Pamiętaj, że codzienne wstawanie jest narzędziem dla zespołu, który pomaga im zorganizować pracę; NIE jest to narzędzie dla menedżerów do śledzenia tego, co robi zespół.

„Push push” nie „pull pull”

Deweloper często przechodzi do jednego z następujących stanów:

1. Tak, zrobiłem X!
2. Pracuję nad X, ale wygląda na to, że zajmie to trochę czasu ...
3. Utknąłem na problemie Y, badam go, ale mogę potrzebować porady;
4. Jestem zablokowany, ponieważ czekam na A, B i C.

Idealnie byłoby, gdybyś miał dość aktualne informacje o tych stanach bez zakłócania faktycznej produktywności. Stała „Czy już tam jesteśmy?” przynosi efekt przeciwny do zamierzonego, ale może być tak, że możesz zrobić coś użytecznego dla stanów 2-4, więc musisz zostać o nich poinformowany.

Działa kultura „push push”, najlepiej w sposób zautomatyzowany. Być może nie będziesz musiał patrzeć na cały dziennik zatwierdzeń, ale możesz utworzyć „pulpit nawigacyjny”, w którym zobaczysz najnowsze zatwierdzenie lub ostatni rozwiązany bilet (na błędy lub funkcje) każdego członka drużyny. W pozostałych sytuacjach możesz poprosić ich o aktywne wysłanie e-maila z takimi aktualizacjami (mam nadzieję, że są one rzadsze niż zatwierdzanie) lub pójść i zapytać, czy nie widzisz ciągłego postępu na jakimkolwiek pulpicie nawigacyjnym - jeśli masz wewnętrzna zgoda, że ​​utknięcie wymaga podniesienia (może się zdarzyć, że jakaś funkcja nie jest potrzebna, jeśli okaże się, że kosztuje ona 80 godzin, a nie 8 godzin), wtedy albo będą Cię na bieżąco, albo będą ci przeszkadzać.

Alternatywnie możesz stworzyć kulturę czegoś takiego jak https://idonethis.com/ codzienne raporty wysyłane do całego zespołu - zapewni to, że inni też będą na tej samej stronie.

Alternatywą dla niektórych innych odpowiedzi (koncentrujących się na komunikacji) jest to, że być może zadania na kartach notatek można podzielić na mniejsze części, o których wcześniej można by uzyskać informacje zwrotne.

Przy mniejszych kawałkach zespół ma wrażenie, że każdego dnia osiąga coś, co powinno znaleźć odzwierciedlenie w pojedynku.

Wadą jest to, że te osobne karty prawdopodobnie będą na siebie polegać. Zespół, który jest w stanie bardzo łatwo się ze sobą komunikować, jest tutaj korzystny, w przeciwnym razie pionki mogą się nie łączyć tak dobrze, jak powinny. Być może trzeba będzie zatrzymać niektóre karty, jeśli najpierw trzeba wykonać pewne czynności.

To powiedziawszy, ludzie nadal utkną lub odkryją, że zadanie jest o wiele trudniejsze niż oni lub ty, od czasu do czasu się spodziewałeś. Dlatego nadal pomocne jest otwarcie omawiać problemy w miejscu, w którym inni mogą udzielać porad, nie oceniając osoby mającej problemy.

Aby odpowiedzieć na kwestię mikro-zarządzania, o której wspominają niektóre inne odpowiedzi: nawet jeśli ludzie będą wykonywać małe zadania każdego dnia, przyjrzą się szerszej perspektywie wykonanej pracy, aby zorientować się, ile naprawdę każda osoba robi, zamiast osądzać ich na podstawie ich codziennych osiągnięć.

Sugeruję to, ponieważ pracuję w 8-osobowym zespole, w którym komunikacja jest bardzo łatwa, a ludzie dostępni. Dostajemy zadania, których praca nigdy nie powinna trwać dłużej niż dwa dni. Czasami te zadania są ze sobą ściśle powiązane i musimy się wzajemnie informować o tym, jak każdy z nas zajmuje się naszym własnym dziełem. Każdy z nas jest odpowiedzialny za zgłaszanie kierownikowi co dwa tygodnie.

Po ponownym przeczytaniu pytania zdaję sobie sprawę, że możesz zadawać to pytanie jako członek zespołu, a nie jako lider, więc możesz nie mieć kontroli nad swoimi zadaniami.

1. Możesz zasugerować swojemu liderowi, aby bardziej rozbił zadania
2. Jeśli twoja praca jest blokowana lub zależy od pracy innego członka zespołu, możesz się z nią skontaktować i podjąć inne zadanie, jeśli zajdzie taka potrzeba.

Przede wszystkim musisz przeanalizować siebie pod względem czasu i umiejętności. Jeśli jesteś osobą techniczną z pewnym doświadczeniem praktycznym, sprawy mogą się różnić od tych w przypadku, gdy jesteś tylko menedżerem (nie posiadającym silnej wiedzy technicznej nad tym, nad czym tak naprawdę pracują Twoi programiści), który musi tylko upewnić się, że terminy są dotrzymane .

Wspólny punkt w obu przypadkach jest to, że trzeba być w stanie zwiększyć swój zespół i stworzyć wrażenie, że im zaufać. Nie oceniasz ich wydajności, ale starasz się być empatyczny i pomocny, aby ich doświadczenie było przyjemne i łatwe.

Załóżmy teraz, że jesteś tylko menedżerem, jak powiedziałem powyżej, w takim przypadku nawet jeśli jakiś programista naprawdę napotyka poważny problem związany z rozwojem, możesz nie być w stanie mu pomóc. Rzeczywisty problem może być czasochłonny i wymagać będzie również koncentracji. Dalej zakładając, że programista jest naprawdę szczery w stosunku do swojej pracy i poświęca cały czas (nawet dodatkowy czas) na rozwiązanie tego problemu, ale niestety nadal nie jest w stanie go rozwiązać. W takiej sytuacji (kiedy nie jesteś w stanie w pełni zrozumieć problemu), ciągle pytasz o problem, postępując codziennie, a nawet nieformalnie dwa razy dziennie. Rezultatem byłaby skrajna frustracja i zakłócenia dla dewelopera. Niezależnie od tego, czy jest to aplikacja do zbierania codziennych postępów, czy tylko codzienne spotkanie stand-up, oba mogą być frustrujące.

Z drugiej strony, zachowując wszystkie pozostałe czynniki bez zmian, po prostu załóż, że masz silne zaplecze techniczne i pracowałeś nad tymi samymi technologiami w przeszłości. W takim przypadku codzienne postępy lub spotkania stand-up są naprawdę pomocne. Deweloperzy z pewnością zaufają Tobie i Twojej wiedzy i będą mogli swobodnie omawiać wielkie wyzwanie, przed którym stają. Dostarczysz kilka sugestii, które mogą być pomocne, a nawet jeśli nie są bezpośrednio pomocne, pomogą w zapewnieniu alternatywnych podejść.

Jednak w każdym przypadku codzienne spotkania stand-up muszą mieć poczucie, że jesteś członkiem zespołu, a nie szefem / liderem / menedżerem. O ile członkowie Twojego zespołu nie uznają Cię na tym samym poziomie co oni, nie będą w stanie wyrazić swoich obaw / sugestii / problemów / opinii itp.
Kolejna kwestia do rozważeniato wielkość twojego zespołu i czas, jaki masz na zarządzanie nim, zanim pomyślisz o użyciu oprogramowania do automatycznego śledzenia postępów lub zwiększeniu interakcji. Musisz upewnić się, że niezależnie od obaw zgłoszonych przez zespół, jesteś w stanie rozwiązać je jak najszybciej. Głównym czynnikiem demotywującym członka zespołu jest to, że jego obawy / sugestie / opinie nie są traktowane poważnie lub nie są cenione. Znajomość codziennych postępów jest ważna, ale tylko w przypadku pełnego zaangażowania się w pracę zespołu. Jeśli zajmujesz się również niektórymi firmami pobocznymi, nie próbuj więcej wchodzić w interakcje ze swoim zespołem. Pomyśl o sytuacji, w której reakcje Twojego zespołu są przytłaczające i przesyłają swoje zadania na długo, budząc obawy i zapytania, ale nie jesteś w stanie zapewnić terminowej informacji zwrotnej i recenzji. W takiej sytuacji,

Twórz i korzystaj z różnych pokojów czatu dla różnych konfiguracji. Niektóre mogą być szerokie jak @inżynierowie, a niektóre mogą być specyficzne, takie jak @newFeatureA

Zastanów się nad tym, aby codzienna awaria obejmowała przegląd biletów lotniczych.

Użyj otwartego środowiska, które wspiera współpracę i upewnij się, że QE i główny właściciel produktu znajdują się pośrodku programistów. Dużo usłyszysz i zobaczysz ekrany wokół siebie.

Jak zauważa Robert, przede wszystkim nie należy uważać za mikro-zarządzanie (zwróć uwagę na użycie „być widocznym”, tj. Niezależnie od twoich rzeczywistych zamiarów).

Ostatecznie śledzimy, co zostało osiągnięte w czasie i widzimy, jaka jest z tego nasza prędkość. Koncentrowanie się na postępach w ciągu dnia przynosi efekt przeciwny do zamierzonego, ponieważ ludzie zostaną zdemoralizowani i / lub odejdą.

Dziwi mnie, że nikt jeszcze nie wspomniał o komunikatach repozytorium „śledzonych” lub „oznaczonych gwiazdką” wbudowanych w systemy takie jak GitHub lub BitBucket.

Nasi techniczni interesariusze (kierownicy projektów, kierownicy ds. Rozwoju i wsparcia) śledzą nasz problem i zatwierdzają historie aktualizacji swoich odpowiednich projektów. Mamy mały zespół (15 FTE + kontrahentów), ale wydaje się, że to działa

Nikt nie jest mierzony żadną z tych rzeczy, ale oprócz cotygodniowych raportów o stanie od PM, daje to codzienny wgląd w projekt, aby przynajmniej uświadomić wszystkim, nad którymi obszarami pracują, więc nikt nie obejdzie się bez widoczności.

Pomogło to również zwiększyć przejrzystość wśród programistów i wykonawców oraz naszych kontaktów biznesowych, co pomaga wszystkim w rozliczaniu się z harmonogramów dostaw.

W połączeniu z kanałami RSS powiązanymi z konkretnymi repozytoriami lub w całej naszej organizacji, byliśmy w stanie ograniczyć e-maile (tam, gdzie było to potrzebne) i zaoferować podobny zestaw danych w czasie rzeczywistym i podsumowanie za pośrednictwem czytników RSS. Dla niektórych użytkowników jest to program Outlook, więc jest w zasadzie dla nich e-mailem, choć nieco inny, ale dla innych użytkowników używają one pełnoprawnego klienta RSS ze wszystkimi dodatkowymi filtrami, których potrzebują, aby dostosować go do ich dokładnych potrzeb.

Na początku mieliśmy podobne obawy dotyczące ilości e-maili, ale nasi użytkownicy końcowi wymyślili system RSS bez konieczności oddziału inżynierii, poza sugerowaniem klientów tym, którzy nie używają programu Outlook. Pracowaliśmy dla nas, ponownie około 20-30 FTE + kontrahentów przez cały rok w wielu biurach i strefach czasowych. Oczywiście, YMMV.

Jest to bardzo marginalny dodatek (i nie jest specyficzny dla programistów), ale odniosłem spory sukces z Asaną w ostatnich projektach.

W celu integracji z istniejącymi narzędziami do współpracy online nie szukaj dalej niż Slack . Jest zbudowany wokół pokoju rozmów, ale służy jako dość minimalistyczne centrum dla innych narzędzi, takich jak Asana, GitHub i Bitbucket. Ma przyzwoity zbiór tych „integracji”, zarówno gotowych i społeczność wykonane przy użyciu API, które oczywiście pozwala budować własne.