środa, 22 lutego 2017

Detekcja problemów na miękko i na twardo....:-)

Zacznę od posypania głowy popiołem i przyznam, że długo nie było mi po drodze napisać merytorycznego artykułu. Recenzje wydarzeń, wsparcie medialne konferencji, książki, itp... to ostatnie kilka postów. Chciałbym trwale zmienić trend i wrócić do regularnego pisania. Tym razem proponuję temat, który żywo dyskutowaliśmy podczas jednej z otwartych sesji zeszłorocznego Agile Coach Camp. Temat nie nowy, jednakże wzbudził wśród uczestników tejże sesji wiele zainteresowania a mnie spodobał się mnogością przedstawionych sposobów detekcji problemów. Sesja zakończyła się po szybkich 45 minutach, wobec czego temat zdążyliśmy ruszyć tylko na poziomie nagłówków. Ale z drugiej strony podczas ACC o to własnie chodzi, o swoistą zajawkę i uruchomienie chęci dalszego zgłębiania wiedzy. Podziękowania dla Kuby Drzyzga za poprowadzenie tej konkretnej sesji i inspirację do dalszych prac nad zagadnieniem. Dzisiaj przedstawię kilkanaście sposobów na detekcję problemów, wierzę że Wam też to się przyda. Zatem zacznijmy... zachęcam do dyskusji!

Na wstępie chciałbym zauważyć, że do wszelkiego rodzaju usprawnień/spostrzeżeń/korekt zespoły powinny dochodzić same, bez ingerencji z zewnątrz. Jest to niekoniecznie najkrótsza i najszybsza ale najlepsza droga do osiągania przez zespół samoorganizacji i wspierania od początku kultury opartej o 5 wartości Scrum. Drugą składową układanki jest dostarczany w ramach iteracji, zawsze działający funkcjonalnie, kawałek oprogramowania. Na tej podstawie możemy oprzeć detekcję potencjalnych problemów i starać się wspólnie wypracować satysfakcjonujące wszystkich rozwiązania. Przyglądając się zgłoszonym zagadnieniom nie uniknąłem chęci podziału na dwie grupy. Jedną odpowiedzialną za stronę czysto ludzką (związaną z uczuciami tj. odwagą, zaangażowaniem, zaufaniem, itd) i drugą opartą o twarde dane, fakty, liczby.

Do grupy sposobów detekcji problemów z obszaru miękkiego zaliczyłem:
  • Budowanie zaufania, wszyscy wiemy jak ważne jest to, aby w zespole każdy na każdym mógł w pełni polegać. Jest to absolutna podstawa dobrej współpracy i tego aby ludzie mieli ze sobą dobry kontakt i w każdym momencie byli skłonni dzielić się ze sobą dobrą ale też i złą nowiną. Proces budowania zaufania wymaga czasu, jednakże jest bardzo istotny dla wydajnej pracy zespołowej. Pozwala znacznie szybciej dostrzegać przesłanki o potencjalnie pojawiających się problemach.  
  • Empatia, to rodzaj duchowego wsparcia którego jedna osoba możne udzielić drugiej. Są sytuacje w których członkowie zespołu mogą mieć kłopot, którym chcieliby się podzielić ale nie mają z kim.... Na pewno podobne sytuacje zdarzają się również w Waszych zespołach. Czasem wystarczy wejść w buty drugiej osoby, wczuć się w jej rolę i przede wszystkim wysłuchać tego co ma do powiedzenia. Patrząc oczami tej osoby spróbować następnie zrozumieć jej perspektywę i położenie. Jak się domyślacie empatia wymaga od osoby słuchającej pełnego zaufania, szacunku, otwartości i bezstronności. Łatwiej przyjdzie o takie wsparcie osobom będącym już na stopie koleżeńskiej.
  • Zaangażowanie zespołu na meetingach, nie bez powodu zaangażowanie jest jedną z 5 wartości Scrum. Zaangażowanie podczas spotkań to tylko jeden z przykładów. Zespół Scrum nie ma menedżera przed którym się rozlicza, pyta co dalej, itp. Składa się za to z pełnoprawnych i równych wobec siebie członków, którzy razem podejmują decyzje, motywują się przed sobą i wnoszą na co dzień niezbędny wkład w celu osiągnięcia celu iteracji czy wydania. Jeżeli brakuje zaangażowania jednemu lub większej liczbie członków zespołu wiedz, że nie dzieje się najlepiej i trzeba szybko reagować...
  • Pytania na około, praca Scrum Mastera to nieustanne bycie w pobliżu zespołu, pomoc, wsparcie, bycie "liderem służebnym", osobą która widzi nieco więcej niż pozostali członkowie zespołu i wie kiedy być sugestywnym, kiedy stać z boku a kiedy wkroczyć do akcji. Rolą Scrum Mastera jest również coaching zespołu, dzięki pytaniom na około może zebrać niezbędne informacje w delikatny sposób nie wywierając na nikim presji czy uniknąć bezpośredniego sugerowania. Technika również przydatna w pomaganiu osobom w dochodzeniu do własnych rozwiązań poprzez naprowadzanie. 
  • 1:1 z feedbackiem, spotkania 1:1 mogą być organizowane jednorazowo (raczej ad hoc w celu poratowania sytuacji, mediacji podczas konfliktu, zebrania faktów) lub częściej cyklicznie w formie regularnych statusów gdzie strony wzajemnie wymieniają się informacjami. Wszyscy zdajemy sobie sprawę, że feedback jest niezbędny, ale większość z nas często zmaga się z problemem utrzymania wydajności pracy na wysokim poziomie. Dlatego dając informacje zwrotne 1:1 powinny one być: 
    • Natychmiastowe, przekaz informacji zaraz po zaobserwowaniu czegoś konkretnego. Wyobraź sobie, że ktoś zrobił wspaniałą rzecz dla projektu, nie czekaj z pochwałami, tego samego dotyczy kwestia feedbacku w drugą stronę w razie niepowodzenia.
    • Cykliczne, informacje zwrotne powinny mieć swoją regularność, spotykanie się przysłowiowo raz do roku byle coś odfajkować...nie będzie miało sensu.
    • Ciągłespotkania oferują możliwość uzyskania i dania informacji zwrotnych, to doskonałe miejsce na detekcje problemów/przeszkód stojących na drodze do celu.
    • Spójneinformacje zwrotne warto uzupełnić o opinie kolegów, podwładnych, a czasem nawet klientów, nigdy nie należy polegać wyłącznie na własnych obserwacjach.
  • Wykresy humoru zespołu (ang. mood chart) to sposób na zapytanie każdego członka zespołu z osobna jaki ma humor na co dzień przez cały okres trwania iteracji. Schemat emocji pozwala eliminować problemy zachowań oraz zachęca zespół do odważnej komunikacji na co dzień. Szczególnie ważny tutaj może być temat negatywnych emocji i rozładowywania pojawiających się konfliktów, które mogą nam rozsadzać zespół od środka. Podczas korzystania z tego prostego narzędzia, którym mogą być codziennie, wspólnie rysowane wykresy humoru albo określane buźki (rodzaj uczucia) powinny budować i wzmacniać więzi w zespole, pozwalać wzajemnie się poznawać, wsłuchiwać w to co mówi druga osoba, po to by potencjalnie unikać agresywnych zachowań i poprawić komunikację.
  • NPS(ang. net promoter score) to narzędzie oceny lojalności klientów danej firmy, jest alternatywną metodą oceny dla tradycyjnych badań satysfakcji klientów. Zakłada się, że wartość NPS jest skorelowana ze wzrostem przychodów firmy. Chodzi o to, aby nasi klienci chcieli polecać nas jako godnych partnerów innym klientom. Szukając dalej, znalazłem informacje o eNPS (ang. employee NPS)  który ma zastosowanie wewnątrz firmy. Pracownicy są pytani o możliwości rozwoju, nastawienie i entuzjazm do pracy, kreatywność zadań i chęć pracy w danej firmie. Tak jak NPS dostarcza danych o ilości promujących/nie polecających nas klientów, tak eNPS spełnia rolę katalizatora atmosfery w firmie. Pokazuje rozkład nastrojów, potencjalnie zbierające się czarne chmury ale jeszcze przed burzą.... 
  • "Fuck upy" wszelkiej maści kłopoty, które uderzają nam w zespół w najmniej spodziewanym momencie.
    • problemy na produkcji, objawiające się dużą ilością incydentów. Często powtarzającymi się problemami z którymi sobie nie radzimy, nie dotrzymujemy umów SLA lub radzimy sobie szczątkowo zamiast kompleksowo, często łatając powierzchniowo tam gdzie widać kłopot ale nie likwidując prawdziwej przyczyny problemu.  
    • zwolnienia/dużą rotacja, to ludzie zawsze tworzą firmę, zespół, kolektyw. Często mówi się, że ludzie nie odchodzą z firmy ale od swojego szefa, który nie potrafi ich przy sobie zatrzymać, zmotywować, pokazać celu ich pracy. Ze swojej ponad 10 letniej praktyki muszę przyznać, że faktycznie jest coś w tym stwierdzeniu.... 
    • niezadowoleni klienci równają się kłopotom często już w krótkim terminie. Oznacza to potencjalne rezygnacje, zmniejszone przychody, nerwowość i potencjalne szukanie winnych. Wiemy jak ważna jest opinia na przykładzie opisanego wyżej NPS. Korzystniej mieć wielu promotorów i przekonywać nieprzekonanych, niż nie zważać na opinię innych. 

W grupie detekcji problemów opartych o twarde dane, w mojej ocenie znalazły się:
  • KPIs (ang. key performance indicators) to wskaźniki efektywności, które mierzą realizację założonych celów. Używane są w wielu różnych dziedzinach życia w formie metryk, statystyk, różnorodnych danych zbieranych w regularnych odstępach czasu w odniesieniu do planu. Na ich podstawie można analizować przeszłość, zakładać plany na przyszłość czy starać się śledzić trendy. Do takowych metryk można zaliczyć między innymi:
    • % dostarczania zaplanowanego zakresu
    • prędkość zespołu (velocity) z uwzględnieniem dostępności zespołu 
    • kryteria jakości kodu (pokrycie testami)
    • ilość błędów znalezionych na produkcji
    • zadowolenie klientów (ankiety)
  • Anonimowa ankieta, w ramach której dajemy wszystkim uczestnikom pełną swobodę wypowiedzi. Dzięki zachowaniu anonimowości ludzie powinni czuć się nieskrępowani w wyrażaniu swoich prawdziwych opinii, pokazywaniu informacji na temat potencjalnych problemów, niezadowolenia czy obaw o przyszłość. Dobrze, jeśli dodatkowo zawrzemy w niej pewne pytania weryfikujące aby potwierdzić prawdomówność uczestników ankiety oraz umożliwimy osobom dodawanie komentarzy. Komentarze mogą często wzmocnić przedstawione stanowisko konkretnymi przykładami z życia. Metoda może być stosowana wewnętrznie jak również zewnętrznie włączając w nią realnych użytkowników końcowych.
  • Tradycyjne, dobre retro, wiele na ten temat zostało już napisane, chciałbym w tym punkcie odesłać Was do posta z przeszłości -> Efektywne retro
  • Drzewo CRT (ang. current reality tree) inaczej drzewo obecnego stanu. Termin drzew CRT wypływa z  pojęcia Teorii Ograniczeń Goldratta (TOC – Theory of Constraints), TOC pomaga walczyć z ograniczeniami! Trącamy tutaj o analizę statystyczną danych. Twórca drzewa dąży do uporządkowania niepożądanych skutków, tak aby w rezultacie odnaleźć przyczyny źródłowe. Te „przyczyny źródłowe” (może być ich więcej niż jedna) to nasze ograniczenia. Dopiero kiedy poznamy ograniczenia możemy się zabrać za ich minimalizację lub całkowitą likwidację. Próba naprawy wszystkiego dookoła to tylko doraźne „gaszenie pożarów”, ale nie usuwanie ich rzeczywistych przyczyn. Prawdopodobnie poświęcę jeden z kolejnych postów tej tematyce, ponieważ wiedza na ten temat nie jest powszechnie znaną. Innym przykładem podobnym do drzew CRT jest diagram Ishikawy. 
  • Zasada Pareto (80/20), zasada stara jak świat która głosi, że 80% wyników wypływa z 20% przyczyn. Inaczej mówiąc 20% problemów będzie miało wpływ na 80% symptomów negatywnie wpływających na nasz produkt i zespół. Naszym zadaniem będzie umiejętne wyselekcjonowanie własnie tych 20% problemów które są dla nas aktualnie najistotniejsze. Przecież to własnie nimi musimy zając się w pierwszej kolejności!
  • Prawdopodobieństwo dowiezienia w skali 1-5, warto często pytać zespół deweloperski czyli ludzi pracujących operacyjnie o prawdopodobieństwo dowiezienia zaplanowanego zakresu sprintu w z góry określonym timeboxie. Wiedza szczególnie ważna dla Produkt Ownera, daje pogląd całemu zespołowi na rozwijającą się w trakcie sprintu sytuacje. Dodatkowo nie będzie efektu zaskoczenia pod koniec iteracji, jeśli zespół nie będzie w stanie dowieźć 100% prognozy. 
  • Analiza 5Why - podobnie jak w przypadku retro tak i tutaj chciałbym odesłać Was do dedykowanego posta na temat analizy "5 Razy Dlaczego"
  • RCA (ang. root casue analysis), to analiza post factum po wdrożeniu i wykryciu przez klienta bądź użytkownika końcowego błędów na produkcji. Doświadczając takiej sytuacji, warto usiąść z zespołem i zastanowić się gdzie była bądź istnieje luka i dlaczego tak się stało. Być może obszar funkcjonalny był niedostatecznie testowany lub nie był testowany w ogóle. Analiza RCA powinna odpowiedzieć na takie pytanie, jednak nie powinna kończyć się tzw. "polowaniem na czarownice" i koniecznością wskazania osoby odpowiedzialnej. Raczej szukamy wspólnie powodu wystąpienia przecieku i dokonujemy odpowiednich zmian aby rozpatrywany problem nigdy więcej nie wystąpił ponownie.  Do określania przyczyny często przydaje się tutaj metoda 5Why. Tą metodę można również wykorzystać do określenia gęstości problemów w komponentach produktu czy na ich stykach. Dlaczego? Aby lepiej lokować wysiłek testerów w obszary generujące większą ilość błędów. 

Brak komentarzy:

Prześlij komentarz