30 lipca 2023 65:36 Odcinek 097

Sekrety sprawnej realizacji projektów – Mariusz Kapusta

Zarządzanie projektami takimi jak wdrożenie e-Commerce, to prosta sprawa. Niestety nie wszystkie proste sprawy są sprawami łatwymi. Warto się więc dobrze przygotować, żeby później budowa Twojego sklepu internetowego nie była spacerem po rozżarzonym węglu.

W tym odcinku rozmawiam z Mariuszem Kapustą o tym, jak sprawnie realizować projekty. Jeśli zastanawiasz się, czy zlecić projekt na zewnątrz, czy zatrudnić kompetencje do firmy i jaki jest przepis na współpracę bez niepotrzebnych przepychanek, to koniecznie posłuchaj.

Listen to „097 – Sekrety sprawnej realizacji projektów – Mariusz Kapusta” on Spreaker.

Dodatkowe materiały

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

  1. Kanał YouTube Mariusza
    https://www.youtube.com/@zarzadzanieprojektami-mkapusta
  2. Książka Mariusza – Zarządzanie projektami krok po kroku + Karty 12 pytań KISS PM®, z której dowiesz się jak sprawnie realizować projekty
    https://leadership-center.pl/produkt/zestaw-ksiazka-zarzadzanie-projektami-krok-kroku-karty-12-pytan/
  3. Szkolenie Mariusza – Dźwignia Projektowa, dzięki któremu poznasz skuteczny model pracy projektowej
    https://dzwignia-projektowa.leadership-center.pl/
  4. Poradnik ABC Kierownika Projektu autorstwa Mariusza, dzięki któremu zdobędziesz wiedzę o tym jak dobrze zarządzać projektami
    https://projekty.leadership-center.pl/poradnik-PM
  5. Książka Piąta dyscyplina. Teorie i praktyka organizacji uczących się – Peter M. Senge, dzięki której poznasz tajniki nowoczesnego zarządzania
    https://lubimyczytac.pl/ksiazka/151440/piata-dyscyplina
  6. Książka Factfulness. Dlaczego świat jest lepszy, niż myślimy, czyli jak stereotypy zastąpić realną wiedzą – Hans Rosling, która otworzy Ci oczy na różnice pomiędzy tym co nam się wydaje, a co jest realnie
    https://lubimyczytac.pl/ksiazka/4860810/factfulness-dlaczego-swiat-jest-lepszy-niz-myslimy-czyli-jak-stereotypy-zastapic-realna-wiedza
  7. Odcinek 091 – Zwinna realizacja projektów e-Commerce – Marcin Żmigrodzki, z którego dowiesz się czy agile to zawsze idealna metodologia do wdrażania projektów e-Commerce
    https://marekkich.pl/sztuka-ecommerce/091-zwinna-realizacja-projektow-ecommerce-marcin-zmigrodzki/
  8. Odcinek 083 – Jak planować cele w biznesie? – Paweł Pałka, o tym jak poprawnie definiować cele i planować ich realizację
    https://marekkich.pl/sztuka-ecommerce/083-jak-planowac-cele-w-biznesie-pawel-palka/
  9. Odcinek 069 – Rola e-Commerce managera w organizacji – Robert Kwissa, z którego dowiesz się jakie obowiązki powinien tak naprawdę pełnić e-Commerce manager
    https://marekkich.pl/sztuka-ecommerce/069-rola-ecommerce-managera-w-organizacji-robert-kwissa/

Transkrypcja odcinka

Czy prowadzenie projektu w firmie jest zadaniem zarezerwowanym dla odważnych? Według mojego gościa i tak nie masz wyjścia, bo prędzej czy później jakiś projekt Cię dopadnie, więc lepiej być na tę okoliczność przygotowanym. O samych projektach mówi za to, że zarządzanie nimi jest proste, ale nie wszystko to, co jest proste, musi być łatwe. 

W tym odcinku głównym tematem jest więc sprawna realizacja projektów. Jeżeli zastanawiasz się, czy lepiej zlecić wdrożenie na zewnątrz, czy nabyć kompetencje do organizacji, kto jest odpowiedzialny za sukces i porażkę w projekcie i jak pracować na co dzień, żeby zapobiec przepychankom, zamiast potem na siłę uzdrawiać atmosferę, której często uzdrowić się nie da, to ten odcinek zdecydowanie jest dla Ciebie. Mnie nie pozostaje nic innego, jak tylko zaprosić Cię do przesłuchania mojej rozmowy z Mariuszem Kapustą.

Cześć, Mariuszu!

Cześć, Marku! Dzień dobry.

Czy mógłbyś w kilku zdaniach opowiedzieć o sobie, o tym, czym zajmujesz się na co dzień i tak sprzedać trochę siebie mnie i słuchaczom jako eksperta w temacie, o którym sobie dzisiaj porozmawiamy?

Dzień dobry, nazywam się Mariusz Kapusta. Prowadzę butik doradczo-szkoleniowy i Leadership Center, gdzie uczymy, jak rozpoczynać i kończyć z sukcesem projekty w świecie, którym brakuje czasu, brakuje zasobów, a problemów nie brakuje. Te problemy rozwiązujemy – albo prowadząc warsztaty z zarządzania projektami, albo wdrażając dopasowane podejście projektowe, albo wreszcie – dobieramy narzędzia do zarządzania projektami, które powodują, że to wszystko działa. Zajmuję się tym praktycznie całe życie zawodowe, to już ponad kilkanaście lat.

Gdybyś miał tak zero-jedynkowo ocenić sytuację z wdrożeń projektowych, to jest raczej łatwy temat czy sprawa dla odważnych?

Ciekawe pytanie – czy to jest dla odważnych? I tak nie masz wyjścia. Generalnie trafiasz na projekty, więc potrzebujesz je robić. Nawet jeśli ich w ten sposób nie nazywasz, bo większość ludzi nie nazywa świadomie projektów, bo nie wie, że je robi – to jest jedna z tych rzeczy. 

Czy to jest sprawa dla odważnych? To jest sprawa tak na dobrą sprawę dla wszystkich. Myślę, że to jest kierunek – nie ma wyjścia, wszyscy jesteśmy w projektach, one są wszędzie, jesteśmy w tych projektach. Czy to jest łatwe? Generalnie zarządzanie projektami jest proste, ale wszystko, co proste, nie zawsze jest łatwe. Na tym polega ta zabawa, że czasem, jak ktoś ma talent i szczęście, to wszystko super zadziała, ale jak okazuje się, że wchodzimy na pewien poziom złożoności, to ta intuicja, talent i szczęście nie wystarczają. Trzeba się posiłkować jakąś metodą, pomysłem na to, jak ogarnąć złożone rzeczy.

Chciałbym dzisiaj porozmawiać z tobą o bardziej złożonych projektach – takich, które już wychodzą poza jednoosobowe działanie, planowanie sobie pracy i po prostu dowożenie wyników – działaniach, które bardziej zależą od wewnętrznych ambicji i tego, czy cię szef pushuje, czyli bardziej takich projektów, które wymagają zespołu, poukładanej pracy. To są projekty, które są rozciągnięte w czasie. 

Chciałbym, żeby najwięcej wiedzy wynieśli z naszej rozmowy e-Commerce managerowie, właściciele sklepów internetowych, którzy zabierają się za nowe wdrożenie, czy firm handlowych, które chcą przejść transformację cyfrową. 

Zacznijmy może od bardzo ogólnego pytania, dylematu na temat tego, w jaki sposób prowadzić tego typu projekty. Pytanie brzmi: czy lepiej prowadzić projekt zasobami wewnętrznymi, to znaczy budować zespół tylko wewnątrz firmy i siłą rzeczy nim zarządzać, czy lepiej postawić na zewnętrznego dostawcę? Jakie są główne różnice pomiędzy tymi dwoma podejściami?

Nie lubię podejścia zero-jedynkowego. Trzeba było sobie na początek zbudować macierz tylko wewnętrzne/tylko zewnętrzne i gdzieś tam mieszane. Generalnie po to idziemy do zewnętrznego dostawcy. Albo nie masz zasobów po swojej stronie, albo nie masz kompetencji do tego, żeby wykonać daną rzecz, poradzić sobie z problemem, i potrzebujesz do tego problemu kogoś, kto ten problem potrafi rozwiązać. Docelowo to jakby popatrzeć przez rozwój firmy – zaczyna sobie mała ekipa, ogarniamy te tematy sami, uczymy się wszystkiego, bo nas po prostu nie stać, więc uczymy się robić wszystko samodzielnie, ogarniamy rzeczywistość, szybko się uczymy. Jeżeli masz dobry zespół, to on jest w stanie i się zorganizować, bo dobrze z tobą współpracuje, i posiąść wiedzę, która mu jest potrzebna do tego, żeby ten projekt dowieźć. 

W pewnym momencie ten czas się kończy. Generalnie problem wielu firm, do których docieramy, jest taki, że nie tyle nie ma kasy na projekt, tylko nie ma kim go po prostu robić, bo ludzie są już uwikłani w poszczególne zadania, więc na koniec tak de facto potrzebujesz mieć kompetencje pracy zespołowej poukładane, i to jest dosyć istotne, i umiejętność pracy i zarządzania dostawcą też w pewien sposób poukładane. Tym bardziej że czasem zlecasz rzeczy, o których nie masz pojęcia, bo zlecasz dlatego, że ty nie jesteś ekspertem w tej konkretnej dziedzinie i nie zlecasz zadania, które znasz od początku do końca, tylko są tam elementy szarości, które dla ciebie są takim czarnym pudełkiem, w które nie wiadomo jak zajrzeć. 

Może być taka sytuacja, że zlecasz dokładnie to, co robisz, dostawcy i go kontrolujesz. Wtedy dużo łatwiej wiesz, jak kontrolować. To nie jest więc tak czy tak. Trzeba umieć jedno i drugie, tylko żeby umieć z dostawcą, to trzeba umieć przede wszystkim ze sobą, bo chyba największa pułapka, w którą można wpaść: biorę sobie poddostawcę, nieważne po co – czy w e-Commerce, czy gdziekolwiek – wrzucam mu, on jest ekspertem, rozwiąże wszystkie problemy i nie będzie zawracał głowy. Najlepiej niech to zrobi i przyjdzie z gotowym. W usługach się tak nie da.

To trochę zahacza o temat współodpowiedzialności. Zawsze staram się o tym w ten sposób myśleć, że zlecanie projektu na zewnątrz oznacza tyle, że ktoś ponosi współodpowiedzialność za dowiezienie wyniku, natomiast nie stuprocentową. Jest dokładnie tak, jak mówisz, że nie powinniśmy delegować w taki sposób, że rób i baw się dobrze, a ja zobaczę wyniki. 

Chciałbym, żebyśmy spróbowali razem narysować granice odpowiedzialności przy współpracy z dostawcą zewnętrznym – gdzie kończy się moja odpowiedzialność jako właściciela (powiedzmy, że zlecam wdrożenie projektu sklepu internetowego), a gdzie zaczyna się odpowiedzialność dostawcy? Jak to między sobą podzielić?

Spróbuję popatrzeć na zasadzie pragmatycznej, bo ostatecznie odpowiedzialny za projekt będziesz ty jako właściciel. Jeśli po prostu dostawca wysypie, to ciebie będzie bolało. Jakbyśmy się nie zastanawiali, wyciągali konsekwencje (a to przepalony czas, nerwy i tak dalej), to się zadzieje. 

Z perspektywy patrzenia projektowego, to dostawca jest częścią twojego zespołu projektowego i potrzebujesz mieć kierownika projektu, czyli kogoś, kto ogarnie rzeczywistość. Może żeby o tym opowiedzieć, to trochę struktury dla tych, którzy bardziej intuicyjnie działają: jak mamy sobie projekt, to w projekcie mamy taką rolę, która nazywa się sponsor. To jest osoba na tyle wysoko w organizacji, która mówi: „Ja ten projekt chcę mieć i chcę, żeby był dowieziony. Udrożnię wam drogę, zapewnię zasoby i jakby co, to przekonam nieprzekonanych, żebyście mi to dowieźli”. Jednak sponsor najczęściej sam tego nie zrobi. Potrzebuje on kierownika projektu, który ma czas i w jego imieniu będzie ten projekt realizował. 

Rola kierownika projektu to nie jest rola wykonawcza, to nie jest osoba, która będzie wiosłować i robić. To jest rola koordynująca zespół projektowy, żeby razem z kierownikiem projektu dowiózł to, czego oczekuje sponsor w tym, na co się umówiliśmy. Układając się w tych rolach – to właściciel firmy będzie sponsorem, kierownik projektu, w zależności od tego, gdzie go umieścimy w organizacji, im mniejsza organizacja to będzie osoba bliżej zarządu, bardziej, powiedzmy, doświadczona i ogarnięta w zarządzaniu nawet intuicyjne, a dostawca będzie częścią zespołu projektowego wykonującego określony zakres pracy, który ma dla nas zrealizować. 

Tutaj często kryje się ten problem z tą odpowiedzialnością. Zakładamy sobie: „Masz problem?” i budujemy sobie w głowie: „A, przyjdzie dostawca i mi te wszystkie problemy rozwiąże”, tylko ten problem nigdy nie do końca jest zdefiniowany, tylko jest taka wielka mgła. Nie sprzedaje mi sklep albo cokolwiek: „Przyjdą, zrobią stronę, to będzie sprzedawało”. Warto pamiętać, że różnica pomiędzy pracą wewnętrzną i zewnętrzną jest taka, że wewnątrz zespołu ludzie jednak dużo bardziej będą związani z firmą, niż dostawca, który przede wszystkim przyszedł tutaj, żeby zrealizować i zarobić na usłudze powtarzalnej, którą ma do zrealizowania. On dużo bardziej będzie określał swój zakres, w którym się porusza, bo nie jest po to, żeby dopłacić do tego całego przedsięwzięcia. 

Zostawienie we mgle, w takim niedopowiedzeniu współpracy z dostawcą, jest dużo bardziej ryzykowne niż zostawienie tego we mgle we współpracy w zespole. Chociaż uważam, że jedno i drugie jest mało ciekawe, bo może wygenerować problemy. Nakreśliłem więc, gdzie się poruszamy. Tutaj możemy sobie ustawiać tę odpowiedzialność.

Powiedziałeś fajną rzecz, że na koniec dnia tak naprawdę odpowiedzialność za niedowiezienie czy dowiezienie projektu to zawsze będzie odpowiedzialność sponsora, bo rzeczywiście tak jest, że to on z tym zostanie. Przychodzi mi do głowy taka scena, która dzieje się bardzo często, szczególnie kiedy sprawy idą nie tak. Bardzo często potrafi się pojawić dialog, w którym sponsor projektu mówi do firmy, że zrobiła coś źle, na co ta mu odpowiada, że tak im to zostało zlecone, przekazane i w taki sposób to po prostu zrobili. Właściciel mówi wtedy: „Ale to wy jesteście ekspertami i powinniście wiedzieć, że tego się tak nie robi”. Zastanawiam się, jaka jest twoja ocena takiej sytuacji. Czy to jest w ogóle dobry dialog? Co powoduje, że on powstaje? Jak mu zapobiec?

To jest w ogóle ciekawy dialog, bo on dzieje się na kilku poziomach. Ja dorzucę do tego jeszcze jedną anegdotę i spróbujemy to porozbijać. 

Moja siostra wynajęła stolarza do zrobienia mebli w domu. Najpierw ktoś te meble zaprojektował i on miał je wykonać zgodnie z tym planem. Ta usługa, doceniając pracę wszystkich fachowców, nie jest tak złożona, jak wdrożenie jakiegoś złożonego systemu, gdzie dużo więcej można nie wiedzieć. Jest projekt, który masz zrealizować. Tylko były sytuacje, że on nie zrealizował tego zgodnie z projektem. Siostra pytała, czemu on nie zrobił zgodnie z projektem, a on na to: „A bo ja to pani poprawiłem”. Jeżeli po prostu okazało się, że było niezgodne z projektem, mówił: „Ja to pani poprawiłem”, a jak było spieprzone i nie działało, to tłumaczył: „Ja zrobiłem zgodnie z projektem”. Zasłaniał się tym tam, gdzie było mu wygodniej. Realizował to sobie, zmieniając, a tam, gdzie było coś nie tak, zwalał to na projekt. 

Zabawa polega na tym, że jeżeli my wejdziemy w ten blame game, a on się pojawia, to on się pojawia z kilku powodów. Najczęściej dlatego, że jak zaczynamy współpracę z dostawcą zewnętrznym i wewnętrznym, jest dokładnie ten sam mechanizm. Ty chcesz być raczej miły dla ludzi. Na początku jeszcze po prostu jak ktoś nie jest totalnie cyniczyny, to chce mieć klienta, z którym będzie pracował w dłuższej perspektywie i będzie super, great, fantastic. Bądźmy dla siebie mili. 

Z perspektywy dostawcy też jest przydzielony jakiś ekspert, który częściej jest ekspertem w dziedzinie merytorycznej, nie zawsze będzie ekspertem od interakcji międzyludzkich. Najczęściej jest tak, że im bardziej masz kogoś wkręconego w eksperta, to tam ten element pracy z ludźmi, z konfliktem nie jest… nie mówię, że jest upośledzony, ale jest trudniejszy. 

Generalnie jako ludzie chcemy unikać konfliktu. Od początku projektu zaczynają się pojawiać zgrzyty. One muszą się pojawić, bo projekt z założenia operuje na ograniczonym czasie w zakresie, kosztach, od początku mamy problem zasobów. Teraz tak: pojawiają się na początku sytuacje, gdzie klient sobie coś zmienia, no to kierownik projektu po stronie dostawcy mówi: „No dobra, nie wyciągajmy tego, jakoś to ogarniemy”. Ale później się okazuje, że jedna, druga, trzecia zmiana i już to nie jest robione zgodnie ze sztuką, tylko tak, żeby po prostu zrobić. Ta sytuacja w ogóle nie została podniesiona w trakcie i w pewnym momencie okazuje się, że jesteśmy w totalnie dziwnym miejscu, w którym nikt nie chciał być – ani klient, ani dostawca. Ci robią coś bez sensu, klient robi coś bez sensu, bo nie wie. Jak do tego doszło, nie wiem. Jak się do tego doszło? Bo nie podnieśliśmy tego problemu w ogóle na starcie. 

Teraz wracając do tego nieśmiertelnego briefu w marketingu albo gdziekolwiek – jaki problem my w ogóle rozwiązujemy? Na co my się umawiamy? Co my chcemy zrealizować? Trzeba by było wrócić do początku na zasadzie: jaki jest cel? Jaka jest rekomendacja? Na co dostawca się zakontraktował? Jasno komunikować, czy to jest zgodnie albo niezgodnie ze sztuką. Jeżeli chcecie zrobić, to jakie ryzyko niesie ze sobą podjęcie konkretnej decyzji? To jest bardzo ważny punkt na tej zasadzie współpracy, że tutaj odpowiedzialność po stronie dostawcy jest taka, żeby powiedzieć: „Słuchaj, drogi kliencie, ta decyzja wpływa na czas, zakres i koszty w następujący sposób, a dodatkowo tak wpływa na ryzyko”. 

Często tego ryzyka klient nie widzi, że: „Słuchaj, tu możemy postawić to po prostu w ten sposób, nie zrobimy jakichś dodatkowych backupów, ale jak się okaże tego jednego konkretnego dnia, że po prostu ktoś ci zhakuje konto w tym sklepie i tak dalej, to stracisz po prostu bardzo, bardzo dużo. Może więc warto by było jednak dopłacić, żeby to zrealizować. Akurat w przypadku usług ja wierzę w takie podejście doradcze. 

No i teraz jeszcze, żeby nie zamieszać, to ważne jest, żeby na początku wiedzieć, jaki mamy cel, plan i jaki będziemy mieć rytm, żeby się kontrolować. Jak nie ma tego dobrego tlenu na starcie, to później wyłącznie pakujemy się w problemy. Bardzo ważną rzeczą jest też, jak cokolwiek zamawiasz, to warto by było zrozumieć, co tam się dzieje pod spodem. To nie znaczy, jak to ma być wykonywane, tylko z czym się wiążą pewne problemy.

Pamiętam pewną sytuację: gdy wdrażaliśmy naszą stronę internetową, to mając doświadczenie w pracy z naszymi klientami, wiedziałem, że potrzebujemy bardzo mocno rozpisać zakres projektu. Generalnie zakres projektu to jest właśnie to, gdzie w większości wypadków można się rozjechać, bo ty jako klient oczekujesz, że to będzie zrobione, a dostawca oczywiście tego nie uwzględnił. Rozpisaliśmy ten zakres i okazało się, że w pewnym momencie przychodzi do mnie dostawca i mówi: „Słuchaj, to już kończymy”, a ja: „Zaraz, zaraz, ale gdzie jest strona po angielsku i jakieś dodatkowe rzeczy?”. „A nie mieliśmy tego”. Oczywiście, wracamy do tablicy, gdzie był rozpisany zakres: „A, faktycznie”. Po prostu o tym zapomnieli, tego nie zrobili.

Miałem także sytuację, gdzie ja byłem dostawcą i klient sobie zażyczył… Były dwie opcje wdrożenia systemu: opcja A, którą my rekomendowaliśmy, i opcja B, którą chciał klient, upierał się na to, ale niosła ze sobą ryzyko, że nie zadziała. Zarekomendowaliśmy opcję A, klient wybrał oczywiście opcję B. Wysłałem wtedy przytomnie maila, że OK, opcja B wiąże się z następującym ryzykiem, ale przyjmujemy, przechodzimy do realizacji, bo taka jest decyzja ze strony tego i tego, który o tym decyduje. 

Oczywiście temat wywrócił się dwa tygodnie po. Zadziało się to, co przewidywaliśmy. Pierwsza reakcja ze strony klienta? „Słuchajcie, czemu to spieprzyliście?”. Generalnie mówiliśmy, że to może pójść nie tak. „Ale nie mówiliście nam o tym!” Ja po prostu przewertowałem maila, w którym informowałem, co się dzieje, próbując to złapać. Jeżeli my odpuścimy sytuację, w której nie informujemy o tym, jakie rozwiązanie w ogóle zaprojektowaliśmy, jakie ma dla siebie konsekwencje i nie edukujemy trochę naszego klienta, jaką potencjalnie robi sobie krzywdę, podejmując decyzję i co o tym myślisz, no to będzie słabo. 

Łapiąc więc w klamrę: wynik tej rozmowy, ona jest uzasadniona na kilku poziomach, ale ona się dzieje dlatego, że trochę wcześniej nie pogadaliśmy otwarcie o tym, co naprawdę robimy.

Zastanawiam się, czy niezależnie od tego, czy to ryzyko było wcześniej adresowane, czy nie: jeżeli wybije takie szambo – bo umówmy się, że czasem jest tak, że popełniony jest błąd w założeniu i niezależnie od tego, że firma to komunikowała, to ten błąd już jest popełniony i jest na przykład tak, jak w waszej sytuacji, że po dwóch tygodniach coś się wywraca i tracimy kupę czasu, a co za tym idzie, najczęściej też pieniędzy – zastanawiam się, czy da się z takiego ochłodzenia relacji później wyjść i to jakoś wyprostować.

To jest ciekawe. Pewnie się da, ale nie zawsze się da i nie zawsze trzeba. Ja bym to zrobił na zasadzie: „postarajmy się ograniczyć ryzyko dopuszczenia do tego”. Właśnie na początku to, co warto zrobić, to spytać, kto będzie decydował o tym, co wy robicie jako dostawca. Często jest tak, że po stronie klienta jest postawiona jakaś osoba, ty traktujesz ją, że to jest osoba, która ma wpływ na organizację i ją ogarnia. Nie zawsze tak jest. To nie musi być najbardziej asertywna osoba wewnątrz organizacji, więc warto by było poznać strukturę, kto tam właściwie będzie decydował. 

Dam przykład, znowu, nie branża e-Commerce’owa, ale podobny zestaw, i to obrazowo można sobie przełożyć. Jedna firma, która robiła maszyny na zamówienie: przychodzi człowiek, zamawia maszynę na linię produkcyjną i oni ją produkują. Na początku przychodzi jeden gość i mówi, jakie są oczekiwania. Przyjeżdżasz z tą maszyną, montujesz i nagle pojawia się cała masa ludzi, m.in. inspektor BHP i mówi, że tego, tego, tego i tamtego nie ma. Bo proces na początku był niewyłapany i się rozjechał. 

Pierwszy krok więc: ja bym po prostu złapał kogoś w firmie, kto będzie decydował, z kim w ogóle warto rozmawiać, żeby upewnić się, że właściwe osoby wiedzą, co się dzieje, bo jeżeli pojawia się, wybija szambo, to się zaczyna blame game. Osoba po stronie kupującego oczywiście będzie zwalać na dostawcę. Dostawca jest na straconej pozycji, bo dostęp do ucha prezesa ma mniejszy z automatu, więc warto po prostu tutaj się zabezpieczyć, ale jednocześnie mówię: to też jest dobra praktyka pracy po stronie zamawiającego. 

Zorganizuj to w taki sposób, żeby co jakiś czas sprawdzać, na co się umawialiśmy, jakie są postępy pracy, jakie mamy problemy i wyciągnijmy je na wierzch, bo to wtedy powoduje, że przy małych problemach uczymy się rozwiązywać sytuacje konfliktowe i ograniczamy ryzyko, że dojdzie do wybicia szamba – to jest jedna rzecz. Druga – jakby wybiło szambo, to będzie łatwiej się dogadać, bo na małych tematach nauczyliśmy się ze sobą rozmawiać o trudnościach i je rozwiązywać. 

Jak jest duży fakap, to ludziom odpala się gadzi mózg, każdy się boi w tym momencie, olaboga, nie wiadomo, co się wydarzy. Wtedy wyjście z tego jest ciężkie. Po pierwsze więc: ja bym jakoś spróbował uspokoić te gadzie mózgi. Wtedy ważny jest ktoś, kto faktycznie powie: „Dobra, słuchajcie, to w takim razie faktycznie się zadziało, bierzemy na siebie odpowiedzialność, rozwiążemy to”. 

W większości przypadków znowu: jeżeli nie macie do czynienia z patologią po drugiej stronie, to trzeba wziąć pod uwagę, co jest najważniejsze po stronie wdrożenia albo klienta dla ciebie. Że masz kogoś, kto w tym całym pożarze kieruje akcją gaśniczą i mówi: „Tak, biorę to na siebie, ja to zorganizuję. Słuchajcie, mamy problem taki i taki, musimy zrobić następujące rzeczy. Nie mamy informacji, więc wrócimy za dwie lub trzy godziny z informacją, przeanalizujemy sytuację, powiem, co jest”. Pojawia się jakiś plan i poczucie bezpieczeństwa dla osoby, która w tym momencie po prostu najbardziej na tym traci, że da się to ogarnąć.

Jak to jesteśmy w stanie zrealizować, to jest jakiś kierunek, że z tego wyjdziemy. Ja bym jako punkt pierwszy postawił: „Dobra, gasimy pożar, zapewnijmy jakąś ramę w tym wszystkim, a później będziemy się zastanawiać, co zrobić dalej”. Ja w to wierzę i widzę to w ten sposób: jak mam problem, ale widzę, że ktoś bierze na siebie: „Tak, OK, jest problem, ale ja go rozwiążę, biorę na siebie i nie dyskutuję z tym”, to ja się czuję bezpiecznie, że mam do czynienia z kimś, kto po prostu poprowadzi mnie przez ten ogień. Ale jeśli mam kogoś: „Ty, to nie moje, kto jest winny?” etc., to mi po prostu odpala gulę na zasadzie: „Słuchaj, to zaraz wszyscy zginiemy w tym pożarze. Tu nie ma, co szukać winnych, tylko trzeba ogarniać rzeczywistość”. Docieramy więc do odwagi, współodpowiedzialności, takiego indywidualnego project management cojones.

Wydaje mi się, że często jest też taki problem, że firmy błędnie identyfikują osobę, wobec której raportują, to znaczy trafiają na product ownera, który ma bardzo iluzoryczne umocowanie w organizacji i tam tak naprawdę najświętszy to jest prezes, a product owner jest tylko po to, żeby prezes nie musiał się tym zajmować. 

W momencie, kiedy postawi się na takiego konia typu źle umocowany product owner i nie ma się dostępu do ucha prezesa, to najczęściej w sytuacji pożarowej automatycznie robi się duży problem, bo wszystko to jest wina firmy dostawczej.

Ja bym przyjął w ogóle, ale to generalnie patrząc na zasadzie extremum, no to tak – idziesz do klienta, bierzesz na siebie odpowiedzialność za wszystko, co się tam zadzieje. Absolutnie za wszystko, i to nie na zasadzie… Nie lubię takiego podejścia uniżoności, bo takie podejście, jak trochę się traktuje dostawców w Polsce, to nie jest fajny patent. Nie mówię, że wszyscy, ale są sytuacje, gdzie niektórzy traktują cię w ten sposób: „OK, zapłacę ci, a ty jesteś niewolnikiem 24 godziny na dobę”. Ej, nie, my się umawiamy na pewien zakres, co my robimy etc. 

Miałem taką sytuację, gdzie faktycznie było mocno emocjonalnie po stronie klienta z telefonem: „Mariusz, ty chyba chcesz mnie doprowadzić do załamania psychicznego”. Widać było stres po drugiej stronie, dla mnie też, bo to był bardzo duży projekt, który realizowaliśmy. Zadzwonił do mnie sponsor z tamtej strony i pytał: „Słuchaj, jak wygląda sytuacja?”. Pogadaliśmy, ustaliliśmy, co robimy i ogarnęliśmy. Dlaczego? Dlatego, że project manager, który był podstawiony przez sponsora, też nie jest w łatwej sytuacji, jest między młotem a kowadłem. Trzeba mieć naprawdę sporo doświadczenia, pewności siebie i tak dalej, żeby… Czasem musisz powiedzieć prezesowi: „Nie, tak się nie da. Oni mają rację. Słuchajcie, musicie to zrobić, bo tutaj daliście ciała”, ale jeżeli jesteś w sytuacji, że jesteś na etacie, zależy ci na tej robocie i w pewnym momencie myślisz: „Kurde, wszystko zależy od tego projektu i od tego prezesa”, to też odłącza się trochę myślenie. 

Więc znowu, to, co mogłoby pomóc, to nawet nieidealistycznie. Ja się zawsze zastanawiałem: „OK, jeżeli my realizujemy projekt dla kogoś w firmie, to jak my możemy zrobić, żeby on był dla niego sukcesem?”. Tak na dobrą sprawę to my robimy na tę osobę, która do nas przyszła. Jak nad tym popracujemy i się zastanowimy, na czym tobie zależy i jak jesteś oceniany, to mamy szansę też jakoś tym zarządzić. Jednocześnie, znowu, w drugą stronę – jak ty zlecasz komuś projekt, to powiedz jasno, na czym ci zależy, co ma być zrobione, żeby jak najmniej mgły było w tym całym projekcie. Według mnie to chyba jest główny problem, że robimy sobie taką mgłę na zasadzie: „Ja ci wszystkiego nie powiem, bo jak wszystko będziesz wiedział, to olaboga, nie wiadomo, co mi zrobisz”. Tak się projekty trudno prowadzi.

Właśnie mija 25. minuta nagrania, a my ani razu nie mówiliśmy o kompetencjach technicznych. Cały czas pojawia się odpowiedzialność, komunikacja, rozumienie własnych potrzeb, granie w jednej drużynie. Czy to rzeczywiście jest dużo ważniejsze niż kompetencje techniczne? 

Często myślę o tym tak, że kompetencje techniczne to jest takie BHP współpracy, to znaczy jak nie masz kompetencji, to nie pchaj się w projekt, natomiast z trzech firm, które mają kompetencje techniczne, najlepiej zrealizuje projekt ta, która ma właśnie to wszystko, o czym dzisiaj rozmawiamy.

To znowu było trochę uproszczenie, bo ja nie lubię podejścia „kompetencje miękkie”. Jest coś takiego jak power skills. To jest nowy pomysł na to, jak to nazywać, natomiast tak – kompetencje techniczne, to musisz mieć pewien poziom kompetencji, żeby w ogóle wejść do gry na pewnym poziomie. Jak nie masz kompetencji technicznych, to po cholerę w ogóle tam jesteś? O czym w ogóle mamy gadać? 

W projektach zakładamy, że musimy mieć bazowy zestaw umiejętności, w których się poruszamy. Fajnie by było mieć bazową umiejętność współpracy w zespole. Wydaje mi się, że ona jest totalnie niestandardowa i niedoceniana, bo zakładamy, że wiemy, jak współpracować w zespole, a tam są subtelności typu: kto komu wystawia zadania, jak one są wystawione, czy to zadanie jest do zrobienia czy do przemyślenia. Jest sporo takich subtelności, które powodują, że się wywracamy. Kompetencje techniczne potrzebujesz mieć do pewnego poziomu, natomiast w projektach potrzebujemy mieć umiejętność rozwiązywania problemów. To jest jako pierwsza bazowa i z nią trzeba by było zacząć. 

Gdy się uczyłem sprzedawać, usłyszałem (bo ja z IT pochodzę): „Zakładasz firmę, więc musisz się nauczyć sprzedawać”. Na szkoleniu ze sprzedaży usłyszałem coś, co mi bardzo mocno dało do myślenia, że w relacjach z daną osobą jesteś na dwóch ringach: albo na merytorycznym, albo relacyjnym. Na relacyjnym masz taką sytuację, że idziesz na spotkanie sprzedażowe i ktoś ci mówi: „A konkurencja ma lepsze!”, „A nie, bo wasze nie ma zielonego” i biegasz za takimi piłeczkami, próbując zbijać te obiekcje. Tak na dobrą sprawę pokazujesz, że nie jesteś na takim ringu merytorycznym, tylko relacyjnym, ktoś się tobą bawi – albo cię nie lubi, albo cokolwiek, nieważne. Wiesz, że nie gadasz o merytoryce. 

Jeśli przechodzisz na ring relacyjny, ustalasz: „Dobra, słuchaj, czy my tu jesteśmy na zasadzie, że coś jest nie tak i musimy rozwiązać sobie tę sytuację pomiędzy nami, czy możemy przejść do merytoryki?”. Jak przejdziesz do merytoryki, jest trochę łatwiej. Warto przy problemach pamiętać, że one się dzieją na tych dwóch poziomach. 

Nie deprecjonowałbym skilla technicznego, bo to musi być, to jest po prostu taka baza, natomiast nie da się projektu zrobić wyłącznie na umiejętnościach technicznych, dlatego że ty możesz być ekspertem jako dostawca w swojej działce, a klient jest ekspertem od swojego biznesu. Jak nie połączymy tych dwóch rzeczywistości, to możecie być najlepszymi wymiataczami we wszechświecie i na koniec się skończy niczym, bo każdy będzie w swoim matrixie. W projektach trzeba jakoś połączyć te wszechświaty i uzgodnić rzeczywistość. 

My po prostu zrobiliśmy badanie, bo mnie to intrygowało, co działa, że czy da się pracować w zespołach, czy trzeba pracować bardziej hierarchicznie, turkusowo, czy zwinnie, i tak dalej – jakie podejście jest właściwe? Prawie 500 projektów przerobiliśmy dosyć głęboko, zrobiliśmy na tym analizę statystyczną i wyszły nam ciekawe rzeczy: że czasem po prostu, w zależności od kontekstu projektu i dojrzałości zespołu, inaczej będziesz z projektem pracował. Jeżeli zespół jest mniej dojrzały procesowo, to będziesz musiał zarządzać bardziej hierarchicznie i bardziej dawać im wytyczne. Jeżeli zespół jest już bardziej dojrzały, pracuje ze sobą, można działać bardziej turkusowo: „Słuchajcie, działajcie sobie samodzielnie”, a jednocześnie to zależy od ryzyka i złożoności projektu. Projektami, które mają duże ryzyko i złożoność, zarządza się bardziej hierarchicznie niż turkusowo, całkiem zlecając odpowiedzialność. 

Na koniec więc: musi być pewien poziom dojrzałości i technologicznej, i procesowej, żeby na tym działał pewien poziom dojrzałości we współpracy. Znając siebie, można się wtedy zastanowić: „No dobra, to w jaki sposób my będziemy nad tym działać?”.

W takim razie zapytam cię jeszcze o taką odwieczną walkę na rynku IT pomiędzy realizacją projektów w modelu time and material i fixed price. Nie zapytam cię jednak o to, co wolisz i co byś rekomendował, bo ten temat, mam wrażenie, jest już tak wyświechtany, że nikomu się o tym nie chce słuchać, ale zapytam cię o coś, co trochę mi chodzi ostatnio po głowie: czy nie uważasz, że jest to w pewnym sensie temat zastępczy? 

Rozmawiamy o tym, co jest lepsze, ale prawda jest taka, że firmy decydują się na fixed price dlatego, że po prostu nie mają kompetencji, żeby zarządzić dostawcą, żeby jakoś doprowadzić ten projekt do sukcesu, więc trochę wychodzą z założenia: „a w dupie z tym, niech dostawca to podpisze i niech to on się martwi”, no bo na koniec dnia przyjdzie do rozliczenia. Czy nie uważasz, że łatwiej byłoby po prostu sobie te kompetencje nadrobić, dotrudnić i wtedy wejść we współpracę w time and material, czy ja po prostu o tym źle myślę?

Wydaje mi się, że to od zawsze są pewne tematy. Ten fixed price i time and material, nie wiem, czy z właściwego kąta o tym usłyszałeś, bo to jest przy projektach, powiedzmy, agile’owych, a po drugie, to jest agile w wersji z waterfall, to kiedy? Albo motywacja wewnętrzna i zewnętrzna. Wkurzają mnie strasznie takie „być albo mieć”. Tworzymy po prostu… Tak, jak spłaszczamy rzeczywistość do jednego wymiaru i poruszamy się na jednej osi, że musisz wybrać to albo to. Gdybyśmy sobie dodali drugi wymiar i już się poruszamy na macierzy, to nagle się okazuje: „O kurczę, mamy jeszcze więcej możliwości”, a tak naprawdę tych wymiarów będzie więcej. 

W fixed price i time and material trzeba by się zastanowić, dlaczego pakujemy się w ten problem, jak to merytorycznie wygląda. Są projekty, w których znasz zakres, wiesz, co ma być zrobione. Jeżeli znasz zakres i wiesz, co ma być zrobione, i to są projekty, które są przewidywalne, powtarzalne, bo robiłeś podobne tematy, to jest określony zakres, jest jakiś rozsądny bufor ryzyka i jesteś w stanie wtedy przedstawić fixed price, time and material, i to będzie w miarę rozsądne i w tym się wyrobisz. Jednak to dotyczy pewnego typu projektów powtarzalnych: robisz podobną stronę, sklep i tak dalej, czyli coś, co ma stosunkowo zamknięty zakres, pasuje pod fixed price. 

Są natomiast projekty, w których ty działasz najbardziej odkrywczo i musisz przeanalizować, przetestować i sprawdzić, czego w ogóle oczekujesz. Tam zakres nie do końca będzie znany. Są znane kroki, masz określony pewien sposób, budżet na to, żeby rozpoznać rzeczywistość, ale fixed price na coś takiego jest trochę bez sensu, bo z natury rzeczy zakres będzie się zmieniał. Możesz się umówić, że OK, nie da się tego zrobić. Teraz do tego dodajemy sobie jeszcze aspekt: „OK, ja potrzebuję zarządzić ryzykiem tym po mojej stronie jako kupującego. Jak ja w tym momencie podpiszę time and material, to my będziemy całe życie rozpoznawać to, ja przepalę pieniądze i na koniec wyląduję z niczym”. To jest jedna obawa. Z drugiej strony, na poziomie dostawcy, to jak podpiszę time and material, to będę miał dokładnie to, że będę robił to do końca życia i będę utrzymywał tego durnego klienta przez całą rzeczywistość, bo on nie wie, co robi. 

Ja bym więc przede wszystkim zastanowił się nad tym, rozbijając sobie projekt, po pierwsze: czy ty wiesz, co ma być zrobione? Jeżeli tego nie wiesz, to jest spora szansa, że jesteś w fazie analizy i do fazy analizy i rozpoznania bardziej pasuje time and material, a jak już wiesz, co ma być zrobione, to możesz się umawiać na fixed price, bo mamy to ogarnięte. 

W jednej z firm, z którą współpracowaliśmy, zaproponowaliśmy taki model pracy. To firma usługowa robiąca rozwiązania dla klientów na indywidualne zamówienie. Na początku działali z tym modelem, że starali się każdy projekt od razu oszacować, żeby to była stała cena, żeby klient wiedział, ile za to zapłaci. Ale później okazywało się, że czasem przeszacowali, czasem na odwrót i zawsze był problem. Zmieniliśmy model: proponujcie klientom projekty na zasadzie – najpierw jest analiza i tam robimy time and material i wiemy, ile ona będzie trwała, tak że klient nie zapłaci więcej, niż X i tym sposobem ogranicza swoje ryzyko, a na koniec ląduje z rozpoznaniem, a później, na kolejnych etapach, przybliżamy to nasze oszacowanie, bo więcej wiemy, co robimy, i w pewnym momencie możemy podpisać faktycznie kontrakt na zasadzie fixed price, który jest większy, ale jednocześnie zrobienie tej analizy wcześniej ogranicza ryzyko jego niezrobienia, czyli życiowo to jest dużo lepsze i sensowniejsze podejście, bo odpowiada temu, jak rzeczywistość działa. 

Z czego się bierze fixed price? To jest najwygodniej podpisać dla mnie jako managera albo kogoś, kto odpowiada za budżet, bo wiem, że będzie kosztowało tyle, nie mniej, nie więcej, najwyżej będziemy się jakoś przepychać, ale przynajmniej w tabelce to się nie zmieniło. To jest takie moje spojrzenie na ten problem, że nie stosujemy właściwych narzędzi do rzeczywistości, tylko próbujemy jakoś przerzucić ryzyko w jedną albo drugą stronę.

Nie masz wrażenia, że projekty na takim dość dynamicznie rozwijającym się rynku z natury rzeczy będą się zmieniały w trakcie realizacji, jeżeli będą wystarczająco długie? Podejście, które ja rekomenduję, to robić szybką analitykę, taką bardziej na zasadzie sprintu analitycznego, lepiej to doszacować i mieć już takie porządnie skrojone ramy, ale jednak mimo wszystko zostawić sobie bufor na time and material, żeby pracować zwinnie, w alternatywie do tego, żeby robić projekt, analizę projektu przez 9 miesięcy i spowodować, że już pod koniec analizy ten projekt robi się nieaktualny.

Zgadzam się. Jeśli zabrzmiało to na zasadzie, że robimy bardzo długo analizę i po analizie dyktujemy, nie, to nie tędy droga. Chodzi o to, żeby rozpoznać te rzeczy, których nie wiemy, i ruszyć do roboty z tematami, które są najważniejsze. Zgadzam się z tobą, że im dłużej trwa projekt, tym prawdopodobieństwo zmiany będzie większe z kilku względów. Będzie się zmieniać rzeczywistość, ale świadomość klienta też będzie rosła. 

Tutaj właśnie zarządzanie zmianą jest dosyć ciekawym tematem, bo te zmiany czasem wynikają z realnej potrzeby merytorycznej, a czasem z całej masy różnych innych ciekawych rzeczy typu: „My wiemy, że to można zrobić, to my to teraz chcemy”. Nie wiedzieliśmy, że tego w ogóle chcemy, ale my teraz tego chcemy. Ale to, co nie wiemy, ale jest fajne. To jest więc też dodatkowy aspekt. Ja, jak powiedziałeś: „ramy”, ja wolę podejście: „szkielet”. Rama tak jakby ogranicza, a szkielet buduje nam coś, na czym rozwijamy. Często ten szkielet nie zmieni się ot, tak, bo model biznesowy firmy rzadko się zmienia i się wywraca wszystko dookoła. Najczęściej model i główny rdzeń tego, jak firma działa, jest nawet dla dużych firm niezmienny. Wewnątrz bardzo dużo takich tematów się dzieje, ale rdzeń się nie zmienia. 

Jeżeli więc my przeanalizowaliśmy sobie ten rdzeń, mamy szkielet i podzielimy sobie tego słonia na kawałki, przeanalizowaliśmy najważniejszy kawałek, który mamy zrobić, przystępujmy do realizacji, żeby faktycznie to się zadziało. Jestem absolutnie przeciw temu, że nie ruszymy, dopóki nie będziemy mieć wszystkich kropek znanych. To się nie wydarzy, dlatego że rzeczywistość jest trochę bardziej złożona. 

Jest taki gość Dave Snowden. Ja go uwielbiam po prostu, bo jego wykład o takim Cynefin Framework to jest uczta intelektualna. On patrzy na rzeczywistość w ten sposób, że ją możemy podzielić sobie na pięć różnych form. 

Pierwsza to jest taki obszar znany, że ty wiesz dokładnie, jak coś działa, i tam się nic innego nie wydarzy, typu wystawianie faktur. Tam naprawdę nie ma rocket science, po prostu jest stałe i ten proces się dzieje. Księgowość to jest taka ostoja, tam się robi wszystko w pewien oprocesowany sposób. Nie mieszaj tam, bo to robi bałagan. Drugi obszar to jest obszar skomplikowany, który analizujemy. Jak my go przeanalizujemy, to znajdziemy odpowiedź, bo tam odpowiedzi są. Trzeci obszar to jest obszar złożony, gdzie my nie wiemy do końca, jak to działa. To jest na przykład obszar reklamy internetowej. Ty wiesz mniej więcej, jakie są zasady ich odpalenia, ale musisz przetestować, co działa, bo nikt ci do końca nie powie: „To zadziała po prostu w danym zestawie od pierwszego kawałka”. Zabawa polega na testowaniu. Czwarty obszar to jest chaotyczny. Nikt nic nie wie i w tym obszarze po prostu działasz. Robisz cokolwiek, bo bezczynność jest gorsza niż ruszenie gdzieś do brzegu. Piąty jest taki, że my nie wiemy, w którym się znajdujemy. 

Teraz wracając po tej paraleli, to w zależności od tego, jaką masz sytuację, trochę inaczej do tego podejdziesz. Jak masz temat skomplikowany, to tam analiza faktycznie do czegoś cię doprowadzi, ale jak masz obszar bardziej złożony, analiza cię do niczego nie doprowadzi. Doprowadzi cię do listy odpowiedzi, które trzeba było przetestować. Umiejętność zorientowania się, z czym mamy do czynienia i dobrania do tego właściwego sposobu pracy projektowej i poprowadzenia tego, to jest klucz, ale najciekawsze jest to, że jak już świadomie wiesz, z czym masz do czynienia, to tego potwora dużo łatwiej da się pokonać, jak w horrorach. Nie wiem, czy je oglądasz.

Tak, namiętnie!

Ja nie mogę oglądać horrorów, w których nie widać potwora. Jeśli są takie, że jest tam szatan, czy coś, to wyobraźnia tak mi pracuje, że ja tworzę sobie w głowie takiego potwora, który po prostu mnie pokonuje. To jest niesamowite. Jak zobaczę potwora, to już on nie jest taki straszny. 

To jest podobny temat. Mamy do czynienia ze specyficzną firmą, sytuacją, a tak naprawdę tych schematów jest ograniczona ilość. Jak wyłapiesz: „A, z tym mamy do czynienia, to automatycznie taki model zarządzania, to automatycznie do tego bardziej pasuje na przykład time and material niż fixed price. No to zróbmy to, bo wszyscy będą bardziej zadowoleni, pokonamy jakąś podróż w sensowny sposób i później możemy działać dalej”.

Wróćmy w takim razie do organizacji pracy projektowej. Zacznijmy może od takiego dnia „0”, gdzie kontrakt jest już podpisany, przychodzi z jednej strony właściciel, sponsor, product owner, wszyscy po stronie firmy, która tę umowę podpisała po lewej stronie, a z drugiej strony przychodzi wykonawca, który podpisał się po prawej stronie. Jakie masz pro tipy, jeżeli chodzi o modelową współpracę pomiędzy tymi dwoma firmami? Jak to powinno wyglądać?

Wracając do takiej bazowej rzeczy – co sprawia, że projekt się udaje? Cel, plan i rytm. Pierwsze – kwestia potwierdzenia sobie tego celu prawdziwego i tego niewypowiedzianego. Najpierw powiem z perspektywy dostawcy – OK, kto jest kim w tej całej rzeczywistości? 

Kolejne to jest plan – na co my się w ogóle umówiliśmy i czy ten plan jest jasny dla wszystkich osób, o których rozmawiamy? Warto tutaj jako dostawca opowiedzieć, w jaki sposób pracujecie i dlaczego w tej branży robi się tak, a nie inaczej, na przykład jak wygląda proces wytwarzania oprogramowania, dlaczego testy, nie testy, jak działacie. Nie na zasadzie agile, tylko odpowiednio i w całości, dlaczego, bo jak klient rozumie, w czym się poruszamy, a często nie rozumie, to wie, o co spytać. 

Kolejny element to jest kwestia, jak my będziemy sprawdzać, czy jesteśmy na kursie i na ścieżce. To jest bardzo ważny element, bo raportowanie jest traktowane na zasadzie: „O ja pierdzielę, znowu mnie sprawdzają”. Raportowanie to jest punkt bezpieczeństwa dla ciebie i dla drugiej strony. Nawet z perspektywy dostawcy to jest ważniejsze. OK, zrobiliśmy to, to i to, przejdźmy, zobaczmy, czy jest odbiór, czy trzymamy się zgodnie z planem, czy jesteście zadowoleni z tego, co robimy, czy jesteście niezadowoleni z tego, co robimy, co możemy zrealizować. I idziemy do kolejnego etapu – podzielenia sobie tego na takie punkty kontrolne. Nie traktujcie tego jako tylko punkty bezpieczeństwa. To bardzo dużo daje, bo problem, z którym masz do czynienia, jest wspólny, tylko go widać po stronie dostawcy, klient mnie zlewa. Odpaliliśmy projekt i nie ma czasu ze mną być. 

To jest syndrom tego, że ty naprawdę sobie wziąłeś tego dostawcę dlatego, że nie masz czasu i nie masz czasu go niańczyć albo przynajmniej jest podejście na zasadzie: „Zróbcie i nie zawracajcie mi głowy”. Skąd się to bierze? Bo w ogóle nie padła informacja albo część osób odpycha ją od siebie, że angażując się w projekt z dostawcą, ty ileś swojego czasu wewnętrznego też musisz poświęcić na pracę z nim, bo on nie ma całej wiedzy. Nawet jeżeli to jest firma, która pracuje od dłuższego czasu, tego nie ma. Bardzo często ta informacja nie pada na tym wstępnym spotkaniu i nie jesteśmy na to zakontraktowani, że my możemy wykonywać swoją pracę pod warunkiem, że mamy dostęp do waszego product ownera, osoby, z którą będziemy pracować w takim i takim czasie i pewne odpowiedzi będziemy dostawać co jakiś czas. 

Mamy to spotkanie bezpieczeństwa, to nasze kontrolne. Jeśli coś się dzieje nie tak w naszej współpracy, nie mamy informacji etc., to warto to podnieść i powiedzieć: „Słuchajcie, to nie idzie do końca tak. Na początku to jest małe odchylenie z kursu, ale w dłuższej perspektywie to będzie większy problem”. Ja uprawiam strzelectwo dynamiczne. Jak sobie wyobrazicie strzelanie, to gdy strzelasz na bliskie odległości (na przykład do metra) do tarczy, to może praktycznie bez celowania trafisz, natomiast im dalej się oddalasz, to tym większy błąd zrobisz na pistolecie. Na milimetry to już jest dużo, na drobne części milimetra, więc na metrze ten problem nie będzie duży. Na 25 metrach po prostu trafisz w tarczę kolegi. Podobnie będzie w projekcie. Jeżeli na początku będzie mała zmiana i my jej nie zaadresujemy, to ta zmiana sama się nie poprawi, ona będzie wyłącznie rosła. Warto więc by było dodać do tego spotkania, oprócz tej części merytorycznej (i oprócz niej tak będzie miło), to, co jest nam potrzebne, by to się udało. 

Ważna jest też świadomość tego, że warto sobie zarezerwować czas na współpracę i kontakt ze sobą, i jakieś zasady tej współpracy, jak my będziemy odpowiadać, jak szybko i tak dalej, bo klient oczekuje, że odpowiedź będzie z założenia natychmiast, dostawca oczekuje, że przynajmniej go ktoś tam „nie zleje”, a są krytyczne obszary w harmonogramie projektu, gdzie tej współpracy będzie więcej i jest potrzebna częstsza. Są też takie, gdzie są potrzebne mniejsze. Według mnie… Ja mówię „według mnie”, ale to jest na podstawie doświadczenia, obserwacji i prac z setkami klientów, tego po prostu nie robimy, bo to nie jest taki intuicyjny temat. 

Koszt, podatek od współpracy to jest 10% do 30% czasochłonności w projekcie. To jest zarządzanie projektem, współpraca, komunikacja. O tym warto pamiętać. Zresztą jak prowadzicie firmę jako szefowie, to wiecie, że zlecasz coś człowiekowi i zakładasz: „Dobra, mam to z głowy, będzie zrobione” i on wraca z pytaniami. Co więcej, te pytania są dosyć często mało uzasadnione. Warto więc wiedzieć, że jak coś zlecasz, to musisz ileś czasu zarezerwować dla siebie najpierw, żeby wyjaśnić, a później, żeby po prostu kontrolować, czy idziemy we właściwym kierunku. Ja bym więc postawił na pilnowanie tego rytmu i podnoszenie każdej rzeczy, która odbiega od tego, na co się zakontraktowaliśmy, bo inaczej nie wyciągniesz tego. To samo się nie zadzieje, doprowadzi do wybicia szamba.

Powiedziałeś fajną rzecz o tym, że firmy technologiczne często się zasłaniają tym, że są zwinne i żadne inne tłumaczenie nie idzie. Nie ma takiego właśnie opisania, co to właściwie znaczy, że jesteśmy zwinni, jak będzie ten proces wyglądał w praktyce, czego się możecie od nas spodziewać – tylko „jesteśmy zwinni” i kropka. To jest teoretycznie tak zajebiste, że nie wymaga wyjaśnienia, a później wydaje się, że z tego robią się problemy. 

Druga rzecz skojarzyła mi się z tym, o czym mówisz – trochę w kontraście do tego zarządzania zwinnego. Mam wrażenie, że firmy chyba mocno pozapominały o tym, że zwinność to nie jest jedyna metodyka pracy, a są takie bardzo duże i mało praktyczne we wdrożeniach, nawet kilkumiesięcznych, metodyki typu na przykład PMI. Akurat nie jestem wielkim fanem. Uważam, że obszary projektowe typu właśnie integracja, zakres, czas, jakość, koszty, ludzie, tam jeszcze jest chyba komunikacja, dostawy i ryzyko, no to uważam, że fajnie by było, żeby każdy project manager i firma wdrożeniowa przynajmniej miała świadomość, że te obszary są i trzeba nimi się jakkolwiek zaopiekować, żeby ten klient był na koniec dnia zadowolony. Tak naprawdę jest to definicja dobrze zarządzonego projektu, niezależnie od tego (według mnie) czy to jest robione zwinne, czy nie.

Jak ruszamy w zwinność – to nie metodyka, tylko filozofia. Stoi za mną ileś lat rozkminy tego, o czym my w ogóle mówimy. Część tych tematów trudno jest odpakować, ale później się okazuje, że jesteś w stanie to odpakować tak, jak popatrzymy sobie lean, popatrzysz sobie na produkt, wymyślono filozofię lean ograniczania marnotrawstwa. Dlaczego? Bo największym problemem w produkcji było to, że jak ty rozpędzisz to na taką skalę i nie przypilnujesz drobnych kosztów, to wypierdzielisz po prostu całość. Stałe dążenie do tego, żeby usuwać marnotrawstwo, bo proces się zmienia, jest bardzo dobrą filozofią. Ten konkretny sposób działania sprawia, że to jest właściwa filozofia myślenia o tym kawałku – eliminuj marnotrawstwo w produkcji, tym sposobem będziesz w stanie osiągnąć najlepsze rezultaty. Sprawdza się od lat, będzie działało, będzie się sprawdzało zawsze, bo tak działa ten obszar. 

Dlaczego powstał agile? Dlatego, że to sprawdzało w budowlance, czyli praca zgodnie z procesem według konkretnych norm. W budowlance to się sprawdza, bo jeśli przechodzisz do projektu „wybuduj” i tak dalej, tam jest pewne kaskadowe podejście, że są poszczególne fazy, jest dużo zwinności i działania w trakcie, ale pewne normy muszą być przestrzegane, bo na koniec to gwarantuje, że ten budynek stoi i będzie stał. 

Natomiast w IT nie działało takie podejście typowo z budowlanki, bo tam mamy do czynienia bardziej ze środowiskiem albo chaotycznym, albo złożonym, gdzie musisz przetestować, czego klient chce. Dlaczego? Dlatego, że on nie wie, nie jest w stanie wyjaśnić w terminach technicznych, czego oczekuje. Jest w stanie opowiedzieć o swojej rzeczywistości. Przychodzi do kogoś, kto się zajmuje programowaniem, opowiada mu o swojej rzeczywistości, a tam jest: „Ty, musimy to analizować”. Ale rynek tak zapierdziela, że zanim skończy się twoja analiza, to nie mamy o czym rozmawiać. Jest inny cykl życia powstawania produktu. Dlatego powstał agile: „Hej, rozwiążmy te problemy. Słuchajcie, skupcie się na współpracy, a nie dokumentacji, bo współpraca będzie tym, co doprowadzi was w tym konkretnym rozwiązaniu do zbudowania czegoś, co ma sens”. To też jest tak naprawdę wycinek projektów informatycznych (nie wszystkich), to jest wycinek rzeczywistości. 

Filozofia, jak pracujesz z klientem, który działa dynamicznie, rozwija produkt i potrzebuje wsparcia technologii, to zwinne działanie w pierwszym etapie wychwytywania, co jest potrzebne, jest właściwą filozofią myślenia. Tutaj problem polega na tym, że kung-fu danej firmy powinno się składać z większej ilości narzędziownika, niż nawet agile’a. Nawet, jak ktoś ma to opanowane, to to pewnie nie wystarczy, a jak ma tylko opanowane słownictwo… 

Był taki stary dowcip: „Znam karate, kung-fu, kickboxing i kilka innych zagranicznych słów”. Tu nie wystarczy znać słowa, trzeba to przełożyć na działania. Ja zakładam, że na koniec potrzebujesz umieć łączyć sztuki walki w zarządzaniu projektami, żeby móc to dowieźć. Warto to robić świadomie, bo to są znowu klocki. Jak mamy projekt tego typu, to tutaj ten element potrzebujemy zrobić bardziej iteracyjnie, a ten moment już możemy przełożyć na harmonogram. Te mamy w harmonogramie, a ten przeznaczymy na minizadania. 

Na koniec więc wszystkie te szkoły mówią o czymś fajnym i ciekawym. Ja z mojej perspektywy mówię o prostocie. Dla mnie 12 pytań KISS PM, czyli moją metodą, wynikała z tego, że jak sobie popatrzysz na te książki – jedna 1000 stron, druga 1500, jakaś tam kolejna po prostu metoda, która działa – stwierdziłem, że poszukamy czegoś, co będzie proste, żeby ludzie, nie ucząc się tego wszystkiego, byli w stanie działać projektowo, trochę na wyższym poziomie świadomości, ale bez wchodzenia we wszystko tak, żeby się spięło.

Mógłbyś pokrótce opowiedzieć o tej metodzie?

Idea jest taka, że jak ja się uczyłem PMBOK’a  i zrobiłem certyfikat z zarządzania projektami, stwierdziłem: „WOW, jakby wszyscy to poznali, to będzie super i teraz będzie się działo z projektami great fantastic”. No i zacząłem, zrobiłem fajne formatki, w których było opisane tło projektu, cel projektu, interesariusze, ryzyka. Tylko jak dajesz ludziom takie formatki, no to ludzie nagle dostają „dysformuli”. Nie potrafią wypełniać formularzy, bo te słowa nic dla nich nie mówią, typu „interesariusz”, ale o czym my mówimy? 

Natomiast jakby to połączyć trochę inaczej… ja to połączyłem z podejściem coachingowym. Nie wiem, co sobie możecie pomyśleć, ale wziąłem pytania z coachingu. Jak zaczynasz zadawać ludziom normalne pytania normalnym językiem, to jesteś w stanie dostać odpowiedź – lepszą albo gorszą, ale dostaniesz. 12 pytań to jest przejście przez projekt na zasadzie: „Dlaczego my ten projekt robimy? Dlaczego on jest ważny? Po co go realizujemy – czyli jaki jest cel? Dla kogo go robimy? Po czym poznasz, że zakończył się sukcesem? Co zrobimy, kiedy, za ile? Kto tego dopilnuje? Co może pójść nie tak? Co może szczególnie pomóc? Jak będziemy monitorować postępy? Jak będziemy wprowadzać zmiany?”. 

To jest taki model domku, gdzie od dołu zaczynasz składać sobie pytania i na nich układasz kolejne. Jeśli fundament jest dobry, czyli wiesz, dlaczego i po co, to pozostałe klocki dużo łatwiej na to wskakują. Jeżeli masz pogubiony fundament, czyli nie wiesz, dlaczego, po co i zaczynasz już coś robić, to jest szansa, że to się ze sobą nie zepnie. Generalnie model działa tak, że zaczynasz projekt, przechodzisz sobie przez te 12 pytań, i już w miarę szybko się orientujesz, czy ten projekt masz pod kontrolą, czy o tym projekcie niewiele wiesz i trzeba było cokolwiek dopracować. Później możemy pracować sobie dalej właśnie na celu, planie, rytmie, dodając kolejne rzeczy. 

Przez te ileś lat okazało się, że to jest fajny sposób, bo ludzie łapią to dosyć szybko, to nie jest metodyka gdzieś dookoła, tylko to są ludzkie pytania. Zaczynasz się orientować, jak projekt działa albo nie. Oczywiście, jak potrzebujesz sobie jakieś pytania bardziej zgłębić, to do tego są techniki i narzędzia, ale podejście jest takie: zaczynasz od pustej kartki „cel, plan i rytm” – gdzie chcesz dojść, jaki masz na to pomysł, jak tego przypilnujesz? Do tego dodajesz sobie 12 pytań i wiesz, czy potrzebujesz sięgnąć po więcej narzędzi, czy właśnie wszystkie, które ci są potrzebne, masz na jednej kartce. Wszyscy rozumieją, dlaczego ten projekt robimy, jaką mamy w tym role, ta historia zaczyna się lepić. Stosunkowo proste podejście. 12 minut i wiesz, czy projekt masz ogarnięty, czy tak na dobrą sprawę to on jest totalnie rozmyty.

Dotychczas rozmawialiśmy o takiej parze projektowej, to znaczy klient i dostawca, chociaż wybitnie nie lubię takiego określenia, ale na potrzeby rozmowy przyjmijmy, że to jest klient i dostawca, natomiast bardzo często rzeczywistość jest taka, że jedna firma po stronie dostawcy to jest za mało. Bywa tak, że jedna firma robi sklep, a druga w tym czasie dłubie ERP albo już go ma i trzeba sobie zintegrować. Pojawiają się firmy od SEO, marketingowe – to równanie najczęściej ma tych składników więcej niż tylko 2. 

Zastanawiam się, jak to, o czym rozmawialiśmy, przełożyć na kanwę współpracy z więcej niż jednym dostawcą, to znaczy jak zachowuje się w takim układzie odpowiedzialność, jak się przesuwa ta granica, jak powinna być poukładana komunikacja. Jakie są Twoje opinie na ten temat?

Zacznijmy od tego, jak powinno wyglądać modelowo. Jest kolejny członek zespołu projektowego z jakimś zakresem odpowiedzialności i dogranie tych zakresów jest ważne – wewnętrzne i zewnętrzne. Jakie się pojawia ryzyko? Może cynizm mi się odpala, ale przerabiałem kilka różnych sytuacji i jest tak – jak pracujesz z kimś, kto jest nastawiony na współpracę i macie podobne wartości, to większość problemów da się rozwiązać, nieważne, ile tam osób jest w to zaangażowanych. 

Jeśli jednak trafisz na sytuację, w której ktoś z tych graczy zaczyna grać, powiedzmy, mocno egoistyczne, to jest idealna sytuacja, żeby (jeżeli klient nie zna się na temacie) przewalić, że to inny dostawca coś skopał. Klient za cholerę się nie ogarnie, bo gadamy o takim poziomie subtelności, że nie wiadomo, kto coś zrobił nie tak. To jest po prostu mega ryzyko, ale zobaczmy, kto za to odpowiada, jaki jest problem. Zawsze tych filozofii będzie tam multum. To jest więc takie największe ryzyko rozmycia tej całej rzeczywistości – to on, to nie ja. 

Rozwiązanie jest dokładnie takie samo – statusy, checki kontrolne i opieprzanie, jeżeli ktoś nie powie, że jest jakikolwiek problem. Bardzo możliwe, że w tym przypadku trzeba było, oprócz takich statusów globalnych, gdzie po prostu mamy oceny, jak idzie cały projekt, robić synchronizację pomiędzy dostawcami, czy to dobrze działa i funkcjonuje. Za nic bym tego nie zostawił (gdybym był zamawiającym) w gestii, że jeden i drugi dostawca niech się dogadają pomiędzy sobą.

To jest jedno z takich kłamstw naszych czasów trochę, to jest… Rzuciłem taki post o ciężkiej pracy w weekend na LinkedIn i od razu dostałem, że jest taki cytat: „Pracuj mądrze, a nie ciężko. Lekko nie znaczy mądrze, a mądrze nie znaczy lekko”, żeby to uzupełnić. To jest takie podejście naszej kultury na zasadzie: „Dobra, oni to ogarną i będzie się działo”. Ty odpowiadasz za ten projekt, więc ty potrzebujesz narzucić pewien poziom współpracy i ją ustawić tak, żeby właściwie działała. Nawet jeżeli ciebie nie ma na tych spotkaniach, to musisz być pewny, że one się odbywają. Ta synchronizacja następuje i następuje wyłapywanie problemów i trudności pomiędzy jedną a drugą stroną. 

To jest proaktywnie raportowane, bo inaczej zadzieje się dokładnie taki sam mechanizm. On się dzieje nawet w firmach wewnętrznych. Jeden dział sprzedaje, a drugi realizuje. Dział, który sprzedał, przerzuca do działu realizacji i znika, a realizacja: „Co wy żeście tam sprzedali?”. „No sprzedaliśmy, macie robotę, to wy teraz to róbcie, a my sobie wracamy szukać kolejnego klienta”. Jest taka naparzanka non stop, kto za co odpowiada. Modelowym rozwiązaniem jest to, że dział sprzedaży jest dostępny po podpisaniu umowy przez jakiś czas na zasadzie consult, żeby dać informację kolejnemu działowi, temu od realizacji, co zostało ustalone, żeby płynniej wejść w ten proces, żeby to się działo na zakładkę. 

W przypadku pracy pomiędzy dostawcami, jak oni zależą na siebie na poszczególnych elementach, ten element odpowiedzialności trzeba doprecyzować i upewnić się, że się ze sobą komunikują i faktycznie masz dowody na to, że ta komunikacja przepływa. Tu też widziałem sytuację, w której: „A, to spokojnie, się dogadamy. My się dogadamy, wy zrobicie swoje, wiecie, co robimy, tak, tak”. Robi się taki front dostawców vs. klient: „O, my tam wiemy, oni nie do końca wiedzą, co robią”. Na koniec okazuje się, że to się rozjeżdża. 

Będę nudny, z tych nudniejszych. Trzeba trzymać się tego modelu nawet wtedy, gdy on potrafi być wkurzający, i pilnować, żeby komunikacja przepływała. Najważniejsze wyłapujemy, wyłapujemy problemy, i ktoś usiądzie trochę wcześniej, przewidując, co się może zadziać, za co odpowiada dany człowiek, czy jest z tej czy z innej firmy, i pilnowanie tej dynamiki, bo w relacji 1:1 nie masz przepychanki, na co się umówiliśmy w umowie i tak dalej i co możemy przepchnąć. 

W przepychance w takiej opcji, gdzie mamy dwóch poddostawców, to ta stawka też może być większa, bo część robi większy obszar, a część mniejszy. Czasem potrafi się walczyć o tego klienta, kto złapie większy tort w kolejnym kroku… Tutaj to zarządzanie interesariuszami zaczyna być ważniejsze, i ratunkiem zawsze, tak z tego całego mojego gadania – zakres i odpowiedzialność na zakresie jest tym punktem, który może bardzo pomóc.

Mariuszu, zbliżamy się do końca. Chciał, żebyśmy na koniec zostawili naszych słuchaczy z takimi trzema dobrymi radami na okoliczność rozpoczynania projektu wdrożeniowego z nowym dostawcą.

Po pierwsze: cel, plan i rytm. Upewnij się, że wiesz, jaki jest cel, pomysł na to, żeby to zrobić, jak będziesz kontrolować ten projekt. Drugi – ja proponuję 12 pytań, rozpisać sobie ten projekt tak, żeby móc o nim opowiedzieć w prosty sposób. Trzeci – zarezerwuj czas na współpracę. Ten trzeci punkt jest najtrudniejszy, bo w świadomości trzeba złapać, że to będzie kosztowało ileś czasu i samo się nie zadzieje. 

Te trzy punkty mają sporą szansę tego, że to się uda albo… OK, żeby było fair, zarządzanie projektami nie gwarantuje sukcesu. Ono tak naprawdę ogranicza prawdopodobieństwo wywrotki, bo jeżeli zostawimy projekt samemu sobie, to jest szansa, że się wywróci bardzo dużo. Odpalając trochę tych modeli, to prawdopodobieństwo zmniejszasz, a tym samym kasa zostaje u ciebie.

Czy w temacie naszej rozmowy są jakieś dodatkowe materiały? To mogą być książki, wideo, kursy – cokolwiek, co przychodzi ci do głowy. Czy są materiały, które poleciłbyś osobom, które bardziej chcą zgłębić ten temat?

Zaproszę was do siebie na kanał YouTube „Zarządzanie Projektami – Mariusz Kapusta”, ewentualnie też jest forma podcastu dla tych, którzy lubią słuchać. Także na mojego LinkedIn, tam dużo publikujemy. 

Jeżeli chodzi o książki, to też mało skromnie polecę moją: „Zarządzanie projektami krok po kroku”. Jest po prostu dobra. Napisałem ją 13 lat temu, ale okazuje się, że recenzje zbiera bardzo dobre. Mniej więcej codziennie 3 osoby ją kupują od tamtego czasu – nie tę samą, tylko różne, ale działa całkiem nieźle, rynek ją weryfikował z dobrymi recenzjami.

Jeszcze dwie pozycje do przemyślenia – jedna to Peter Senge Piąta dyscyplina. To stara książka o myśleniu systemowym. Warto ją przeczytać. Daje mocno do myślenia, z czym mamy do czynienia, że to nie są proste rzeczy, tylko bardziej złożone. Druga to Factfulness. Autor mi wyleciał z głowy, taka biało-pomarańczowa. Jest na temat tego, jak my postrzegamy rzeczywistość i co nam się wydaje, a co naprawdę jest. Mnie otworzyła oczy w takim myśleniu: „Hej, zaraz, może nie wszystko, czego mnie uczyli, to jednak po prostu podejmuję decyzje na czymś, czego się uczyłem 20 lat temu. To już wtedy nie była prawda, a teraz tym bardziej nie jest i może warto otworzyć sobie głowę na pozyskiwanie nowej wiedzy”. To bym więc zaproponował. A jak traficie do mnie, to materiału jest sporo.

Ja to wszystko podlinkuję. Tak dla ustalenia – autorem Factfulness jest Hans Rosling, zdążyłem to sprawdzić w tak zwanym międzyczasie. 

Mariuszu, dla Ciebie ostatnie pytanie natury inspiracyjnej – gdybyś miał naszych słuchaczy zostawić z taką jedną myślą, apelem, hasłem, czyli taką jedną rzeczą, którą chciałbyś, żeby każdy po przesłuchaniu tego odcinka zapamiętał i zostawił ze sobą na dłużej, to co by to było?

Jeżeli robisz projekty i nie masz z tego funu w trakcie, to na pewno robisz coś nie tak. To jest ten punkt. To nie znaczy, że będzie lekko, bo to może być ciężka praca, ale takie poczucie, że robisz z sensem i robisz wartościową rzecz, powinno towarzyszyć temu, że robisz właściwie projekt. Z tym warto zostać. Jak jest nie tak, to trzeba krzepnąć, żeby się dogrzebać.

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

Dzięki, do usłyszenia, do zobaczenia.