Dwa lata temu pewna firma postanowiła wesprzeć swoje procesy za pomocą systemu ERP. Mieli wiele małych systemów, ale marzyło się im kompleksowe rozwiązanie. Tak się złożyło, że dostałem zlecenie zebrania wymagań, a następnie zaprojektowania architektury owego.
Dwa tygodnie później zachodziłem w głowę jak to się mogło stać, że uzbrojony w całą wiedzę z wiązaną z UMLem (i zakupionym na tę okazję EA), architekturą, programowaniem i doświadczeniem związanym z wytwarzaniem oprogramowania, poniosłem katastrofalną Klęskę. Dokładnie tak Klęskę przed duże "K". Czułem podskórnie, że ten projekt się nie uda i po jakimś czasie okazało się, że miałem rację. Lecz co z tego, ze miałem rację, skoro klient był niezadowolony? Pozostał z nierozwiązanym problem. Problem, którego ja nie potrafiłem namierzyć oraz nazwać.
Kilka tygodni później przypadkiem brałem udział w szkoleniu i prowadzący niby przypadkiem powiedział takie zdanie: "Problem jest początkiem rozwiązania". Do końca szkolenia nie mogłem się już skupić na niczym innym niż to, kołaczące mi w głowie zdanie: "problem jest początkiem rozwiązania".
Po powrocie do domu napisałem ten post. Potem obsesyjne zacząłem zastanawiać się nad moim problem związanym ze zbieraniem wymagań do wspomnianego systemu ERP. Potem w trakcie kolejnych rozmów z klientami zacząłem zauważać coraz więcej reguł jakimi rządzą się takie rozmowy. Powoli włączałem moje odkrycia do swoich szkoleń. W końcu postanowiłem napisać książkę.
Dlaczego ta książka warta jest Twojego czasu? Zwróć uwagę, że wszystkie popularne metodyki w inżynierii oprogramowania: począwszy na OOD a na DDD skończywszy mówią o: odwzorowywaniu rzeczywistości, modelowaniu procesów biznesowych, modelowaniu dziedziny, kruszeniu dziedziny, itd. I tylko drobnym druczkiem jest w tych książkach napisane, że zakłada się, iż wiadomo, co trzeba zrobić. A guzik prawda! Nie bez powodu narzekamy na nieprecyzyjne wymagania. Zapewniam Cię, że gdybyś dokładnie wiedział, co należy zrobić, to nie miałbyś najmniejszych kłopotów z zastosowaniem OOD, TDD, BDD, DDD, DDDD i jeszcze więcej "D". Z architekturą i późniejszym utrzymaniem też by nie było kłopotów.
Metody inżynierii oprogramowania zajmują się modelowaniem rzeczywistości. Ta rzeczywistość znajduje się w głowach Twoich klientów. I o odkrywaniu właśnie tej rzeczywistości jest książka Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce?.
