Potrzeba biznesowa 

Potrzeba biznesowa, czyli „business need” jest tym, co powinniśmy spełniać w ramach naszych agile’owych procesów. Niestety, w większości przypadków po prostu realizujemy zlecone prace, bez jakiejkolwiek optymalizacji wytwarzanej wartości. Agile to dla nas tylko sposób na realizację waterfallowego projektu.

Right thing, czyli właściwy produkt

Najbardziej niedocenianą cechą podejścia zwinnego jest możliwość „tworzenia właściwych produktów”. Dziś zajmiemy się więc różnicą pomiędzy „building the right thing” i „building thing right”. Czyli, z grubsza, „dobrym wytwarzaniem” i „wytwarzaniem dobrej [właściwej] rzeczy”.

Język angielski nam nie ułatwi przebrnięcia przez dzisiejszy tekst, a już na pewno nie uprości mi jego pisania. „Building the right thing” oznacza „budowę właściwej rzeczy”, czyli takiej, która jest potrzebna naszym odbiorcom. Jest to niewątpliwie podstawa podstaw jeżeli chodzi o podejście zwinne.

„Ten cały agile” w swoim założeniu mówi, że ani my nie jesteśmy w stanie precyzyjnie odgadnąć potrzeb naszych klientów, ani oni sami często nie są ich świadomi. Jedynym sposobem na to, żeby odkryć te potrzeby i je spełnić, jest tworzenie i wypuszczanie rozwiązania kawałek po kawałku, odkrywanie jak reagują na nie odbiorcy. To często stoi w sprzeczności z podejściem projektowym.

Jeżeli mamy projekt, to zwykle mamy też jego zakres, budżet oraz datę początku i końca. Jak mówiliśmy w materiale „Projekt kontra produkt„, to niekoniecznie wyklucza podejście zwinne, ale zwykle jest tożsame ze sztywną listą wymagań. I nawet jeżeli w trakcie jego budowy i wypuszczania kolejnych wersji na rynek okaże się, że jest to zły pomysł albo wypadałoby zupełnie zmienić tworzony produkt, to tym gorzej dla nas.

Projekty mają to do siebie, że raz wystartowane trudno zatrzymać. A już prawie niemożliwością jest zmiana kierunku, w którym podążają. Bo kto zna projekt, gdzie w połowie zmieniono jego cel?

Building it right, czyli właściwy proces

I tak dochodzimy do procesu wytwórczego, czyli „building thing right”.

Nie da się ukryć, że bez zwinnego procesu wytwórczego, który umożliwią nam dostosowywanie naszego rozwiązania do oczekiwań klientów i użytkowników zostaniemy li tylko ze zwinną wydmuszką. Iteracyjnym i/lub przyrostowym procesem realizującym kawałek po kawałku z góry zdefiniowany zestaw wymagań.

Ta karykatura zwinności jest niestety bardzo popularna. Wiele przedsięwzięć wprowadza „zwinne procesy” albo nawet „zwinne metodyki”, totalnie zapominając, że jeżeli mamy z góry zdefiniowaną szczegółową listę wymagań oraz niezmienny czas i budżet, to równie dobrze możemy sprawnie wykorzystać stary dobry waterfall.

I tutaj zwykle dochodzimy do sedna sprawy – wymagania owszem, są wyryte w kamieniu, ale z drugiej strony chcielibyśmy móc dostosować rozwiązanie do prawdziwych potrzeb użytkowników. Prawdziwych, a nie tych, które zebrane zostały w procesie RFP kilka miesięcy temu i przy których spisywaniu nie brał udziału ani jeden użytkownik końcowy tworzonego produktu.

Wszystko rozbija się w tym momencie o fakt, że produkt naszego projektu został zdefiniowany na samym jego początku. Gdyby to był projekt mający na celu spełnienie określonych potrzeb naszych odbiorców, z ewentualnym zarysowaniem formuły, wszystko byłoby ok.

Nic nie stoi na przeszkodzie zaznaczyć, że np. chodzi nam o aplikację na urządzenia mobilne i o dotarcie do x tysięcy odbiorców. Ale oba te kryteria można spełnić na tysiące sposobów. Tylko oczywiście musi temu wszystkiemu towarzyszyć dobrze zdefiniowana potrzeba biznesowa.

Potrzeba biznesowa to nie wszystko

O wiele lepiej pracuje nam się zwinnie, jeżeli wiemy co chcemy osiągnąć, a droga do tego celu nie jest z góry określona. Jeżeli chcecie zobaczyć jak definiować wymagania w ten sposób (zarówno na poziomie projektu/produktu jak i tym operacyjnym), zapraszam do tekstu „Wymagania, a nie zadania„. Ale powtórzmy jeszcze raz: to nie wystarczy.

Oba elementy wspomniane w dzisiejszym tekście – właściwy pomysł i właściwy sposób budowy – są nieodłącznie ze sobą związane. Idealnie pracujące zwinne zespoły to takie, które są świetne zgrane i potrafią wytwarzać określone produkty. Do nich zaś trafiają inicjatywy i pomysły, które szybko są walidowane pod kątem osiągania właściwych rezultatów.

Inaczej mówiąc, mamy grupę ludzi potrafiącą wytwarzać wartościowe rozwiązania („building it right”), a do tego jakiś mechanizm, który pozwala nam decydować o tym, nad czym aktualnie powinniśmy pracować („buidling the right thing”). Niestety, taki widok należy do rzadkości.

Jak więc to powinno wyglądać modelowo? Mechanizmów działania w opisywany przeze mnie sposób dostarcza każda metodyka zwinna. Wystarczy skorzystać z nich właściwie – niech Product Owner faktycznie decyduje o tym, co w tej chwili powinniśmy wytwarzać, a nie tylko mechanicznie realizuje backlog punkt po punkcie. Jeżeli mamy jakieś rozwiązania skalowalne, to niech i ten nieszczęsny PI Planning faktycznie służy wybraniu „the right thing”, a nie tylko ślepemu podążaniu za harmonogramem projektu zdefiniowanym kilkanaście miesięcy wcześniej.

Świetnie jest wyjść od ogólnie zdefiniowanej potrzeby biznesowej i zastanawiać się, w jaki sposób ją spełnić i jak możemy na niej skorzystać. Ale bez właściwego procesu będą to tylko mrzonki i marzenia. Z drugiej zaś strony sam proces ze sztywnym harmonogramem i ściśle zdefiniowaną niezmienną listą wymagań nie zadziała.

I gdzieś tu się czai niewypowiedziane słowo „synergia”, które nie należy do moich ulubionych, więc dla mnie to znak, żeby skończyć dzisiejszy tekst i zostawić Was z tymi przemyśleniami.