-
Nigdy nie będzie dobrze
Postanowiłem się dziś podzielić obserwacją tak oczywistą, ale najwyraźniej nie na tyle by była ona powszechnym rozumieniem. Otóż: nigdy nie będzie dość szybkich zespołów developerskich.
Dlaczego? Ano dlatego, że wymyślanie potrzeb oraz funkcji w oprogramowaniu, które mogłyby je zaspokajać jest bardzo szybkie. Sam pomysł to krótki błysk w duszy i przebieg impulsów po neuronach – jest! Eureka! Zapisanie go, ew. przedyskutowanie to kwestia godzin. Ale realizacja może trwać dni, tygodnie, miesiące nawet. Jeśli dodamy do tego dość typową sytuację, kiedy wymyślających (zwanych elegancko „interesariuszami”) jest istotnie więcej od implementujących widać wyraźnie, że jest niemożliwością doprowadzenie do sytuacji, w której każdy pomysł („wymaganie”) jest realizowane bez oczekiwania. Z tego właśnie powodu praktycznie zawsze wymagania czekają a ich lista rośnie.
[Opisując to językiem procesów tworzenie oprogramowania to – na wysokim poziomie ogólności – etap, na którym jednostki pracy są wytwarzane bardzo szybko, po którym następuje etap przetwarzający je dużo wolniej.]
Jeśli chwilę pomyśleć rzecz jest – jak to już napisałem wyżej – oczywista. Prosta logika mówi, że nie może być inaczej. A jednak mimo to w praktycznie wszystkich organizacjach, z którymi miałem do czynienia, jest ogromny nacisk na to, żeby zespoły działały szybciej. Tak jakby organizacje chciały osiągnąć to marzenie, idealny stan, w którym powiedzą sobie „mamy już wystarczająco szybki development”. Realizuje się to głównie przez odruch zatrudniania (stąd taka popularność tematu „skalowania Agile” – jak się już tych ludzi zatrudni jakoś trzeba ogarniać współpracę pomiędzy nimi).
I w sumie nie ma w tym nic złego gdyby nie to, że nie widać by co najmniej taka sama energia i zaangażowanie były poświęcone na dobre wybieranie tego, co będzie realizowane. A to jest rzecz absolutnie najważniejsza. Mając ograniczony zasób jakim są możliwości i energia developmentu należy przede wszystkim zadbać o to, by nie marnować go na rzeczy o niskiej wartości. Każde wymaganie, każdy pomysł powinno się trzy razy obracać w palcach, oglądać pod światło i porównywać z innymi żeby mieć absolutną pewność, że w danej chwili nie ma naprawdę nic ważniejszego co developerzy mogliby zrobić.
To jest kolejna oczywistość, dużo bardziej zresztą uniwersalna niż tworzenie oprogramowania – wszędzie ważna jest koncentracja. Niby wszyscy o tym wiedzą, ale w 9 przypadkach na 10 kiedy np. w ramach warsztatu zwizualizujemy kierownictwu ile mają otwartych inicjatyw i projektów to jest wielkie zdziwienie. Po czym oczywiście jedno z pierwszych pytań jest takie: co zrobić, żeby development szybciej pracował? Może zatrudnijmy więcej programistów?
Myślę, że lekarstwem na to może być powtarzanie w kółko oczywistości, od której zacząłem ten wpis: „nigdy nie będzie wystarczająco szybkich zespołów”. I dodawanie „zatem zastanówmy się jak najlepiej wykorzystać to, co mamy”.
Jak to konkretnie zrobić? Ano stosując empiryzm, nie pakując się w wielkie inicjatywy bez zweryfikowania małym (i tanim) eksperymentem, że warto, stosując biznesowe metryki (np. kwantyfikację celów biznesowych) i weryfikowanie na ile dana planowana funkcjonalność je poprawia – i tak dalej. Dużo narzędzi i praktyk wykraczających poza zakres tego artykuliku (o części z nich mówimy na szkoleniu dla Product Ownerów, o innych na różnych warsztatach). Czyli robiąc wszystko co się da, żeby właśnie jak najlepiej wybierać rzeczy, które trafią do realizacji.
Ale to są narzędzia, a najważniejsza jest świadomość, że w ten sposób osiągniemy więcej niż koncentrując się na powiększaniu zespołów. Teraz już ją masz, więc do dzieła! Bo choć nigdy nie będzie dobrze, to jednak może być lepiej. 🙂
-
Kwestia perspektywy
Na jednym z ostatnich warsztatów zderzyłem się z pewnym problemem – uczestnicy zupełnie nie rozumieli po co komuś w biznesie jakieś oszacowania, a w szczególności informacja ile mniej-więcej będzie „to coś” kosztować. Przecież mamy Agile, się zrobi – się zobaczy. Dyskusja toczyła się przez jakiś czas, zanim do mnie dotarło, że problemem jest brak w życiu osób, z którymi rozmawiam, doświadczenia, do którego mogliby się odnieść.
O jakie doświadczenie mi chodzi? O doświadczenie wydawania pieniędzy na produkt software-owy lub choćby jakieś jego funkcje. Najlepiej własnych pieniędzy we własnym biznesie albo przynajmniej powierzonego (i nietrywialnego) budżetu w firmie. Znajdując się w takiej sytuacji można podjąć trzy decyzje – wydać pieniądze na zbudowanie danego produktu/funkcji, wydać je na zbudowanie innego produktu/funkcji oraz… zainwestować je w jakiś instrument finansowy o mniej-więcej znanej stopie zwrotu (ROI). Ludzie potocznie zwani „kierownictwem” takie decyzje podejmują relatywnie często. I nie podejmą decyzji o wydaniu choćby grosika na projekt, co do którego nie będzie jakiegoś uzasadnienia, że ów grosik się zwróci i przyniesie co najmniej pół grosika zysku. Jasne, że czasem jest ryzyko, że się nie uda (czyli zysku nie będzie) ale ono zwykle musi być skompensowane spodziewanym zwrotem (jak się uda będzie więcej zysku niż przy bezpieczniejszych, bardziej przewidywalnych inwestycjach). Można realizować przedsięwzięcie zwinnie i w ten sposób ograniczać ryzyko (wcześniej można skorygować produkt lub w ogóle go porzucić ograniczając potencjalne straty) oraz wykorzystywać zbudowane funkcje (zwrot następuje wcześniej), jednak sama decyzja „robimy/nie robimy” podejmowana jest z konieczności a priori i musi być oparta na przekonaniu, że to się ma szanse opłacić. Najczęściej dość trudno mieć takie przekonanie nie wiedząc, choćby w zarysie, ile dana rzecz (funkcja, produkt) będzie kosztować.
„Punkt widzenia zależy od punktu siedzenia” mówi przysłowie i ma rację. Patrząc z żabiej perspektywy ciężko zrozumieć punkt widzenia żyrafy – i odwrotnie. Kto nigdy nie programował, temu może być trudniej zrozumieć dług techniczny – kto nigdy nie zarządzał kapitałem i produktem temu ciężko trudniej zrozumieć po co te stałe pytania „a ile to będzie kosztować?”. To czasem utrudnia współpracę – w miejsce próby zrozumienia punktu widzenia innych pojawia się uznanie ich za głupich, leniwych czy w inny sposób nie do końca dobrych. Czasem jeśli nie możemy zrozumieć powodów takiej czy innej prośby i nie docierają do nas wyjaśnienia, to może powodem jest właśnie brak doświadczenia? Może wtedy warto po prostu zaufać, że jeśli ktoś o coś prosi to jest mu to rzeczywiście do czegoś potrzebne nawet jeśli my nie do końca tą potrzebę rozumiemy?
-
Lokalne optymalizacje
Na każdą organizację można spojrzeć jako na system, który przetwarza pewne sygnały wejściowe na jakieś produkty wyjściowe. W tym sensie organizacja jest zbiorem procesów, mniej lub bardziej powtarzalnych, w których przepływają pewne zlecenia. W przemyśle mają one charakter materialny, namacalny. W pracy intelektualnej (mylonej czasem z biurową) są najczęściej tylko pojęciami takimi jak pojedyncza sprawa, zlecenie, „ficzer” itp. Umownie możemy je nazwać „jednostkami pracy”.
Tak patrząc na dowolną firmę o jej sprawności świadczą dwa najważniejsze parametry: przepustowość (liczba jednostek pracy w jednostce czasu, które firma przetwarza) oraz średni czas przetwarzania (czyli średni czas jaki upływa od rozpoczęcia do zakończenia pracy nad jednostką pracy – oczywiście patrząc z perspektywy odbiorcy). Efektywność to funkcja kosztu – innymi słowy ile kosztuje przetworzenie jednostki pracy – ale z pewnością ma ona związek ze średnim czasem przetwarzania, przeciętnie im szybciej coś jest przetwarzane tym to przetwarzanie powinno być tańsze.
Teoretycznie kierujący organizacją powinni tak działać, by organizacja tak szybko jak to w danej domenie działalności jest możliwe przetwarzała jednostki pracy od wejścia do ukończenia.
Wyobraźmy sobie teraz organizację jako proces składający się z wyróżnialnych kroków wykonywanych przez konkretnych ludzi i z użyciem konkretnych zasobów. Każdy z tych kroków działa sobie jakoś, w swoim tempie, a średni czas przetwarzania całości wynosi X. Co stanie się, jeśli krok C raptownie przyspieszy, a więc stanie się dużo bardziej wydajny od innych? Czy sumaryczny czas przetwarzania wzrośnie czy spadnie?
Wbrew pozorom średni czas przetwarzania wzrośnie. Dlaczego? Bo wyniki pracy kroku C zaczną się odkładać w coraz bardziej rosnącej kolejce przed krokiem D, który nie przyspieszył. Co się podzieje z przepustowością? Pozostanie taka sama, ograniczona możliwościami kroku D.Taki scenariusz to właśnie lokalna optymalizacja – tylko część całego łańcucha albo procesu usprawniła się bez zmiany w pozostałych. Stan całości organizacji nie uległ poprawie, ale przeciwnie, pogorszeniu.
Jakie to ma przełożenie na nasz świat? Takie mianowicie, że w bardzo wielu miejscach Scrum (czy Kanban) zastosowany w zespołach jest właśnie taką lokalną optymalizacją. Reszta organizacji się nie zmienia, nie zmieniają się zwłaszcza te procesy, które zajmują się wprowadzaniem zmian do użytku. W efekcie co prawda zespoły wytwarzają często wydawalny produkt, działają szybciej, efektywniej – ale korzyści nie widać, bo wydania nadal są tylko trzy razy do roku (i jest na to mnóstwo wspaniałych uzasadnień).
Przy tym lokalna optymalizacja w wytarzaniu oprogramowania jest bardziej zdradliwa niż w fabryce. W przetwarzaniu fizycznych elementów jest ona bowiem widoczna namacalnie. Po pierwsze kolejki wytworzone przez krok, który nagle przyspieszył mają charakter widocznego stosu elementów czy półproduktów, których przechowywanie dodatkowo kosztuje. Po drugie jednak widać wyraźnie, że poprzednie kroki nie nadążają co prowadzi do przestojów na etapie, który przyspieszył, bo zaczyna mu brakować elementów na wejściu (z kroków A i B).Tymczasem w naszej dziedzinie ten drugi efekt jest rzadziej widoczny, bo zawsze jest pełno pomysłów na ficzery i zmiany, które można wprowadzić do prodktu. Co więcej, jeśli zmiany naprawdę najbardziej wartościowe zostaną załatwione można na lata utonąć w mało wartościowych pomysłach, co jest niestety odruchem w wielu organizacjach zamiast otwartego przyznania, że to, co najważniejsze jest już zrobione i w sumie nie ma uzasadnienia dla utrzymywania dużych zespołów developerskich. Mogłoby to się stać widoczne, gdyby śledzono wartość dostarczaną w funkcji czasu starając się ją jakoś obiektywnie mierzyć, ale z mojej praktyki wynika, że jest to niezmiernie rzadkie.
Podsumowując: przyspieszanie i usprawnianie działania samych zespołów – w czym wiele organizacji celuje w ramach tzw. „wdrożeń Scrum” – poprawia wskaźniki w IT, ale nie przynosi spodziewanych korzyści dopóki pozostaje lokalną optymalizacją a reszta organizacji pozostanie bez zmian. Niestety, nie jest to widoczne bo zawsze jest pełno czekających na jakąś zmianę w produkcie i powstaje złudzenie, że to wciąż za mało tempa i pojemności w developmencie.