“Produkt testowany dermatologicznie”

Na etykietach niektórych produktów możemy znaleźć różne hasła mające nas zapewnić o ich jakości. Jeżeli chodzi o kosmetyki, bardzo popularnym stwierdzeniem jest “produkt testowany dermatologicznie”. Brzmi dobrze, do momentu aż nie uświadomimy sobie, że przecież nic nie wiemy o wynikach tych testów.

 

Produkt testowany czy przetestowany?

Oczywiście stwierdzenie “produkt testowany dermatologicznie” zwykle nie jest tylko pustym hasłem. Zakładamy, że skoro dany kosmetyk został przetestowany, to spełnił jakieś standardy i nie wywołał żadnych szkodliwych reakcji. Gdyby tak się jednak stało, to co prawda też mógłby być określony jako “testowany”, ale ufamy, że nie zostałby dopuszczony do użytku.

Gwarancją w tym przypadku wcale nie są więc wspomniane testy, ale nasze zaufanie do marki. Wierzymy, że firma, która używa takiego stwierdzenia nie wypuściłaby na rynek czegoś, co by nam zaszkodziło. Sam wynik testów nie ma dla nas absolutnie żadnego znaczenia.

Bo i trudno się przecież spodziewać, że ktokolwiek kiedykolwiek użyłby porażki czy negatywnego scenariusza do reklamowania swojego produktu. Z drugiej strony, jesteśmy bez problemu w stanie sobie wyobrazić testy, których wyniki są kompletnie ignorowane.

Tylko co to ma wszystko wspólnego z byciem zwinnym i agilem?

 

Co mierzymy?

W naszej pracy często analizujemy jak przebiega nasz proces i skrupulatnie notujemy poziom niektórych wskaźników. Mierzymy np. velocity poszczególnych zespołów, lead time (czy Time To Market), czas poświęcony na poszczególne etapy pracy i wiele innych.

Niestety, czasami przypomina to właśnie pusty slogan pod tytułem “produkt testowany dermatologicznie”, bo wyniki naszych pomiarów trafiają tylko i wyłącznie do jakiegoś pliku excelowego i tam dokonują żywota. Nikt się nimi nie interesuje, nikt ich nie analizuje, ani nie mają one na nic wpływu. Sam fakt ich zbierania jest ważniejszy, niż jakakolwiek analiza bądź korzyść, która mogłaby z nich płynąć.

Najbardziej typowym przykładem takiego bezsensownego zbierania danych są wszystkiego rodzaju timesheety. Firmy wymagają od osób raportowania czasu pracy poświęconego na różne zadania, chociaż dobrze wiemy, że wpisywane tam godziny mało mają wspólnego z rzeczywistością.

Ale wcale nie to jest najgorsze. W większości przypadków zebrane dane nie są używane absolutnie do niczego.

Ktoś może krzyknąć, że jest to potrzebne do budżetowania bądź wyceniania projektu. Niestety, przeczy temu fakt, że nawet osoby oddelegowane na projekt w stu procentach nadal muszą te timesheety wypełniać. I to często w dużym stopniu szczegółowości. Wpisanie, że w danym miesiącu 160 godzin poświęciło się na “pracę projektową” o dziwo nie wystarcza.

I tak, jak mierzenie i obliczanie niektórych wskaźników wydaje się być stratą czasu, tak robienie tego ze świadomością, że nikt się nawet naszymi wyliczeniami nie zainteresuje jest po prostu torturą.

 

Po co mierzymy?

Zawsze, w każdej sytuacji w której poświęcamy nasz czas i wysiłek na mierzenie jakiejś wartości czy obliczanie jakiegoś wskaźnika, musimy zadać sobie pytania “Po co i dla kogo to robimy?”.

W pierwszej kolejności zastanówmy się, czy sami mamy w ogóle jakąś korzyść z tych informacji. Są takie miary, które są przez nas używane wprost, jak np. velocity naszego zespołu. Wykorzystujemy je między innymi na Planowaniu Sprintu, a Product Owner używa go do prognozowania i planowania prac w dłuższym terminie.

Czasami jednak te zbierane dane będą przypominały “test dermatologiczny” – nikogo nie interesuje rezultat ani wynik, ale sam fakt zbierania danych. Dzięki temu możemy się np. pochwalić, że “śledzimy wykorzystywanie zasobów na projekcie”. Tylko co to tak naprawdę wnosi w nasze codzienne życie?

Wykorzystanie danych z raportów i analiz do “prezentacji dla zarządu” to na pewno nie jest wartościowe zastosowanie. Zwłaszcza, że na podstawie tych prezentacji często i tak nie są podejmowane żadne decyzje. Ot, sztuka dla sztuki.

 

Dla kogo mierzymy?

Jeżeli podejrzewamy, że nasze wyliczenia nie mają realnych odbiorców – spróbujmy zaniechać tych działań i sprawdźmy, czy ktoś w ogóle się o nie upomni. Jeżeli już w ten sposób zidentyfikujemy interesariusza, spróbujmy uzyskać od niego informację, do czego używa opracowywanych przez nas liczb.

Bardzo często okazuje się, że dane są przetwarzane i gromadzone “na wszelki wypadek”. Mówiąc wprost, jest to marnowanie naszego czasu na rzeczy zbędne. W takim przypadku jak najbardziej zachęcam do rozpętania dyskusji na temat tej bezsensownie wykonywanej pracy.

Czasami jest też tak, że pomiary dokonywane są z powodów, które co prawda są istotne, ale które w żaden sposób nie dotykają naszego zespołu. Wtedy przede wszystkim musimy się zastanowić czy osoby, którym na tym zależy nie mogą zająć się tym same, bez naszego udziału. A jeżeli nie, to przynajmniej powinniśmy wszystkim wytłumaczyć cel.

Zawsze lepiej wiedzieć po co coś robimy, bo pozwala nam to na kreatywne rozwiązanie problemu, zamiast ślepego wykonywania poleceń. Ale ten temat poruszałem już w tekście “wymagania, a nie zadania” i tam możemy znaleźć też pomysły na uratowanie sytuacji.

Mówiąc krótko – być może jesteśmy w stanie zaspokoić potrzeby odbiorcy tych danych w zupełnie inny sposób, który nie będzie dla nas uciążliwy. Ale to się uda tylko i wyłącznie wtedy, gdy poznamy potrzeby tej osoby.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: