Wat is uw skateboard?
De bovenste rij illustreert een veel voorkomende misvatting over iteratieve, incrementele productontwikkeling (ook bekend als Agile Scrum).
Veel projecten mislukken omdat ze het waterfall-model (het project bouwen tot een project 100% klaar is en helemaal aan het einde pas opleveren) gebruiken. Door de jaren heen heb ik vele projecten zien falen op het waterfall-model. Wanneer Agile scrum echter wordt gepresenteerd als een alternatief, aarzelen mensen soms om een onvoltooid product af te leveren - wie wil de helft van een auto?
Stel u dit voor:
“AUB-meneer, hier is onze eerste iteratie, een voorband. Wat denkt u?"
De klant zegt: "Waarom bezorgt u me in vredesnaam een band? Ik heb een auto besteld! Wat moet ik hiermee doen?"
Bij elke levering komt het product dichterbij, maar de klant is nog steeds miscontent omdat hij het product niet echt kan gebruiken. Het is nog maar een gedeeltelijke auto.
En tot slot, als het product klaar is, zegt de klant “Bedankt! Waarom hebt u dit niet gewoon afgeleverd en alle andere nutteloze bezorgingen overgeslagen? ”.
In dit voorbeeld is de klant blij met het eindproduct, want dat is wat hij besteld heeft. In werkelijkheid is dat meestal niet zo. Er is veel tijd verstreken zonder daadwerkelijke gebruikerstests, dus het product is hoogstwaarschijnlijk bezaaid met ‘ontwerpfouten’ op basis van onjuiste aannames over wat mensen nodig hebben. Dus dat smileygezicht aan het einde is behoorlijk idealistisch.
Hoe dan ook, de eerste rij staat voor "bastardized agile". Technisch gezien kan het incrementele en iteratieve levering zijn, maar het ontbreken van een daadwerkelijke feedbacklus maakt het erg riskant - en zeker niet flexibel.
Vandaar de kop " Non pas ça".
Nu voor de tweede rij.
Hier pakken we een heel andere benadering aan. We beginnen met dezelfde context: de klant heeft een auto besteld. Maar deze keer bouwen we niet zomaar een auto. In plaats daarvan concentreren we ons op de onderliggende behoefte die de klant wil vervullen. Blijkt dat zijn onderliggende behoefte is: "Ik moet sneller van A naar B komen", en auto is daar slechts een mogelijke oplossing voor. Onthoud dat auto slechts een analogie is, denk aan elke vorm van productontwikkelingssituatie op maat.
Het team levert het kleinste ding dat ze kunnen bedenken, waardoor de klant dingen test en ons feedback geeft. U kunt het zien als de eerste stap binnen het MVP-verhaal.
Ik noem het bewust geen Proof of Concept (PoC). Een PoC gooit u meestal na een bepaalde periode weg, een MVP, zoals wij deze bedoelen, legt de basis voor de toekomstige ontwikkelingen en past binnen de business -en data strategie 1.
Sommige noemen hun eerste release zelfs de "de skateboardversie" van het product, gebaseerd op deze analogie...
Het is onwaarschijnlijk dat de klant hier helemaal blij mee is. Dit is nergens in de buurt van de auto die hij heeft vooropgesteld als eindresultaat. We maken een paar early adopters blij, maar ons belangrijkste doel op dit punt is gewoon om te leren en terwijl al een basisoplossing te hebben.
In tegenstelling tot het voorwiel in het eerste scenario is het skateboard echter eigenlijk een bruikbaar product dat de klant helpt om van A naar B te komen. We streven nog steeds naar het bouwen van een auto, maar met deze skateboardfase hebben we een eerste stap gezet en kunnen we feedback verzamelen “.
Nadat er gebruik gemaakt werd van het skateboard, zeggen de gebruikers: “Ik ben er sneller van punt A naar B. Maar het is onstabiel. Ik val er te gemakkelijk af”.
Dus de volgende iteratie proberen we dat probleem op te lossen, of er in ieder geval meer over te leren.
De gebruiker kan zich nu verplaatsen zonder eraf te vallen!
Men wil nog steeds die auto. Maar ondertussen wordt het product ook daadwerkelijk gebruikt en krijgen we feedback. De grootste klacht is dat het moeilijk is om langere afstanden af te leggen, zoals tussen gebouwen, vanwege de kleine wielen en het ontbreken van pauzes. Dus de volgende release verandert het product in zoiets als een fiets.
Gaandeweg leren we een aantal dingen: de klant houdt van het gevoel van frisse lucht op zijn gezicht. De klant houdt van stabiliteit en grotere.
De fiets kan hierna bijvoorbeeld een veel beter product blijken dan de auto oorspronkelijke die men voor ogen had. Tijdens het testen van dit product kunnen we zelfs ontdekken dat de paden sowieso te smal zijn voor een auto. We hebben de klant zojuist veel tijd en geld bespaard en hem in minder tijd een beter product gegeven!
Nu denkt u misschien “maar hadden we dat niet al moeten weten? Via een analyse vooraf van de context en behoeften van de klant? "
Goed punt. Maar in de meeste real-life productontwikkelingsscenario's die ik heb gezien, ongeacht hoeveel analyse u vooraf doet, bent u nog steeds verrast wanneer u de eerste echte release in handen van een echte gebruiker legt, en veel van uw aannames blijken ver weg te zijn.
Hoe dan ook, terug naar het verhaal. Misschien wil de klant meer. Soms moet hij naar een andere stad reizen en is de fietstocht te langzaam en bezweet. Dus volgende iteratie voegen we een batterij toe.
Dus wat nu? Misschien is de klant blij met de elektrische fiets. We zouden het project eerder kunnen beëindigen dan gepland. De meeste producten zitten vol met complexiteit en functies die niemand gebruikt. De iteratieve aanpak is echt een manier om minder te leveren, of om de eenvoudigste en goedkoopste manier te vinden om het probleem van de klant op te lossen.
De klant kan ervoor kiezen om door te gaan, met of zonder aanpassingen aan de vereisten. We kunnen eindigen met exact dezelfde auto als oorspronkelijk bedoeld. Het is echter veel waarschijnlijker dat we onderweg vitale inzichten krijgen en uiteindelijk met iets anders eindigen. Zoals dit:
De klant is dolgelukkig! Waarom? Omdat we gaandeweg leerden dat hij frisse lucht in zijn gezicht waardeert, hebben we uiteindelijk een cabriolet gekregen. Hij heeft toch een auto gekregen - maar een betere auto dan oorspronkelijk gepland!
Dus laten we een stap terug doen.
Het bovenste scenario (het leveren van een voorband) is waardeloos omdat we dingen blijven leveren die de klant helemaal niet kan gebruiken
De hamvraag is dus: wat is uw skateboard?
Bij productontwikkeling is een van de eerste dingen die u moet doen (nadat u heeft beschreven welk probleem u voor wie probeert op te lossen), uw skateboard-equivalent te identificeren. Beschouw het skateboard als een analogie voor het kleinste dat u in de handen van echte gebruikers kunt leggen, en krijg echte feedback.
Of gebruik "treinkaartje" als die analogie beter werkt.
Dit geeft u de broodnodige feedback lus en geeft zowel u als de klant controle over het project - u kunt leren en veranderingen aanbrengen, in plaats van alleen het plan te volgen en er het beste van te hopen.
Belangrijkste leerpunten:
• Vermijd Big Bang-levering (waterfall-model) voor complexe, innovatieve productontwikkeling. Doe het iteratief en stapsgewijs.
• Begin met het identificeren van uw skateboard - het vroegst testbare product. The sky is the limiet, maar slik uw trots in en begin met het afleveren van het skateboard. En onthoud - de skateboard/ autotekening is slechts een analogie!
If you set out to make the most robust thing you can imagine, it will take you a long time before you create value for your customer or gain any learnings for yourself. Instead, focus on something you can make quickly that will provide an opportunity to gain real feedback. At the start of every new project, ask your team: “What’s our skateboard?”
Investeren in IT is cruciaal voor elk bedrijf, maar welke investering is het meest belangrijk?
DX-Solutions helpt deze beslissing voor te bereiden door middel van een business analyse.
Tijdens een dergelijke analyse bouwen we een volledig beeld van de mogelijke investeringen(-en). We nemen daarbij de uitdagingen, kosten, opportuniteiten en winsten die ze met zich kan meebrengen mee in acht.
Afhankelijk van de context en noden maken we gebruik van interviews, workshops, probleemanalyses, fit-gap assessments of kosten- en opbrengstprojecties.
We leveren steeds een document waarin helder beschreven staat hoeveel waarde een investering zal opleveren voor uw zaak. Bijkomend voorzien we een IT-roadmap (3 à 5 jaar) voor de komende jaren op.
Vorig artikel:
Product Information Management (PIM)Volgend artikel:
Large-Scale Scrum (LeSS) is more
