W ostatnim artykule zwracałem uwagę między innymi na bardzo ważny element analizy i projektowania jakim jest abstrahowanie od detali, ponieważ: 

…analityk musi abstrahować od wszelkich detali, bez tego projekt zostanie już na samym początku ?zabity? ich ilością. [1]

Nieco wcześniej (2013 r.) pisałem o tym, kiedy uzgadniać detale, które i gdzie one są: 

Cała logika biznesowa jest wykonywana wewnątrz aplikacji (informacje o ewentualnych błędach pojawią się po zatwierdzeniu formularza), np. upust może być sprawdzony (albo naliczony) dopiero po skompletowaniu danych wymaganych do jego wyliczenia, czyli będzie to kilka różnych pól (najmniej dwa :)). Bywa, że do wyliczenia czegoś potrzebne będą dane nie wprowadzane do danej formatki faktury, np. saldo klienta. [2]

 

Tym razem kilka słów o tym jak skomplikować i zabić projekt już pierwszego dnia. Jednym z najbardziej ryzykownych sposobów rozpoczynania projektu jest rozpoczynanie od konsultacji z użytkownikiem w kwestii interfejsu użytkownika. Prowadzi to do sytuacji, w której jeszcze nie mamy żadnego pojęcia o logice biznesowej i architekturze aplikacji, a już deklarujemy to jak będzie się ona komunikowała z użytkownikiem (ciekawe na jakiej podstawie?). 

Do napisania tego artykułu skłonił mnie ten wpis:

The role of design still puzzles many agile teams I work with. When should the design activities take place?  Who should carry them out? How are design decisions best captured? This blog tries to answer the questions by discussing a user-centric, iterative, and collaborative design process for Scrum and Kanban teams. [3]

Autor pokazuje jak “walczy” ze złożonością na tym etapie, ja pragnę zasugerować by do tej złożoności na tym etapie po prostu nie dopuszczać. Powyższy diagram pokazuje z czym walczy analityk, który doprowadzi do zebrania wyrwanych z kontekstu (tak, nie ma modelu logiki więc dyskusje o GUI są oderwane od kontekstu) “wymagań” (historyjki użytkownika, lewa kolumna tablicy Story Area), których zamawiający może “naopowiadać” bardzo dużo.

A jak inaczej? Pomoże nam stosowanie wzorców architektonicznych. Są one od lat dostępne w większości frameworków (szkoda, że bardzo często developerzy je ignorują). Poniżej prosty, abstrakcyjny model klasycznego wzorca MVC.

W architekturze wydziela się komponenty (separowanie odpowiedzialności): odpowiedzialny za obsługę dialogu z użytkownikiem (View), odpowiedzialny za technologie, jakość, bezpieczeństwo, sterowanie itp. (Controler) oraz odpowiedzialny za (całą a nie tylko dane!) logikę biznesową (Model). 

Zarządzanie złożonością polega tu na tym, by na początku analizy i projektowania abstrahować całkowicie od detali GUI! (a dokładnie od całej technologii czyli elementów View i Contoler).  Kluczową odpowiedzialnością aplikacji jest realizacja określonej logiki biznesowej. Na tym etapie powinien powstać model przypadków użycia rozumiany jako prosty dialog pomiędzy użytkownikiem a aplikacją, tu celem jest uchwycenie kluczowych wymagań jakimi są wymagane usługi aplikacyjne realizowane przez aplikację oraz opracowanie wewnętrznej architektury – Modelu, która te usługi zrealizuje. Dopiero po przetestowaniu całej logiki biznesowej na modelach, warto się zabierać na komplikowanie projektu poprzez opracowanie detali GUI, sterowania, bezpieczeństwa itp.. Postępowanie takie umożliwia wzorzec architektoniczny MVVM opracowany ponad 10 lat temu. Wzorzec ten wprowadza dodatkowy komponent pomiędzy komponenty View i Model: View-Model, który realizuje logikę dialogu GUI-użytkownik. Dzięki temu możemy wydzielić etap pracy nad GUI, jako osobny w projekcie, który zrealizuje (później) tak zwany “UX designer”, a developer zamieni pierwotnie abstrakcyjny komponent View na implementacje “View-View Model”.

Bardzo dobry opis tego podejścia:

W przypadku warstwy prezentacji można wykorzystać m. in. następujące rozwiązania: MVC, MVP czy Model-View-ViewModel. Ze względu na mechanizm wiązań (binding), programistom WPF oraz Silverlight, polecany jest wzorzec MVVM ? jest to technologia umożliwiająca bardzo łatwą implementację wzorca. […] …po co utrudniać sobie zadanie poprzez wykorzystywanie MVVM, zamiast pisać aplikację w klasyczny sposób (za pomocą code-behind)? W końcu wdrożenie praktycznie każdego wzorca projektowego wymaga trochę większych początkowych nakładów pracy.

Podejście Code-Behind (autonomous view ? AV) ma poważną wadę ? nie gwarantuje elastyczności oraz testowalności. Podsumowując, wprowadzenie wzorca [MVVM, przypis autora] umożliwia:

• niezależność logiki od sposobu wyświetlania danych,
• niezależność kodu od technologii, w której wykonana jest warstwa prezentacji,
• wykonywanie testów ? za pomocą MVVM czy MVP możliwe jest wykonanie testów zautomatyzowanych (np. jednostkowych),
• łatwą zamianę widoków (brak sztywnych powiązań między widokiem a logiką). [4]

(Tak: stosowanie wzorców podnosi początkową pracochłonność ale zwraca się z nawiązką w dalszych cyklach życia projektu.) Strukturę i historię powstania tej architektury zainteresowani mogą poznać także tu: 

Model View View Model (MVVM) 
In 2005, John Gossman, Architect at Microsoft, unveiled the Model-View-ViewModel (MVVM) pattern on his blog. MVVM is identical to Fowler?s Presentation Model, in that both patterns feature an abstraction of a View, which contains a View?s state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF and Silverlight to simplify the creation of user interfaces. MVVM is a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms to leverage core features of WPF such as data binding, commands , templates.

This diagram take from MSDN depicts MVVM Pattern in action.

[5]

 

Tak więc analizę i projektowanie warto zacząć od logiki i szkieletu architektury, a ta to przede wszystkim Model (dziedziny) systemu czyli kompletna logika biznesowa (utożsamianie modelu dziedziny z relacyjną bazą danych to poważny błąd i nieporozumienie). Po uporaniu się z tym etapem projektu ma sens opracowywanie detali komunikacji z użytkownikiem, bo dopiero teraz znamy wymagania i ograniczenia logiki biznesowej. Odkrywanie ich dopiero na etapie prototypowania  to stanowczo za późno, bo generuje to ogromne koszty cyklicznego refaktoringu kodu (albo kod szybko staje się “bryłą błota”). 

 

Bardzo często słyszę, że klient chce jak najszybciej coś zobaczyć. Rzecz w tym, że jeżeli się na to zgodzimy, powstaje i jest akceptowana masa tak zwanych “pobożnych życzeń”, a klient bardzo szybko się przywiązuje do tego co zobaczył na prezentacji (i nie chce odpuścić). W efekcie tworzy się spirala żądań, testów i poprawek, które szybko przekształcają “agile” w porażkę budżetu i harmonogramu. Praktyka pokazuje, że budżet zawsze ma limit, dlatego bardzo wiele takich projektów kończy albo w koszu na śmieci albo efekty stanowią tylko namiastkę tego co opisywała pierwotna wizja. Jeżeli zaś zaczniemy od jądra systemu a na koniec zostawimy sobie “makijaż” jakim jest GUI, szansa na sukces będzie znacznie większa. Problem polega na tym, że moda na “user-centric, iterative, and collaborative design” jest silna mimo tego, że jest przyczyną wielu porażek. 

Tak więc odpowiedź na pytanie jak poradzić sobie z życzeniami biznesu, brzmi: nie dopuszczać do ich wyartykułowania :). Projektowanie i tworzenie samochodu rozpoczyna się od podwozia i napędu a nie od deski rozdzielczej…

• 

• 

• 

• 

• 

• 

• 

• 

• 

[zaktualizowany [last-modified]]

Niedawno pisałem na temat “modelu systemu” i “modelu dziedziny systemu”. Oba te pojęcia są sobie bliskie, pierwsze jest bardzo ogólne, dotyczy systemu zawężonego do jego dziedzinowej specyfiki. Model dziedziny systemu to także, w inżynierii oprogramowania, nazwa konkretnego komponentu, nazywanego Model, w architekturze opartej na wzoru MVC. Swego czasu pisałem, że (Czym jest a czym nie jest model dziedziny…):

Pojęcie system oznacza albo detaliczną strukturę określonej rzeczywistości albo abstrakcję ją reprezentującą (model systemu).

Jest to standardowe tłumaczenie tego pojęcia w literaturze z zakresu teorii systemów a także właśnie inżynierii oprogramowania [zotpressInText item=”{5085975:CHQUCPGA}”].

Mam właśnie za sobą kilka spotkań na targach IT Future Expo. Dotyczyły między innymi roli “product ownera”, analityka biznesowego i wymiany informacji pomiędzy developerami i “resztą świata”. Okazuje się, że największym problemem w projekcie jest: (a)  zrozumieć czego chce zamawiający biznes, (b) przetworzyć to tak by developer wiedział co ma zaimplementować. I tu niestety jest problem: developer owszem jest bardzo dobry w implementacji… i w niczym więcej. Co ciekawe, programiści, z którymi często mam do czynienia, nie potrafią (nie chcą?) myśleć abstrakcyjnie, oczekują typowej “kawy na ławę” (pierwszy dzień projektu a tu nagle ktoś pyta o typ pola “nazwisko”).  Gorzej, wielu z nich myśli wyłącznie o oddaniu kodu “na jutro rano”. Paradoksalnie, nie mała rotacja na stanowiskach programistów oraz regularne przenoszenie wszelkich kosztów i ryzyk na kupującego (który tego nie wie, bo nie rozumie tej technologii), powoduje, że przemyślana architektura całości to coś czego nie nikt robi,  developer po prostu koduje…

Nie walczymy z faktami, musimy się z nimi zmierzyć. Jak? Dać developerowi i egzekwować architekturę i logikę systemu jako wymaganie, a nie “zebrane wymagania”. Niestety, osoba zwana analitykiem, nie powinna postrzegać swojej pracy jako “kolekcjonera”  (“zbieranie wymagań” zawsze kojarzy mi się ze zbieraniem grzybów). Tak zwany analityk musi abstrahować od wszelkich detali, bez tego projekt zostanie już na samym początku “zabity” ich ilością. To się nazywa “utrata panowania nad złożonością projektu” a w konsekwencji “utrata panowania nad zakresem projektu”. W artykule o zegarze [1] opisałem jak to zrobić, tu opiszę źródła tego podejścia.

Analiza systemowa dziedziny problemu

Praca analityka powinna mieć charakter “naukowy”: na bazie faktów opisuje się logikę działania analizowanej organizacji [zotpressInText item=”{5085975:MG2IRJC4}”]. Przede wszystkim trzeba mieć świadomość, że badanym systemem jest np. organizacja a nie “tylko system informatyczny”. Organizacja (firma, urząd, itp.) to system składający się z ludzi i narzędzi jakich używają a całość jest sterowana regułami (prawo, regulacje wewnętrzne niespisane zasady itp.). Część z tych narzędzi to oprogramowanie. Jeżeli jest to oprogramowanie planowane do zakupu i wdrożenia, to znaczy, że ktoś musi zrozumieć stan obecny, zrozumieć cele i zaprojektować stan przyszły, zakładający istnienie nowego oprogramowania. Nie ma tu znaczenia czy będzie to oprogramowanie wspomagające produkcje czy prawnika i jego pracę. 

A gdzie wymagania? Wymaganiem jest projekt logiki (architektura) nowego oprogramowania. Czy to robota analityka? Tak, bo developer jest od wykonania implementacji.

Zegar. Abstrakcja systemu

Przede wszystkim warto uporządkować użyte tu pojęcia, które są często mylone lub źle interpretation:

• abstrahujemy od czegoś
• idealizujemy coś

Modelowanie polega na abstrahowaniu od określonych szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm.

[zotpressInText item=”{5085975:LKGQJ85W},{5085975:4VZTGC59}”]

Powinno paść pytanie:  Co system robi? (będzie robił jak go wdrożymy).

Jeżeli byłby to zegar, to “system wskazuje aktualny czas”. To jest biznesowy cel, uznano, że potrzebna jest stała znajomość aktualnej godziny, a nie “my chcemy mieć zegar”.

Teraz decyzja: Jak system to robi? Może to być zegar ścienny, analogowy, cyfrowy, może to być stale włączone radio. Decyzja brzmi: zegar ścienny analogowy (poniżej prototyp w postaci mock-up’u).

I dopiero teraz wiem o co pytać dostawców!

Tu drażliwy moment. Jeżeli opiszemy to tylko prostymi historyjkami użytkownika to może się skończyć tak, że developer po prostu stworzy kilkadziesiąt obrazów tarczy zegara i będzie je wyświetlał np. na wiszącym ekranie. To nic innego jak literalnie zrealizowane “zebrane wymagania”  (proszę się nie śmiać, tak to nie raz wygląda: “hardkodowanie” wymagań).

Dlatego warto jednak opracować abstrakcyjną architekturę rozwiązania czyli model opisujący mechanizm działania tego co chcemy otrzymać:

To nam zagwarantuje, że developer nie pójdzie na łatwiznę, że nasz zegar będzie się dał w przyszłości rozwijać i modyfikować [zotpressInText item=”{5085975:4XDEIZGV}”].

Teraz dopiero developer, mając (i słusznie) nieco związane ręce,  opracuje koncepcję realizacji (Jak system został zrealizowany?), my ją zatwierdzimy i dostaniemy np. to:

…albo oprogramowanie zawierające trzy komponenty i wyświetlacz.  Jak nam kiedyś przyjdzie do głowy dodanie datownika albo zamiana tarczy analogowej na cyfrową, to będzie to rozwój oprogramowania a nie kosztowne pisanie od zera (gdyby nam dano projektor z filmem z nakręconym zegarem analogowym). To jak ten system został zrealizowany zależy od developera, jednak jego logika i architektura powinny być opracowane wcześniej po stronie zamawiającego i narzucone developerowi (inżynierom).

Inny przykład. Popatrzmy na szklankę jako opisane historyjkami użytkownika wymagania:

• możliwość picia kawy,
• możliwość przechowania cukru,
• możliwość złapania muchy na stole,
• możliwość podlania wodą kwiatów,
• ….

Alternatywą dla tego opisu będzie:

– Szklanka jako projekt: “szklany cylindryczny pojemnik o średnicy 8 cm i pojemności 250 ml”.

Zastanówcie się, który z powyższych opisów będzie większym ryzykiem, jeżeli wyślemy go do huty szkła jako zamówienie na 1000 szt. szklanek dla pracowników… [zotpressInText item=”{5085975:LXK8VA68}”].

P.S.

Czy te “możliwości”  to przypadki użycia szklanki? Nie. Przypadek użycia szklanki, to co ona faktycznie robi (usługa systemu), to przechowanie/magazynowanie substancji ciekłej lub sypkiej z pewnymi ograniczeniami takimi jak np. maksymalna temperatura. Te możliwości to co najwyżej historyjki użytkownika… które są może dobrym materiałem do analizy ale nie są dobrym wymaganiem. Większość programistów, jak dostanie tak opisane “możliwości” jako wymagania, to je po protu wprost zakoduje i odda “system zgodny z wymaganiami”…  sami oceńcie jego przydatność teraz i w przyszłości…

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Dzisiaj pokazała się wersja 14.2 pakietu Visual-Paradigm. Podstawową nowością w wersji 14.2 są diagramy czysto biznesowe, które w czytelny sposób pokazują “biznesowy” proces analizy, działania na każdym jej etapie. Stanowią także sobą plan działania. Struktury TOGAF czy Siatki Zachmana są dla normalnego zjadacza chleba nieczytelne, teraz w końcu można szybko przygotować diagram poglądowy taki jaki chce zobaczyć klient: kilka pagoników, pod każdym wypunktowane kluczowe elementy. Śladowanie zagwarantowane na każdym etapie..

Na stronie What’s New in Visual Paradigm, poza innymi nowymi detalami znajdziecie zupełnie nową rzecz:

Customer Journey Mapping [1]

Customer Journey Mapping jest najczęściej definiowane jako wizualizacja “historii” klienta od momentu gdy określił swoje cele i potrzeby,  poprzez odczucia i bariery w kontaktach z nami, aż do zrealizowania zamówienia, na całej tej drodze. To narzędzie pozwalające zebrać wiedzę o kliencie i jego zachowaniach i potrzebach w jednym miejscu, w postaci zrozumiałej dla biznesu, czyli w takiej jaką jest w stanie bez dodatkowych szkoleń zrozumieć, zweryfikować i zaakceptować. Jest to informacja ogólna ale doskonale nadaje się do określenia np. zakresu projektu analitycznego i wdrożeniowego. Poniżej krótka prezentacja (i tutorial zarazem). 

Polecam też ciekawy opis tego do czego służy i jak może wyglądać: http://blog.uxeria.com/10-najciekawszych-przykladow-customer-journey-map/ .

 

Wpadł mi właśnie przed oczy ciekawy wpis na pewnym blogu:

Historia o tym w jaki sposób prawie straciłem firmę i sam dostarczyłem (bo nawet nie sprzedałem) sznur, na którym próbowano mnie powiesić. [1]

Zanim przejdę do sedna, przypomnę jeden z moich artykułów:

Na czym więc polega skuteczne zarządzanie? Na zrozumieniu, posiadaniu planu działania i przemyślanym tworzeniu ograniczeń. Robi tak każda większa firma: powstają zakresy obowiązków, wewnętrzne zarządzenia i procedury. To wszystko to nic innego jak ograniczenia. model organizacji, dający zrozumienie tego jak ona działa, to kompletny model pojęciowy ? nazwy i definicje podstawowych pojęć opisujących jej działanie (co to jest klient, produkt, kontrahent, ?), specyfikacja wszelkich ograniczeń czyli [2]

 

Kluczem do skutecznego zarządzania jest wizja działania firmy i zbudowanie wewnętrznych ograniczeń, które będą “trzymały” wszystkie zachowania pracowników na “właściwym kursie”. 

Bohater tej historii tak pisze o sobie:

W ciągu 9 lat działalności rozrosła się od jednoosobowej firmy do grupy ponad 60 pracowników i przychodów na poziomie 56 mln rocznie. Z powodu braku czasu na zmiany formy działalności przez cały ten okres działała w formie jednoosobowej działalności gospodarczej prowadzonej przez Dariusza Kuźniewskiego.

Jak widać, pomysł na biznes był dobry bo właściciel osiągnął sukces. Jednak, jak pisze w innym miejscu, nie zmienił swojego podejścia do zarządzania nią:

Nie pomyślałem, że celem tych osób jest tak naprawdę zniszczenie firmy, wykradzenie bazy klientów, ?przejęcie? kluczowych pracowników, przywłaszczenie sprzętu, pozyskanie ode mnie kapitału oraz kilka elementów, które dla dobra przyszłych postępowań nie mogę teraz wspomnieć. […] Nie muszę chyba wspominać, że wiele kopii umów 31 lipca br. tajemniczo zniknęło z działu księgowości.

Jedną z metod zarządzania ryzykiem jest rozkładanie uprawnień, tam gdzie ryzyko jest duże, jedna osoba nie powinna mieć “możliwości sprawczych”. W tym miejscu często słyszę, że firma mam być zwinna a procedury nie powinny stwarzać wąskich gardeł. Ogólnie to prawda, jednak każdy obszar firmy to inne ryzyka, i po prostu pewne rzeczy “muszą trwać” (to temat na inny artykuł…).  Co do zasady archiwum firmy powinno być samodzielnym działem, nie biorącym udziału w zawieraniu umów. Dlaczego? Bo jeżeli dostęp do umów ma osoba mogąca mieć interes w ich “zagubieniu” lub modyfikacji, albo ujawnieniu poza firmą, to to się prędzej czy później zdarzy. 

XXX przekazał mi dyski z monitoringu oraz z serwera wewnątrz firmy, a także klucze do magazynu zewnętrznego (które miał wyłącznie on), gdzie miała być wywieziona księgowość firmy i zbędne wyposażenie. Pojawiła się sugestia, że nie powinienem pojawiać się publicznie, bo ?wiele osób się na mnie szykuje?. […] 

Jakie było moje zdziwienie, gdy pojechałem do siedziby firmy przy XXX w Poznaniu, że: brama jest uchylona, boczne drzwi nie zamknięte, niewłączone alarmy, w serwerowni wyrwane wszystkie kable oraz zniszczona kamera. W samej firmie brak wiele elementów wyposażenia, niektóre pokoje wywiezione w pełni.

Nie ma o tym mowy wprost, ale z kontekstu wynika, że najprawdopodobniej wielomilionowy majątek firmy był bez żadnego nadzoru w rękach jednego pracownika. A wystarczyłoby, by po pierwsze były zapasowe klucze, by było monitorowane każde otwarcie i wejście do magazyny, by była procedura (zestaw reguł) o dopuszczalnych godzinach otwarcia magazynu z rejestracją każdego otwarcia. 

Równocześnie firma XXX zaczęła korzystać z chronionej bazy klientów kuzniewski.pl i zaczęła kontaktować się z klientami próbując ich przejąć naruszając przy tym prawa klientów i łamiąc ustawę o nieuczciwej konkurencji.

To jest to, co zawsze budzi mój uśmiech na twarzy, bo praktycznie pracownicy każdego działu sprzedaży, dla systemu CRM, zgłaszają wymaganie by system CRM “pozwalał na eksport danych klientów w formacie excel”. Dostawcy oprogramowania realizują te wymagania (z reguły sami są tymi, którzy te wymagania zbierają) bez zmrużenia oka. Ja nie pozwalam by wymagania dyktowali pracownicy (między innymi chroniąc firmy przed tym co powyżej), a jak już to przede mną zrobili, to wysyłam natychmiast rekomendację do Zarządu by takie jak to powyżej usuwać.

Nonszalancją wielu zarządów/właścicieli firm jest to, że godzą się na takie wymagania, ja wtedy staram się przekonywać do rezygnacji z takich niebezpiecznych funkcjonalności, bywało że z tego powodu (mój upór) zerwano ze mną umowę (czego nie żałuję). Robię to z prostego powodu: jeżeli na etapie składania oferty piszę, że coś tam potrafię, że mam jakieś doświadczenie, że przed czymś staram się ochronić klientów, to nie mogę łamać ani własnych zasad ani godzić się na to, by na moich oczach i z moją aprobatą klient szedł na dno.  To troszkę jak lekarz: jeżeli chory pacjent nie realizuje zaleconej terapii, lekarzowi pozostaje przerwać współprace z pacjentem, bo nie ma prawa go do niczego zmusić ale też nie musi przykładać ręki do postępującej choroby pacjenta czy nawet jego zgonu. 

Nie znam tego właściciela firmy, ale czytając jego emocjonalny (i chyba raczej tylko ratujący wizerunek) wpis, mam przed oczami wiele małych i średnich firm, które albo miały podobne “przygody” albo są doskonałymi kandydatami na takie. Porzekadło “mądry po szkodzie” to także niestety, wiele historii nieudanych wdrożeń z powodów jak wyżej… Duże firmy także nie są wolne od takich wad…

Na zakończenie, przypomnę, że

Problem zaczyna się gdy takich osób [pracowników] jest nie jedna czy kilka, a dziesiątki lub setki, w dużych organizacjach pojedyncze tysiące. Tu już nie mamy możliwości indywidualnego pokierowania zachowaniem (pracą) każdej osoby, udzielania wskazówek i obserwacji. Owszem, możemy udzielić stosownego instruktarzu każdej, to jednak wymaga dużej dyscypliny tego instruowanego, jeżeli czuje on ?wzrok? nadzorcy realizuje zadania, jeżeli nie, pozostaje wierzyć w jego zaangażowanie i uczciwość.[2]

Dlatego

każde wdrożenie jakiegokolwiek oprogramowania wspomagającego zarządzanie powinno być poprzedzone analizą i opracowaniem modeli (opisu mechanizmu) działania firmy, a nie serią wywiadów i kolekcjonowaniem życzeń pracowników. Te są z reguły przyczyną niepowodzeń takich projektów.