7 maja 2023 90:12 Odcinek 091

Zwinna realizacja projektów e-Commerce – Marcin Żmigrodzki

Podejście kaskadowe czy zwinne? Jaka metoda zarządzania projektami będzie najlepsza do wdrożenia e-Commerce? Jak to zwykle bywa, odpowiedź jest jedna: to zależy. W realizacji projektów technologicznych nie ma niestety złotego środka, jednej idealnej metody, która sprawdzi się przy każdym wdrożeniu. W jakiej sytuacji więc wybrać podejście agile, a w jakiej waterfall?

W tym odcinku moim gościem jest Marcin Żmigrodzki, praktyk wdrożeń projektów IT z wieloletnim doświadczeniem w branży, autor kilku książek na ten temat. Posłuchaj i dowiedz się, jak w praktyce wygląda realizacja projektów i jak się do tej rzeczywistości najlepiej przygotować.

Listen to „091 – Zwinna realizacja projektów e-Commerce – Marcin Żmigrodzki” on Spreaker.

Dodatkowe materiały

Jeśli zainteresował Cię ten odcinek, sprawdź również:

Książka Marcina – Zwinni. Zbrodnia i Scrum, nietypowy podręcznik zwinnego zarządzania projektami
https://lubimyczytac.pl/ksiazka/5013014/zwinni-zbrodnia-i-scrum
Książka Marcina – Instrukcja obsługi projektu, z której dowiesz się jak prowadzić projekt, by zakończyć go sukcesem
https://lubimyczytac.pl/ksiazka/4962868/instrukcja-obslugi-projektu
Książka Marcina – W tym szaleństwie jest metoda. Powieść o zarządzaniu projektami
https://lubimyczytac.pl/ksiazka/4882202/w-tym-szalenstwie-jest-metoda-powiesc-o-zarzadzaniu-projektami
Książka Marcina – Zarządzanie projektami dla początkujących. Jak zmienić wyzwanie w proste zadanie, dzięki której poznasz 10 prostych kroków skutecznego zarządzania projektami
https://lubimyczytac.pl/ksiazka/3817653/zarzadzanie-projektami-dla-poczatkujacych-jak-zmienic-wyzwanie-w-proste-zadanie
Manifest programowania zwinnego, dzięki któremu poznasz założenia podejścia agile
https://agilemanifesto.org/iso/pl/manifesto.html
Książka Incremental Commitment Spiral Model, The: Principles and Practices for Successful Systems and Software – Barry Boehm, w której znajdziesz informacje na temat modelu spiralnego w programowaniu
https://www.amazon.pl/Incremental-Commitment-Spiral-Model-Principles/dp/0321808223
Książka High Velocity Innovation. How to Get Your Best Ideas to Market Faster – Katherine Radeka, o tym jak szybciej dowozić projekty z wysoki poziomem ryzyka
https://katherineradeka.com/book/high-velocity-innovation/
Książka Testowanie pomysłów biznesowych. Biblioteka technik eksperymentacyjnych – J. Bland David, Alexander Osterwalder
https://lubimyczytac.pl/ksiazka/4946198/testowanie-pomyslow-biznesowych-biblioteka-technik-eksperymentacyjnych
Książka Metoda Lean Startup. Wykorzystaj innowacyjne narzędzia i stwórz firmę, która zdobędzie rynek – Eric Ries, dzięki której poznasz praktyczne metody pozwalające unikać błędów w rozwoju produktu
https://lubimyczytac.pl/ksiazka/158180/metoda-lean-startup-wykorzystaj-innowacyjne-narzedzia-i-stworz-firme-ktora-zdobedzie-rynek
Książka Lean UX dla zespołów AGILE – Eric Ries
https://lubimyczytac.pl/ksiazka/4912453/lean-ux-dla-zespolow-agile
Odcinek 085 – Zanim zdecydujesz się na wdrożenie Magento, z którego dowiesz się, czy Magento jest odpowiednim silnikiem dla Twojego e-Commerce
https://marekkich.pl/sztuka-ecommerce/085-zanim-zdecydujesz-sie-na-wdrozenie-magento/
Odcinek 077 – Zmiana sklepu internetowego – jak zrobić ją dobrze?, o tym jak sprawnie zmienić platformę e-Commerce
https://marekkich.pl/sztuka-ecommerce/077-zmiana-sklepu-internetowego-jak-zrobic-ja-dobrze/
Odcinek 073 – O wdrożeniach systemów ERP – Marek Mac, z którego dowiesz się jak z sukcesem wdrożyć system ERP
https://marekkich.pl/sztuka-ecommerce/073-o-wdrozeniach-systemow-erp-marek-mac/
Odcinek 069 – Rola e-Commerce managera w organizacji – Robert Kwissa
https://marekkich.pl/sztuka-ecommerce/069-rola-ecommerce-managera-w-organizacji-robert-kwissa/
Odcinek 054 – Jak to jest z tym budżetem i terminami?, dzięki któremu dowiesz się jak podczas wdrożenia e-Commerce mieć budżet pod kontrolą
https://marekkich.pl/sztuka-ecommerce/054-jak-to-jest-z-tym-budzetem-i-terminami/

Transkrypcja odcinka

Co różni metodę agile od podejścia waterfall?
Czy można zapobiec przekroczeniom budżetów i terminów we wdrożeniu?
Co zrobić, by zminimalizować ryzyka projektowe?
Rola product ownera we wdrożeniu systemu informatycznego
Najpopularniejszy błąd podczas wdrażania projektów metodą zwinną

Wszyscy chyba znamy odwieczny konflikt między waterfallem a agile. Zwolennicy waterfalla mówią, że zwinność prowadzi do nadużyć budżetów i terminów. Druga strona mówi o tym, jak waterfall betonuje innowacje i wcale nie gwarantuje sukcesu. Prawda jest gdzieś pośrodku, bo – jak się okazuje – nie ma wcale jednoznacznej odpowiedzi na pytanie: „To jak mam wdrażać swój sklep?”. Czasami może się okazać, że trzeba czerpać z obu tych metodyk jednocześnie. W tym odcinku moim gościem jest Marcin Żmigrodzki, a z naszej rozmowy dowiesz się, jak podejść do realizacji projektu e-Commerce, żeby potem nie żałować. Zapraszam do przesłuchania.

Cześć, Marcinie!

Hej!

Zaprosiłem cię dzisiaj, żebyśmy porozmawiali o zwinnym podejściu do wdrażania projektów w kontekście tego, jakie są jego zalety, a jakie wady, jak można go porównać do tradycyjnego, kaskadowego podejścia. Natomiast zanim zaczniemy, chciałbym, żebyś tak w kilku słowach opowiedział, co sprawia, że masz na ten temat wiedzę. Czy mógłbyś się przedstawić słuchaczom, którzy jeszcze nie mieli okazji Cię poznać?

Swoją przygodę z projektami IT zacząłem niedługo po studiach, zakładając niewielki software house. Dzisiaj byśmy to nazywali startupem. Jak większość startupów, po latach się okazało, że mu się aż tak dobrze nie powiodło, ale kilka projektów IT prowadziliśmy z kolegami. Zaczęliśmy ponad 20 lat temu. Potem, pracując przez kilka lat w banku, nadzorowałem portfel projektów. W bankowości właściwie prawie każdy projekt jest w dużej mierze projektem IT opartym o centralne systemy takie jak księga główna, stan transakcyjny, hurtownie i wiele, wiele innych, więc tam zawsze jest istotny komponent IT na wyjściu. To też jest wąskie gardło w takich projektach. Potem poobijałem się jeszcze po paru innych firmach, a potem zacząłem karierę niezależnego konsultanta i szkoleniowca. Od około 15 lat doradzam, szkolę i rozmawiam na temat rozmaitych projektów.

Od jakichś sześciu lat jestem kierownikiem studiów podyplomowych na Akademii Koźmińskiego właśnie z zarządzania wymaganiami w projektach IT, a jeszcze wcześniej uruchomiliśmy studia zarządzania projektami IT. Przez nasze ręce przewinęło się już 2-3 tysiące studentów. To już kilkanaście przeprowadzonych grup. W tym roku mamy równolegle pięć grup na jednej uczelni, dwie na drugiej, bo jeszcze WSB we Wrocławiu jest naszym partnerem, więc łącznie mamy 7 grup właśnie z obszarów projektów IT od strony zarządzania zwinno-kaskadowego i od strony definiowania wymagań.

Trochę więc w tym siedzę. Zdarza mi się jeździć po różnych firmach. Wiele z nich to firmy informatyczne, jednak nie tylko, bo zdarzają się też firmy inżynierskie, konstrukcyjne, produkcyjne, sektora publicznego, urzędy, natomiast duża część moich klientów to firmy IT. Od paru lat nastąpił ich wysyp na rynku, bardzo się rozwijały. Teraz czekamy na bankructwa, które będą konsekwencją intensywnego rozwoju (śmiech). Troszeczkę więc tych projektów IT widziałem. Tuż przed covidem przez jakiś czas nadzorowałem portfel projektów w pewnym funduszu inwestycyjnym, który za zadanie miał uruchamianie startupów. Miały one wspólne założenie (jedno z wielu, ale to było istotne), że działają w Internecie, czyli w środku tam był system e-Commerce, który miał łączyć klientów z dostawcami. To miał być marketplace z różnych aspektów. Tam też stawialiśmy wspólnie z zewnętrznym partnerem system, później sami go rozwijaliśmy dla kolejnych przedsięwzięć, startupów. Na poziomie wdrożenia, czyli, powiedzmy, pierwszych transakcji, przewinęło się kilkanaście przez ten fundusz. Miałem więc szansę nadzorować albo koordynować (albo wręcz sam w pewnym momencie zabrałem się za kodowanie), rozwijać system e-Commerce, który stawiał to, trzymał to na sobie.

Moje pierwsze pytanie będzie o wieloletnią już walkę pomiędzy zwinnością a kaskadowością w projektach. Mam wrażenie, że jak spojrzysz na to pole bitwy, to po jednej stronie są klienci, którzy mówią, że kaskadowo jest super, a zwinnie to same problemy, a po drugiej stronie są firmy wdrożeniowe, które kochają zwinność i nienawidzą kaskadowości, bo czują, że są w pewnym sensie ograniczani. Pewnie, jak to zwykle bywa, prawda jest pośrodku. Chciałbym najpierw poznać twoją opinię na temat tego, dlaczego w ogóle ten temat tak polaryzuje obszar wdrożeniowy pomiędzy klientów a wykonawców, dlaczego każdy ciągnie w inną stronę?

Najpierw udzielę krótkiej odpowiedzi – to zależy, a teraz dłuższej. Zacząłbym od tego, że w ogóle idea projektów pojawiła się w odpowiedzi na ryzyka. Grupa ludzi chciała coś zrobić, coś, co nie do końca było pewne, ponieważ to robiła z różnych względów po raz pierwszy: taka skala „po raz pierwszy”, taka technologia „po raz pierwszy”, w tym zespole „po raz pierwszy”, na tym terenie „po raz pierwszy” jestem klientem, „po raz pierwszy” ten produkt, „po raz pierwszy” na tym rynku. „Po raz pierwszy” może być dużo, ale one generalnie generują jakiś poziom niepewności i po stronie zamawiającego, i po stronie dostawcy. W zależności od tego, jak dużo jest tej niepewności, bardziej użyteczne przydaje się podejście nr 1, nr 2, ale również nr 3, o czym też chciałem wspomnieć.

Możemy mieć, bardzo upraszczając, ryzyka dotyczące tego, że nie wiemy, jak coś zrobić. Wiemy, co mamy zrobić, wiemy, że to na pewno nam pomoże, ale nie wiemy, jak to zrobić – nie znamy technologii albo są niewylistowane funkcjonalności, ktoś nie przemyślał swoich potrzeb, nie udokumentował ich. Tutaj się pojawią ryzyka na poziomie, po pierwsze – wykonalności. Dzisiaj, na przykład, sektor sztucznej inteligencji czy też uczenia maszynowego takie ryzyka rodzi. Wiemy dokładnie, co chcemy, żeby to robiło, ale nie zawsze się udaje, żeby to robiło wystarczająco dobrze, na przykład, żeby odpowiednio powiększało nam koszyk w sklepie. Liczymy na to, że AI podwoi nam zakupy klientów albo zmniejszy ilość spadających koszyków, natomiast tak się nie dzieje, bo AI nie ma jakichś danych, bo nie udaje się odpowiednio wycyzelować algorytmu. Tutaj mogą być różne przyczyny.

Druga kategoria ryzyk – nie wiemy, co chcemy zrobić, czyli wyobrażamy sobie, że będziemy obecni w Internecie, a nie mamy pojęcia, w jaki konkretnie sposób. Technologia to dźwignie, tylko trzeba wymyślić, co to ma być – ten produkt finalny.

W końcu trzecia kategoria ryzyk, którą bym wyróżnił – nie wiemy, po co to robimy. Wiemy, że chcemy mieć sklep internetowy, wiemy, że chcemy, żeby tam były na przykład książki, wiemy, jak go napisać (tu nie ma wielkiej magii), ale okazuje się, że nikt nie wejdzie do tego sklepu internetowego z różnych powodów, nikt nie kupi żadnej książki. Być może dlatego, że jest już 200 innych sklepów internetowych w Polsce, więc ryzykiem w tym wypadku są rezultaty. Doskonale wiemy, co chcemy osiągnąć, tyle że zakres oraz technologia nie są w stanie dowieźć rezultatów, bo na przykład konkurencja działa albo logistycznie nie potrafimy czegoś dźwignąć, bo koszty dotarcia do klienta będą tak gigantyczne, że to się nigdy nie zwróci.

W zależności od tego, gdzie są główne ryzyka, takie podejście jest użyteczne, na przykład, jeżeli klient nie wie, czego chce, ale zespół wie, co mu dowieźć, i jeszcze do tego rozwiązanie nie jest na tyle duże, żeby trzeba było się martwić na 10 lat naprzód, jak to będzie utrzymywane, składa się z dziesiątków modułów, jak niektóre systemy ERP na przykład. To podejście zwinne wydaje się najbardziej odpowiednie, bo zawiera w sobie fajny komponent pod tytułem „konwersacja”, który pozwala wyciągnąć między dwoma stronami te potrzeby. Co więcej – to podejście zakłada, że dostawca też jest w stanie podpowiedzieć coś ciekawego klientowi, że klient powinien być otwarty na sugestie z drugiej strony, bo dostawca mówi: „Jest 100 innych sklepów, w których coś działało albo nie” i może powiedzieć: „Słuchaj, ale tak się generalnie nie robi”. I wtedy pogadają.

Ta konwersacja ma ukryte założenie, że dzielimy się ryzykiem po równo, czyli jeżeli dojdą nowe wymagania, to nie usztywniamy się, nie blokujemy się, tylko jesteśmy w stanie się dogadać, jak je finansujemy, jak sfinansujemy to, że czegoś nie przewidzieliśmy albo jak sfinansujemy sytuacje, kiedy dane wymaganie kosztuje 4 razy więcej, bo czegoś nie dopowiedziano. Podejście zwinne ja bym w ukryty sposób zakładał podczas sprawdzania kontraktów typu payment material, natomiast klient często ma poczucie (stąd, myślę, jedna przyczyna tej, jak to nazwałeś, wojny), że dostawca z nim pogrywa nie do końca uczciwie, mówiąc, że coś miało kosztować jedną złotówkę, ale teraz to będzie 5 złotych, tylko że tak miało być drogi kliencie, zapłać. Klient zaczyna być podejrzliwy w takich sytuacjach, natomiast z drugiej strony, jeżeli nie ma zaufania, to trudno o to, żeby dostawca wychodził z nowymi pomysłami dotyczącymi zakresu, żeby krytykował to, co klient zgłosił. Dla niego jest najbezpieczniej w takiej sytuacji po prostu wykonać 1 do 1 to, co było zapisane. W takiej sytuacji więc, kiedy produkt finalny jest niejasny, podejście zwinne moim zdaniem się świetnie sprawdza, szczególnie jeżeli system jest mały i ta potrzeba długotrwałego utrzymywania go i pilnowania ogólnej architektury nie jest aż tak istotna. Tutaj królują na przykład apki mobilne, które relatywnie nie są zbyt dużymi systemami, są w miarę takie atomowe, wydzielone, i je się świetnie w ten sposób rozwija.

Jeśli głównym ryzykiem jest to, że nie wiemy, czy to się w ogóle sprzeda, czy ten pomysł w ogóle ma sens, wówczas ani podejście kaskadowe, ani podejście zwinne nie będzie moim zdaniem dobre, bo najpierw trzeba odkryć, co na tym rynku się sprawdzi. Tutaj pojawia się hasło product discovery w tej branży – coś, czym od jakiegoś czasu bardzo mocno się interesuję. On ma różne inne przejawy, ale w tej branży jest to product discovery, gdzie głównym celem jest stawianie hipotez i wypełnianie poprzez eksperymenty luk wiedzy. Eksperymenty na przykład na rynku, na potencjalnych klientach, stawianie pustego landinga i sprawdzanie, kto przyjdzie. Stawianie, pokazywanie jakiejś obietnicy wartości, pewnej usługi i w tle być może nie ma tych technologii, tam siedzi człowiek, który ręcznie coś zrobi, ale my sprawdzamy, czy ci klienci są, czy są skłonni zapłacić i jakie mają oczekiwania – na przykład jak szybko oczekują, że coś będzie dostarczone. Tutaj więc celem jest eksperymentowanie na prototypach po to, żeby wiedzieć, co później chcemy stworzyć w takiej formie dorosłej.

Podejście kaskadowe moim zdaniem (pewnie tutaj pojawi się sporo kontrowersyjnych komentarzy ze strony ludzi, którzy lubią agile) sprawdza się lepiej wtedy, kiedy mamy do czynienia z dużym systemem, kiedy trzeba z góry przewidzieć pewne aspekty architektoniczne, kiedy bardzo istotna jest na przykład kontrola. Podejście zwinne jest słabe, jeżeli chodzi o kontrolę. Ona stawia na współpracę, dogadanie się, otwartość i zachęca do innowacyjności, natomiast słabo kontroluje. To niekiedy nie przeszkadza, a niekiedy jest poważnym problemem. Podejście kaskadowe wówczas przychodzi z pomocą i proponuje zupełnie inne metody. Oczywiście, one są w sprzeczności, jest rozbieżność między waterfallem a agile, natomiast czasem jest to najlepszy kompromis – umówić się na zakres z góry, a potem pilnować, czy dowozimy to, co obiecaliśmy.

Powiedziałbym, że nie ma złotego środka i trzeba dopasowywać metody do konkretnej sytuacji. Pojawiają się na przykład koncepcje hybrydowe, czyli łączenia projektu waterfallowego ze zwinnym, gdzie zakłada się, że na górze będzie projekt waterfallowy, czyli można do niego przypisać budżet, strukturę organizacyjną, zakres, jest to ładnie opisane, jest harmonogram, mapa drogowa, a poniżej część zakresu – ta część, w której powinniśmy zachować innowacyjność, jest prowadzona zwinnie. Jest taki bąbelek zwinności w dużym, kaskadowym projekcie, tam siedzi sobie zwinny zespół no i zwinnie coś dewelopuje.

To też jest jakaś formuła i ona ma swój backlog, zasady. Tu się pojawia z kolei ryzyko na styku, bo ktoś musi zapewnić z jednej strony spójność planu, a z drugiej strony dopuścić pewną elastyczność w dowożeniu części zwinnej. Bardzo często bierze to na siebie project manager, który albo zakłada duże bufory, albo coś negocjuje, albo uprasza, ukrywa. W każdym razie próbuje zatrzeć te tarcia pomiędzy sztywnym harmonogramem a pływającymi sprintami.

Stosuje się więc różne półśrodki. Jestem wręcz gorącym przeciwnikiem książkowego odczytywania wszelakich metodyk. Ich już dziesiątki się przewinęły przez biznes przez ostatnie parędziesiąt lat. Fala agile jest tylko po prostu kolejną falą, która się przetoczyła, dostarczała fajnych narzędzi, ale niektóre z nich zostały później odrzucone. Nie wiem, czy słuchacze wiedzą o agile manifesto, zginęło kilkanaście metodyk zwinnych z rynku. One już w ogóle nie są wspominane – crystal, DSDM , FDD i parę innych. Pojedyncze techniki być może z nich przeniknęły do tego, co dzisiaj stosujemy, natomiast wygrał oczywiście Scrum z elementami kanbana i extreme programmingu, przy czym słowo extreme programming jest coraz mniej znane. Coraz mniej ludzi rozpoznaje, że coś takiego w ogóle istnieje. Oni wymogą backloga i historyjki, więc za chwilę przyjdą kolejne koncepcje, które w jeszcze inny sposób spróbują nas dogadać.

Podsumowując moją trochę przydługą odpowiedź – wojna się nie skończy. Ona zawsze będzie trwała, a zwycięstwo polega na dobraniu najlepszego kompromisu do danej sytuacji. Ale to zawsze będzie jakiś kompromis.

Jest jeszcze jedno zjawisko – otóż biznes, który ma pieniądze i który przychodzi i zamawia u technologii coś, chciałby czasami mieć ciastko i zjeść ciastko. Chciałby mieć tę innowacyjność po stronie dostawcy, żeby on podważał pewne założenia, że przychodzi z własnymi pomysłami, ale z drugiej strony chciałby móc kontrolować i rozliczyć dostawcę, żeby to nie była jego wina. To nie zawsze jest fair, natomiast większość dużych organizacji działa w formule budżetowej – na okresy czasu planowane są pewne kupki pieniędzy. To jest w totalnej sprzeczności z filozofią zwinną, gdzie ja nie mogę upfront z góry planować, ile sztuk wydam, bo nie wiem, co zrobię, natomiast duże firmy tak się rozliczają. Wprowadzanie więc w tym momencie kontraktu time and material może być dla niektórych pracowników kłopotem, bo oni muszą się rozliczyć z dodania konkretnych pieniędzy. Tutaj więc pojawia się mentalna bariera, że w dużych organizacjach dominuje filozofia: „zlecaj cele i kontroluj realizacje”, co nie jest zwinne, a z drugiej strony oczekuje się oddolnej innowacyjności.

Z drugiej strony znam firmy, które narzekają na swoich dostawców, uważając, że ci ściemniają i że zwinność posłużyła im do sprytnego rozpulchniania kosztów. Albo jest to robione w taki sposób, nawet z dobrymi intencjami typu – dostawca skupia się na rzeczach nieistotnych dla klienta, a klient nie umiał go przypilnować, żeby dostarczał rzeczy o dużej wartości, czyli dostawca skupia się na refaktoringu, dokumentowaniu, bawieniu się algorytmami i dopieszczaniu ich, żeby było jeszcze równiej, ładniej, jeszcze bardziej hi-techowo, czego klient w ogóle nie zauważa, ale klient wydaje stałe kwoty, bo to jest podejście zwinne. Albo wręcz dostawca upycha etaty do projektu zwinnego, które tak naprawdę nie wnoszą żadnej wartości. Dopiero po jakimś czasie klient, widząc wysokie faktury, zadaje niewygodne pytanie: „No ale po co nam czwarty analityk albo po co nam agile coach przy tym projekcie, skoro jest pięć osób?”. Natomiast zwinność czasami jest też jakimś wytrychem podreperowania finansów dostawcy, co nie buduje zaufania. Tutaj więc po obu stronach są różne wybiegi, które mogą powodować, że brakuje zaufania, a bez niego trudno o podejście zwinne.

Powiedziałbym, że wyczerpałeś prawie całą agendę. Mam jednak jeszcze tyle follow-upów, że nie wiem, od którego zacząć. Zacznę od domu, bo to jest chyba jedno z najczęstszych stwierdzeń, które się pojawia. Chciałbym, żebyśmy na tej osi ryzyk postawili gdzieś tę budowę domu, dlatego że to jest jeden z częstszych argumentów, który sobie teraz pozwolę przytoczyć. On polega mniej więcej na tym, że: „Panie Marcinie, jak budowałem dom, to przyszedł architekt i ja mu zapłaciłem. Później przyszła firma budowlana, zapłaciłem jej i oni mi ten dom postawili. Dlaczego tak się nie da zrobić ze sklepem internetowym, skoro sam stwierdziłeś chwilę wcześniej, że tych sklepów internetowych jest w jak mrówków?” Gdzie w takim razie jest innowacyjność w sklepie internetowym, skoro w samej Polsce jest ich kilkadziesiąt tysięcy? Domów oczywiście jest więcej, ale to już jest tak duża skala, że właściwie nic nas tam nie powinno zaskoczyć.

Tutaj chodzi nie tylko o innowacyjność, ale ona rzeczywiście też jest istotna. Po pierwsze – przy budowie domów są bardzo wysokie koszty zmian. Jeżeli bym zbudował sobie domek parterowy, a w połowie inwestycji stwierdził, że ma być jednak jednopiętrowy, to zakładając, że to by mi się nie zawaliło i że nadzór budowlany mi by to przełknął (o czym za chwilę), to by było bardzo kosztowne. Dużo taniej jest z góry przewidzieć, że chcę mieć jeszcze jedno piętro i tak zaplanować fundamenty, żeby on nie osiadał, tak zaplanować stropy, żeby dało się po nich chodzić, i tak dalej. W IT dużo łatwiej się okleja rozwiązanie srebrnymi taśmami, żeby to się trzymało – dodaje kolejne ekraniki, tabelki, pola w bazie, API – i to nadal działa, a koszt przebudowywania w porównaniu do budowlanki nie jest aż tak duży.

Druga kwestia jest taka, że to jest bezpieczeństwo ludzkie. Jeżeli system informatyczny się zawali, to się go za chwilę postawi. Miałem taką sytuację wiele lat temu, że prowadziłem właśnie tę pierwszą firmę – software house, i zniknęło nam z konta kilkadziesiąt tysięcy złotych. To były dla nas bardzo duże pieniądze, bo byliśmy małą firmą i ta płynność była taka sobie. Poszła taka panika. Spytałem wspólnika: „Czy to ty żeś wypłacił?”. „Nie no, ja w życiu” – odpowiedział. On mnie spytał, czy ja wypłaciłem, a ja: „No nie”. Patrzyliśmy na siebie podejrzliwie, ale te pieniądze po prostu znikły. To nie było tak, że ktoś dokonał wypłaty. Zadzwoniliśmy do banku, a pani poinformowała: „A, tak, bo w sobotę było wdrożenie” i zupełnie zadowolona, bez żadnej krępacji stwierdziła, że one się odnajdą. Oczywiście, byliśmy potwornie sfrustrowani i wylaliśmy na nią swoje emocje. Ona też była przygotowana do takich rozmów, bo wiedziała, że w sobotę było wdrożenie, więc nie wierzę, że to była pierwsza rozmowa. Faktycznie, 2-3 dni później te pieniądze się znalazły. Bank wykopał je gdzieś tam z backupów czy księgi głównej i odświeżył nasz rachunek tak, że był poprawny.

Gdyby tak samo się stało z budynkiem, byłoby to kłopotliwe. Jeżeli ludzie byliby w środku w momencie, kiedy by to wdrożenie się zawaliło, to byśmy mieli do czynienia z przestępstwem. Zagrożenie dla życia ludzkiego pociąga za sobą normatywność. Tutaj jest dużo norm. Ja mogę sobie jako klient wymyślić cuda, ale przyjdzie mi architekt i powie: „Panie, ale ja tego panu tak nie zrobię, nie puszczę dalej, branżysta tego nie podpisze, bo to nie wytrzyma obciążenia. Jeżeli ma pan tej wielkości dach, a w tym rejonie są takie opady, to pan musi mieć taki skos (nie znam się na tym, więc przepraszam za herezje, które opowiadam), żeby odprowadzał śnieg w zimie. Pan nie może zrobić tego w ten sposób, chyba że pan będzie codziennie odgarniał szuflą śnieg z tego dachu. Okna muszą mieć odpowiednią przepuszczalność termiczną, bo na to są normy unijne”. Nie mogę sobie wstawić okna, które będzie wiało chłodem. Kontakty powinny być na określonej wysokości, szczególnie w budynkach użyteczności publicznej. Tutaj nie ma dużej dowolności, bo w takim budynku mogą się pojawić osoby, które mają problem z poruszaniem się i one też muszą sięgnąć do kontaktu. Kontakty zwyczajowo, na przykład włączniki, wstawia się koło drzwi, a nie na drugim końcu pokoju, i nikt o tym nie dyskutuje. W IT takie rozwiązanie by przeszło. A ja chcę teraz włącznik mieć na balkonie – proszę bardzo, damy radę. Tu jest więc bardziej znormalizowane i pod kątem prawnym, i pod kątem dobrych praktyk, że coś się robi lub nie i już. To ogranicza więc dowolność. Kolejna kwestia jest taka, że… Tu nawet nie chodzi o tę innowacyjność sklepów, tylko… Bo rzeczywiście, przy 10 tysiącach sklepów można by stwierdzić, że one są bardzo powtarzalne.

Zaraz powiem coś w drugą stronę – one są powtarzalne, ale koszt zmiany jest tak niski w porównaniu do niepewności, że czasem bardziej opłaca się popełnić błąd, a potem go szybko naprawić, niż w przypadku budowlanki. Tu trzeba więc patrzeć nie tyle na ryzykowność projektu, co na taki iloraz ryzyka do kosztu poprawy. Jeżeli jest duże ryzyko, ale koszt poprawy jest niski, to może zaryzykujmy, zobaczmy, co wyjdzie i poprawiajmy non stop. Jeżeli natomiast koszt poprawy byłby wielki, to rzeczywiście tutaj trzeba by się zastanowić, bo OK, nawet domy się przesuwa, jeżeli stoją w złym miejscu, ale robi się to wobec budynków, które są na przykład zabytkowe i których wartość kulturowa, historyczna jest tak duża, że warto w to zainwestować. Natomiast w większości przypadków albo się zaniecha planu przesuwania budynku, bo to będzie zbyt kosztowne, albo się ten budynek rozbierze, jeżeli ktoś, na przykład, postanowił wybudować nagle lotnisko w tym miejscu. To są gigantyczne pieniądze.

W IT przesuwanie funkcji, modułów, ekranów jest robione po prostu przy okazji. Rodzi to jakieś dalsze konsekwencje, ale to się robi w locie i panuje przekonanie, że wszystko się da.

W budowlance to przekonanie już dawno, dawno temu upadło. Mam przykład dwóch budynków i oba są przepiękne, czyli ta satysfakcja użytkownika jest olbrzymia (to jest charakterystyczne dla agile), ale oba potwornie przekroczyły budżety i zostały skończone tylko dlatego, że miały bardzo bogatego sponsora. Pierwszy mój ulubiony przykład, to jest Neuschwanstein w Bawarii, czyli ten zamek, który był inspiracją dla logo Disneya – taki cukierkowy, z tysiącem wieżyczek, daszków – ale inwestorem był król. On miał na to całkiem spory budżet. Warto poczytać, co się z nim później działo, bo te przekroczenia dla projektu miały bardzo tragiczny finał. Został między innymi ogłoszony nienormalnym i zdjętym z tronu ze względu na przekroczenia w budżecie projektu.

Drugi przykład to jest Sagrada Familia, gdzie architekt (genialny, któremu zaufało miasto) budował katedrę na podstawie szkiców. On je w trakcie zmieniał, miał oczywiście ogólną wizję, ale szczegółowy plan techniczny tego nie powstał na starcie. W momencie, kiedy zdarzył mu się wypadek drogowy i zginął, kontynuatorzy tej budowli zostali tak naprawdę ze szkicami, z pewną wizją artystyczną, a nie z konkretnym projektem architektonicznym do ostatniej cegły. Efekt jest taki, że projekt pochłonął później potworne pieniądze. Przez kolejnych kilkadziesiąt lat był kończony i chyba nadal nie jest wykończony, tak mi się wydaje. Z zabawnych anegdot – niedawno, parę lat temu okazało się, że ten projekt w ogóle był samowolą budowlaną, że aspekt formalny został pominięty. Oczywiście, nikt chyba nie myślał o rozbiórce Sagrady Familii, ale musieli szybko nadgonić te braki formalne.

Podejście zwinne w budowlance z tych powodów się nie sprawdza, mamy na to, jak widać, przykłady, natomiast w IT też często się nie sprawdza, bo jeżeli mamy system, który będzie odpowiednio duży, który zostanie zalany dużą ilością zmian i my nie będziemy w stanie zamknąć specyfikacji w odpowiednim momencie, to on się totalnie rozpełznie. Polecam lekturę projektu Taurus z londyńskiej giełdy papierów wartościowych – projektu, który na koniec kosztował (podobno, bo nikt tego nie wie) 37 razy tyle – na koniec, czyli w momencie, w którym został skasowany i wyrzucony do kosza. Czyli 37-krotnie przekroczył budżet i piąty project manager powiedział, że on nie ma pojęcia, ile to kosztowało. Projekt zalała niekontrolowana fala zmian, a był na tyle duży, że każda kolejna generowała wykładniczy koszt powtórnej analizy, czy ona jest spójna, czy to zadziała, czy tak można.

W takim razie wrócę jeszcze do ryzyk, szczególnie budżetowych, bo to jest z kolei powód, dla którego firmy dążą do wdrożeń fixowych (to o tym zresztą też powiedziałeś). Zastanawiam się, jaka jest twoja perspektywa na temat tego, czy naprawdę tak jest i czy uważasz, że da się zapobiec ryzykom rozjazdów budżetowych i terminowych, wdrażając coś fixowo?

Z mojej perspektywy jest tak, że termin to są najczęściej kary umowne, więc pytanie, czy wykonawcę stać na te kary. Jeśli tak, to termin jest kwestią do dyskusji. Poza tym bardzo często jest tak, że same zapisy umowy fixowej powodują, że te terminy też się trochę upłynniają, bo zawsze można powiedzieć, że termin jest przesunięty, bo klient czegoś nie dowiózł, bo się pojawiły jakieś nieplanowane zmiany, bo siły wyższe (jakkolwiek definiowane). Podobnie jest z zakresem – szczególnie mam tutaj na myśli zamówienia publiczne, gdzie mimo wszystko to jest chyba książkowy przykład wdrożeń fixowych, gdzie pojawiają się grube dokumenty. I budżetowo, i terminowo nie wygląda więc to najlepiej.

Da się wyeliminować rozjazdy budżetowe. Przez ponad 20 lat były prowadzone takie badania chaosu przez Standish Group – to się nazywało bodajże „Raport chaosu na projektach IT”. To były deklaratywne ankiety, gdzie specjaliści z IT mówili, czy projekty się kończą w terminie, w czasie lub zakresie. Na tej podstawie badacze z firmy konsultingowej określali, jaki jest procent projektów, które kończą się sukcesem. Przez kilkanaście lat ten procent sukcesowych projektów był mniej więcej ten sam. Nie było jakiegoś trendu rosnącego – między 30% a 40% projektów było udanych, aż nagle wszedł agile i te wskaźniki skoczyły. Tylko uwaga – stwierdziłem, że jest to podejrzane i ten raport sobie kupiłem, żeby zobaczyć, jaka jest metodyka stojąca za definicją sukcesu. Okazało się, że jak wyszedł agile, to zmienili definicję sukcesu, bo stwierdzili, że sukces to jest coś, co strony uważają subiektywnie za sukces. W takiej sytuacji nic dziwnego, że wskaźniki im skoczyły, bo jeżeli nie mamy odniesienia do twardych wymiarów typu koszt, termin, zakres, to wówczas łatwiej jest przyznać się do właśnie udanego wdrożenia, projektu niż mówić: „O, znowu mi tu nie wyszło”. To jest chyba też problem z agile – że w nim trudniej się mierzy obiektywne parametry – że projekt miał się skończyć w tym momencie, a nie skończył, bo ten moment, w którym teoretycznie miał się skończyć, jest płynny, bo się na przykład pojawiały rozjazdy na wymaganiach.

Wydaje mi się, że dopóki projekty będą poruszały się w sferze ryzyka, niezależnie od tego, jak będą robione, będą narażone na opóźnienia takie jak przekroczenia kosztów i nierealizowanie potrzeb klienta. Wszystko jedno, czy są one waterfallowe, czy agile’owe, przy czym przy agile to będzie mniej widać, ale rozjazdy tak czy siak na pewno będą, bo taka jest natura ryzyk.

Natomiast jeszcze wracając do jednej tezy, o której zacząłem mówić przy poprzednim pytaniu – dlaczego sklepy internetowe nie są robione kaskadowo tylko zwinnie? Uważam, że to jest przyczynek do dyskusji: „A dlaczego właśnie by nie?”. Dlaczego nie można doprowadzić projektów (wdrożeniowych, nie mówię o developmencie, gdzie się programuje dużo, tylko takich, gdzie wdrażamy istniejącą technologię) do takiego poziomu powtarzalności, żeby kolejne wdrożenie szło według jakiegoś schematu? Ono oczywiście ma pewne odchylenia. Te wymagania mogą być różne – różna liczba wdrażanych userów, trochę inne role, proces zawierania transakcji, wygląd frontendu, ale tak naprawdę można to sprowadzić do pewnej powtarzalności i ustabilizować na tyle, żeby to wdrożenie było mocno przewidywalne.

Posłużę się takim skrajnym przykładem, być może przez to nie do końca adekwatnym, ale zobaczcie, drodzy słuchacze, jak wyglądało wdrożenie bloga. 20 lat temu, jeżeli ktoś chciał postawić sobie blog, to musiał napisać formularz, czasami zaprząc jakąś bazkę, postawić sobie ze dwie stronki, na których byłaby lista postów i szczegóły postu, bezpośrednio na bazie sobie na jakimś PHP, myAdmin edytował ten layout, treść posta, albo dorobił sobie panel edycyjny i na nim wpisywał. To były początki, natomiast jak to wygląda dzisiaj? Obecnie ściągam paczkę WordPressa, idę next, next, wybieram sobie layout spośród całej gigantycznej biblioteki i 20 minut później mam blog. Do tego mogę dodać jakieś customizowane obrazki, swoje logo, nagłówek, który będzie mnie charakteryzował, a tak naprawdę technologia stoi i robi 100 lub 1000 razy więcej niż tamten biedny blog sprzed 20 lat. Natomiast jego powtarzalność, przewidywalność bardzo wzrosła. Wręcz to przestało być projektem, stało się procesem wdrożeniowym WordPressa.

Moja teza jest taka, że o ile nie mamy do czynienia z developowaniem od nowa sklepu, tylko stawianiem kolejnego, to tak naprawdę to wręcz powinno iść trochę kaskadowo, jeżeli nie da się tego w pełni sprocesowić. Pytanie – jak dużo niepewności możemy usunąć poprzez obserwowanie poprzednich wdrożeń, poprzez szukanie tych powtarzalności?

Myślę, że oczekiwanie rynku jest takie, żeby to jednak było chociaż trochę uprocesowione, bo w podstawie każdy sklep jest w jakimś stopniu klonem swojego poprzednika, bo i tu, i tu mamy koszyk, tu i tu mamy proces zakupowy. Są oczywiście różne metody płatności, dostaw, każdy sklep może trochę się różnić od siebie wyglądem. W przypadku B2B dochodzą jakieś nowe wymagania, raz się integrujesz z tym, a raz z innym systemem, natomiast od strony procesów tak naprawdę sklep internetowy w swojej podstawowej strukturze to nie jest coś bardzo skomplikowanego, bo tych procesów zbyt dużo tam nie ma. Tam jest proces zakupowy i właściwie koniec, plus te małe procesy typu rejestracja, wymiana danych.

Obserwuję, że coraz częściej jednak pracuje się w tym takim trybie hybrydowym, o którym mówiłeś na początku, że częściowo się przewiduje te najważniejsze obszary związane ze sklepem internetowym, takie jak wygląd, integracja, jakieś customizacje, a później się już leci takim… To już nie jest takie do końca zwinne, ale z drugiej strony też trudno udawać, że my coś wszyscy robimy jako rynek po raz pierwszy w obliczu tego, że tych sklepów jest po prostu dużo i bardzo często jedni od drugich po prostu kopiują.

Ta zwinność więc nie do końca działa, natomiast obserwuję, że bardzo często po drugiej stronie tego całego równania są klienci, którzy mówią, że właściwie my możemy sobie wdrażać i mówimy jako branża wdrożeniowa: „Możemy to sobie wdrażać, jak chcemy, byle to było na czas i w budżecie”. Cała ta otoczka procesowa jest już po stronie wykonawcy, bo nikt nie będzie się wtrącał w ten proces, bo wykonawca wie, jak to zrobić najlepiej. Ale te dwa parametry – budżet i czas – to jest coś takiego… Przynajmniej dąży się do tego, żeby to było w miarę nieprzekraczalne, o ile rzeczywiście nie pojawi się innowacja w obszarze, na przykład, wdrożenia B2B, nie.

Tak, natomiast wydaje mi się, że dobre może być miejsce tak naprawdę uzyskiwania przewagi konkurencyjnej przez firmy wdrażające takie rzeczy, bo ci, którzy będą w stanie doprowadzić do powtarzalności to wdrożenie, powiedzieć klientowi: „Dobra, kliencie, chcesz czy budżet czas? Proszę bardzo, tak i tak” i jest to w miarę wiarygodne, nie jest napompowane. Zawsze ekstra buforem, podwajając budżet, mogę zmieścić te moje niedociągnięcia, ryzyka, ale będzie to w miarę sensowna wycena, mogę po prostu wygrać rynek.

Jeżeli widzimy na stole dwie oferty – jedną, która mówi: „Za miesiąc – tyle”, a druga mówi: „Za taką kwotę – tyle” i to będzie jeszcze w miarę sensowna kwota, to co klient wybierze? Co więcej, powiem jeszcze dalej – miałem rok temu rozmowę z firmą, która robiła systemy na zlecenie, czyli mocno zwinne, nie wdrażała gotowego softu, tylko (nadal istnieje i to robi) pisała pod zamówienie klienta. Oni opowiadali taką historię, że przychodzi do nich klient w miesiącu nr 1, pyta, ile z grubsza coś będzie kosztowało. Oni mówią mu: „Ale drogi kliencie, my pracujemy zwinnie, rozumiesz, tak? Time and material, płacicie za sprinty czy za miesiące”. „Tak, tak, ale tak z grubsza, bo muszę coś powiedzieć szefowi”. No to rzucili jakąś kwotę X, załóżmy 100 zł, mijały kolejne miesiące, a w szóstym miesiącu przychodzi klient i mówi: „Już, już, dopinam wszystkie budżety. Słuchajcie, za chwilę ruszamy, przygotujmy sobie tylko umowę”. Klienci podsuwają umowę time and material, wszystko legal, zgodnie ze scrumem, klient pracuje customowo przez kolejne miesiące. W końcu, załóżmy, po 12 miesiącach wraca, zabudżetował sobie to, co zabudżetował, podpisuje umowę time and material, zespół zaczyna pracować i nagle okazuje się po kolejnych, załóżmy, trzech miesiącach, że po wystawieniu trzeciej faktury klient patrzy w budżetach, że kwota X jest przekroczona. Przychodzi z pretensjami do dostawy: „Ale jak to? Przecież mówiłeś, że to będzie X”. Dostawca mówi: „Tak, to była wstępna wycena, potem żeśmy przez rok rozmawiali. Zobacz, co masz w umowie – płacisz za sprinty a nie za całe rozwiązanie. Na co klient mówi: „Ale ja mam zabudżetowane X” i po trzech miesiącach wydał wszystkie pieniądze, a widzi, że system jest rozgrzebany. „No ile to jeszcze będzie kosztowało?”. „No my nie wiemy”, „Ale jak to nie wiecie? Ja już nie mam pieniędzy!”. Ten partner mówi, że klient się obraził i zerwał współpracę, mimo że prawnie wszystko było posprzątane. Wydawało im się, że oni czują się czyści wobec klienta, etyczni, natomiast klient miał poczucie bycia oszukanym. Nie wiem, na ile grał, na ile to była podstawa negocjacyjna przed swoim własnym przełożonym, że złe IT, ten zły dostawca nas tutaj naciągnął, co ja mogę, a na ile faktycznie czuł się, że coś tu było nie tak.

Nawet mimo uzgodnienia wszystkiego klient dalej ma dalej w głowie te kwoty, bo on jest rozliczany jako pracownik korporacji bardzo często za wydanie kwot w trybie waterfallowym – „Na ten rok masz tyle i masz dowieźć wartość”. Jak mu się to rozjeżdża i tego nie zauważy, to przerzuca winę na zewnątrz. Dlatego uważam, że to nie jest zagrożenie. Tak bywa, ale to nie tylko zagrożenie, ale też okazja dla tych, którzy potrafią odpowiednio zarządzić tymi relacjami z klientem i przygotować taki sposób dostarczania, żeby klient stwierdził: „OK, ja mam kontrolę, wy robicie fajne rzeczy, wszystko się spina”.

A jaka jest twoja ocena tej sytuacji, o której mówiłeś? Z mojej obserwacji wynika, że to wcale nie jest takie rzadkie, że to nie jest takie anegdotyczne, tylko to jest taka trochę codzienność wdrożeń projektowych, że jednak podpisuje się kontrakt niezależnie od tego, czy on jest fixowy, czy to jest time and material – podpisuje się w oparciu o coś, i tym czymś najczęściej są jakieś kwoty.

Oczywiście, każda wycena jest tak dobra, jak wsad, którego ta wycena dotyczyła. Jeżeli to jest jedna strona A4, to ta wycena jest, można powiedzieć, trochę wywróżona. Jeżeli jest to bardzo doskonała dokumentacja, to ta wycena jest całkiem niezła, ale niezależnie od tego, jaki ten kontrakt był i w którym momencie podpisał, to on najczęściej zahaczał chociaż o szczątki wycen. Bardzo często te wyceny są traktowane jako pewnego rodzaju obietnica. Dochodzi sytuacji, o której ty powiedziałeś – ktoś sobie zakodował w głowie, przekazał być może dalej przełożonym, że to będzie te 100 zł, no i w 90% budżetu okazało się, że jesteśmy w 30% projektu, i się robi z tego problem. Jak oceniasz tę sytuację? Jak można temu w ogóle zapobiec, jak można temu zaradzić?

To, co nam pomogło, co oni sami mówili i ja też się bym podpisał obiema rękami, to jest szybsze budowanie świadomości klienta co do tego, co on zamawia, czyli szybsze budowanie wizji tego rozwiązania, dokumentowanie jego wymagań. Tutaj w ogóle analiza biznesowa bardzo mocno się kłania. Akurat w IT jest takim remedium na bardzo wiele problemów, a jest bardzo często pomijana, bo klient nawet nie wie, że istnieje coś takiego, jak analiza biznesowa, analiza wymagań. On chce, żeby było dobrze. No przecież system – to oczywiste! System jaki jest – każdy widzi. Oni na przykład wymyślili sobie takie coś, jak warsztaty product discovery, czyli warsztaty, na których oni przez 2-3 dni siedzą z klientem i definiują, co ty, drogi kliencie, chcesz.

To jest taka wielka burza mózgów. Te warsztaty mają zafixowany koszt, czyli klient kontroluje budżet. Po tych warsztatach klient dostaje dokumentację i może sobie pójść do kogoś innego, jeżeli tak chce. Rzadko tak się dzieje, bo już ufa, zbudował sobie relację, więc po co ma szukać dalej, ale teoretycznie mógłby wziąć tę książkę z dokumentacją wymagań i pójść gdzieś dalej. W tych warsztatach bierze udział duża część zespołu, bo tam się pojawi UX-owiec, analityk, często kierownik projektu. Jeżeli ma zahaczyć o jakieś kwestie techniczne, to jakiś deweloper dobrze, żeby był. Efektem tych warsztatów jest przede wszystkim zbudowanie listy albo przypadków życia, albo z grubsza historyjek, czyli głównych elementów funkcjonalnych tego rozwiązania, listy funkcji tak czy inaczej zdefiniowanych (to już jest trudne), kto będzie korzystał i w jaki sposób z tego systemu. Czasem nawet dochodzi do zdefiniowania albo jakichś procesów przepływających przez system główny typu uzgadnianie transakcji, jeśli system ma na przykład jakiś element negocjacji, to wtedy to przestaje być takie oczywiste, albo uzgadnianie terminu wykonania usługi.

Myśmy mieli taką sytuację, kiedyś robiliśmy pewien site z usługami i największą miną okazał się system umówienia terminu spotkania z psychologiem online (bo o psychologów chodziło). Od strony technicznej było tam wiele niuansów do rozegrania – co, jak psycholog lub pacjent nie ma czasu, co jak w trakcie się zmienia ten termin, jak zarządzić kalendarzem psychologa, żeby nie umawiać podwójnych wizyt i tak dalej. Kilka takich drobnych niuansów, ale trzeba je przewidzieć.

Czasami z takich warsztatów wychodzi się jeszcze z makietami ekranów. W tym momencie klient ma przekonanie, czego on w ogóle chce, bo często nie ma świadomości, że nie wie, czego chce. Wydaje mi się, że to jest takie oczywiste, ale dopiero, jak mu się pokaże, rozbierze jego potrzebę na małe części, to nagle otwierają mu się oczy: „O, kurczę, faktycznie, i to nieprzewidziane, i to, i to, i tu będą takie konsekwencje”. Jeżeli więc odpowiednio szybko to się zrobi, to klient nabierze zaufania, że ten zespół umie go poprowadzić za rękę, umie wyeliminować jego własne zagrożenia, a z drugiej strony też ta zmienność projektu mocno się ogranicza, bo mamy wstępną definicję wymagań. To jest więc coś, co zadziałało.

Z tego, co widzę czasami, to takie warsztaty typu, że sprzedaje się, a później mówi się klientowi, że jeżeli u nas zamówi, to odejmiemy mu na przykład od ceny. Czy tak się dzieje, czy nie, to już jest kwestia negocjacji, ale też takiego argumentu handlowego firmy wystarczająco używają, więc to też jest metoda – szybko zdefiniować wymagania, przynajmniej na ogólnym poziomie.

Jak blisko czy jak daleko takiej dokumentacji, która nadawałaby się jako załącznik do umowy fix price’owej, są tak sformułowane wymagania zebrane przez trzy- lub czterodniowy warsztat?

Na pewno bliżej niż akapit, który mówi: „Celem umowy jest stworzenie sklepu internetowego (śmiech). Tutaj sam się kiedyś nadziałem wiele lat temu na kontrakt – miał być tłusty i w ogóle od fajnego klienta, który właśnie był wielką firemką, i przedmiotem umowy było stworzenie systemu ofertowania, kropka. Potem się okazało, że jest to po prostu gigantyczna mina, bo tam musiały wchodzić nawet elementy księgowe. No, cuda, żeśmy bardzo na tym popłynęli, więc tak naprawdę pytanie jest takie, na ile klient później będzie akceptował zmiany zakresu wywołane swoją niewiedzą albo dostawcą, jego pracami. Ale tak czy siak, na ile będzie akceptował, na ile ufa, a na ile chce mieć poczucie kontroli.

Mnie się zdarzało być w takiej sytuacji, że klient zamawiał u nas dokumentację systemu. Robiliśmy w UML taką grubą książkę z rozmaitymi diagramami. Klient to wziął, przeczytał, stwierdził: „Dziękuję chłopaki, kasuję projekt”. Oczywiście, zapłacił nam za przygotowanie dokumentacji, natomiast z analizy wyszło, że jest to zbyt złożone i nie ma sensu tak dużego rozwiązania wdrażać. Dla niego gigantyczna korzyść, bo nie zmarnował pieniędzy na nieudane wdrożenie.

Pytanie więc, jak duże jest zaufanie i niepewności po obu stronach. Sam wspominałeś na starcie, że jeżeli mamy do czynienia z wewnętrznymi pracownikami, to się przymyka oko na bardzo dużo rzeczy. Jeżeli to jest wewnętrzny dział IT, to może latami coś rozwijać i wcale nie szkodzi, bo chłopaki faktycznie codziennie przychodzą do pracy, więc chyba pracują. Natomiast jeśli jest zewnętrzny dostawca, to zaufanie jest mniejsze. To więc zależy.

Nie mam tutaj prostych metod. Wydaje mi się, że takim minimum, to jest wiedzieć, kto korzysta z rozwiązania, jacy są aktorzy, a po drugie wiedzieć, jakie są główne funkcje, to znaczy jakie są wszystkie funkcje, ale na ogólnym poziomie, być może ogólniejszym niż to, co oferuje user story, być może na poziomie takim, jak use case tego oczekuje. Jeżeli w środku występuje jakiś złożony proces, bo jeżeli to nie są tylko typowe procesy, ale na przykład są dostawcy, jest to marketplace, z jednej strony klienci, z drugiej dostawca, my robimy narzędzie pośrodku. Teraz oni coś między sobą muszą uzgodnić. To prawdopodobnie będzie złożony proces. Jeżeli jest złożony proces, to te wyjątkowe, trudne obszary dodatkowo opisałbym jakimś rodzajem mapy – może byś BPMN, może po prostu zwykły flowchart, ale jakimś schematem – tylko rozrysował, żeby rozbroić tę największą niepewność.

Jeżeli jest wiele integracji, to pewnie chciałbym mieć to rozpisane na starcie, bo z czym to ma gadać? Z tym, z tym, z tym i z tym, bo może dojść do takiej kwestii, że nie tylko czerpiemy dane, ale one sobie płyną, potem z powrotem płyną, potem tam, musimy coś uzgodnić, poczekać, i to się zaczyna robić złożone. Wtedy bym się więc po prostu przyjrzał, gdzie są te najbardziej ryzykowne obszary i je dodatkowo opisał.

Niektórzy mówią, że warto jeszcze zrobić makiety, że to też powinien być kanon. Tutaj ta technologia jest coraz bardziej przystępna, coraz łatwiej się tworzy te makiety. Możemy jeszcze pójść w tę stronę, szczególnie że (i to jest jeszcze jeden ważny czynnik) klient musi rozumieć, co czyta. Makiety są fajną techniką, bo na ogół klient je rozumie. Każdy zna się na estetyce i wie, co jest ładne (przynajmniej tak każdy uważa). Makiety ekranów, jeżeli są jeszcze wykonane estetyczne, czymś trochę bardziej zaawansowanym niż konturowe narysowanie kontrolek, czyli coś, co daje już jakby wygląd końcowy, są czymś, co klient zrozumie, będzie mógł dać uwagi, będzie mógł powiedzieć: „Słuchajcie, nie, ja sobie to wyobrażałem inaczej. Czy to mogłoby być węższe? Czy tu da się dołożyć taką kolumnę?” i tak dalej. Uważam, że jest to fajna technika.

UML ma ten problem, że jest precyzyjny, ale klient tego nie rozumie i się wyłącza. Gdy mu się pokazuje diagramy, chociaż takie najbardziej wstępne typu przypadków użycia, to zdarzały się takie rozmowy, że klienci mówili: „Nie, Marcin, ja wiem, że ty się na tym znasz. Na pewno to jest dobrze”. I to jest początek problemów, jak klient nie zwalidował. Jeżeli wiec klient rozumie, to bym szedł w tę stronę. Jeżeli chce coś czytać, rozumie schematy, to mówimy: „Dobra, zróbmy na start schemat”.

Powiedziałeś fajną rzecz, że jak klient nie rozumie, to się wyłącza i z tego są później problemy. To nas trochę prowadzi do pytania (już niezależnie od metodyki wdrożeniowej) – jak firmy powinny się przygotować na to, żeby zapobiec albo zminimalizować ryzyka projektowe? Łącznie z tym ryzykiem, o którym ty z kolei powiedziałeś, że wykonawca często wdraża kontrakt time and material po to, żeby sobie podreperować budżet.

Oczywiście, na pewnym poziomie trzeba ufać sobie, a także ufać, że jeżeli ktoś robi coś 8 godzin, a zadeklarował, że będzie to robił 2, to znaczy, że faktycznie wyniknęły tam dodatkowe rzeczy i tak po prostu musiało być, natomiast w którymś momencie albo chcąco, albo z powodu braku kompetencji wykonawcy lubią sobie przekroczyć pewne rzeczy i trochę naciągnąć strunę. Co taka firma, będąca beneficjentem rozwiązania, powinna zrobić przed wdrożeniem w jego trakcie, żeby później nie być niezadowolona z własnej winy?

Różne pomysły przychodzą mi do głowy. Takie najbardziej książkowe to jest: „zrobić porządną analizę wymagań”. Czasami dobrym pomysłem jest zrobić osobny projekt samej analizy – co my chcemy. Robimy wewnętrznie czy zewnętrznie, może z innym specjalistą, niekoniecznie tym, który to będzie potem produkował, żebyśmy na końcu takiego etapu czy projekciku zostali z książeczką, która pokazuje, czym będzie ten system i żeby rzeczywiście zamawiający rozumiał, co tam jest napisane, wyrysowane i jakie to rodzi konsekwencje. To bardzo, bardzo ułatwia i ratuje wiele sytuacji, natomiast tej świadomości, że to powinniśmy zrobić, często nie ma. Ta świadomość jest nawet większa po stronie dostawcy, bo oni, żeby chronić samych siebie, robią taką analizę wymagań. Często nawet nie wliczają tego do budżetu, ale po prostu robią, bo to i tak daje im korzyści.

Druga rzecz, która mi przychodzi do głowy, to jest przerzucić ryzyko na drugą stronę. To już jest kwestia siły negocjacyjnej. Pamiętam kontakt, który negocjowaliśmy. Stosowaliśmy tam żelazną konsekwencję. To był kontrakt e-Commerce, gdzie wdrażaliśmy CRM-a, który miał być takim przede wszystkim frontem dla klientów, takim sklepem, a te funkcje CRM-owe poschodziły na plan dalszy. Jedyne, na co kategorycznie postawiłem nacisk, to żeby to była umowa typu fixed price. Prawie nic właściwie nie negocjowaliśmy – stawek, kosztów, nawet terminu. Pytaliśmy: „Ile wam to zajmie?”, dostawca mówił: „Tyle”, no i OK, piszmy to. Pytaliśmy: „Ile to będzie kosztowało, a oni mówią: „No, trudno to ocenić”. „No ale spróbujcie oszacować, my zaakceptujemy waszą uczciwą wycenę” – odpowiadaliśmy. Oni nam dawali wycenę, byliśmy właściwie 1 do 1, wpisywali – dobra, to taki koszt. Natomiast schody zaczęły się w pewnym momencie, bo dostawca, jak już wszystkie parametry były wycenione i uzgodnione, czyli główne wymagania, terminy czy też z grubsza koszty, przysłano umowę typu time and material. W tym momencie wróciliśmy do naszej argumentacji: „Ale my chcemy fixed price”.

Przeoraliśmy tę umowę i zamieniliśmy ją na fixed price, usuwając wszystko, co było tam elastyczne, bo na tym jednym nam zależało. Dlaczego? Dlatego, że nie chcieliśmy ponosić ryzyka. To może było wyrachowane, ale na tym polegają negocjacje. Długo żeśmy to negocjowali, ale problem dostawcy polegał na tym, że, po pierwsze, ponieważ on nie miał innych zleceń, to, po drugie, zaczął pracę przed podpisaniem kontraktu. Jeżeli zakładam czapeczkę negocjatora i widzę taką sytuację, to zacieram rączki, bo w tym momencie każdy dzień powoduje, że on się bardziej angażuje, ponosi koszty korzystania zespołu, a cały czas kontrakt nie jest dopięty na stole. Klient mówi: „Słuchaj, termin akceptuję, kwotę akceptuję, tylko że natura umowy musi być inna”. Woziliśmy się przez cały miesiąc, ale byliśmy bardzo konsekwentni, bo system cały czas powstawał. Oni nam cały czas udowadniali, że są na coraz słabszej pozycji negocjacyjnej. Mówię to też, żeby uczulić dostawców na przyszłość, bo mogą trafić na kogoś, kto wykorzysta tę sytuację. Myśmy konsekwentnie chcieli zmienić naturę współpracy i w końcu oni podpisali ten fixed price.

Właściciele spółki byli źli bardzo na nas, że myśmy to wymusili. Wyobrażam sobie, że czuli się trochę zawiedzeni. Nie oszukani, bo myśmy od początku mówili, że wszystko OK, super, ale fixed price. W pewnym momencie doszło do takiej sytuacji, gdzie szło wszystko ładnie, ale zmaterializowało się ryzyko, którego się bałem. Coś było nie do końca przemyślane. To było coś, co wspomniałem przed chwilą, czyli uwzględnienie wizyty u psychologa, sam proces łączenia kalendarzy – czy ty lub ja mam czas, potwierdźmy sobie, przestawmy, jak już dojdzie do skutku, no to zabookujmy termin, powysyłajmy notyfikacje – takie drobiazgi. Jednak okazało się to bardziej złożone, niż się wydawało dostawcy. Myśmy mówili, że to ma być, nie definiowaliśmy, bo dostawca nie naciskał, a w momencie, gdy ja miałem w kieszeni fixed price, to w tym momencie ryzyko jest po drugiej stronie. Jak przyszło do definiowania tego procesu i jego implementacji, to się zaczęło. Wychodziły kolejne warunki, niuanse, które opóźniały pracę, zwiększały czasochłonność. W pewnym momencie dostaliśmy sygnał od zespołu, że właściwie oni już przekroczyli kosztowo to, co jest zapisane w umowie, czyli jechali na marży ujemnej. No ale właśnie o to chodziło, żeby to nie był nasz problem.

Wybór typu kontraktu jest wiec też techniką zabezpieczenia się zamawiającego, przy czym tutaj jeszcze było jeszcze jedno założenie – takie, że my na koniec przejmujemy kompetencje, czyli my nie potrzebowaliśmy współpracować z tym dostawcą, jak bardzo by się na nas nie obraził. Nie potrzebowaliśmy współpracować w długim okresie. Myśmy chcieli, żeby nam dowiózł to dzieło, które było zamówione, i mogliśmy skończyć współpracę. Założenie było takie, że przejmujemy kompetencje i utrzymanie sobie robimy sami. Tak zresztą też się stało. Co więcej, żeby pokazać, jak można być wrednym, to żeby zachęcić dostawców do podpisania umowy fixed price, myśmy mu zaproponowali większą zaliczkę: „Słuchaj, tak dużo się napracowałeś, podnieśmy zaliczkę. W ramach stałej kwoty zapłacimy ci dużo na starcie, żeby poprawić tę płynność”. Rozumieliśmy, że tutaj pojawiają się problemy – zatrudnia zespół, a nie ma umowy, przychodu. To też był pewien argument, który go (tak zgaduję) przekonał do umowy, która przerzucała ryzyko na niego. Dostał naprawdę dużą część kwoty w zaliczce, ale kilkadziesiąt procent zostało na koniec, i to było fixed price’owe. To zostało zapłacone dopiero wtedy, gdy odebraliśmy zakres. Ten zakres rzeczywiście był na tyle ogólnie określony, że na poziomie pracochłonności generował ryzyka.

A nie masz takiego wrażenia, że to jest handlowanie ryzykiem za jakość? Realia fixed price’owe wyglądają często tak, że na początku wszystko jest fajnie, każdy się wykazuje do momentu, w którym nie przechyli się ta szala sponsorowania projektu. Jak się ona przechyli już na niekorzyść wykonawcy, to bardzo często (przynajmniej ja to tak obserwowałem) odbijało się to po prostu na jakości, pojawiały się ścinania zakrętów. Jeżeli wymaganie było opisane zbyt ogólnie, to się realizowało je w najbardziej oczywisty sposób, czyli ten najmniej kosztowy. Na koniec zakres był dowieziony, operacja się udała, tylko pacjent zdychał, bo tego się nie dało używać. Nie masz wrażenia, że to jest takie sztuczne budowanie bezpieczeństwa?

Może być taka sytuacja, jak najbardziej, że się będzie robiło tak brzydko, jak klient sobie zażyczył, natomiast jeżeli chodzi o jakość na poziomie działa czy nie działa, to da się sprawdzić, zrobić przed odbiorem solidne testy. Jeżeli chodzi o jakość w rozumieniu estetyki czy też rzetelności pewnych rozwiązań, wydajności, długofalowej stabilności, to rzeczywiście ten dług techniczny może być gdzieś tam ukryty i zepchnięty w przyszłość. Tutaj jest rola tego, który wtedy koordynuje taki fixed price’owy kontrakt, żeby po prostu się upewniał, że wybrana metoda pasuje i żeby na każdym kroku tego pilnował. U nas był project manager, który wiedział, czego chce. Mieliśmy też o tyle łatwiej, że to wszystko było stawiane na Salesforce. Tam jest otwarty kod, tam, gdzie się skrypty pisze, więc nawet, gdyby coś było zrobione byle jak, to myśmy mieli do tego wgląd, to nie było kompilowalne. A kompetencje, jak mówiłem, zostały u nas, więc myśmy świadomie podjęli takie ryzyko.

Masz jednak rację – to prowadzi czasami do kompromisów. Tyle, że podejście zwinne też może do nich prowadzić. Jeżeli po 20. sprincie klient jest już naprawdę zirytowany, zaakceptuje te faktury, ale już po prostu drepcze pod drzwiami: „Ale kiedy skończycie? Kiedy skończycie?” i u dostawcy już zaczyna się robić ciepło, bo nie wiemy, czy klient nie zerwie za chwilę umowy i nawet nie odbierze prototypu, po prostu byleby odebrać, natomiast nie będzie z nami współpracował, a jeszcze pójdzie zła reputacja na rynek, że: „Nas strasznie naciągnęli, a dostarczyli, zobaczcie, to nie działa”. No bo jak było odebrane przed przedostatnim sprintem, to miało prawo nie działać, ale firma może różne rzeczy opowiadać. Takie sytuacje też w agile mogą się pojawić – takie niepożądane kompromisy. Szczególnie, że w agile klient odbiera tą warstwę funkcjonalną. Patrzy – jest inkrement? Działa? Realizuje mi jakiś cel? Ale, przynajmniej taka jest moja opinia, rzadko weryfikuje, w jaki sposób realizuje te inkrementy. Tam też da się spychać dług techniczny. Nie chcę dyskutować o ideałach, które są zapisane w rozmaitych poradnikach, guide’ach i tego typu rzeczach, ale w życiu tak bywa.

Miałem kiedyś taką sytuację – był rozwijany system w e-Commerce – miał być sam intranet przez Internet, ale B2B w pewnej firmie. Szef tej firmy powiedział: „Marcin, mam problem. Mamy dostawcę, on rozwija ten system już bardzo długo, my płacimy kolejne faktury, ale ja nie widzę przyrostu. Nie widzę, żeby on robił coś więcej. Kolejny sprint i nic mi się nie zmienia. Co się dzieje?”. Założenie było takie, że dostawca ściemnia. Przyszedłem na to spotkanie z nimi posłuchać, co się dzieje, i też miałem ukryte założenie, że na pewno go oszukują, na pewno nic nie robią, tylko ściemniają. Okazało się, że nie. Odebrałem ten zespół jako bardzo zaangażowany, zmotywowany, naprawdę fajni, młodzi ludzie, którzy chcieli coś fajnego zrobić, chwalili się tym, co oddali. Zrobiliśmy sobie na tym spotkaniu rachunek sumienia i zapytałem: „Słuchajcie, a co z tego zobaczy prezes albo szeregowy pracownik waszego klienta?”. Okazało się, że jest refactoring – to może nie. Tutaj żeśmy poprawili dokumentację – no to nie. O, tutaj jest – wydajność poprawiona! O ile? No 2 razy, z dwóch sekund zeszliśmy do sekundy. Aha, i to zobaczy? Faktycznie, może nie będzie to aż tak widoczne. Nagle się okazało, że po części dlatego, że product owner nie pilnował rzeczy, po części dlatego, że zespół miał sporą wizję rozwoju tego rozwiązania, przestali dostarczać wartość. Takie sytuacje też się zdarzają. Akurat tutaj to nie jakość była problemem, bo ona była wysoka, tylko robili nie to, co trzeba. Ale agile nie gwarantuje niczego.

Pytanie tak naprawdę, jakie największe ryzyka eliminuje jedno lub drugie podejście. Co więcej – nie znam (może są) żadnych badań, które by porównywały efektywność pracy zespołu w stylu waterfallowym i agile’owym. Kiedyś sporo ludzi, którzy lubią bardzo agile (tak nazwę tę grupę) mówiło, że agile bardzo wszystko przyspiesza – zwiększa produktywność, były opinie, że razy dwa. Teraz część jest przy opinii, że nie zwiększa produktywności, ale zwiększa responsywność na zmiany, czyli ludzie robią w takim samym tempie, ale jak się pojawia nowa okazja, rzecz, którą warto by zrobić, to są dużo mniejsze opory, żeby troszeczkę skręcić, żeby się nie trzymać precyzyjnie planów. Może to prawda, natomiast nie znam takich badań. Trudno by było takie coś badać, ale nie znam żadnych twardych danych, że tak jest na pewno lepiej.

Odniosę się jeszcze do roli product ownera, którą właściwie poruszyłeś w jednym zdaniu. Jeszcze o nią nie zapytałem, a mam wrażenie, że jest bardzo duża korelacja pomiędzy jakością obsadzenia tej roli a powodzeniem projektu, dlatego że dobry product owner w mojej ocenie to jest taka osoba, która występuje po stronie prawdy, a niekoniecznie po stronie zarządu lub wykonawcy. W zależności od tego, gdzie ta prawda jest, to tam po prostu stanie i rzeczywiście przyczynia się do tego, że te projekty kończą się dobrze. Chciałbym poznać twoją opinię na temat roli product ownera w projektach.

Moją opinią jest znowu: „to zależy”, bo wydaje mi się, że nie ma jednej roli product ownera. Ja zidentyfikowałem co najmniej cztery. Z perspektywy zespołu zwinnego jest to w miarę precyzyjnie zdefiniowane, co robi taka osoba, jakie postawy powinna reprezentować. Tak jak mówiłeś, na przykład stać po stronie prawdy, natomiast schody zaczynają się, gdy się patrzy z drugiej strony tego płotu – kim jest product owner dla reszty organizacji? W zależności od tego, kim jest, on tak naprawdę różne rzeczy robi w praktyce. Prawdę mówiąc, regularnie staram się uciekać od myślenia o wszelkich rolach zarządzania z perspektywy idealistycznej, bo tak generalnie nie jest, to tak nie działa. Gdybyś sobie przeczytał Safe’a albo jakieś inne PMBOK’a czy Prince’a (jest on świetnym przykładem) – jakbyś przeczytał jego podręcznik, to wszystko powinno elegancko działać – wszystkie role są zdefiniowane, wiadomo, kto co robi, nie kłócimy się, wszystko jest super. Tylko że nikt nie stosuje Prince’a. Nawet urzędy niespecjalnie stosują Prince’a. Ale spróbuj przeczytać jako taki, wiesz, przedszkolak – włącz sobie model mentalny przedszkolaka i przeczytaj, jak dorośli współpracują.

No tak! Jestem certyfikowany z Prince’a, tego podstawowego, i rzeczywiście tak jak mówisz, na poziomie idealistycznym jest chociażby to założenie, że tam się nie kłócimy, rozwiązujemy konflikty, idzie wszystkim dobrze i życzymy sobie doskonałej współpracy, natomiast to się kończy w momencie, kiedy twoje stanowisko w firmie robi się zagrożone tym, jak wygląda stan projektu. Wtedy już masz trochę mniejszą gotowość do tego, żeby szukać kompromisu, a bardziej taką, żeby ratować sobie dupę. To już jest pierwszy problem, którego ta książka nie przewiduje.

Scrum też tego nie przewiduje, prawda? Jeżeli cały zespół ściemnia, nie ma żadnej metody w Scrumie na poradzenie sobie. Trzeba wyjść poza Scruma, musi wkroczyć manager i coś z tym zrobić. Jeżeli jest bardzo silny konflikt między dwójką ludzi w zespole, ale naprawdę tak silny, że nie chcą nawet ze sobą gadać, to co Scrum Master powie? „No słuchajcie, warto rozmawiać”? „A my nie chcemy!” No i trzeba „Wyjść poza to pudełko scrumowe i innymi metodami sobie poradzić”.

Natomiast wracając do product ownera, to mówię – to zależy. Jeżeli jest nim na przykład właściciel niewielkiej firmy, który znalazł sobie fajny zespół techniczny z zewnątrz do wykonania czegoś, to myśli sobie: „O, teraz będziemy mieli sklep. Sprzedawaliśmy płytki ceramiczne w naszym sklepie fizycznym, ale dobra, zrobimy sklep internetowy do tego”. On będzie innym product ownerem, nawet jeżeli się naczyta tego, jak powinien się zachowywać, bo będzie miał prawdopodobnie gigantyczną wiedzę biznesową po co mu to jest. Będzie rozumiał każdy aspekt strategiczny tego przedsiębiorstwa, więc także to, jak ten sklep się w to wpasowuje. Prawdopodobnie będzie świetnie rozumiał, czego chcą klienci, bo on z nimi od lat współpracuje. Być może nie klienci internetowi, ale klienci, którzy przychodzą do jego sklepu i oglądają te próbki. Prawdopodobnie jednak będzie słaby z analizy, czyli trudno mu będzie dekomponować jego potrzeby na malutkie punkciki – co tam trzeba zrobić, żeby dowieźć tę jego obietnicę. Prawdopodobnie będzie także słaby z technologii i jednym z głównych problemów będzie to, że prawdopodobnie nie będzie miał czasu, bo on ma biznes do prowadzenia, jest ważnym managerem, właścicielem, dyrektorem lub prezesem tej firmy. Będzie miał dużą decyzyjność, ale trudno go będzie złapać. Tutaj więc będą pewne kompromisy w tym obszarze.

Jeżeli jest korporacja, która robi projekt zwinny i uruchamia go na przykład dla działu marketingu, i product ownerem jest specjalista do spraw marketingu wyznaczony przez dyrektora – dyrektor chce ten projekt, ale specjaliście powiedział: „Ty będziesz tam ownerem, to jest taki zespół, wyłoniliśmy go w przetargu i będziesz mówił, co mamy zrobić”. Znowu – to jest trochę inna rola, bo ten człowiek będzie świetny biznesowo, bo pracuje jako marketingowiec albo księgowy, technicznie bywa różnie, bo to po prostu nie jego fach. Jeżeli chodzi o kwestie analityczne – też może być bardzo różnie, bo to nie jego fach.

Analiza czy cięcie problemu na małe części wymaga szczególnych, specyficznych kompetencji. Może ludzie posługują się językiem typu: „No, musi być fajne, musi tak, słuchajcie, chwytać za serce!”. Kiedyś słyszałem takie wymaganie od takiego product ownera, że system musi być sexy. Nie wiem, co miał w głowie ten człowiek, ale trudno było to zdekomponować na opcje – seksowne systemy informatyczne. Więc będziemy się posługiwać językiem emocji, a nie językiem funkcjonalnym? Będzie miał więcej czasu, ale za chwilę się okaże, że nie ma decyzyjności, czyli zespół go zapyta: „Ty, owner, chcesz tak czy tak?”, „Poczekajcie, ja się dowiem” – odpowie i zniknie. Potem wróci i powie: „Mój szef chce tak”. Rozumiesz, niby on ma stać po stronie swojej prawdy, ale ma szefa. No i będzie realizował wizję szefa tak, jak mu ją sprzeda. Czasem sprzeda mu sprytnie i przekona do swojego pomysłu, a czasem szef stwierdzi, że nie, kategorycznie inaczej, bo ma inne jeszcze zamierzenie strategiczne i to mu się przyda.

Trzeci typ product ownera to jest project manager, który ma waterfallowy projekt na górze. Mówiliśmy o tym wcześniej – on ma budżety, harmonogramy, i gdzieś po drodze ma zakres. Zrobił sobie ten zakres w UBS-ie, czyli hierarchicznej strukturze podziału prac, i część tego zakresu zapisał w backlogu. Teraz do tej części musi założyć inną czapeczkę, zamienić się w product ownera. Wchodzi do zespołu i mówi: „Słuchajcie, a ten wasz kawałek to teraz siódmy punkt poproszę, żebyście mi robili, bo mi z kamieniem milowym koliduje, że tego nie zrobiliście”. On będzie miał świetne rozeznanie w tych wszystkich zależnościach pomiędzy elementami, bo nadzoruje całą dużą inwestycję, rozumie, że zrobienie tego dłużej wpłynie mu na przykład na koszty, na inne kontrakty, na innych wykonawców, na to, co chce biznes. Jednak na przykład już wiedzy biznesowej tak dużej raczej nie będzie miał, jak wcześniej wspomnieli, bo jest project managerem, skacze z tematu na temat. On więc nie jest właścicielem strategii, tego kawałka strategii firmy, tylko koordynatorem. Ma to przepchać i pójść dalej. To jest więc trochę inna rola i jego decyzyjność będzie zależała od tego, kim jest project manager w tej firmie. Może być ktoś ważny, z dużą decyzyjnością, a może być tylko figurant, który nazywa się project managerem, ale głównie rezerwuje sale i robi notatki ze spotkań.

Teraz jak na takim spotkaniu, na które salę zarezerwował samodzielnie, zrobi notatkę, że zespół pyta o to, czy najpierw robić piętnastkę, czy siódemkę, to on na tym spotkaniu nie odpowie, tylko pójdzie do interesariuszy dookoła, wypyta ich, co sądzą, spróbuje wynegocjować jakiś kompromis, wróci i powie: „Słuchajcie, zróbcie połowę siódemki i piętnastki”. To jest inny typ project managera. Decyzje odnośnie backlogu nie są jego własne. O ile on ma domknąć kontrakt, to kto inny czeka na te rzeczy. On więc nie angażuje się w sposób osobisty, nie robi tego dla siebie, pod siebie, tylko jest na zlecenie kontraktowcem dla kogoś innego.

Trzeci typ product ownera to jest na przykład analityk biznesowy, czyli człowiek, który nie jest managerem niczego, świetnie analizuje, świetnie tnie problem na małe części i patrzy, jakie są zależności między tymi małymi kawałkami, ale nie ma prawie żadnej decyzyjności, nie jest biznesowy. Oczywiście, wdrażał być może systemy w tym obszarze, więc regularnie na przykład pracował z marketingiem i rozumie, co robi marketing, ale to nie są jego problemy, nie jest ekspertem od tego, tylko rozumie na czasem płytkim poziomie intencje. Tak naprawdę z każdą decyzją będzie latał do ludzi, którzy zamawiają dane funkcjonalności, i pytał ich: „Słuchajcie, to jak wy chcecie? Jak zrobicie najpierw siódemkę, to konsekwencje będą takie, a jak najpierw piętnastkę, to konsekwencje będą takie, więc tak to się wtedy zmieni”. Rozpisze im szczegółowo analitycznie, ale będzie czekał na decyzję. To w ogóle scrum pomija, nawiasem mówiąc, tę złożoność, która jest moim zdaniem krytyczna dla sukcesu w firmie. Więc – to zależy! Tutaj, wydaje mi się, nie ma teoretycznych sytuacji.

Mam taką uwagę albo właściwie wniosek. Powiedziałeś o czterech różnych typach product ownera, ale na swój sposób każdy z nich jest zły. A czy jest taka modelowa rola, którą ty byś widział? Oczywiście, możemy to rozbić na kompetencje, dostępy, decyzyjność, umocowanie. Jak to powinno być, żeby uniknąć tego problemu, że na przykład zespół czeka albo taki product owner z każdą pierdołą musi latać, albo staje po stronie klienta zamiast po stronie prawdy?

Taka idealna sytuacja? Na pewno ktoś, kto ma czas – to jest pierwsza rzecz, bo to pierwszy problem, który się pojawia, szczególnie wśród ważnych decydentów. Powinien być ktoś, kto czuje temat i po co on jest, bo wydaje mi się, że product owner odpowiada przede wszystkim za rezultaty – co z tego wyniknie później. To, co jest zawarte w backlogu, jest dla niego narzędziem do osiągnięcia późniejszych rezultatów. Z tej perspektywy patrzę.

Całe sortowanie backlogu ma na celu dostarczenie tych rezultatów, czyli wartości, która jest po projekcie. Powinien więc to czuć, powinien się z tym utożsamiać, powinno to być jego. Idealnie, jeżeli to on będzie później z tego osobiście korzystał i będzie zadowolony lub zirytowany tym, co dostał, bo wtedy bardziej się przyłoży. Trudno się deleguje odpowiedzialność za rezultaty, trudno jest przekazać to osobiste zaangażowanie. W idealnej sytuacji powinien też umieć rozbić na części swoje potrzeby, czyli zamienić emocje, że: „O, klienci się zakochają!” na 20 funkcji, które w efekcie spowodują, że klienci faktycznie się zakochają.

To często się osiąga poprzez facylitację, czyli taki product owner umie poprowadzić warsztat, na którym przeprowadzi swoich interesariuszy, a później również zespół, przez ścieżkę rozumienia – od emocji klienta końcowego: „Dlaczego ja chcę tu kupować? Dlaczego chcę wracać? Dlaczego raczej tutaj domknę koszyk niż u konkurencji?” do konkretnych funkcji na konkretnym ekranie. Tutaj są różne metody, tylko on powinien umieć to zastosować, widzieć, kiedy ten zespół zebrać: „Słuchajcie, my nadal nie mamy przekonania, jak chcemy to osiągnąć, pogadajmy jeszcze raz”. Ja bym widział te trzy cechy: czas, osobiste zaangażowanie w powód, dla którego projekt uruchomiono, żeby ten inkrement był mój własny, i umiejętność facylitacji problemu, rozbijania go na części z zespołami i interesariuszami.

Na koniec zapytam o twój ulubiony błąd, który popełnia się przy wdrożeniach projektów metodą zwinną. Taki najbardziej popularny, który dla ciebie jest numerem jeden?

To jest błąd, ale zwinność próbuje go trochę ochronić. To błąd generalnie przy projektach, a przy zwinności on jest mniej widoczny. Płaci za niego klient – to spełzanie wycen, Przy podejściu zwinnym też się szacuje, coś się też zakłada: czy to przez ilość sprintów, czy wyceniając pojedyncze elementy backlogu. Te szacunki są na ogół bardzo błędne, przy czym przy agile’u to klient płaci.

Tutaj trudno o dobre metody, bo tak naprawdę ten wysoki poziom ryzyk, który towarzyszy projektom zwinnym, jest źródłem tego błędu. Po prostu nigdy tego nie robiliśmy, w związku z tym nie wiemy, ile zajmie, więc zgadujemy. Nawet są badania pokazujące, jak bardzo zgadywanie jest błędne. Philip Tetlock zajmuje się badaniem syndromu expert judgement – czyli ja z głowy coś mówię, że „to na pewno będzie tak”. On pokazuje na bardzo precyzyjnych, wręcz statystycznie dowiedzionych badaniach, że expert judgement generalnie nie działa, prowadzi do błędnych konkluzji na poziomie statystycznym. To jest więc najczęstszy błąd. Ponieważ klient płaci, to dostawcy tego nie czują, przynajmniej krótkoterminowo, natomiast tu mogą to poczuć. Kiedy? Gdy klient stwierdzi, że ma dość bycia naciąganym i ponoszenia kosztów wszystkich niedociągnięć w zarządzaniu, jaki ma dostawca, i stwierdzi, że szuka kogoś innego. Jeżeli na rynku nie ma lepszych, to pół biedy dla dostawców. Klient kiedyś wróci, bo trafi na równie słabego.

Druga natomiast sytuacja jest taka, gdy błąd się mści na dostawcy, kiedy rynek cały się zmienia, kiedy następuje odpływ, bo kiedy jest wysoka fala, kiedy firmy dużo zamawiają rozwiązań IT, to my możemy je sprzedawać drogo. Jak je sprzedajemy drogo, to każdy nasz błąd i tak będzie pokryty tą ekstra marżą. I tak swoje zarobimy, nie szkodzi, że projekt spóźnił się dwa razy. Nie szkodzi, że musieliśmy klientowi za darmo później w ramach reklamacji dorobić jeszcze 40 osobo-dni, bo jednak agile zakłada jakiś odbiór, a później jeszcze mogą być prace związane z poprawkami, za które klient już wtedy nie chce płacić, bo przecież odebrał. Tu się tak jeszcze mści. W takiej sytuacji, kiedy jest odpływ, firmy zaczynają sprzedawać swoje rozwiązania coraz taniej, bo jest coraz mniej klientów na rynku, czyli kończą się tłuste czasy.

Te firmy, które potrafiły efektywnie estymować zakres czy też czasochłonność tego zakresu, korzystały po prostu z wysokich marż, miały dużo pieniążków, być może inwestowały, być może przejadały, ale potrafiły zarobić. Jeżeli te marże spadają, nadal potrafią zarabiać, natomiast te, które miały duże problemy z estymowaniem i nie doszacowywały tych godzin, w momencie, kiedy te marże spadają, zaczynają tracić. Nagle okazuje się, że pierwszy projekt robią na zerowej marży, bo musiałyby taniej sprzedać i niestety nic nie zarobili. Drugi projekt robią na ujemnej, bo trzeba było jeszcze taniej sprzedać, ale my cały czas robimy tak samo, nie robimy lepiej, niestety. Jeżeli kilka projektów z rzędu będzie sprzedawanych po niższych cenach, a przez to na ujemnej marży, a firma nie nauczy się sprawniej prowadzić projektów, lepiej, na przykład, estymować, to zbankrutuje. Wtedy nawet w lukratywnych sektorach zaczyna się seria bankructw, bo płynność jest zagrożona.

Ten błąd więc potrafi zemścić się na dostawcach, a mam wrażenie (nie wiem, czy się ze mną zgodzisz), że właśnie teraz się zbliża taki okres korekty na rynku IT, bo w niektórych firmach są zwolnienia, klienci wstrzymują budżety, bo w Stanach padł bank, który zajmował się technicznymi startupami. I bo GPT – i tutaj nie wiadomo, jak to się rozwinie, jest taki okres niepewności. Teraz to weryfikuje, kto jest sprawny, a kto nie.

Ja też to widzę. Widzę, że zaczyna się ten okres, gdzie przetrwają na pewno najlepsi. Wielu rzeczy, które rynek wybaczał, myślę, że w nadchodzącym czasie po prostu nie będzie już wybaczać, bo nie będzie musiał, bo będzie nadpodaż dostawców, więc zawsze można wybrać i zaryzykować, że nie będzie gorzej.

Te firmy, które, tak jak mówisz, nie potrafią sobie poradzić z wdrożeniami, czy popełniają te wszystkie błędy, o których mówiliśmy wcześniej, czyli właśnie niedowożenie obietnic, niedowożenie inkrementów, które niosą wartość biznesową – to powoduje później frustrację niezależnie od tego, czy to było w dobrej, czy w złej intencji, czy w imię reperowania budżetu, czy po prostu „tak wyszło” – te firmy na pewno będą przeżywały teraz trudniejsze czasy.

Warren Buffet miał taki fajny cytat, że jak przychodzi odpływ, to wtedy widać, kto pływał bez gaci. Oczywiście, nie życzę tego, to też są moi klienci, więc szkoda, gdyby ten rynek trochę nam zwątlał, ale wydaje mi się, że właśnie tak teraz może być. Ta sytuacja teraz zweryfikuje, kto się trzyma dobrze, a kto źle. Przy tym jest tu też taki problem, że największą świadomość tego, że trzeba coś robić inaczej, na przykład inaczej zarządzać projektami, jest w momentach kryzysu, i to jest najgorszy moment na wdrażanie zmian. Najlepiej się wdraża, kiedy jest spokój, kiedy mamy nadmiar gotówki, możemy eksperymentować. Wtedy natomiast często nie ma woli.

Marcinie, to na koniec pytanie o dodatkowe źródła wiedzy. Mam wrażenie, że dzisiaj tak trochę podrapaliśmy po powierzchni ten temat i to jest temat rzeka. Mimo że manifest agile jest dość krótki i zmieści się na jednej stronie A4, to tych źródeł trochę powstało. Czy są jakieś, które ty byś szczególnie polecał?

Mam taką hipotezę na temat manifestu agile, dlaczego jest tak krótki. Nie mam żadnych dowodów, ale moja teza jest taka, że jak się spotkało twórców kilkunastu metodyk zwinnych, które w tamtym czasie były rozwijane, to było jedyne, na co mogli się dogadać: „Dobra, chłopaki, dwa dni posiedzimy, to chociaż tyle, co? Niech wam będzie”.

Jakieś źródła wiedzy bym polecał? Jak wspominałem, dużo tych projektów klasy discovery, nazwałbym – „projekty eksploracyjne”, bo to troszeczkę szerszy termin, i tutaj jest parę fajnych książek, które chętnie bym podrzucił. Jedną z nich jest Incremental Commitment Spiral Model, troszeczkę spoza IT. O tyle fajna, że Barry Boehm (wieloletni dyrektor daty, jeden z moich rozmówców, gdy rozmawiałem na temat mojej książki, którą piszę) przez wiele lat był dyrektorem w DARPA-ie, czyli w takim światowym mateczniku innowacji, który tworzy różne rozwiązania zaawansowane głównie dla wojska, ale one często przenikają do cywila, chociażby Internet. On opisuje model spiralny rozwoju projektów bardzo niepewnych.

Druga (jeszcze mam ją tutaj na stole) Katheriny Radeki, to jest High Velocity Innovation. How to Get Your Best Ideas to Market Faster. Całkiem fajna, krótka książka, parę sympatycznych konkretów tutaj pani proponuje, przy czym nietypowa, ponieważ na ogół agile migruje z software’u do hardware’u, bo narodził się w obszarze motoryzacji, ale potem przeszedł szybko do software’u i tutaj rozkwitł. Teraz projekty hardware’owe czerpią inspiracje, natomiast pani Radeka i pan Boehm, są przedstawicielami tego nurtu hardware’owego, tam, gdzie się robi sprzęt, i warto się zainspirować w drugą stronę – co im wychodzi, dlaczego nie wychodzi, jakie są ograniczenia.

Jest fajna książka w kontekście z kolei eksplorowania szans biznesowych, tego, czy to się nam opłaca, czy to się sprzeda. Jej tytuł to Testowanie pomysłów biznesowych – niepozorna książeczka, która zawiera listę eksperymentów, które możemy prowadzić na klientach, szczególnie internetowych. Wyszła jakiś czas temu nawet po polsku i zawiera rozmaite pomysły, jak przetestować, czego chce klient, czyli jak robić właśnie fake’owe landing page i co z nich można wyciągnąć, fake’owe guziki, które nam testują, czy klient jest tym zainteresowany, czy nie, zanim w ogóle wyprodukujemy daną funkcjonalność. Nie jest to podręcznik, tylko taki leksykon, spis, ale fajnie jest to opisane.

Całkiem podobała mi się książka Metoda Lean Startup, która jest bardzo znana, to nie jest świeża pozycja. Zapewne też kojarzysz Lean UX dla zespołów AGILE Erica Riesa – to kontynuacja tej koncepcji. Też adresowana do obszaru testowania nowych biznesów, w tym przede wszystkim biznesów działających w Internecie. Duża część tych metod opiera się na podstawieniu czegoś w Internecie i patrzeniu, kto przychodzi, jak się zachowuje, jak korzysta z danego rozwiązania internetowego.

Jeśli mogę autoreklamę wrzucić, to popełniłem jakiś czas temu taką nietypową (wydaje mi się) książkę na temat Scruma, przy czym nietypową dlatego, że jest to powieść o projekcie, który nie powinien wręcz być prowadzony zwinnie – o projekcie ukradzenia pewnego dzieła sztuki. Zatytułowana jest Zwinni. Zbrodnia i Scrum. Jak sam przyznaję we wstępie, gdybym miał kraść dzieło sztuki, to raczej bym to zrobił waterfallowo, bo jest tylko jedna próba. Później, jak coś nie wyjdzie, będzie już za późno. Trudno zrobić to „adapt”, natomiast tutaj ta banda przestępców próbuje stosować Scruma do tej wielkiej kradzieży. Zachęcam więc, może kogoś zainteresuje ta pozycja.

Super, wszystko podlinkuję! Myślę, że jeszcze parę twoich publikacji dodatkowych też się znajdzie na tej liście, bo dość skromnie podszedłeś do autoreklamy, jednak trochę więcej w życiu się napisałeś. Na sam koniec już pytanie natury czysto inspiracyjnej: gdybyś miał naszych słuchaczy zostawić z taką jedną myślą, apelem, hasłem – taką jedną rzeczą, którą chciałbyś, żeby każdy zapamiętał po tej rozmowie, to co by to było?

Chciałem powiedzieć: „nie pływajcie bez gaci, bo może nadejść odpływ” (śmiech). Jeśli mam powiedzieć poważnie: analizujcie wymagania. Jeżeli klient nawet łyka, akceptuje z olbrzymią dozą zaufania dzisiaj to, co mu tam opowiadacie, na bardzo ogólnym poziomie, to nie znaczy, że w połowie projektu nie straci zaufania i nie będzie miał pretensji.

Często więc klient nie ma świadomości, że nie wie, czego nie wie, i w związku z tym analiza wymagań jest dobrą metodą w projekcie, aby troszeczkę, mocno redukować właśnie ryzyka, czyli uświadomić klientowi: „Słuchaj, ty chcesz tego, czy to na pewno tak ma działać? Czy tak to sobie wyobrażasz? Czy twoim zdaniem da to rezultat? Czy to pomoże ci w twoim biznesie, który chcesz robić? Zobacz, a inni robią tak”. Czyli im szybciej będziemy uświadamiali klienta co do tego, czego chce, tym lepiej, bo on zbuduje sobie wtedy zaufanie: „O, wiedzą, o czym mówią! Robili to! Wyprowadzają mnie z błędu!”. Jest część klientów, która potraktuje zwracanie im uwagi na starcie jako na taki atak personalny – zdarzają się tacy ludzie, którzy nie lubią, jak ich się wyprowadza z błędu, tu trzeba być oczywiście, czujnym. Natomiast duża część klientów lubi, jak im się powie: „Słuchaj, a może byś tak zrobił, a może tak?”, bo odbierze to jako zaangażowanie z drugiej strony. Więc należy zwiększyć presję na analizę wymagań na starcie i na upewnienie się, że zakres jest kompletny.

Marcinie, dziękuję za twoją wiedzę, dzięki za naszą rozmowę. Trzymaj się i do usłyszenia następnym razem.

Do usłyszenia, dzięki wielkie za zaproszenie.