01
Het verzoek
Wat moet er anders, waarom, voor wie, en hoe erg is het als het niet gebeurt. Vier vragen, geen vrije mail.
OneDayBuild, het bouwdagmerk van Appfront
Kan een wijzigingsverzoek met impactbeoordeling in één dag?
Ja. Wie iets veranderd wil hebben aan een systeem, een proces of een product, dient het verzoek in met wat en waarom, de beoordelaar vult de impact in op kosten, tijd en risico, en het verzoek doorloopt een vaste reeks van ingediend naar besloten. Het overzicht van wat er openstaat, wie eraan zit en wat is afgewezen, is daarmee terug. Wat er niet in past, is de beoordeling zelf automatiseren.
- Eén werkdag
- Werkend prototype
- Code in je eigen repository
01/06
Wat er eigenlijk wordt gevraagd
Niet of een formulier kan, maar of niemand meer hoeft te vragen wat er met zijn verzoek is gebeurd.
Wijzigingsverzoeken komen overal binnen: een mail aan de projectleider, een bericht in de chat, een opmerking bij de koffie. Een deel wordt opgepakt, een deel vergeten, en na een half jaar weet niemand meer wat er is toegezegd. De indiener vraagt hoe het ermee staat, de beoordelaar zoekt in zijn mailbox, en het antwoord is een schatting.
Het probleem is niet dat er te veel verzoeken zijn, maar dat ze geen plek hebben. Eén plek waar een verzoek binnenkomt met wat en waarom, waar iemand de impact invult op kosten, tijd en risico, en waar het verzoek een status heeft die iedereen kan zien, haalt de vraag 'hoe staat het ermee' weg. En het maakt afwijzen mogelijk: een verzoek dat is afgewezen met een reden, komt niet elke maand terug.
In een dag bouwen we die plek. Het formulier met wat, waarom en voor wie, de impactvelden voor de beoordelaar, de reeks van ingediend via beoordeeld naar goedgekeurd of afgewezen, en het overzicht per status. De impact zelf uitrekenen blijft mensenwerk; de flow zorgt dat het wordt opgeschreven en dat de indiener het ziet.
02
De impact
Kosten, tijd, risico en wie erdoor wordt geraakt, ingevuld door wie het kan overzien. Een verzoek zonder impact komt niet bij de beslisser.
03
De reeks
Ingediend, in beoordeling, goedgekeurd, ingepland, afgewezen. Elke stap met wie en wanneer, en de indiener ziet hem.
04
Het overzicht
Wat er openstaat, hoe lang al, bij wie. De lijst die nu in drie mailboxen zit, op één scherm.
02/06
Wat valt binnen en buiten de bouwdag
Binnen scope
- Een formulier voor het verzoek: wat, waarom, voor wie, urgentie, met bijlagen.
- Impactvelden voor de beoordelaar: kosten, tijd, risico, geraakte onderdelen, met een advies.
- Een vaste reeks statussen met wie en wanneer, en een melding aan de indiener bij elke stap.
- Een overzicht per status en per beoordelaar, en de code in je eigen repository.
Buiten scope
- De impact automatisch berekenen; dat blijft een inschatting door een mens.
- Koppeling met je planningstool, ticketsysteem of ontwikkelomgeving.
- Een formeel wijzigingsbeheerproces volgens een norm, met adviesraad en vrijgave.
- Rollen en rechten op basis van jullie SSO; voor het prototype werkt een link per mail.
03/06
Hoe de bouwdag verloopt
- Stap 1
De verzoeken van nu op tafel
Twintig verzoeken uit mail en chat: wat werd gevraagd, wat is ermee gebeurd.
- Stap 2
Het formulier
Wat, waarom, voor wie, urgentie. Kort, want een lang formulier drijft de vraag terug naar de chat.
- Stap 3
De impactvelden
Kosten, tijd, risico en geraakte onderdelen, met een advies. Voor de beoordelaar, in zijn taal.
- Stap 4
De reeks en de meldingen
Statussen met wie en wanneer; de indiener krijgt bericht bij elke stap.
- Stap 5
Het overzicht
Open verzoeken per status, met de ouderdom erbij. Dit is het scherm voor het weekoverleg.
- Stap 6
Opleveren
Live URL, code in je eigen repository en de twintig verzoeken erin als startpunt.
Volgende stap
Wil je het overzicht over verzoeken terug?
Stuur ons tien verzoeken zoals ze nu binnenkomen en vertel wie beoordeelt en wie beslist. Dan zeggen we of het in één dag past en welke impactvelden bij jullie horen.
04/06
Eerlijk over wat dit oplevert
- De flow beoordeelt niet. Ze zorgt dat iemand het doet en opschrijft. Wie hoopt dat de software zegt of een wijziging verstandig is, koopt het verkeerde.
- Het werkt alleen als de zijdeur dicht is. Als een verzoek via de wandelgang nog steeds sneller gaat, blijft het via de wandelgang gaan. De afspraak dat alles via de flow loopt, is belangrijker dan de flow.
- Afwijzen is de helft van de waarde. Een verzoek dat is afgewezen met een reden, komt niet terug. Wie niet durft af te wijzen, krijgt een lange lijst met open verzoeken in plaats van een lange lijst met mails.
- Een norm vraagt meer. Formeel wijzigingsbeheer met adviesraad, vrijgave en audittrail is een traject. De bouwdag geeft de flow waar dat later op kan bouwen.
05/06
Twee manieren om verder te gaan
De bouwdag maakt je idee aantoonbaar. Wil je daarna doorbouwen naar een volwaardige applicatie, dan doet Appfront dat traject.
Eén bouwdag, OneDayBuild
- Je wilt dat verzoeken op één plek binnenkomen en dat iedereen ziet wat ermee gebeurt.
- Aan het eind van de dag loopt een echt verzoek door de flow naar een besluit.
- Één dag, vaste prijs, code in je eigen repository.
Volledig traject, Appfront
- Het werkt en je wilt koppeling met planning en tickets, rollen via SSO en formeel wijzigingsbeheer.
- Rapportage over doorlooptijd, een adviesraad en vrijgave volgens jullie norm.
- Een traject bij Appfront, met beheer en doorontwikkeling.
06/06
Veelgestelde vragen
Kan een wijzigingsverzoek met impactbeoordeling in één dag?
Ja. In een dag bouwen we het formulier voor het verzoek, de impactvelden voor de beoordelaar, een vaste reeks statussen met meldingen aan de indiener en een overzicht van wat openstaat. De impact zelf berekenen en de koppeling met planning of tickets vallen erbuiten.
Kan een simpele flow het overzicht over openstaande verzoeken herstellen?
Ja, als alle verzoeken erdoor gaan. Het overzicht ontstaat doordat elk verzoek een status heeft en niet meer in een mailbox zit. De voorwaarde is een afspraak: wat niet in de flow staat, bestaat niet. Zonder die afspraak is het een tweede plek naast de mail.
Wie vult de impact in?
Degene die het kan overzien: de projectleider, de productverantwoordelijke of de ontwikkelaar. De flow stuurt het verzoek naar die persoon en vraagt om kosten, tijd, risico en een advies. Pas met impact gaat het door naar de beslisser.
Ziet de indiener wat er met zijn verzoek gebeurt?
Ja, bij elke statuswijziging krijgt hij een bericht met de stap en, bij afwijzing, de reden. Dat is het einde van de vraag hoe het ermee staat, en het maakt afwijzen makkelijker omdat de reden vastligt.
Kunnen we dit koppelen aan ons ticketsysteem of onze planning?
Niet in de bouwdag. Een goedgekeurd verzoek kan wel handmatig een ticket of een planningsregel worden; de flow bewaart de link ernaartoe. De koppeling zelf is een uitbreiding voor daarna, als de flow zich heeft bewezen.
Is dit hetzelfde als een interne projectaanvraag?
Het lijkt erop, maar de vraag is anders. Een projectaanvraag vraagt om iets nieuws met budget; een wijzigingsverzoek vraagt om een aanpassing aan iets dat bestaat, met impact op wat er al draait. De flow is vergelijkbaar, de velden en de beoordelaars niet.
