Ontwikkelproces Innovaties
Van idee tot overdracht — het ontwikkelproces voor nieuwe educatieve producten
Van idee tot overdracht — het ontwikkelproces voor nieuwe educatieve producten
Dit proces is voor innovaties: iets ontwikkelen dat er nog niet is. Voor het maken en actualiseren van bestaande leermiddelen en examens gebruik je het productieproces, niet dit.
Twijfel je? Staat er aan het eind iets dat er nog niet was, dan hoort het hier. Gaat het om beter maken wat er al is, dan is het productie.
Deze lijn loopt niet naar een compleet product maar naar een MVP: een werkende eerste versie die echt in gebruik wordt genomen. De Must have-set uit de MoSCoW-prioritering (stap 2) is de scope van die versie; alles daarbuiten is niet afgewezen maar geagendeerd. Na de uitrol meet je met het evaluatieplan wat gebruikers werkelijk doen, en dát bepaalt de volgende ronde — de stippellijn onder de tijdlijn, van stap 5 terug naar stap 1. Blijkt er een substantiële uitbreiding nodig, dan is dat een nieuw initiatief met een nieuw akkoord op het startdocument.
Dat MVP lever je snel op en is bewust nog niet af. In stap 4 test je het daarna elke sprint met gebruikers en pas je het aan — tot de bevindingen klein en cosmetisch worden. Dát is het signaal dat het overdraagbaar is. Die sprints zijn jouw verantwoordelijkheid als proceseigenaar, niet die van Dienst Digitalisering: zij nemen het over als het uit-geïtereerd is.
Je legt je werk twee keer voor aan je leidinggevende, en die momenten staan niet als losse poort op de lijn maar sluiten de stap af waar ze bij horen. Ze zijn er om je ruimte en rugdekking te geven: je spreekt af wat je nodig hebt voordat je verder werkt. Het akkoord op het startdocument sluit stap 1 af en dekt het hele voortraject tot en met de Proof of Concept. Het akkoord op het concept sluit stap 3 af — het concept is dan met een werkend prototype bewezen, en de MVP-scope wordt vastgesteld.
Dat zijn de enige twee. Bouwen, beoordelen en overdragen gebeuren op dat tweede akkoord. De kwaliteitstoets in stap 4 is geen beslismoment maar een hoofdstuk van het Opleverdossier.
Elke stap levert één dossier op met precies één functie: de volgende persoon kan ermee verder. Het is geen verantwoording achteraf en geen archiefstuk. Bij elke stap staat een richtlijn voor de omvang — twee tot drie pagina's voor het startdocument, vijf tot acht voor de Product Backlog & het Programma van Eisen. Zit je daar ruim overheen, dan ben je waarschijnlijk aan het polijsten in plaats van aan het opleveren. Een sectie die niet van toepassing is, streep je door: dat is een antwoord, geen gat.
De methoden zijn een keuzelijst, geen checklist. Met de kiezer hieronder blijven de methoden die bij jouw omvang horen scherp en wordt de rest gedimd — je ziet dus wat je overslaat. De selectie is cumulatief: wat bij klein hoort doe je bij midden en groot ook.
Die indeling is richtinggevend, geen verplichting. Ze helpt je kiezen; ze schrijft niet voor. Ken je je project beter dan de kiezer, dan pak je wat je nodig hebt en laat je de rest staan — ook als dat afwijkt van je omvang. De op te leveren documenten liggen wél vast: elke stap sluit af met zijn dossier, ongeacht welke methoden je ervoor hebt gebruikt.
Elke stap sluit af met één definitief resultaat. Daardoor is de voortgang te volgen als stap + status op een KANBAN-bord: een stap is klaar als het dossier er ligt en — waar dat geldt — het akkoord is gegeven.
Hosting, beheer, monitoring, versiebeheer en support liggen na de release bij Dienst Digitalisering. Dat werk staat daarom niet in dit proces: jij doet het niet. Wat je wél doet is specificeren wat het technisch moet kunnen, toetsen of het prototype standhoudt, en aan het eind accepteren wat er is gebouwd.
Juist daarom zit Digitalisering vanaf stap 1 aan tafel. In het Programma van Eisen leg je in één tabel vast wat zij overnemen en met wie dat is afgesproken, zodat er aan het eind niets open blijft staan.
Dit proces volgt Agile/Scrum; de vijf stappen zijn genoemd naar de Scrum-cyclus. Het startdocument uit stap 1 is de productvisie en businesscase. In stap 2 bouw je de Product Backlog op: user stories, met MoSCoW geordend. Stap 3 is de Proof of Concept, in Scrum-termen Sprint 0: met een werkend prototype bewijs je dat het concept werkt. In stap 4 bouw je in sprints van 1–3 weken, en elke sprint levert een werkend increment op. Stap 5 is de release, met een evaluatie die bepaalt wat er in de volgende ronde op de backlog komt.
Elke sprint kent de vaste Scrum-events: Sprint Planning, Daily Scrum, Sprint Review met gebruikers en de Retrospective. Je vindt ze als methoden in stap 4, samen met de Definition of Done.
Rollen: de Product Owner bewaakt de waarde van het product en de volgorde van de backlog, de Scrum Master bewaakt het proces en ruimt blokkades op, en het ontwikkelteam bouwt. De projectleider bewaakt uren en planning richting je leidinggevende. De Product Owner en de projectleider worden bij het akkoord op het startdocument aangewezen. De twee akkoorden zijn de momenten waarop de organisatie bijstuurt; binnen de sprints stuurt het team zelf.
Bij een kleine innovatie hoeven dat geen drie mensen te zijn: één persoon mag Product Owner en projectleider tegelijk zijn, en de Scrum Master-rol kan bij een teamlid liggen. Houd dan wel de taken uit elkaar, zodat duidelijk blijft wie over de backlog beslist en wie het proces bewaakt.