Zrozumienie i dokumentacja procesów logistycznych jako pierwszy etap wdrożenia systemu SCE
Niemal każdy projekt wdrożeniowy rozpoczyna się od etapu projektowania systemu, uzyskiwania wymagań, porządkowania procesów, którymi należy zarządzać. To wydaje się takie proste. Wystarczy usiąść z przyszłymi użytkownikami systemu oraz z innymi interesariuszami projektu i wypytywać jakie są ich życzenia, które system ma spełniać. Jednak już pierwsze pytanie – „Jaki jest cel uruchomienia nowego systemu?”, przysparza odbiorcy wiele problemów i niekoniecznie daje jasną odpowiedź.
Sprawny przebieg tego etapu pozwoli zarówno dostawcy oprogramowania jak i klientowi końcowemu zrozumieć ideę projektu i nakreślić spodziewany efekt końcowy po uruchomieniu systemu. Dlaczego zatem jest to takie trudne i dlaczego posiłkujemy się różnymi technikami na etapie zbierania wymagań? W celu uzyskania pełniejszego wyjaśnienia tego problemu, przyjrzyjmy się najpierw typowym syndromom, które zazwyczaj towarzyszą dokumentowaniu wymagań.
Syndrom „tak, ale…”
Jednym z powszechnie występujących i pozornie przygnębiających problemów podczas rozbudowy aplikacji jest to, co możemy nazwać syndromem „tak, ale..”. Występowanie tego syndromu możemy stwierdzić na podstawie reakcji użytkowników na daną część systemu:
„Tak, ale czy będzie można jeszcze…? Czy nie lepiej byłoby, gdyby…? Przecież, jeżeli… to trudno będzie…”
Wydaje się, że korzenie syndromu leżą w mnogości wyjątków występujących w realnym świecie i z trudnością zakodowania ich wszystkich we wdrażanym systemie. Te reakcje użytkowników wynikają także z ludzkiej natury i odniesienia do codziennych problemów. Użytkownicy często nie znają podobnych systemów, nie rozumieją zatem co analityk, czy programista miał na myśli, kiedy wcześniej opisywał im system. Teraz, kiedy po dłuższym oczekiwaniu mają wreszcie możliwość interaktywnie go przetestować, okazuje się, że to nie jest to, czego oczekiwali.
Gdyby analogicznie porównać proces tworzenia oprogramowania z tworzeniem urządzeń mechanicznych, których technologia i proces tworzenia są starsze o kilkaset lat, to okazuje się, że tworzenie maszyn bazowało na dobrze zdefiniowanych teoriach popartych sprawdzonymi w praktyce modelami, prototypami, wzorami itp. Użytkownicy mogli zobaczyć urządzenia mechaniczne już na wstępie ich tworzenia, dotknąć ich, rozważyć ich przydatność a nawet je wypróbować zanim trafią do produkcji masowej.
Mimo to, że syndrom „tak, ale” jest frustrujący, świadomość występowania oraz zaakceptowanie go prowadzi do konkretnych wniosków, które pomagają łagodzić okoliczności jego występowania w projekcie:
- Syndrom „tak, ale” leży w ludzkiej naturze i jest integralną częścią procesu tworzenia aplikacji,
- Możemy redukować ten efekt stosując techniki, które wcześnie wykryją wszystkie wyjątki
Syndrom „nieodkrytych zjawisk”
W trakcie realizacji jednego z projektów, podczas identyfikacji przepływów logistycznych natrafiłem z klientem na proces, którego istnienia klient nie podejrzewał. Okazuje się, że operacyjna warstwa przedsiębiorstwa wykształciła sobie sposób na optymalizację organizacji pracy i wprowadzała pewne „usprawnienia”, które z czasem wymknęły się kadrze zarządzającej spod kontroli i zaczęły żyć własnym życiem. Klient sam zadał pytanie: „Ile jeszcze takich nieodkrytych zjawisk mamy w firmie?”.
Faktycznie nigdy nie jesteś pewien, czy znalazłeś i udokumentowałeś już wszystkie procesy i prawdopodobnie nigdy ich wszystkich nie poznasz. Zazwyczaj zespoły projektowe borykają się z zagadnieniem określenia, kiedy proces pozyskiwania wymagań jest zakończony, tj. kiedy zostaną znalezione wszystkie istotne z punktu widzenia uruchomienia wymagania, lub ich liczba zostanie uznana za wystarczającą?
Zderzenie „logistyka z informatykiem”
Trzeci syndrom wynika z pewnej bariery komunikacyjnej między logistykiem a informatykiem, lub dokładniej między użytkownikiem a programistą. Zwykle ci ludzie należą do różnych środowisk, używają różnego słownictwa i mają inne cele a nawet motywacje. Zazwyczaj problem sprowadza się do tego, że użytkownicy nie potrafią precyzyjnie wyrazić tego czego oczekują. Lub też analitycy uważają, że rozumieją problemy użytkownika lepiej niż on sam. Bywa także, że to co chce użytkownik jest nie do wykonania, lub wreszcie programista znając ograniczenia oprogramowania przekonuje do tego, aby proces logistyczny dopasować do gotowego oprogramowania.
Techniki uzyskiwania wymagań
Lepsze wzajemne zrozumienie przeniesie analityków systemowych z poziomu bajtów do świata rzeczywistych ludzi i problemów a logistyków zorientuje do procesowego podejścia, pogrupowania zagadnień i uporządkowania przebiegu zdarzeń.
Do analizowania i projektowania rozwiązań można użyć różnych technik i narzędzi. Do tych najczęściej stosowanych zalicza się:
- Przeprowadzanie wywiadów, ankiet z interesariuszami projektu
- Przeprowadzanie warsztatów ze standardowej wersji systemu
- Burza mózgów
- Szkicowanie przebiegu procesu na diagramach przepływowych
- Stosowanie list z przypadkami użycia
- Przygotowywanie prototypu rozwiązania
- Podział na role i aktorów
Wybór określonej techniki zależy od typu aplikacji i procesu, jaki zostanie objęty wspomaganiem systemowym. Zależy również od indywidualnych predyspozycji zespołu projektowego, umiejętności komunikacyjnych użytkowników, skali problemu, stopnia ważności, stosowanej technologii produkcji oprogramowania oraz stopnia wyjątkowości aplikacji. Stosowanie techniki wspomagane są poprzez wiele specjalistycznych narzędzi, raczej ale o tym w kolejnym wątku…
