blog.testowka.pl

Archiwum wiadomości z Lipiec, 2014

Ludzie zawsze podejmują najlepsze z możliwych decyzji – a managerowie?

opublikowany przez 22, Lip, 2014, w kategoriach Agile, Zarządzanie

decisionPisałem blisko rok temu o postawie coacha i o kilku faktach na temat nas samych którymi coach powinien się kierować. Jedną z przytoczonych przeze mnie prawd było stwierdzenie, że „Ludzie zawsze podejmują najlepszą z możliwych decyzji w oparciu o informacje, którymi dysponują”.

Tak, zdaję sobie sprawę z tego jak bardzo kontrowersyjne jest powyższe stwierdzenie. Wielokrotnie sam też miałem wątpliwości co do jego poprawności zwłaszcza obserwując osoby decyzyjne w firmach zajmujących się różnymi rzeczami (nie tylko IT).

Managerów można podzielić na tych dobrych i tych złych – na tych, którzy w naszej ocenie podejmują dobre decyzje i na tych, których decyzje nie są najlepsze (z naszej perspektywy). Często też upływ czasu pokazuje, że nasza perspektywa i obserwacje były poprawne i manager się mylił od samego początku.

Ale jak to? Przecież podejmował najlepszą z możliwych decyzji w oparciu o informacje które posiadał… No właśnie, pytanie brzmi czy posiadał wszystkie informacje jakie mógł zdobyć w danym momencie? Czy zrobił wszystko by te informacje pozyskać? Czy zadał odpowiednie pytania odpowiednim osobom? Czy może po prostu podjął decyzję na podstawie tego co wiedział w danym momencie?

Miałem przyjemność w swojej karierze pracować z wieloma managerami/osobami decyzyjnymi – zarówno jako pracownik, współpracownik jak i doradca czy agile coach. W mojej ocenie dobrego managera charakteryzuje właśnie ta dociekliwość i umiejętność pozyskania jak największej ilości informacji potrzebnych do podejmowania decyzji. Jednocześnie kluczowe jest podejmowanie decyzji wystarczająco szybko by nie powodować niepotrzebnych opóźnień.

Dlatego też radzę wszystkim osobom decyzyjnym, a przecież wszyscy podejmujemy na co dzień – zarówno w pracy jak i w życiu osobistym różne decyzje, by zanim powiedzą ostatnie słowo i przejdą do działania upewnili się, że informacje, które posiadają są względnie kompletne i prawdziwe.

4 komentarze więcej...

5 poziomów wymagań i specyfikacji

opublikowany przez 16, Lip, 2014, w kategoriach Agile, BDD, Scrum, Specyfication By Example, User Stories

Ten wpis jest (powiedzmy, że) kontynuacją wpisu „Wymagania != Specyfikacja

Piramida wymagań

Jeśli mówimy o wymaganiach i specyfikacji i wprowadziliśmy już rozróżnienie tego czym są wymagania i czym jest specyfikacja, oraz że istnieje specyfikacja funkcjonalna oraz specyfikacja techniczna to teraz możemy swobodnie przemyśleć to jak zkategoryzować poszczególne poziomy wymagań i specyfikacji.

Jak w tytule pozwoliłem sobie na wyróżnienie pięciu poziomów wymagań i specyfikacji, które można by przedstawić w postaci na przykład piramidy (Wygląda na to, że ludzie w IT lubią piramidy, nie wiem dlaczego…).

Na szczycie piramidy mamy pierwszy poziom: Jaki jest cel naszego przedsięwzięcia? 

Odpowiadając na pytanie po co nasza organizacja istnieje i po co tworzy produkty najprawdopodobniej dojdziemy do odpowiedzi, że oczywiście robi to dla pieniędzy. Tak, pieniądze i ich zarabianie są celem niemalże każdego biznesu (bezpośrednio lub pośrednio – np. zyski wizerunkowe, które później się monetaryzują). Warto o tym pamiętać bez względu na to gdzie w strukturach organizacji się znajdujemy bez względu na to czy tworzymy produkty dla naszej własnej organizacji czy jesteśmy jedynie dostawcami usług dla klientów/organizacji zewnętrznych. Aby osiągnąć cel (zarabianie pieniędzy) organizacja wytwarza pewne produkty – w IT mamy obecnie do czynienia raczej nie tyle z produktami w sensie wytwarzaniem pewnych dóbr materialnych co tworzeniem produktów będących narzędziami do świadczenia usług. Tworzymy produkty, które świadczą pewne usługi dla użytkowników końcowych za które są oni gotowi zapłacić.

Drugim poziomem jest odpowiedź na pytania: Kto jest interesariuszem naszego produktu i jakie problemy próbuje rozwiazać? 

Kto jest naszym odbiorcą i jest gotów zapłacić za „rozwiązanie” swoich problemów, spełnienie potrzeb? Jakich problemów i potrzeb? Warto pamiętać, że dla interesariuszy celem nadrzędnym też są raczej pieniądze więc myśląc nad produktami powinniśmy brać pod uwagę to w jaki sposób my możemy zarobić na tym, że zarabiają (oszczędzają) nasi klienci?

Mając problemy do rozwiązania i grupę odbiorców docelowych naszych rozwiązań mamy właściwie wysoko-poziomową definicję produktu.

Trzecie poziom to zdefiniowanie tego co będzie robił, czy też jakie funkcjonalności będzie zawierał nasz produkt by rozwiązać powyższe problemy interesariuszy?

Powyższe trzy poziomy to wymagania – co nasz produkt będzie robił by rozwiązać konkretne problemy, konkretnych interesariuszy. Na tym poziomie mamy zdefiniowane na pewnym poziomie abstrakcji ficzery naszego produktu. Możemy przystąpić do badania rynku i sprawdzania naszej hipotezy, że odbiorcy faktycznie potrzebują rozwiązać te problemy i są gotowi za nie zapłacić.

Czwarty poziom to  Specyfikacja Funkcjonalna – czyli odpowiedź na pytania w jaki sposób nasz produkt rozwiązuje problemy interesariuszy, jakie konkretne funkcjonalności dostarcza? 

Tutaj specyfikujemy jakie konkretnie funkcje naszego produktu użytkownicy będą mieli do dyspozycji. Możemy zbadać czy dane funkcjonalności są faktycznie przez użytkowników używane – czy są im potrzebne?

Piąty poziom to Specyfikacja Techniczna – w jaki sposób działają poszczególne funkcjonalności oraz jak są zaimplementowane?

Czwarty i piąty poziom to obszary w których możemy (a nawet powinniśmy) pokusić się o wykonywanie testów A/B i ciągłe usprawnianie dostarczanych przez nas funkcjonalności, tak by jeszcze lepiej spełniały oczekiwania użytkowników.

Na zakończenie jedna ważna uwaga: Nawet jeśli świetnie zdefiniujemy założenia co do wymagań i specyfikacji w naszym produkcie oraz poprawnie to zaimplementujemy to wcale nie znaczy, że nie mogą się one zmienić – to rynek zwaliduje czy mieliśmy rację. Dlatego też tak istotne jest testowanie naszych hipotez oraz wydawanie nowych wersji produktów – eksperymentowanie jak najczęściej, wprowadzając minimalne inkrementalne zmiany.

-==C.D.N==-

5 komentarzy więcej...