Pływający zakres

Lubisz niespodzianki? Także w projekcie? W trakcie pracy okazuje się, że jest coraz więcej do zrobienia, nie wiadomo skąd pojawiają się zagadnienia, których się nie spodziewałeś. Budżet i terminy ani drgną! Uwaga, kierowniku projektu! Wszedłeś na pole minowe pływającego zakresu.

Wchodzisz na pole minowe

„Ile to będzie kosztować?” – to intrygujące pytanie pada zazwyczaj w pierwszej rozmowie. Niekiedy na samym jej początku. Będąc pod presją niepewności umowy i świadomości, że konkurencja czyha, starasz się odpowiedzieć jak najszybciej (i przy tym atrakcyjnie dla klienta). Zadajesz kilka pytań, czasem odbywasz krótkie spotkanie poświęcone omówieniu zakresu. Niekiedy masz do dyspozycji jedynie dokument z określonymi wymaganiami.
Ile czasu masz na analizę tego, co ma wejść w zakres projektu? Godzinę? Trzy? Jeden dzień? Jak dokładnie w tym czasie jesteś w stanie przemyśleć i omówić wszystkie zgadanienia? Często – kiepsko i sam to czujesz. Jeśli jesteś szczęśliwcem, któremu nie narzuca się z góry zbyt krótkich terminów, odpowiesz pewnie, że na tyle, na ile uznasz, że chwytasz i możesz podać jakąś wycenę.
Po zamknięciu negocjacji uznajesz, że, żeby się wyrobić, trzeba natychmiast zacząć pracować? Czy to, co wykonałeś przed rozpoczęciem pracy wystarcza? Przypomnij sobie ile razy byłeś zaskakiwany w poprzednich projektach? Jak duże były to niespodzianki?
Jeśli miałeś mało czasu/informacji przy szacowaniu projektu, może to oznaczać, że wszedłes na pole minowe.

Czyhające niewypały

Po dynamicznym wkroczeniu na poligon (projekt zchwytany), czas zacząć działać! Jednak na drodze ku szczęśliwemu zakończeniu czyhają niewypały. Prychodzą mi do głowy trzy:

1. rzeczy, które miały być proste i szybkie do wykonania, okazują się być większe,
2. nierozwinięte skróty myślowe,
3. pojawiają się rzeczy, o których wcześniej nie pomyślałeś.

Ad. 1 Niestety jest to ryzyko pobieżnego ustalania zakresu. Im ogólniejszymi pojęciami/hasłami operujesz, tym większe pole do niedoceniania wagi sprawy. Gdyby klient był hobbystycznym programistą, być może uprzedziłby Cię o zależnościach i komplikacjach, jakie powinieneś uwzględnić w oprogramowaniu. Ale najczęściej nie jest. Rzuca hasło i liczy na Ciebie.

(np. uprawnienia administrator/nauczyciel/student okazują się nie być przypisane jednoznacznie od osoby – każdy może być jednym/drugim/trzecim w zależności od kursu, pory roku, stażu i indywidualnego uznania dyrektora)

Ad. 2 Klasyka nieporozumień, czyli mówimy to samo, każdy rozumie coś innego. Ktoś ma czas bawić się w parafrazowanie i doprecyzowanie każdej jednej kwestii? Zazwyczaj nie. Więc, bierzemy hasło, rozumiemy na swój sposób. Później jedno zdanie okazuje się rozrastać do monstrualnych rozmiarów.

(np. wyświetlanie informacji o kontrahencie może okazać się nie operacją „wpisz-wyświetl”, ale „zintegruj z core’owym systemem bankowym”)

Ad. 3 Podczas pracy okazuje się, że aby spełnić cel projeku (jeśli mamy szczęście znać go w weryfikowalnej postaci, albo mniej szczęśliwie ustanawia go klient „No, bez tego nie możemy pracować! To będzie dla nas bezużyteczny system.”), po prostu musisz dodać kolejne funkcje, będące komplementarne do innych.

(np. przy rejestracji sprzedaży towarów musimy mieć określony stan, a więc obsługiwać dostawy, o czym nikt nie wspomniał, ale nie da się bez tego…)

Rozminuj poligon

Jak moża bezpiecznie przejść przez projekt i nie dać się za bardzo zaskakiwać? Warto działać zapobiegawczo już od początku i:

1. ustalić cel,
2. zrozumieć dziedzinę,
3. określić procesy,
4. określić zakres,
5. doprecyzowywać.

Ad. 1 Ustalenie celu projektu (co wprowadzana zmiana ma spowodować, jakie będą korzyści dla ogranizacji/właściciela produktu) pozwala stwierdzać, co go wspiera, a co nie, a przez to – co powinno być w zakresie, a co nie. To Twoja pierwsza linia obrony.
Ad.2 Warto zrozumieć dziedzinę. Im więcej wiesz, tym mniej masz możliwości, by zostać zakoczonym. To też panaceum na mniej zdecydowanych/zorientowanych klientów – możesz im podpowiedzieć, czego potrzebują 🙂 Dzięki zrozumieniu zależności między różnymi pojęciami, ułatwiasz programistom tworzyć struktury danych i modele bardziej odporne na nieoczekiwane zmiany (bo inspirują je zależności ze świata rzeczywistego).
Ad. 3 Co będziesz informatyzować? Jakie akcje, jakie działania? Jak one przebiegają? Jakie czynności są wykonywane? Przez kogo? Z wykorzystaniem czego? Niezrozumienie procesów wraca jak bumerang – powtarzają się pytania wśród zespołu – jak to ma działać? Potrafiąc to przekazać, pomagasz zespołowi tworzyć lepsze alogrytmy – bardziej podatne na dostosowanie po zaskoczeniu kolejną zmianą wymagań.
Ad. 4 Mając określone procesy, łatwo wskazać na nich, co powinno wejść w zakres projektu i od razu zweryfikować, czy całość procesu będzie wykonywalna, jeśli część zostanie pozostawiona do obsługi poza systemem (telefony, maile, listy, rozmowy). Kilka sposobów określania zakresu znajdziesz tu: https://analizait.pl/2012/modelowanie-zakresu/.
Ad. 5 Niewiele rzeczy jest tak przyjemnych dla analityka jak szukanie niedociągnięć 😉 Po pewnej praktyce zaczyna się dostrzegać coraz sprawniej nieprecyzyjne stwierdzenia i braki informacji. Wymagania przesiane przez dobre analityczne sito, nie zostawią już cienia wątpliwości.

Generalnie…

Im lepszego masz analityka (lub im lepsze sam posiadasz kompetencje analityczne) i im więcej zapewnisz czasu koniecznego na analizę, tym mniej musisz obawiać się pływającego zakresu i wybuchających niewypałów.
P.S. Wpis dotyczy projektów zewnętrznych (zleconych przez zewnętrznego klienta).