Jak mierzyć efektywność IT?

Efektywność – to takie ładne słowo… Wszyscy chcieliby, żeby praca – zarówno ich osobista praca, jak i działanie całej firmy czy organizacji – była efektywna. Wysoka efektywność z reguły związana jest z sprawnym działaniem, brakiem marnowania czasu na niepotrzebne aktywności, skupieniem się na tym co najważniejsze, dostarczaniem właściwych rezultatów czy produktów, wysoką motywacją do pracy, oraz – last but not least – dochodowością przedsiębiorstwa.

To wszystko brzmi pięknie – natomiast kiedy próbujemy odpowiedzieć na pytanie, czy praca naszych działów czy zespołów wytwarzających oprogramowanie jest efektywna, to z reguły pojawia się problem. A jeszcze większy problem pojawia się w momencie, kiedy chcemy tą efektywność jakoś zmierzyć…

 

Po co nam mierzenie efektywności?

Zanim przejdziemy do samego mierzenia, dobrze jest zastanowić się przez chwilę po co jest nam potrzebna miara naszej efektywności. Jaka jest nasza motywacja do tego, aby inwestować w to mierzenie – bo tak naprawdę podwody mierzenia efektywności mogą być bardzo różne.

Być może chcemy mierzyć efektywność, po to, aby pochwalić się w jakimiś ładnymi liczbami czy wskaźnikami w jakimś raporcie. W tym przypadku nie trzeba się mocno zastanawiać nad wyborem metody mierzenia – bierzemy po prostu taką metodę, która da nam najlepsze wyniki. I cieszymy się tym wynikami do czasu, aż ktoś nie zacznie drążyć, co tak naprawdę się za tymi wskaźnikami kryje…

Być może mamy kilka osób czy zespołów, które pracują razem i chcemy porównać ich efektywność ze sobą – po to, aby nagrodzić najlepszych i dać sygnał „hej, powinniście się poprawić” tym gorszym. W tym przypadku musimy być szczególnie ostrożni z wyborem metody pomiaru. Informatycy (wbrew pozorom) nie są głupi i wybranie złej metody oceniania będzie miało dwie konsekwencje. Po pierwsze spowoduje efekt odwrotny do zamierzonego, czyli demotywację pracowników: „po co mam się starać w pracy, skoro jestem oceniany przez tak idiotyczne kryteria?”. A po drugie, bardzo szybko pracownicy nauczą się tak organizować swoją pracę tak, aby raportować wysokie wskaźniki efektywności, nawet jeżeli ich praca nie będzie efektywna…

I jest jeszcze jedna motywacja – w moim odczuciu najbardziej sensowna. W wielu firmach podejmowane są różnorakie wysiłki mające na celu zwiększenie efektywności pracy. Wprowadzanie tych zmian zawsze wiąże się z jakimiś kosztami – albo są to koszty bezpośrednie, albo pośrednie, kiedy to musimy zmienić nasze przyzwyczajenia, wprowadzić jakieś nowe narzędzie, przekonać się do niego… I tak naprawdę czasami trudno jest stwierdzić, czy wprowadzenie danej zmiany przyniosło więcej kosztu czy pożytku. Ba, często różne osoby mają różne zdania na temat tej samej zmiany: „wprowadzenie wiki pomogło nam aktualizować na bieżąco naszą dokumentację” vs. „wprowadzenie wiki sprawiło, że mamy dodatkową robę z utrzymywaniem tego narzędzia”. Dlatego też dobrze byłoby w mierzyć, czy po wprowadzeniu zmiany efektywność pracy faktycznie nam wzrosła. Czy faktycznie jest lepiej – bo może też być tak, że koszty zmiany przeważają nad zyskami z jej wprowadzenia.

 

Problem z licznikiem równania

Jeżeli mamy coś mierzyć, to najlepiej jest zacząć od określenia definicji wartości mierzonej… Proponuję wziąć najprostszą definicję efektywności, która mówi, że efektywność można określić jako stosunek uzyskanych efektów (na przykład wytworzonych produktów) do poniesionych nakładów (najczęściej włożonej pracy lub kapitału). Im więcej wytwarzamy – tym efektywność jest większa. Im większy jest koszt wytwarzania – tym efektywność mniejsza. Banalne, nieprawdaż?

Mając takie równanie, z reguły w projektach IT nie mamy większych problemów z określeniem jego mianownika. Koszt wytworzenia oprogramowania możemy bardzo łatwo zmierzyć w poniesionych wydatkach (np. koszt sprzętu) oraz w czasie pracy, który również możemy przeliczyć pieniądze. Problem natomiast pojawia się w mierzeniu efektu pracy – jaka jest „wartość” czy „ilość” stworzonego przez nas oprogramowania. Jak ją zmierzyć? I tutaj właśnie zaczynają się schody…

 

Próbujemy coś zmierzyć od strony klienta…

Pierwszym pomysłem jest określenie wartości oprogramowania z perspektywy klienta. Czyli próba odpowiedzi na pytanie: co nowy system (albo zmiana w istniejącym systemie) daje klientowi? Na ile klient wycenia taką zmianę?

I tutaj trafiamy na pierwszy problem: wartość oprogramowania dla klienta jest czasami zupełnie niewspółmierna do nakładów koniecznych do wytworzenia tego oprogramowania! Może być tak, że to, co klient zamawia, można mieć „prawie za darmo” – możemy to wykonać używając gotowego i darmowego systemu lub składając razem kilka dostępnych komponentów. Tak może być na przykład przy tworzeniu prostych serwisów internetowych – jeżeli klient chce założyć sobie bloga firmowego, to można taki serwis stworzyć w ciągu pół godziny. Ale może też być tak, że klient wymaga implementacji specyficznych funkcjonalności w specyficznej technologii (np. wymaga zmiany w systemie, który jest napisany specjalnie dla niego) i tutaj koszt zmiany jest duży. Może być też tak, że stosunkowo prosta zmiana wymaga upgrade’u lub wymiany całego systemu, z którego korzysta klient – a wtedy koszt jest ogromny…

Co więcej, nawet w ramach zmian w obrębie jednego systemu, niektóre zmiany mogą być wprowadzone względnie łatwo (bo jest to np. zmiana parametryzacji), natomiast inne zmiany wymagają głębokiej przebudowy tego systemu. Czasami rodzi to sporą konfuzję po stronie klienta – skoro zmiana A kosztuje mnie 1 jednostkę czasu/pieniędzy, to dlaczego porównywalna funkcjonalnie zmiana B ma mnie kosztować 100 takich jednostek?

 

Kod posiada linie

Skoro nie udało nam się wyprowadzić jednostki wartości oprogramowania od strony klienta, to może zmieńmy punkt widzenia i spróbujmy spojrzeć na problem od strony technologicznej?

Metodą pomiaru ilości pracy, która była kiedyś popularna i czasami jeszcze powraca w różnych kontekstach, jest liczenie linii kodu tworzonych przez programistę. Pomysł na pozór wydaje się bardzo kuszący – ilość linii kodu jest to metryka bardzo prosta do pomiaru, intuicyjna, zrozumiała (nawet dla menedżerów…) oraz w pewien związana z dostarczanymi funkcjonalnościami. Nic, tylko wziąć i stosować.

Tyle, że tak naprawdę średnio zdolny programista jest w stanie wyprodukować dowolną ilość linii kodu w ciągu dnia i, co więcej, wytworzony w ten sposób kod przy pierwszej konieczności jego zmiany, będzie nadawał się tylko i wyłącznie do wyrzucenia i napisania na nowo… Często też praca najzdolniejszych programistów polega na refaktoryzacji kodu, w wyniku czego otrzymujemy… ujemną liczbę stworzonych linii kodu. Nie rozwijając tego tematu – ocenie efektywności pracy programisty poprzez ilość napisanych linii kodu mówimy nasze stanowcze i zdecydowanie „nie”. A więcej o różnych aspektach pomiarów linii kodu można przeczytać na przykład tutaj: „It’s Not About Lines of Code”.

 

Takie różne pointy…

Jeżeli nie linie kodu są miarą wartości oprogramowania, to co? Dawno, dawno temu, bo już w 1979 pojawiła się koncepcja obliczania punktów funkcyjnych (Function Point Analysis – FPA), czyli liczenia wartości, która ma wyrażać złożoność oraz wartość oprogramowania. Koncepcja jest ciekawa, pojawiają się w niej definicje, wzory, algorytmy i wszystko wygląda bardzo mądrze i naukowo… Tylko że, tak jak podobno ta metoda jest popularna w USA, tak w Polsce nie spotkałem się z żadnym projektem, który by tę metodę stosował. Wpadamy tutaj trochę w błędne koło: nie stosujemy punktów funkcyjnych, bo nie widzimy z tego korzyści; nie widzimy korzyści z punktów funkcyjnych, bo ich nie stosujemy. Więcej o punktach funkcyjnych można przeczytać np. w pracy Ewy Magiery. A jeżeli ktoś próbował kiedyś stosować punkty funkcyjne w jakimś praktycznym projekcie – będę wdzięczny za kontakt i podzielenie się doświadczeniami…

Koncepcją z pozoru troszkę podobną do punktów funkcyjnych są story points stosowane w metodykach lekkich, np. w Scrumie. Podobieństwo polega na tym, że zarówno punkty funkcyjne, jak i story points, są to wartości bezwymiarowe, to znaczy nie mające bezpośredniego przełożenia na czas czy koszt wytworzenia oprogramowania. Ale zupełnie inna jest filozofia wyznaczania tych wartości. Za punktami funkcyjnymi stoją pomiary i wyliczenia – czyli podejście inżynierskie: „Zmierzmy w naszym systemie wejścia, wyjścia, pliki, interfejsy i inne cuda, a potem wyliczmy z tego złożoność oprogramowania używając do tego bardzo skomplikowanych wzorów”. Koncepcja wyznaczania story points wychodzi z diametralnie innego założenia i mówi tak: „Te wszystkie pomiary są bardzo pracochłonne i żmudne, a ich wynik jest nie zawsze pewny. Dlatego też dajmy sobie spokój z tym mierzeniem, zrezygnujemy z pięknych teorii, które w praktyce nie działają i bazujmy na doświadczeniu naszego zespołu, który już pewne zmiany wykonał i potrafi szacować, ile następne zmiany zajmą nam czasu”.

Story points sprawdzają się bardzo dobrze w projektach prowadzonych za pomocą metodyk lekkich i pozwalają na branie do iteracji odpowiedniej ilości zadań oraz pozwalają na oszacowanie, ile iteracji pozostało nam do końca projektu. Ale nie są one wskaźnikiem, który pozwala na porównywanie między sobą zespołów, które pracują nad różnymi systemami i w różnych technologiach, ani też nie wskażą nam efektywności całej organizacji.

 

A może nie mierzyć wcale?

I w tym momencie wiele osób mówi tak: story points u nas nie zadziałają, bo nie jesteśmy Scrumowi. Nie chcemy albo nie mamy czasu na eksperymenty z punktami funkcyjnymi. Żadnych innych sensownych miar też nie udało nam się skonstruować. No to trudno, zróbmy inaczej. Zrezygnujmy z mierzenia efektywności całej organizacji – zamiast tego uwierzmy w to, że nasze subiektywne poczucie „na ile jest dobrze” jest prawdziwe. Starajmy się poprawić efektywność tam, gdzie widzimy problemy. Natomiast jeżeli chodzi o ocenę efektywności pracy poszczególnych osób – niech zajmą się tym ich bezpośredni przełożeni. Kierownik przydziela swoim pracownikom zadania, niech zatem również ocenia, czy pracownik wykonuje te zadania efektywnie.

Takie podejście jest stosowane w wielu firmach – ale zauważmy, że takie rozwiązanie wymaga, aby kierownik zespołu posiadał co najmniej taki sam poziom wiedzy i umiejętności technicznych co jego podwładni. A nie zawsze tak jest – często bywa tak, że kierownik zespołu zarządza zadaniami, współpracuje z klientem, sporządza różne raporty i robi milion innych rzeczy, które sprawiają, że nie nadąża w rozwoju technicznym za swoimi podwładnymi. Dotykamy tutaj skomplikowanej kwestii roli kierownika w zespole IT – bo bardzo często oczekuje się, że ma być to osoba, która będzie super-programistą, znawcą wszystkich niuansów systemu, wyrocznią architektoniczną, a jednocześnie będzie to osoba zapewniająca skuteczną komunikację, prezentująca wizje, pracująca nad motywacją zespołu, zapewniająca coaching pracowników, zarządzająca konfliktami, oceniająca wyniki pracy, dbająca o rozwój zespołu i robiąca masę innych rzeczy. W pewnym momencie trzeba podjąć decyzję – czy kierownik zespołu ma bardziej rozwijać się w kierunku technicznym (jest wtedy super programistą i ocena efektywności pracy podwładnych jest dla niego o tyle prosta, że robi na co dzień to samo), czy też może ma się rozwijać bardziej w kierunku zarządzania (wtedy prowadzi zespół, ale niekonieczne może być w stanie ocenić efektywność pracy podwładnych, bo ci mogą mieć większą wiedzę techniczną od niego).

 

I na zakończenie…

Zaczęliśmy od efektywności, a skończyliśmy na oczekiwaniach co do kierownika zespołu… Znak to, że pora już kończyć ten tekst.

I na koniec o jeszcze jednym sposobie mierzenia i „poprawiania” efektywności. W pewnej małej firmie normą pracy programisty była ilość spędzonych godzin przy pisaniu kodu. A żeby dopilnować postępów pracy, właściciel firmy co jakiś czas wpadał do pokoju programistów i sprawdzał, czy wszyscy mają ręce na klawiaturach i stukają w klawisze… Historia wydaje się absurdalna, ale jest, niestety, prawdziwa.

A czy w Twoim zespole czy firmie stosuje się jakiś pomiar efektywności pracy? Jeżeli tak – będę wdzięczny za podzielenie się nim w komentarzach.

---

 

Link od naszego sponsora: psycholog Gdańsk.