Co by się nie działo w naszej codziennej pracy projektowej musimy liczyć się z tym, że problemy na pewno się pojawią. W naszej pracy kierownika projektu kluczowe będzie to jak sobie z nimi poradzimy i jaką strategię wybierzemy. Umiejętności związane z identyfikowaniem i znajdywaniem rozwiązań zwłaszcza złożonych problemów mogą stać się naszym koronnym wyróżnikiem, który spowoduje, że zostaniemy dobrze zapamiętani.
Przeglądając różne raporty o umiejętnościach, jakie powinien posiadać project manager coraz częściej wymienia się „problem solving” (ang. rozwiązywanie problemów) oraz „critical thinking” (ang. krytyczne myślenie). Obie te cechy są pożądane przez pracodawców poszukujących kierowników projektów, bo to właśnie te umiejętności powodują, że nie tylko lepiej realizujemy projekty, ale długoterminowo i pozytywnie wpływamy na organizacje. Poza samymi umiejętnościami potrzebujemy jeszcze sprawdzonych narzędzi oraz technik, które ułatwią nam pracę. W jubileuszowej, bo już dwudziestej części skrzynki project managera, podzielę się z Wami moimi doświadczeniami dotyczącymi dobrych praktyk w rozwiązywaniu problemów.
Kultura rozwiązywania problemów
Jeśli zależy nam na ciągłym polepszaniu się i dobrych wynikach musimy na początek zadbać o to by rozwiązywanie problemów było wpisane w DNA naszej organizacji. Będąc częścią organizacji, której kultura zorientowana jest na poprawianie się z pewnością będzie nam łatwiej i efektywniej pracowało. Praca nad takim podejściem nie należy do najłatwiejszych, jednak jako liderzy projektów możemy próbować walczyć o to, by nasza firma i współpracownicy wspierali proaktywne podejście do usuwania przeszkód, inwestowania w ulepszenia i ciągły rozwój. Ogromny nacisk na ten aspekt kładą wszystkie zwinne metody pracy. W wartościach i pryncypiach agile niezależnie od metody możemy znaleźć „problem solving” – na rysunku 1. przykład z Scaled Agile Framework i jednego z fundamentalnych pryncypiów.
Wachlarz możliwości
Wpisując w wyszukiwarkę hasło: „problem solving” znajdziemy ponad cztery miliardy (!) stron. Wśród nich możemy dostrzec hasła: rozwiązywanie problemów w trzech, czterech, pięciu, siedmiu itd. krokach. Analizując niektóre z polecanych sposobów znalazłam kilka wspólnych mianowników. Niezależnie od tego jak będziemy chcieli postępować i jakie narzędzia wykorzystamy cały proces opiera się na kilku podstawowych krokach, które możemy ze sobą łączyć, czasem omijać, lub dostosowywać techniki by osiągnąć zamierzony cel.
Kluczowe aspekty rozwiązywania lub zmniejszania problemów możemy zauważyć na rysunku 2. Możemy je ze sobą łączyć, jednak to co najważniejsze to trafne określenie i zdefiniowanie samego problemu. Odpowiednia analiza, konkretne mierniki i dane, które pozwolą nam lepiej i dogłębniej poznać problem są kluczowe w dalszym postępowaniu. Warto skupić się na najważniejszych przyczynach problemu, bo to one wpływają na to, że ów istnieje i powoduje szkody. Trzeba pamiętać, że zbyt szybkie próby decyzji jak daną przeszkodę pokonać lub usunąć mogą doprowadzić nas do kolejnych kłopotów. Dlatego tak istotne jest wnikliwe przeanalizowanie przyczyn, a nie samego efektu. Dopiero gdy wiemy, co powoduje problem, możemy przejść do konkretnych decyzji jak z nim walczyć.
Na ogół nie mamy większych przeszkód z wymyślaniem właściwych akcji, ale to co poza analizą jest ważne, to również weryfikacja i potwierdzenie czy problem został faktycznie ujarzmiony, a jeśli nie, to decyzja, jakie kroki podejmiemy dalej. Z własnego doświadczenia wiem, że niestety z tym ostatnim krokiem mamy później najwięcej problemów. Albo brakuje nam czasu na sprawdzenie czy sprawa została rozwiązana, albo zwyczajnie z góry zakładamy, że ustalone akcje przyniosą zamierzony efekt i nie weryfikujemy czy tak rzeczywiście się stało.
6 etapów i po kłopocie
We wstępie do tego artykułu wspomniałam, że narzędzi dla problem solvingu jest wiele, i możemy je śmiało wykorzystywać. Moim ulubionym stało się rozwiązywanie problemów w sześciu krokach, które promuje Scaled Agile Framework (SAFe) dla ceremonii Inspect & Adapt. Do tej pory wielokrotnie korzystałam z niego w zespołach, z którymi pracuję, nie tylko w tych, gdzie wykorzystywany był SAFe.
Warsztat dotyczący rozwiązywania problemu dla naszego zespołu powinien trwać ok 1,5 do dwóch godzin. Dla każdego z sześciu kroków ustalamy dokładny czas trwania po to żeby później prowadząc sesję w zakładanym czasie osiągnąć zamierzony efekt, tj. listę akcji jakie planujemy wdrożyć aby zlikwidować lub zmniejszyć przyczyny danego problemu.
Pierwszym krokiem wedle tego formatu jest ustalenie problemu jaki chcemy rozwiązać. Możemy do tego przygotować się wcześniej, prosząc zaproszonych uczestników o zastanowienie się nad potencjalnymi problemami z którymi boryka się nasz zespół, albo zrobić krótką retrospektywę na początku spotkania i wybrać na czym chcemy się skupić. W swoich wcześniejszych zespołach, z racji tego że był to dość duży zespół, składający się z kilku scrumowych, wybieraliśmy problem na podstawie listy wcześniej przygotowanych przez członków opisów i krótkich jedno- lub dwu minutowych prezentacji na początku warsztatu. Po prezentacji wszyscy uczestnicy spotkania mogli głosować na te problemy, które według nich mają dla nas największy wpływ. Poniżej przykład tabelki, którą można wykorzystać do zbierania danych przed warsztatem.
Lp. | Zgłaszający | Tytuł | Opis problemu | Efekt/ konsekwencje | Wpływ na | Głosy |
---|
1 | Jan Kowalski | Dostępność środowisk testowych | Testerzy nie mogą ukończyć prac i mają duże przestoje z uwagi na częste problemy z dostępnością środowisk testowych | 1) 30% historyjek spada na kolejny sprint i nie zostają ukończone w zaplanowanym czasie 2) spada motywacja i morale zespołu 3) niezadowolenie biznesu – niedotrzymywanie zobowiązań | wszystkie zespoły w ART | 25 |
2 | Antonina Maj | Przesuwanie daty wdrożeń | Ostatnie 3 wdrożenia na produkcję w ostatniej chwili zostały przesunięte o co najmniej 1 tydzień | 1) 3 z 5 zaplanowanych wdrożeń na prod miały opóźnienia | klientów | 22 |
Tab. 1. Im lepiej opisany i sformułowany problem i jego efekt, tym łatwiej wybrać ten,
którego rozwiązanie może przynieść nam największe korzyści w przyszłości.
Opracowanie własne, dane w niej zawarte – wymyślone na potrzeby artykułu.
Drugim etapem jest odpowiednie dotarcie do przyczyn problemu, tzw. root cause analysis. Tu wykorzystać możemy diagram Ishikawy znany także jako fishbone diagram. Dla predefiniowanych kategorii, takich jak: ludzie, procesy, narzędzia, środowisko, program, zadając sobie pytanie: Dlaczego? wypisujemy przyczyny problemu. Korzystając jednocześnie z techniki 5 Why (z ang. 5 x Dlaczego?) powtarzamy to samo pytanie tak długo, aż dojdziemy do ostatecznej przyczyny. Ta część powinna być bardzo konkretna i wnikliwa, pozwoli ona nam na rzeczywiste zorientowanie na najistotniejszej przyczynie. Stąd tak ważna jest tu rola facylitatora, który przede wszystkim będzie pilnował, aby zespół nie przeskakiwał od razu do potencjalnych rozwiązań i akcji, które można wykonać, ale w pierwszej kolejności skupił się na przyczynach. Niejednokrotnie podczas tego kroku widziałam najwięcej błędów i chęci rozmawiania już o tym co należy zrobić, dlatego uczulam każdego, aby precyzyjnie wyjaśnił cel tej części i zadbał o to aby najpierw skupić się na przyczynach.
Kolejnym, trzecim punktem jest wybranie przyczyny, która w największej mierze generuje problem. Możemy posłużyć się analizą Pareto, która to polega na tym, by wszystkie przyczyny umieścić na grafie w zależności od ich wpływu na problem. Zgodnie z zasadą Pareto znaną również jako 80-20, znajdujemy jedną taką przyczynę, której rozwiązanie spowoduje zniwelowanie w 80% problemu. Decyzję tę warto poprzeć również zebranymi danymi, ilością przypadków, a nie własnym odczuciem.
Gdy wybraną mamy główną przyczynę zabieramy się do zadania, które pochłania zdecydowanie najmniej czasu, ale jest kluczowe do przejścia dalej. W czwartym kroku zajmujemy się przeformułowaniem problemu z uwzględnieniem wybranej najważniejszej przyczyny. Jeśli weźmiemy dla przykładu problem z punktu pierwszego wyżej podanej tabeli, może to wyglądać następująco:
Pierwotny zapis problemu: Niedostępne środowiska testowe przez 30% czasu. Po jego przeanalizowaniu i wybraniu najważniejszej przyczyny nowy zapis problemu mógłby wyglądać następująco: Integrowanie kodu na środowiskach testowych z błędem i próby kolejnych integracji powodują niedostępność środowisk testowych przez 30% czasu.
Dopiero w taki sposób sformułowany problem pozwoli nam na zaadresowanie właściwych działań, które skupiać będą się na największej przyczynie. Tym samym możemy przejść do burzy mózgów, podczas której zespół zaczyna wymyślać kroki i akcje jakie mógłby potencjalnie wdrożyć w przyszłości, aby uniknąć lub zmniejszyć pojawiający się problem.
W piątej części warsztatu, podczas burzy mózgów powinniśmy podkreślać, że każdy pomysł, jaki wpadnie nam do głowy, powinien zostać zapisany, nawet jeśli wydaje nam się on surrealistyczny albo niewykonalny. Gdy mamy gotową listę pomysłów przechodzimy do jej omówienia, przedyskutowania, tak, aby każdy wiedział, co autor danej inicjatywy miał na myśli, a następnie głosujemy na pomysły, które zespół uważa za najistotniejsze i najlepsze. Po zliczeniu głosów, te które otrzymały ich najwięcej w ostatnim kroku wpisujemy do rejestru produktu jako nasze usprawnienia, do których realizacji przejdziemy zaraz po warsztacie. Warto je transparentnie dodawać do backlogu, wyceniać i w trakcie trwających iteracji poświęcać im czas, a później także pokazywać efekty ich wdrożenia, by zapewnić naszych interesariuszy, że dbamy o ciągłe doskonalenie się i jeszcze lepsze dostarczanie.
Sama w tej formule przeprowadziłam kilka warsztatów i mogę Wam zagwarantować, że naprawdę płyną z nich ogromne korzyści i zachęcam Was do spróbowania i dalszego działania. Jeśli powyższa metoda wydaje się Wam zbyt rozbudowana, zachęcam do skorzystania z innych, powszechnie znanych technik analizowania, rozwiązywania i monitorowania problemów.
Na co uważać?
Istnieje całe mnóstwo reguł, na które należy zwrócić uwagę. Identyfikując i wybierając problemy do rozwiązania w naszych projektach czy zespołach powinniśmy przede wszystkim pamiętać, aby był to ciągły proces i nieustanne dbanie o doskonalenie się. Trzeba również pamiętać, by mierzyć siły na zamiary, nie brać na siebie za dużo, a tyle ile jesteśmy w stanie zrobić. Zwłaszcza gdy problemów jest dużo, dobrze nadawać im odpowiednie priorytety i krok po kroku działać nad nimi. Bardzo ważne jest również bazowanie na danych, konkretnych miernikach, a nie naszych przeczuciach i intuicji. Obserwacja jest ważna, ale dobrze jest ją poprzeć twardymi danymi. Jak bardzo inne jest stwierdzenie: „Ciągle się spóźniamy”, od „25% naszych zobowiązań nie jest dostarczane na czas” – zapewne gołym okiem zauważacie różnicę pomiędzy tymi sformułowaniami. Może się okazać, że w danym miejscu i czasie te 25% opóźnień nie jest aż tak złym wynikiem – wszystko zależy zawsze od kontekstu.
Weźmy również pod uwagę paradoks ukrytych kosztów. Wybierając rozwiązania naszych problemów pamiętajmy o tym, czy koszty jakie musimy ponieść, aby zniwelować dane wyzwanie są warte inwestowania. Często nawet najlepszy pomysł może nieść za sobą inne konsekwencje, w tym finansowe lub czasowe. Stąd też decydujmy się na kroki, które są realne, na które mamy wpływ i rzeczywiście warto w nie inwestować czas i pieniądze. Czynniki warte uwagi to nie tylko koszt implementacji, ale ryzyka z nim związane, na przykład czy mamy odpowiednią wiedzę i umiejętności, innymi słowy czy nie porywamy się z przysłowiową motyką na słońce.
Teoria góry lodowej
Zwracajmy uwagę na przyczyny, szukajmy tego co niewidoczne, a co powoduje problemy. Nie patrzmy tylko na efekty i konsekwencje, ale zweryfikujmy, co kryje się pod poziomem morza naszej góry lodowej. Często widzimy tylko wierzchołek problemu, jego efekt, a jeśli naprawdę chcemy go zniwelować musimy dojść do jego sedna. Tak jak góra lodowa, której większą część jest niewidoczna na pierwszy rzut oka.
Jedno jest pewne: nie robiąc nic – tracimy, robiąc cokolwiek i próbując usprawnić swoją pracę możemy tylko zyskać, nawet jeśli miałaby to być jedynie wiedza czego nie robić następnym razem. Dlatego warto inwestować i nasz czas i budżet w ciągłe skupienie się na rozwiązywaniu problemów. Może być to 10-15% naszego czasu, nie musi to być duża część naszej codziennej pracy, ale jeśli choć trochę go poświęcimy i będziemy robić to regularnie, unikniemy etapu ciągłego gaszenia pożarów. Presja czasowa i piętrzące się kłopoty nigdy nie działają dobrze i warto tego unikać.
[ENG] Leader, Agile ways of working enthusiast. Has over 10 years experience with multicultural teams. Support teams achieving their goals, delivering projects and solutions that are focused on meeting clients needs. People doing the work are priority number one for her and she does her best motivating and empowering them. PMP® & SAFe SPC® certified, trainer and designer of interactive workshop. In her free time, passionate of active forms of leisure, crime stories, baking and cooking.
[PL] Liderka, pasjonatka zwinnej pracy projektowej. Posiada ponad 10-letnie doświadczenie w pracy w zespołach wielokulturowych. Wspiera zespoły w osiąganiu celi i dostarczaniu projektów lub rozwiązań, które spełniają oczekiwania klienta. Wierzy, że w pracy na pierwszym miejscu są ludzie i to ich wspiera w dotarciu do celu. Projektuje gry i interaktywne warsztaty szkoleniowe. Akredytowany trener PMP® oraz SAFe SPC®. W wolnym czasie fanka aktywnego wypoczynku, kryminałów, pieczenia i gotowania.