Moje pierwsze doświadczenia z IT wydawały się obiecujące. Była połowa poprzedniej dekady, a ja trafiłem do zespołu, który zarządzał jedną z aplikacji. Zarządzał w sensie biznesowym. Koleżanka, która uczyła mnie fachu, zajmowała się wymyślaniem, co ta aplikacja miała robić i zgłaszaniem błędów, gdy tego nie robiła. Przy okazji oczywiście tej aplikacji zwyczajnie używała na swoje służbowe potrzeby. A niedługo potem odeszła z pracy.
Wpadłem, jak śliwka w kompot. Po pół roku pracy spadły na mnie jej dotychczasowe obowiązki. Na całe szczęście przez te pół roku wdrożyłem się całkiem nieźle. Dziś uważam, że to głównie dzięki temu, że były to czasy, gdy nikt nie wyobrażał sobie jeszcze pracy zdalnej w skali większej, niż raz, czy dwa dni w miesiącu, a i to w drodze wyjątku. Opanowałem więc meandry biznesu i wiele zakamarków aplikacji.
Moim pierwszym zadaniem było opracowanie wymagań funkcjonalnych na potrzeby rozwoju tego naszego małego systemu. Teraz mogę to tak ładnie nazwać, “opracowanie wymagań funkcjonalnych”, a to była w gruncie rzeczy prozaiczna sprawa. Było parę groszy na rozwój i albo je wydamy, albo nie, a wtedy nie w kolejnym roku nie dostaniemy grosza. Siedziałem nad tym pewnie kwartał i w efekcie spisałem bez mała 20 stron. Opisałem dosyć szczegółowo, w jaki sposób system powinien realizować kilka dodatkowych procesów, lub co należy zmienić w tych, co realizuje dotychczas.
A później mój szef pokazał mi, jak wyglądały listy wymagań spisywane na potrzeby wcześniejszych zamówień. Trochę się różniły. Wcześniej wymagania były spisywane w postaci jednostronicowej listy punktów w stylu “chcemy, żeby system obsługiwał zgłoszenia windykacyjne”. Tymczasem te same zgłoszenia windykacyjne ja opisałem w postaci całej strony, albo i dwóch.
To nie były opisy przypadków użycia, tak jak niektórzy mogą sobie wyobrażać. A wcześniej to nie były historyjki użytkownika. Wtedy, w tamtej organizacji nie mieliśmy pojęcia ani o jednym, ani o drugim. Listę wymagań, długą lub krótką, otrzymywał wykonawca, który miał zrobić magię i dokonać wyceny.
Różnica pomiędzy wcześniejszymi i moimi wymaganiami ostatecznie sprowadzała się do czasu. Ile czasu musiało minąć od momentu dostarczenia wykonawcy listy wymagań, do czasu przygotowania przez niego wyceny. Moja, dosyć szczegółowa specyfikacja zaowocowała jednym spotkaniem z wykonawcą na potrzeby doprecyzowania kilku detali lub zaproponowaniu alternatywnego rozwiązania. W przypadku wcześniejszych zamówień takich spotkań na linii biznes-wykonawca było blisko dziesięciu, a rolą biznesu było przedstawienie szczegółów, które wykonawcy pozwolą na zrozumienie potrzeb i prawidłową implementację.
I pewnie nic by to, gdybyśmy byli stricte analitykami i nasza praca się do tego sprowadzała. Tymczasem my mieliśmy swoją robotę do wykonania, a współpraca z wykonawcą była tylko jednym z obowiązków.
Jak już nasz wykonawca wiedział, co ma zrobić, przystępował do szacowania kosztów. Później następował kilkuetapowy proces negocjacji, wykonawca mówił, dlaczego tak drogo, a my pytaliśmy, dlaczego tak drogo. Gdy już się udało podpisać umowę, wykonawca wziął się do roboty, a ja się dowiedziałem, że efekty swoich pomysłów zobaczę… za jakiś rok.
COOOOOOOOOOOO?!?!
Nasz świat i nasze otoczenie nie działa tak wolno, żebyśmy mogli rok czekać na wdrożenie kilku nowych funkcjonalności. A co, jeśli w międzyczasie okaże się, że coś w tym projekcie trzeba zmienić? Albo przestanie być potrzebne? Albo zamiast jednej funkcjonalności będziemy potrzebować czegoś innego?
I nie zgadniecie. Wszystkie a co się spełniły. Wtedy wjeżdża na stół aneks, CR, czy jeszcze coś innego, robi się kolejną wycenę, ponosi koszty, zmienia harmonogram, a dotychczasowe pracy, w razie potrzeby, odsuwa w czasie.
No więc musiałem czekać trochę dłużej, niż rok. A jak już się doczekałem, to okazało się, że to nie koniec! Jak już dostałem ten nowy kawałek systemu, to musiałem go przetestować i sprawdzić, czy program faktycznie działa tak, jak powinien. Nie działał. Seria poprawek i przepychanek doprowadziła do tego, że jak odchodziłem z pracy blisko dwa lata później, to projekt wciąż nie był ukończony.
Chyba w każdym podręczniku do zarządzania projektami (lub szerzej na temat inżynierii oprogramowania) znajdziemy opis terminu kryzys oprogramowania. W różnych podręcznikach datuje się go na lata 70. lub 80. XX wieku. Ów kryzys oprogramowania objawiał się zarzucaniem 30% uruchamianych projektów, a w kolejnych 50% znacznym przekroczeniem kosztów, czasu lub niespełnieniu oczekiwań użytkowników. W pierwszej połowie lat 90. opublikowany został manifest agile.
W połowie poprzedniej dekady jeszcze miałem niewielkie pojęcie o tym, że można projekty prowadzić inaczej. Co ja w ogóle wiedziałem o prowadzeniu projektów? Intuicyjnie czułem, że to nie może być tak, że czas od wymyślenia funkcji do zobaczenia, jak ona działa, wynosi co najmniej półtora roku. To nie mogło tylko mi przeszkadzać. To jakiś absurd.
Z czasem się przekonałem, że niejedyny. Ale o kolejnych przeczytacie kiedy indziej. Ja w każdym razie zrozumiałem, czym się chcę zawodowo zajmować.
Photo by Artem Beliaikin on Unsplash
Jeśli czegoś Ci tutaj brakuje, napisz w komentarzu. Dzięki Tobie będę mógł pisać bardziej interesujące teksty!