W ciągu ostatnich kilku miesięcy współpracowałem z doświadczonym psychologiem klinicznym i zespołem badawczym posiadającym stopień doktora, w tym psychologiem i akademickim naukowcem zajmującym się behawioryzmem, aby zrozumieć, co odróżnia zespoły osiągające najlepsze wyniki od tych, które mają trudności. Badania pokazują, że 81% decydentów biznesowych w Wielkiej Brytanii i 89% w USA jest zaniepokojonych… terminowa dostawa projektów oprogramowania w swoich organizacjach.
Pracę tę przeprowadzono w kontekście, w którym branża zazwyczaj skupiała się na ulepszaniu procesu testowania oprogramowania, będącego jednym z późniejszych etapów cyklu życia oprogramowania, w celu rozwiązania tych problemów. Ponadto wiele firm coraz częściej zwraca się ku badaniu wskaźników dotyczących sposobu pisania samego oprogramowania, aby spróbować ulepszyć proces inżynierii oprogramowania.
Wyzwania wydają się jednak jeszcze głębiej zakorzenione niż w przypadku pisania lub testowania kodu.
Kiedy pisałem moją ostatnią książkę, Jak chronić się przed zabójczymi komputerami, Przyjrzałem się szczegółowo szeregowi katastrofalnych awarii oprogramowania, w tym wpadnięciu samolotu w „nurkowanie śmiercionośne”, śmiertelnym wypadkom samochodowym i zabójczemu przedawkowaniu promieniowania w szpitalach. Książka opisuje jak czynniki psychologiczne pomagają nam zrozumieć, dlaczego błędy w oprogramowaniu powodują kulę śnieżną, która prowadzi do katastrofalnych awarii komputerów. Jednak alarmującym, powracającym tematem w wielu studiach przypadków jest to, że pierwotną techniczną przyczyną wielu problemów były problemy z projektowaniem oprogramowania, a w rzeczywistości brak solidnego projektu.
To podejście oparte na wymaganiach zostało sformalizowane w dokumencie Manifest Agile’aobecnie ponad 23-letni, który opowiadał się za podejściem do projektowania oprogramowania skupionym wokół „reagowania na zmiany zamiast podążania za planem”.
W firmie badawczej JL Partners zapytałem 600 inżynierów oprogramowania w Wielkiej Brytanii i USA o udane i nieudane projekty rozwoju oprogramowania, nad którymi pracowali. Nasze badanie wykazało, że w przypadku projektów oprogramowania, których rozwój rozpoczął się przed jasnymi wymaganiami, gdzie nie istniał kompletny dokument specyfikacji i gdzie znaczące zmiany nastąpiły na późniejszym etapie, projekty kończyły się niepowodzeniem w 65% przypadków.
Zidentyfikowaliśmy jednak tylko pięć praktyk inżynieryjnych, które zmniejszyły wskaźnik awaryjności do 10%. Posiadanie jasnych wymagań przed rozpoczęciem samodzielnego programowania zwiększało szansę powodzenia projektów o 97%, a inżynierowie, którzy mieli swobodę omawiania i rozwiązywania problemów, zwiększyli wskaźnik powodzenia o 87%. Inne praktyki obejmowały: zapewnienie zgodności wymagań z rzeczywistym problemem (54%); posiadanie pełnej specyfikacji przed rozpoczęciem programowania (50%) i unikanie późnych zmian wymagań (7%). Łącznie nazywamy te praktyki tzw Inżynieria uderzeniowa.
Co ciekawe, nie znaleźliśmy statystycznie istotnej różnicy między osobami pracującymi nad wieloma projektami jednocześnie a osobami pracującymi tylko nad jednym na raz, mimo że ograniczenie liczby prac w toku jest kluczowym założeniem rozwiązań takich jak tworzenie oprogramowania Lean. To pokazuje, jak należy zająć się zagrożeniami w projektach oprogramowania na wczesnym etapie.
Niepokojące było to, że największa różnica w praktykach inżynieryjnych między Wielką Brytanią a USA polegała na tym, że inżynierowie oprogramowania w Wielkiej Brytanii mieli o 13% mniejsze poczucie, że mogą omawiać problemy i rozwiązywać je niż inżynierowie w USA. Dzieje się tak pomimo liczne badania przeprowadzone przeze mnie i inne osoby, łącznie z niniejszym badaniem, podkreślające fundamentalne znaczenie bezpieczeństwa psychicznego dla powodzenia systemów komputerowych.
Podczas naszego badania sprawdziliśmy także, dlaczego inicjatywy transformacyjne kończą się niepowodzeniem. Pomimo obietnic, jakie niosą ze sobą metodologie transformacji, nadal widzimy, że 70% transformacji cyfrowych i 96% transformacji zwinnych kończy się niepowodzeniem. Nawet wśród wszystkich firm, niezależnie od branży, kiedy firma wchodzi do administracji w Anglii i Walii (tj. syndyk przejmuje kontrolę), tylko 10% firm przetrwa pomimo zmiany zarządu.
Nasze badania wykazały, że fundamentalne czynniki psychologiczne odgrywają decydującą rolę w powodzeniu lub niepowodzeniu takich transformacji. Wykazano to w badaniach przeprowadzonych przez EY (Ernst & Young) i szkołę biznesu Uniwersytetu Oksfordzkiego, które wykazały, że liderzy, dla których priorytetem są emocje pracowników, mają o 260% większe szanse na sukces w transformacji cyfrowej.
Podobnie jak w przypadku pocieszania płaczącego dziecka, przed zajęciem się rzeczywistym problemem należy poświęcić mu uwagę emocjonalną. Ważne jest również, aby podczas transformacji organizacyjnych nie pominąć czynników emocjonalnych.
Podobnych wniosków dokonał psycholog David DeSteno, który odkrył, że samo odczuwanie przez uczestników badania emocji wdzięczności ponad dwukrotnie zwiększało ich zdolność do opóźniania gratyfikacji w tej chwili w celu uzyskania większej nagrody później.
Dzięki takim badaniom opracowaliśmy ramy psychologiczne umożliwiające ludziom osiągnięcie znaczących przemian osobistych i organizacyjnych. Techniki te zostały przedstawione w mojej nowej książce pt. Inżynieria wpływu: transformacja wykraczająca poza zwinne zarządzanie projektamiw którym opisano jego zastosowanie w studiach przypadków ze świata rzeczywistego, wraz z opisem podstaw naukowych tych ustaleń.
Chciałbym jednak podkreślić, że niezwykle ważne jest, aby nie nadużywać tych badań zmusić innych do zmiany kiedy nie chcą. W wielu przypadkach zwolennicy transformacji nie okazywali należytego szacunku absolutnej konieczności uzyskania zgody, zarówno w przypadku osób fizycznych, jak i organizacji.
Pomijając kwestie moralne, pozbawienie kogoś możliwości uczenia się na własnych błędach pozbawia go ważnego źródła nauki, z którego może skorzystać (w zakresie, w jakim wyraził świadomą zgodę na popełnianie tych błędów i nie stwarza całkowitego ryzyka dla innych) ).
Dodatkowo, jak pokazały nasze badania nad zwinnością, ci, którzy mają największe przekonanie do swoich pomysłów, mogą się mylić, do sytuacji powinniśmy podchodzić z otwartym umysłem, niezależnie od tego, jak bardzo jesteśmy przekonani o swojej racji.
Niemniej jednak, upewniając się, że problemy są dobrze zdefiniowane, zanim zaczniemy szukać rozwiązań, i projektując rozwiązania, zanim zaczniemy je wdrażać, jesteśmy w stanie poprawić powodzenie naszych projektów oprogramowania. Podobnie, dbając o zaspokojenie potrzeb emocjonalnych i rozwiązywanie problemów, jesteśmy w stanie zapewnić sukces inicjatyw transformacyjnych.
Dr Junade Ali CEng FIET jest doświadczonym technologiem zainteresowanym zarządzaniem inżynierią oprogramowania, badaniami nad bezpieczeństwem komputerów i systemami rozproszonymi.