Monika Perendyk Oszczędzaj! Zaciskaj pasa! Idzie kryzys! A potem… „Już jest kryzys, musimy oszczędzać”. Brzmi znajomo? W ostatnich latach te hasła powtarzają się jak mantrę. W efekcie firmy ograniczają zatrudnienie, zmniejszają budżety, a najczęściej – tną koszty projektów. Bo przecież rozwijać się trzeba, ale jak najtaniej.
I tu pojawia się klasyczny zgrzyt:
🟧 Klient chce usprawnienia, które przyniesie oszczędności.
🟧 Jednocześnie nie chce inwestować w projekt, bo budżet ledwo zipie.
Więc szuka cięć. I najczęściej zaczyna od tego, co wydaje się najmniej namacalne – od analizy.
Tniemy koszty – i co z tego mamy?
Wyobraź sobie, że idziesz do najlepszego krawca w mieście.
Chcesz uszyć garnitur na miarę.
Tylko że:
❌ Nie pozwalasz się wymierzyć.
❌ Podajesz wymiary z poprzedniego garnituru.
❌ Skracasz spodnie na oko.
❌ Doradzasz się znajomych zamiast fachowca.
A potem odbierasz zamówienie… i zamiast eleganckich spodni dostajesz szorty.
Co poszło nie tak? Brak zaufania do specjalisty. Ignorowanie procesu. Chęć szybkiej „optymalizacji”, która skończyła się katastrofą.
Tak samo wygląda cięcie kosztów w projektach IT.
Bez analizy możesz skończyć z produktem, który spełnia „jakieś” wymagania. Tylko że nie te, które powinien.
Brak analizy w projekcie – pozorna oszczędność
Analityk często jest traktowany jak zbędny koszt.
Bo przecież „to tylko dokumentacja”.
Tyle że dokument analityczny to coś więcej niż zbiór notatek czy diagramów.
To instrukcja obsługi Twojego produktu.
Bez niej:
❌ Programista pisze po omacku.
❌ Tester nie wie, czego się czepiać.
❌ Klient nie dostaje tego, czego chciał.
A później zaczyna się gaszenie pożarów.
Przykłady z życia? Proszę bardzo:
🚨 2011 rok – nowe motocykle dla policji
Policjanci z czterech największych miast Polski dostali nowoczesny sprzęt, który miał usprawnić komunikację z centralą.
Efekt? Totalna klapa.
Nikt nie zauważył, że motocykle wyposażono w system analogowy, podczas gdy cała centrala działała już w systemie cyfrowym.
Brak analizy i niedoprecyzowanie wymagań skończyły się koniecznością kosztownych poprawek, a sprzęt długo nie nadawał się do użytku.
🚨 2002 rok – system kontroli lotów w Swanwick
Projekt zarządzania ruchem lotniczym nad Anglią i Walią miał kosztować 35 milionów funtów.
Finalnie pochłonął… 623 miliony.
A do tego został ukończony z 6-letnim opóźnieniem.
Dlaczego?
Bo poprawki, które miały umożliwić działanie systemu, wprowadzano dopiero podczas… szkolenia personelu.
Analiza była, ale niedokładna. A konsekwencje tej bylejakości ciągnęły się latami.
To nie są odosobnione przypadki.
Gdy rezygnujesz z analizy lub traktujesz ją jak formalność, licz się z tym, że:
🔹 projekt będzie droższy,
🔹 wdrożenie się opóźni,
🔹 jakość końcowego rozwiązania poleci.
Osoby decyzyjne często myślą, że skracając etap analizy, oszczędzą czas i budżet.
Tylko że to działa jak skracanie nogawek u krawca – efekt końcowy może już nie przypominać tego, co było zamawiane.
Pokaż mi swój dokument, a powiem Ci, czy projekt się uda
Co decyduje o sukcesie projektu?
Możesz mieć świetnych ludzi, ogromny budżet i najlepsze technologie.
A i tak wszystko może rozbić się o… dokumentację.
Dlaczego?
Bo dla każdej osoby w projekcie „dobry dokument” znaczy coś innego:
🔹 Klient chce widzieć, że opisano wszystkie jego potrzeby biznesowe.
🔹 Analityk liczy, że spisał pełne wymagania funkcjonalne.
🔹 Programista potrzebuje dokładnych wymagań niefunkcjonalnych.
🔹 Tester sprawdza, czy funkcjonalności mają komplet scenariuszy.
Problem w tym, że każdy widzi „swoją część słonia”.
Jak w bajce o niewidomych, którzy dotykali różnych fragmentów i opisali go zupełnie inaczej:
– „Słoń jest jak drzewo” (bo złapał za nogę),
– „Nie, jak sznur” (bo trzymał ogon),
– „Jak mur” (bo dotknął boku).
I choć każdy miał rację, nikt nie widział całości.
Dokładnie tak samo jest z dokumentacją analityczną.
Jeśli patrzysz tylko na fragment, projekt wymyka się spod kontroli.
Jak ocenić, czy dokumentacja ma sens?
Wystarczy spojrzeć na nią przez pryzmat sprawdzonych kryteriów.
7 cech dobrej dokumentacji:
ℹ️Poprawna – zgodna z prawem, standardami i logiką projektu.
ℹ️Jednoznaczna – zrozumiała tak samo dla każdej osoby w projekcie.
ℹ️Kompletna – zawiera pełen zakres funkcji, także w scenariuszach wyjątkowych.
ℹ️Spójna – bez sprzecznych zapisów i luk logicznych.
ℹ️Uporządkowana wg ważności – pokazuje priorytety funkcji i potrzeb.
ℹ️Modyfikowalna – umożliwia zmiany bez burzenia całej struktury.
ℹ️Możliwa do śledzenia – każda zmiana ma swoją historię i wpływ na pozostałe elementy.
Co, jeśli tego zabraknie?
Wróćmy do realnych przykładów:
🚨 Projekt zegarka cyfrowego
Dokumentacja zakładała, że zegarek obsłuży 24 strefy czasowe.
Problem? Na świecie jest ich więcej, a część ma przesunięcia o pół godziny.
Brak precyzyjnego opisu funkcji spowodował, że trzeba było przerobić projekt, by działał zgodnie z rzeczywistością.
🚨 Synchronizacja czasu
W wymaganiach zapisano, że zegarek ma dostosować czas do bieżącej strefy.
Ale czy miał uwzględniać zmianę na czas letni?
Tego już nikt nie określił. Efekt? Chaos przy wdrożeniu i poprawki w ostatniej chwili.
Brzmi jak drobiazgi?
Tyle że właśnie takie detale decydują, czy projekt dowiezie wartość, czy zaliczy spektakularną wpadkę.
🔹Masz dokumentację? Świetnie.
🔹 A czy na pewno obejmuje cały obraz, a nie tylko „nogę słonia”?
Bibliografia:
[1] C.Larman – UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji. Wydanie III, 2011,
[2] B.Bruegge, A.H. Dutoit, Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce projektowe i Java, 2011
[3] Sommerville, Ian; Sawyer, Requirements Engineering – A Good Practice Guide, 1997,
[4] IEEE 830-1998,
[5] P.G.Neumann, Computer-Related Risks, Addison-Wesley,Reading, MA, 1995
