Zasada Pareto w pewnym uproszczeniu mówi, że 20% obiektów jest związanych z 20% zasobów. Co to oznacza dla nas? Np to że 80% funkcjonalności nowego programu zrobimy w 20% całego czasu realizacji programu. Jednocześnie na odwrót: 80% czasu zajmie nam tworzenie 20% programu. I co z tego ? A np to, że warto oszacować które z procedur należą do tych 80% a które do pozostałych 20% i zrealizować 80% funkcjonalności, po 1/5 czasu zaplanowanego na projekt w harmonogramie dać użytkownikom program (działający w 80%). Ten program usprawni już im pracę. Widzą co powstało, maja na czym pracować ,nie marudzą kiedy będzie program, tylko ewentualnie wypominają czego w nim brakuje – a to już inna bajka (w końcu nie ukrywamy, że to nie jest nasze ostatnie słowo)! Presja pracy nad programem spada – oczywiście nie można sobie pozostałych 20% odpuścić, ale dobre poczucie, że już coś działa pozwala na bardziej komfortową pracą nad resztą.
Drugą zaletą takiego postępowania jest to, że jeśli podczas projektowania poczyniliśmy błędne założenia to większość z nich może być już na tym etapie wychwycona. Chyba lepiej dowiedzieć się, ze do zmiany mamy wynik kilku tygodni pracy, niż to co robiliśmy przez ostatnie pół roku.
Należy sobie uświadomić, że program idealny nie istnieje. Zawsze można coś zakodować lepiej: uzyskamy bardziej efektywny kod, czytelniej czy bardziej przyjazne dla użytkownika. Tylko jeśli będziemy pracować nad tym tym idealnym programem to czas jego oddania będzie oscylował w następnym dziesięcioleciu.
Na Playstation jest taka gra Gran Turismo 5. Pisali ją kilka lat i podobno skończyli tylko dlatego ze ktoś zagroził zespołowi programistycznemu, że ich odłączy od kasy za pisanie. Ci przyjęli „propozycję nie odrzucenia” z komentarzem ze wiele rzeczy jeszcze chcieli tam zmienić tylko nie dane im było. Pewnie robiliby to jeszcze ze 4 lata. Efekt jaki uzyskali w „niedokończonej” wersji jest wybitny, niespotykany w żadnym innym symulatorze wyścigów samochodowych. Tak długo mogli trzymać klientów w niepewności i testować ich cierpliwość , bo …………………… po 2ch latach wypuścili wersję GT5 Prologue .
Tak też należy pisać program: robimy wersje „Prologue”, dajemy użytkownikom, niech się nacieszą, niech używają, testują, a my mamy czas na cyzelowanie interfejsu użytkownika, dopieszczanie zapytańdo bazy danych czy kolejnej pętli liczącej PI z dokładnością do kilku tysięcy miejsc po przecinku 😉
Wśród ostatnich przemyśleń pojawiło się jeszcze jedno: nikt nie lubi pisać dokumentacji. Warto wtedy pamiętać o opisywanej zasadzie. Trzeba napisać 20 % dokumentacji, która opiszę 80% funkcji systemu. Zawsze można powiedzieć że 80% tego co miało być opisane, jest opisane!
Kashiash's Blog 