Geneza metodologii a ich wdrażanie we współczesnym IT. O korzeniach metodologii w posttransformacyjnej rzeczywistości.

Epidemia COVID-19 i spowodowany przez nią przewrót w gospodarce bezbłędnie zweryfikowały dumnie brzmiące hasła o byciu fair w biznesie. Niestety, w wielu przypadkach firmy, kreujące się na te, które zawsze grają czysto, które dbają o swoich pracowników i organizują szumne akcje pod hasłem społecznej odpowiedzialności biznesu, w czasie kryzysu nie dały rady sprostać swoim ideom. Poniżej podzielę się z wami moimi przemyśleniami na temat etycznej działalności, tego czym jest i czy słusznie mówi się o niej częściej w kontekście dużych korporacji niż małych i średnich przedsiębiorstw. Tym jakże nostalgicznym wstępem chciałbym przybliżyć odrobinę historii, ale nie tej z Wikipedii, gdzie wyczytasz, że Agile powstał w 2001, tylko tej, w której nikt o nim jeszcze wtedy nie słyszał. Także nie tej, w której DevOps miał swój początek w 2009 roku, a tej, w której istniał, zanim otrzymał tę nazwę. Nie chciałbym się jednak skupiać na krytyce formalizowania organicznie powstałych metodologii oraz metodyk czy też dywagować na temat skuteczności różnych popularnych transformacji, ale tego chciałbym się skupić na oddolnych korzeniach tego, co w 2021 roku powszechnie uważa się za złote standardy pracy w IT, oraz pokazać, dlaczego warto do nich wrócić. Lekcji do wyciągnięcia z ewolucji procesów tworzenia oprogramowania jest więcej niż mogłoby się na pierwszy rzut oka wydawać.

Podstawy genezy współczesnych metodologii

Zacznijmy zatem od omówienia podstaw genezy wszelkich metodyk i metodologii. Nie powstają one przecież na papierze, lecz zostają na nim z biegiem czasu sformalizowane. Skąd zatem biorą się te pomysły? Dawno temu, gdy zaczynałem pracę jako programista, mówiło się o dobrych praktykach programowania, testowania, designu – innymi słowy: utrzymywania jakości w poszczególnych aspektach produktów cyfrowych. Nie mówiło się za to praktycznie wcale o praktykach optymalizacji wydajności. Z dzisiejszej perspektywy może to wydawać się wręcz dziwne, ale sytuacja taka miała bardzo konkretne przyczyny, które chciałbym teraz wyliczyć.

Oddolne korzenie

Po pierwsze, cytując pewnego znanego polityka, była to najzwyczajniej „oczywista oczywistość”, wliczona w codzienność pracy zespołu, ponieważ w tamtych czasach budżety były dużo skromniejsze, a klienci dużo bardziej wymagający lub wręcz roszczeniowi. Każdy freelancer nie raz usłyszał wtedy od klienta, że jak nie wprowadzi zmian spoza umowy, to klient mu nie zapłaci. Niestety, prawo często nie nadąża za technologią, a sądownictwo działa bardzo powolnie, więc takie ekstremalne sytuacje musiały być wliczone w koszty funkcjonowania firmy. Tym samym wymuszały one optymalizacje wydajnościowe lub (częściej niż rzadziej) czasowe. Programiści pracujący w tak sztywnych ramach projektowo-czasowych, w połączeniu z niską dostępnością, jak na współczesne standardy gotowych do wdrożenia rozwiązań automatyzacyjnych czy optymalizacyjnych, często musieli sami pisać skrypty czy dedykowane narzędzia, aby ułatwić i/lub przyspieszyć swoją pracę. Zdolność oraz chęć do takiej metodyki pracy była wymiernym parametrem odróżniającym dobry programistów od tych przeciętnych lub wręcz słabych.

Wymagania projektowe

Po drugie: nie wykształciła się jeszcze warstwa managerów średniego stopnia, która z jednej strony rozmywała odpowiedzialność oraz metryki wydajności, a z drugiej, co za chwilę omówimy szerzej, utrudniała pracę osobom technicznym. Często na firmę składał się tylko właściciel, pozyskujący zlecenia, oraz zespół deweloperski, który – według dzisiejszej nomenklatury – wypadałoby nazwać cross-funkcyjnym. Nie był on taki na skutek rozporządzenia czy polityki firmy, tylko dlatego, że tego wymagały projekty. Każdy członek zespołu odpowiadał za pewne części składowe całego procesu tak, że często raptem kilkuosobowy zespół ogarniał wszystkie etapy rozwoju oprogramowania. Od administrowania serwerem lub serwerami, poprzez architekturę, projektowanie grafiki czy interfejsów, programowanie, testowanie, bazy danych, wdrożenie na produkcję, wsparcie techniczne oraz wiele innych. Geneza takiego stanu rzeczy była oddolna i naturalna. Zespół ukształtował się tak, aby zaspokoić wszystkie wymagania, a nie dlatego że firma przeszła transformację DevOpsową w celu optymalizacji wydajności. To samo tyczy się początków popularnego aktualnie Agile’a, u którego podstaw leży iteracyjny rozwój oprogramowania, czyli prototypowanie. Praktyka budowy prototypów nie jest niczym nowym, ponieważ, kierując się zdrowym rozsądkiem, wstępne sprawdzenie pomysłu poprzedzające pełną inwestycję brzmi jak najbardziej logicznie. Nie inaczej było w przypadku projektów IT. W nowym świecie wschodzącej technologii oraz Internetu klienci często nie wiedzieli, czego tak naprawdę chcą, dopóki nie zobaczyli jakiejś namacalnej propozycji. Nie rzadko też sam zespół deweloperski lub programista potrzebował wstępnie zweryfikować sens czy wykonalność danego rozwiązania. Tak więc i ta praktyka wytworzyła się organicznie w celu zaspokojenia konkretnych potrzeb projektowych, a nie została odgórnie narzucona oraz wdrożona. Mógłbym w ten sposób zilustrować jeszcze kilka innych przykładów, ale wszystkie będą się sprowadzać do zaspokajania jednej podstawowej potrzeby – dbałości o jakość. Może się to wydawać ogromnym skokiem logicznym lub uproszczeniem, tak więc przeanalizujmy głębiej ten temat. Jeżeli projekt ma określony kontraktem budżet, to jakie skutki będzie miało zainwestowanie czasu pracy zespołu na budowę funkcjonalności, która nie spełni wymagań klienta oraz zostanie przez niego odrzucona lub sam zespół stwierdzi, że rozwiązanie to nie spełnia wymagań projektu? Stracony czas to jedno, ale właśnie wytworzyliśmy także źródło ogromnej presji, ponieważ teraz może nam zabraknąć czasu na dostarczenie pełnowartościowego produktu, a co za tym idzie, obniżoną jego jakość. Nawet w przed-Agile’owym świecie iteracyjny rozwój oprogramowania był wdrażany naturalnie z powodu wewnętrznych i oddolnych potrzeb projektowych, w celu optymalizacji procesów wytwarzania produktów cyfrowych. Tak samo Waterfall miał swoje uzasadnienie w bardzo wysokich kosztach, czasochłonności oraz idącej za tym potrzebie minimalizowania wykonywanej pracy.

Paradoks transformacji

Mając na uwadze powyższe, jakże paradoksalnym można nazwać fakt, iż współcześnie wdraża się te oddolnie wytworzone metodologie w sposób odgórnie narzucany z kompletnym pominięciem wszystkich ich przyczyn środowiskowych, które doprowadziły do ich powstania. Tym samym nie rozwiązuje się faktycznych problemów, lecz na ślepo przykleja plaster, licząc na to, że zatamuje odpływ traconej efektywności, zamykając błędne koło współczesnych transformacji. Proste i oczywiste mogłoby się wydawać prawidłowe podejście do tego złożonego tematu. Wystarczy przeanalizować problemy organizacyjne oraz technologiczne u ich podstaw, wysłuchać feedbacku pracowników, po czym procesem analitycznym dojść do konstruktywnych wniosków. Skonsultować je, wydedukować rozwiązania lub optymalizacje po czym metodologia pracy zespołów dokona samooptymalizacji do bardziej sprzyjających warunków pracy. Niestety, bardzo często tylko tak się wydaje, ponieważ jest to wyjątkowo utrudnione w dużych firmach oraz korporacjach, posiadających rozrośniętą warstwę zarządzającą średniego stopnia. W takich organizacja jest cała rzesza ludzi w teorii odpowiadających za jakość oraz wydajność, co w kontekście wcześniej omówionej problematyki może wydawać się absurdalne. Jeżeli jakość wynika z oddolnej kultury pracy, a wydajność jest efektem poniekąd ubocznym tego procesu, to jaki wkład może w niego mieć ktoś kompletnie oderwany od codziennej rzeczywistości projektowej? W mojej opinii znikomy – już uzasadniam dlaczego. O ile osoba taka mogłaby mieć pozytywny wpływ na jakość dostarczanego produktu poprzez oddziaływanie na problemy wynikające z charakterystyki strukturalnej danej organizacji, to ze względu na brak jej bezpośredniego zaangażowania w czynności projektowe, eliminuje to jakąkolwiek możliwość ingerencji w poziom jakości. To zespół wykonuje faktyczną pracę, a osoba postronna może mieć co najwyżej wpływ na warunki, w jakich on operuje. Jeżeli weźmiemy pod uwagę wcześniej omówioną wewnętrzną potrzebę dbałości o jakość w odpowiedniej kulturze pracy, to jedyna możliwa interakcja pomiędzy osobą „z zewnątrz” a projektem ogranicza się do warstwy organizacyjnej. Kompletnie już upraszczając: osoba ta mogłaby jedynie rozwiązywać problemy w związku z samym istnieniem struktury organizacyjnej, zawierającej jej rolę, co prowadzi do paradoksu, którego nie da się rozwiązać bez zmiany tej struktury tak, aby priorytetyzowała jakość oraz faktyczne potrzeby projektowe. Odnosząc się do popularnego nie tylko w branży IT powiedzenia „nie po to zatrudnia się ekspertów, żeby im mówić, jak mają pracować”: niestety, w praktyce polityka często wygrywa z jakością, a sektor technologiczny cierpi z powodu bardzo wysokiego punktu wejścia na poziom merytorycznej dyskusji. No i tutaj napotykamy podstawowy problem współczesnego rozwoju oprogramowania, który prawdopodobnie występuje też w innych wysokospecjalizowanych branżach.

Archetyp menadżera

Zarządzanie pracownikami wyżej wykwalifikowanymi w różnych dziedzinach. Każdy chyba czytelnik, nawet laik, jest w stanie zrozumieć następujące porównanie. Mechanik pracujący w warsztacie ma naprawić samochód. Jego szef, samemu nie będąc mechanikiem, jest w stanie odróżnić działający samochód od zepsutego (oczywiście upraszczam tutaj złożoność mechaniki pojazdowej celem zwięzłości). Tym samym przełożony mechanika jest w stanie ocenić efekt pracy mechanika bez jednoczesnego zrozumienia procesu naprawczego, którego skutki obserwuje. Przenosząc ten ciąg logiczny na proces rozwoju oprogramowania – osoba zarządzająca jest w stanie ocenić, czy dany produkt spełnia jej/jego lub klienta wymagania. Nie jest w stanie natomiast ocenić procesu jego wytwarzania. Niby oczywiste, a jednak w zdecydowanej większości przypadków rzeczywistość wygląda inaczej. Nie będę tutaj przytaczał niezliczonej ilości przykładów, ale pozwolę sobie przytoczyć pewien schemat zachowania, któremu ulega znaczna część nietechnicznych osób, zarządzających wyspecjalizowanymi pracownikami. Schemat ten jest bardzo prosty i sprowadza się do dwóch czynników: ego oraz poczucia władzy, które wynikają z archetypu menedżera jako jednostki nadrzędnej. Niczym władca feudalny nad chłopem pańszczyźnianym menedżer po studiach podyplomowych z całym portfolio referencji nie może przecież uznać wyższości kwalifikacyjnej programisty, który tak naprawdę może nie mieć skończonych studiów czy nawet zdanej matury. Zdaję sobie sprawę z być może nawet krzywdzącego uogólnienia w powyższych stwierdzeniach, nie mniej jednak wiele osób pracujących w IT wie, że ten stereotyp nie powstał znikąd i znajduje swoje uzasadnienie w codziennej rzeczywistości.

Wpływ

Następnie chciałbym nawiązać do wcześniej omawianego znikomego wpływu, jaki jednostka zarządzająca ma na faktyczny proces dostarczania oprogramowania. Skoro wspomniany wpływ jest z założenia znikomy, a menedżer może mieć niemerytoryczne pobudki do ingerencji w metodologie rozwoju oprogramowania, to prawdopodobne jest, że ten wpływ może być nie tylko niewielki, ale wręcz negatywny. W celu lekkiego usprawiedliwienia nietechnicznych menedżerów warto zaznaczyć, że ich proces logiczny jest jak najbardziej prawidłowy. Jeżeli ktoś reklamuje, że dana metodologia podnosi wydajność, to jedynym sensownym wnioskiem może być jej wdrożenie. Niestety, na tym logika się kończy, ponieważ najczęściej osoba decydująca o danej transformacji nie jest w stanie ocenić złożoności zadania, przed którym stoi. Dlatego też odgórnie wprowadzane transformacje w zdecydowanej większości nie przynoszą spodziewanych rezultatów. Mam tutaj na myśli te oczekiwane przez warstwę zarządzającą, pragnącą podniesienia wydajności. Z perspektywy zespołów projektowych skutki są, oczywiście, zgodne z przewidywanymi. To zburzenie organicznie wypracowanego statusu quo, skutkujące mniejszym lub większym chaosem, zmianami proceduralnymi oraz strukturalnymi, no i koniec końców – obniżoną wydajnością. Czyli faktyczny skutek transformacji jest kompletnym przeciwieństwem tego założonego. Można by to uznać za odważne stwierdzenie, biorąc pod uwagę aktualny boom transformacyjny oraz zatrważającą popularność poszczególnych metodyk czy metodologii, takich jak Agile czy DevOps, ale skupmy się na faktach, które są następujące. Na tę chwilę nie zostały opublikowane żadne empiryczne dowody na skuteczność takich transformacji, a powód takiego stanu rzeczy jest banalny. Transformację na taką skalę przeprowadza się zazwyczaj tylko w organizacji o wysokim poziomie złożoności struktur organizacyjnych, zawierających wspomnianą warstwę zarządzającą, w których – z racji ich rozmiaru – nie da się wskazać na miarodajne metryki. Nie sposób też udowodnić, że jakiekolwiek pozytywne zmiany, wynikające z transformacji, są jej efektem, a nie skutkiem ubocznym zmian – chociażby personalnych w czasie jej trwania. Chciałbym zaznaczyć, że nie mówię tutaj o efektywności poszczególnych metodologii, a tylko o rezultatach ich wdrażania bez wystarczająco dogłębnej analizy optymalizowanego procesu rozwoju oprogramowania, przy jednoczesnym ignorowaniu oddolnych potrzeb, wynikających z faktycznych problemów procesowych, technologicznych lub organizacyjnych.

Podsumowując: chciałbym napisać, że zdaję sobie sprawę, że na omawiany temat można spokojnie napisać książkę, a nie tylko skromny artykuł, ale mam nadzieję, że jego lektura zachęci do przetarcia oczu ze współczesnych naleciałości. Do zobaczenia rzeczy takimi, jakimi są w rzeczywistości, a nie tylko na papierze. Do przeanalizowania istotnych procesów wytwarzania produktów cyfrowych od podstaw, a nie przez pryzmat wszechobecnych, lecz powierzchownych sloganów. To z kolei prowadzi do swoistego powrotu do oddolnych, organicznych korzeni współczesnego IT wraz z jednoczesnym przesunięciem uwagi w kierunku jakości – tak, aby wydajność była jej skutkiem, a nie hipotetycznym wyznacznikiem.