CAPEX i OPEX w SCRUM

CAPEX i OPEX w SCRUM

Bez wątpienia Scrum jest frameworkiem zaprojektowanym do organizacji pracy wytwórczej. Zatem wszystko to, co zespół wytworzy potencjalnie można zaliczyć do kapitału przedsiębiorstwa, a koszt pracy ludzi jako nakład inwestycyjny. Niestety nie zawsze. Jak wówczas liczyć CAPEX?

Czy to się nam podoba czy nie, cykl życia produktu jest w większości przypadków sekwencyjny. Zaczyna się od identyfikacji potrzeb, wytworzenia i dostarczenia a później utrzymania i złomowania. Nakłady ponoszone na identyfikację potrzeb i wytworzenie bez wątpienia są inwestycją. Czasem do takiej można też zaliczyć dostarczenie produktu. Trudno jednak mówić o inwestycji w przypadku utrzymania i złomowania. Stosując to podejście, łatwo wprowadzić podział koszów: do momentu dostarczenia produktu do klienta mamy CAPEX, później wszelkie działania związane z produktem to już OPEX.

Rzecz nam się komplikuje, gdy ten tradycyjny cykl życia produktu chcemy zastosować dla oprogramowania. Scrum, a będąc bardziej precyzyjny, każda metoda przyrostowa, niejako skraca czas inwestycji i wydłuża czas utrzymania lub jak kto woli użytkowania produktu. Z jednej strony to dobrze, bo szybciej możemy zacząć sprzedawać. Z drugiej strony komplikuje to trochę sposób liczenia kosztów operacyjnych i inwestycyjnych, gdyż w czasie utrzymania produkt wciąż jest rozwijany. Najlepiej problem ten widać, gdy ten sam zespół pracuje wspólnie nad wytworzeniem wartości, jak i później nad jego utrzymaniem. Może się okazać, że nie będziemy wiedzieli do jakich kosztów zaliczyć pensje pracowników tego składu.

Rozwiązanie I

Najprostszym wyjściem z tej sytuacji byłoby powiedzenie, że do momentu pierwszego release’u pensje to CAPEX, później to OPEX. I po problemie. Byłoby, gdyby nie ulgi podatkowe. Zespół przecież wciąż rozwija produkt, dodaje nowe funkcjonalności. Czas na to poświęcony, a co za tym idzie także wynagrodzenia, są w rzeczywistości nakładem inwestycyjnym. Niestety nie całe wynagrodzenie można w takiej sytuacji zaliczyć do CAPEX, bowiem zespół podejmuje działania operacyjne, związane z bieżącym utrzymanie produktu, np. aktualizuje zabezpieczenia, naprawia usterki, monitoruje infrastrukturę, itd.

Rozwiązanie II

I tu z pomocą przychodzą nam różnego rodzaju narzędzia i pluginy do rejestracji czasu pracy. Również JIRA posiada możliwość rejestracji czasu spędzonego nad zadaniem. Rozwiązaniem jakie w pierwszej kolejności przychodzi do głowy jest poproszenie zespołu o dodawanie do rejestru sprintu całej pracy w formie tasków i historyjek oraz rejestrowanie faktycznie spędzonego nad nimi czasu. Rozwiązanie, choć nieeleganckie, to pozwala uzyskać informacje na temat tego, ile czasu zespół pracował nad nową wartością a ile czasu nad utrzymaniem istniejącej. Problem w tym, że taka “księgowość” angażuje każdą osobę w zespole. Czasem nawet godzinę miesięcznie. W konsekwencji, dla jednego zespołu sposób ten może się nie opłacać, ale kilku…

Są tacy, co próbują, ale… Efekt skali daje dużo większe możliwości. Przy 25 zespołach, każdy po książkowe 7 osób, może być już opłacalne zatrudnienie tańszego pracownika do liczenia CAPEXu. Gdyby tylko znaleźć inny sposób na zbieranie informacji o czasie spędzonym nad utrzymaniem.

Rozwiązanie III

I tu z pomocą przychodzi nam sam Scrum i tradycyjna ewidencja czasu pracy. Z tej drugiej wiemy dokładnie ile dni w danym okresie pracownicy byli obecni. To przekłada się na rzeczywisty czas ich pracy. Brak nam jedynie informacji o proporcji między CAPEX a OPEX, tzn. jaki czas spędzili oni nad dodaniem nowych funkcji, a ile czasu zajmowali się utrzymaniem. Aby to uzyskać, nie ma konieczności rejestracji czasu spędzonego nad każdym zadaniem przez każdego członka zespołu.

Dzięki pracy w iteracjach, których długość jest znana, wprost można dokonać mapowania rejestrów sprintów na okresy rozliczeniowe. Wykorzystujemy tutaj mechanikę Scruma oraz założenie, że zespół do organizowania pracy w iteracji wykorzystuje rejestr sprintu (ang. Sprint Backlog) a praca w nim zarejestrowana jest realizowana wspólnie, tzn. cały zespół pracuje nad wytworzeniem wartości. W takim rejestrze powinna być zarejestrowana także praca utrzymaniowa, ponieważ miała ona (negatywny, ale jednak) wpływ na cel sprintu.

Na koniec iteracji możliwe jest policzenie ile elementów w rejestrze sprintu to praca wytwórcza a ile utrzymaniowa. Otrzymany stosunek to właśnie szukana proporcja, potrzebna do obliczenia CAPEX i OPEX. Wystarczy teraz przemnożyć obecności pracownika przez procentowy udział pracy wytwórczej. W ten sposób otrzymamy nakład inwestycyjny wyrażony w rzeczywistym czasie.

Dodatkowo, niektóre zespoły wykorzystują tzw. story pointy do różnicowania wielkości elementów. Można wówczas poprosić je o to, aby także zadania utrzymaniowe były ocenione w ten sam sposób, na przykład na koniec iteracji. Dzięki czemu stosunek CAPEX do OPEX będzie bardziej dokładny.

W porównaniu do rozwiązania II, w tym przypadku oszczędzamy czas, poprzez redukcję ilości informacji, jaka musi być wprowadzona do narzędzia, np. JIRA. Często zdarza się, że dane te już tam są i wymagają jedynie niewielkiego uzupełnienia. Bez wątpienia zaletą tego podejścia, jest wykorzystanie samej mechaniki Scruma i ponowne wykorzystanie raportów z iteracji oraz wartości story pointów, których zespół i tak używa do obliczania swojej prędkości oraz oceny efektywności pracy. W niektórych przypadkach, nowością dla zespołu może okazać się jednie konieczność oceny wielkości pracy utrzymaniowej. W wyniku takiej zmiany zespół może zyskać bardziej szczegółowe informacje na temat szybkości wytwarzania oraz argumenty (oparte o rzeczywiste dane) w dyskusji na temat zasadności implementacji usprawnień zmierzających do redukcji pracy utrzymaniowej. Wiedza o stosunku pracy wytwórczej do utrzymaniowej wydaje się być także ciekawym elementem budowania świadomości zespołu.