Przejście z umów typu Waterfall na umowy określające czas trwania i cenę (z Tuckerem Sauerem-Pivonką z Crema)

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Prosimy o wyrozumiałość w przypadku literówek, ponieważ bot nie zawsze działa w 100% poprawnie.

Ben Aston:

Witamy w podcaście DPM, w którym wychodzimy poza teorię, aby udzielać praktycznych porad dotyczących lepszego prowadzenia projektów cyfrowych. Dziękuję za dostrojenie się. Nazywam się Ben Aston i jestem założycielem Digital Project Manager. Projekty rzadko przebiegają zgodnie z planem, a gdy plany się zmieniają, często powoduje to ogromny stres. Trzeba podejmować decyzje, organizować spotkania, aktualizować plany, ponownie przeliczać szacunki i zazwyczaj wystawiać wnioski o zmianę. Ale co, gdyby istniał inny sposób zarządzania zmianą w projektach? W tym odcinku przyjrzymy się innemu podejściu do zarządzania zmianą — umowom zwinnym. Słuchaj dalej, aby dowiedzieć się, jak sprawić, by umowy zwinne działały na twoją korzyść, oraz poznać zalety i wyzwania związane z tym podejściem.

Dziś dołącza do mnie Tucker Sauer-Pivonka, dyrektor zarządzania produktem w Crema, gdzie pomaga menedżerom produktu rozwijać się i doskonalić. Odpowiada również za rozwijanie najlepszych praktyk. Cześć, Tucker.

Tucker Sauer-Pivonka:

Cześć, Ben. Miło cię dziś słyszeć.

Ben Aston:

Ciebie również. Na początek chciałem zapytać o jedną rzecz. Wiem, że częścią twojej roli jest rozwój zespołu. Czy możesz podzielić się spostrzeżeniami na temat tego, co naprawdę pomagało twojemu zespołowi rozwijać się i ewoluować? Być może również w kontekście umów, nad którymi pracujecie lub które testujecie. Jak wspierasz zespół i pomagasz mu się rozwijać? Co sprawdza się w twoim przypadku?

Tucker Sauer-Pivonka:

Myślę, że na początku trzeba uświadomić sobie, że każdy uczy się trochę inaczej i każdy potrzebuje nieco innego sposobu coachingu. Jedną z pierwszych rzeczy, które robię z członkami zespołu, jest rozmowa z nimi i próba zrozumienia, jak się uczą, jak chcą otrzymywać informacje zwrotne i jak lubią być chwaleni. Wszystko to zapisuję, aby móc dostosować swoje podejście do sposobu, na który najlepiej reagują. Dużo czasu poświęcam indywidualnym spotkaniom jeden na jeden, omawiając różne tematy i obszary rozwoju. Po prostu pomagam im w kwestiach, z którymi aktualnie mają trudności. Problemy pojawiają się na bieżąco, więc wtedy się nimi zajmujemy. Poza tym w Crema prowadzimy obecnie wspólną naukę na podstawie książki „Multipliers”.

To ważny element rozwoju naszego zespołu. Oczywiście uczestniczymy też w konferencjach. Pod koniec września wybieramy się na konferencję poświęconą zarządzaniu produktem. Pojedziemy tam jako zespół, nie tylko w celach integracyjnych, lecz także po to, aby poznać nowe tematy.

Ben Aston:

Świetnie. Wiesz, jak nazywa się ta konferencja?

Tucker Sauer-Pivonka:

Nazywa się Industry: The Product Conference i odbywa się w Cincinnati, jeśli dobrze pamiętam.

Ben Aston:

Impreza w Cincinnati, jeśli chcesz dołączyć do Tuckera i jego zespołu. Chciałbym jednak wrócić do tego, o czym mówiłeś — że omawiacie z zespołem różne tematy. Czy możesz podzielić się przykładami tematów lub obszarów, w których pomagasz zespołowi? Jakie wyzwania stoją przed zespołem i w pokonywaniu których mu pomagasz?

Tucker Sauer-Pivonka:

Wygląda to nieco inaczej w przypadku każdej osoby, ponieważ członkowie naszego zespołu mają różne poziomy umiejętności. Wiele tematów, które omawiamy grupowo, dotyczy zarządzania klientami. Na przykład: „Mój klient powiedział to albo poprosił nas o zrobienie czegoś, o czym wcześniej nie rozmawialiśmy. Jak powinienem się tym zająć?”.

Zagadnienia związane z zarządzaniem klientami są zazwyczaj najtrudniejsze do nauczenia, dlatego rozmowy często dotyczą sytuacji takich jak: „Czułem się niezręcznie i nie wiem, czy dobrze sobie z tym poradziłem. Czy powinienem następnym razem postąpić inaczej?”. Właśnie w tym kierunku zwykle zmierzają nasze rozmowy.

Ben Aston:

To prawda. W zarządzaniu klientami i zespołem ważne są umiejętności miękkie, prawda? Nie ma jednej właściwej odpowiedzi, bo wszystko zależy od sytuacji. Zawsze możemy jednak rozwijać się i doskonalić w tych obszarach. Wspomniałeś o uczestnictwie w konferencji jako zespół, co jest świetne. Chciałbym dowiedzieć się więcej o tym, skąd czerpiesz inspirację i jak nadążasz za tym, co dzieje się w branży. Jak pozostajesz na bieżąco i co cię inspiruje?

Tucker Sauer-Pivonka:

Inspirację czerpię z wielu różnych źródeł. Jednym z nich są książki, które czytam. Czytam też dużo artykułów. Często korzystam z Medium, szczególnie w poszukiwaniu inspiracji związanych z zarządzaniem produktem i zespołami. Trzeba jednak pamiętać, że Medium jest dobrym źródłem, ale do publikowanych tam treści należy podchodzić z dystansem, ponieważ każdy może zamieścić artykuł. Sam fakt opublikowania czegoś w internecie nie czyni autora ekspertem. Mimo to takie materiały mogą dostarczyć kontekstu potrzebnego do radzenia sobie z określonymi sytuacjami.

Korzystam z tego dość często, a poza tym czytam magazyn Wired. Zwykle czytam większość artykułów w każdym numerze. Pomaga mi to śledzić trendy wykraczające poza świat zarządzania projektami — przede wszystkim to, co dzieje się ogólnie w technologii.

Ben Aston:

Świetnie. A jeśli chodzi o technologię — czy należysz do osób, które zawsze korzystają z najnowszych rozwiązań? Jaki jest najnowszy gadżet, który kupiłeś?

Tucker Sauer-Pivonka:

To dobre pytanie. Żałuję, że nie mam żadnej szczególnie ekscytującej odpowiedzi. Nie powiedziałbym, że jestem na absolutnym froncie technologii. Uważam się raczej za osobę wcześnie wdrażającą nowe rozwiązania, ale nie jestem wśród pierwszych użytkowników. Zwykle staram się kupować nowe produkty, gdy się pojawiają, jeśli mogę sobie na to pozwolić. Obecnie bardzo chcę kupić nowego iPada. Mam iPada Pro, który działa dobrze, ale chciałbym mieć nową wersję i nie potrafię tego uzasadnić. To właśnie jest świetne w produktach Apple — nadal działają dobrze, więc nie ma rzeczywistej potrzeby ich wymiany.

Ostatnio interesowała mnie najnowsza wersja systemów iOS i iPadOS oraz wszystko, co zaprezentowano podczas WWDC. Dużo myślałem o wpływie tych rozwiązań na całą branżę, a nawet na niektóre produkty, które tworzę. Jestem też trochę fanem serii Zelda, a zapowiedziano właśnie sequel „Breath of the Wild”, więc tym również się ekscytuję.

Ben Aston:

Świetnie. Ja obecnie interesuję się DGI Roverem. Nie wiem, czy nazywa się to Roverem, ale to mała kamera na niewielkim czołgu, który samodzielnie budujesz. Wygląda świetnie i znajduje się na mojej liście zakupów.

Tucker Sauer-Pivonka:

Brzmi świetnie.

Ben Aston:

To znowu jedna z tych rzeczy, przy których człowiek pyta: „Czy naprawdę tego potrzebuję?”. Oczywiście nie potrzebuję, ale dzieci będą się dobrze bawić. Skoro wspomniałeś, że lubisz iPada Pro, zapytam jeszcze: czy znalazłeś ostatnio jakiś sprzęt albo oprogramowanie, które ułatwia ci życie i o którym każdy powinien wiedzieć?

Tucker Sauer-Pivonka:

Od lat próbuję znaleźć równowagę między robieniem odręcznych notatek, pisaniem na klawiaturze i śledzeniem zadań. Istnieje wiele informacji wskazujących, że zapisując coś ręcznie, przyswajamy to inaczej niż podczas pisania na klawiaturze, co bardzo mnie interesuje. Przez jakiś czas robiłem notatki na iPadzie za pomocą Apple Pencil. To działało całkiem dobrze, ale ostatnio przeszedłem na rozwiązanie pośrednie.

Noszę ze sobą mały notes, w którym zapisuję codzienne notatki i zadania. Pod koniec dnia przenoszę te informacje do aplikacji Todoist, aby śledzić wszystkie zadania. Następnie porządkuję również notatki w aplikacji. Dopiero zaczynam stosować ten system, ale to największa ostatnia zmiana w moim sposobie pracy i bardzo mi pomaga. Lepiej rozumiem, nad czym pracuję, i skuteczniej śledzę zadania, zamiast od razu przystępować do ich realizacji. Pomaga mi to również w zarządzaniu czasem.

Ben Aston:

Ciekawe. Czyli używasz papierowego notesu do robienia notatek, przypomnień i podobnych rzeczy. Wróciłeś w tym zakresie do rozwiązania analogowego?

Tucker Sauer-Pivonka:

Tak, ale ostatecznie informacje trafiają do przestrzeni cyfrowej. Nic nie zastąpi otwarcia notesu, kliknięcia długopisem i rozpoczęcia pisania. Korzystanie z iPada i Apple Pencil wymaga otwarcia właściwej aplikacji, znalezienia odpowiedniego notesu i upewnienia się, że rysik jest naładowany. To drobne rzeczy, ale tworzą bariery utrudniające szybkie zapisanie notatki.

Zauważyłem, że nosiłem iPada oraz mnóstwo karteczek samoprzylepnych. Gdy musiałem coś szybko zapisać, korzystałem z karteczki. Pomyślałem, że to nie jest rozwiązanie na dłuższą metę i że noszenie tylu karteczek jest trochę absurdalne. Dlatego zdecydowałem się na notes.

Ben Aston:

To problem, z którym również się zmagam. Obecnie korzystam z Evernote. Mam jeden notes z listą zadań i drugi, który nazywam brudnopisem. Trafiają do niego wszystkie surowe informacje, a później przenoszę je do listy zadań. Brzmi to podobnie do twojego systemu. Mam też mały notatnik, który celowo jest tak niewielki, że można w nim zapisywać tylko przypomnienia, a nie dłuższe notatki. Dzięki temu zmuszam się do korzystania z systemu i nie tworzę wielu list w różnych miejscach.

Porozmawiajmy jednak o artykule i przygotowanym przez ciebie studium przypadku. Dotyczy ono przejścia z umów typu Waterfall na umowy określające czas trwania i cenę. Rozmawialiśmy już wcześniej o umowach zwinnych, a w szkole DPM ktoś zapytał w tym tygodniu o przykład takiej umowy. Wysłałem mu link do świetnego artykułu Alexy o umowach zwinnych. Dla osób, które nie znają tego rodzaju umów, wyjaśnij proszę krótko, czym jest umowa określająca czas trwania i cenę oraz jak działa.

Tucker Sauer-Pivonka:

Wyjaśnię to na przykładzie sposobu, w jaki robimy to w Crema. Nie oznacza to, że każda umowa musi wyglądać dokładnie tak samo, ale jest to model, który znam najlepiej. Umowa określająca czas trwania i cenę koncentruje projekt wokół dedykowanego zespołu. Może to być dwóch programistów pracujących w pełnym wymiarze, inżynier testów pracujący na pół etatu, projektant pracujący na ćwierć lub pół etatu, menedżer produktu oraz strateg pracujący w niepełnym wymiarze.

Umowa skupia się na zespole i celach, do których dążymy, zamiast wyszczególniać dokładne rezultaty, funkcje i odpowiadające im szacunkowe liczby godzin. Oprogramowanie jest zbyt złożone, aby dokładnie oszacować wszystko z wyprzedzeniem i założyć, że cały projekt przebiegnie zgodnie z planem. Takie założenie niemal nigdy nie jest prawdziwe.

Umowy tego rodzaju pozwalają nam i klientom przesuwać uwagę na pracę o najwyższym priorytecie. Dzięki temu pod koniec ustalonego okresu, a także podczas kolejnych cykli iteracyjnych, dostarczamy wartość, która jest w danym momencie najważniejsza dla firmy. W umowie o stałym zakresie priorytety mogą się zmienić w trakcie realizacji. Jeśli kontrakt trwa sześć miesięcy, na jego końcu można dostarczyć funkcje, które nie są już istotne dla firmy. Ten model pozwala nam reagować na potrzeby klienta.

Ben Aston:

Wspomniałeś o projektach, w przypadku których umowy zwinne mają sens, szczególnie o tworzeniu oprogramowania i produktów. Czy spotkałeś się z typami projektów, w których próba zastosowania umowy określającej czas trwania i cenę nie sprawdziła się tak dobrze?

Tucker Sauer-Pivonka:

Trzeba ocenić rodzaj wykonywanej pracy. Ten model sprawdza się u nas, ponieważ tworzymy produkty, których nie da się szczegółowo opisać od samego początku, a realizacja wiąże się z ryzykiem. Jeśli praca jest powtarzalna — na przykład tworzenie standardowych stron internetowych o określonej liczbie podstron i układzie — można zastosować model o stałym zakresie, ponieważ proces jest przewidywalny. Ostatecznie chodzi o różnicę między przewidywalnością a nieprzewidywalnością pracy.

Ben Aston:

Pojawia się również temat wyceny opartej na wartości. To inne podejście niż umowy oparte na czasie trwania i cenie. W przypadku wyceny opartej na wartości można powiedzieć klientowi: „Wartość tej pracy dla firmy wynosi 50 tysięcy”, a następnie pobrać 50 tysięcy, mając nadzieję, że realizacja będzie kosztować mniej. Sprzedaje się wtedy wartość, a nie godziny. Jak taki model współgra z prostymi i przejrzystymi umowami, w których klient płaci za określoną alokację zespołu? Jak wpływa to na rentowność?

Tucker Sauer-Pivonka:

To dwie różne rzeczy. Gdy tworzymy oprogramowanie w modelu określającym czas trwania i cenę, nie zawsze wiemy, jaki będzie ostateczny rezultat. Skoro nie można go przewidzieć, trudno ustalić cenę na początku. Wycena oparta na wartości działa dobrze w sytuacjach, w których można powiedzieć: „Dostarczymy rozwiązanie, które zapewni twojej firmie określoną wartość”. Może to być sprint projektowy. Trudniej zastosować to przy tworzeniu dużego produktu.

Jedną z zalet modelu określającego czas trwania i cenę jest to, że rentowność jest wbudowana w sposób jego działania. Klient kupuje określoną alokację zespołu, a ta alokacja jest tym, co otrzymuje. Nie rozliczamy projektu godzinowo, więc nie ma klasycznego przekroczenia liczby godzin. Dostarczamy wartość w kolejnych sprintach, a klient nie płaci za każdą godzinę osobno.

Ben Aston:

Czyli klient kupuje zespół na określony czas. Czy zdarzyło się, że po kilku sprintach klient powiedział: „Pracujecie nad tym od trzech sprintów, ale nie widzę odpowiedniej wartości”? Jak radzicie sobie w takiej sytuacji?

Tucker Sauer-Pivonka:

Nie zdarza się to często, ponieważ bardzo starannie dbamy o zgodność oczekiwań z klientem — nie tylko podczas rozpoczęcia sprintu, lecz także w jego trakcie. Informujemy klienta o wszystkich zmianach. Najlepszym sposobem zarządzania taką sytuacją jest dobra komunikacja i zarządzanie klientem.

Mówimy otwarcie: „Zakładaliśmy, że zajmie nam to dwa sprinty, ale wygląda na to, że zajmie trzy lub cztery, ponieważ odkryliśmy nowe informacje. Oto, czego się dowiedzieliśmy i dlaczego potrzebujemy więcej czasu. Możemy też przerwać tę pracę i przejść do czegoś innego, jeśli wolisz”. Przedstawienie klientowi wszystkich faktów pomaga podejmować decyzje bez nadmiernych emocji.

Przed każdym sprintem uzgadniamy z klientem jego zakres i upewniamy się, że zespół czuje się komfortowo z planowanymi zadaniami. Na koniec prezentujemy wykonane elementy. Jeśli coś zostało przeniesione do kolejnego sprintu albo pojawiły się nowe informacje, omawiamy przyczyny i upewniamy się, że klient rozumie sytuację.

Ben Aston:

W studium przypadku wspomniałeś, że wiedzieliście, iż prace potrwają co najmniej siedem miesięcy. Jak doszliście do tego szacunku, skoro nie byliście pewni, co dokładnie budujecie?

Tucker Sauer-Pivonka:

W tym przypadku, podobnie jak w większości naszych projektów, oszacowanie powstało po wykonaniu prototypu lub przeprowadzeniu testów. Było to sześciotygodniowe zaangażowanie obejmujące również audyt techniczny istniejącego systemu. Takie działania pomogły nam określić ramy czasowe potrzebne do osiągnięcia celów klienta.

Szacowanie częściowo wynika z doświadczenia. Im więcej projektów realizujesz, tym lepiej rozumiesz, ile czasu zajmują określone zadania i jaka jest ich złożoność. Ważny jest również udział zespołu produkcyjnego. Po zakończeniu prototypowania i testów analizujemy cele oraz poszczególne elementy produktu, nadając im przybliżone rozmiary, a następnie rekomendujemy wielkość zespołu.

Czas trwania nie wynika z listy rezultatów, lecz z celów biznesowych. Wiedzieliśmy, że pracy wystarczy na siedem miesięcy i że w tym okresie zespół pozostanie skoncentrowany na dostarczaniu wartości. Znaczenie miały także budżet i gotowość klienta do finansowania prac, ponieważ oprogramowanie nigdy nie jest naprawdę skończone.

Ben Aston:

Zakładam, że ocenialiście również, czy klient może sobie pozwolić tylko na siedem miesięcy, czy ma budżet pozwalający kontynuować prace dłużej.

Tucker Sauer-Pivonka:

Jeśli klient chciałby podpisać umowę tylko na trzy miesiące, to również jest w porządku. W tym czasie skupilibyśmy się na pracy o najwyższym priorytecie. Można myśleć o tym jak o wynajęciu zespołu. Klient otrzymuje wszystko, co zespół jest w stanie wyprodukować w ciągu trzech miesięcy, sześciu miesięcy, roku czy dwóch lat.

Ben Aston:

Wspomniałeś, że pierwszym etapem było prototypowanie i walidacja. Czy ten etap miał stałą cenę? Jak dobrze określone były rezultaty po sześciu tygodniach?

Tucker Sauer-Pivonka:

Technicznie nadal był to model określający czas trwania i cenę, ale był bardziej zbliżony do stałej ceny niż nasza standardowa umowa. W takim zaangażowaniu określamy pewne rezultaty: prototyp o wysokiej wierności, pliki projektowe, wywiady z użytkownikami, notatki i powiązane badania.

Jeśli jednak po trzech tygodniach okaże się, że użytkownicy nie chcą rozwiązania, nad którym pracujemy, możemy wrócić do punktu wyjścia. Nie chodzi o dostarczenie dokładnie określonej liczby ekranów, lecz o pracę w ramach ustalonego czasu i budżetu.

Ben Aston:

To dobre rozwiązanie, ponieważ problemy często pojawiają się już na etapie prototypowania. Klient może uznać, że prototyp nie jest odpowiedni, jeszcze zanim zostanie przetestowany z użytkownikami. Jeśli model opiera się na czasie trwania i cenie, można odpowiednio zareagować.

Po sześciu tygodniach macie prototyp, przeprowadzacie testy użytkowników i szacujecie siedem miesięcy pracy. Czy wyliczaliście kwotę od dołu czy od góry? Czy pytaliście klienta, jaki ma budżet?

Tucker Sauer-Pivonka:

Przygotowaliśmy przybliżone rozmiary elementów, oceniliśmy ich złożoność i opracowaliśmy wstępny plan techniczny. Na tej podstawie stworzyliśmy plan działania. Wyraźnie zaznaczyliśmy, że może on zmieniać się w czasie, ale pomógł nam dojść do pierwotnych siedmiu miesięcy.

Nie znaliśmy jeszcze apetytu klienta na taką skalę prac, gdy przedstawialiśmy propozycję. Omówiliśmy dotychczasowe działania, kolejne kroki i potencjalny plan rozwoju produktu. Obecność zespołu technicznego, menedżera produktu i stratega pomogła określić, ile czasu zajmą poszczególne części aplikacji.

Ben Aston:

Przejdźmy do metodyki. Opisałeś to podejście jako zwinne, z elementami Scruma. Co przejęliście z podręcznikowego Scruma, a co odrzuciliście? Wspomniałeś o strategu produktu, ale nie o mistrzu Scruma ani właścicielu produktu.

Tucker Sauer-Pivonka:

Często mówimy, że stawiamy ludzi ponad procesem. Praktykujemy Scruma pisanego małą literą „s”, czyli pozostawiamy w procesie wystarczająco dużo elastyczności, aby nie ograniczał ludzi. Jeśli zespół musi dostosować proces do współpracy z klientem, ma pełną autonomię, by to zrobić.

W strukturze agencji trudniej jest mieć osobne, dedykowane role. Właścicielem produktu jest zazwyczaj osoba po stronie klienta, która kontaktuje się z nami na co dzień. Jeśli w projekcie uczestniczy strateg, może działać jako współwłaściciel produktu i pomagać klientowi w podejmowaniu decyzji dotyczących ogólnej strategii oraz kierunku produktu.

Czasami część obowiązków właściciela produktu przejmuje nasz menedżer produktu, zwłaszcza gdy osoba po stronie klienta nie może być z nami w codziennym kontakcie. Menedżer produktu łączy również funkcję menedżera produktu i mistrza Scruma. To odbiega od podręcznikowego modelu, ale u nas działa. Prowadzimy ceremonie, automatyzujemy większość codziennych spotkań, usuwamy blokady i wykorzystujemy kontekst do podejmowania decyzji produktowych.

Pozostałe elementy są podobne: planowanie sprintów, szacowanie, retrospektywy i prezentacje produktu. Zwykle łączymy je w jedno środowe spotkanie zwane spotkaniem rozpoczynającym.

Ben Aston:

Wspomniałeś, że czasem właścicielem produktu jest klient, a czasem menedżer produktu z waszego zespołu. Chciałbym porozmawiać o zarządzaniu zmianą. W studium przypadku pojawiły się sprzeczne priorytety: klient chciał budować nową rzecz, ale stary system, który trzeba było utrzymywać, coraz bardziej się psuł. Jak zarządzaliście tym konfliktem i pomagaliście klientowi ustalać priorytety w rejestrze zadań?

Tucker Sauer-Pivonka:

Najpierw trzeba zrozumieć, co powoduje zmianę priorytetów. W środowisku agencyjnym należy wykazać się empatią. Klient zazwyczaj nie chce zmieniać priorytetów — chce, abyśmy skupili się na pierwotnym planie. Jeśli jednak prosi o zmianę, prawdopodobnie naprawdę jej potrzebuje.

Trzeba ustalić, czy zmiana rzeczywiście ma wysoki priorytet, czy jest tylko reakcją na presję interesariusza. Każda z tych odpowiedzi może być uzasadniona, ale zrozumienie przyczyny pomaga dobrać sposób komunikacji.

Następnie należy bardzo jasno wyjaśnić, że zmiana priorytetów zmienia cały plan. Jeśli zespół przenosi się z jednej dużej funkcji do nowego pilnego zadania, poprzednia praca nie zostanie ukończona w pierwotnie zakładanym terminie. To nie musi być problem, ale klient musi rozumieć konsekwencje swojej decyzji.

Pomagają również wizualizacje w narzędziach, takich jak Jira. Czasami coś, co zostało wyjaśnione słowami, staje się znacznie bardziej zrozumiałe po przedstawieniu tego w formie wizualnej.

Ben Aston:

Czy klienci mają dostęp do Jiry?

Tucker Sauer-Pivonka:

Tak. Zapewniamy klientom pełną przejrzystość. Mają dostęp do używanych przez nas narzędzi i są gośćmi w naszym zespole Slack. Korzystają również z Jiry, aby pomagać w ustalaniu priorytetów, weryfikować wymagania i upewniać się, że zmierzamy we właściwym kierunku.

Ben Aston:

Wspomniałeś o budowaniu zaufania i przejrzystości. Mówisz również o aktualizowaniu planu działania i wykresu spalania. Jak zapobiegacie przeciążeniu klienta informacjami, zwłaszcza gdy nie jest techniczny i otrzymuje dostęp do Jiry oraz wszystkich szczegółów projektu?

Tucker Sauer-Pivonka:

Jednym ze sposobów budowania zaufania jest otwarte przyznawanie się do błędów. Jeśli klient widzi, że przyznajemy się do pomyłki i wyjaśniamy, jak ją naprawimy, szybko zaczyna nam ufać.

Nie wymagamy, aby klienci korzystali z narzędzi — udostępniamy je, jeśli chcą. Przygotowujemy spersonalizowane nagrania ekranu pokazujące, jak korzystać z danego narzędzia, gdzie znaleźć potrzebne informacje i które obszary można pominąć. Jeśli klient czuje się przytłoczony, powinien nam o tym powiedzieć, abyśmy mogli szybko zareagować.

Staramy się dostarczać materiały iteracyjnie i stopniowo, aby klient nie otrzymał wszystkiego jednocześnie. Nie zawsze jest to możliwe, ponieważ praca czasami się kumuluje, ale otwarta komunikacja bardzo pomaga.

Ben Aston:

Jak wygląda raportowanie? Klient płaci za zespół na określony czas. Czy raportujecie czas pracy i prowadzicie karty czasu, czy po prostu mówicie: „Kupujesz zespół i ufasz nam, że pracowaliśmy nad projektem”?

Tucker Sauer-Pivonka:

Raportujemy przede wszystkim rezultaty. W każdym sprincie analizujemy ukończone zadania, zadania nieukończone i prędkość zespołu. Omawiamy również przyczyny zmian.

Nie raportujemy godzin, ponieważ klient nie płaci za konkretną liczbę godzin potrzebnych do wykonania funkcji. Raportowanie pomaga nam jednak kontrolować alokacje. Jeśli ktoś pracuje nad projektem na pół etatu, sprawdzamy, czy rzeczywiście poświęca mu około połowy czasu. Jeśli nie, możemy zmienić zakres odpowiedzialności albo alokację.

Nie raportujemy każdej tygodniowej różnicy, lecz pilnujemy, aby alokacje były prawidłowe. Klient otrzymuje informacje o wykonanej i niewykonanej pracy, a nie szczegółowe rozliczenie godzinowe.

Ben Aston:

Na koniec: kiedy umowy określające czas trwania i cenę nie działają? Czy kiedykolwiek projekt całkowicie się rozpadł? Co powinny obserwować osoby, które rozważają takie podejście?

Tucker Sauer-Pivonka:

Problemy mogą się pojawić, zwłaszcza gdy klient jest rozczarowany postępem. Gdy zaczynasz wyczuwać napięcie, nie ignoruj go. Powiedz wprost: „Mam wrażenie, że nie jesteśmy w pełni zgodni. Czy możemy o tym porozmawiać?”. Trzeba szybko ustalić, co powoduje frustrację. Jeśli zaczekasz do końca, klient może nie przedłużyć umowy i nie będzie już okazji do odbudowania zaufania.

W jednej sytuacji klient był rozczarowany postępem przed odnowieniem umowy. Porozmawialiśmy o tym i odkryliśmy, że zmiana priorytetów skierowała nas na dwa miesiące do innego zadania. Było ono ważne dla działalności klienta, ale odsunęło pierwotny cel. Gdy wyjaśniliśmy tę zależność, klient zrozumiał sytuację.

Najczęstszym problemem jest brak zgodności oczekiwań. Jeśli klient nie chce się z nami dostosować, być może nie jesteśmy dla siebie najlepszymi partnerami. Dlatego staramy się rozpoznać takie kwestie już na etapie sprzedaży.

Ben Aston:

Najważniejsza lekcja z tej rozmowy jest taka, że do powodzenia tego modelu potrzebny jest odpowiedni klient. Musi rozumieć, że praca wymaga czasu, a zmiana priorytetów wpływa na harmonogram i koszt. Edukowanie klienta podczas procesu sprzedaży, prototypowania i walidacji jest niezwykle ważne. Rezultatem powinno być stałe dostarczanie wartości zgodnie z priorytetami klienta, zamiast podejmowania przez agencję skrótów lub decyzji tylko po to, aby zmieścić się w budżecie i terminie.

Umowy określające czas trwania i cenę to bardzo interesująca koncepcja. Tucker, dziękuję za udział w dzisiejszym odcinku.

Tucker Sauer-Pivonka:

Dziękuję za zaproszenie. To była świetna rozmowa.

Ben Aston:

A co wy o tym sądzicie? Czy próbowaliście umowy zwinnej? Chętnie dowiem się, jak wam poszło. Podzielcie się opinią w komentarzu pod tym wpisem i odwiedźcie stronę TheDigitalProjectManager.com, aby dołączyć do naszego zespołu Slack. Znajdziecie tam wiele interesujących rozmów o realizacji projektów. Mamy również kanał poświęcony metodykom zwinnym.

Jeśli podobał wam się dzisiejszy odcinek, zasubskrybujcie podcast i poświęćcie kilka minut na pozostawienie szczerej opinii o podcaście DPM w Apple Podcasts. Oceny i recenzje bardzo nam pomagają i ogromnie je doceniamy. Do usłyszenia następnym razem.