Nie pojmiecie sztuki, póki nie zrozumiecie, że w sztuce 1+1 może dać każdą liczbę z wyjątkiem 2. Pablo Picasso

Z psychologicznego punktu widzenia jesteśmy stworzeniami żyjącymi na krawędzi. Na pierwszy rzut oka wydajemy się jednostkami dość stabilnymi i w miarę ugruntowanymi emocjonalnie. Wiemy z grubsza, czego możemy się spodziewać po sobie i innych. Umiemy nawet przewidzieć z dużą dozą prawdopodobieństwa, jak potoczą się niektóre sprawy. Wystarczy jednak unikalna kompozycja specyficznych bodźców, a już zmieniamy się w płonącą kulę ognia albo górę lodową, innym razem znowu w żądną zemsty bestię albo dziecko potrzebujące miłości.

W świecie IT takim bodźcem wywołującym "odmienne stany świadomości" jest pytanie o metryki w produkcji oprogramowania. Menedżerowie zaczynają zachowywać się wtedy dziwnie. Kiwają ze zrozumieniem głowami, przyznają, że coś właśnie słyszeli, że to ważne i przydatne, zapewnia lepszą kontrolę i zmniejsza ryzyko. W IT, tak jak w wielu innych branżach, pomiary procesów i produktów są czymś tak naturalnym i oczywistym, że pytanie o to, czy i jakie metody pomiaru są stosowane, jest nie tylko nie na miejscu, ale wręcz obraźliwe. Tak. Oczywiście, stosujemy i jesteśmy dumni z naszych osiągnięć. Miary? Nie, nie stosujemy żadnych miar.

Słyszałem to dziesiątki razy w różnych projektach i organizacjach. Czasem rzeczywiście coś istniało, ale częściej przypominało dziki gąszcz tabelek i wykresów niż użyteczny system miar przydatnych w zarządzaniu projektem. Taka jest rzeczywistość. Miary zbiera się chętnie, systemowo i holistycznie, bo oczekiwania są ogromne. Chcemy wiedzieć, co się dzieje w procesach, próbując dać odpowiedź na wszystkie pytania i to z dokładnością do czwartego miejsca po przecinku. Ale czy to ma sens? Można przypuszczać, że taki sposób zarządzania miarami wcale nie spełni oczekiwań i wcześniej czy później zostanie zarzucony jako nieefektywny i nie gwarantujący zwrotu nakładów poniesionych na jego uruchomienie.

Jak zracjonalizować nasze poszukiwania? Oto kilka wskazówek.

a) Generalną zasadą tworzenia miar jest podejście GQM, czyli Goal-Question-Metric, opracowane przez Victora Basili z Uniwersytetu Maryland. Zakłada ono, że miary służą do wsparcia realizacji celów postawionych przez kierownictwo firmy lub projektu. Czy osiągnęliśmy cel, czy zrobiliśmy to efektywnie, czy można było lepiej, kiedy skończymy, jakie jest ryzyko zakończenia w terminie? To pytania, które zadaje sobie każdy kierownik odpowiadający za realizację celów. Może oczywiście odpowiadać na nie "z głowy". Może także starać się zobiektywizować odpowiedzi wg obiektywnych miar. W ten sposób powstaje racjonalny ciąg myślowy menedżera: jaki mam cel - co muszę wiedzieć, by doprowadzić do jego osiągnięcia - jak zobiektywizować moją wiedzę, czyli jakich miar potrzebuję. Podejście to skutecznie ogranicza liczbę miar tylko do tych, które są niezbędne z punktu widzenia zamierzonego celu. Alternatywne sposoby polegające na zbieraniu wszelkich możliwych miar o procesie w nadziei na wyciągnięcie z dużej liczby informacji przydatnych wniosków w praktyce nie działają i frustrują zespół.

b) Miara składa się z kilku elementów: celu, obiektu, procesu pomiaru i skali. Zbagatelizowanie któregoś z nich zawsze prowadzi do klęski. O celu była mowa w poprzednim punkcie. Zaczniemy więc od obiektu. Jest to "coś" wybranego z otaczającej nas rzeczywistości podlegające procesowi pomiarowemu. Mogą to być: wyrób materialny lub wytwór niematerialny, proces, usługa itp. Nie można mierzyć czegoś, co nie istnieje, np. skuteczności systemu jakości projektu, jeśli go w projekcie w ogóle nie ma! Proces pomiarowy to metoda przypisywania atrybutom mierzonego obiektu wartości z przyjętej skali pomiarowej. Nie wystarczy powiedzieć, że chcemy np. znać pracochłonność prac projektowych. Trzeba podać jeszcze metodę jej pomiaru. Pracochłonność można przecież mierzyć np. jako liczbę "czystych" dniówek lub np. dniówki z nadgodzinami i czasem przeznaczonym na szkolenia. Gołym okiem widać, że ta sama jednostka "osobodzień" w obu przypadkach znaczy coś zupełnie innego. Jest to wynikiem różnych metod pomiaru.

c) Nie ma jednej uniwersalnej miary produkcji oprogramowania, tak jak nie ma uniwersalnej miary pozwalającej oceniać i przewidywać działalność organizacji. Liczba błędów, punkty funkcyjne, czas trwania projektu, pracochłonność itd. są miarami dotyczącymi różnych aspektów procesu wytwórczego i odpowiadają na różne pytania. Nie ma jednej miary, która odpowie na wszystkie pytania jednocześnie. Potrzebujemy zatem systemu miar, a nie jednej pojedynczej i zagregowanej wielkości mierzalnej.

d) Przed wdrożeniem miar trzeba dobrze zrozumieć, co oznaczają one w praktyce. Na przykład popularna miara pracochłonności - osobomiesiąc - jest zmienną zależną od wielu innych zmiennych, takich jak złożoność projektu, technologia, narzędzia i umiejętności. Pracochłonność jako zmienna zależna nie może być więc traktowana w sposób "bezwzględny i bezkrytyczny". Można ją szacować i posługiwać się nią w zarządzaniu projektem, pamiętając jednak, że ze swojej istoty rzeczywistość oddaje jedynie w przybliżeniu. Nigdy nie będziemy mieć miar "idealnych", bo w zarządzaniu takie nie istnieją.

e) Ostatnia zasada to stosowanie zdrowego rozsądku i ciągła weryfikacja danych. Wadliwy proces pomiarowy, różne skale, nieaktualność danych mogą spowodować w projekcie niewyobrażalny chaos. Trzeba być bardzo czujnym, bo niewłaściwe i nierozważne korzystanie z dobrodziejstw systemu miar produkcyjnych będzie jak przysłowiowe zapałki w ręku dziecka.

Kluczem do sukcesu w omawianym obszarze uwewnętrznienia prawdy, która brzmi jak truizm, jest to, że potrzebujemy miar do lepszego zarządzania procesem wytwórczym oprogramowania. System miar nie może być celem samym dla siebie. Tylko takie podejście może wyzwolić nas od wszelkiego dogmatyzmu i przenieść ze sfery "społecznictwa i działania" do efektywnego zarządzania.

Tomasz Byzia jest dyrektorem ds. rozwoju firmy Premium Technology.