-
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?
-
Co jest pracą a co nie?
Podobno kiedyś, dawno temu na Wojskowej Akademii Technicznej w Warszawie był sobie pewien naukowiec. Miał on taki zwyczaj, że kiedy rozwiązywał jakiś trudny problem, to chodził tam i z powrotem po pokoju – ruch pomagał mu myśleć. Legenda głosi, że do WAT trafił nowy komendant i traf chciał, że z okna jego gabinetu było świetnie widać okno pokoju owego naukowca znajdujące się po drugiej stronie podwórza. Nie raz więc komendant obserwował go chodzącego intensywnie po pokoju. W końcu nie wytrzymał, wezwał go do siebie i powiedział mu tak:
– Proszę pana, widzę jak chodzi pan stale tam i z powrotem po pokoju. Tak być nie może. My płacimy panu za to, żeby pan pracował naukowo a nie chodził po pokoju. Proszę siedzieć i uczciwie pracować przez osiem godzin. Do widzenia!
Nie wiem czy anegdota ta jest prawdziwa, ale dość dobrze ilustruje ona absurdalność wąskiego postrzegania pracy – zwłaszcza intelektualnej – jako czegoś co da się sprowadzić do konkretnej czynności. Niestety, takie postrzeganie jest powszechne – a przy tym jak wszelkie błędne przekonania – prowadzi do podejmowania bezsensownych działań.
Źródłem tego problemu jest niewątpliwie fakt, że przez większą część historii ludzkości większość pracy wykonywanej przez większość ludzi to była praca fizyczna. Przy pracy fizycznej jest dość łatwo określić kiedy się pracuje a kiedy nie. Odruchowo zatem to na pracy fizycznej zbudowane są intuicje, którymi się posługujemy mówiąc o pracy. Ba! Są one nawet zawarte w samym języku (np. „pracować w pocie czoła”).
Pojawienie się prostych maszyn w wieku 18 i 19 niewiele zmieniło – człowiek najczęściej dostarczał zręczności i inteligentnego sterowania, którego maszyny te nie miały. Praca zatem tym różniła się od pracy fizycznej, że polegała na obsłudze jakiegoś urządzenia. Wszystkie wywiedzione z pracy fizycznej intuicje co do tego kiedy pracownik pracuje a kiedy nie nadal pozostawały prawidłowe. Pracownik pracował kiedy stał przy maszynie i coś robił, kiedy od niej odchodził to nie pracował. Zatem, czas przez niego na pracy, a więc obsłudze jakiejś maszyny, mógł być dobrą miarą produktywności.
Na początku zeszłego wieku Taylor dodał do tego naukową systematyzację jeszcze skuteczniej wbijając nam do głów takie dwie zasadnicze intuicje:
- praca to obsługiwanie jakiejś maszyny lub wykonywanie jakiejś czynności,
- czas pracy jest dobrą miarą pracy gdyż kiedy pracownik nie obsługuje maszyny lub nie wykonuje czynności to nie przynosi wartości – a więc nie pracuje.
Zaowocowało to pomiarem czasu pracy i optymalizacją zarówno tego czasu jak i czynności czy wręcz ruchów pracownika tak, żeby ów czas pracy był maksymalnie dobrze wykorzystany. Ponieważ kolejną cechą prostej pracy są proste miary jej rezultatów – sztuki wyprodukowanych części, metry czy kilogramy materiału, litry płynu itp. – łatwo było określić wydajność jako stosunek właśnie takiej miary ilościowej do czasu spędzanego przez pracownika na pracy. Jak już ją można było zmierzyć to można było obserwować wpływ różnych działań (np. skrócenia czasu pracy do 8h) na tak rozumianą wydajność.
W przemyśle był to krok do przodu, jednak cały ten mechanizm kompletnie się załamuje przy pracy intelektualnej. Weźmy na przykład osobę programującą (często etykietowaną jako „programista”). Stwierdzenie, że programista pracuje kiedy wytwarza kod jest tak absurdalne, że aż ciężko uwierzyć, że może być traktowane poważnie. A jednak sami programiści często tak właśnie postrzegają swoją pracę uważając za czas efektywnej pracy tylko momenty kiedy siedzą przed ekranem i klepią kod pozostając w mitycznym stanie „flow”. I – logicznie – ludzie widzący tak swoją pracę postrzegają wtedy wszelkie inne wydarzenia w pracy – na przykład spotkania – jako „nie-pracę”, a więc marnotrawstwo i bezsens. Podobnie, niestety, myśli wielu kierowników.
Tymczasem kod jest tylko efektem najważniejszego procesu w pracy intelektualnej jakim jest myślenie. Narzędziem tej pracy jest mózg, który programista zasadniczo ma ze sobą cały czas. Czy jeśli jadąc autobusem do domu zastanawia się jaki algorytm przyłożyć do problemu to pracuje czy nie? Zewnętrznie nie – nie siedzi przy komputerze, w ogóle nie przebywa w biurze, efektem nie jest choćby pół linijki kodu. Faktycznie jednak pracuje.
Idźmy dalej. Jeśli nasz programista nie pracuje w pojedynkę, to musi jakoś uzgadniać rozwiązania i to, co będzie robione z innymi – czy komunikacja z nimi to „nie-praca”? Czyż zatem czas spędzony np. w zespole przed tablicą na omawianiu rozwiązań i towarzyszące temu zwykle tworzenie na owej tablicy typowych dla tego procesu bazgrołów – schematów, zapisków – nie jest również integralną częścią pracy? Jest nią oczywiście, nawet pomimo tego, że efektów tej pracy nie da się zmierzyć punktami funkcyjnymi.
A przecież to tylko pierwszy „poziom błędu” – jeśli tak można powiedzieć – bo przecież zespół programistów może stworzyć piękny, elegancki kod, który jednak będzie całkowicie bezwartościowy. Kiedy tak będzie? Ano kiedy ów kod nie będzie przydatny dla użytkownika czy klienta. W takiej sytuacji cały czas spędzony na jego tworzeniu można uznać za całkowicie zmarnotrawiony. Jak widać kluczowe znaczenie ma komunikowanie się programisty z klientem, które niewątpliwie jest również integralnym elementem pracy, bo bez tego może się ona okazać całkowicie pozbawiona sensu. Zatem na przykład poświęcone temu dokładnie spotkanie zwane „Przeglądem Sprintu” jest integralną częścią pracy a nie „nie-pracą” albo przerwą w pracy. Istotą jego jest bowiem badanie czy wytworzony produkt ma sens dla odbiorców. I choć programiści nie stworzą na tym spotkaniu ani jednej klasy to jest to inherentna część ich pracy.
Nie negując zatem wagi i znaczenia samego kodowania oraz koniecznego dla tego skupienia (bo rzeczywiście na tym schodzi dużo czasu) praca zwana programowaniem jest złożoną pracą intelektualną, składającą się z wielu czynności, podczas których powstaje wiele produktów pośrednich o ulotnej wartości nie będących kodem (jak choćby owe bazgroły na tablicy – bardzo wartościowe tu i teraz dla konkretnego zespołu, zupełnie bezwartościowe już miesiąc później).
Wszystko co napisałem powyżej biorąc sobie jako przykład osobę programującą (którą dla wygody pisania określiłem stosowną etykietką) odnosi się do wszelkich specjalistów, którzy coś tworzą i wymyślają – np. testerów, grafików, pisarzy itp. W istocie to, co chcielibyśmy osiągnąć – ów „wysokowydajny zespół” który jest celem zabiegów Scrum Masterów i innych (bo przecież nie tylko w Scrumie takowy zespół jest możliwy) to zespół, w którym wszyscy wkładają wszelkie swoje kompetencje w tworzenie dobrego produktu – a więc nie tylko poprawnego technicznie ale i sensownego, wartościowego – nie zaś skupiają się na wykonywaniu swoich wąskich czynności stroniąc od wszystkiego innego jako „nie-pracy”.
Jest ważne by zdawać sobie sprawę, że twórcza praca intelektualna nie polega na tym, że każdy „zaetykietkowany” człowiek wykonuje swoje określone czynności („zadania”). Brak tej świadomości prowadzi organizacje do robienia rzeczy głupich takich jak na przykład liczenie godzin pracy zespołów developerskich czy etykietkowanie i tworzenie silosów specjalizacji.