Werkende betalingen
Een betaalscherm tonen kan. Geld ontvangen niet. Daarvoor heb je een goedgekeurd account bij een betaaldienst nodig, met controle op je bedrijfsgegevens. Die aanvraag loopt buiten de bouwdag om.
Wat krijg je niet in één dag?
Een werkdag levert een klikbaar prototype op waarmee je een idee kunt laten zien en toetsen. Er is ook een lijst met dingen die er bewust niet in passen. Die grens is geen voorbehoud achteraf, maar de reden dat een dag genoeg is voor waar het wel voor bedoeld is. Hieronder staat wat er buiten valt en waarom.
01
/
06
Het korte antwoord
Alles wat afhankelijk is van goedkeuring, toegang of doorlooptijd van een ander valt buiten een bouwdag.
Een bouwdag is kort, en dat is precies de bedoeling. In die tijd bouwen we de kern van je idee zo ver uit dat je erdoorheen kunt klikken en er een gesprek over kunt voeren. Wat we niet kunnen versnellen zijn de dingen die buiten de dag om lopen: een account dat door een betaaldienst moet worden goedgekeurd, toegang tot een systeem waar een beheerder over gaat, of een beoordeling in een appstore.
Dat onderscheid is bruikbaar bij het bepalen van de scope. Werk dat binnen de dag valt is werk waar wij invloed op hebben. Werk dat buiten de dag valt, wacht op iemand anders. Daarom is de eerste vraag in de intake niet hoeveel we kunnen bouwen, maar welke vraag je aan het eind van de dag beantwoord wilt hebben.
Wat er wel uitkomt staat op de pagina over wat je na een dag bouwen krijgt. Deze pagina is het spiegelbeeld daarvan.
02
/
06
Wat er buiten valt
Vier categorieën komen het vaakst voorbij. Ze hebben gemeen dat de vertraging niet in het bouwen zit.
Koppelingen met bestaande systemen
Een koppeling met een boekhoudpakket, ERP of ledenadministratie vraagt toegang, rechten en testdata. Dat regelen kost doorgaans meer tijd dan het koppelen zelf. In het prototype bootsen we het gedrag na.
Publicatie in de App Store
Publiceren vraagt een ontwikkelaarsaccount, beoordelingsmateriaal en een beoordelingsronde bij Apple of Google. Het prototype werkt wel op een telefoon en is te delen via een link.
Daarnaast valt er een vierde categorie buiten: alles wat met productie te maken heeft. Een beveiligingsaudit, migratie van bestaande gegevens, een uitgewerkt rollen- en rechtenmodel en gedrag onder zware belasting horen bij een app die live gaat, niet bij een prototype dat een vraag beantwoordt.
03
/
06
Waarom die grens er is
Niet omdat het te moeilijk is, maar omdat de klok elders loopt.
De onderdelen hierboven zijn stuk voor stuk goed te bouwen. Het punt is dat ze afhangen van beslissingen en processen buiten de bouwdag. Een betaaldienst beoordeelt je aanvraag op zijn eigen tempo. Een IT-afdeling geeft toegang wanneer het in de planning past. Een appstore doet een controle die dagen kan duren.
Als we die onderdelen toch in de dag zouden proppen, gaat de tijd op aan wachten en aanvragen in plaats van aan bouwen. Het resultaat is dan een halve koppeling en geen antwoord op je eigenlijke vraag. Door ze er bewust buiten te laten, blijft de dag beschikbaar voor het deel dat je wilt zien werken.
Zie ook wat er gebeurt als het onderweg anders loopt, want dat is een andere vraag dan deze.
04
/
06
Wat wel en niet in een dag past
Een praktische indeling om je eigen idee tegen te houden.
Past in een werkdag
- Eén kernflow die je van begin tot eind kunt doorlopen.
- Schermen met representatieve gegevens die kloppen in het verhaal.
- Een inlog die het onderscheid tussen gebruikers laat zien.
- Een betaalstap die het scherm en de bevestiging toont.
Vraagt meer dan een werkdag
- Een betaling die daadwerkelijk geld verplaatst.
- Een koppeling met een systeem waar je nog geen toegang toe hebt.
- Publicatie in de App Store of Google Play.
- Migratie van bestaande gegevens uit een lopend systeem.
05
/
06
Hoe je met die grens omgaat
De grens is een scoping-instrument, geen beperking waar je omheen moet werken.
In de intake bepalen we samen welke vraag centraal staat. Vaak blijkt dat het onderdeel dat buiten de dag valt niet het onderdeel is waar je twijfel over hebt. Iemand wil weten of gebruikers de flow snappen, niet of de betaling technisch werkt. Dan is een getoonde betaalstap voldoende.
Soms ligt het anders en zit je vraag juist in het stuk dat niet past. Dan bespreken we dat vooraf, en kijken we of er een kleinere variant is die dezelfde onzekerheid wegneemt. Als die er niet is, is een dag niet het juiste formaat en zeggen we dat.
Twijfel je zelf over de omvang, dan geeft de scope-slicer een eerste indeling van je featurelijst, en loopt de kan-dit-in-1-dag-check de vraag met je na.
06
/
06
Veelgestelde vragen
Waarom lukt een koppeling met een bestaand systeem niet in een dag?
Omdat de tijd zelden in het koppelen zelf zit. Toegang regelen, de juiste rechten krijgen, testdata bemachtigen en uitzoeken hoe het andere systeem zich gedraagt loopt via mensen en procedures die niet op een bouwdag wachten. Wat wel kan, is de koppeling nabootsen met representatieve gegevens, zodat je de flow eromheen kunt beoordelen.
Kan er wel een betaling in het prototype?
Een betaalflow tonen kan, een werkende betaling ontvangen niet. Voor dat laatste heb je een goedgekeurd account bij een betaaldienst nodig, plus een controle op je bedrijfsgegevens. Die aanvraag loopt buiten ons om en duurt langer dan een dag. In het prototype zie je het scherm, de bevestiging en het vervolg, zonder dat er geld beweegt.
Waarom staat een prototype niet in de App Store?
Publicatie vraagt een ontwikkelaarsaccount, een beoordelingsronde bij Apple of Google en materiaal zoals iconen, schermafbeeldingen en een privacyverklaring. De beoordeling alleen al duurt dagen. Een prototype dat op een telefoon werkt kun je wel gewoon delen via een link.
Betekent dit dat het prototype nep is?
Nee. Wat erin zit werkt, je kunt erdoorheen klikken en het gedraagt zich zoals je verwacht. Het verschil met een productieversie zit in wat eromheen hoort: beveiliging tegen misbruik, foutafhandeling voor uitzonderingen, gedrag onder belasting en onderhoud op termijn.
Wat als het onderdeel dat ik wil bewijzen juist buiten de dag valt?
Dan is dat het gesprek dat we in de intake voeren, en niet iets dat je aan het eind van de dag ontdekt. Soms is er een kleinere variant die dezelfde vraag beantwoordt. Soms is de conclusie dat je meer tijd nodig hebt dan een dag, en dan zeggen we dat vooraf.
Kan het prototype daarna alsnog naar productie?
Dat kan, maar het is een apart traject met eigen keuzes over architectuur, beveiliging en beheer. Sommige onderdelen blijven bruikbaar, andere worden opnieuw opgebouwd met productie als uitgangspunt.
Waarom noemen jullie deze grenzen zo expliciet?
Omdat een verkeerde verwachting het grootste risico van een korte bouwdag is. Als vooraf duidelijk is wat er wel en niet in past, gaat de dag over de vraag die je wilt beantwoorden in plaats van over wat er ontbreekt.
