Usługa ta stanowi sobą audyt treści i struktury dokumentów w procesach biznesowych oraz opracowanie modelu architektury IT w celu mapowania dokumentów na aplikacje, w których powstają i są wykorzystywane (integracja). Są to wyłączone i połączone razem pierwsze etapy usług Audyt organizacji, podnoszenie efektywności oraz Analiza i Opracowanie Wymagań na Oprogramowanie. Jednym z głównych celów i produktów jest opracowana strategia cyfryzacji i archiwizacji dokumentów w organizacji oraz zarządzania ich treścią.

Ten wpis adresuję przede wszystkim menedżerom nie tylko IT. Analitycy i programiści spokojnie mogą go pominąć, chyba, że …;) chcą wiedzieć dlaczego powinny powstawać idealizowane projekty, kiedy mogą czasem wykonać niekoniecznie idealną implementację i dlaczego nie należy pomijać etapu projektowania idealizacji .

W jednym z ostatnich wpisów w dyskusji napisałem w komentarzach, że:

…jestem purystą formalnym. Jednak nie dlatego, by pacyfikować projekty ortodoksją. To efekt dwóch rzeczy: teoria poznania jako restrykcyjne podchodzenie do semantyki, pozwala uniknąć niejednoznaczności. Druga rzecz, to zdefiniowanie ideału, pozwala ocenić (zmierzyć) odstępstwo konkretnego projektu od niego [od ideału]. To pozwala ocenić ryzyko takiego projektu. Fizyka ma np. nieistniejące w naturze idealne wahadło czy ciało doskonale czarne , po co? By móc ocenić błąd rzeczywistych obliczeń. Zdaję sobie sprawę, że to filozofia, ale taki mam cel , nie tylko analizować i modelować ale w 100% rozumieć (Czym jest a czym nie jest tak zwany model dziedziny systemu).

Dość często spotykam się z zarzutem, że to szkodzi projektom, że trzeba z jednej strony naginać zasady a z drugiej, że nie ma co zajmować się idealnymi systemami bo takich nie będzie, że ograniczenia projektu, głównie czas i budżet, wymagają “psucia” bo na ideały nie ma czasu.

To są niestety, w moim mniemaniu, tłumaczenia ludzi nie potrafiących tego ideału zrobić czyli niemających pomysłu na właściwe rozwiązanie, czytaj, nie potrafiących problemu rozwiązać.

Droga na skróty to droga niewiedzy. Nie twierdzę tu, że sens mają wyłącznie projekty idealne. Twierdze, że na etapie analizy problemu i projektowania powinien powstać ideał, a dopiero na etapie analizy zakresu projektu i oceny wykonalności, jest miejsce na ewentualne uproszczenia, bo tu są one czynione świadomie.

Z tezą taką w literaturze spotykam się bardzo rzadko,  ale spotykam . Możliwe, że to bardzo odważna teza:

większość projektów to rozwiązywanie niezrozumianego problemu.

Statystyki jednak zdają się potwierdzać, że coś jest na rzeczy .

Na szczęście, nie ja jeden tak sądzę. Tu zacytuję także blog pewnego programisty:

ciągle zmieniający się program zwiększa swoją złożoność o ile nie pochylimy się nad kodem aby ją zmniejszyć. Pisanie programów jest łatwe, wręcz banalnie łatwe, jednak pisanie tak, aby dało się je długo i w miarę tanio utrzymywać jest bardzo trudne. Wynika to z dwóch złożoności. Jedna to złożoność samego problemu, druga to złożoność przypadkowa. Tą przypadkową tworzymy my sami ? programiści. Sami komplikujemy soft bardzo często zupełnie niepotrzebnie. Sami idąc na skróty gmatwamy kod tak, że staje się z dnia na dzień coraz droższy w utrzymaniu. To podrażanie utrzymania to właśnie dług technologiczny. Dług technologiczny, jak każdy dług ma to do siebie, że im dłużej nie spłacany tym więcej będzie kosztować. (Dług technologiczny | @rek online | Arkadiusz Benedykt, Gorąco polecam cały ten cykl artykułów).

Tu autor pastwi się, i słusznie, na zaciąganiem długu, który ja postrzegam jako dług nie tylko technologiczny. To dług niezrozumienia mający swój początek  już na etapie analizy: ktoś  nie chciał do końca zrozumieć złożoności problemu (patrz wytłuszczenie w cytacie), zignorował etap dogłębnej analizy problemu i zaczął kodować: zaciągnął dług nie ponosząc kosztu zrozumienia tylko  zaczyna od razu kodować. Przypomnę, że pomijanie dogłębnej analizy i tworzenie kodu to implementacja czegoś, czego  właśnie nie chcieliśmy do końca zrozumieć.  Czy to zdanie nie brzmi strasznie? Co powstanie?

Czego się spodziewać po projekcie, gdy słyszę: nie ma czasu na analizę, myśmy już podpisali umowę z wykonawcą bo nasza firma  nie ma czasu. Niestety najczęściej taki projekt trwa znacznie dłużej niż planowano, pieniądze oszczędzone na “zbędnym” projektowaniu ideału z ogromną nawiązką są wydawane na kolejne modyfikacje i poprawki (spłata długu, nie raz bardzo kosztowna).

O skutecznym zarządzaniu, posiadaniu wizji, napisano wiele, nie jest to miejsce na powielanie tych prawd. Spójrzmy na poniższy cytat:

Społeczeństwo niezdolne do wydawania na świat utopii i do poświęcania się jej zagrożone jest sklerozą i ruiną. Mądrość, dla której nie istnieją żadne fascynacje, zaleca nam szczęście dane, gotowe. Wybór szczęścia wyobrażonego czyni nas zdolnym do zmiany, do wzrostu.    Emil Cioran (Business Dialog – Posłuchaj. Powiedz. Przynosimy radość owocnej rozmowy)..

A teraz małe ćwiczenie: zamieńcie państwo słowo “Społeczeństwo” na “Organizacje”…

Powyższe wywody, czasami wspominam o problemie długu na konferencjach czy na forach, natychmiast  wywołują pobudkę zwolenników metod zwinnych (co by to nie miało znaczyć). Wiem, że są podobno różne formy zwinności, te dobre i te złe. Ale podobno zakończone sukcesem zwinne projekty są jak Yeti: każdy o nich mówi a nikt nie widział. Tu znowu zacytuję przywoływany już tu blog:

Modne ostatnio programowanie agile czy też programowanie zwinne oznacza w dużym uproszczeniu ciągłą ewolucję i ciągłe wprowadzanie zmian, tak żeby być elastycznym na potrzeby biznesu. Nie da się być agile budując monolity, nie da się być agile zaciągając coraz to nowe długi technologiczne. W końcu, nie da się być agile jeśli po roku czy dwóch wprowadzanie zmian zaczyna trwać dłużej i dłużej. Jeśli chcemy być agile to musimy bardzo mocno trzymać się zasad dobrego programowania. Musimy tworzyć elastyczne i otwarte konstrukcje zamiast monolitów. SOLID w tym bardzo pomaga chociaż nie jest to jedyna ?religia?. Aby to zrobić trzeba poświęcić odpowiednią ilość czasu i potu aby wyprodukować dobry kawałek kodu. (Monolity to też dług technologiczny | @rek online | Arkadiusz Benedykt).

Cóż, o SOLID za niedługo napiszę więcej, dziś podam jedną z kluczowych zasad, nazwał bym ją kluczowym wymaganiem pozafunkcjonlanym: projekt ma być odporny na zmiany i otwarty na rozszerzenie. Jak to osiągnąć? jest tylko jeden sposób: wykonać dobry projekt. Dobry czyli przemyślany, z pełnym zrozumieniem problemu i świadomym odkładaniem pewnych prac.

Na zakończenie przyznam, że wśród moich niedoszłych klientów i programistów  mam wielu wrogów. To Ci, którzy uważają, że analizy i projektowanie ideału (co by tu słowo nie miało oznaczać) na samym początku są bez sensu, bo i tak wymagania biznesu się zmienią, więc i program będzie się zmieniał. Ja wtedy pytam: zmieniał czy rozszerzał? Jeżeli wymagania się zmieniają to raczej sygnał, że nie zostały na początku przemyślane… Ale wymaganiem powinien być cel a nie aktualne środki jego osiągania! Biznes także ma skłonności do zaciągania opisywanego długu… Na koniec  w kwestii wrogów pół żartem i pół serio:

Chińczycy hołdują powiedzeniu: ?jak posiedzisz wystarczająco długo nad brzegiem rzeki, to zobaczysz trupy swoich wrogów płynące z prądem”. No więc sobie siedzę.

… i nie raz je oglądam… a siedzę sobie analizując i projektując… 😉 i nie jestem tu sam…

Źródła