W ostatnim artykule pisałem o zbliżającym się, a tak naprawdę już obecnym, kryzysie gospodarczym i egzaminie ze zwinności, jaki nas czeka (zobacz „Reality check”). Chciałbym kontynuować myśl, tym razem skupiając się na tym, co da się zrobić realnie, aby zminimalizować negatywne skutki kryzysu.

Eliminacja znanego marnotrawstwa

Niemal w każdej organizacji da się bez trudu znaleźć inicjatywy, których kontynuowanie nie ma żadnego uzasadnienia ekonomicznego, ale brak woli, by je zakończyć. Czasami powody są polityczne (bo służą zadbaniu o dobre samopoczucie „bardzo ważnej osoby”). Częściej wynika to z bezwładu decyzyjnego lub wręcz braku decydenta, który twardo powiedziałby „stop!”. O bezcelowości takich inicjatyw powszechnie wiadomo w organizacji, ale są jak lord Voldemort: ich imienia głośno się nie wypowiada.

Innym źródłem strat i marnotrawstwa, o którym wiedzą wszyscy, są nieefektywne procedury, zbędna biurokracja, utrzymywanie zduplikowanych rozwiązań „na wszelki wypadek”, użycie komercyjnych (drogich!) rozwiązań tam, gdzie dałoby się bez trudu zastosować inne, bezpłatne i często lepsze. Prawie zawsze co mądrzejsi ludzie w organizacji, a często całe zespoły, od lat dopraszają się o zmianę, która jakoś nie następuje…

Zatrzymanie zbędnych projektów i usunięcie zatorów decyzyjnych to pierwszy krok. Drugim powinno być wdrożenie najszybciej jak to możliwe proponowanych usprawnień, jeśli dają one w perspektywie większą efektywność lub redukcję kosztów. Tak, to oznacza jakąś inwestycję (wydatek) – ale lepiej zrobić ją, póki nas stać. Jeśli zaśpimy, być może za parę miesięcy nie będzie ani za co, ani kim takich zmian dokonać, a koszty stałe utrzymywania rzeczy zbędnych w ruchu zabiją organizację.

Automatyzacja powtarzalnych procesów

Każdy proces bez wyjątku obejmuje dwie kategorie działań: te, które są realizacją pewnego powtarzalnego lub przewidywalnego (dla znanych warunków początkowych) zestawu operacji, oraz te wymagające udziału ludzi, w szczególności do podejmowania decyzji. O ile całkowite wyrugowanie człowieka z wielu procesów nie jest możliwe, o tyle oparcie powtarzalnych czynności na pracy ludzi jest błędem. Generuje to koszty i problemy – bo pracownicy się mylą, a im bardziej powtarzalna (czyli nudna) praca, tym ryzyko błędów wyższe.

Automatyzacja tych powtarzalnych procesów jest kosztowna ale inwestycja zwraca się niemal od razu, jeśli realizują ją profesjonaliści, którzy wiedzą, co robią. Korzyści są oczywiste, ale na wszelki wypadek wymienię kilka z nich:

  • redukcja ilości problemów spowodowanych błędami ludzkimi,
  • przyspieszenie działania wielu procesów (bo automaty pracują szybciej niż ludzie i się nie męczą),
  • możliwość zrównoleglenia działań lub skalowania ilości działań odbywających się równocześnie (rzecz niewykonalna w krótkim czasie, jeśli praca wykonywana jest manualnie, bo ludzi trzeba przeszkolić).

Skrócenie czasu, jaki niezbędny jest na przebieg różnych procesów dzięki automatyzacji, może dać przewagę organizacji nad konkurentami na rynku. Poza tym, jeśli kryzys naprawdę będzie głęboki, konieczne okażą się redukcje zatrudnienia. Nagle konieczne będzie realizowanie tej samej ilości rzeczy o wiele mniejszą załogą. Automaty nie pobierają pensji i nadal będą pracować, a uwolnieni od manualnej pracy ludzie mogą przydać się do bardziej sensownych działań, gdzie inteligencja i kreatywność jest niezbędna.

Warto zauważyć, że automatyzacja procesów jest tym obszarem, w którym – jako konsultanci wraz z kolegami z Code Sprinters – zauważamy największe obszary możliwych usprawnień. Z drugiej strony to jednocześnie obszar, w którym stosunkowo najłatwiej marnotrawstwo eliminować, bo nie wymaga to rewolucyjnych zmian, a jedynie narzędzi, umiejętności i konsekwencji w działaniu.

O automatyzacji jeszcze kilka słów za moment, gdy będę pastwił się nad IT.

Realny Product Ownership

Jak już zadbamy o to, żeby przestać marnować pieniądze i czas w sposób oczywisty i z daleka widoczny, pora pochylić się nad wartością tego, co nadal jest robione. Bo niekoniecznie wszystko jest potrzebne. Ba, doświadczenie w pracy konsultanta każe mi stwierdzić, że uzasadnienie dla wielu inicjatyw biznesowych jest bardzo liche, a często w ogóle go brak. Zakłamywanie rzeczywistości i myślenie życzeniowe („może to się przyda?”) wiąże się z trzema deficytami w organizacji.

Pierwszym, najbardziej dotkliwym, jest brak Product Ownerów (albo ogólniej managerów produktów) z prawdziwego zdarzenia. I nie chodzi tu nawet o to, że w wielu organizacjach tytularny Product Owner nie ma realnej władzy nad tym, co jest niby jego własnością. Chodzi o brak myślenia przedsiębiorcy (ang. enterpreneur), które pozwalałoby na wytworzenie sensownej wizji produktu, i skutkowałoby decyzyjnością oraz asertywnością niezbędną do dobrego sprawowania roli Product Ownera. Ludzie, którzy tak działają mimo braku formalnej władzy, bardzo często ją w końcu dostają – bo otoczenie zaczyna ufać takiej osobie, albo wręcz czerpać z niej inspirację.

Niestety wielu „Product Ownerów” woli jęczeć, że nic od nich nie zależy, jednocześnie z lubością zajmując się dyskusją na temat takiej czy innej formy zapisu konkretnego wymagania – zapominając o całym świecie dookoła i pozwalając okazjom biznesowym wymykać się z rąk. Można powiedzieć, że szukają wymówek i problemów, zamiast możliwości.

Osobną kategorią „Product Ownerów” są ci, którzy w teorii mają i zdolności, i możliwości (wiedzę, władzę), ale nie mają czasu, by zadbać o podejmowanie sensownych decyzji. Już samo to, że nie uznają za wartościowe poświęcenia czasu na swój produkt, powinno być silnym sygnałem, że być może produkt ten jest zbędny i nie warto dalej go rozwijać. Najczęściej pojawiają się, niczym meteor, na kilka chwil, podejmują kilka – czasem bardzo trafnych – decyzji i znikają. Realnego Product Ownera brak…

Drugim deficytem jest brak wiedzy o rynku i samym produkcie. Nie wystarczy bowiem dać komuś władzę nad produktem, by uczynić go Product Ownerem. Ta osoba musi rozumieć, co ma zbudować i utożsamiać się z tym – wszak jest właścicielem produktu i nazwa ta nie jest przypadkowa, bo oddaje istotę roli.

Natomiast deficyt wiedzy wynika też z braku realnego sprawdzania, co dzieje się na rynku, jak rynek reaguje na dostarczony produkt, jak odbierają go użytkownicy itd. Podejmowanie większości decyzji w oparciu o intuicję może skończyć się fatalnie. Prawdziwy Product Owner działa empirycznie, a to implikuje podejmowanie decyzji na bazie czegoś, co wiadomo na pewno. Niestety w wielu miejscach nikt nic nie mierzy, co najwyżej liczony jest bilans zysków i strat w jakimś okresie (np. półrocza). Jeśli decyzje są nietrafione, w końcu będzie to widać, przy czym na tym etapie można już tylko radzić sobie ze skutkami błędów decyzyjnych, bo niepodobna zapobiec czemuś, co już się stało.

Trzecim deficytem jest brak odwagi do podejmowania decyzji. Przejawia się to często jako brak umiejętności powiedzenia „nie”, podczas gdy Product Owner musi być mistrzem w obłupywaniu potrzeb do absolutnego minimum i wyławianiu wartości z szerokiego strumienia potrzeb. Dlaczego? Ponieważ nie jest możliwe zrobienie wszystkiego, a większość pomysłów – nawet sensownych – pozostanie na zawsze na papierze.

Kryzys wystawi bardzo wysoki rachunek tym firmom, w których product ownership jest lichy i ma niską skuteczność. Już teraz każdy prawdziwy Product Owner powinien dążyć do potwierdzenia wartości swego produktu – nie udowodnienia na siłę, że jest potrzebny, ale sprawdzenia, czy naprawdę tak jest. I jeśli okaże się, że warto utrzymywać rozwiązanie, krytycznym jest zadbanie, by produkt ten nie utracił rynku. A jeśli już jest zbędny? Cóż, profesjonalista poinformuje o tym organizację tak, by ludzie, którzy dla niego budowali ową niepotrzebną rzecz, mogli zająć się czymś, co wartość przynosi.

Podniesienie poziomu wiedzy i praktyk

Jestem konsultantem i trenerem, uczę ludzi jak korzystać z różnych metod do radzenia sobie ze złożonymi problemami. Satysfakcję daje mi świadomość, że pomogłem – cieszę się za każdym razem, jak ktoś skontaktuje się ze mną i opowie, jak użył czegoś, o czym rozmawialiśmy, lub czego go nauczyłem.

Szkolenia i inwestowanie w rozwój pracowników prawdopodobnie będzie pierwszym obszarem, w którym firmy będą poszukiwać oszczędności. Ubolewam nad tym, ale takie są realia: dla większości organizacji podnoszenie kompetencji to działanie obliczone na „zwrot inwestycji w bliżej niekreślonej przyszłości”, a nie na pozyskanie narzędzi do skuteczniejszego działania tu i teraz.

Tymczasem praktyki wywodzące się z Leana lub Agile mogą pomóc wielu firmom w przetrwaniu kryzysu. Są bowiem nastawione na ograniczanie marnotrawstwa i poszukiwanie lepszego sposobu działania – podnoszenie efektywności i zwiększenie wartości pracy, jaką wykonują ludzie. Jest to w pełni spójne z tym, co w kryzysie jest celem każdej organizacji. A z drugiej strony wiedza jak naprawdę użyć metod zwinnych (robić je na serio, a nie na pokaz, bo to modne) jest wciąż niewielka. Tymczasem czas, by na serio być Agile i by kierować się filozofią Lean, właśnie nadszedł.

Podobnie rzecz ma się z automatyzacją i ogólnie z podniesieniem kompetencji „twardych” w obszarze technologii, która wspiera różne działania biznesowe. Jeśli ludzie zatrudnieni do tej pory w firmie nie zdołali sensownie automatów zbudować, być może nie mają zdolności, by to zrobić. W sytuacji zamrożenia wydatków na szkolenia i postępującej redukcji zatrudnienia szansa, że nagle objawi się w załodze i wiedza, i wola, by zrobić coś takiego szybko i dobrze, jest dokładnie zerowa.

Oczywiście niemal w każdej firmie już są ludzie, którzy mają niezbędne kompetencje, by budować automaty i od miesięcy, czasem lat, domagają się przyzwolenia na to i niezbędnych środków. Niewykluczone, że teraz odejdą, bo na rynku pojawi się popyt na specjalistów w tej dziedzinie.

Jeśli więc firmy nie chcą „wykrwawiać się” w ten sposób (tracąc cennych ludzi) i potrzebują podnieść poziom wiedzy i stosowanych praktyk (inżynierskich i nie tylko), niekoniecznie rozsądnym jest zamrożenie wydatków na szkolenia. Da to taktyczne oszczędności, które mogą okazać się strategicznym gwoździem do trumny.

O działach IT słów kilka

Na koniec parę cierpkich słów o ludziach zajmujących się tworzeniem i utrzymaniem systemów informatycznych. Rynek pracownika, z jakim mamy do czynienia od paru lat, właśnie znika. To oznacza, że w szeroko rozumianym „IT” zaczną się zmiany.

Pierwszą będzie zniknięcie z tej branży wielu osób, które pojawiły się w niej wyłącznie dla pieniędzy, choć brak im realnej pasji do zajmowania się oprogramowaniem. I to akurat wyjdzie wszystkim na dobre.

Drugą zmianą będzie zdemolowanie zespołów, które jakoś zgrały się ze sobą, a teraz mogą zostać przetrzebione w ramach redukcji zatrudnienia. Nauczenie się jak robić tyle samo w ograniczonym składzie osobowym będzie prawdziwym testem na umiejętność współpracy i profesjonalizm. Od lat z zażenowaniem wysłuchuję opowieści o tym, jak to ktoś „nie po to się zatrudniał jako programista, żeby testy pisać” – to się musi zmienić i ten efekt kryzysu (przypomnienie, że developer to coś więcej niż klepacz kodu) przywitam z zadowoleniem.

Trzecia zmiana: konieczność szybszego reagowania na potrzeby rynku, podniesienia jakości, brak przestrzeni na marnotrawstwo – może przerastać umiejętności wielu istniejących zespołów. Pisałem o braku automatyzacji procesów wcześniej – podobny brak automatyzacji bez trudu można znaleźć w IT. A jest to domena, gdzie istnieją od lat (i pojawiają się coraz to nowe) narzędzia i praktyki wspierające automatyzację. Ba, większość współczesnych podejść do rozwoju systemów informatycznych jest na niej oparta!

Dlatego, panie i panowie z IT, pora się ogarnąć. Klecenie paczek instalacyjnych ręcznie po to, żeby je potem kopiować plik po pliku na serwery, albo przesyłanie kodu mailem, to niekoniecznie to, czego dziś oczekuje się od inżyniera oprogramowania. Mówienie, że „tu się testów automatycznych napisać nie da, bo to legacy” również nie świadczy za dobrze o waszych kompetencjach. Robienie rzeczy w najnowszych technologiach jest fajne, ale o klasie programisty (lub ogólniej: developera) świadczy umiejętność radzenia sobie również z kodem napisanym jakiś czas temu.

Dlatego najwyższa pora nauczyć się refaktoryzować istniejący kod, usuwać dług techniczny, automatyzować testy i wydania kodu. Praktyki takie jak continuous integration to nie jest fanaberia, ale podstawa – zwłaszcza, że dziś nie wymaga to pisania od podstaw złożonych systemów, tylko można wykorzystać gotowe rozwiązania.

A dlaczego trzeba się tego wszystkiego nauczyć? Bo jeśli wasza firma zależy od skuteczności działania systemów informatycznych – a takich organizacji jest coraz więcej – „nieogarnięte IT” może ją skutecznie wepchnąć do grobu. Z drugiej strony efektywnie działający inżynierowie IT mogą dać firmie przewagę nad konkurencją, jeśli umożliwią szybsze reagowanie na zmiany. A zmiany w kryzysie następują szybko, bardzo szybko…

Zdjęcie: Yaoqi LAI