Mierzenie zajętości a mierzenie rezultatów

 

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.

Galen Low: Szybki quiz: jesteś w połowie realizacji projektu, a wszystkie wskaźniki wyglądają świetnie. Dostawca przepracował uzgodnioną liczbę godzin, a prędkość i wykorzystanie zespołu są dokładnie takie, jak zaplanowaliście.

Mimo że projekt jest formalnie w dobrej kondycji, produkt nadal nie sprawdza się w grupach fokusowych i testach użytkowników. Technologia, przy której upierał się sponsor wykonawczy, szybko się starzeje, przez co wprowadzanie zmian staje się trudne. Morale zespołu jest niskie: kiedy prosisz o rozwiązania, wzruszają ramionami i mówią, że zrobili to, o co ich proszono, w wyznaczonym czasie.

Jak więc projekt może być zdrowy, nawet jeśli jego rezultat nie przynosi zamierzonej wartości?

Jeśli zauważasz, że wskaźniki projektu mierzą raczej zajętość niż wartość, słuchaj dalej. Omówimy praktyczne sposoby mierzenia wartości przez zespoły projektowe oraz pomysły na przeniesienie punktu ciężkości z przepracowanych godzin na stworzoną wartość.

Cześć wszystkim, dziękuję za włączenie podcastu. Nazywam się Galen Low i jestem związany z The Digital Project Manager. Jesteśmy społecznością specjalistów cyfrowych, której celem jest pomaganie sobie nawzajem w zdobywaniu umiejętności, pewności siebie i kontaktów, aby zwiększać znaczenie zarządzania projektami w cyfrowym świecie. Jeśli chcecie dowiedzieć się więcej, zajrzyjcie na thedigitalprojectmanager.com.

Dzisiaj rozmawiamy o różnicy między mierzeniem kondycji i postępu projektu a mierzeniem jego sukcesu. Czy wystarczy śledzić prędkość zespołu i wyniki kosztowe? Czy też jako liderzy projektów powinniśmy mierzyć również rezultaty i wpływ projektu?

Moim gościem jest Fred Fowler — certyfikowany mistrz Scrum poziomu 3, autor kilku książek o metodyce Scrum, organizator spotkań grupy Silicon Valley Professional Scrum liczącej około 2000 członków, lider podobnej społeczności Scrum w Szanghaju oraz organizator pierwszej konferencji Silicon Valley Scrummit. Innymi słowy, ktoś, kto zna się na Scrumie.

Witaj, Fred!

Fred Fowler: Cześć! Dziękuję za zaproszenie do programu.

Galen Low: Miło cię gościć.

Fred Fowler: Przedstawiam się jako facet od Scruma. Chociaż niektórzy mówią, że jestem „scrumicious”.

Galen Low: To i tak lepsze niż gdybym powiedział, że Fred jest „scrumem z samej ziemi”.

Fred Fowler: Z określeniem Scrum można robić różne rzeczy. Można mówić „scrumbag” i tak dalej. W każdym razie, proszę, kontynuuj.

Galen Low: Rzeczywiście. Masz bardzo interesujące doświadczenie i myślę, że da ono naszym słuchaczom dużo kontekstu do zrozumienia twojego podejścia do wskaźników projektowych. Jeśli dobrze rozumiem, zaczynałeś jako programista komputerowy, potem zająłeś się polityką, zostałeś burmistrzem, a następnie dyrektorem ds. informatyki, zanim zacząłeś wykorzystywać rzadki certyfikat mistrza Scrum poziomu 3 do pomagania innym.

Czy możesz opowiedzieć nam trochę o swojej drodze i o tym, jak te doświadczenia wpłynęły na twoje dzisiejsze spojrzenie?

Fred Fowler: Powiedziałbym, że moja kariera przypominała pobyt wewnątrz automatu do pinballa.

Zacząłem jako programista w 1980 roku. Pracowałem wtedy na maszynie tak dużej i ciężkiej, że do jej przeniesienia potrzebny był specjalistyczny sprzęt, a mimo to była mniej wydajna niż przeciętny dzisiejszy telefon, czyli smartfon. Prowadziliśmy za jej pomocą dział firmy półprzewodnikowej i właśnie tam zdobyłem umiejętności.

Później, ponieważ była to Dolina Krzemowa w początkach jej rozwoju, panowała tam ogromna zmienność. W ciągu pierwszych ośmiu lat kariery pracowałem w pięciu różnych firmach. W końcu pomyślałem, że potrzebuję stabilności, więc powinienem pracować na własny rachunek.

Zostałem konsultantem i przez następne dziesięć lat pracowałem dla 60 różnych firm. Wciąż robiłem to samo: próbowałem stosować technologię do rozwiązywania problemów biznesowych, bo właśnie o to w tym wszystkim chodzi. Potem jedna z firm, dla których konsultowałem, złożyła mi ofertę nie do odrzucenia.

Ostatecznie kierowałem jej działem IT i zostałem dyrektorem ds. informatyki. Wprowadziłem wiele technik, które w praktyce okazały się technikami Scrum, choć wtedy jeszcze o tym nie wiedziałem. Upoważnialiśmy ludzi do rozwiązywania problemów i uzasadnialiśmy pracę na podstawie zwrotu z inwestycji.

W tamtym czasie realizowałem wiele projektów, które ukształtowały moje spojrzenie na organizowanie przedsięwzięć. Z wielu jestem dumny. Firma ciężko pracowała nad stworzeniem strony internetowej przy użyciu rozwiązań dużej, znanej wszystkim firmy komputerowej.

Zapłaciła tej firmie ćwierć miliona dolarów za dość słabe rozwiązanie handlu elektronicznego. Zaangażowałem się i zobaczyłem ogromną możliwość poprawy. Zorganizowałem projekt i długie ciągi prac Scrum.

Wykorzystywaliśmy dwie różne technologie. Zapleczem był starszy minikomputer IBM AS/400, ale potrzebowaliśmy warstwy frontowej. Pojechałem więc do Chin i znalazłem małą, ambitną firmę, która mogła ją stworzyć. Zorganizowaliśmy pracę tak, że zespół amerykański zajmował się zapleczem, a chiński interfejsem. Musieliśmy tylko sprawić, aby obie platformy mogły się ze sobą komunikować.

Okazało się to całkiem proste. Zastąpiliśmy pracę wartą ćwierć miliona dolarów stroną internetową, która w ciągu sześciu miesięcy generowała 40% przychodów firmy, a jej stworzenie kosztowało 14 000 dolarów. To było proste: wystarczyło dać ludziom rozumiejącym technologię problem do rozwiązania i pozwolić im go rozwiązać.

Możesz mieć zespoły w różnych częściach świata. To nie problem. Trzeba tylko zarządzać sposobem ich współpracy.

Galen Low: Szczupłe zespoły, kontrakt dotyczący danych i można działać.

Fred Fowler: Zgadza się. Kluczowe było zrozumienie, co należy mierzyć.

Kiedy mówisz o zespołach zewnętrznych i pracy zdalnej, wszyscy wpadają w panikę: „Skąd mamy wiedzieć, co oni robią?”. Chcemy więc mieć narzędzia mierzące, jak ciężko pracują i jak bardzo są zajęci, bo chcemy, żeby cały czas byli zajęci.

Tylko że to nie ma znaczenia. Nie jest ważne, czy ludzie pracujący zdalnie są zajęci. Ważne jest to, co faktycznie dostarczają, czyli wartość dostarczonego rezultatu. To należy mierzyć. Zapomnijcie o trzymaniu ludzi na stoperze.

Wyobraź sobie zespół ponad 200 osób pracujący przez dwa lata po 8–10 godzin dziennie oraz zespół pięciu, sześciu albo dziesięciu osób pracujący przez rok w normalnych godzinach. Który dostarczyłby większą wartość? Okazało się, że 200 osób pracujących przez dwa lata stworzyło healthcare.gov, stronę internetową, która stała się całkowitą katastrofą.

Miała wdrażać reformę opieki zdrowotnej Obamy, ale zawieszała się i poniosła porażkę, ponieważ tych 200 osób oceniano na podstawie tego, jak bardzo były zajęte. Dziesięć osób w kolejnym roku całkowicie przepisało system i sprawiło, że zaczął działać. Dostarczyły znacznie większą wartość niż tamte 200 osób.

Galen Low: Właśnie do tego chciałem przejść. Wspomniałeś jedną z przyczyn, dla których mierzymy zajętość. W moim świecie, czyli w agencjach i firmach konsultingowych, chodzi o godziny rozliczane z klientem, wykorzystanie zespołu, liczbę naprawionych błędów i ukończonych zadań.

Dlaczego mamy tendencję do mierzenia zajętości?

Fred Fowler: To proste: ponieważ łatwo ją zmierzyć. Do zmierzenia zajętości wystarczy zegar. Do sprawdzenia, czy ludzie dotrzymują terminów, wystarczy kalendarz. Łatwo to mierzyć, a ponadto stanowi podstawę wynagrodzenia.

Wspomniałeś o godzinach rozliczanych z klientem. To wielki błąd. Idea, że cenna jest ilość czasu ludzi, jest fałszywa. Ich czas jest cenny dla nich, ale dla ciebie cenna jest praca wykonana w tym czasie. Światu przydałaby się dobra miara rezultatów ludzkiej pracy.

Kiedy rozmawiam z firmami, mówię im, że przede wszystkim muszą ustalić wartość, którą chcą stworzyć, i podzielić ją na sensowne, mierzalne części. Następnie powinny mierzyć postęp na podstawie stworzonej wartości. W podejściu szczupłym istnieje pojęcie minimalnego produktu nadającego się do wdrożenia.

Tworzysz tyle produktu, ile potrzeba, aby przekazać coś klientowi. To dobry pomysł, ponieważ rzecz znajdująca się w rękach klienta ma wartość, a klient może powiedzieć, jak dużą. Możesz wtedy ocenić, czy stworzona wartość była warta poniesionego kosztu.

Jeśli aplikacja kosztowała pół miliona dolarów, czy była dobrą inwestycją? To zależy. Jeżeli trafiła do iTunes i pobrano ją trzy miliony razy po dwa dolary, zarobiłeś sześć milionów na inwestycji wynoszącej pół miliona. To świetny interes.

Jeśli ta sama aplikacja została pobrana 25 000 razy po dwa dolary, stworzyłeś 50 000 dolarów wartości za 500 000 dolarów. Ten sam wysiłek i liczba godzin, ale inna wartość rezultatu. To właśnie wartość rezultatu jest najważniejsza.

Galen Low: Dotknąłeś ważnej kwestii dotyczącej minimalnego produktu nadającego się do wdrożenia. Mierzymy zajętość, bo czasem chodzi o zaufanie. Nie ufamy, że ludzie coś robią, ale jeśli możemy mierzyć ich czas pracy, przynajmniej wiemy, że przepracowali te godziny.

Nie mierzy to jednak wartości. Ludzie mówią: „Oczywiście potrzebujemy godzin rozliczanych z klientem, tak działa umowa i wynagrodzenie”. Podoba mi się w twoim podejściu do minimalnego produktu to, że mówisz: wypuśćmy coś na rynek. Będzie to wymagało inwestycji, a klient zdecyduje, czy rzecz ma wartość.

Nie da się jednak zawsze poznać wartości przed wydaniem pieniędzy. Możesz mieć 50 000 dolarów, zbudować produkt, wydać te pieniądze, a mimo to nie otrzymać tego, co stworzyłoby wartość. Czy godziny rozliczane z klientem i dolary są koniecznym złem, czy powinniśmy próbować wyjść poza ten model?

Fred Fowler: W pewnym sensie są koniecznym złem. Nadal trzeba jednak porównywać koszt pracy ludzi z wartością rezultatu. W Scrumie na koniec każdego sprintu zawsze trzeba stworzyć coś ukończonego, gotowego do przekazania klientowi.

Dlaczego? Ponieważ coś ma wartość dopiero wtedy, gdy jest gotowe i można przekazać to klientowi. Wartość mierzy się tym, ile klient zapłaci za rezultat. Co dwa tygodnie tworzysz coś wartościowego, mierzysz tę wartość i porównujesz ją z kosztem stworzenia.

Musisz dzielić produkt na części, z których każda ma mierzalną wartość. Nie „wydaje mi się, że to ma wartość”, lecz rzeczywistą, mierzalną wartość. Scrum podkreśla podejmowanie decyzji na podstawie pomiarów, a nie przypuszczeń czy opinii. Najważniejszą rzeczą do zmierzenia jest wartość.

Galen Low: Czy możesz przeprowadzić nas przez proces mierzenia wartości? Jeśli mierzenie zajętości nie jest szczególnie użyteczne, jakie wskaźniki powinniśmy mierzyć jako zespół Scrum? Kto ocenia, czy coś jest wartościowe między sprintami i jak się to śledzi?

Fred Fowler: W Scrumie pomiar wartości jest zasadniczo zadaniem jednej osoby. Scrum dzieli odpowiedzialność na trzy części: właściciela produktu, deweloperów i mistrza Scrum.

Zadaniem właściciela produktu jest maksymalizowanie wartości pracy zespołu. To on odpowiada za wartość. Nie można maksymalizować czegoś, czego nie da się zmierzyć, bo nie wiadomo, czy działanie poprawia sytuację, czy ją pogarsza.

Wartość można zwiększyć na cztery sposoby. Najczęstszy to zwiększenie przychodów. Możesz też zmniejszyć koszt. Jeżeli produkujesz milion sztuk rocznie i obniżysz koszt każdej o 50 centów, zyskujesz pół miliona dolarów.

Trzeci sposób to ograniczenie ryzyka. Kiedy byłem dyrektorem ds. informatyki, firma miała centrum danych połączone z główną siedzibą światłowodem. Raz w roku ktoś kopał w ziemi i przerywał połączenie, wyłączając firmę na cały dzień. Firma traciła wtedy około miliona dolarów.

Koszt ryzyka wynosił więc milion dolarów rocznie. Zaproponowałem przeniesienie centrum danych do bezpiecznej lokalizacji poza Sacramento, gdzie serwery miały Google i Facebook. Obiekt miał kontrolę dostępu, nadciśnienie wypychające kurz, zasilanie z dwóch podstacji i ogromne akumulatory. Wydaliśmy 50 000 dolarów, aby uniknąć ryzyka utraty miliona. To była wartość.

Czwartym sposobem jest zwiększenie szans. Jeśli wygrywasz jeden przetarg na sześć, a dzięki zmianie możesz wygrywać dwa na sześć, łatwo obliczyć dodatkowe pieniądze i porównać je z kosztem działania.

Galen Low: Właściciel produktu odpowiada za wartość i mierzy te cztery obszary. Jak przekazuje to zespołowi deweloperskiemu?

Fred Fowler: Właściciel produktu mierzy wartość i podejmuje racjonalne decyzje dotyczące pracy zespołu. Nie można jednak zmierzyć wartości czegoś, co jeszcze nie istnieje. Właściciel produktu musi więc przewidywać, co będzie wartościowe. To decyzja inwestycyjna, podobna do zakupu akcji.

Kieruje zespoły ku stworzeniu przewidywanej wartości, a następnie przekazuje rezultat klientom, aby sprawdzić jego wartość. Mierzy ją, sprawdzając, ile ludzie zapłacą, jakie koszty zostaną zaoszczędzone lub jakie możliwości powstaną.

Jak ocenić, czy właściciel produktu dobrze wykonuje swoją pracę? Należy spojrzeć na zwrot z inwestycji. Jeżeli sprint kosztował 50 000 dolarów, czy przyniósł ponad 50 000 dolarów wartości? Właściciel produktu i zespół są w tej samej łodzi: muszą dostarczyć więcej wartości, niż kosztuje ich praca.

Galen Low: To bardzo klarowne stwierdzenie. Czasem myślimy: „Zapłacą mi, bo przepracowałem 80 godzin, dokładnie tyle, ile obiecałem”. To jednak rozmowa o czasie i pieniądzach, a nie o wartości.

Fred Fowler: Gdy deweloperzy zrozumieją, że mają interes w tworzeniu wartości, powstaje partnerstwo. Właściciel produktu pełni rolę biznesową, a deweloperzy techniczną. Właściciel mówi, co jest pożądane, deweloperzy — co możliwe, a poprzez negocjacje ustalają, co jest praktyczne i najbardziej wartościowe.

Galen Low: Podoba mi się słowo „partnerstwo”. Scrum nie polega na służebności, ale na wzmacnianiu pozycji ludzi i wykorzystywaniu ich wiedzy. Chodzi o negocjowanie równowagi między wartością biznesową a tym, co można realnie stworzyć bez ogromnych kosztów.

Fred Fowler: Deweloperzy mogą znacząco wpływać na koszt w nieoczywisty sposób. Jeśli właściciel produktu chce stworzyć system logowania, deweloperzy powinni zapytać, czy można użyć logowania przez Google lub Facebooka, zamiast budować wszystko od zera.

Deweloperzy nie powinni pytać wyłącznie: „Co mam zrobić?”. Należy zapytać ich: „Czy możecie rozwiązać ten problem?”. Problem właściciela produktu może polegać na tym, że użytkownicy muszą jednoznacznie identyfikować się w aplikacji. Istnieje wiele rozwiązań: logowanie przez Google, rozpoznawanie twarzy czy odcisk palca.

Deweloperzy mogą powiedzieć, co jest łatwe, a co trudne, a właściciel produktu, co jest wartościowe. Wspólnie wybierają najprostsze rozwiązanie, które ma wartość. Następnie trzeba stworzyć je w takiej postaci, aby można było przekazać je klientowi i zmierzyć wartość.

Galen Low: Zdarzało mi się mierzyć zajętość, a nawet szybkość. Prędkość nadal jest wskaźnikiem, podobnie jak wykresy spalania pracy. Jak zespoły Scrum rozmawiają o wartości? Czy właściciel produktu mówi: „Chcieliśmy, żeby to było warte 65 dolarów, ale ludzie płacą tylko 60”? Czy chodzi o optymalizowanie konkretnego wskaźnika, czy raczej o zmianę kierunku między sprintami?

Fred Fowler: To wiąże się z wynagrodzeniem. Jeśli wszyscy otrzymują zapłatę za godzinę, mają zachętę, aby wykonywać pracę w trudny sposób. To choroba wielu projektów.

Pracowałem z firmą z pierwszej pięćdziesiątki największych przedsiębiorstw. Miała ambitny projekt: dwa lata i 500 milionów dolarów na całkowitą zmianę platformy procesów biznesowych. Zatrudniała ogromną liczbę osób, które były niezwykle zajęte: spotkania, raporty, pisanie kodu.

Po dwóch latach i wydaniu większości pieniędzy nie stworzyli żadnej wartości. Wytworzyli hałas, aktywność i mnóstwo rozliczanych godzin. Dopiero później okazało się, że była to praca pozorna.

Wynagrodzenie ma dwa aspekty. Po pierwsze, trzeba przyciągnąć ludzi, płacąc stawkę rynkową. Po drugie, należy wynagradzać wartość, którą tworzą. Jeśli zespół stworzy wartość wartą 100 000 dolarów, firma może przekazać mu na przykład 20%, czyli 20 000 dolarów.

Nie należy dzielić tej kwoty według wysokości pensji. Młodszy programista może uratować projekt, mimo że jego stawka jest niższa. Właściwym rozwiązaniem jest przekazanie pieniędzy zespołowi i pozwolenie mu na sprawiedliwy podział. Wszyscy mają wtedy zachętę do tworzenia wartości.

Galen Low: To przypomina model udziału w zyskach: pensja podstawowa, aby pozyskać ludzi, oraz zachęta zależna od stworzonej i konsekwentnie mierzonej wartości.

Fred Fowler: To ma sens, bo właściwie ustawia wszystkie zachęty. Właściciel produktu jest inwestorem, więc powinien mieć możliwość inwestowania czasu zespołu, ale musi odpowiadać za wyniki tych inwestycji.

Zespół deweloperski powinien mieć pełną władzę nad sposobem wykonania pracy. Nikt nie powinien mówić mu, jak ma to zrobić. Jeśli ktoś podejmuje decyzje za zespół, można później zrzucić na tę osobę winę za problemy. Gdy deweloperzy mają władzę do samodzielnego podejmowania decyzji, nie mogą wskazywać nikogo poza sobą.

Galen Low: Nasza branża nie zawsze dobrze budowała odpowiedzialność. Często słyszeliśmy: „Zrób to tak, bo tak powiedziałem”.

Fred Fowler: To przeciwskuteczne, ponieważ lekcje zdobyte podczas pracy nie wpływają na osoby podejmujące decyzje. Dlatego Scrum wymaga, aby zespoły deweloperskie były samozarządzające i interdyscyplinarne.

Interdyscyplinarność oznacza, że zespół potrafi samodzielnie stworzyć produkt. Musi również organizować i zarządzać własną pracą. W przeciwnym razie zawsze można zrzucić winę na osobę, która podjęła decyzję. Istnieje stare powiedzenie: „Nic nie jest niemożliwe, jeśli nie musisz zrobić tego sam”.

Galen Low: To zabawne. Chodzi o równowagę między wzmacnianiem pozycji a odpowiedzialnością. Możesz dać zespołowi sprawczość, ale zespół musi też odpowiadać za rezultaty. To nie dzieje się z dnia na dzień.

Fred Fowler: Potrzebne są trzy rzeczy: sprawczość, odpowiedzialność i kompetencje. Osoby, którym dajesz władzę, muszą być zdolne do działania. Właściciel produktu musi potrafić inwestować setki tysięcy lub miliony dolarów w tworzenie wartościowych produktów. Deweloperzy muszą potrafić stworzyć produkt jako zespół.

Największym wyzwaniem mistrza Scrum jest doprowadzenie do współpracy i zrozumienia własnych odpowiedzialności. Pomaga także system wynagrodzeń nagradzający rzeczywiście stworzoną wartość. Kiedy ludzie rozumieją, że premia zależy od mierzalnego rezultatu, zaczynają działać razem.

Galen Low: Mierz wartość i nagradzaj wartość.

Fred Fowler: Wartość produktu musi być mierzalna. Jeśli pracujesz nad czymś, czego wartości nie można zmierzyć, nie jest to produkt. Nie możesz wtedy podejmować racjonalnych decyzji.

Pracowałem w firmie posiadającej aplikację internetową do transakcji finansowych. Miała trzy główne elementy: warstwę frontową, interfejsy API oraz zaplecze przetwarzające dane. Każdy poziom miał innego właściciela produktu.

Powodowało to ciągłe spory. Aktualizacja frontu była opóźniona przez dwa lata, ponieważ właściciel produktu zaplecza nie uważał, że mieści się ona w jego planie wynagrodzeń. Problem polegał na tym, że nie można było zmierzyć wartości żadnej pojedynczej warstwy bez uwzględnienia całego łańcucha wartości.

Powinien istnieć jeden właściciel produktu całego łańcucha, odpowiadający za dostarczoną wartość. Wtedy konflikty zniknęłyby, a rozwój byłby racjonalny.

Galen Low: To ciekawe, że przeszkodą dla wartości bywa po prostu polityka.

Fred Fowler: Tak, zwłaszcza gdy nikt nie potrafi zmierzyć wartości swoich działań i decyzji. Decyzje stają się przypadkowe, bo nie ma podstaw do racjonalnego ustalania priorytetów.

Galen Low: Istnieje też pojęcie minimalnego doświadczenia nadającego się do wdrożenia. Jeśli produkt składa się z trzech warstw, trzeba ciąć go pionowo, od góry do dołu, a nie poziomo. W przeciwnym razie widzi się tylko jedną warstwę.

Być może zespoły, które twierdzą, że nie mogą pracować w Scrumie, ponieważ nie tworzą przyrostów ani minimalnego produktu, po prostu nie myślą o sobie w kategoriach produktu. Powinny postrzegać rezultat jako przekrojowe fragmenty, a nie oddzielne komponenty z osobnymi priorytetami, listami prac i właścicielami produktów.

Fred Fowler: Sprawdzałem to z Jeffem Sutherlandem, jednym z twórców Scruma. Potwierdził, że produkt to coś, co można wytworzyć i czego wartość można obiektywnie zmierzyć.

Wartość mierzy się przez sprzedaż i płatność klienta. Jeśli nie można czegoś sprzedać ani znaleźć osoby, która za to zapłaci, nie jest to produkt, tylko część większego produktu, który powinien kierować decyzjami rozwojowymi.

Galen Low: Na koniec jedno pytanie. Czy mierzenie wartości i wpływu zamiast zajętości może działać w innych metodykach?

Fred Fowler: Inne metodyki? Oczywiście. Scrum jest warstwą położoną na czymś głębszym. Zwinność również jest taką warstwą.

Scrum próbuje tworzyć produkty bez ślepego stosowania przepisu. Model kaskadowy PMI polega na planowaniu i tworzeniu instrukcji dla grupy osób. Problem w tym, że rzeczy się zmieniają.

Roman Pichler opisał projekt trwający dwa lata, którego celem było unowocześnienie głównego produktu firmy świadczącej usługi medyczne. Wszystko zaplanowano zgodnie z modelem kaskadowym. Dziewięć zespołów dostarczyło pracę na czas i poniżej budżetu, ale po dwóch latach okazało się, że produkt był już przestarzały przed dostarczeniem.

Dlatego Scrum mówi: nie stosuj sztywnego przepisu. Twórz przyrosty, obserwuj, ucz się i dostosowuj. Głębsza prawda polega na tym, że wykwalifikowani ludzie muszą podejmować decyzje, za które odpowiadają, zarówno biznesowo, jak i produktowo. Deweloperzy muszą umieć tworzyć produkt i zarządzać sobą.

Do tego potrzebny jest sposób mierzenia przyrostowego postępu produktu i projektu. Zachęcam wszystkich, niezależnie od używanej metodyki, aby koncentrowali się na mierzeniu wartości zamiast aktywności oraz rezultatów zamiast produktów pracy. Jeśli można mierzyć rezultaty i uczyć się na ich podstawie, jest to droga do sukcesu.

Galen Low: Oto i ona. Bardzo dobrze.

Fred, rozmawialiśmy o twojej grupie spotkaniowej i książkach. Gdzie słuchacze mogą dowiedzieć się więcej?

Fred Fowler: Od 2015 roku prowadzę internetową grupę spotkaniową poświęconą Scrumowi, którą nazywamy Advanced Scrum Case Studies.

Co dwa tygodnie spotykamy się online. Wcześniej publikuję przypadek dotyczący problemu z zarządzania projektami lub Scrumem, na przykład pracy z zespołami zewnętrznymi albo mierzenia wartości.

Jeśli jesteście zainteresowani, możecie dołączyć. Grupa nazywa się Silicon Valley Professional Scrum i można ją znaleźć w serwisie Meetup. Znajdziecie tam również spotkania Advanced Scrum Case Studies.

Spotkania stworzyły wiele interesujących materiałów. Mam notatki dotyczące około 60 przypadków, części własnych, a części zgłoszonych przez członków. Zebrałem je w książce Advanced Scrum Case Studies. Jest dostępna na Amazonie oraz na mojej stronie: www.siliconvalleyscrum.com.

Książka zawiera 15 interesujących przypadków, a obecnie pracuję nad drugim tomem. Mam zgromadzonych ponad 60 przypadków i co kilka tygodni przybywają kolejne.

Galen Low: Nie wiedziałem, że książka powstała na podstawie materiałów z dyskusji grupy. To świetne.

Fred, dziękuję za udział w programie. Bardzo podobały mi się twoje historie i perspektywa. Rozmowa o wynagrodzeniach mogłaby być osobnym odcinkiem.

Mam nadzieję, że nasi słuchacze wynieśli z niej wiele wartości. Dziękuję.

Fred Fowler: Dziękuję. Bardzo dobrze mi się z tobą rozmawiało.

Galen Low: Co o tym sądzicie?

Czy zespoły projektowe mogą koncentrować się na tworzeniu wartości zamiast na liczbie przepracowanych godzin lub ukończonych historyjek użytkownika? Czy jesteśmy zbyt zależni od modelu wymiany pieniędzy za godziny pracy?

Opowiedzcie nam swoją historię: jakie wskaźniki okazały się właściwe dla waszych projektów? Jakie zmiany lub rezultaty zauważyliście dzięki lepszemu wglądowi w dane projektowe?

Zostawcie swoje przemyślenia w komentarzach poniżej!

Jeśli chcecie doskonalić umiejętności strategicznego lidera projektu, dołączcie do naszej społeczności!

Odwiedźcie thedigitalprojectmanager.com/membership, aby uzyskać dostęp do wspierającej społeczności, która dzieli się wiedzą, rozwiązuje złożone problemy i wspólnie kształtuje przyszłość naszego zawodu.

Od rozbudowanych szablonów i comiesięcznych szkoleń oszczędzających czas i energię po wsparcie innych członków w dyskusjach na Slacku, wydarzeniach na żywo i grupach mastermind — członkostwo oznacza ponad tysiąc osób po twojej stronie podczas rozwoju kariery w cyfrowej realizacji projektów.

Jeśli podobało wam się to, czego dziś słuchaliście, zasubskrybujcie podcast i pozostańcie w kontakcie na thedigitalprojectmanager.com.

Do usłyszenia następnym razem. Dziękuję za uwagę.