Swego czasu pisałem, że
… opis ?co? system ma robić to stanowczo za mało, tak na prawdę nie definiuje on niczego poza tym, w jaki sposób może zostać wykorzystywany. Przypadek użycia jest dosłownie ?przypadkiem użycia systemu?, ale przypadków użycia jest nieskończenie wiele. Na ile sposobów wykorzystujecie posiadane oprogramowanie?
[…] Tak więc dokument wymagań to nie tylko przypadki użycia [listy pól czy prototypy ekranów] . Te są raczej testem poprawności rozwiązania, czy model jest poprawny (przypominam, że przypadki użycia, poza ich scenariuszami, zawierają stan początkowy i stan końcowy akcji użytkownika). Dokument wymagań to model (tu model dziedziny), który po zaimplementowaniu, będzie się zachowywał tak jak tego oczekujemy a przypadki użycia będą jedynie dowodem na to, że jest on poprawny. […] Jeśli model przypadków użycia to model tak zwanej czarnej skrzynki, to model dziedziny (bo tak się on nazywa) to tak zwana biała skrzynka. (Czy wymagania opisują tylko to ?co? system ma robić? | Jarosław Żeliński IT-Consulting).
Ogólnie konkluzja jest taka, że czarna skrzynka nie daje niemalże żadnej wiedzy o tym ja ona działa. Niedawno wpadł mi przed oczy artykuł traktujący o tym samym, konkluzja autora (wnikliwym polecam cały artykuł):
Sure, you put a lot of time into creating a prototype, a mockup, screenshot, or wireframe (are there any other names for the user interface drawing I?ve missed?). You may have drawn it on a whiteboard, in VISIO, or even used a requirements tool to create it. At the end of the day, no matter how much time you spend on it, it?s nothing more than a picture. And those of you who have worked in IT know developers cannot code and create a solution solely from a picture. (A Prototype is Nothing More Than a Picture > Business Analyst Community & Resources | Modern Analyst > Business Analyst Articles & Systems Analysis Articles | Modern Analyst).
(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.
W kwestii rysowania vs. modelowanie polecam mój stary tekst Modelowanie a rysowanie.
Pozwolę się nie zgodzić. Lub też, zgodzić, ale tylko przy założeniu że na działanie oprogramowania składa się wyłącznie wykonywaniue kodu przez komputer.
Tak jednak nie jest. Potrzebujemy makiet i prototypów, i to bardziej niż jest to obecnie praktykowane. Dlaczego?
Są wg. mnie 3 powody:
1) Użytkownicy
2) Zespół
3) Ryzyko
1) Skuteczność oprogramowania zależy od użytkowników.
Drogie i ryzykowne projektowanie skutecznego rozwiązania IT używanego przez ludzi bez uprzedniego testowania i eksperymentów z interfejsem. Każdy kawałek software jest inny.
Niedocenienie wagi doświadczenia użytkownika końcowego może doprowadzić w najlepszym wypadku do wzrostu skarg na supporcie a w najgorszym do odrzucenia rozwiązania przez odbiorców.
Narzędzia które frustrują użytkowników są przez nich używane tylko wtedy gdy jest to absolutna konieczność i jeśli tylko będą mogli będą wspomagać się innym oprogramowaniem
2) Tworzenie opgrogramowania to gra zespołowa.
Dopóki sofware nie powstanie istnieje w 3 miejscach. W głowach “biznesu” , w głowie projektanta i, przy odrobinie szczęścia, w dokumentacji. Może czasem w głowie analityka.
Warto zauważyć, że to co ma w głowie biznes jest często jedynie kolektywnym wyobrażeniem tego jak dane rozwiązanie ma funkcjonować. I jest zniekształconym odwzorowowaniem procesów biznesowych.
Ten zniekształcony obraz muszą przefiltrować analityk i projektant. A następnie przekaząć go developerom. O ile proces biznesowy można przekazać jedynie za pomocą dokumentacji, logikę działania złożonych formularzy czy kontekst przepływu przez kolejne widoki z perspektywy użytkownika da się pokazać jedynie rysując je.
3) Tworzenie oprogramowania jest eksperymentem, za każdym razem.
Rzadko kiedy zdarza się sytuacja by dany kawałek oprogramowania był projektem który da się szczegółowo zaprojektować ze szczegółowo określonymi z góry założeniami.
Jeśli tak jest powstają projekty nieskuteczne lub jakieś potworki programistyczne. A większości powstają po terminie, niezgodnie z wymaganiami i poza budżetem.
Prototypowanie jako jedna z metod pozwala skuteczniej negocjować wymagania oraz testować rozwiązania zanim zostaną wdrożone.
Zatem, podsumowując, uważam że nie jest prawdą stwierdzenie że prototyp to tylko obrazek. To narzędzie komunikacyjne pomagające skuteczniej podejmować decyzje co do kierunku rozwoju projektu oraz pomagające redukować ryzyko w projekcie. Pomaga też podnosić jakość efektu końcowego. We wprawnych rękach, oczywiście.
Nie można w projektowaniu oprogramowania oddzielić logiki biznesowej od cech “miękkich” użytkownika, choćby dlatego, że żaden budżet nie zakłada osobno developmentu “dla biznesu” i “dla usera”. Ostatecznie to ludzie tworzą organizacje, nie software.
Myślę, że mieszamy tu dwa elementy tworzenia jakiegokolwiek rozwiązania ale po kolei.
1). Nie rozumiem związku skuteczności oprogramowania i użytkownika, jeżeli ktoś projektuje kalkulator to jego skuteczność nie ma nic wspólnego z tym kto i jak go używa (i czy w ogóle). Owszem, może się pojawić problem wygody pracy z nim (np. klawisze będą zbyt małe i zbyt blisko siebie), ale to nie problem logiki działania kalkulatora. Zgadzam się, że frustrujące narzędzie będzie używane z oporami ale ta frustracja często ma miejsce gdy użytkownikowi ograniczamy swobodę (np. z powodów biznesowych nie pozwalamy stosować określonych, zbyt ryzykownych dla firmy, scenariuszy: nie wolno wystawić faktury bez zamówienia). Owszem zły interfejs użytkownika także może być przyczyna frustracji ale nie o tym tu piszemy.
2). Jak pokazać tylko na kolejnych ekranach, logikę działania systemu skoringowego lub naliczenie rabatów na fakturze? Skoro dowolny program można rozłożyć na obiekty składające się z atrybutów i metod to jakimi “ekranami” przekażemy wiedzę o metodach (a tu tkwi serce oprogramowania)? I na koniec: jak, bez dokumentacji przekażemy w umowie pomiędzy biznesem a dostawca oprogramowania cel projektu? Co do logiki złożonych formularzy: czym jest złożony formularz? Bo patrząc na dokumenty księgowe czy na formularze urzędowe są to statyczne ekrany, ich wypełnianie nie jest żadnym wyzwaniem. Tu mogę tylko zauważyć, że implementacja np. deklaracji PIT w postaci kilkunastu formularzy zbierających dane pokazujących się na ekranie w jakiś złożony sposób nie jest dobrym pomysłem ale tu wkraczamy w “gusty” czyli “jak projektujemy GUI” w ten wątek to inny temat 🙂
3). Z tym zupełnie się mogę zgodzić, chyba, że metodą jest “praca czas i materiał aż skończymy”. Tworzenie oprogramowania może być bardzo dobrze planowanym procesem podobnie jak budowa drapacza chmur, to że jest duży nie znaczy, że niemożliwy do zaprojektowania na samym początku. Owszem, projektowanie jest kosztem i pochłania czas, ale tu w grę wchodzi oszacowanie ryzyka i nic więcej. Otóż jeżeli znany jest cel (a warto go znać) oprogramowanie da się szczegółowo zaprojektować, co zresztą nie ja jeden robię.
Za zakończenie: prototyp (w rozumieniu mock-up) to tylko obrazek, ale faktycznie jest także narzędziem komunikacji. Tu jednak komunikujemy jedynie GUI i ewentualnie jego zachowanie, ale nie logikę (przepływ ekranów to senariusz pracy a nie logika biznesowa). Owszem GUI to element oceniany jako pierwszy i tego nie negujemy. Niestety, cytując jednego z moich klientów (zerwał umowę z firmą programistyczną) “pokazanie mi na prawdę ładnego GUI już po kilkunastu dniach pracy z moimi pracownikami było bardzo cyniczne ze strony dostawcy, bo zachęcił mnie do dalszego finansowania projektu; niestety nie udało się nawet po kilkunastu tygodniach uzyskać poprawnego naliczania rabatów, poprawnego naliczania prowizji dla sprzedawców ani raportowania kosztów działu sprzedaży”. I niestety widuje takie problemy dość często (zresztą głównie w takich przypadkach jestem angażowany).
Co do oddzielenia cech miękkich (tu rozumiem chodzi o GUI, ergonomie itp.) od logiki oprogramowania, to akurat jest to łatwe w rozdzieleniu tak jak wyraźnie oddzielne są od siebie komponenty wzorca MVC czyli osobno logika biznesowa, osobno GUI i osobno reszta technologii.
Na koniec powiem tak “tylko przy założeniu że na działanie oprogramowania składa się wyłącznie wykonywanie kodu przez komputer.” Oprogramowanie (zrobione) to właśnie wykonywanie kodu przez komputer, cała reszta to “ludzie i narzędzie ich pracy”, którym może być właśnie to oprogramowanie. Warto moim zdaniem oddzielać proces projektowania i wykonania młotka, od dywagacji nad pracą stolarza przybijającego gwoździe tym młotkiem. To dwa różne projekty: pierwszy to projektowanie narzędzia pracy, drugi to temat dla szefa stolarni stawiającemu zadania stolarzowi. Jeżeli pozwolimy by to stolarz a nie jego szef zarządzał pracą, to z reguły źle się to kończy. Moje doświadczenie mówi, że przyczyną problemów w projektach programistycznych jest sytuacja, w której programiści ze stolarzem (praca zespołowa) “naprawiają” stolarnię…
Uzupełniając powyższą odpowiedź: nie da się udokumentować gry w szachy tylko serią widoków planszy z kolejnymi rozstawieniami. Takich widoków (kolejne ekrany) mogą być setki, możliwych scenariuszy tysiące, a i tak nie zastąpią dwóch stron opisujących zasady (reguły biznesowe) tej gry.
Innym przykładem jest flet, można je tworzyć, tworząc masę kolejnych prototypów na bazie opisu flecisty i na bazie jego oceny w końcu dojść do instrumenty, który dobrze stroi i jest wygodny do gry. Jednak wystarczy przeprowadzić “analizę”, poznać zasady fizyki i akustyki, by za pierwszym razem obliczyć właściwe średnice i odległości otworów. Z flecistą ustalimy już tylko elementy ergonomii (mock-up). Robienie fletu metodą kolejnych prototypów jest wielokrotnie kosztowniejsze i bardziej pracochłonne w porównaniu z poprzedzającą jego konstruowanie analizą i obliczeniami fizycznymi.
Wydaje mi sie, ze mowicie o dwoch roznych prototypach. Jarek pisze o prototype w sensie mockup’u, czyli po prostu grafice przedstawiajacej GUI, a Cyryl o dzialajacym programie, pisanym “quick and dirty”, ale takim, ktory da sie poklikac i sprawdzic, czy logika (przynajmniej jej czesc) dziala i jak dziala.
Cytowany artykuł dotyczy faktycznie “martwych” prototypów GUI. Jestem jednak zdania, że prototypy ?quick and dirty? to nic innego jak bardziej pracochłonny (ale bajerancki) mock-up, który wymaga albo wywalenia do kosza albo refaktoryzacji. Kilka takich cykli (ile “mendejsów wymaga stworzenie kolejnej wersji ?quick and dirty?) szybko zniweluje “korzyści” z braku wcześniejszej analizy i projektowania. Nie twierdzę, że rezygnacja z wcześniejszego projektowania logiki nie daje żadnej szansy sukcesu. Ale wykazano, że prawdopodobieństwo szybszego sukcesu jest nie do policzenia przed rozpoczęciem projektu, więc jakiekolwiek obietnice przed rozpoczęciem projektu, że użycie metod zwinnych da korzyści są nieuprawnione.
Coz… musze zawsze brac poprawke na to ze piszesz z punktu widzenia systemow biznesowych. Osobiscie pracuje jako programista w dziale R&D i wlasciwie nasza jedyna “metodologia” to rapid prototyping. Tutaj zdecydowanie koszt analizy i projektowania przekroczylby koszty prototypu :). Wlasciwie w zalozenie naszej pracy wpisane jest to, ze po tygodniu pracy klient obejrzy, pocmoka i powie “ladnie panowie, bardzo ladnie, ale wiecie co… to sie raczej nie sprzeda (produkcja nie bedzie chciala tego wdrazac), nie chcemy juz uzywac , sprobujmy z ” (gdzie X i Y to dowolne API, framework, technologia, you name it).
Co do R&D nie raz pisałem, że to “badania” a nie “projekty” 🙂 i tu zgadzam się z Tobą w 100%. Ja faktycznie ze “start-up’pami” nie wiele ma wspólnego. Obserwując rynek, mam wrażenie, że większość tego co wyrosło ze “stron internetowych” to właśnie takie R&D, jednak w moich oczach “szkodliwe” jest przenoszenie przez wielu developerów metod pracy skutecznych w projektach R&D na projekty “biznesowe”, które jednak maja swój cel, termin i budżet.
Moje zdanie jest pomiędzy.
Nie zgodzę się, że prototyp to tylko obrazek. Korzystając z bardziej zaawansowanych narzędzi niż VISIO, np. Axure, możemy w szybki sposób wytworzyć klikalną makietę, której celem jest zobrazowanie klientowi rozwiązania, które otrzyma finalnie dopiero za kilka miesięcy. Takie makiety mogą uruchamiać formularze, prezentować zawartość list rozwijalnych itp.
Natomiast nie wyobrażam sobie, żeby oprzeć dokumentację analityczną jedynie o makietę. Wówczas pominiemy całe mięso czyli to o czym była mowa w artykule źródłowym.
Najważniejsze w projekcie wykorzystującym prototypu jak np. makiety jest znalezienie złotego środka. Czyli optymalnego czasu jaki poświęcimy na opisanie logiki, której nie widać na makiecie, minimalizujące pracę odtwórczą jak np. opisywanie pól tekstowych, które nie posiadają logiki.
W kontekście polecam zapoznanie się z pewną ideą:
GUI to jedno, logika wewnętrzna to drugie, a komunikacja z klientem to trzecie. Klient w większości wypadków jest wstanie zrozumieć dobrze GUI.
To troszkę naciągana teoria, “klient często nie rozumie logiki którą realizuje” – to zależy kogo pytamy. Jeżeli “szeregowych pracowników” zgoda, jeżeli ich szefów, bywa różnie, jeżeli przestudiować papiery firmowe i prawo, tę logikę da się zrozumieć i opisać. Opis tej logiki nie raz także przerasta użytkownika, większość pracowników firm realizuje zarządzenia zarządów nie rozumiejąc ich celu – i nie muszą. Logika biznesowa tkwi w regułach biznesowych a tego najlepszy, “klikalny” mock-up nie opisze bo to dziedzinowe elementy systemu. To, że klient rozumie GUI absolutnie nie znaczy, że GUI to wszystko. Zwracam uwagę, że większość z nas doskonale posługuje się kalkulatorem (rozumie GUI) i prawnie nikt nie rozumie algorytmu pierwiastkowania. Projekt GUI kalkulatora jednak nie pozwoli go oprogramować.
Panie Jarosławie, myślę, że mówimy faktycznie o dwóch różnych obszarach.
Wszędzie tam, gdzie interakcja człowieka z oprogramowaniem wpływa na wskaźniki biznesowe prototypowanie pomoże, i będzie wskazówką dla developera. Nie może być oczywiście jedynym elementem dokumentacji.
Nawet przytoczony przez Pana przykład kalkulatora będzie wymagał testowania, o ile nie tworzymy kopii 1:1 już funkcjonującego rozwiązania. Z tym, że to odbywa się zanim powstanie jakakolwiek dokumentacja. I może być jej pomocną częścią.
To część roli dziedziny którą się zajmuję (interakcja człowiek – komputer czy zagadnienia związane z użytecznością i doświadczeniem użytkownika).
To na pewno dwa różne obszary. Prototyp, w rozumieniu “interakcji człowieka z oprogramowaniem” to faktycznie zupełnie inny obszar niż “logika działania systemu”. Myślę, że nikt rozsądny nie zaneguje potrzeby testowania (prezentowania) prototypu interfejsu użytkownika. Problem widzę tym, że ten prototyp jest TYLKO prototypem tego interfejsu… Uznanie, że pakiet mock-upów to kompletna dokumentacja oprogramowania (co widzę w umowach) jest kompletnym nieporozumieniem, była by to prawda tylko wtedy, gdyby oprogramowanie było zestawem CRUDów (zarządzanie prostymi rejestrami). Owszem wizytówki internetowe i proste CMSy nimi są, ale na pewno nie oprogramowanie biznesowe nafaszerowane złożonymi regułami biznesowymi. Niestety bardzo wielu programistów (i całe firmy) podchodzi do programowania jak do internetowej wizytówki. Napisanie rejestru stron WWW wraz z rejestrem jej użytkowników to trywialny problem. Zastosowane takiego podejścia już np. do tworzenia systemu CRM jest najgorszą makabrą, co nie przeszkadza wielu firmom oferować takich pomysłów i jako cyniczne umowy czas i materiał.