Od czego zacząć projekt informatyczny? (pierwszy krok)

IT nie wnosi wiele nowego, jeżeli chodzi o funkcje, czyli to, co robią systemy. Biznesy działały sprawnie przez setki lat przed informatyzacją. Tym, co zachęca do korzystania z rozwiązań IT, jest coś innego. Prawdziwą wartość daje to, jak systemy realizują funkcje, w porównaniu do wcześniejszych rozwiązań. Czyli na pytanie „od czego zacząć projekt informatyczny?” według mnie dobra odpowiedź to – od analizy tego, co już jest i działa. I stopniowo próbować to ulepszać.

W dalszej części pokażę Ci kilka przykładów takiego podejścia w praktyce.

Terminologia – rodzaje wymagań (bardzo ważne!)

Do analizy przykładów przyda nam się spójna terminologia, czyli:

• Funkcja – oznacza to, co robi system lub ktoś/coś poza systemem. Funkcja jest niezależna od Rozwiązania. Funkcją może być np. definiowanie listy zadań do zrobienia w danym dniu.
• Cecha (jakościowa) – określa „jak …” system realizuje Funkcję. Czyli np. „jak szybko”, „jak intuicyjnie”, „jak bezpiecznie” itd. Cechy są też nazywane wymaganiami niefunkcjonalnymi (przeczytaj: Jak zmierzyć wymagania niefunkcjonalne w projekcie IT).
• Rozwiązanie – definiuje, w jaki sposób możliwe jest zrealizowanie danej Funkcji przy zachowaniu określonych Cech.

Jak w praktyce zacząć projekt na podstawie czegoś, co już istnieje

Zacznę od prostego przykładu, na którym wyjaśnię różnice pomiędzy trzema typami wymagań. Przeanalizujmy książkę w formie papierowej:

• Funkcja: pozwala czytać wszelką literaturę,
• Cechy: waga, rozmiar, czytelność, atrakcyjność wizualna, odporność na uderzenia, odporność na zalanie, trwałość, itd.
• Rozwiązanie: różnego typu papier i druk.

W zależności od wybranego Rozwiązania Cechy będą inne. Na przykład książka w grubej okładce jest cięższa, ale bardziej trwalsza.

Idąc dalej wyobraź sobie, że chcesz realizować Funkcję czytania, ale ze względu na częste przeprowadzki przeszkadzają Ci Cechy: waga i rozmiar papierowej ksiązki.

Być może w wyniku takiej analizy w 2007 roku na rynku pojawił się Kindle, popularny czytnik e-booków. Czy zmieniły się Funkcje względem tradycyjnej książki? Nie, dalej można na nim czytać wszelką literaturę. Projektanci czytnika zmienili jednak pewne Cechy, np.:

• Waga jest stała, niezależna od liczby książek i wynosi ok. 200 gram, czyli mniej niż standardowa książka (✅poprawa Cechy).
• Odporność na zalanie jest zerowa, podczas gdy tradycyjna książka zwykle nadaje się do użytku po zalaniu (❌pogorszenie Cechy).

Czytnik e-booków powstał więc jako odpowiedź na konkretne oczekiwania względem wybranych Cech. Nie jest on idealnym rozwiązaniem. Jest alternatywą dla osób, które cenią takie Cechy jak np. mała waga i rozmiar bardziej niż np. atrakcyjność wizualna.

Zaczynanie projektów informatycznych od tego, co jest – przykłady

Przykład z książką był nieco abstrakcyjny. Teraz już pora na konkrety ze świata IT.

Comiesięczny koszmar menedżerów

Pewna brytyjska sieć sklepów odzieżowych posiada oprogramowanie z poprzedniej epoki. Niektóre Rozwiązania doprowadzają menedżerów sklepów do szału.

Jednym z problemów jest comiesięczne tworzenie grafiku. System zupełnie nie wspiera tego procesu, a sytuację komplikują różne formy i wymiary etatów (np. studenci pracujący tylko co drugi weekend).

Jak jest teraz?

Obecna sytuacja wygląda tak:

• Funkcja: planowanie grafiku – planu pracy na kolejny miesiąc,
• Cechy:
  • czasochłonność: 8 godzin (wliczając potwierdzanie z pracownikami),
  • poprawność: 70% (ile osób otrzymuje plan, który nie zawiera błędów),
• Rozwiązanie: arkusze Excel – ręczne planowanie.

Jak zacząć projekt nastawiony na rozwiązanie tego problemu?

Jedna z opcji to wdrożenie nowego ERPa, który zawiera funkcjonalność planowania pracy. Potrwa to co najmniej kilka miesięcy. Konieczna będzie analiza wszystkich istniejących procesów. Także tych, które obecnie działają prawidłowo (żeby ich nie zepsuć). Koszt będzie więc odpowiedni.

Zarząd nie chce przeznaczyć pieniędzy na tak ogromną inwestycję. Menedżerowie przeklinają i sfrustrowani wykonują pracę, którą w XXI wieku powinien zrobić za nich system.

Załóżmy teraz, że chcemy zaadresować ten ból i zacząć projekt od czegoś mniejszego, stosując podejście Design to Cost.

Kolejne kroki mogą być następujące:

Krok 1 Interaktywny formularz zasilany danymi z ERP

Rozwiązanie: Budujemy interaktywną stronę, na której menedżer sklepu będzie widział wszystkich pracowników, ich wymiar czasu pracy, oraz zaplanowane nieobecności na podstawie danych z ERP. Menedżer będzie przypisywał osoby do konkretnych dni i godzin, a system będzie porównywał zaplanowany czas pracy z wymaganiami otrzymanymi z ERP.

Oczekiwane zmiany Cech:

• czasochłonność: 6 godzin (nie trzeba ręcznie weryfikować informacji o urlopach),
• poprawność: 85% (system waliduje poprawność planu, zdarzają się błędy w ERP).

Krok 2 Automatyczna komunikacja z pracownikami

Rozwiązanie: Po wygenerowaniu grafiku (w ramach strony z kroku 1) system wysyła email do każdego pracownika w celu potwierdzenia planu. Pracownik potwierdza plan lub odpisuje do menedżera podając co jest nie tak.

Oczekiwane zmiany Cech:

• czasochłonność: 3 godziny (nie trzeba każdego pytać indywidualnie),
• poprawność: 95% (pracownicy weryfikują grafik, sporadycznie zdarzają się błędy).

Krok 3 Automatyczne planowanie z uwzględnieniem nieobecności

Rozwiązanie: System przypisuje pracowników do poszczególnych dni uwzględniając ich zaplanowane nieobecności. System uwzględnia też przepisy prawa, czyli np. maksymalną długość pracy bez przerwy.

Oczekiwane zmiany Cech:

• czasochłonność: 1,5 godziny (pozostaje czas na uwzględnienie indywidualnych preferencji),
• poprawność: 95% (pracownicy weryfikują grafik, sporadycznie zdarzają się błędy).

Krok 4 Automatyczne planowanie na podstawie wcześniejszych miesięcy

Rozwiązanie: W trakcie planowania system uwzględnia poprzednie plany. Czyli jeżeli np. ktoś pracuje zwykle w weekendy, to na kolejny miesiąc też będzie miał zaplanowaną pracę w weekend.

Oczekiwane zmiany Cech:

• czasochłonność: 0,5 godziny (pozostaje czas na obsługę wyjątków),
• poprawność: 99% (błędy zdarzają się bardzo rzadko).

Jak zacząć projekt planowania czasu pracy – podsumowanie

Jak widać, w kilku iteracjach dążymy do skrócenia czasochłonności procesu 16 razy, przy znaczącej poprawie jakości planowania. To wszystko wdrażania nowego ERPa. Zaczynamy projekt od tego co jest i działa.

Być może z czasem dojdą kolejne Rozwiązania i w końcu nowy system całkowicie zastąpi starego ERP. Na początek opłacalne jest jednak stosowanie obu rozwiązań.

Niestrawne spaghetti

Kolejny przykład.

Firma otrzymała do utrzymania oprogramowanie, które jest napisane niezgodnie ze standardami. Jest to jedno wielkie i niestrawne spaghetti. Klient chce jednak dalej rozwijać ten soft.

Co zrobić?

Jedna z dostępnych opcji to „zaorać”. Czyli przepisać od nowa.

Inne rozwiązanie to napisać zgodnie ze sztuką moduł, który będzie dostarczał wyłącznie nowe funkcjonalności. I spróbować połączyć stare rozwiązanie z nowym (np. poprzez API). Jeżeli pojawi się potrzeba większych zmian w starym kodzie, to przenosić modyfikowane części do nowego rozwiązania. Pozostałe stare części, które działają i nie trzeba ich zmieniać, mogą zostać tam, gdzie są.

W tym przypadku można podać konkretne Cechy wynikające z jakości kodu źródłowego, takie jak np.:

• modyfikowalność – czas potrzebny na wprowadzenie zmian,
• stabilność – liczba nowych błędów w miejscach, które wcześniej działały prawidłowo,
• czytelność kodu – czas potrzebny na wdrożenie nowego programisty,
• itd. …

Wartości tych Cech będą różne, w zależności od Rozwiązania, czyli tego, czy nowa Funkcja będzie wdrożona w starym, czy nowym module.

Wiedząc co można zyskać lub stracić (zmiana Cech na +/-) łatwiej podjąć taką decyzję.

Przykłady:

1. Potrzebujemy dodać jedno pole do formularza. Taka zmiana nie wpływa na modyfikowalność, czy stabilność spaghetti kodu. Cechy pozostaną na takim samym poziomie. Można więc wdrożyć zmianę w starym kodzie.

2. Potrzebujemy dodać nowy algorytm. Zrobienie tego w spaghetti kodzie jeszcze bardziej obniży Cechy tego rozwiązania, przez co wygeneruje dodatkowe koszty, np.: now błędy, dłuższy czas wdrożenia nowej osoby itp. Opłacalne jest zrobienie tego w nowym module.

Jak zacząć projekt informatyczny od tego co istnieje – wnioski

Pisanie oprogramowania od zera do długotrwały proces. Nawet jeżeli „tylko” przepisujemy stary soft na nowy. Zaczynanie projektu od tego, co już istnieje, jest atrakcyjną alternatywą.

Dzięki temu szbyko zaadresujesz palące problemy. Możesz dostarczyć wartość dla użytkowników w tydzień, czy dwa. Unikasz przy tym ryzyka, że w trakcie przepisywania zepsujesz coś, co wcześniej działało prawidłowo.

Nie zawsze jednak można zacząć projekt informatyczny na podstawie istniejącego rozwiązania. Czasami jest to technicznie niemożliwe, bo stary system nie udostępnia API i nie można się dostać do bazy danych. Albo biznesowo klient oczekuje kompletnego, nowego rozwiązania i jest w stanie za to zapłacić.

Na koniec chodzi o to, żeby wybrać podejście w którym korzyści przewyższają koszty. Jeżeli wiesz jak oszacować i zaprezentować konkretne liczby, to bez problemu znajdziesz odpowiedź.

---