Bez eksperymentowania

Poświęcamy dużo czasu na wdrażanie nowych metod, narzędzi i sposobów zarządzania, ale robimy to na oślep. Należy sięgnąć po metody szacowania opłacalności i skuteczności działań.

Przed wojenną wyprawą, nad ogniskiem, w tipi wodza zebrało się ich trzech. Wódz, najmłodszy ze wszystkich, zamierzał przedsięwziąć wyprawę przeciwko sąsiedniemu plemieniu, ale tak ważnej decyzji nie chciał, nie mógł podjąć sam. Może wyprawa się nie powiedzie? Może wystąpią nieoczekiwane przeszkody? Jakie mogą być ich skutki? Z tymi pytaniami zwrócił się do młodszego z szamanów. Starszy szaman milczał, jego wyblakłe, jasnoszare oczy patrzyły w przyszłość. Myślał nie tylko o tej wyprawie, ale i o wielu następnych: co zrobić, aby decyzje o ich podjęciu lub zaniechaniu on i jego następcy podejmowali coraz lepiej, coraz bardziej bezbłędnie?

Takiej narady Indian sprzed dwustu-trzystu lat raczej nie zobaczymy dzisiaj. Wódz - kierownik projektu - rzadko rozmawia ze specjalistą od zarządzania ryzykiem (młodszy szaman), a prawie nigdy - ze specjalistą od udoskonalania procesów i procedur (starszy szaman). A szkoda, bo mogliby się sobie nawzajem przydać.

Skąd wiadomo, czy to prawda?

W nauce o zarządzaniu, o zapewnieniu jakości, a nawet w pewnych obszarach inżynierii oprogramowania nietrudno spotkać tezy i teorie wątpliwe - modne bzdury. Nie zawsze to, co modne jest bzdurą, a to, co niemodne - mądrością, ale brakuje metod pozwalających szybko i skutecznie odróżnić jedno od drugiego.

O tym, że jakaś metoda staje się modna i panuje o niej przekonanie, że naprawdę sprawdza się w praktyce, decyduje wiele czynników, nie mających nic wspólnego z jej rzeczywistą wartością. Pomińmy mechanizmy, których opis należy do psychologii, dynamiki grupowej, socjologii, antropologii czy mechanizmów międzyludzkiej komunikacji. Jeśli chcemy zmniejszyć ich wpływ, trzeba dać inne, lepsze metody w zamian. I z tym mamy kłopot.

Kiedyś, w czasie młodzieńczego wakacyjnego wyjazdu, moja namiotowa partnerka wdała się przy kolacji w spór z moim kolegą na temat wyższości języków strukturalnych nad COBOL-em. Po dwóch godzinach strasznej pyskówki wspólny wyjazd stanął pod znakiem zapytania. Minęło niemal 30 lat i oto kilka tygodni temu byłem świadkiem równie zażartej dyskusji o wyższości Mac nad Windows i odwrotnie. Gdzie indziej jeszcze toczą się zajadłe i bezproduktywne dyskusje o wyższości agile nad metodami tradycyjnymi, PRINCE-2 nad PMI, IREB nad REQB, UML nad XML. Czyżby trzeba było uznać, że prawda jest wyłącznie subiektywna i nie da się niczego rozstrzygnąć w żadnej kwestii, w tym w sprawie skutecznych i nieskutecznych metod produkcji oprogramowania?

Nie jest tak źle, choć w chwilach pesymizmu, kiedy wygadani zwolennicy jakiejś modnej bzdury zawzięcie ujadają na prestiżowych konferencjach, można się tego obawiać. Nie twierdzę, że mając dobrze udowodnioną wiedzę o tym, co działa, co jest skuteczne, przekonamy innych. Nie, ludzkie zapotrzebowanie na wiarę w modne bzdury jest niewyczerpane. Ale i tak tę wiedzę możemy dobrze wykorzystać w praktyce projektowej, w organizacjach, w działalności biznesowej.

Czy łysi są mądrzejsi od kudłatych?

Jak można odpowiedzieć na to pytanie? Kusi tzw. "logiczna" (czytaj: nielogiczna) dyskusja, odwoływanie się do anegdotycznych przykładów i fałszywych analogii. Zainteresowanym polecam lekturę "Krótkiego kursu samoobrony intelektualnej" Normanda Baillargeona. Mając choć odrobinę intelektualnej uczciwości, należy przeprowadzić badanie spełniające wymogi naukowe. Wybiera się połowę osób łysych, połowę kudłatych, mierzy im iloraz inteligencji oraz poziom wiedzy i teza o wielkiej przewadze łysych udowodniona. Jakim cudem? Drobne fałszerstwo: łysych wybieraliśmy spomiędzy pracowników wyższej uczelni, a kudłatych spośród bezrobotnych w PGR na odludziu. Nie, nie, nie: żeby wynik badania był miarodajny, grupy muszą być choć trochę równoważne.

Ta zasada nigdy nie jest przestrzegana, kiedy porównuje się ze sobą różne metody, języki programowania, technologie, narzędzia, sposoby modelowania, podejścia do zarządzania, struktury organizacyjne, procedury. Czy razi kogoś uzasadnienie typu: "ta metoda jest lepsza, przecież projekt zakończył się sukcesem". Albo inne: "musimy stosować tę technologię, używają jej wszyscy". Najczęściej antagonistów próbuje się powalić erystyką, czyli sztuką prowadzenia sporów: "Każdy rozumie, że przecież… ludzka kreatywność… projektowanie obiektowe… TQM… proaktywnie… BDD… bla bla".

Zamiast gołosłownych twierdzeń należy zrobić… co? Porównać ze sobą dwa, a najlepiej więcej projektów równoważnych pod każdym względem, różniących się tylko metodą, której skuteczność chce się zbadać. Tylko to jest nierealne z powodów finansowych. Żeby sobie na to pozwolić, trzeba znaleźć ekscentrycznego miliardera-przedsiębiorcę, tak jak bohater książki Toma DeMarco "Zdążyć przed terminem".

Nadzieja jest w matematyce

Wyobraź sobie, Czytelniku, że Twój dział personalny zawiódł haniebnie i zatrudnił człowieka, który zamiast dostosować się do kultury Twojej organizacji i zaangażować z całego serca w walkę o wpływy, robienie dobrego wrażenia i podgryzanie rywali, jest autentycznie zainteresowany usprawnieniem procesów, aby osiągnąć biznesowe korzyści! Mówi, że inwestycja w lepsze praktyki inżynierii wymagań zwróci się w krótkim czasie, ba - przyniesie znaczne zyski. Twój CIO stuka się w głowę, Twój CFO mówi, że nie da się uzyskać potrzebnych danych finansowych, a Twój CMO trzyma się za serce i jęczy coś na temat CRM, CEM, BPML. Tego nowego to trzeba jak najszybciej zwolnić dyscyplinarnie… niestety, jeden z ważnych członków zarządu, znajdujący się na liście 100 najbogatszych Polaków, dał się zbajerować i mówi, żeby dać młodemu spróbować.

Młody wziął się do pracy. Najpierw zbudował sieć bayesowską pokazującą, od czego i w jakim stopniu zależy stopa zysku firmy. Taka sieć mogła wyglądać następująco:

Na rysunku 1 (tak, to jest graf - diagram sieci bayesowskiej) interesujący wynik - STOPA ZYSKU - przedstawiony jest jako zależny (strzałki pokazują tę zależność) od szeregu czynników. Czynniki przedstawione na niebiesko - marketing, logistyka itd. - te nas nie interesują (co nie znaczy, że są nieważne, tylko w tym momencie nie ich udoskonalaniem się zajmujemy).

Poza tym stopa zysku zależy od KOSZTÓW UZYSKANIA oraz KOSZTÓW UTRZYMANIA produktu (np. produktu IT). Te zaś zależą od CZYNNIKÓW JAKOŚCI - to zielone pola na rysunku, wśród nich zarządzanie, inżynieria wymagań i inne.

Strzałki-zależności mają swój atrybut, swego rodzaju siłę zależności mówiącą, jak mocno dany czynnik wpływa na końcowy efekt. Suma wszystkich zależności powinna wynosić 100%, w przeciwnym razie oznacza to, że jakiś ważny czynnik został pominięty.

Skąd możemy wiedzieć, jaka jest siła tych zależności? Jak bardzo jakość inżynierii wymagań wpływa na koszty utrzymania i wytworzenia? Czy to 5%, czy raczej 40%? To można próbować oszacować, na pewnym poziomie pewności, na podstawie: 1. opinii eksperckich, 2. danych historycznych z kolejnych projektów oraz - najlepsze oszacowanie - na podstawie 3. danych z całej branży.

Przyjmując, że dane są prawdziwe, możemy dokonywać na papierze eksperymentów: jeśli usprawnimy inżynierię wymagań o 50%, to o ile zmaleją koszty produktu, o ile wzrośnie zysk? Ponieważ nie wiemy, na ile proponowane przez młodego pracownika zmiany zaowocują mniejszą liczbą błędów w wymaganiach ani jakie będą koszty ich wdrożenia, ani jak silna jest zależność między jakością inżynierii wymagań a kosztami produktu, ani nawet tego, na ile koszty produktu wpływają na zyski - to co mamy robić?

Sądząc z poziomu płac w Polsce, górny kwartyl wynagrodzenia dla kierowników marketingu to 11 tys. zł, a dla kierowników działu IT - 12 tys. Odpowiednio, 25% dyrektorów działu IT zarabia ponad 23 tys. zł - tyle, ile 25% dyrektorów działu marketingu. Czyli rynek szacuje - przez pensje - znaczenie tych działów jako podobne. Niemniej znaczny poziom niepewności pozostaje i wyliczenia algorytmiczne na podstawie niepewnych danych nie mają sensu.

Z pomocą przychodzi metoda Monte Carlo. Jedna z jej definicji brzmi: "metoda Monte Carlo jest stosowana do modelowania matematycznego procesów zbyt złożonych, aby można było przewidzieć ich wyniki za pomocą podejścia analitycznego. Istotną rolę odgrywa w niej losowanie wielkości charakteryzujących proces".

Procesy zbyt złożone - to dotyczy procesów wytwarzania oprogramowania. Nie da się wziąć pod uwagę wszystkich czynników wywierających wpływ na ich koszty i na ich skuteczność. Można zanalizować rozkład wyników dla danych generowanych losowo. Ręcznie byłoby to beznadziejne zadanie, ale od czego mamy komputery. Wrzuciwszy diagram sieci Bayesa do odpowiedniego narzędzia, możemy na nim wykonywać eksperymenty za pomocą wartości losowo wygenerowanych wokół oczekiwanej średniej. Wsparcie narzędziowe metody Monte Carlo da nam każdy język programowania, a nawet każdy arkusz kalkulacyjny.

I co dalej?

Co dalej i kogo w czasach kryzysu stać na takie eksperymenty? Przewidując to pytanie, z wielką obawą powołuję się na opracowanie z 2009 r., opublikowane przez SEI (Software Engineering Institute), dotyczące zastosowania tej metody w dziale badawczo-rozwojowym firmy Ericsson w Holandii:http://repository.cmu.edu/cgi/viewcontent.cgi?article=1273&context=sei. To nie jest dobra rekomendacja dla prezesa kilkudziesięcioosobowej firmy informatycznej…

A jednak. Przypomnijmy sobie anegdotę o drwalu, co marnie rąbał drzewa, bo tak był zajęty, że nie miał czasu naostrzyć siekiery, czy o budowlańcu, co biegał z pustymi taczkami, bo nie miał czasu ich naładować. I tak na co dzień poświęcamy dużo czasu na projektowanie i realizację zmian procedur i procesów, na wdrażanie nowych metod i narzędzi, nowych sposobów zarządzania, tyle że robimy to na oślep, kierując się jakże zawodną intuicją i nie prowadząc żadnych późniejszych oszacowań opłacalności ani skuteczności tych eksperymentów. W ten sposób mnóstwo pieniędzy się marnuje, wręcz wyrzuca w błoto - choć część ich można przeznaczyć na zastosowanie opisanych w tym artykule metod, które są najzwyczajniej praktyczne, konkretne i opłacalne. A kryzys to najlepszy czas na takie sprawy! (http://gazeta.testerzy.org.pl/nr/2013-02-17/kryzys.html).

Poza tym można spróbować przełamać stereotypy i uprzedzenia i poszukać współpracy z uczelniami. Przykłady, że taka współpraca jest obustronnie korzystna i pozwala nawet niewielkim firmom niskim kosztem osiągnąć udoskonalenia będą omawiane na spotkaniu "Praktyczne doświadczenia współpracy między IT a wyższymi uczelniami w szwedzkim i polskim przemyśle IT", 18 kwietnia br., podczas konferencji "Dobre wymagania" (http://breq2013.wymagania.org.pl/program/panel.html). Warto się przyjrzeć doświadczeniom z tej dziedziny.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200