Rozwój zawodowy i psychologia, Wydarzenia,
16 września 2020
Dzień Porażki 2020
Sukcesy są fajne, ale to przez porażki wiedzie prawdziwe życie. I droga do sukcesów. Trzeba umieć uczyć się na błędach.
Miałam okazję zaczerpnąć wiedzy u samego źródła – autora Manifestu Agile – Arie van Bennekum. Spotkałam Ariego na PAM Summit w Krakowie 🙂 Chociaż posługiwaliśmy się różnymi pojęciami i narzędziami, odkryłam jak zdumiewająco wiele mamy wspólnych celów i jak wiele jest możliwości połączenia porządnej analizy i podejścia zwinnego dla dobra naszych klientów.
A w zasadzie – nie. Właściwie chcemy tego samego – zadowolenia klienta z produktu, który otrzymuje. Agile przeciwstawia się wielomiesięcznemu zamykaniu przed klientem, sztywnym procedurom, planom i dokumentom, które odgradzają od drugiego człowieka – odbiorcy (hasło firmy Ariego to “People make the difference”). Analiza w ujęciu formalnych narzędzi, metod dogłębnego zrozumienia problemu, sprzeciwia się bałaganowi, brakowi ładu i planu, czyli rzeczom, które spotyka się obecnie niestety często, a utrudniają one znacząco wykonywanie systemów wysokiej jakości i odpowiadających potrzebom klienta.
Chaos _______________________________________________________ Sztywność
Arie jest za tym, żeby przeprowadzać analizę na początku projektu. Nazywał to spotkaniami, warsztatami, ale generalnie mieliśmy zadziwiająco spójną wizję. Co mnie urzekło w rzeczach, ktore podkreślał twórca Agile – pierwsze i najważniejsze, to zrozumieć cel klienta! Nie to, co ma robić zamówione oprogramowanie, ale przyczyny podjęcia decyzji o jego zamówieniu. Przesłanki te są osadzone w biznesie klienta, np. obniżenie kosztów, wykorzystanie możliwości rynkowej, zwiększenie efektywności głównych procesów. Właśnie! Po drugie – zrozumieć jak działa biznes klienta, zrozumieć jego procesy biznesowe, które są powiązane z problemem, który staramy się zaadresować. Zrozumieć i jeszcze raz zrozumieć! Nie mogłabym się zgadzać bardziej:) Więc jak? Analiza biznesowa first, a później dobieranie rozwiązania. Propozycjom funkcji przydzielamy priorytety (np. MoSCoW), żeby określić co jest konieczne, a co stanowi miły acz niekonieczny dodatek i umiejętnie dobierać funkcje tak, aby zawsze dostarczać produkt najwyższej wartości dla klienta (wodotryski nie są konieczne), a także uświadamiać, czego rozwiązanie nie będzie miało (Won’t have).
“Working software over comprehensive documentation” – to jedno z najczęściej opacznie rozumianych stwierdzeń Manifestu Agile. Arie mówił jak wielu spotyka ludzi, którzy są przekonani o swojej zwinności, ponieważ nie tworzą dokumentacji. Zwinność to nie chaos. Metodyki nurtu agile mają wiele procesów i narzędzi, których należy ściśle przestrzegać. Dokumentacja odgrywa w nich mniejszą rolę niż działające oprogramowanie, ponieważ to właśnie odbiera klient. Działamy w celu stworzenia rozwiązania, nie dokumentacji. Jednak jej tworzenie, jeśli nie jest przerostem formy nad treścią, nie jest żadnym demonicznym działaniem. Arie lubi rysować na spotkaniach z klientem. Ja też. Moje modele i opisy spełniają ważną rolę – pomagają weryfikować kompletność i spójność tego, o czym mówimy. Zanim nie narysujesz modelu, nie wiesz, ile rzeczy dostąd nie zauważyłeś. Zanim nie zapiszesz jawnie przyjętych założeń, nie zobaczysz, że pociągają one kolejne doprecyzowujące pytania. Takie dokumentowanie służy produktowi, buduje zrozumienie analityka i wspólne zrozumienie problemu w taki sam sposób przez wszytskich zainteresowanych, nie jest ślepym dopełnianiem procedury.
Arie widzi miejsce dla analityka w Agile. Jest to styk świata biznesu ze światem IT. Nie ma też problemu ze specjalizacją w zespole – jeśli mamy analityka, wysyłamy go na pozyskiwanie wymagań. Musi być ktoś, kto lubi drążyć temat i rozumie biznes. Co ma być efektem pracy analityka? Po pierwsze – zrozumienie, po drugie, w zależności od metodyki, np. w Scrumie Rejestr Produktu (czy analityk czy PO, to kwestia do rozstrzygnięcia), doprecyzowanie wymagań w bardziej dokładnej dokumentacji? Czemu nie? Sprinty i prezentacje dla klienta? Cóż jest mniej kosztownego i szybszego do wykonania niż prezentowanie w pierwszym sprincie protowypów-modeli przypadków użycia, które można łatwo zweryfikować, odrzucać i zmieniać oraz prototypów-makiet, które pomagają zwizualizować klientowi proponowane rozwiązanie?
Individuals and interactions over processes and tools.
Dobry analityk posiada zestaw narzędzi, z kórych może wybierać te, które najlepiej będą pasować do projektu i klienta, nie jest niewolnikiem procesów, których nie potrafi dopasować.
Working software over comprehensive documentation.
Dobry analityk tworzy dokumentację i modele, które służą projektowi, nie są bezmyślmym wypełanianiem nadmiarowych szablonów.
Customer collaboration over contract negotiation.
Tu wiele zależy od dostępności klienta i przyjętego modelu współpracy. Im większe stawki i klienci, tym trudniej.
Responding to change over following a plan.
Dobry analityk proponuje rozwiązanie oparte na zrozumieniu biznesu, stąd wiele zmian jest przewidywalnych lub rozwiązanie jest w stanie jest łatwo zaadaptować, jeśli się pojawią; podążanie do ruchomego celu nie jest proste, ale dzielenie planów na krótkie okresy stanowi dobry kompromis między zmianami a planem.
Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.
