Problemy przy wytwarzaniu oprogramowania

Tworzenie oprogramowania to złożony i często ekscytujący proces, w którym programista powołuje do życia użyteczne systemy i aplikacje, w środowisku w którym bardzo często brakuje zasobów ludzkich, czasu lub niezbędnych wymagań i szczegółów dotyczących określonych przypadków użycia w projekcie. Natomiast na brak problemów zespoły developerskie narzekają z reguły rzadko, a wiele z tych utrudnień jest wspólna dla wszystkich firm IT. Sama wiedza o ich obecności nie jest jeszcze rozwiązaniem, ale buduje świadomość sytuacyjną w kontekście barier i przeszkód, które w ramach realizacji danego zadania są nieuniknione, a powinny być uwzględnione w procesach planowania i estymowania zadań.

Programowanie skupia się na rozwiązywaniu problemów, a postęp w dziedzinie języków i wszelkich narzędzi służących do wytwarzania oprogramowania usprawnia to zadanie. Jest to niezmiernie ważne zwłaszcza ze względu na to, że mamy do czynienia z konsekwentnym zwiększaniem się złożoności problemów technologicznych. Z kolei postęp metodologiczny na poziomie operacyjnym nie zapobiega powstawaniu meta problemów, które wychodzą poza ramy procesu wytwórczego realizowanego przez developerów.

Inflacja technologii

Mamy do dyspozycji dużo języków programowania oraz frameworków i bibliotek w ich obrębie, co z jednej strony daje nam bogatszą ofertę doboru narzędzi, a z drugiej utrudnia naukę programowania, planowanie rozwoju projektów, dbanie o kompatybilność między używanymi narzędziami i wybranymi ekosystemami. Początkujący programista staje przed dylematem jakich technologii powinien się nauczyć, a przeglądając oferty pracy wpada w jeszcze większy paraliż decyzyjny, bo przy różnorodnej gamie projektów IT okazuje, się że “wszystko” jest po części potrzebne.

Dla uporządkowania tego stanu rzeczy tworzone są rankingi języków uwzględniające różne czynniki. Jednak to rodzi przekonanie, że dana technologia stojąc o kilka miejsc wyżej nad inną jest od niej o rzędy wielkości lepsza pod kątem produktywności. Na przykład Python jest językiem interpretowanym, gdzie nie ma potrzeby kompilowania kodu — działa natychmiastowo. Dodatkowo nie wymaga określania typów zdefiniowanych zmiennych, co tylko przyspiesza proces developmentu.

A zatem według tej logiki powinniśmy powiedzieć, że Python jest lepszy niż C++. Jednak to niekoniecznie musi być prawda. Proces kompilacji i typowania pozwala na wyłapanie wielu błędów, które po dostaniu
się na środowisku produkcyjnym mogą być bardzo kosztowne. Dobór narzędzi musi być zatem dopasowany do priorytetowych potrzeb danego projektu, jednak czasem to dopasowanie będzie wiązało się z pewnym kompromisem. Sama technologia nie jest w stanie diametralnie zwiększyć produktywności, to co ją zwiększa to stopień biegłości w posługiwaniu się nią. To bardzo istotna kwestia w otoczeniu płodnych w nowości ekosystemów IT, które również dotykają chwilowe trendy i przesadny entuzjazm. Dlatego przed konwersją z jednego języka na drugi, albo dodaniem nowej biblioteki warto zadać sobie pytania:
– czy faktycznie jest to potrzebne?
– czy ułatwi to realizację postawionego celu, zarówno krótko jak i długoterminowo?
– jakie skutki uboczne może spowodować ta decyzja?

Postępująca specjalizacja

Wraz z rozwojem inżynierii oprogramowania stworzone zostały specjalizacje i podspecjalizacje w celu sprostania skali i złożoności tworzonych systemów. Ten proces zachodzi w całym świecie nauki i jest nieunikniony na pewnym etapie rozwoju. Podział na dziedziny, następnie na działy, potem na coraz węższe specjalności. Na początkowej fazie rozwoju motoryzacji wiele osób było w stanie samodzielnie naprawić samochód, teraz potrzebny jest ekspert, często zajmujący się
tylko określonymi markami. Kiedyś informatycy zajmowali się niemal wszystkim: serwerami, stronami internetowymi, bazami danych, hostingiem, sprzętem, naprawami hardware’u. Jednak z czasem powstało więcej warstw i dodatkowych podsystemów do obsługi, które wymagają odrębnych profesji. Jakiś czas temu programista webowy zajmował się tworzeniem aplikacji internetowych pisząc backend na przykład w PHP i SQL oraz frontend (HTML, CSS, JavaScript), jednocześnie potrafił skonfigurować serwery, proces deploymentu z uwzględnieniem kwestii cyberbezpieczeństwa. Obecnie mamy wydzielone osobne
profesje np. devops, backend i frontend developer. W obrębie frontendu natomiast powszechne są rozróżnienia na React, Angular lub Vue dewelopera — jako specjalistów od konkretnej biblioteki lub frameworka frontendowego.

Jest to naturalna kolei rzeczy, jednak rodzi pewne problemy. Poszczególne specjalności wykształciły odrębne terminologie, która zwiększają próg wejścia do nich, co prowadzi do coraz trudniejszego uchwycenia całości w trakcie procesu developmentu. To z kolei może prowadzić do istotnych błędów w przyjętych założeniach, sposobie danej implementacji lub do niechcianego wpływu na inne systemy. Jednak w większości przypadków na pewnym poziomie ogólności programiści reprezentujący inne zestawy umiejętności technicznych są w stanie znaleźć porozumienie i wypracować wspólne rozwiązania. Natomiast wychodząc szerzej i ścierając się z aspektem biznesowym, społecznym lub etycznym danego produktu IT, wówczas bardzo często ma miejsce brak zrozumienia lub nawet konflikt.

Konsekwencje takiego fragmentarycznego spojrzenia na wytwarzanie oprogramowania widać już w skali makro w postaci negatywnego wpływu aplikacji mediów społecznościowych, które jak wynika z najnowszych badań wspierają proces uzależnienia od danej platformy, aby zmaksymalizować zysk i zdolność do manipulowania poglądami, emocjami i zachowaniem ludzi. W taki sposób po latach pracy najlepszych inżynierów na świecie, ale nie wychodzących poza ramy swojej specjalizacji stworzono usługę, która ma ewidentny wpływ na zdrowie psychiczne użytkowników, w szczególności nastolatków, przekładając się dodatkowo na rosnące wskaźniki samobójstw w tej grupie wiekowej.

„To, co kodujesz, wpływa teraz na świat. Dawno minęły czasy, kiedy programiści mogli zignorować kontekst społeczny tego, co kodują, kiedy mogliśmy powiedzieć: “Użytkownicy po prostu to wszystko zrozumieją”.
Obecnie programy, aplikacje i algorytmy wpływają na społeczeństwo.
Wybory Facebooka wpływają na demokrację. To, w jaki sposób autonomiczne samochody będą decydować o unikaniu wypadków, wpłynie na ludzkie życie”.

Bruce Schneier, amerykański kryptograf i specjalista z zakresu cyberbezpieczeństwa

Brak nauki sprawdzonych rozwiązań

Edukacja programistyczna w zakresie wzorców projektowych, dobrych praktyk, architektury oraz algorytmów i struktur danych jest generalnie traktowana drugorzędnie lub stanowi wiedzę, która jest budowana na bazie praktyki po latach doświadczenia. Statystycznie najwięcej teorii obejmującej wymienione obszary w procesie nauki programowania otrzymują studenci uczelni wyższych. Podczas kursów online, bootcampów lub samoedukacji większy nacisk kładzie się na praktykę i umiejętność pracy z określonymi narzędziami, tak aby zdobyć operacyjną sprawność pozwalającą na zdobycie pracy i szybkie wdrożenie się w projekt. Pomijając ścieżkę edukacji, twórcy oprogramowania dzielą się na tych, którzy poważnie traktują teorię oraz takich, którzy całkowicie ją ignorują, tracąc tym samym dostęp do gotowych rozwiązań powtarzalnych problemów, próbując stworzyć koło na nowo. Jednocześnie jednak traktowanie tych narzędzi jako panaceum na wszystko również może doprowadzić do negatywnych konsekwencji. Dlatego tak jak z każdym narzędziem, jego użycie musi być poprzedzone odpowiednią analizą, która da informację zwrotną odnośnie adekwatności zastosowania.

Wraz ze zdobywanym doświadczeniem taka ocena staje się łatwiejsza i nie wymaga dokładnego bilansu potencjalnych zysków i strat, tylko bazuje na opinii specjalisty wypracowanej przez udział w podobnego typu projektach, zakończonych sukcesem lub porażką. Jednak nie w każdym projekcie mamy wystarczającą liczbę takich osób, a przepustowość podejmowanych decyzji przez danego eksperta również jest ograniczona, przez co jego uwadze mogą umknąć pewne niedopatrzenia.

Według badań społeczności IT przeprowadzonych przez portal bulldogjob.pl w 2022 roku tylko 35% ankietowanych (na próbie 7382 osób) posiadało seniorski lub wyższy poziom doświadczenia, a średnia wieku pracowników IT w Polsce wynosiła około 30 lat. Na bazie tych danych można wnioskować, że mamy do czynienia z relatywnie młodym sektorem, który dopiero zdobywa ekspertyzę. Wąskie gardło mentoringu programistycznego liczące nieco ponad jedną trzecią zasobów w zespołach deweloperskich staje się jeszcze mniej wydolne przez wadliwe procedury, problemy z komunikacją i presję czasu — trzy najczęściej wymieniane przeszkody w efektywnej pracy w firmach.

Ciężko spośród nich wybrać głównego winowajcę, jednak w istocie problem sprowadza się do planowania i koordynacji, ponieważ brak czasu na skuteczną realizację zadań jest najczęściej spowodowany słabym zarządzaniem procesami i komunikacją. Należałoby zatem usprawnić ten element, ale jeśli brakuje czasu to reorganizacja staje się niemożliwa i tak błędne koło się zamyka. Rozwiązanie wymaga odgórnych decyzji oraz oddolnego zaangażowania i inicjatywy, dlatego członkowie zespołu mogą zawsze wypracować lepszą formułę uczenia się i z pomocą decyzyjnych managerów ustanowić z niej nowy standard. Kwestia edukacji wewnątrz organizacji dotyczy jednak nie tylko zbioru dobrych praktyk i optymalnych paradygmatów programowania, ale również wiedzy domenowej i logiki biznesowej, która stanowi część projektu. Tutaj brak odpowiedniego wdrożenia i przekazania wiedzy skutkuje poznawaniem projektu
przez nowe osoby metodą prób i błędów, co prowadzi do tworzenia
nawarstwiającego się długu technologicznego.

Legacy code

Kod zależny od niewspieranej wersji systemu, języka, frameworka czy innego oprogramowania lub taki, który odziedziczyliśmy po innym zespole bez dokumentacji i testów, jest bardzo częstym środowiskiem w jakim pracuje programista. W magazynie IEEE Spectrum z 2020 roku podjęto się analizy przestarzałych systemów. Wskazano, że istnieje ogromna liczba sprzętu i oprogramowania, która nie jest już dłużej wspierana przez ich twórców lub zespoły zajmujące się utrzymaniem. Prowadzi to do awarii systemów, nieoczekiwanych błędów, podatności na ataki hakerskie lub chwilowe niedyspozycje. Jakkolwiek każdy jest w stanie obyć się tymczasowo bez aplikacji rozrywkowych, tak systemy bankowe, ubezpieczeniowe i publiczne usługi cyfrowe wymagają wysokiego poziomu
dostępności i bezpieczeństwa. Korporacje i państwa na całym świecie dbają o ten obszar inwestując od 2010 do 2020 roku 35 bilionów dolarów na produkty i usługi IT. 75% tej kwoty została wydana na zadania operacyjne i utrzymania istniejących systemów. Oszacowano również, że 2,5 biliona dolarów zostało wydane na zastąpienie legacy code nowymi rozwiązaniami, z czego 720 miliardów zmarnowano na nieudane próby
zastąpienia starych systemów.

Legacy code rozumiany również jako oprogramowanie, którego kod jest nieuporządkowany i napisany w niezrozumiały dla innych sposób, może powstać relatywnie szybko — w perspektywie miesięcy. Niezależnie od tego czy zostaną użyte najnowsze narzędzia, bo ostatecznie liczyć będzie się ich implementacja. Dlatego ponad pięcioletni system, może być tak samo trudny do utrzymania lub przepisania jak aplikacja napisana rok temu, do której tworzenia wkradła się niedbałość i brak wczesnej mitygacji ryzyk.

Dla programisty praca z przestarzałymi technologiami nie jest rozwojowa, a brak rzetelnej dokumentacji i przejrzystości systemu również nie wpływają pozytywnie na morale pracownika. Gdy dodamy do tego również wspomnianą już presję czasu i problemy organizacyjno-komunikacyjne powstaje idealny grunt pod decyzję odejścia z firmy. Taka rotacja w zespołach może przyczynić się w ten sposób do pogłębienia problemu odziedziczonego kodu słabszej jakości. Osoba opuszczająca projekt przez ostatnie dni swojej pracy w większości cechuje się mniejszą wydajnością i przywiązaniem do produktu, który tworzy i jest mentalnie już w nowej firmie.

Oczywiście nie stanowi to zasady i jest to kwestia indywidualnej etyki pracy i poczucia odpowiedzialności. Jednak decyzja o odejściu ze względu na aspekt rozwoju zawodowego, często znacząco zmniejsza motywację do wysoko jakościowej pracy do samego końca, przez co możliwe staje się tworzenie kolejnego niezrozumiałego kodu, nie posiadającego dokładnej specyfikacji i pokrycia testami, który zostanie przejęty przez nowych developerów. Jednocześnie dostępna na rynku edukacja programistyczna w formie prywatnej i publicznej nie przygotowywuje wystarczająco do pracy z problemami jakie generuje skomplikowany i niejasny kod, działając na sterylnych i statycznych przykładach, które nie odzwierciedlają wystarczająco realnej dynamiki zmian biznesowych.

Większość materiałów jest realizowana głównie na przykładach aplikacji tworzonych od zera lub w ograniczonym przewidywalnym kontekście. To prowadzi do braku umiejętności radzenia sobie w warunkach nieprzejrzystych i złożonych systemów, a w przypadku tzw. projektów greenfield — nowych, pisanych od zera — doprowadzi z czasem do stworzenia trudnego w utrzymaniu kodu. W związku z tym ta luka kompetencyjna sprawia, że problem może się jedynie nawarstwiać, jeśli nie stworzy się na niego rozwiązań w organizacjach i edukacji. Świadomość tego zjawiska to pierwszy krok w tym kierunku. Więcej dostępnego czasu na dokładniejszą analizę oraz posiadanie zestawu metod pracy z legacy code mogą przerwać cykl przekazywania niechcianego “dziedzictwa”.

Natomiast proces nie jest łatwy i pełen pułapek oraz błędów poznawczych, jak na przykład konserwatywne podejście do każdej zmiany, traktujące ją jako ryzyko. Poprzez minimalizację liczby wprowadzanych zmian, próbuje się zmniejszyć ilość potencjalnych problemów. Jednak czasem uciekając przed jednym zagrożeniem, można wpaść w drugie. Gdy w projekcie unika się tworzenia nowych klas i metod, wówczas istniejące stają się większe i mniej zrozumiałe. Dodatkowo zwlekanie z pewnymi zmianami prowadzi do powstawania wrażliwych miejsc, które będę jeszcze trudniejsze w modyfikacji w przyszłości. Tak samo odkładanie w czasie pisania dokumentacji tworzonego kodu może również zrodzić dodatkowe problemy w momencie konieczności przekazania jej nowym
programistom, innemu zespołowi lub firmie zewnętrznej, która podjęła właśnie współpracę w projekcie. Kumulowanie wiedzy i budowanie świadomości sytuacyjnej tylko w jednej lub kilku głowach daje złudne poczucie niezastępowalności, jednak wytwarzanie oprogramowania łączy interesy wielu grup, dlatego w tym obszarze powinien przyświecać szerszy kontekst i długoterminowy cel.

Kompetencyjna strefa komfortu

Skupienie się wyłącznie na swoich obowiązkach jest jednym ze sposobów radzenia sobie w zmiennym i złożonym środowisku. Wybór jednego aspektu projektu, który definiuje specjalizacja i praca nad tworzeniem, utrzymaniem i debugowaniem kodu. Jednak proces tworzenia kompleksowych rozwiązań jest owocem przecinania się
świata inżynierii, designu, wiedzy domenowej, psychologii użytkownika i biznesu, który jest ściśle powiązany ze społecznymi potrzebami danej grupy docelowej oraz makro ekonomicznymi wskaźnikami. W tym kontekście programista zmuszony jest do konfrontacji z obszarami, które wychodzą poza zakres jego kompetencji oraz komunikacji z grupami interesów, które mogą mieć czasem sprzeczne cele.

Dochodzi wtedy do forsowania jednego rozwiązania ponad drugie, tracąc przy tym wspólną wizję, do której dąży nie tylko zespół developerski, ale też wszystkie inne grupy zaangażowane w dany projekt. Wówczas skupienie tylko na jednym obszarze zaburza ocenę użyteczności rozważanego rozwiązania jako całości. To z kolei może objawiać się w postaci trudniejszego osiągnięcia konsensusu pomiędzy programistami w momencie podejmowania kluczowych decyzji architektonicznych. A także w nie skutecznej komunikacji ze stroną biznesową, poprzez ograniczoną empatię i zamknięcie się w kompetencyjnej strefie komfortu. To przekłada się na mniejsze zaufanie między zespołami i działami lub na linii poszczególnych jednostek, co wprowadza do organizacji pewnego rodzaju atomizację, gdzie każdy dba jedynie o swoje interesy, wpływając przy tym negatywnie na przepływ informacji i decyzji.

Ten problem jest bezpośrednio powiązany z postępującą specjalizacją, jednak jakkolwiek tworzenie nowych szczegółowych profesji wynika z rozwoju technologicznego, tak nieodpowiedni sposób komunikacji i percepcji odpowiedzialności w tych warunkach, może przejawiać się już jako społeczny regres. Problem przerzucany na inny zespół, może za jakiś czas wrócić w innej formie, dlatego postrzeganie własnej pracy tylko wycinkowo, adekwatnie do wąskiej specjalizacji jest krótkowzroczną perspektywą, budującą przekonanie, że inni ludzie są samolubni i leniwi.
A to stanowi impuls do rozwoju wirusa cynizmu w firmie, którego efektem będzie toksyczna atmosfera, wypalenie zawodowe i związane z tym
straty finansowe. Postrzeganie tworzonego produktu całościowo i branie
odpowiedzialności nie jest absolutną regułą i rozwiązaniem tego problemu, ponieważ również wymaga zdrowych granic. Nikt nie lubi nadmiernej ingerencji w swoje kompetencje i wymyślania koła od nowa, co może mieć miejsce w przypadku wypaczonej implementacji postawy wychodzenia poza obszar swojej ekspertyzy. Dlatego problem ten jest zidentyfikowany jako zamknięcie się lub ambiwalencja co do wpływu na pozostałe systemy i współpracowników. Rozwiązanie tej kwestii wymaga m.in. otwartości, empatii i szerszej perspektywy, przekładające się na skuteczniejsze podejście w planowaniu i rozwoju oprogramowania.

Wskazana nieefektywność jest związana z jednym z błędów poznawczych, efektem skupienia. Jest to nieracjonalny sposób postrzegania rzeczywistości polegający na przywiązywaniu zbyt dużej wagi do jednego szczegółu, co zaburza całościową ocenę sytuacji. Uwaga kierowana jest wtedy na najbardziej znane i oczywiste dla danej osoby aspekty, ignorując przy tym pozostałe opcje. Amerykański ekspert w zakresie architektury oprogramowania Matt Stine, w swoich publikacjach omawia problematykę upierania się przy nie adekwatnych rozwiązaniach, omawiając przykład mikroserwisów — rodzaju architektury aplikacji, tworzącej zbiór niezależnych modułów, posiadających osobne odpowiedzialności.

Rozwiązuje ona problemy utrzymania, skalowalności oraz kosztów. Jednak
zafiksowanie się na tej metodologii organizacji przepływu danych również może doprowadzić do większych problemów, niż te, które chcieliśmy poprzez to narzędzie zmitygować. Jedną z sytuacji omawianych przez Matt’a jest zbyt duża liczba mikroserwisów. Zespół, który nieodpowiednio skonstruował model danych i granulację serwisów może doprowadzić do potrzeby tworzenia kilku mikroserwisów niemal każdego tygodnia, aby podtrzymać tempo rozwoju aplikacji. Przez co narzędzie, które miało przynieść korzyści, zaczyna być coraz trudniejsze w zarządzaniu, a jego opłacalność zaczyna być wątpliwa. W wielu przypadkach architektura mikroserwisowa nie jest rekomendowanym środkiem do osiągania programistycznych celów. Jednak poprzez przyzwyczajenie do znanego sposobu działania opartego na danej metodologii lub technologii, tworzy się tendencja do grawitowania w tym kierunku, która niekoniecznie może być dopasowana do realiów nowych wymagań biznesowych. Osadzanie się na swojej pozycji kompetencyjnej jest przejawem krótkowzroczności i wąskowzroczności, które stanowią ogromne ryzyko w świecie VUCA (zmiennym, niepewnym, złożonym, niejednoznacznym).

Problemy z estymacją

Przybliżone określanie czasu potrzebnego na wykonanie zadania jest niezbędną czynnością w procesie planowania projektu i zarządzania budżetem. Strona biznesowa chce mieć konkretną informację, która pozwoli na oszacowanie opłacalności przedsięwzięcia, a zespół dostarczający dane rozwiązanie, również potrzebuje nanieść na linię czasu swój plan realizacji. Wszystkie zaangażowane strony potrzebują jakiejś formy przewidywania przebiegu przyszłych działań, jednak metody stosowane w tym celu przynoszą często więcej kłopotów niż korzyści. Z
danych prezentowanych przez Allena Holuba, architekta oprogramowania, autora książek IT i konsultanta procesów agile (metodyki zwinne), wynika, że średnio 80% estymacji jest nietrafiona. Niestety nie wiąże się to z wykonaniem zadań przed założonym czasem, tylko znacząco po nim.

Jak trudne jest to zadanie można uświadomić sobie na przykładzie szacowania czasu w dość statycznych warunkach jakimi są domowa kuchnia i cel jakim jest przygotowanie obiadu. Zakładając, że struganie pierwszych 5 ziemniaków zajmuje 4 minuty, to struganie pozostałych 15 powinno zająć 12 minut. Jednak wystarczy, że pozostałe ziemniaki będą mniejsze, większe, bardziej zdeformowane albo częściowo lub w całości popsute w stosunku do tych z pierwszej sprawdzonej próby, aby nasza estymacja zmieniła się z 12 do 16 minut. Pytanie również czy resztę pracy wykona tak samo doświadczona osoba, czy może ktoś kto robi to pierwszy raz? Wówczas nasza estymacja tym bardziej oddala się od tej pierwszej bazującej na przeszłości. A mówimy przecież o trywialnym zadaniu, jednak przesunięcie w szacunkach może mieć miejsce już o kilkanaście a nawet kilkadziesiąt procent od rzeczywistego czasu. Jak więc zatem możemy rzetelnie wyestymować złożone zadania na które wpływ ma wiele osób,
wymagania mogą w trakcie zostać zmienione, a osoby realizujące projekt opuszczą go w trakcie? A to tylko kilka z podstawowych zmiennych, które możemy napotkać.

Dodatkowo programiści podają estymaty i nie są ich pewni, natomiast osoby egzekwujące od nas tych estymat traktują je poważnie i na ich bazie tworzą symulację zwrotu z inwestycji czasu pracy. Programiści chcą tworzyć szybko wartość, żeby sprostać obiecanym wycenom czasu realizacji. Jednak działając szybko tworzą bałagan w kodzie i pomijają aspekty, które zabezpieczyłyby przed tworzeniem trudnego w utrzymaniu oprogramowania. Jest to widoczne szczególnie w początkowych fazach nowego projektu, ponieważ budując od zera, tempo tworzenia funkcjonalności jest zwykle bardzo duże. W pierwszych dniach, tygodniach, a nawet miesiącach możliwa jest realizacja w ustalonym czasie deklarowanych krótkoterminowych celów. Jednak wraz z rozbudową, zwiększoną złożonością i nawarstwiającymi się zaniedbaniami czas developmentu będzie dramatycznie wzrastał. Szybkie zaspokajanie potrzeb biznesowych pod presją obiecanych terminów, ale kosztem dbałości o architekturę, czysty kod i komunikację w zespole doprowadza do stworzenia omawianego wcześniej legacy code, z którym praca staja się coraz trudniejsza i coraz bardziej frustrująca.

“Nadmierne lub nieracjonalne harmonogramy są prawdopodobnie najbardziej destrukcyjnym wpływem na całe oprogramowanie”.
Capers Jones, amerykański specjalista w zakresie metodologii inżynierii
oprogramowania

„Presja terminów jest największym wrogiem inżynierii oprogramowania”
Scott Costello, inżynier oprogramowania, autor książek IT

Niedoszacowanie czasu prowadzi również do problemów organizacyjnych, ponieważ gdy projekt otrzymuje status “spóźniony” podejmowane są działania naprawcze w formie większej ilości spotkań mających za zadanie przywrócić projekt na właściwe tory. Ciągłe reestymacje, aby uzyskać aktualny obraz tego ile zajmie dostarczenie założonej wartości. Spotkania z managementem, klientami, użytkownikami tworzonego produktu lub innymi interesariuszami w celu wyjaśnienia opóźnień i planowania akcji korygujących proces wytwarzania oprogramowania. Czasami to pomaga, pozwalając na lepszą priorytetyzację i uzyskanie przestrzeni na reorganizację zaniedbanych obszarów lub mitygację nie dostrzeżonych wcześniej ryzyk. Jednak równie dobrze efektem takich spotkań może być jeszcze większa presja czasu i dezorganizacja.

Przeszacowanie okresów pracy może być równie destruktywne. Długi horyzont czasowy może okazać się odstraszający pod kątem finansowym dla osób decyzyjnych, przez co dany projekt zostanie przekazany w inne ręce lub zawieszony. Innym ryzykiem jest mechanizm nieefektywnego wykorzystywania nadmiernego czasu i zwlekania z konstruktywnymi działaniami. Wynegocjowany bufor czasowy daje iluzję spokoju co do wyrobienia się w terminie z pracami, co często kończy się bezproduktywnym wyczerpaniem większości dostępnego czasu, po czym zespół spieszy się z ukończeniem w taki sam sposób jak w przypadku gdzie od początku estymacja była zaniżona.
W celu rozwiązania tego problemu powstają nowe podejścia do zarządzania czasu i narzędzia pozwalające na lepsze monitorowanie progresu oraz projekcję przyszłości. Jednak dystrybucja tych rozwiązań nie przebiega łatwo, ponieważ jest po części związana z mentalnością i kulturą panującą w firmach.

Ego Driven Development

Tam gdzie ludzie tam też konflikty i nieporozumienia. To truizm, jednak
konsekwencje problemów personalnych potrafią rozbić zespoły i całe projekty. Ciemna strona czynnika ludzkiego dotyka każdą branżę, natomiast przejawy są inne. W świecie programowania gdzie głównym produktem pracy jest kod, to relacja z nim może przejawiać destrukcyjne wzorce. Poprzez zintegrowanie tożsamości twórcy z jego dziełem, potencjalne zmiany i krytyka będą brane osobiście, co może
powodować forsowanie nieadekwatnych rozwiązań. To tylko jeden z przykładów całej puli błędów poznawczych i wariacji społecznych dynamik w zespołach.

Problem ten sprowadza się często do braku zrozumienia interesu organizacji i szerszego kontekstu zmian. Pierwszym krokiem w kierunku poprawy tego stanu rzeczy jest przyjęcie postawy cechującej się pokorą, pozwalającą wyjść za ograniczające ramy ego. Podobną tezę po latach doświadczenia w projektach IT stawia Matt Stine, w książce o wymownym tytule “Rozwój oparty na pokorze. Praktykowanie ponadczasowej mądrości programowania bez ego”. Dobre praktyki, wzorce projektowe i nowoczesne narzędzia nie wniosą nic wartościowego jeśli nie trafią na grunt dojrzałej kultury organizacyjnej.

Kształtowanie postaw wymaga czasu i systematyczności, w przeciwieństwie do pobrania w kilka sekund nowej wtyczki automatyzującej pracę, obejrzenia kilku godzin video kursu czy odbycia kilkudniowego szkolenia. Budowa zdrowego i efektywnego środowiska pracy wydaje się czasem być niewidoczna i trudno mierzalna w przeciwieństwie do statystyk jakie można otrzymać za pomocą odpowiednich metryk systemu informatycznego. Problem ludzkiego ego w pracy z technologią przejawia się głównie jako krótkowzroczność skupiona na jak najszybszej gratyfikacji oraz jako wąska perspektywa, która nie pozwala dostrzec innych okazji lub ryzyk. Taki sposób myślenia rzutuje potem na projektowanie oprogramowania i podejmowane decyzje, dlatego obszar psychiki i kultury zespołu jest meta poziomem kształtującym jakość tworzonych produktów IT. Zaniedbania na tej płaszczyźnie będą podminowywać decyzje zarówno strategiczne jak i operacyjne.

Próby kształtowania zdrowych postaw w przypadku niepowodzenia mogą niestety wpaść w pułapkę cynizmu, w którym cały proces zostanie uznany za próbę wykorzystania pracowników wyłącznie w interesie firmy, a wszelkie aktywności kultywujące określone wartości zostaną zignorowane. Cynizm, obojętność i bezradność wkradają się do organizacji poprzez poszczególne jednostki o domyślnie cynicznym usposobieniu oraz poprzez wprowadzanie polityk i procedur, które motywują do realizacji potrzeb jednej strony kosztem drugiej. Jakkolwiek proces rekrutacyjny jest w stanie częściowo zabezpieczyć zespoły przed włączeniem do firmy takich osób, to jednak destrukcyjne cechy mogą pojawić się pod wpływem nieodpowiedniego zarządzania. Dlatego w tym przypadku główny ciężar leży po stronie osób kierowniczych oraz liderów projektów, jako osób najbardziej wpływowych. Zmienność i złożoność problemów w rzeczywistości VUCA nie ułatwia rozwiązania tego problemu, a dane pokazują, że postawa nacechowana sceptycyzmem i ograniczonym zaufaniem jest dominująca w społeczeństwie.

W badaniach Barometru Zaufania Edelmana z 2022 r. prawie 60% ankietowanych w 27 krajach stwierdziło, że ich domyślnym nastawieniem jest brak zaufania do innych ludzi. Tak samo plasuje się zaufanie do przywódców politycznych, instytucji i korporacji. Jednocześnie mamy również dostęp do danych o skutkach takiej postawy, a są nimi mniejsze zarobki, większe ryzyko depresji i chorób serca wśród cyników.

Do takiego stanu może doprowadzić również „kultura geniuszu” kultywowana w wielu firmach, która ceni kreatywną jednostkę, generującą nowe pomysły ponad kolektywną inteligencję samoorganizującego się zespołu, przez co gloryfikacja poszczególnych osób kosztem reszty demotywuje zespół lub stanowi źródło nie zdrowej konkurencji. A gdy pracownicy są nastawieni na współzawodnictwo, wówczas mają niewiele powodów, aby wnosić wkład we wspólne pomysły i ogólną kooperację. Występuje również większa skłonność do ukrywania wiedzy przed rówieśnikami, która może dać przewagę w wyścigu, gdzie zwycięzca bierze wszystko. To w konsekwencji niszczy relacje i uniemożliwia powstawanie innowacji.

Identyfikacja problemów i odpowienia ich definicja to podobno połowa sukcesu, drugą połówką zostaną poświęcone kolejne wpisy.