niedziela, 24 lutego 2008

Miary

Z miarami jest tak jak w popularnym powiedzeniu. W języku polskim mówi się „proście a będzie wam dane”, po angielsku jest „proście a otrzymacie”. To drugie ma w tym przypadku jeszcze większy sens. Już znany chyba wszystkim W. Edwards Deming kilkadziesiąt lat temu wskazywał, że wszelkiego typu systemy miar stosowane w przedsiębiorstwach i firmach determinują sposób, w jaki pracują pracownicy. „Pokaż mi, co mierzysz a powiem Ci jak pracujesz”. To normalne dla natury ludzkiej, że ucieka od sytuacji kiedy boli a dąży do sytuacji w której jest przyjemnie. Systemy miar stosowane w firmach najczęściej powiązane są z jakimiś reperkusjami, na przykład z wypłatą premii czy choćby łaskawszym (bądź nie) spojrzeniem szefa. Dlatego tak skutecznie determinują sposób w jaki się pracuje. Ludzie nie są głupi i będą próbowali pracować tak, aby dzięki stosowanym miarom mieć jak najwięcej przyjemności.

Po co to piszę? Bo każdy, nawet najlepszy system zarządzania, nawet najlepiej zdefiniowane i wdrożone metody zwinne zarządzania projektami można wypaczyć stosując nieadekwatny i źle dostosowany system miar. Najczęściej zdarza się to, kiedy „dojrzała” organizacja dojdzie do wniosku, że trzeba wdrożyć metody zwinne. Dość szybko okazuje się, że problemem jest to, że dość dużo osób ma problemy z odnalezieniem się w nowej sytuacji. Wszystkie te osoby są z kategorii zawodowej zajmującej się w głównej mierze przeglądaniem różnego typu raportów, papierków, tworzeniem sprawozdań, koordynowaniem działań, zapewnianiem spójności, politykami wewnętrznymi itp. W skrócie: żadna z nich nie przyczynia się bezpośrednio do osiągania wartości dodanej dla klienta. Poprawne wdrożenie metod zwinnych w organizacji oznacza przestawienie wszystkich tych osób na zadania bezpośrednio związane z generowaniem wartości dodanej. Niestety często w przypadku niezbyt udanych wdrożeń zdarza się, że o tych osobach się „zapomina”. Problem zamieciony pod dywan wraca jednak dość szybko. Zaczyna się usilne udowadnianie jak kto bardzo jest potrzebny. W ramach tego udowadniania najprościej jest zażądać tego, co było wcześniej, czyli raportów i sprawozdań. Najczęściej pod szczytnym hasłem potrzeby sprawdzania, czy wszystko jest: zgodne z planem, zgodne z polityką jakości, zgodne z procesami, itp. Z raportów wyciągane są miary. Miary służą potem do oceny pracowników. Pracownicy zaczynają pracować dla zaspokojenia miar. Normalne i zdrowe ludzkie zachowanie. Tyle tylko, że nie ma nic wspólnego z tym, co powinni robić. Przypominam: pracownicy powinni pracować dla zaspokojenia potrzeb klienta.

Przykład z życia wzięty. Pewna firma produkująca oprogramowanie komputerowe wdrożyła zarządzanie zwinne projektami. Zapomniano jednak zaangażować w prace projektowe dział zarządzania jakością firmy i zostawiono go poza strukturą projektów. Szybko okazało się, że dział ten zaczął zgłaszać potrzebę upewnienia się, że w projektach tworzy się tylko i wyłącznie oprogramowanie „wysokiej jakości”. Zdefiniowano więc miary: ilość unikalnych przypadków testowych w projekcie oraz stopień automatyzacji przypadków testowych. Jeden i drugi wskaźnik ustalano na podstawie historii wcześniejszych projektów. Miało to zagwarantować wysoką jakość oprogramowania gdyż: im więcej przypadków testowych tym lepiej przetestowany produkt oraz im więcej z nich jest automatycznych tym mniejsze prawdopodobieństwo popełnienia błędów. Na ten drugi wskaźnik zwracano szczególną uwagę, gdyż zapewniał on także znaczące oszczędności: testy odbywały się automatycznie, więc były „tańsze” niż takie, przy których pracować musieli ludzie. Brzmi logicznie? Powiedzmy. Co się stało? Oczywiście oba wskaźniki były osiągane w każdym projekcie. Przynajmniej na pierwszy rzut oka wszystko było ok. A w szczegółach? Zacznijmy od automatyzacji. Konieczność automatyzacji testów powodowała, że po prostu nie definiowano przypadków testowych, których nie dało się zautomatyzować. Proste? Ano tak. Po drugie ilość testów. Jak najprościej osiągnąć dużą liczbę przypadków testowych? Ano napisać wiele wersji tego samego. Szybko i bezboleśnie można wygenerować dowolnie dużą ilość przypadków. W tym konkretnym przypadku po analizie okazało się, że zdefiniowane przypadki testowe pokrywały (wielokrotnie) średnio niecałe 70% kodu stworzonego oprogramowania. Nietrudno się domyślić, że pozostałe 30% było tymi fragmentami, gdzie trudno było napisać testy automatyczne. Zgadnijcie, gdzie najczęściej ujawniały się błędy w oprogramowaniu tworzonym przez tą firmę? Proście a otrzymacie…

poniedziałek, 4 lutego 2008

Przerwa

Ze względu na nawał pracy ze smutkiem ogłaszam przerwę w pisaniu na blogu. Orientacyjny czas powrotu do regularnego pisania: ostatni tydzień lutego 2008.

Zapraszam serdecznie!!!