16 maja 2021 36:24 Odcinek 040

Agile vs. waterfall – jak najlepiej wdrażać sklep internetowy?

Wbrew powszechnej opinii, nawet najlepiej przygotowana umowa i zakres projektu nie daje żadnej gwarancji, że e-Commerce, który wdrożysz razem z agencją, dostarczy Ci pożądaną wartość i zwrot z inwestycji. Dlatego w dyskusji „agile vs. waterfall” odpowiedź będzie zupełnie inna, niż mogłoby się wydawać na pierwszy rzut oka.

Co w takim razie wybrać? W 40 odcinku omawiam zalety obydwu modeli i przybliżam scenariusze wdrożenia e-Commerce w obydwu przypadkach. Dowiesz się też, na co zwrócić szczególną uwagę, żeby odnieść sukces niezależnie od tego, na który model się zdecydujesz.

Listen to „040-agile-vs-waterfall-jak-najlepiej-wdrazac-sklep-internetowy” on Spreaker.

Dodatkowe materiały

Żeby uzupełnić wiedzę z odcinka, koniecznie posłuchaj innych odcinków Sztuki E-Commerce:

Odcinek „005 – Jak napisać dobry brief?”, dzięki któremu lepiej przygotujesz swoje wymagania dotyczące nowego sklepu internetowego
https://marekkich.pl/sztuka-ecommerce/005-jak-napisac-dobry-brief/
Odcinek „016 – Zanim zatrudnisz agencję e-Commerce”, w którym podpowiadam, na co zwrócić uwagę przy wyborze firmy wdrożeniowej
https://marekkich.pl/sztuka-ecommerce/016-zanim-zatrudnisz-agencje-e-commerce/
Odcinek „038 – Co składa się na koszt wdrożenia sklepu internetowego?”, z którego dowiesz się orientacyjnie, na jakie inwestycje szykować swój portfel
https://marekkich.pl/sztuka-ecommerce/038-co-sklada-sie-na-koszt-wdrozenia-sklepu-internetowego/

„Jeśli przystawisz drabinę do złej ściany, to każdy krok będzie stawiany w złym kierunku”.

Kiedy przygotowywałem się do nagrania odcinka i szukałem przydatnych materiałów, natrafiłem na właśnie te słowa. Od razu dobrze zagrały w mojej głowie i uznałem, że na tyle dobrze obrazują wiele kwestii, które dzisiaj jeszcze padną podczas tego odcinka, że to one właśnie zasługują na to, żeby rozpocząć rozmowę o wieloletniej już debacie dotyczącej wyboru pomiędzy agile a waterfall w realizacji projektów.

Zapamiętaj je dobrze, bo jestem bardziej niż pewien, że Tobie też mogą się jeszcze później przydać, chociażby do tego, żebyś lepiej zrozumiał temat, albo na przykład później mógł przekonać szefa, albo zespół do tego, którą metodę wybrać.

Zaproszę Cię na małą wycieczkę historyczną.

Jeżeli miałeś już do czynienia wcześniej z innymi odcinkami Sztuki E-Commerce albo znamy się, chociażby z LinkedIn, to pewnie dobrze wiesz, że biorę aktywny udział we wdrażaniu projektów e-Commerce gdzieś tak od mniej więcej dziesięciu lat. Co prawda dzisiaj to już bardziej udział merytoryczny, ale na samym początku dość szeroko korzystałem też ze swoich umiejętności technicznych, które wyniosłem ze studiów na Politechnice Wrocławskiej, czyli mówiąc najprościej, jak się tylko da, po prostu kodowałem te sklepy.

Myślę, że to wszystko dało mi spory przegląd sytuacyjny na wdrożenia projektów z wielu różnych perspektyw, od tej typowo technicznej i egzekucyjnej, aż po strategiczną na poziomie właścicieli biznesów.

Gdybyśmy cofnęli się do samego początku mojej historii zawodowej, to wtedy realizowaliśmy projekty w sposób, który prawdopodobnie jest Ci dość dobrze znany, bo jeszcze dzisiaj występuje bardzo często na rynku.

Na początku zaczynało się od zapytania o wdrożenie, najczęściej w formie dość ogólnego briefu. Na jego podstawie trzeba było przygotować już konkretny zakres prac do zrealizowania, no i oczywiście wszystkie wycenić, żeby było jasne, co tak naprawdę jest do zrobienia. Więc opisywaliśmy, jakie zrobimy projekty graficzne, jakie trzeba wdrożyć funkcje w sklepie, z czym się zintegrować i tak dalej.

Tak przygotowany dokument stawał się później załącznikiem numer jeden do umowy wdrożeniowej.

Sama umowa myślę, że też nie powinna być dla Ciebie jakoś mocno zaskakująca, bo jak pewnie się domyślasz, precyzyjnie opisywała produkt, który mieliśmy dostarczyć, etapy płatności, terminy, gwarancje, kary umowne plus ogólne warunki, jak na przykład sposób odbioru prac, przekazywanie praw autorskich i inne rzeczy, które w razie czego miały posłużyć działom prawnym za skuteczny oręż w walce o to, żeby ich klient wygrał w razie czego sprawy sądowe.

Można powiedzieć, że pracowaliśmy po prostu dość standardowo. Zresztą nie dotyczy to tylko realizacji projektów IT, bo podobnie buduje się na przykład domy, gdzie kupujesz projekt, wynajmujesz ekipę i później odbierasz efekty ich prac, po drodze gdzieś tam zaliczkując poszczególne etapy.

I w teorii brzmi to dość dobrze, bo wymieniasz pieniądze na produkt końcowy, który spełnia Twoje oczekiwania, które zostały opisane szczegółowo w załączniku do umowy.

Problem w tym, że jeśli prowadziłeś już kiedyś w taki sposób projekt, to mam naprawdę duże szanse trafić ze stwierdzeniem, że pewnie tak różowo wcale nie było. Moje doświadczenia były podobne. Im większy projekt, tym więcej pojawiało się niedopowiedzeń, które później przeradzały się w mniej lub bardziej otwarty i agresywny – nazwijmy to wprost – konflikt z klientem pod patronatem hasła „czy moje uwagi są w zakresie prac, czy są zmianą tego zakresu”.

No i wiadomo, gdybym postawił Ciebie w takiej sytuacji, to pewnie argumentowałbyś (i to często w pełnym przekonaniu o słuszności swoich słów), że dane prace są jeszcze w zakresie i agencja musi je wykonać w ramach kontraktu, a agencja, że jednak niekoniecznie (i to również często w pełnym przekonaniu o słuszności swoich słów).

Powstałby więc impas, który najczęściej eskaluje do bardziej agresywnych argumentów, typu odmawianie płatności po stronie klienta, na co agencja odpowiada najczęściej odmową wydania kodu projektu i tak to się wzajemnie później napędza, aż ktoś w końcu odpuścił lub rzeczywiście sprawa się formalizuje.

Trzeba przy tym pamiętać, że im większy projekt, tym takich dyskusji należy się spodziewać więcej. Z kolei im więcej dyskusji, tym gorzej dla projektu. W tym, co mówię, jest zarówno moje doświadczenie, jak i naprawdę wiele lat obserwacji i rozmów z różnymi klientami.

I dla mnie punktem zwrotnym w realizacji projektów był dokładnie 2013 rok, kiedy podpisałem ostatnią tego rodzaju umowę. I chociaż projekt koniec końców się udał, to, prawdę mówiąc, nie mam związanych z nim zbyt dobrych wspomnień. Chyba najlepszym obrazem efektów są dwie grube teczki zakresów, aneksów i ogólnie w moim odczuciu bezsensownej papierologii, która nigdy nie powinna powstać.

Zwróć tutaj uwagę – mimo tego, że na koniec dnia przecież projekt się udał, to nie udało się uniknąć zmęczenia i rezygnacji. Więc z jednej strony sukces wdrożeniowy i fajny rozwój klienta w kanale e-Commerce, a z drugiej dość traumatyczne przeżycia i decyzja „nigdy więcej”.

I rzeczywiście od tego momentu zmieniłem zupełnie podejście do realizacji projektów, a przez kolejne lata obserwowałem dyskusje o przewadze jednego sposobu nad drugim i vice versa. Dlatego dzisiaj poruszam temat, do którego zbierałem się praktycznie od samego początku powstania Sztuki E-Commerce. Opowiem Ci o obydwu podejściach do realizacji projektów i bez agresywnego przekonywania Cię do żadnego z nich, pomogę samodzielnie podjąć decyzję, w jaki sposób możesz wdrażać Twój następny sklep internetowy.

Wdrażanie projektów e-Commerce w modelu waterfall

Pierwszy model realizacji projektów e-Commerce już pokrótce przedstawiłem we wstępie do odcinka, więc teraz go trochę razem pogłębimy. Oczywiście cały czas mówiłem o waterfallu, czy też modelu kaskadowym, jeśli miałbym szukać polskiego odpowiednika na nazwę.

U podstaw waterfalla leży podzielenie całego projektu na mniejsze etapy, które następują kolejno jeden po drugim w taki sposób, że efekty prac poprzedniego etapu są jednocześnie wkładem do kolejnego. Na końcu wszystkich etapów jest już gotowy produkt, czyli w naszym wypadku sklep internetowy.

Idąc w kierunku bardziej praktycznym, opowiem Ci pokrótce o tym, jak w tym modelu byłby realizowany projekt wdrożenia e-Commerce.

Zanim programiści usiądą do napisania pierwszej linijki kodu, najpierw muszą powstać solidne fundamenty. Dlatego cały projekt zaczyna się od tego, że ktoś (i jest to najczęściej rola analityka biznesowego) musi zebrać wymagania organizacji dotyczące nowego sklepu. To jest pierwszy etap, w którym opisuje się najpierw strategię, a później na jej podstawie i na podstawie potrzeb reprezentantów organizacji, powstają szczegółowe opisy wymagań biznesowych, prototypy interfejsu i opis funkcjonalny.

W kolejnym etapie podobną pracę realizuje się po stronie technologii, czyli przygotowuje dokument, który jest specyfikacją techniczną. Na tym etapie po prostu schodzi się niżej do poziomu, który umożliwi później realizację i odbiór oprogramowania.

Tu następuje w zasadzie koniec ścisłej współpracy pomiędzy Tobą a agencją wdrożeniową.

Mając spisane wszystkie wymagania i szczegółową specyfikację, następuje etap wdrożeniowy, który zazwyczaj też jest jakoś podzielony, na przykład na wdrożenie, integrację i migrację danych osobno. Wdrożenie po prostu polega na tym, że cały zespół ma solidny punkt odniesienia w postaci dokumentacji lub specyfikacji projektowej i w sposób w miarę swobodny i indywidualny dla zespołu (o ile umowa nie przewiduje jakiejś konkretnej ramy) po prostu poszczególni członkowie zespołu odhaczają poszczególne wymagania tak, żeby na koniec można było odebrać działający projekt.

Na koniec tych prac najczęściej następuje etap stabilizacji, który polega na przeprowadzeniu jednej bądź kilku rund testów akceptacyjnych, poprawiania błędów i przygotowania projektu do uruchomienia produkcyjnego.

No i tyle. Zespół dowozi projekt, Ty go odbierasz, to kończy umowę, przynajmniej w tym pozytywnym scenariuszu, co, jak powiedziałem – bywa różnie. Więc waterfall daje Ci pewien szkielet realizacji projektu. W ramach tego szkieletu na samym początku precyzyjnie określasz to, czego potrzebujesz, a potem firma wdrożeniowa realizuje projekt zgodnie z założeniami i całość prac kończy się w momencie odbioru.

Na razie celowo pomijam to, czy taki scenariusz idealny jest w ogóle możliwy. Uznajmy na potrzeby chwili, że jest. W tym kontekście tak ustalona rama realizacji to tak naprawdę największa siła modelu waterfallowego, bo pozwala na pozbycie się zmiennych jeszcze przed rozpoczęciem prac i realizację projektu według ściśle określonych przez Ciebie wytycznych.

Wyłania się tutaj dzięki takiemu podejściu kilka dodatkowych pozytywnych konsekwencji.

Po pierwsze, Twój udział ogranicza się tylko do początku projektu i chociaż jest wtedy dość intensywny, to potem możesz ograniczyć współpracę z wykonawcą do odbioru poszczególnych etapów prac.

Po drugie – skoro wszystko jest jasne, to możesz zarówno oczekiwać terminu i związać ten termin karami umownymi, a po drugie możesz też oczekiwać konkretnej kwoty za realizację prac po stronie wykonawcy. To znacząco porządkuje rozwój Twojej firmy, bo dokładnie wiesz, kiedy czego się spodziewać i jakie inwestycje będziesz musiał ponieść na samą realizację.

No i po trzecie – na wypadek problemów chroni Cię gwarancja poprawnego wykonania sklepu, więc jakiekolwiek problemy zostaną naprawione w ustalonych w umowie terminach,

Na pierwszy rzut oka tych zalet jest tak dużo, że trudno w zasadzie się dziwić, że mógłbyś chcieć wdrażać e-Commerce dokładnie w ten sposób. I rzeczywiście – z moich obserwacji wynika, że cały czas wiele firm decyduje się na taki przewidywalny i bezpieczny model realizowania projektów.

Wdrażanie projektów e-Commerce w sposób zwinny

To był model waterfall, według którego sklep internetowy trzeba najpierw opisać tak, żeby nie było żadnych wątpliwości po stronie wykonawcy co do sposobu realizacji, a potem po prostu wdrożyć zgodnie z opisem.

To trochę tak, jak z pieczeniem ciasta, a może nawet łatwiej, bo w przepisach często jest coś takiego jak „szklanka mąki”, a ja później zawsze się zastanawiam, jakie autor ma szklanki na chacie. No i wydaje mi się, że jeszcze nikt nie integrował ciasta z systemem ERP, chociaż co do tego nie mam stu procent pewności.

Teraz czas na model zwinny. Żeby zrozumieć zwinność w realizacji projektów, warto by było, żebyśmy cofnęli się do początku roku 2001, kiedy to po raz pierwszy został ogłoszony manifest programowania zwinnego. Przeczytam Ci go. Manifest ten w całości brzmi następująco.

Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy zaczęliśmy bardziej cenić:

ludzi i interakcje od procesów i narzędzi,
działające oprogramowanie od szczegółowej dokumentacji,
współpracę z klientem od negocjacji umów,
reagowanie na zmiany od realizacji założonego planu.

Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.

Jeśli wsłuchasz się w manifest, to można go podsumować mniej więcej tak, że waterfall z wszystkimi swoimi etapami, dokumentacjami i sztywnym kontraktem może i jest cacy, ale jeszcze bardziej cacy są ludzie, współpraca, możliwość reakcji na zmiany i działające oprogramowanie.

Jak taka zwinna realizacja projektu mogłaby wyglądać w praktyce?

Pokażę Ci to na przykładzie scruma. Scrum to taki najbardziej popularny framework agile, który opisuje sposób realizacji projektu, czyli też daje pewne ramy, w których porusza się zespół wraz z klientem przez cały okres współpracy.

I teraz – w waterfallu mieliśmy etap analityczny, w którym współpracowałbyś z agencją nad zebraniem wymagań biznesowych i opisania zakresu prac w specyfikacji technicznej, a potem Twoja rola ograniczyłaby się do odbioru prac.

W modelu zwinnym jest inaczej.

Tutaj Twój czynny udział w projekcie i zaangażowanie będzie potrzebne przez cały czas trwania współpracy. Taka rola nazywa się product ownerem, który ja zawsze opisuję tak, że jest to osoba decyzyjna z punktu widzenia zespołu projektowego. Decyzyjna w takim sensie, że dobrze rozumie projekt, ma jakąś określoną wizję i współpracuje ściśle z zespołem wdrożeniowym, żeby tę wizję urzeczywistnić, a w trakcie trwania projektu ma moc sprawczą w organizacji, czyli być może nie jest w stanie samodzielnie podjąć niektórych decyzji, ale w tym wypadku jest w stanie sobie tę decyzję wydłubać sobie na wyższym poziomie, więc z punktu widzenia zespołu jest to rzeczywiście osoba decyzyjna.

Takim najważniejszym obowiązkiem product ownera jest opisywanie i priorytetyzacja prac w projekcie. W tym odcinku nie będę zagłębiał się w szczegóły scruma, ale bardziej dokładny opis pracy na pewno znajdzie się w Sztuce E-Commerce, bo myślę, że jest równie ważny, co sama idea pracy zwinnej, a przy okazji jest dość ciekawy, więc pewnie ściągnę kiedyś jakiegoś eksperta, który opowie o tym dużo bardziej dokładnie i pozwoli Ci lepiej zrozumieć zasady scruma.

Wracając do ról – po drugiej stronie jest zespół techniczny, który uwzględniając ustalone priorytety, będzie cyklicznie realizował jakiś fragment opisanego zakresu prac. Najczęściej przyjmuje się okresy dwutygodniowe, bo to jest wystarczający okres, żeby dowieźć coś fajnego, a jednocześnie niezbyt długi, żeby faktycznie mieć checkpointy w projekcie i go dobrze kontrolować.

Po takich dwóch tygodniach odbywa się demo, podczas którego prezentowane są prace, podsumowanie efektów i później cały cykl rozpoczyna się od nowa. Oczywiście cały czas mówimy tutaj o bardzo dużym uproszczeniu, bo są jeszcze różnego rodzaju spotkania po drodze i dodatkowe role, ale na potrzeby odcinka myślę, że na tym poziomie ogólności nam powinien zupełnie wystarczyć, a przy okazji będę mógł zwrócić Twoją uwagę na kilka interesujących rzeczy.

Najważniejsze – zakres projektu jest opracowywany i modyfikowany na bieżąco. Dzięki temu masz o wiele większą kontrolę nad projektem i możesz reagować na to, co na przykład dzieje się na rynku. 2020 rok pokazał, że taka możliwość reagowania na zmiany może być bardzo przydatna, ale nawet w mniej skrajnych przypadkach, niż epidemia koronawirusa, drobne korekty kursu zdarzają się praktycznie przez cały czas.

Druga kwestia to współpraca, która bardzo mocno wybrzmiewa w modelu zwinnym. Ja mówię zawsze klientom, że nie pracujemy ze sobą w modelu klient-dostawca, tylko pracujemy ze sobą w modelu my kontra użytkownicy docelowi. Dzięki takiemu połączeniu jesteśmy w stanie połączyć naszą wiedzę i kompetencje z wiedzą i kompetencjami naszych klientów, a tak naprawdę, mimo że to nasi klienci płacą za sklep, to de facto nie robimy go dla nich, tylko dla użytkowników końcowych. Więc taki podział, gdzie my działamy wspólnie, a po drugiej stronie są użytkownicy i ich potrzeby, jest chyba najbardziej optymalny model, w którym można pracować. A dzięki temu nie ma też potrzeby okopywania się jakimiś grubymi specyfikacjami technicznymi, które konieczne są w waterfallu, bo po prostu możemy ze sobą rozmawiać i najczęściej robimy to przez cały czas.

Trzecia sprawa – w ten sposób (czyli w modelu zwinnym) osiąga się dużo szybciej efekty. Co dwa tygodnie pojawia się jakiś przyrost w projekcie, no i dzięki czemu możesz szybciej zbierać feedback w organizacji czy od użytkowników końcowych, weryfikować na bieżąco przyjęte założenia i sterować dalszymi krokami w projekcie.

I czwarta – umowy są dzięki temu dużo mniej skomplikowane, bo nie musisz w końcu wymyślać dokładnie, jakie użytkownik będzie musiał na przykład uzupełnić dane w formularzu reklamacyjnym, który dopiero za rok będziesz wdrażał w Twoim sklepie. Dojdziesz do tego w momencie, kiedy ten formularz będzie bieżącą potrzebą do zrealizowania i wtedy się zastanowisz, jakie dane są konieczne i dzięki temu zyskujesz dużo czasu, który trzeba poświęcić na początku projektu na przygotowanie tych informacji w sposób nieodwracalny.

Myślę, że zgodzisz się ze mną, że takie podejście ma w sobie wiele zalet. Ścisła współpraca, dużo komunikacji, duża kontrola nad projektem i ciągłe dostarczanie efektów – brzmi atrakcyjnie i warto sobie zadać pytanie „kto by tego nie chciał w swoim projekcie?”.

Masz więc do wyboru agile i waterfall po drugiej stronie. Określiłbym to starciem dynamiki i dużej przewidywalności.

Który model powinien wygrać?

Waterfall czy agile – który model jest lepszy?

Mimo że dyskusje o tym, które z tych dwóch podejść jest lepsze, toczą się od wielu lat i nawet ten odcinek ma taki tytuł, to uważam, że to nie jest najlepiej postawione pytanie.

Albo może inaczej – to wcale nie odpowiedź na to pytanie powoduje, że dokonujesz jakiegoś wyboru.

Myślę sobie, że dzieje się tak dlatego, że właściciele, czy też przyszli właściciele sklepów internetowych niespecjalnie na co dzień zastanawiają się, czy chcieliby, żeby ich nowy e-Commerce był wdrażany w modelu kaskadowym, a może jednak zwinnie. W moich rozmowach z klientami zauważam często, że nawet nie ma u nich świadomości, że takie modele w ogóle istnieją. Więc te dyskusje to raczej na imprezach branżowych, tymczasem biznes niespecjalnie chce w nich uczestniczyć, o ile oczywiście ten wybór nie został podjęty z góry, bo najczęściej agencje rządowe na przykład specjalnie się nie zastanawiają nad modelem, bo tam od lat jest waterfall.

To, co jednak bardzo interesuje właścicieli biznesów, to odpowiedź na pytanie „ile zarobię na sprzedaży w Internecie?”. I to jest właściwe pytanie na dzisiaj.

I teraz, żeby w ogóle jakkolwiek móc jakoś przewidywać to, ile się zarobi, to trzeba przede wszystkim wiedzieć:

ile taki e-Commerce może w ogóle sprzedawać,
ile będzie trzeba na niego wydać?

Nas dzisiaj szczególnie interesuje ta druga kwestia. I tu pomału dochodzimy do sedna sprawy tego odcinka.

Okazuje się, że ROI to nie są żarty i dla firm naprawdę jest bardzo duża różnica, czy wydadzą 500 000 złotych na wdrożenie i potrwa ono rok, czy milion złotych na wdrożenie, które potrwa 2 lata. W tym drugim przypadku może się okazać, że taki sklep internetowy zwyczajnie nigdy się nie zwróci, bo przecież taką technologię też co parę lat trzeba zmieniać.

Więc najczęściej jest tak, że budżet i terminy to krytyczne czynniki sukcesu dla Twojego e-Commerce. A skoro tak jest, to często tok myślenia wygląda mniej więcej w taki sposób, że fajnie by było zagwarantować sobie obydwa te parametry w umowie. To z kolei prowadzi nas prosto do waterfalla, bo tam można zarówno wrzucić terminy, jak i budżet.

Niby fajnie, ale jednak na początku odcinka mówiłem o tym, że z tymi długoterminowymi kontraktami wdrożeniowymi bywa różnie, a nawet pokuszę się o stwierdzenie, że ogólnie raczej bywa słabo.

Spróbuję to teraz jakoś uporządkować, żebyśmy mogli pomału przechodzić do jakichś rekomendacji. Najlepiej będzie mi o tym mówić, przyjmując zmienność i poziom skomplikowania jako podstawowy punkt odniesienia w projekcie.

Są projekty, w których zmienność jest relatywnie niewielka, albo nawet czasami powinna taka być, to znaczy chcielibyśmy, żeby raz coś ustalić i później najlepiej nie zmieniać. Tak jest na przykład podczas budowy domu, odchodząc na chwilę od IT. Na początku powstaje projekt, a potem wjeżdża ekipa budowlana i leci według projektu. Iteracja nie znajdzie tutaj większego zastosowania, tym bardziej że z raz podjętych decyzji najczęściej trudno się wycofać. Na przykład wcale nie będzie łatwo ingerować w bryłę po tym, jak już skończyłeś dach. W oprogramowaniu zmiany są zazwyczaj trochę łatwiejsze do zrealizowania, bo można zazwyczaj wymienić kawałek kodu i nie burzyć wszystkiego (chociaż oczywiście nie zawsze).

W e-Commerce projektem o niewielkim stopniu skomplikowania może być na przykład wdrożenie sklepu w SaaS-ie albo wdrożenie jakiegoś pudełkowego ERP. Nie ma większej różnicy, czy skonfigurujemy dane oprogramowanie tak, czy inaczej, bo zajmie to mniej więcej podobną liczbę godzin. Analiza też raczej będzie w miarę przewidywalna, bo mamy na przykład 10 000 pól do skonfigurowania i trzeba sobie odpowiedzieć na pytanie „w jaki sposób je ustawić”, a potem to po prostu zrobić. Taki projekt też z zasady nie będzie cechował się dużą zmiennością, bo niewiele się w nim może zdarzyć.

Więc jeśli projekt wymaga jakiejś powtarzalnej, nieskomplikowanej i przewidywalnej pracy, to łatwo opisać jego zakres w dokumentacji, a później wdrożyć, zachowując duże bezpieczeństwo dla terminu i budżetu.

Pozostaje pytanie, czy podobnie będzie w przypadku dużych wdrożeń e-Commerce? Cóż, gdyby odpowiedź była twierdząca, to pewnie nie byłoby tego odcinka.

I rzeczywiście, większe projekty e-Commerce, czyli takie, gdzie trzeba zrobić więcej, niż tylko skonfigurować sklep, idą w parze z o wiele większą zmiennością i nieprzewidywalnością na przynajmniej kilku płaszczyznach.

Po pierwsze w takich wdrożeniach zakres będzie ulegał zmianom w trakcie trwania projektu. Często jest tak, że to, co jest wymyślone na papierze podczas analityki, w praktyce ulega przeobrażeniom. I to jest rzecz zupełnie normalna, bo zawsze jak się coś zacznie używać, to do głowy przychodzą nowe pomysły. Zawsze jest tak, że jak się później podrąży trochę bardziej temat, to też w szczegółach te prace się stają coraz bardziej skomplikowane.

Czasami te zmiany są dobre dla budżetu (bo z czegoś na przykład zechcesz zrezygnować), ale najczęściej jednak nie będą dobre dla budżetu, bo w wyniku drążenia coś trzeba dorobić. Te zmiany będą tym bardziej dotkliwe, im gorzej przygotujesz się do wdrożenia. Mówiłem w kilku odcinkach, że jeśli podchodzisz do realizacji z niegotową organizacją i dość ogólnym briefem, to ten zakres będzie dość mocno pływał i należy być na to gotowym.

Po drugie w dużych projektach, które trwają długo, w międzyczasie zmienia się też rynek. Jeśli projekt trwa kilkanaście miesięcy, to raczej nie ma siły, żeby coś w tym czasie nie wydarzyło się na rynku. Chociażby tak prosta sprawa, jak to, że w międzyczasie konkurencja wypuści coś nowego i trzeba zupełnie przemodelować wdrożenie tak, żeby było jak najszybciej na produkcji. Są też nowe trendy, no a 2020 rok dobitnie pokazał, że rynkiem potrafi też naprawdę porządnie zatrząść i wtedy w ogóle trzeba często szukać planu B, C, aż do W na wszystkie możliwe okoliczności.

Po trzecie zmienia się technologia. Internet tak goni, że chyba jeszcze nigdy nie realizowałem dwóch projektów w dokładnie tej samej technologii. Cały czas pojawia się coś nowego, niech to będą nawet małe zmiany typu nowa biblioteka lub wersja programowania, ale zawsze coś nowego jest. To powoduje znaczące utrudnienie w szacowaniu czasu pracy z dużym wyprzedzeniem.

No i po czwarte – o ile na przykład przy wdrożeniu małych ERP kilkadziesiąt tysięcy firm potrafi pracować na tym samym oprogramowaniu, tylko skonfigurowanym pod potrzeby każdej z nich, o tyle przy dużych e-Commerce każdy de facto będzie trochę inny. Od wyglądu po działanie. Więc w pewnym sensie każdorazowo mówimy tutaj o innowacji, którą trudno objąć jakimś stuprocentowo pewnym oszacowaniem godzinowym, a tym samym – budżetem.

Więc z jednej strony są zmiany (wewnętrzne i zewnętrzne), a z drugiej też pewien margines błędu, który może popełnić sama agencja.

Mógłbyś teraz powiedzieć (i zapewniam Cię, że słyszę to często), że w sumie to nie powinien być Twój problem, bo jak będą zmiany, to zrobi się aneks do umowy, a to, że agencja nie umie szacować swojego czasu pracy, to nie Twój problem. Tutaj znowu trudno nie zgodzić się z takim argumentem.

Ale tutaj musimy znowu wrócić do zakresu prac i specyfikacji technicznej.

Niezależnie od tego, jak bardzo się przygotujesz i napracujesz nad zakresem, który jest załącznikiem do umowy, nie da się, albo nigdy się jeszcze przez te wszystkie lata nie spotkałem z taką specyfikacją techniczną, która byłany w stu procentach kuloodporna. Według mnie nawet nie da się takiej napisać, bo:

trzeba by było zejść do tak dużego poziomu szczegółowości, że dokument musiałby mieć setki stron,
są jeszcze niemierzalne kwestie, jak „fajność” rozwiązania, jakość kodu, komunikacja w projekcie, zaangażowanie zespołu, poziom obsługi klienta i tak dalej.

Dużo rzeczy składa się na to, że jesteś zadowolony z projektu i zdecydowanie nie jest to tylko jego poprawność. A nawet najlepsza specyfikacja techniczna daje tylko poprawność, która niekoniecznie musi mieć związek z wartościowym projektem (chociaż poprawność jest oczywiście ważną składową, a nawet podstawą każdego udanego projektu).

Dlatego, mimo że być może faktycznie to nie jest Twój problem, że agencja nie umie szacować swojego czasu pracy, no to warto, żebyś pamiętał, że gwarancja budżetu w tym skrajnym wypadku, kiedy to agencja zaczyna dopłacać do projektu, może odbić się tym, że otrzymasz projekt tylko poprawny.

I może, żeby to jakoś zobrazować.

Powiedzmy, że masz do wdrożenia sklep internetowy, agencja wyceniła Ci go na 300 000,00zł, podpisujecie umowę typu fix price, jest specyfikacja i działacie.

Najlepszy scenariusz – wdrożenie kończy się sukcesem, w terminie, w budżecie i jesteś zadowolony, agencja też jest zadowolona. Takie projekty oczywiście też są, myślę, że na rynku jest pełno wdrożeń, które suchą stopą przeszły przez cały czas trwania projektu i wszyscy na koniec byli zadowoleni.

Bardziej prawdopodobny scenariusz to jednak materializacja tych ryzyk, o których mówiłem.

Pierwsze to zmiany zakresu projektu, a co za tym idzie zmiany w budżecie – w wyniku ewolucji projektu, zmian rynkowych, zmian w organizacji, czy nawet popełnienia błędu w założeniach. Mój ulubiony błąd to założenie, że wykorzysta się jakiś moduł do integracji z systemem ERP, a potem się okazuje, że ten moduł działa tak mniej więcej w 3 na 10 przypadków. No i oczywiście zmiana modułu na wdrożenie dedykowane to nie jest duży problem, ale kosztowo można się naprawdę zdziwić. W tym wypadku będziesz musiał podpisać aneks do umowy na zmianę i pewnie pluć sobie w brodę, że wyszło to prawdopodobnie zbyt późno, bo dopiero na odbiorze. Zresztą na odbiorze dużo rzeczy może wyjść, więc ten aneks potrafi być dość dużym dokumentem.

Drugie ryzyko to, że jednak agencja nie do końca poprawnie wyceniła swoją pracę. To zdarza się naprawdę każdemu, szczególnie gdy trzeba oszacować prace na tysiące, czy dziesiątki tysięcy godzin. Wtedy staniesz prawdopodobnie przed wyborem – albo podnieść budżet wdrożeniowy sklepu, albo stracić to, co nie wynika wprost ze specyfikacji, czyli na przykład jakość kodu, co odbije się tym, że późniejszy rozwój będzie trudniejszy lub bardziej kosztowny, albo ktoś i tak będzie to musiał poprawić, więc ten kredyt i tak kiedyś trzeba będzie spłacić.

Kiedyś obserwowałem wdrożenie projektu dla jednej z instytucji publicznych w ramach przetargu. Wszystko było fajnie, aż się okazało, że zaczyna gonić termin i prace trwają trochę dłużej, niż wynikałoby to z oszacowania. Pewnie w kontekście tego, o czym mówię, domyślasz się, na ile instytucja publiczna była otwarta na podnoszenie budżetu wdrożeniowego. Wtedy po raz pierwszy przekonałem się, jak duża jest różnica pomiędzy spełnieniem kryteriów akceptacyjnych a wywołaniem zadowolenia u klienta z projektu. Naprawdę nie życzę takich efektów nikomu, bo to są zupełnie dwa różne światy i uwierz mi, że każdy brief da się spełnić na wiele różnych sposobów, natomiast są sposoby, z których na sto procent nie będziesz zadowolony.

Więc podsumowując, podpisując umowę typu fix price, dajesz agencji gwarancję wypłacenia jej pieniędzy i dokończenia z nią projektu, a sobie gwarancję, że dostaniesz minimum poprawny projekt (bo to wynika wprost ze specyfikacji). To, czy to będzie więcej niż minimum, jest już obarczone jakimś ryzykiem.

W mojej ocenie taka gwarancja jest złudzeniem i złudnym poczuciem bezpieczeństwa, bo nie daje Ci takiego bezpieczeństwa, jakiego oczekiwałbyś od tego typu umowy w momencie, w którym ją podpisujesz. Jeśli dodasz do tego utratę kontroli nad projektem z tytułu kaskadowej realizacji, to już należy się mocno zastanowić, czy to na pewno najlepsza droga.

Czy w takim razie agile będzie lepszy?

Czy agile rozwiązuje problemy waterfalla?

Będzie, bo i w jednym i w drugim modelu ostatecznie zapłacisz tyle samo, a zwinność więcej wybacza.

Ale na koniec musimy sobie powiedzieć o jeszcze jednej, arcyważnej rzeczy i to też jest absolutnie do zapamiętania z dzisiejszego odcinka.

Otóż wracając do początku i pytania „czy lepiej robić projekty zwinnie, czy kaskadowo?” – odpowiedź brzmi „poświęć swój czas na to, żeby naprawdę porządnie wybrać agencję i dobrze przygotować swoją organizację do wdrożenia e-Commerce”. Jeśli zawalisz jedno lub drugie, to żadna umowa Ci nie da gwarancji, której potrzebujesz.

Zwinność wcale nie powinna też oznaczać kupowania kota w worku, a z taką opinią często się spotykam. Niestety rynek pełen jest firm, które agile utożsamiają z jazdą bez trzymanki i nie trzymają żadnej kontroli nad budżetem, ryzykiem, czy terminami. Praca z taką firmą na pewno nie udowodni żadnej przewagi modelu zwinnego. Myślę, że bardziej Cię do niego zniechęci i często też tak jest, że przychodzą do mnie firmy, które absolutnie nie chcą realizować projektu zwinnie, bo już raz to robiły i nigdy więcej. Ale zapewniam Cię, że jeżeli naciąłeś się na agencję przy modelu zwinnym, to prawdopodobnie przy waterfallu też nie byłoby szału.

Niestety zbyt często obserwuję firmy, które swój brak odpowiedniego przygotowania do realizacji projektu e-Commerce próbują przykryć umową, która de facto w przypadku odpowiedniego partnera może być ograniczeniem, chociażby dlatego, że w trakcie prac waterfallowych trudno o jakiś poziom elastyczności (a fajny partner mógłby tutaj wnieść coś do organizacji), a w przypadku wyboru złego wyboru firmy taka umowa też niespecjalnie Ci pomoże.

Jeżeli spełnisz te kryteria, to szybko jeszcze podsumuję moją rekomendację. Czyli zakładam, że dobrze się przygotowałeś i wybrałeś fajną agencję.

Jeżeli wszystko jest jasne, praca jest powtarzalna i przewidywalna, bo jest to na przykład bardzo małe wdrożenie, albo konfiguracja jakiegoś narzędzia – według mnie spokojnie waterfall się sprawdzi. Przy bardzo małych pracach myślę, że jest szansa, że mógłby być nawet lepszy.

Przy bardziej złożonych kwestiach waterfall sprawdza się na ogół gorzej i przypomina pokonywanie zakrętów na wciśniętym sprzęgle, a zaczyna wygrywać zwinność, bo odzyskujesz kontrolę i masz dużo większy kontakt z efektami projektowymi. W takich projektach dzieje się tak dużo, że na pewno docenisz też wartość bieżącej współpracy z zespołem.

Na koniec polecę Ci jeszcze trzy odcinki, które pomogą Ci lepiej przygotować się do procesu i mam nadzieję, że dzięki temu wdrożenie przebiegnie Ci o wiele przyjemniej. Są to odcinki numer 038, 016 i 005. Myślę, że te wszystkie 4 odcinki razem dadzą Ci duży pogląd na to, jak dobrze przygotować się do realizacji i jak taka realizacja powinna przebiegać, żebyś później był rzeczywiście zadowolony.

Od siebie pozostaje mi życzyć Ci już tylko udanego i wartościowego wdrożenia!