Efektywna współpraca między klientem, a zespołem wdrożeniowym w projektach e-commerce B2B

Tak. I to jest wtedy taki argument, z którym bardzo ciężko jest dyskutować, bo my mówimy o eksperckości w ogóle nie w naszym obszarze. Specjalistą w tej danej dziedzinie jest klient, my jesteśmy specjalistami o dostarczeniu rozwiązania IT, które ma pomóc rozwiązać jakieś inne problemy, czy na przykład procesowe w firmie, a wtedy słyszymy, że jesteśmy ekspertami. No i to już jest ten pierwszy taki mur, który nie buduje tej relacji, tylko Wiesz, że to jest pierwszy znak zapytania, czy ta współpraca będzie szła dobrze, nie? Tak, z drugiej strony. Na to jest, myślę, dosyć prosty i w mojej ocenie, przynajmniej w moich projektach, skuteczny sposób. Okej, to jakie są odpowiedzialności? I jeśli my sobie wyznaczymy na początku, za co odpowiada Product Owner, czyli osoba odpowiedzialna za projekt i wizję projektu po stronie klienta, i ja wiem, czego się też ode mnie wymaga, bo to nie jest tak, że jak ja zlecam to do dostawcy, to mogę za rok przyjść i powiedzieć, okej, to pokażcie mi, jak to pięknie działa, bo ja to w głowie widziałem tak i teraz chcę widzieć to faktycznie, wyklikać.

Czyli ja już na tym poziomie przed przystąpieniem do pracy wiem, gdzie ja będę potrzebna, co ja będę musiała wiedzieć, kogo ewentualnie będę musiała o to dopytać, jakie inne kompetencje będą mi potrzebne, żeby ten cały projekt dostarczyć, to zminimalizujemy to ryzyko właśnie przerzucania na dostawcę. Dobra, nie wiem jak to zrobić, to wy jesteście ekspertem, zajmijcie się tym. Tylko to ma dwie strony, no bo to muszą być odpowiedzialności i product ownera po stronie klienta, czyli okej, to ja wiem, co mam do zrobienia, ale też ja jako klient chciałabym wiedzieć, czego mogę wymagać od dostawcy. Więc chciałabym, żeby właśnie dążąc do tego podejścia takiego partnerskiego, wiedzieć jakby do czego się zobowiązuje dostawca wobec mnie.

To znaczy potrzebne są i usprawnienia w zespole. Ja bym chciała jako klient, żeby te zespoły szukały rozwiązań, żeby robić rzeczy szybciej, optymalizować spotkania. Kto zarządza tymi? Product Owner. Zespół realizuje to, co Product Owner robi. Klient staje się Product Ownerem. No bo ktoś musi mieć tą wizję. Tak, dlatego, no bo ktoś musi mieć tą wizję i jakby powiedzieć o tym, dobra, ale kierunek jest taki, to był fajny pomysł, ale kierunek jest taki. Tu jest jeszcze inny obszar, że nawet jak zespół coś proponuje i powiedzmy sobie, no mamy jakąś funkcjonalność, a zespół zaczyna sypać pomysłami, a może tak, a może tak, to jeszcze pod tym wszystkim jest intencja. Bo jako ludzie też jesteśmy różni.

Jeśli mamy klienta, który odbiera, to może to odebrać też jako okej, ale ja powiedziałem tak i moje było super. Czemu wymyślacie 10 innych rzeczy? To ma być tak. No to tu jest gruby problem, jeżeli mamy takiego klienta po drugiej stronie. I może tak być. I to jest też okej, no bo product owners właśnie są tacy, którzy mają Dużo kompetencji też technicznych i są, mają faktycznie tą wizję, oni wiedzą co chcą wdrożyć, wiedzą jaki jest cel, jaki ma być z tego zysk i tak dalej. A są tacy też prodakonerzy, którzy faktycznie mają ten projekt tak trochę dostali boczkiem. Ale dobry Product Owner wie, że nie jest nieomylny i rzuca jakiś, wiecie, on rzuca jakiś zalążek pomysłu, a obrobienie tego to jest praca całego zespołu.

I to jest, jeżeli jesteśmy w tym punkcie i to wiemy, to już jest super. Start projektu jest ułatwiony, jeżeli wiemy, że cały zespół ma fajne pomysły i może to wdrożyć. To też trzeba wyczuć, a nawet jeśli jest tak, że Product Owner ma takie jednak podejście, że Ja bym chciała, żeby to było moje, tak jak ja to wymyśliłam. To po stronie dostawcy zawsze można te intencje wyłożyć i powiedzieć po prostu na głos. My nie przedstawiamy tego po to, żeby zanegować, żeby powiedzieć, że to jest zły pomysł. Czyli komunikacja znowu. Tylko żeby komunikacyjnie dać znać, Po prostu zastanówmy się, czy nie można tego zrobić szybciej. My to chcemy zrobić też, po prostu dostarczyć tę wartość szybciej. Będziemy mogli robić inne rzeczy już, a z tego już będziecie mogli na przykład, będziecie mogli korzystać.

Podjąć wszystkich dokładnych decyzji, bo to by spowodowało, że projekt by nie ruszył w ogóle przez najbliższe pół roku czy rok, bo byśmy siedzieli, rozmawiali o dokumentacji, po czym dopiero by ruszył. Skończyłby się za rok, dwa lata tak naprawdę, a w tym czasie nasza konkurencja może już nas wyprzedzić. Tak, tylko spójrz, tam dałeś jedno bardzo ważne założenie. To była taka gwiazdka, nawet myślę, że mogła tutaj część naszych widzów to umknąć. Siadamy na pół roku i wybieramy. Czyli mamy założenie, że product owner jest dostępny na pół roku non stop. I to jest już założenie, my możemy takie przyjąć, ale jeśli Product Owner po drodze nam się rozchoruje, czego nikomu nie życzę oczywiście, ale hipotetycznie to albo cokolwiek się wydarzy takiego, że po prostu nam zniknie z horyzontu na miesiąc czy dwa, no to nam wypada 30% czasu na to przeznaczonego.

I teraz oczekiwanie byłoby takie, że termin się Nie zmieni, no bo wiadomo, że przecież było pół roku, ale w cztery miesiące też się da to zrobić. No da się, tylko nie tak dokładnie, nie? Albo trzeba pomyśleć, co musimy zmienić, bo na pewno nie w pierwotnych założeniach, bo da się, jeżeli wprowadzimy jakieś zmiany, czy był większy zespół, cokolwiek, nie? Wiadomo. Tak jest. Stąd myślę, że taka miara, która się pojawia w projektach, to jest jakiś taki, nazwijmy to, procent dokładności przewidywalności. To znaczy, że na analizie przedwdrożeniowej nie chcemy, żeby ona trwała pół roku, rok, tylko chcemy, żeby ona trwała Miesiąc, dwa, żeby złapała grubsze tematy, kontekst na poziomie, nie wiem, 80-70%, a w trakcie trwania projektu, gdzie product owner będzie miał więcej czasu, bo już będzie zwolniony jakby z tej dużej części głównej decyzji, będzie można doprecyzować te 30% czasu, tak, no bo inaczej te projekty, i to tak musi funkcjonować w IT, bo inaczej...

Te rzeczy, ale znowu, powiedziane raz, a napisane dwa. Jakby prowadzenie po stronie i dostawcy, i klienta, dla mnie zawsze to powinna być współpraca takiej dokumentacji projektowej i utrzymywanie tego. Czyli jeśli ja jako klient chcę coś ważnego zakomunikować, to też zawsze chciałabym mieć możliwość, jako Product Owner, mieć możliwości tam uzupełnienia tych danych. Tak samo po stronie dostawcy oczekiwałabym, że jakieś ważne, zmienne informacje będą tam umieszczone. I to jest chyba dla mnie klucz tak naprawdę. Czyli tip dla dostawców i klientów, jeżeli zadanie jest nieopisane, nie realizujemy, klienci starają się opisywać zadania, a jeżeli dostawca ma je podjąć, to po prostu zweryfikuje, czy na pewno wszystkie założenia są jasne.

Są fazy takie, że już mamy tak dużo danych zebranych, że jakby projekt się stoczy. Że teraz trzeba być czas na przerobienie tych danych. A są fazy później odbiorowe, gdzie już pod koniec jest więcej spotkań, no bo chcemy już pewne rzeczy już... Albo fazy utrzymaniowe, gdzie po prostu już na bieżąco weryfikujemy tematy, które zapotrzebowanie i też nie musimy się spotykać w tak dużym gronie. To jest nasza ulubiona odpowiedź, to zależy, ale zacznijmy od jakichś ram, ustalmy coś i sprawdzajmy, czy to się nadaje, czy to się nie nadaje i modyfikujmy na potrzeby zespołu i klienta. Zgadzam się z tym, dlatego że ja mogę wejść do projektu jako product owner po stronie klienta z dużym doświadczeniem, wieloma innymi projektami podobnymi, innymi i mieć swoje pomysły, a mogę wejść jako product owner właśnie, który dostał ten projekt jakby dodatkowo,

I wiemy, czy to jest fajne, czy niefajne, czy nam pasuje, czy nam nie pasuje. I też trzeba wiedzieć, że w projekcie A to się sprawdziło. W projekcie B może się w ogóle nie sprawdzi, bo są inne ludzie, inne zmienne po prostu też, nie? Jedna taka moja myśl, która przychodzi odnośnie jeszcze harmonogramowania, że dlatego, że często te projekty, mówimy tutaj w B2B Master Class głównie o platformach B2B, o projektach B2B, one są powiązane w harmonogramie z wewnętrznymi działaniami. Z wieloma systemami. Teraz nie mogą product ownerzy po stronie klientów traktować wybiórczo harmonogramu. To znaczy, że jeśli harmonogram jest po stronie dostawcy, to go pilnujemy, ale jeśli my musimy się zobowiązać wobec jakiegoś harmonogramu, to tam jakoś to pójdzie, bo mieliśmy często takie też sytuacje. Wszystkiego rodzaju integracje i tak dalej, że one się rozciągały w czasie i mówimy, słuchajcie drogi kliencie, no nam się bufor już kończy, no to, że nam od miesiąca nie możecie oddać integracji, która działa z ERP-em na przykład, no to też powoduje, że my nie możemy zrobić.

My też często nie jesteśmy stroną do takich osób, bo jesteśmy, wiesz, obcymi ludźmi z innego projektu i czasami po prostu nie mamy takiej mocy sprawczej, nie? A słuchajcie, jakbyście mieli powiedzieć najważniejsza cecha Product Ownera po stronie, jeśli Product Owner jest po stronie klienta? Dowożenie. To nie jest cecha. Cecha? Ja jestem z polskiego słaby, więc... Skuteczność... Bo jak was słucham, to myślę sobie o decyzyjności. Decyzyjność, oddawanie. Mamy tą siłę przebicia po prostu. To jest bardzo ważne w cyfrowych transformacjach, w bardzo dużych organizacjach. Mieliśmy taką cyfrową transformację wdrożenie dużego e-commerce'u B2C. I faktycznie w bardzo dużej firmie i tam była dedykowana osoba praktycznie pod zarządem, która była kierownikiem projektu w tej fazie początkowej bardzo mocno, która po prostu była w stanie na każdą pytanie uzyskać odpowiedź w organizacji.

Po zweryfikowaniu może się okazać prawdą. Dopóki tego nie zweryfikujemy, pozostanie w obszarze założeń. I chyba drugi, że to powodzenie projektu jest po dwóch stronach. To nie jest tak, że dostawca to dostarczy i będzie super, albo że product owner zrobi swoją robotę, a deweloperzy to po prostu Tak, to jest sukcesowa strona. To jest praca po dwóch stronach. I tak samo możemy położyć projekt, jeśli po stronie dostawcy zabraknie jakiegoś z tych obszarów, o których dzisiaj rozmawialiśmy. Tak samo, dokładnie taka sama odpowiedzialność leży po stronie product ownera, jeśli gdzieś tam będą jakieś, powiedzmy, słownie niedociągnięcia.

I wiecie, co jeszcze mi przyszło do głowy? To feedbackowanie na bieżąco. To jest rzecz, której szalenie mi... Otwartość na feedback, nie? Tak, otwartość, ale też czasami mi tego brakuje, żeby ktoś się frustruje wewnętrznie, mówi, kurczę, niedobrze mi się z nim pracuje, bo to i to. Jakbyśmy usłyszeli niektóre rzeczy, to szybciej możemy wdrożyć jakieś usprawnienie. I tak samo po naszej stronie. Nie lubię, jeżeli coś siedzi za długo, wolę to od razu przekazać i na przykład zaproponować jakieś rozwiązanie, żebyśmy sprawdzili. Ja zawsze mówię, sprawdźmy i zobaczmy, bo... To, co mówisz, to jest bardzo ciekawe i to może faktycznie bardzo na koniec tak fajnie wybrzmi, że jakby My jako społeczeństwo, ale znowu pracujące, jesteśmy absolutnie zamknięci na feedback ze strony dostawców. To znaczy, jeśli dostawca by nam powiedział, że na przykład ja jako Product Owner źle pracuję, to traktuję to jako na najgorszą w ogóle.

Jak najbardziej. No bo komunikacja, słuchajcie. Super narzędzie. Banał, o którym mówimy, ale komunikacja. Ja wiem, że my musimy kończyć, bo czasu mamy mało. Możemy jeszcze rozmawiać długo. Tam się słuchacze wyłączą. Może tak być. To ja tylko jedno dam do tego feedbacku. Dużo łatwiej jest nam przekazywać feedback, jeśli mamy się do czegoś odnieść. Bo jeśli my sobie na początku zbierzemy jakieś ramy tej współpracy, właśnie te oczekiwania, Czego my możemy wymagać od siebie i od kogoś innego, to przekazując feedback, to już nie odnoszę się do mojej wyimaginowanej po prostu wizji project managera albo product ownera, tylko odnoszę się do tego, na co my się umówiliśmy. Słuchaj, widzę, że ostatnio nie pojawiasz się na spotkaniach, nam to utrudnia pracę,