Przerwa od relacji z konferencji. Ostatnio miałem okazję popracować z kolegą programistą nad pewnym projektem, w którym dużą uwagę trzeba było przyłożyć do wymagań, jak również potencjalnych powodów z których przedsięwzięcia IT nie kończą się sukcesem. Kilka dni po zakończeniu mojego wkładu we wcześniej wymienioną pracę, w trakcie rozmowy z innym kolegą, temat zszedł w rejony zarządzania projektami, tworzenia wymagań i rozmów z klientami dotyczącymi ich potrzeb. Przypadek? Nie sądzę…
Legacy Code …
Pragnienie ludzi do posiadania nowych możliwości w starych gadżetach nie jest niczym nadzwyczajnym. Ten fakt o naturze człowieka nie ulega zmianie w świecie programów, aplikacji webowych i systemów informatycznych. Przykład: jest sobie firma X z sektora ubezpieczeń, posiadająca napisany 10-20 lat temu system, którego używa do przechowywania danych o wszystkich swoich klientach, wspomagania podejmowania konkretnych decyzji, szacowania zdefiniowanego ryzyka, czy generowania sprecyzowanych raportów. Wszystkie te dobrodziejstwa powstawały w przeszłości, a architektura systemu w mniejszym lub większym stopniu była projektowana pod realizację tych funkcjonalności.
Dzisiaj firma X pragnie rozszerzyć możliwości swojego systemu o generowanie nowego typu raportu (RODO?). Analitycy/Handlowcy ruszają w bój, aby zdobyć kontrakt. W IT wszystko jest możliwie, programowanie to niemal magia. Należy przy tym pamiętać, że wszystko ma swoją cenę. W pewnych okolicznościach nakład potrzebnej do wykonania pracy, nie jest wart nowej opcji, czy zautomatyzowania fragmentu procesu biznesowego. We wszystkich pozostałych, ilość zasobów potrzebnych na nową funkcjonalność nie została właściwie oszacowana.
… Condemns Devs to …
Jednak Analitycy/Handlowcy pospolicie ruszyli już zdobyć trofeum. Nic ich nie zatrzyma, nie ma odwrotu, reakcja łańcuchowa została rozpoczęta. Żaden Analityk/Handlowiec nie zawaha się oddać życia (developerów) żeby zdobyć to, po co przyszedł. Z powodów bardziej prawdziwych t.j.: brak specjalistycznej wiedzy nt. systemu klienta, brak konsultacji z programistami obu interesariuszy, jak również rozmów z użytkownikami końcowymi nowego raportu – może się zdarzyć, że zostanie podpisana umowa na realizację sprawozdania. W wymaganiach: dostępne na stronie www, za pomocą jednego kliknięcia w pojedynczą kontrolkę, generowane każdorazowo w czasie nie dłuższym niż 5 sekund -> zestawienie roczne 😉
… The Query From Hell
Wymagania do projektu już są, więc programiści zaczynają pracę. „Szkoda”, że system klienta to „zwykła” baza danych. Wiele wody w Wiśle nie upłynie nim ujawnią się pierwsze przeciwności losu. Wyzwania jakim prawdopodobnie trzeba będzie stawić czoło to np. dodanie nowej kolumny w tabeli o milionach rekordów i setkach kolumn, rozwiązanie kwestii zawartości nowego pola w stosunku do rekordów już tam istniejących, czy próba zaprojektowania nowej tabeli i zaimportowania do niej części danych w celu przyśpieszenia zapytań bazodanowych… i wiele… wiele innych.
Projekt dojrzewa, programiści pracują po 50-60h tygodniowo żeby „dowieźć”, przekopali w tym czasie 3/4 StackOverflow i w końcu się udaje. Protokół zawierający dane z pożądanego zakresu, przedstawiony w jasny i oczekiwany przez klienta sposób, na wyciągnięcie palca wskazującego. Nawet generuje się w wymaganym czasie. Nowy fragment systemu zostaje oddany do akceptacji, klient przyjmuje, zapłata spływa, strony otwierają szampana – koniec historii.
Niestety nie koniec… Funkcjonalność trafia do użytkowników końcowych na produkcji. Czas mija, danych przybywa, a tabele puchną. Zapytania, które na akceptacji wykonywały się w czasie zgodnym z wymaganiami, już nie osiągają takich wyników – a czasy będą jedynie rosnąć. Klient jest niezadowolony, bo nie taki produkt kupił, nie za to zapłacił. Kwestię utrzymania takiego potwora pozwolę sobie przemilczeć.
Koniec bajki
Powyższa historia jest zmyśloną interpretacją opowieści programisty, bazującej na prawdziwych wydarzeniach. Teraz nadszedł czas skończyć bujać w obłokach i wrócić na ziemię.
Wpis ma na celu zwrócenie uwagi na okoliczności, z powodu których, w roku 2017 projekty kończyły się niepowodzeniem. Zawarte tu treści bazować będą m.in. na corocznie wydawanym raporcie Pulse of the Profession. Jest to globalne badanie stanu zarządzania projektami, udostępniające szereg statystyk z tej dziedziny. Wszystkich zainteresowanych odsyłam do materiału źródłowego.
Co mówią dane
Zgodnie z treścią wymienionego wcześniej raportu z roku 2017, 14% projektów zakończyło się zupełną porażką. Być może wydaje się to niewielkim odsetkiem, należy jednak mieć na uwadze, że 31% w chwili oddania nie posiadało założonych funkcjonalności, 43% przekroczyło zakładany budżet, 49% przekroczyło zaplanowane ramy czasowe. Wymienione procenty nie dają sumy 100% ponieważ dany projekt może przekroczyć czas wykonania oraz budżet, a pomimo to nie posiadać wszystkich wymaganych funkcjonalności. W badaniu zostały wymienione najczęstsze przyczyny niepowodzeń i to właśnie na nich chcę skupić Twoją uwagę.
Zmiany w priorytetach organizacji, niedokładne wymagania, częste modyfikacje wymagań, niejasna wizja lub różne wyobrażenia na temat gotowego produktu, problemy w komunikacji, nieodpowiednie zarządzanie zmianami, niedokładne szacowanie kosztów, brak analizy ryzyka oraz definicji szans, brak zaangażowania ze strony klienta – to dziewięć najczęściej wymienianych grzechów nieudanych projektów.
Zmiany priorytetów
Wiecie że 80% osób odpowiedzialnych za zarządzanie nie wie w jakim stopniu prowadzony przez nie projekt wpisuje się w strategię biznesową organizacji? Przedsięwzięcia w świecie IT, są najczęściej zaplanowane na lata, w trakcie trwania których, wiele może się wydarzyć na rynku. Im dalsza perspektywa, tym bardziej zamazany obraz przyszłości. Zmiany są czymś naturalnym i oczekiwanym w życiu. Tak samo sprawa wygląda ze strefami zainteresowania organizacji odpowiedzialnej za realizację. W pewnej chwili może się okazać, że dalsze prace nad oprogramowaniem są bezsensowne ze względu na znaczne obniżenie wartości biznesowej lub przeminięcie okna szansy na rynku docelowym. Dana inicjatywa zostanie wtedy zamknięta.
Jest to najczęściej wymieniana przyczyna niepowodzenia projektów. Moim zdaniem – nie do końca jest to prawda. Zmiany priorytetów organizacji są przyczynami zamykania projektów, lecz nie zawsze są to przyczyny bezpośrednie. Myślę, że częściej niż rzadziej taki obrót spraw jest wynikiem wystąpienia jednego, bądź kilku, z pozostałych grzechów.
Gwoździe, Trumny i Wymagania
Wysoce nieprawdopodobne jest stworzenie „czegoś” w określonym czasie i funduszach, co spełnia oczekiwania, robi dokładnie to, co klient chce i wszystkich uszczęśliwia, jeżeli nie są dostępne dokładne wymagania na podstawie których zespół wykonawczy może pracować. Wymagania często są gwoździem do trumny, gdy powstają w próżni, tworzone przez osoby pozbawione szerszej perspektywy na zakres problemu z powodu braku współpracy z zespołem developerskim.
Jak w takim razie stworzyć wymagania wysokiej jakości? Żeby zminimalizować znacząco ryzyko upadku projektu, należy w proces tworzenia wymagań zaangażować wszystkie „zainteresowane” strony, czyli specjalistów od biznesu, reprezentantów z IT (administratorzy, programiści, architekci) oraz użytkowników końcowych. Biznes odpowie na pytanie – co ma być zrobione, IT udzieli odpowiedzi na pytania – w jaki sposób można to zrealizować, a użytkownicy końcowi – kto i w jaki sposób będzie tego używał. Najważniejsze to zrozumieć kontekst i odnaleźć w tym sens.
Zwinność – czyli spektakularne akrobacje nad architekturą
Modyfikacje wymagań są standardem w świecie IT. Na sposób w jaki organizacje sobie z tym radzą powstał nawet termin: zwinność. Gdy wymagania nie zostaną należycie zdefiniowane w początkowej fazie, najważniejszą cechą zespołu odpowiedzialnego za realizację staje się zwinność. W porządku – trochę przesadzam. Pewna doza zmian pojawi się zawsze, a produkt powinien być w stanie się do tych zmian ugiąć.
Odnoszę jednak wrażenie, że bardzo często zmianą podlegają fundamentalne założenia systemów. „Fundamentalne” nie jest tu bynajmniej użyte przez przypadek. Klient chce dany produkt, który ma realizować funkcjonalność A – jest to tak podstawowa czynność w założonym modelu biznesowym, że na niej zbudowany zostaje cały system. Powiedźmy na miesiąc przed pierwszym terminem oddania, klient orzeka, że zastosowanie A powinno być opcjonalne dla użytkowników końcowych, a cały system powinien obsłużyć sytuację wykluczającą wykorzystanie tej opcji. W takiej chwili zespół realizujący projekt jest zmuszony do modyfikacji samego dna aplikacji. Dróg na skróty, fragmentów „na Jana” oraz pewnej dozy haków nie da się uniknąć – zaciąganie długu technicznego nie zna w takich chwilach granic. Na dobrą sprawę trzeba napisać drugi system. Następnie trzeba ten system utrzymać…
Remedium na opisaną sytuację, jest właściwa konstrukcja umowy pomiędzy stronami, określająca które wymagania są podstawami aplikacji i nie mogą ulec zmianie. Powinny one zostać zamrożone – niezmienne do zakończenia procesu realizacji aplikacji. Aby było to możliwe, potrzebne są wysokiej jakości wymagania. Świadomość, które wymagania gdy ulegną zmianie, spowodują zawalenie się architektury aplikacji.
W trosce o stabilność układu
Sposób w jaki gatunek ludzki się komunikuje jest wysoce niewydajny. Najgorszym faktem jest brak ujemnego sprzężenia zwrotnego. Ludzie mają w zwyczaju uznawać, że to, co chcieli przekazać zostało odebrane bez zniekształceń, dokładnie tak, jak chcieli być zrozumieni. Dodajmy do tego, że typowy człowiek zajmujący się programowaniem jest introwertykiem, a naszkicowany obraz na pewno przedstawiać będzie scenę pod tytułem: problemy w komunikacji. Dodatkiem do tego pejzażu niech będzie krótka i wybiórcza pamięć, o cechach której jej właściciel nie ma pojęcia. Mówiąc inaczej: nie zdaje sobie sprawy, że źle pamięta, to co pamięta.
Jeżeli osoby prowadzące projekt nie wezmą pod uwagę powyższych faktów i nie postarają się o minimalizowanie szkodliwych skutków, to prawdopodobnym jest, że wysokiej jakości wymagania zostaną przeczytane raz albo dwa i odłożone na półkę. Pod koniec realizacji aplikacji, zostaną ponownie odczytane w celu weryfikacji zgodności. Weryfikacja wykaże brak spójności między dokumentem a zrealizowanym produktem. Ot wybiórcza pamięć.
Dzieci we mgle
Jeżeli nie zostaną jasno sprecyzowane zakresy odpowiedzialności – możliwe, że projekt zostanie zalany błędami, pomyłkami i opóźnieniami wynikającymi z dezorientacji członków zespołu. To naturalne, że gdy widzimy zadanie, do którego nie zostaliśmy przypisani – wierzymy, że ktoś inny będzie zobligowany do jego realizacji. Gdy nie zostaną określone kryteria realizacji, to zadanie zostanie wykonane zgodnie z wizją wykonawcy. Nie zawsze będzie to wizja spójna z wyobrażeniem klienta bądź pozostałej części zespołu.
Programiści bardzo często nie są wstanie dostrzegać całości problemu, widzieć potencjalne przeszkody czy zdawać sobie sprawę z potrzeb w innych częściach projektu. Osoby tworzące kod potrafią godzinami rozmawiać o tym, czego wzajemnie od siebie potrzebują, nie wynosząc z poświęconego czasu wartości dodatniej. Pomimo długiej rozmowy, nie osiągają zrozumienia. Fragmenty kodu, powstałe specjalnie na potrzeby innych modułów nie nadają się do wykorzystania przez te moduły i muszą być wielokrotnie zmieniane.
Osoba odpowiedzialna za prowadzenie projektu, jako człowiek o wysokich zdolnościach komunikacyjnych oraz szerokiej perspektywie powinien wspierać osoby odpowiedzialne za tworzenie współpracujących ze sobą modułów w procesie dogadywania tejże współpracy. Tablica, rysunek, schemat oraz pseudokod również są narzędziami, po które warto sięgać. Wnioski oraz część materiałów powstałych w procesie powinna zostać utrwalona i zapisana.
Zrobią to! – zarządzanie zmianą
Wszystko jest dobrze, a te akapity są wartościowe jeżeli umowa nie została jeszcze podpisana. Co jednak zrobić, gdy kontrakt nie ogranicza możliwości klienta do zmiany wymagań? Być rozsądnym. Z mojego doświadczenia wynika, że zbyt często odpowiedzią osób mających kontakt z klientem oraz zbierających jego uwagi na temat przedsięwzięcia jest godzenie się na wszystkie zmiany. Tak bez mrugnięcia okiem czy próby negocjacji. Klient chce modyfikacji, to ją dostanie. Najwyżej zwiększymy ilość zasobów pracujących nad tym systemem. Jednak z prawa Brooksa wynika, że im więcej osób dołącza do pracy w późnej fazie projektu, tym bardziej zostanie on opóźniony.
Jak można radzić sobie ze zmianami, które zgłasza klient? Zawsze próbować negocjować, rozmawiać ze wszystkimi zainteresowanymi stronami – biznesem, programistami, użytkownikami końcowymi. Godzić się na zmiany – ale może w formie aneksów do kontraktu. Skoro zespół realizujący ma być skazany na pracę w nadgodzinach, to niech będzie z tego profit.
Szklana kula, czyli szacowanie
Czasem zastanawiam się w jaki sposób szacowane są ramy czasowe projektów oraz wynikające z nich koszty. Biorąc pod uwagę częstotliwość z jaką jestem pytany o przewidywany czas realizacji, gotów jestem uznać, że ma to związek z horoskopem, siłami wyższymi, przypadkiem lub wróżeniem z fusów. Oczywiście zdaje sobie sprawę z potęgi intuicji oraz znajomości historii poprzednich zadań i czasu ich realizacji. Mam jednak poczucie, że coś jest planowane w sposób nie właściwy.
Znaczne obcinanie kosztów aby wygrać przetarg. Estymowanie tych parametrów kontraktu bez udziału osób, które faktycznie będą kontrakt wykonywać. Szacunki dokonywane bez jasnego sprecyzowania zakresów prac, bez wyczerpującej ilości informacji czy wykonania analiz. Planowanie bez udokumentowania założeń oraz sprawdzenia ich podstaw. To wszystko jest strategią krótkowzroczną i niesie ze sobą ryzyko niedoszacowania.
Profesjonalnie „nie”
Programiści też mają tutaj swoje za uszami. Zbyt często dajemy się ugłaskać słowami „Ja w was wierzę”, „dacie radę” i „jak się postaracie to na pewno się uda” i godzimy się na wykonanie zadań, o których wiemy, że są prawie niewykonalne. Wynika to po części z tego, że każdy z nas pragnie zostać bohaterem – wybrańcem który uratował projekt. Niestety, rzeczywistość jest zupełnie inna. Nawet, jeżeli uda się zrealizować, z pozoru niewykonalne zadanie – to nic na programistę nie czeka na mecie. Projekt po prostu zostanie wykonany, a finał będzie bardzo zwyczajny. Za to poniesionych osobistych kosztów i oddanych pracodawcy godzin z życia nic nie zwróci.
Zachowujmy się profesjonalnie. Jeżeli dane zadanie w określonym zakresie jest niewykonalne, to słowo „nie” jest właściwe. Pamiętaj tylko, aby po „nie” nastąpiło wyjaśnienie dlaczego nie. Jeżeli jesteś w stanie ocenić, co Twoim zdaniem należało by zmienić, by realizacja stała się możliwa – to również tą informacją podziel się ze wszystkimi zainteresowanymi stronami.
Pragniesz dowiedzieć się więcej?
Katalog Katastrof
101 Najczęstszych przyczyn
9 przyczyn upadku projektu IT
Dlaczego projekty IT upadają
Dlaczego projekty IT upadają #2
Historia, którą opisałeś na początku przedstawia bardzo niedoświadczonego przedsiębiorcę oraz bardzo niedoświadczonego klienta, który nie był w stanie przetestować lub nie wymagał testów, które sprawdziły by skalowalność systemu. Jeśli tak jak mówisz, jest to jedna z częstszych przyczyn upadania projektów… jest to smutne, bo podstawowe założenie nie zostało wzięte pod uwagę już na starcie.
Wydaje mi się, że trochę niepoprawnie interpretujesz pracę w projektach „zwinnych”. Największą zaletą takich projektów jest możliwość adaptacji zmian do zmieniających się oczekiwań rynku. Projekty informatyczne są rozwijane przez lata, rynek nie stoi w miejscu, dlatego też zmieniają się wymagania.
Nawet najlepiej zdefiniowane wymagania będą odpowiadały sytuacji „na teraz”, klient sam nie wie czego będzie oczekiwał za powiedzmy rok.
Odnośnie szacowania kosztów i obniżania ceny żeby wygrać przetarg – wiele projektów jest właśnie w ten sposób tworzona, że samo wykonanie projektu jest niekorzystne, natomiast podpisywane są umowy na utrzymywanie systemów – i w ten sposób właśnie najwięcej zarabiają firmy informatyczne.