-
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. 🙂
-
O depresji przedsiębiorcy
To jak widzimy świat, co jest dla nas ważne – jaki jest nasz świat – jest w dużym stopniu kształtowane przez media. Dzięki rozwojowi techniki są one w stanie jeszcze intensywniej i silniej niż kiedykolwiek przedstawiać historie i doświadczenia cudze albo całkowicie zmyślone z taką siłą, że stają się one nasze własne – wrastają w nasz „filtr” postrzegania świata.
W mediach poświęconych tematyce biznesowej dużo uwagi poświęca się startupom. Startupy to są firmy, które mają nowy, rewelacyjny i rewolucyjny pomysł na usługę lub produkt, taki, który zasadniczo wywróci rynek lub wręcz stworzy zupełnie nowy. Wzorcem dla ludzi, którze je tworzą – oraz wielu, którzy się temu tylko przyglądają – są oczywiście te startupy, którym się udało i które obecnie są wielkimi firmami – a ich założyciele nieprzyzwoicie bogatymi ludźmi. Wielu z nich funkcjonuje wręcz jako swego rodzaju „święci” tej specyficznej odmiany wiary w sukces, ikony i idole do naśladowania – Steve Jobs (Apple), Bill Gates (Microsoft), Larry Ellison (Oracle), trzej założyciele Google, Mark Zuckerberg (Facebook) a ostatnio Elon Musk (Tesla, Space-X). Jest jeszcze wielu innych znanych tylko w swojej produktowej niszy albo na lokalnym, krajowym rynku. Właściwie każdy założyciel startupa, który się w miarę rozwinął może zakosztować odrobiny sławy i uznania, bo to ich sukcesy są wzorem a oni sami wzorcem do naśladowania. Ogląda się wywiady z nimi, studiuje ich działania, sposób życia i dietę w nadziei, że może uda się powtórzyć ich sukces.
Wszystko to jest piękne i pouczające, ma jednak jedną paskudną wadę. I nie chodzi mi o powszechnie znany fakt, że przytłaczająca większość startupów kończy się kompletną klapą (albo pomysł albo wykonanie albo jedno i drugie nie było tak rewolucyjne i rewelacyjne jak się wydawało), bo z tym się liczy nawet większość założycieli startupów. Ani nawet o to, że wielu z nich swój sukces zawdzięcza nie tylko świetnemu pomysłowi i szczęściu, ale także koneksjom dzięki którym mogli dotrzeć do ludzi, z którymi przeciętny Kowalski nie ma szans porozmawiać. Nie, mam na myśli ten przykry fakt, że patrząc przez ten właśnie filtr normalny, dobrze prowadzony biznes, który rośnie o te 10-15% rok do roku wydaje się być kompletną porażką a prowadzący go życiowymi nieudacznikami przy wspomnianych wyżej ikonach sukcesu i ich wynikach. Niestety wielu przedsiębiorców wpędza to w depresję, która jako żywo przypomina mi depresję wielu kobiet, które będąc całkiem ładnymi dołują się porównując się z podrasowanymi w Photoshopie zdjęciami modelek.
Dużo ważniejsze niż samopoczucie tych przedsiębiorców jest jednak to, że gospodarka opiera się właśnie na takich normalnych, przeciętnych firmach a nie na super-startupach. To właśnie one dostarczają większości usług i towarów, z których korzystamy i wypracowują większość narodowego bogactwa. Dlatego wydaje mi się, że powinniśmy je bardziej doceniać. I sami przedsiębiorcy powinni siebie i swoje firmy także bardziej docenić. Dobrze prowadzony biznes, który notuje systematyczne wzrosty, ma zadowolonych klientów, dobre produkty, jest dobrze zarządzany i solidnie rozwijany to duży sukces, który nie wszystkim udaje się osiągnąć.
-
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?