Hoe gaan wij van jouw wens naar onze oplossing? Door stapsgewijs jouw wensen te concretiseren en deze uit te werken in een applicatie die precies doet wat jij wil. En hoe we dat precies doen? We leggen je onze werkwijze graag uit op deze pagina.
Eerste gesprek
Het begint natuurlijk met jouw behoefte. Jij wil iets en je denkt dat wij dé partner zijn die jou verder kan helpen. Mooi, dan is het tijd voor een goed gesprek! We maken kennis met jou als klant via bijvoorbeeld een account- of projectmanager. We stellen een aantal vragen, zodat we weten waar precies de behoefte ligt. Op basis hiervan bepalen we of er een ontwikkelaar moet bijkomen of dat we zo al weten hoe dit technisch haalbaar is.
Dit eerste gesprek heeft als doel niet alleen om kennis te maken, maar voor de projectmanager ook om hun huidige procesflow in kaart te brengen. Op basis van jullie situatie nu kunnen wij gaan nadenken over een nieuwe procesflow waarin we zoveel mogelijk kunnen automatiseren.
Mocht het wederzijds klikken dan gaan we graag de samenwerking aan! Dat doen we op basis van wederzijds vertrouwen. En dat bestaat bijvoorbeeld uit het simpele feit dat als jij iets wil wat al bestaat, we je niet onnodig kosten laten maken, maar gewoon doorverwijzen naar een bestaande oplossing. Wel zo fijn.
Als alle seinen op groen staan dan gaan we snel verder. We verwerken de klantbehoefte en vatten die samen op papier. En dan is het tijd voor nóg een gesprek.
Tweede gesprek
Het tweede gesprek is vaak wat technischer van aard. Mocht dat nodig zijn, dan voegt één van onze ontwikkelaars zich bij het gesprek om de klantwens – met name op technisch vlak – nog beter uit te vragen. We verzamelen genoeg input, want hierna is het tijd voor ons onderzoek.
Onderzoek
In ons onderzoek beginnen we altijd met een procesflow. Daarna starten we met het opstellen van de requirements. Deze eisen ordenen we op basis van prioriteit volgens de MoSCoW-methode:
| Must-haves | Deze eisen moeten per se terugkomen in de oplossing |
| Should-haves | Deze eisen zijn erg gewenst, maar het product kán ook zonder |
| Could-haves | Deze eisen worden alleen verwerkt als er tijd over is |
| Won’t-haves | Deze eisen worden niet ingewilligd, maar zijn mogelijk interessant in de toekomst |
Op basis van deze requirements stellen we een globale tijdsindicatie op, waarbij er uiteraard ook een indicatie wordt gemaakt per requirement. Van hieruit stellen we een globale planning op, zodat je weet wat je kan verwachten.
Look and feel
Als onderdeel van ons onderzoek zullen we je ook alvast een look and feel meegeven. Met hulp van onze design-afdeling maken we bijvoorbeeld de adminpagina op in jullie stijl, zodat je weet hoe de applicatie er uiteindelijk zou kunnen uitzien.
Daarnaast leggen we vast welke eventuele externe koppelingen er nodig zijn om jouw behoefte optimaal te kunnen bevredigen. Denk bijvoorbeeld aan een koppeling met jullie facturatiesysteem.
Als we een principeakkoord hebben op de urenindicatie gaan we verder met het maken van een functioneel ontwerp (FO).
Functioneel ontwerp
In een functioneel ontwerp leggen we per scherm uit wat de functies zijn op dat scherm of die pagina. Bij geavanceerde processen presenteren we ook een flowchart met daarin alle stappen die worden genomen tijdens zo’n proces.
Procesflow
Een procesflow beschrijft de werking van de app of applicatie. Hierin geven we op schematische en overzichtelijke wijze weer wat er precies gebeurt als de gebruiker een bepaalde handeling uitvoert. Zie bijvoorbeeld de procesflow van de ID-check vanuit de DigiD-app:
Per scherm tonen we je de uitwerking van de requirements en geven we een toelichting waarom we het zo doen. We zullen alles benoemen, zodat het voor beide partijen duidelijk is waar er precies aan gewerkt gaat worden. Zo komt niemand voor verrassingen te staan en dat werkt wel zo fijn.
In principe komen we per scherm met een wireframe, waardoor het makkelijk en snel feedback geven is. Mocht je nou wel al een ontwerp per scherm willen zien, dan is dat ook mogelijk.
Risicoanalyse
Een vast onderdeel van ons functioneel ontwerp is een risicoanalyse. Hierin maken we een beschrijving van de eventuele risico’s. Denk bijvoorbeeld aan een koppeling met een bepaald systeem. Want op basis van zo’n koppeling maken we een urenindicatie, ervan uitgaande dat die koppeling ook werkt! Helaas komt het in de praktijk wel eens voor dat dit niet altijd zo blijkt te zijn. Wederom om verrassingen te voorkomen zullen we dit soort mogelijke scenario’s tijdens ons onderzoek al in kaart brengen.
Om het aantal mogelijke risico’s zo veel mogelijk te beperken zijn we tijdens deze onderzoeksfase graag op de hoogte van álle koppelingen waar de applicatie mee moet werken. We snappen dat dit aardig wat vertrouwen vraagt, juist in deze fase, maar het is wel iets waar we beiden later veel aan hebben.
Als het onderzoek helemaal is afgerond, dan is het tijd voor de ontwikkelaars om de handen uit de mouwen te steken. Tijd om te programmeren!
Start ontwikkeling
Het functioneel ontwerp is bedoeld voor het hele project, maar de ontwikkeling gebeurt bij ons in sprints. Hiervoor maken we gebruik van projectsoft ware Jira, waarmee je ook op de hoogte wordt gehouden van alle ontwikkelingen. Meer weten? Lees dan verder over hoe wij werken met Jira.
Sprints
Aan het begin van een sprint bepalen we gezamenlijk aan welke functionaliteiten er wordt gewerkt binnen die sprint. Samen met de ontwikkelaars vullen we de backlog, een lijst met functionaliteiten en taken die door de ontwikkelaars wordt uitgevoerd.
Aan de start van een nieuwe sprint wordt er teruggekeken naar de voltooide (of in ontwikkeling zijnde) werkzaamheden van de vorige sprint en is er ruimte om feedback te geven. En op deze manier werken we van sprint naar sprint tot het eind in zicht is!
Bespreek je wensen met ons!
Zie jij onze werkwijze wel zitten en wil je met ons om de tafel gaan zitten om jouw wensen te bespreken voor een webapplicatie, webshop of mobiele app die jouw bedrijfsprocessen écht efficiënter maakt? Neem dan vandaag nog contact met ons op!
