Nie raz pojawiały się tu (mój blog) odniesienia do tak zwanego ideału (idealizacja ) jako wzorca lub szkieletu. W artykule o studium wykonalności pisałem: Brak wiedzy o stanie idealnym możliwym…
"Requirements must be based on facts and real-life scenarios." (wymagania muszą być oparte na faktach i realnych scenariuszach). Więc ile warte są wizje w projektach agile albo wydumane w toku warsztatowych burz mózgów litanie życzeń i pomysłów? Nie tylko moim zdaniem: nie są wiele warte i nie powinny być wymaganiami.
Tak więc brak (umiejętności) stosowania abstrakcji w modelowaniu czyni te i inne modele (schematy blokowe) nieczytelnymi, trudnymi do interpretacji, kosztownymi w wytworzeniu i utrzymaniu. To ostatnie powoduje, że większość takich dokumentów szybko kończy życie na półkach, bo dezaktualizują się jak tylko dojdzie do jakiejkolwiek, nawet najdrobniejszej, zmiany w organizacji. Co ciekawe, biorąc pod uwagę czas trwania przeciętnego wdrożenia oprogramowania, taki zbyt szczegółowy model nie ma szans być przydatnym w toku takiego projektu, tu rację mają developerzy, którzy twierdzą, że im takie dokumenty im w niczym nie pomagają.
Tak więc AK jest to ktoś, kto rozumie całość ale nie musi (nawet nie powinien) być tym, kto ją implementuje, gdyż tu także ważne jest rozdzielenie roli projektującego od wdrażającego. Role te mają nie raz sprzeczne interesy: im głębiej w szczegółach tkwi dana rola (np. developer) tym bardziej w jej interesie leży utrzymanie status quo, mniejszą ma skłonność do wprowadzania zmian.
Wielu właścicieli firm, ich zarządy, pomija ten etap w projektach z uwagi na swoje przekonanie, że ich dotychczasowe działania i chęć ich kontynuacji, nie wymagają żadnej korekty, oczekują podania na tacy opisu narzędzia, którego - jak sądzą - potrzebują. Zachowują się jak pacjenci, którzy mimo, że ostatnie badania robili wiele lat temu, nie dopuszczają myśli, że lekarz może im przepisać na gorączkę coś innego niż kolejną aspiryną. Bywa, że zbyt późno odkrywają, że tym razem to nie było kolejne przeziębienie.