Od samego początku analizy i projektowania logiki systemu należy skupić się na tym "co i po co" a nie "jak". Zajmowanie się pytaniami "jak" (najgorsze pytanie analizy: jak Państwo to robią) na samym początku, prowadzi do zgromadzenia ogromnej ilości, nadmiarowych, szczegółów, które zamulają prace wszystkich członków zespołu projektowego. Szczegóły, te których znajomość faktycznie wnosi wartość, należy analizować na końcu, wtedy - mając szkielet całego projektu - wiemy które mają jakiekolwiek znaczenie.
Od czego należy zacząć? Od zbudowania własnej (lub własnego wariantu) metodyki jej tworzenia oraz zatrudnieniu Architekta. Czy to powinien być własny pracownik? Moim zdaniem nie, gdyż po pierwsze nie będziemy w stanie obciążyć go pracą na 100%. Po drugie powinien to być ktoś z zewnątrz, by nie był uwikłany w wewnątrzorganizacyjne zależności - Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją (podobnie jak lekarz domowy to raczej nikt z domowników).
Nagromadzenie danych to jeszcze nie jest nauka (Galileusz) Duże bazy danych na określony temat - najczęściej mowa o zachowaniach klientów ? to ostatnio temat pierwszych, najdalej drugich, stron gazet. BigData to temat przewodni konferencji i artykułów na pierwszych stronach periodyków branży IT. W 2011 roku artykuł na podobny temat kończyłem pytając: Budowanie modeli na bazie małych partii danych jest po pierwsze wiarygodniejsze (paradoksalnie) niż proste wnioskowanie statystyczne, po drugie daje szanse odkrycia czegoś nowego. W czym problem? To drugie jest nie możliwe z pomocą deterministycznej maszyny jaką jest komputer. To…
Z powyższego płynie także kolejny wniosek: autor specyfikacji wymagań, powinien kontynuować projekt jako osoba zarządzająca wymaganiami, i bardzo dobrze jest jeżeli pracuje po stronie Zamawiającego, gdyż stanowi naturalny mechanizm kontroli pracy dostawcy np. oprogramowania. Zamawiający nie ma innej możliwości realnego, merytorycznego nadzoru nad dostawcą, to Zamawiający powinien zarządzać wymaganiami bo to w końcu jego wymagania!
Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie.
Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.
Często słyszę, że to trudne i pracochłonne (dodatkowe klasy w modelu) ale niestety zbyt prosty projekt potrafi być kosztowniejszy w rozbudowie w porównaniu z pierwotnym wytworzeniem, dlatego jak klient w ramach wymagań wpisuje (a wpisuje coraz częściej): system ma umożliwiać łatwe rozszerzenia funkcjonalności, to należy go tak projektować, w przeciwnym wypadku wymaganie to nie jest spełnione...
Druga uwaga: często sami klienci zabijają swoje projekty żądając na samym początku dokumentowania wszystkich szczegółów jakie im do głowy przyjdą nie potrafiąc jednocześnie opisać mechanizmu działania ich organizacji. To niestety często spotykane zjawisko, z którym moim zdaniem należy walczyć. Paradoksalnie złożoność systemów biznesowych tkwi w mechanizmie ich funkcjonownia a nie w danych które zbierają (których nie raz jest po prostu za dużo...)
Tak więc warto zawsze rozważać udział fazy analizy i planowania w całości projektu, mieć świadomość konsekwencji tej decyzji oraz w szczególności, planując budżet oraz czas na analizę i projektowanie, przyjąć, że dokumentacja analityczno- projektowa jest objętościowo najszczuplejszym "artefaktem" w całym projekcie (największym artefaktem jest kod) mimo, że nie najtańszym.
Na koniec przytoczę słowa jednego z moich klientów, dobrze doświadczonego kierownika projektów: każda oszczędzona godzina analityka projektanta, to dodatkowy tydzień pracy zespołu programistów.
W kontekście poziomów modelowania polecam książkę How Works Get Done , którą właśnie kończę czytać. Bardzo dobre kompendium wiedzy o modelowaniu procesów w kontekście tytułowego "jak ta praca jest wykonywana". Nie będę tu pisał streszczenia ;). Książkę gorąco polecam, jest napisana pragmatycznie przez praktyka, który jednak zaznacza, że skuteczne modelowanie, analiza, usprawnianie procesów i firm wymaga pełnego zrozumienia działania tych firm, zrozumienia wzajemnego wpływu ludzi, zasobów, mechanizmów, celów na produkty procesów, podkreśla także znaczenie i wskazuje korzyści z formalnego podejścia to analizy i modelowania (z naciskiem na słowo modelowanie a…
Moim zdaniem ten kto wymyślił ocenę pracy policji poprzez licznie ilości wystawionych mandatów (albo gorzej - ich wartość!) jest w moich oczach kompletnym ignorantem nierozumiejącym opisanego zjawiska. Wytłumaczeniem może być chęć pozyskania zwiększonych środków z mandatów, ale to jest nic innego jak działania na szkodę społeczności, którą się reprezentuje!
Cel samorządów, z tego co można wyczytać, to zapobieżenie wyrzucania śmieci np. do lasów przez naszych kochanych uczciwych obywateli, gdyż do tej pory obywatel płacił za śmieci, które od niego odebrano. Wystarczyło "zutylizować" śmieci na własną rękę i były oszczędności. Drugi powód to ekologia, czyli maksymalizowanie odzysku (tak zwany [[recycling]]). Czy aby na pewno?
miasto
Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości "map procesów", które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia. [...] jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.
otwartość oprogramowania (kodu) czyni go bardziej wiarygodnym, otwartość kodu skłania jego twórców do podnoszenie jego jakości (wstyd zabrania partaniny ;)), to czy jest darmowy czy nie, zależy wyłącznie od modelu biznesowego sprzedaży: twórca sam ustala czy zarabia na licencjonowaniu kodu czy na swojej wiedzy i pracy, "zamykanie kodu", to kwestia subiektywnego uznania twórcy kodu, czy stanowi on (treść) chronione know-how (jego przewagę konkurencyjną) czy nie... ale warto dodać, że przewaga stojąca na takiej tajemnicy ma jednak gliniane nogi (jak każda przewaga bazująca w 100% na tajemnicy).
