Jak powstaje shadow software

Kiedy dashboard świeci na zielono, a testerzy piszą własne aplikacje

Mieliście kiedys tak, że pracowaliście w narzędziu, w którym brakowało wam jednej, banalnej funkcji? Albo jeszcze lepiej. Mieliście system, z którego zadowolony był wasz kierownik, menedżer, jego menedżer i cała lista osób ‘na górze’ a wam szybciej było… wyslać maila dołączajac 5 grup w CC? Bo raporty się zgadzają, wykresiki pięknie świecą na zielono (bądź czerwono), statystyki można wyeksportowac do powerbi, excela czy innego painta a na pytanie jak status wertujecie maile bo jakoś nikt się nie zastanowił czy ludziom, którzy codziennie w tym pracują faktycznie to pomaga.

I tu pojawia się pytanie: czy aplikacja wspierająca pracę, która bardziej wspiera nadzór i kontrole niż jej wykonanie jest jeszcze narzędziem wspierającym? A może jest już tylko ładnie zawiniętym i przyozdobionym sabotażem terminów i produktywności?

Dziesięć zespołów, jedno środowisko i mała katastrofa

Wyobraźmy sobie firmę, nie żaden januszex, tylko prawdzwią, rodzimą korporacje, która szturmem i krwią zdobyła swoje miejsce na świecie. Pracuje tam (zgodnie z duchem więcej menedżerów = lepsza firma) 10 zespołów testerskich w każdym po kilku testerów. Testują oni różne aplikacje, mają własne zadania, cele (czy ambicje). A ponieważ systemy są od siebie zależne to pracują na tych samych środowiskach - dla ułatwienia przyjmijmy, że na jednym.

Pewnego pięknego poranka właśnie to środowisko postanowiło spaść z rowerka. Zaczyna sypać wyjątkami, aplikacje przestają odpowiadać a logi wyglądają jak losowy ciąg błędów bez początku i końca. Może skończyło się miejsce na dysku bo ktoś dodał właśnie o jeden załącznik za dużo, może usługa miała awarię, a może problem leży zupełnie gdzie indziej?

W optymistycznym scenariuszu ktoś szybko rozpozna problem, zgłosi ją odpowiedniemu zespołowi i wszyscy po krótkiej kawie wrócą do pracy. W mniej optymistycznym wariancie, połowa zespołów niezależnie zacznie zgłaszać problemy, kolejne 3 zakładać nowe defekty (exception to exception a jak piękne statystyki pójdą w góre!) a jeszcze jeden zespół zacznie wypisywać urlopy.

Ale spokojnie, na ratunek przychodzi firmowy system zgłoszeń! Rozbudowany, z kateoriami, statusami, priorytetami i pięknym dashboardem. Przełożeni widzą ile zgłoszeń zostało założonych, ile czasu zajeła ich obsługa, kolejny kierownik kierownika oglada te same rzeczy na jeszcze ładniejszym, animowanym w czasie rzeczywistym wykresie. Tylko że tester chce wiedzieć 3 rzeczy: czy ktoś to już zgłosił? Czy ktoś na to patrzy? Ile to mniej więcej zajmie?

I okazuje się, że uzyskanie tych informacji nie jest takie proste jak być powinno. System nie pokazuje aktualnych awarii, które nie są przypisane. Zgłoszenie to kolejnych 10 formularzy, no i treba wiedzieć do kogo przypisać, czyli zrobić inwestygacje… w kodzie lub na środowisku… Więc co się robi? Wysyła się maila, dzwoni, albo pisze do znajomego na komunikatorze i czeka. Niby jest czas na kawe, można nadrobić zaległości w dokumentacji i plotkach ale terminy się nie przesuną a nadgodziny mimo wszystko nie wyglądają aż tak kusząco.

Krzysiek i Władzio maja dość

Krzysiek i Władzio, na co dzień testerzy z krwi i kości, tacy co to w swoim zespole biedronek mają opinie tyraczy uznają, że tak dalej być nie może. Siadają więc, zagadują krzemowego diabła i szybko tworzą niewielką aplikację, która umożliwia zgłaszanie awariu. Nie zgadniecie, wysyłając automatycznie maile na podstawie prostego formularza. I jeszcze pozwala sprawdzić status zgłoszenia w jednej tabeli! Rewolucja w postaci prostoty! Nagle coś co wymagało przejścia przez 10 formularzy i 2 cyrografy zajmuje 2 minuty, co prawda mailem ale biedronki są zachwycone. Krzysiek i Władzio też. Więc… problem rozwiązany?

Historia lubi się powtarzać

Tym razem w zespole pszczółek. Monia dochodzi do podobnego wniosku co chłopaki i tworzy własną aplikacje. Pszczółki również świętują. Ilość maili zwiększa się. Programiści widząc kolejki mailowe, również stwierdzają że przekopywanie się przez pocztę jest ‘no ten no… bez sensu szefie’ i prezentują swoją aplikację. Z pięknym, złotym pluginem który… kopiuje maile do aplikacji i tam szybciutko sobie procesują - wszak chłopaki wiedzą co robią prawda?

I zanim ktokolwiek krzyknie ‘optymalizacja procesu’ mamy piętnaście skryptów, 6 aplikacji i 2 pluginy rozwiązujące różne fragmenty tego samego problemu jednocześnie generując kolejne niedogodności (kto nigdy nie przekopywał się przez 50 wiadomości w których jest się tylko w cc niech pierwszy rzuci kamieniem). Co najlepsze, wszystkie te rozwiązania mogą być całkiem dobre. Każdy zespół rozwiązał przecież swój problem i realnie pracuje szybciej.

Tylko że organizacja właśnie stworzyła sobie problem globalny, rozwiązując kilkanaście problemów lokalnych.

Shadow software, czyli coś co jest, no chyba że idzie audyt

To generalnie zjawisko wpisujące się w szerszy problem znany jako shadow IT. Chodzi o technologie wykorzystywane w organizacji poza oficjalnymi kanałami. Prywatne usługi, narzędzia, arkusze czy właśnie aplikacje, które mają usprawniać pracę. Bo Krzysiek i Władzio nie napisali aplikacji, żeby zaszkodzić firmie. Wręcz przeciwnie. Chcieli wykonać swoją pracę szybciej i sprawniej. Problem pojawił się w momencie, kiedy firma nie potrafiła dostrzec lokalnych problemów. Bo kto teraz aktualizuje taką aplikację? Zaryzkujmy przejście do momentu kiedy obaj panowie zmienią firmy. Znając życie powstanie kolejna aplikacja, a ponieważ każda potwora znajdzie swojego lubego to część osób stwierdzi ze ona na niej zostaje. Jak możecie się domyślać Krzysiek 2.0 napisał jeszcze kolejną. I po kilku latach skąd właściwie wiadomo gdzie jest aktualny status? Tymczasem oficjalny system nadal działa. Dashboard jest zielony, raporty się zgadzają tyle że… jakby nagle wolniej, więcej maili jest słanych a na pytanie o status zapada cisza i spradzanie kilku aplikacji w tle…

Tyle opini ile ludzi a nasza aplikacja jest najlepsza bo jest nasza

W końcu ktoś zauważa problem. Wpada na całkiem rozsądny pomysł - skoro potrzebujemy podobnych funkcjonalności to może zróbmy jedno rozwiązanie? I tutaj odpinamy wrotki. Biedronki mają swoją aplikacje, która jest szybka i prosta. Pszczółki rownież mają swoją, ich zdaiem lepszą. Programiści kategorycznie żądają dostępu do morza… wróć, przejścia na ich rozwiązanie a admini mają narzędzie z dostępem do danych technicznych z których absolutnie nikt poza nimi nie korzysta.

Każdy ma argumenty, każdy ma trochę racji. Bo przez ostatnie miesiące dostosowywali rozwiązanie pod siebie. Ujednolicenie narzędzi przestaje więc już być problemem technicznym a staje się organizacyjnym. Trzeba zdiagnozować potrzeby, pogodzić czasem sprzeczne wizje, zdiagnozować co jest potrzebne a co jest tylko ułatwieniem dla 3 osób i pogodzić się z tym, że część rozwiązań trzeba zaorać ku lepszemu (wspólnemu) dobru.

Czyli jedna to znaczy, że lepsza?

No nie zawsze. Nie chodzi przecież o budowanie kombajnu do wszystkiego. Czasem kilka wyspecjalizowanych, dobrze zintegrowanych narzędzi ma więcej sensu niż korpo-bydle. Zamiast jednej aplikacji za wszelką cene powinniśmy zbudować jeden spójny proces i wiarygodne źródło prawdy. Balans pomiędzy innowacją, użytecznością a ryzykiem.

Jasne, czyli wina menedżerów bo chcieli tabelki

No bo oni dostali co potrzebowali, testerzy nie, więc musieli zacząć pisać swoje aplikacje. A Ci biedni programiści dostali rykosztem. Koniec historii. Tyle, że samo raportowanie nie jest problemem. Dane w taki czy inny sposób są potrzebne i będa zbierane, choćby do planowania. Problem zaczął się wtedy, kiedy potrzeby osób oglądających raporty był stale ważniejsze od potrzeb osób które dane do tych raportów generowały.

Ile kosztowało stworzneie tych aplikacji? Ile czasu poświęcono na ich utrzymanie, integrację czy synchronizację? Ile razy dwa zespoły niezależnie rozwiązały dokładnie ten sam problem? Tych kosztów nie zobaczymy na wykresach. A przecież to również jest czas i pieniądze. I nie chodzi o to, że należy kogoś z tych kosztów rozliczać. Tylko czemu nie mielibyśmy tych środków przekierować jeśli nie na nowe rzeczy to na uczynienie pracy… wygodniejszej?

Co więc zrobić? Zacząć od przyjrzenia się rzeczywistej pracy, a nie tylko raportom. Zignorujmy na chwilę procedury, tak pięknie, tak idealnie opisujące to jak pracujemy i popatrzmy na żywy organizm. Bo może się okazać, że ten organizm zamiast galopować majestatycznie powiewając grzywą biegnie niczym szaleniec zakosami unikając dziur na jezdni. Znajdźmy ‘stałe odstępstwa’ od procedur i sprawdźmy skąd się one biorą. Nie chodzi o zakazanie pracownikom usprawniania swojej pracy. Bo zakaz nie powoduje, że potrzeba nagle znika.

Dlaczego o tym piszę? Bo w QA doskonale znamy sytuacje, w których oficjalny proces wygląda świetnie na papierze, ale codzienna praca wymaga kreatywności, cierpliwości i kilku dodatkowych narzędzi, o których najlepiej nie wspominać podczas audytu. Możemy dalej pisać kolejne aplikacje, pluginy i skrypty, które będą łatały niedoskonałości firmowych systemów. Możemy też spróbować czegoś trudniejszego: spojrzeć na cały proces, przyznać, że pewne decyzje nie były najlepsze i zacząć naprawiać przyczyny zamiast objawów. I wiecie co? To też jest dbanie o jakość.

A jeśli i ty drogi kierowniku jakimś cudem to czytasz to pamiętaj, jeśli zespół będzie miał jak pracować to nawet najbrzydsze wykresy będą szły w góre i w prawo a testy świeciły na zielono nawet w najgorszy dzień. A wszystkim, którzy próbują taką zmianę przeprowadzić, życzę powodzenia. Bo przekonanie piętnastu zespołów do wspólnego rozwiązania może być trudniejsze niż napisanie szesnastej aplikacji. Tylko że tej szesnastej naprawdę już nie potrzebujemy.