Spis treści
Wiele projektów informatycznych zaczyna się w bardzo podobny sposób. Firma chce systemu. Ma pomysł. Ma budżet. Znajduje wykonawcę. Zaczyna się praca.
Kilka miesięcy później pojawia się chaos. Zakres się zmienia. Funkcjonalności są niedoprecyzowane. Każda ze stron ma inne oczekiwania. Budżet rośnie, a projekt coraz bardziej przypomina eksperyment.
Paradoks polega na tym, że większość takich problemów nie wynika z technologii. Wynika z decyzji podjętych na samym początku projektu.
Zanim powstanie choć jedna linijka kodu, powinien wydarzyć się proces, który w wielu firmach jest pomijany. Proces uporządkowania decyzji.
Projekt IT zaczyna się od problemu biznesowego
Największym błędem jest rozpoczynanie projektu od pytania: jaki system chcemy zbudować.
Znacznie ważniejsze pytanie brzmi: jaki problem chcemy rozwiązać.
Czy firma chce przyspieszyć obsługę klientów?
Czy chce zautomatyzować procesy wewnętrzne?
Czy chce lepiej zarządzać danymi?
Bez jasnej odpowiedzi na to pytanie projekt technologiczny szybko zaczyna żyć własnym życiem. Funkcjonalności pojawiają się przypadkowo, a system przestaje mieć spójną logikę.
Dlatego pierwszym etapem powinno być zdefiniowanie celu biznesowego projektu.
Wymagania, które mają sens
Dopiero gdy cel jest jasny, można przejść do pracy nad wymaganiami.
W wielu firmach wymagania powstają w formie długiego dokumentu. Kilkadziesiąt stron opisów, które po kilku miesiącach przestają być aktualne.
Znacznie lepszym podejściem jest opisanie wymagań w sposób, który pozwala nimi zarządzać w trakcie projektu.
W praktyce oznacza to przejście od statycznego dokumentu do struktury wymagań, które można rozwijać i porządkować.
Właśnie w tym miejscu pojawia się backlog.
Backlog jako mapa projektu
Backlog to lista funkcjonalności, które system powinien realizować. Ale dobrze przygotowany backlog to coś więcej niż spis pomysłów.
Każdy element backlogu powinien odpowiadać na trzy pytania.
Jaki problem biznesowy rozwiązuje dana funkcjonalność.
Jak użytkownik będzie z niej korzystał.
Jak można sprawdzić, czy działa poprawnie.
Dzięki temu backlog staje się mapą projektu. Zamiast jednego ogromnego przedsięwzięcia powstaje zestaw mniejszych elementów, które można planować i realizować etapami.
Priorytety zamiast chaosu
Kolejnym kluczowym elementem jest ustalenie priorytetów.
Bez tego backlog szybko zamienia się w listę życzeń. Każdy dział chce mieć swoje funkcjonalności. Każdy uważa je za najważniejsze.
W dobrze prowadzonym projekcie funkcjonalności dzielone są na kilka poziomów ważności.
Najpierw powstaje rdzeń systemu, który rozwiązuje podstawowy problem biznesowy. Dopiero później rozwijane są kolejne funkcje.
To podejście ma ogromną zaletę. System zaczyna przynosić wartość dużo wcześniej, zamiast powstawać przez dwa lata w zamkniętym projekcie.
Rola inspektora nadzoru
W wielu projektach IT pojawia się jeszcze jeden element, który bywa niedoceniany. Inspektor nadzoru.
To rola znana z budownictwa, ale coraz częściej pojawiająca się również w projektach technologicznych.
Inspektor nadzoru reprezentuje interes inwestora. Nie jest częścią zespołu wykonawcy. Jego zadaniem jest pilnowanie, aby projekt był realizowany zgodnie z założeniami biznesowymi.
W praktyce oznacza to kontrolę zakresu projektu, ocenę jakości rozwiązań, weryfikację postępu prac oraz pomoc w podejmowaniu decyzji.
Dzięki temu firma nie musi polegać wyłącznie na deklaracjach wykonawcy.
A w praktyce wygląda to tak…
W jednej z firm powstawał system, który miał obsługiwać niemal wszystkie procesy organizacji. Projekt trwał ponad dwa lata.
Problem polegał na tym, że każda funkcjonalność była traktowana jako równie ważna. Nie było priorytetów.
Po analizie projektu zdecydowano się podzielić backlog na trzy poziomy. Najpierw wdrożono moduł kluczowy dla sprzedaży.
System zaczął przynosić realne korzyści już po kilku miesiącach, a reszta funkcjonalności była rozwijana etapami.
Inna firma zleciła budowę systemu zewnętrznemu wykonawcy. Projekt miał szczegółową specyfikację, ale nie było osoby po stronie inwestora, która rozumiałaby technologię i potrafiła ocenić decyzje projektowe.
Po roku okazało się, że część funkcjonalności została zrealizowana w sposób, który utrudniał dalszy rozwój systemu.
Dopiero wprowadzenie zewnętrznego doradcy pełniącego rolę inspektora nadzoru pozwoliło uporządkować architekturę projektu i ustalić realistyczny plan dalszych prac.
Projekt IT to przede wszystkim decyzje
Z perspektywy wielu lat pracy z projektami informatycznymi widać jedną rzecz bardzo wyraźnie.
Największe problemy projektów IT nie wynikają z technologii. Wynikają z decyzji podjętych przed rozpoczęciem pracy.
Brak jasnych wymagań.
Brak priorytetów.
Brak osoby reprezentującej interes inwestora.
Gdy te elementy są uporządkowane, projekty informatyczne przestają być ryzykownym eksperymentem. Stają się przewidywalnym procesem, w którym technologia jest narzędziem realizacji celów biznesowych.
I właśnie na tym polega prawdziwe zarządzanie projektem systemu informatycznego. Nie na pisaniu kodu, ale na podejmowaniu właściwych decyzji we właściwym momencie.
Jeśli ten temat jest bliski Twojej firmie...
Na blogu dzielę się obserwacjami z pracy z przedsiębiorstwami oraz refleksjami dotyczącymi technologii, zarządzania i funkcjonowania organizacji. W wielu firmach podobne zagadnienia pojawiają się jednak nie tylko jako ciekawy temat do dyskusji, ale jako realne wyzwanie związane z rozwojem biznesu.
Jeśli w Twojej firmie pojawiają się pytania dotyczące organizacji procesów, wykorzystania technologii lub kierunku rozwoju projektów informatycznych, możesz skorzystać z mojego wsparcia doradczego.
