W ostatnim artykule pisałem o zbliżającym się, a tak naprawdę już obecnym kryzysie gospodarczym i egzaminie ze zdolności adaptacyjnych, 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 takie opinie są jak lord Voldemort, którego 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 dokonać tego, 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 przeprowadzić, 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 powtarzalnych procesów jest kosztowna, ale inwestycja zwracać zaczyna 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ą),
  • faktyczna powtarzalność zautomatyzowanych procedur,
  • 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 stanie się realizowanie tej samej ilości rzeczy o wiele mniejszą załogą. Automaty nie pobierają pensji (choć też generują koszty) i nadal będą pracować, gdy uwolnieni od manualnej pracy ludzie zajmą się bardziej sensownymi działaniami, 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.

Prawdziwi Product Ownerzy

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.

Władza i sposób myślenia

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 typowego dla przedsiębiorcy (ang. enterpreneur), które pozwalałoby na stworzenie sensownej wizji produktu i skutkowałoby decyzyjnością oraz asertywnością niezbędną do dobrego wywiązywania się z odpowiedzialności 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ć od 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ą 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…

Wiedza i umiejętności

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ę odpowiedzialności, jaką Product Owner na siebie bierze.

Natomiast deficyt wiedzy wynika też z braku sprawdzania, co dzieje się na rynku, jak rynek reaguje na dostarczony produkt, jak odbierają go użytkownicy itd. Podejmowanie większości decyzji na podstawie intuicji może skończyć się fatalnie. Prawdziwy Product Owner działa empirycznie, a to implikuje podejmowanie decyzji na podstawie 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 wtedy można tylko radzić sobie ze skutkami błędów decyzyjnych, bo niepodobna zapobiec czemuś, co już się stało.

Odwaga i odpowiedzialność

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 Ownerzy są marni. 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, kiedy ktoś skontaktuje się ze mną i opowie, że użył czegoś, o czym rozmawialiśmy, lub przydało mu się to, 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. Rzadko postrzega się rozwój kompetencji jako narzędzie do podniesienia efektywności i skuteczności w działaniu 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. Jest to w pełni spójne z tym, co w kryzysie jest celem każdej organizacji. A z drugiej strony wiedza jak dobrze użyć metod zwinnych (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 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 jeśli potrzebują podnieść poziom wiedzy i stosowanych praktyk (inżynierskich i nie tylko), nie powinny zamrażać wydatków na usprawnienia i rozwój ludzi (w tym na szkolenia). Da to taktyczne oszczędności, które mogą rychło okazać się strategicznym gwoździem do trumny.

Kilka słów o IT

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 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 samym 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 Developera świadczy umiejętność radzenia sobie również z kodem napisanym jakiś czas temu.

Dlatego najwyższa pora nauczyć się refaktoryzować istniejące rozwiązania, 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 powodzenie waszej firmy 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…