Dekalog GOV

Czy projekty IT z kręgu programów rządowych, zamówień publicznych i innych dużych „sławnych inaczej” przedsięwzięć mogą kojarzyć się komuś z sukcesem, dostarczaniem na czas, w założonym budżecie, z wymaganą funkcjonalnością i bez awarii kilka minut po starcie? Pewnie większość z nas powie, na podstawie naszych rodzimych doświadczeń, że nie ma szans, a krótkie poszukiwania w zasobach sieci upewniają, że nie jest to tylko nasza polska przypadłość. Jednak nie na porażkach chciałbym się dzisiaj skupić, a odwrotnie, na sukcesach. Otóż w jednym z europejskich krajów zdarzył się cud i tworzenie cyfrowej wersji usług spod domeny „gov” zakończyło się sukcesem i to, jak piszą, spektakularnym. Idąc tropem tego sukcesu, dotarłem do zasad, którymi kierowano się w trakcie realizacji całego przedsięwzięcia. Jest ich dziesięć i tak jak dziesięć przykazań stanowiły podstawowy „dekalog” projektu. Ważne jest to, że zasady te mogą dać odpowiedź na podstawowe pytanie „jak oni to zrobili”. Oto te zasady, w kolejności:

1. Zacznij od potrzeb.
2. Rób mniej.
3. Projektuj na podstawie danych.
4. Wkładaj duży wysiłek, ale w to, by budować rzeczy proste.
5. Iteruj. A następnie znów iteruj.
6. Twórz dla każdego.
7. Musisz rozumieć kontekst.
8. Buduj usługi, a nie aplikacje.
9. Bądź spójny, ale nie zuniformizowany.
10. Czyń rzeczy otwartymi – wtedy będą lepsze.

A ja zdobywam się na śmiałość i komentuje je tak:

• (1) To elementarz, zawsze należy zacząć od potrzeb, wymagań, to raczej oczywiste.
• (2) To ciekawe podejście, trąci „adżajlem”, zwinnym podejściem, bardziej rozumiem to jako „rób to, co najważniejsze w danej chwili”, to zrozumiałe, skupienie się na celu głównym i w dodatku na jego głównych elementach jest zdecydowanie korzystne dla przebiegu projektu.
• (3) Tu niestety trudno się zgodzić, co prawda jest to zasada w pewnych kontekstach słuszna, dla systemów „dano centrycznych” pewnie optymalna, ale nie wolno zapominać, że oprócz samych danych mamy choćby zachowania czy procesy, wolałbym powiedzieć „projektuj na podstawie pełnej domeny”, choć rozumiem specyfikę działań „gov” gdzie dane być może stanowią główne źródło bodźców projektowych.
• (4) Rewelacja, za jednym razem pochwała pracy i prostoty, podpisuję się dwoma rękami.
• (5) Czysty „adżajl”, dzisiaj już wiemy, że w projektach inaczej się nie da, „dziel i zwyciężaj” to cały czas pozostaje bardzo ważna zasada, z tym że to już nie wystarczy. Sam podział może nas doprowadzić do etapów i kamieni milowych z metodyk kaskadowych, a iteracja to coś więcej, po każdej iteracji siadamy do weryfikacji dalszego planu, możemy go, bacząc na doświadczania z zakończonej iteracji, zmienić … i to jest piękne.
• (6) Jakoś mi to zasada nie leży, „dla każdego”, tzn. „dla kogo”?  Mamy tu sprzeczność z (1) i (2), skoro robimy pod potrzeby i robimy tylko te najważniejsze tematy, a potrzeby są różne, to nie zrealizujemy wszystkich potrzeb i nie zrobimy czegoś dla wszystkich. Może bardziej chodzi tu o to, żeby nie komplikować, żeby było proste w użytkowaniu, może.
• (7) Ogromna i przeogromna racja, brak zrozumienia kontekstu jest dużym problemem, powszechne forsowanie poprzednich doświadczeń jako miernika czy coś się sprawdza, czy nie, bez świadomości innego być może kontekstu tych doświadczeń jest załamujące. Pomijanie kontekstu, myślenie schematem, raz się udo udało się zawsze, to powszechne grzechy nie tylko w projektach.
• (8) To ważne i dla mnie najważniejsze zdanie na tej liście. To podstawa nowoczesnych architektur, myślenie aplikacjami, stronami, portalami należy zawsze umieszczać za myśleniem o usługach. Usługi są esencją systemów, System = Zbiór usług, „frontendy” dla usług są drugorzędne, choć oczywiście potrzebne.
• (9) To dziwnie brzmiąca zasada, możliwe, że jakoś nie do końca szczęśliwie przetłumaczona. Jeżeli dobrze rozumiem jej znaczenie, to uważam ją za bardzo, bardzo ważną. Spójność to jasne, ważna zaleta, nie dopuszczając do „radosnej twórczości” mamy szansę otrzymywać rozwiązania spójne, pełne reguł i wzorców, w takim systemie te same klasy problemów rozwiązane są tak samo, daje to porządek i prostotę, zmniejsza koszty utrzymania, obniża nachylenie krzywej nauczania, słowem same zalety. Uniformizm jest pojęciem w tym samym wymiarze, co oznacza, że przesadne dążenie do spójności może zabić różnorodność, spowodować, że całkiem różne klasy problemów rozwiązywane są tymi samymi schematami, dążenie tą drogą doprowadza do podejścia schematycznego, sztywnego, pozbawionego polotu. Sztuką jest być spójnym, ale nie dopuścić do schematycznego uniformizmu.
• (10) To oczywista konsekwencja (8), mamy usługi i ich interfejsy, możemy się otworzyć, dla „gov” i nie tylko to ogromna wartość. Jednoczesna zdolność do wystawiania i konsumpcji usług jest dzisiaj fundamentalną zasadą, pozwalającą na wielowymiarową i wielokierunkową integrację.

Brawo Oni. Jaki to kraj i jaki projekt? Nie Estonia, jakby się wydawało, powiem tylko, że domena kończy się na gov.uk.