Dość często spotykam się z opiniami, że teraz oprogramowanie pisze się zwinnie bo jest to proces twórczy i “nieplanowalny”, jedynym sposobem są prototypy, klient nie wie czego chce, pracujemy metodą “programowania ekstremalnego”, bo tylko tak klient może szybko zobaczyć efekty i odkryć swoje wymagania. I dalej jeszcze potok podobnych argumentów. Niestety projekty te, dotyczące procesów biznesowych, a nie tylko rozbudowanych wizytówek firm czy całych systemów portalowych, często kończą się fiaskiem (znacznie przekroczone terminy i budżety, a nie raz pozwy do sądu). Dzisiaj kilka słów właśnie na temat tak zwanych “projektów internetowych”.
Cztery lata temu (Dziwne projekty …) komentowałem pewien dziwny projekt. W artykule tym napisałem między innymi:
Szukając powodów takiego stanu rzeczy [problemy z tymi wdrożeniami] odkryłem ciekawą rzecz: szukając w Internecie haseł pozwalających odnaleźć firmy wykonujące strony WWW dla firm generalnie pojawiają się firmy specjalizujące się w portalach i serwisach społecznościowych. Nawet jeżeli mają na swojej liście referencyjnej duże firmy czy instytucje publiczne to strony te mają często właśnie wady opisane w tym artykule.
Jak temu zaradzić? Wydaje mi się, że podstawowym błędem jest angażowanie do tych [biznesowe oprogramowanie] projektów właśnie firm specjalizujących się w komunikacji internetowej a nie w tworzeniu aplikacji biznesowych. Jeżeli firmie specjalizującej się tworzeniu wizytówek internetowych i portali promocyjnych czy wizerunkowych, zlecimy wykonanie serwisu, którego celem jest samoobsługa zakupów, reklamacji czy składania wniosków, to serwis ten będzie prawdopodobnie wyglądał jak Nasza Klasa albo YouTube (albo inne cudo Web 2.0 a ja do dziś nie wiem co to jest i nikt nie potrafi mi wytłumaczyć).
Na czym polega ów problem?
Otóż faktycznie na rynku mamy wiele firm, które mają ogromne doświadczenie w tworzeniu, nawet bardzo rozbudowanych, stron i portali WW. Bardzo doświadczeni programiści, graficy, specjaliści od “wygodnego poruszania się po stronie”, doskonale radzący sobie z szybkim pisaniem prototypów w językach skryptowych typu PHP, Ruby itp. Mają bardzo duże osiągnięcia w tej dziedzinie i wiele referencji. To faktycznie projekty wręcz skazane na stosowanie zwinnych i ekstremalnych metody pracy.
Dlaczego te firmy bardzo często rozkładają się na tak zwanych projektach biznesowych? Moim zdaniem kluczowym powodem są próby stosowania metod pracy i doświadczeń wyniesionych z projektów portalowych na projekty biznesowe. W projektach portalowych ok. 90% logiki stanowi widok i poruszanie się po stronie WWW. W projektach biznesowych jest raczej odwrotnie, ekrany to może 10% złożoności, reszta to wewnętrzna logika biznesowa, reguły biznesowe, złożone zależności między obiektami biznesowymi (ot choćby pomiędzy fakturą, zamówieniem, reklamacją, cennikiem, systemem upustów i kredytów kupieckich czyli terminów płatności). Portale internetowe to złożone struktury stron WWW i relatywnie bardzo proste rejestry (kont użytkowników, podstron itp.) i raporty (w zasadzie głównie filtry). Firmy te bardzo często ignorują standardowe wzorce projektowe, choćby te zalecające całkowitą separację logiki biznesowej od obsługi ekranów (i pakują część tej logiki w formularze ekranowe co dość szybko źle się kończy).
“To ma być przez WWW więc zlećmy to firmie od WWW”
Co się stanie, gdy firma, np. tak zwana agencja interaktywna, mająca wieloletnie doświadczenie w tworzeniu nawet bardzo wyrafinowanych portali internetowych, dostanie zlecenie np. na tak zwany system biznesowy?
Zastosuje swoje zwinne metody pracy, czyli całą logikę biznesową wpakuje (tak planuje zrobić, bo czemu nie, do tej pory tak było) w portal, zacznie od tworzenia formularzy ekranowych, wytworzy kilka rejestrów (prostych tablic danych) i szybko pokaże klientowi “działający prototyp”, którego cała logika, obejmująca niestety tylko przepływy ekranów i zawartości rejestrów, jest zakodowana w tych formatkach ekranowych. W literaturze przedmiotu można spotkać nawę tej części: “cyniczny quick win”.
Co się dzieje dalej? Dalej klient po kolei zgłasza kolejne wymagania (bo pracujemy szybko, zwinnie i ekstremalnie) takie jak np. “klienci mają indywidualne ceny wg. systemu upustów”, “klienci mają dedykowane terminy płatności na bazie systemu reguł wynikającego z ich dotychczasowych obrotów”, “reklamacje są przyjmowane na bazie terminów gwarancji, które są różne, zależnie od typu produktu” itd. System portalowy zaczyna być od środka rozsadzany rosnąca ilością logiki biznesowej “przypinanej” w przypadkowe, wynikające tylko z bieżącego kontekstu (bo nie ma architektury ani logiki całości systemu), miejsca baz danych i ekranów. W efekcie każde kolejne życzenie zamawiającego, owocuje kolejnymi, coraz kosztowniejszymi, rozliczanymi “czas i materiał” etapami, dość szybko dochodzi do momentu, gdy kluczowym ograniczeniem rozwoju systemu jest sam rozwijany system. Pojawiają się coraz częściej odpowiedzi programistów: “tego się tak nie da zrobić”. Załatwienie bardziej złożonej sprawy na stronie WWW taje się trudne bo odbywa się po prostych tabelach, czyli “po prostych rejestrach”. Ktoś z Państwa odnajduje się w tym scenariuszu?
Jak można to robić?
Popatrzmy na poniższy diagram:
System, którego celem jest “prowadzenie biznesu” przez internet (nazywane B2B, B2C, itp.) to połączenie dwóch zupełnie różnych obszarów: pierwszy to strona “portalowa”, której celem jest wywołanie zainteresowania, atrakcyjne przekazanie informacji o firmie, zachęta do skorzystania z oferty, reklama itp. To ten obszar działań, który w tradycyjnym kontakcie z klientem realizuje sprzedawca. Kolejny krok, to obsługa typowo biznesowych zdarzeń, takich jak przyjęcie zamówienia czy wcześniejsze przygotowanie oferty, to złożona logika biznesowa.
Projektując internetowy system obsługi klienta tak na prawdę rozwiązujemy dwa zupełnie odrębne problemy: musimy zastąpić sprzedawcę naszą nową stroną WWW oraz obsłużyć zdarzenia, które wygeneruje nasz (tu wirtualny) sprzedawca.
Mamy tu dwa odrębne projekty: opracowanie portalu, i to jest robota dla agencji interaktywnej. Drugi, to zaprojektowanie, wytworzenie (albo opisanie wymagań i zakup gotowego na rynku) i zintegrowanie z portalem, czysto biznesowego, złożonego, oprogramowania “wypchanego” trudną i złożoną logika biznesową.
Dlatego takie projekty należy dzielić na komponenty, na (pod)projekty, z których każdy można (i ma to sens) realizować odrębnymi metodami pracy. Pierwszy (portal) “zwinnie”, drugi – logikę biznesową – planując i projektując. Architektura bazująca na wzorcach mogła by by wyglądać tak:
Użytkownik pracuje z komponentem, odpowiedzialnym za wszelką specyfikę środowiska, w którym pracuje (pracownik i komputer PC w firmie, klient przez portal WWW, klient przez smartfona). Uznając zasadę hermetyzacji, logika biznesowa jest wyłącznie w jednym komponencie, nie ma jej w komponencie obsługującym GUI (nawet, jeżeli jest to rozbudowany portal WWW obłożony elementami reklam, logiki ofertowej czy atrakcyjnej grafiki prezentacyjnej). Portal WWW to może być rozbudowany CMS (Content Management System np. taki jak wordpress). Mam nadzieję, że widać “zło” jakie wyrządzi umieszczenie jakiejkolwiek logiki biznesowej w komponentach bezpośrednio dostępnych dla użytkownika: logika będzie powielona z różnymi ograniczeniami w wielu miejscach. Zarządzanie jej zmianą będzie koszmarem.
Niewątpliwą zaletą takiej architektury jest pełna swoboda w kolejności wdrażania poszczególnych grup użytkowników rożnych środowisk oraz całkowita niezależność wszystkich tych komponentów, czyli zmiany w jednym nie będą się propagowały na pozostałe. Tezy jakoby umieszczanie części logiki biznesowej w komponentach odpowiedzialnych za obsługę użytkownika na stronie niszczą powyższe zalety i prowadzą do sytuacji, w której każda zmiana zawsze wymaga przeglądu i testowania całego systemu.
Czuję się w obowiązku zaprotestować przeciwko insynuacjom jakoby proces zwinnego budowania aplikacji z definicji nie jest planowany 🙂 Otóż z założenia jest i powinien być planowany.
Chciałbym też zwrócić uwagę, że wspomnienie tu programowania ekstremalnego odbyło się chyba przez pomyłkę, albo miał Pan na myśli coś innego niż to: http://en.wikipedia.org/wiki/Extreme_programming.
Nie wyważa się otwartych drzwi – jeśli wymagania są określone i niezmienne to po co stosować metodyki do zmiennych i nieokreślonych wymagań? 🙂
Mowa o planowaniu – agile/scrum – w sensie “kto i czym się jutro zajmie”, czy planowaniu polegającym na określeniu co i po co ma powstać, zanim powstanie?
Ja tylko opisuję to, co spotykam w praktyce :), co do nazw (brak planu, programowanie ekstremalne) to ja tylko cytuje to, co słyszę na prezentacjach tych firm… nie jestem specjalistą od sportów ekstremalnych. Po drugie nie ma pojęcia “zmienne wymagania”. Jeżeli “wymagania” to “cechy decydujące o przydatności czegoś”, to zmienne mogą być co najwyżej cele projektu, jednak cele sensownie zarządzanych projektów nie zmieniają się w trakcie trwania projektów. Magiczne i mityczne “zmienne wymagania” to raczej wyraz bezsilności firm rzucających się na programowanie bez zrozumienia biznesowego celu projektu i bez planu.
Proszę się więc odnieść do scenariusza opisanego w części “Zlećmy to firmie od WWW”…
Mam na myśli “co”->”jak”->”kiedy”->”kiedy”, czyli całym procesie. Bez określenia “celu” (“co”) bardzo trudno jest kończyć projekty :).
Co do “po co” to już różnie z tym bywa. Jak klient bardziej świadomy to obejdzie się bez głębszej analizy, a jak nie to analiza jest niezbędna.
Będę się upierał :), pojęcie “zmienne wymagania” istnieje i jest starsze niż informatyka. Jako dowód przedstawię istnienie pojęcia “zarządzanie zmianą” 🙂
Faktem jest, że termin “zmienne wymagania” jest używany jako “zasłona dymna”, gdy pojawia się niechęć (brak kompetencji) do przeprowadzenia analizy lub planowania.
Co do przykładu z “Zlećmy to firmie od http://WWW...”
Dla mnie to oczywista oczywistość, że należy to podzielić na moduły (2, 3 … więcej?), a może i aplikacje. Ponieważ: tak jest łatwiej, bardziej uporządkowanie, bezpieczniej, można tym lepiej zarządzać, …. itd. Co do różnych metod pracy to moim zdaniem nie ma to znaczenia. Z opisanego przykładu wynika, że ta firma po prostu nie ma kompetencji w oprogramowaniu biznesowym. Klient błędnie założył, że medium (WWW) definiuje wykonawcę.
Zwinność metodyki polega na dostosowywaniu się do potrzeb klienta i projektu.
Pamiętać też trzeba , że każda metodyka jest dla LUDZI, a nie zespół dla metodyki. Czyli niektórzy będą dobrze się czuli pracując w metodykach zwinnych, a inni w waterfall (lub innych).
Jeden komentarz: nie istnieje pojęcie “klient świadomy” bo klient nie jest developerem. Zaś my wiemy, że “dla mnie to oczywista oczywistość, że należy to podzielić na moduły (2, 3 ? więcej?), a może i aplikacje. co najważniejsze :)” ale niestety nie dla każdego jest to taka “oczywista oczywistość”. Ale z tym, ze “Zwinność metodyki polega na dostosowywaniu się do potrzeb klienta i projektu.” do mnie nie przemawia chyba, że jesteśmy lekarzem, który pozwala sobie by pacjent dyktował lekarzowi receptę… i nie widzę tu żadnego związku z samopoczuciem ;). Powtórzę się: metodyka (w szczegółach) nie ma żadnego znaczenia, tu się zgadzam, faktycznie ważne by się wybranej metodzie pracy dobrze czuć ale są pewne zasady, których łamanie to szukanie kłopotów: np. pomijanie etapu “proof of concept”. Po drugie nie do końca zgadzam się, że to metody są dla ludzi a nie odwrotnie, bo metody są po to by obniżać ryzyka projektów i mogą być (i nie raz są) “uciążliwe” dla ludzi (np. dokumentowanie spotkań, żądanie danych źródłowych w postaci dokumentów w nie słowotoków…)
Nie można stawiać znaku równości pomiędzy zwinny podejściem, a aplikacjami napisanymi z jakością prototypu (logika biznesowa w UI, brak testów automatycznych itd.). To że wspomniane firmy tak podchodzą do wytwarzania oprogramowania wynika z ich braku doświadczenia w dużych projektach ze skomplikowaną logika biznesowa. Podejrzewam, że skończyło by się to tak samo niezależnie od użytego procesu wytwórczego. Jeśli ktokolwiek próbuje usprawiedliwić jakość swojego “dzieła” (a raczej jej brak) przyjętym procesem który wykorzystuje, to jest to co najmniej nie poważne.
Zgadzam się w 100% z wyjaśnieniem: “To że wspomniane firmy tak podchodzą do wytwarzania oprogramowania wynika z ich braku doświadczenia w dużych projektach ze skomplikowaną logika biznesowa.”, problem w tym, że to robią, mamią klientów tym, ze “będzie szybko i tanio” i nazywają to robią “Agile”, … Zgadzam się, że żaden proces wytwórczy nie implikuje jakości kodu (oprogramowania), ale moim zdaniem trudno też nazwać proces pozbawiony etapu “proof of concept” sensownym procesem wytwórczym …
Po kilku pytaniach mailem, dopisałem akapit z architekturą w UML.
1.”klient świadomy” “klient bardziej świadomy” 🙂
2.Zdrowie jest pacjenta, a nie lekarza. Lekarz nie powinien i nie ma prawa leczyć wbrew woli pacjenta (oprócz przypadków ubezwłasnowolnienia). Jeśli pacjent i lekarz nie mogą się dogadać co do sposobu leczenia, pacjent udaje się do innego lekarza. Jeśli klientowi nie podoba się sposób podejścia do projektu wykonawcy (analityka, developera itp.) to szuka innego. Nie wyobrażam sobie umowy realizowanej bez wzajemnego zrozumienia i współpracy, bo developer/analityk sobie coś wymyślił i tak ma być bo to lepiej. Nie chodzi tu o wchodzenie sobie w kompetencje. Klient i wykonawca cały czas komunikują się na poziomie wymagań, potrzeb i celów.
To: “Zdrowie jest pacjenta, a nie lekarza. Lekarz nie powinien i nie ma prawa leczyć wbrew woli pacjenta” to bardzo cyniczna formuła, bo lekarz składa przysięgę Hipokratesa: “przede wszystkim nie szkodzić” a IT developerzy – wielu – właśnie szkodzą zjadając budżet klienta, obiecując nie raz coś, czego nie są w stanie dostarczyć …
Kolejny cynizm to uznanie, ze klient jest dorosły i sam wybiera … w Kodeksie Cywilnym istnieje pojecie usługi profesjonalnej nakładające na usługodawcę tak zwane “staranne działanie”, na bazie tego zapisu niektóre firmy programistyczne stosujące “agile” przegrywają procesy w sądach o odszkodowania za np. brak dokumentacji co dowodzi “niestarannego działania” 😉
Kolejny cynizm: w relacji lekarz-pacjent nie ma pojęcia wzajemnego zrozumienia, bo pacjent nie ma pojęcia o medycynie, podobnie jak nie ma pojęcia o prawie zlecając coś prawnikowi, czy nie zna obcego języka zlecając coś tłumaczowi itp. Są określone ryzyka i zatajanie ich (lub ignorowanie) jest cynizmem. Prawo budowlane chroni nas przed śmiercią ofiar katastrof budowlanych, dlatego wymusza określone podejście. Katastrofy projektów IT to nie śmierć ludzi a budżetów (może poza oprogramowaniem sprzętu medycznego ale tam “agile” jest zakazane).
Daleki jestem od przekonywania do jakiejkolwiek metody pracy ale moim zdaniem, przerzucanie 100% ryzyka projektu na klienta i branie za to pieniędzy jest w moich oczach cyniczne, czego zresztą wyrazem jest forsowanie umów T&M przez “zwinne” zespoły.
Proponuję, z braku ścisłej definicji, nie używać pojęcia “metody zwinne”, a pisać o stosowanych fazach procesu wytwarzania oprogramowania. Dwie kluczowe to proof of concept (PoC) i wykonanie. PoC do dowód słuszności np. logiki i architektury kodu, który to projekt i jego PoC powinien powstać przed wytworzeniem kodu. Druga rzecz to stosowanie (lub nie) wzorców projektowych itp. to jest architektury rozwiązującej problem zmienności wymagań – to decyduje o jakości efektu końcowego. Jednak znowu wraca temat tego, ze projekt architektury powinien powstać przez powstaniem kodu. Zaczynanie projektu od razu od kodowania jest po prostu ryzykowne i prowadzi często do powstania niskiej jakości oprogramowania.
“Zaczynanie projektu od razu od kodowania jest po prostu ryzykowne i prowadzi często do powstania niskiej jakości oprogramowania”
To zbyt posunięta generalizacja.
Często zaczęcie od kodowania jest najbardziej optymalnym podejściem. Dotyczy to zwłaszcza projektów innowacyjnych, nieszablonowych. Np. PoC-e z którymi się spotkałem były w większości testami, czy technologia zadziała. Czyli zaczynano od kodowania, aby sprawdzić koncepcję architektury.
PoC to nie tylko testy technologii (i raczej rzadko są to testy technologii) a testy pomysłu na realizację określonej logiki w taki a nie inny sposób (np. jak implementacja zareaguje na zmiany gdzieś tam…), np. jak skonstruować kilka agregatów by bardzo prawdopodobne przyszłe zmiany nie wymagały przerabiania całego komponentu. I o to chodzi, testy architektury zaczynane od razu jej implementacji (czyli od kodowania) to pominięcie oceny samego pomysłu na papierze, co jest o niebo tańsze.
Odpowiedzialność za własne czyny to nie cynizm.
Rzetelne wykonywanie swojej roboty – zgodnie z dobrymi praktykami tj. informowanie o możliwych konsekwencjach podjętych przez klienta decyzji – to nie przerzucanie ryzyka.
Cynizmem jest przerzucanie odpowiedzialności na kogoś, kto nie zna się na tym co kupuje, to klasyczne nabijanie w butelkę osoby kupującej używany samochód a nie znającej się na samochodach, od nieuczciwego sprzedawcy sprzedającego picowane samochody na giełdzie. Owszem, można powiedzieć, że jak ktoś tak kupuje to jego problem w końcu jest dorosły. Ja zadaje pytanie: czy to usprawiedliwia nieuczciwość sprzedawcy używanych samochodów?
Jeżeli zaś idziemy w kierunku dobrych praktyk, to one raczej nie zalecają kodowania z pomijaniem PoC. Samo informowanie klienta o skutkach nie jest dobrą praktyką, bo mogę go regularnie informować, że kolejna zmiana wystroju mieszkania spowoduje w “mojej technologii” wyburzanie całości, ale nie jest to dobra praktyka polegająca na rzetelnym informowaniu klienta, a paskudna praktyka prowadzenia na koszt klienta nieprzemyślanej budowy…
Moim zdaniem, przytłaczająca większość programistów nie potrafi niczego poza kodowaniem, i nie jest to ich wada, wadą jest dopiero uznanie, że tylko kodowanie prowadzi do powstania oprogramowania.
Ad.PoC: Testowanie rozwiązania na papierze to takie “pobożne życzenia”, że będzie działać 🙂
Niestety nie… “testowanie koncepcji na papierze” pozwala oszczędzać setki mendejsów programistów… (ale nie mam na myśli sprawdzania literówek w kodzie programisty, od tego są inne testy). (Tu więcej o testowaniu pomysłu czyli proof of concept.)
Witam
Panie Jarosławie, ciekawy i interesujący artykuł.
Zastanawiam się czy biorąc pod uwagę, że “klient przeważnie nie jest świadomy bo nie jest developerem” właśnie chociażby dla tego nie powinno się zawsze budować prototypu czy makiety pokazującej “działanie” projektowanej aplikacji biznesowej.
Nie chodzi o zaczynanie od makiety ale wcześniej czy później powinna się moim zdaniem pojawić po to żeby klienta bardziej uświadomić co dostanie.
Tylko, że problem większości oprogramowania biznesowego nie polega na jego wyglądzie, a na tym co i jak ten program przetwarza….Jeżeli więc mowa o portalu reklamującym firmę, gdzie 90% tego co chce klient to treść ekranu, to jestem się w stanie zgodzić, ale jeżeli problem polega na tym, ze jeden prosty ekran np. faktury sprzedaży (a jej wygląd reguluje ustawa), ma pod sobą złożony np. system rabatowania i kredytów kupieckich (logika ustalania upustów i terminów płatności), to metodą prototypowania tu żadnego problemu nie rozwiążemy za to kolejnymi prototypami nabijemy koszty projektu (dodam, że projekty zwinne to nigdy umowy fixed-price). Podaje ten przykład bo widziałem naście projektów wdrożeń np. systemów CRM kończących się w sądzie, dlatego że dostawca bardzo szybko dostarczał strony WWW ale nie udawało mu się zaimplementować (obiecanego) “zarządzania sprzedażą”.
“Makieta albo śmierć!!!” (żarcik taki :))
Zgodzę się, że makieta nie rozwiąże złożonych problemów technicznych, które dzieją się w tle i są “core” biznesu. Nie można przeceniać jej wartości. Myślę że powinno się ją traktować jako dobre uzupełnienie analizy i opisu procesów biznesowych, a nie jako wytycznych dla programisty 🙂
Tu chyba wszystko zależy od firmy, Pan zna przypadki procesów sądowych gdzie projekt został położony mimo że miał makiety i strony www, ja znam takie, gdzie budowa dużych systemów biznesowych rozpoczynała się od makiet i była kończona projektem zrealizowanym w terminie. Z tym że… makieta była tu finalnie częścią dokumentacji a nie jej głównym elementem :).
Makieta to taka karoseria dla samochodu (warstwa prezentacji z powiedzmy jakąś minimalną logiką zaszytą i nic ponad to). Bez silnika i całych bebechów samochód nie pojedzie, bez makiety klient (czy też sponsor projektu) może mieć problem z ogarnięciem całości. Tak więc chyba po prostu nie ma co przeceniać jej roli, można (dla wygody klienta i programisty) ją rozrysować i zrobić. Na pewno nie zaszkodzi, trochę tylko wydłuży proces analizy, na pewno ten czas zwróci się w dwójnasób na etapie programowania.
Wypada się zgodzić :), dodam, że makiety ekranów (lub wzory dokumentów) to standardowy – nie tylko u mnie – element definicji przypadku użycia. Ważne by nie zapominać, że 99% samochodu jest pod maską 🙂 i same makiety nic nie powiedzą o tym jak jest skonstruowany :).
Ci co zapominają o tym to Ci, którzy później spotykają się z klientem w sądzie 🙂
🙂