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…
Świetny artykuł! Zgadzam się w 100%. Powinniśmy dążyć do ideału jako punktu odniesienia (inna sprawa, że trzeba wyczuć kiedy na tej drodze się zatrzymać). Ale oznacza to, że musimy wiedzieć czym jest ten ideał.
Przychodzi mi na myśl taka refleksja: starajmy się tworzyć rzeczy piękne! Piękno to przecież nie tylko sztuka czy natura. Piękne mogą być prawa fizyki czy modele matematyczne. W informatyce oznacza to dla mnie przemyślany model, czytelną architekturę, spójną logikę, dobrze zdefiniowane moduły itd.
A dlaczego powinniśmy to robić? Słyszałem ostatnio myśl, która świetnie nadaje się na podsumowanie:
“Jeżeli coś dobrze wygląda to jest szansa, że będzie dobrze działać. Ale jak coś wygląda fatalnie to na pewno jest schrzanione.”
Weźmy to sobie do serca. Projektujmy rzeczy dobrze wyglądające, bliskie ideałowi – i piękne 🙂
Dobrze powiedziane. Niestety z definicją piękna jest tak jak z d**ą i szczoteczką do zębów, każdy ma własną. Czasem naszą definicję musimy zbudować począwszy od odkrycia prawd podstawowych, co do których zgodni będą wszyscy interesariusze.
Za największy problem w drodze do ideału uważam ludzkie EGO, które potrafi przysłonić zdrowy rozsądek. Bywamy głusi na argumenty, skupiając się na własnym subiektywnym poczuciu piękna, zamiast dążyć do odkrycia piękna obiektywnego, co czasem kończy się takimi potworkami jak Pałac Parlamentu w Bukareszcie.
Kluczowe jest “dążenie do ideału”. Nie ma idealnych projektów 🙂
podobnie jak nie ma ciał doskonale czarnych….
i nikt nie twierdzi że są, problem w tym, że nie znając ideału nawet nie wiemy czy warto się za projekt brać. Kolejna rzecz nielubiana przez wielu dostawców nie tylko IT: studium wykonywalności… Bardzo wiele zarzuconych projektów zostało rozpoczętych choć nie miało to żadnego realnego uzasadnienia. Idiotyczna “prawda” w rodzaju “wszyscy wiedzą, że się nie da, a ten co nie wiedział zrobił” jest typowym bełkotem guru “samorozwoju”…
To nie jest kwestia znajomości ideału, tylko mądrego podejścia do wdrożenia. Np. błędem jest zakładanie, że każdy system informatyczny usprawni działanie przedsiębiorstwa. Należy wykonać “badanie” – nazwijmy je studium wykonalności – które zweryfikuje założenia. Zgadzam się, że takie badanie powinno obejmować szerszy zakres niż sam system, ale powinno też nie być zbyt szczegółowe ze względu na koszty.
W informatyce wszystko da się zrobić, tylko nie wszystko ma sens i się opłaca 🙂
Wdrożenie systemu IT, dotyczy to jakiegokolwiek narzędzia pracy, ma w zasadzie dwa cele: usprawnienie lub umożliwienie robienia czegoś. Co do pracochłonności Studium wykonywalności: ono także musi być rentowne. Dlatego najpierw należy ocenić co zyskamy jeżeli “usprawnimy lub umożliwimy robienia czegoś”, potem trzeba ocenić ryzyko i ustalić budżet na studium wykonywalności.
Jak porównywać model idealny z rzeczywistym ? Jest na to sposób np w Visual Paradigm ? Generowanie takiego porównania w dokumentacji projektowej było by potężnym narzędziem w wykrywaniu ograniczeń, długu technologicznego a także w ocenie ryzyka i kosztu utrzymania projektu.
Jeżeli podejdziemy do tego tak, że as-is to model rzeczywisty a to-be to idealny to jesteśmy w domu :), pytanie brzmi “co podlega porównaniu” czyli jakie kryteria oceny (coś jak u ludzi: porównać można oceny w szkole, wzrost, wagę,… ale coś z tego trzeba wybrać). A pojęcie ‘długu technologicznego” bardzo mi się podoba, tu jeżeli uznać, że stan idealny to stan “robimy to zgodnie z zasadami” to takie porównanie jest dobrym narzędziem do oceny tego długu…