Pytanie moje: skoro OPZ opisuje [przedmiot zamówienia] w sposób jednoznaczny i wyczerpujący oraz zastrzeżeniem tajności [w ofertach przetargowych] nie mogą być objęte nazwy (firmy) oraz adresy wykonawców, a także informacje dotyczące ceny, terminu wykonania zamówienia, okresu gwarancji i warunków płatności zawartych w ofertach, to gdzie tu miejsce na inne "tajne informacje informacje posiadające wartość gospodarczą" w ofertach?
Po co dokumentować (modelować) AK? Przede wszystkim po to by zrozumieć jak działa organizacja, a potem by móc świadomie, znając ryzyko, podejmować decyzje o wprowadzaniu zmian do niej. [...] Czy to musi być jakiś standard np. TOGAF? Nie jestem przekonany. ArchiMate (notacja zalecana w TOGAF) to nic innego jak system pojęciowy. Czy mamy wybór? Oczywiście, że mamy. Od dawna OMG dostarcza sprawdzone i otwarte standardy notacyjne.
Ćwiczenie myślowe dla czytelników ;): biorąc pod uwagę znane Wam lub dostępne w sieci opisy metod pracy Agile, innych mniej lub bardziej sformalizowanych, "przyłóżcie" je do powyższego opisu poziomów. Czy nie macie wrażenia, że metody zwinne to jedyny sposób pracy w firmach na pierwszym poziomie? Czy nie macie wrażenia, że inne metody pracy niż czas i materiał, nie mają żadnego sensu w firmach na pierwszym poziomie dojrzałości? Jakie to ryzyko i straty (diagram powyżej)?
(developer nie jest w stanie stworzyć żadnego rozwiązania tylko na bazie obrazków).Trudno z tym artykułem polemizować, a jednak rzesze analityków, i o dziwo developerów, chyba większości firm IT, jako produkty analiz wymagań przedstawiają tylko owe prototypy czyli "user story", mock-up'y ekranów, tabele itp. W środku jest jakaś określona logika i to ona jest kluczowym wymaganiem.
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…
