Benieuwd hoe een project van klantvraag tot technische realisatie tot stand komt? En hoe je de keuze maakt voor technieken en bepaalde software? Wij ook! Daarom gingen we in gesprek met Proud Nerds. Zij bouwen webapps met complexe configuraties en maken digitale en interactieve producten, zoals maatwerk apps en websites. Daarin proberen ze altijd de ultieme user experience aan hun digitale producten mee te geven.
We spraken met Michiel Geurts (Business Consultant) en Sjoerd de Wildt (Senior Developer in het .NET team). Samen werkten zij onder andere aan de App to Order applicatie voor het Canisius Wilhelmina Ziekenhuis. Via deze applicatie kunnen OK-medewerkers eenvoudig en snel producten bijbestellen vanuit, jawel, de operatiekamer. In plaats van moeizame communicatie via portofoon is het OK-personeel nu slechts een paar eenvoudige kliks van de juiste bestelling verwijderd. Hoe zo’n proces van klantvraag tot technische realisatie in z’n werk gaat, dat lees je hier!
Op zoek naar het échte probleem
Voordat het team van Proud Nerds start met het bouwen van een applicatie, voeren ze een vooronderzoek uit. Samen met de opdrachtgever gaat de Business Consultant op zoek naar het échte probleem. Wanneer dit duidelijk is, weet de klant wat hij of zij kan verwachten en weet het Proud Nerds team wat ze moeten bouwen.
“Samen met de klant schets je op papier het product. Dat resulteert in een voorlopige lijst met technische en functionele requirements. Die lijst vertaal je naar User Stories. Hierin neem je ook een stukje wireframes en UX mee.”
Michiel Geurts, Business Consultant bij Proud Nerds
Van klantvraag naar technische realisatie
Bij een heldere probleemstelling hoort ook het in kaart brengen van mogelijke valkuilen. In het geval van A2O opperde het CWZ team zelf het idee van een bestelapp. Vervolgens brachten ze samen met het Proud Nerds team in kaart wat er gebeurt als je aan de voorkant ergens op klikt. En wanneer het dus aankomt op de logistiek. Want wat gebeurt er bijvoorbeeld wanneer de internetverbinding uitvalt? Welke statistieken wil je in kunnen zien? En wat doe je wanneer iemand een productnaam niet zeker weet? Door hierover te sparren, maak je alle randvoorwaarden inzichtelijk.
Verwachtingsmanagement met wireframes
Wanneer je een huis bouwt, kun je op de tekening redelijk duidelijk aangeven waar de voordeur en de ramen komen. Met een bouwtekening schets je een duidelijk beeld, wat voor de meeste niet-software developers tot de verbeelding spreekt. Wanneer het draait om software is dat wat abstracter. Sjoerd: “Wat ik vaak merk is dat opdrachtgevers het probleem helder hebben, alleen dat het lastig is wat het eindproduct wordt. Met wireframes proberen we dit in beeld te brengen. Pas wanneer het eindproduct in handen is, komen die wireframes tot leven bij de klant. Vanaf dat moment ga je verwachtingen bijsturen om te komen tot een oplossing.”
“Door gewoon te beginnen, tussentijdse reviews in te plannen en te blijven onderzoeken of we nog steeds op één lijn zitten, sturen we de verwachtingen steeds bij.”
Sjoerd de Wildt, Senior Developer in het .NET team bij Proud Nerds
Prototyping & Agile development
Dat ‘gewoon beginnen’ zit ook nog in iets anders. Michiel: “In het verleden schreven we bij software ontwikkelprojecten eerst alles uit: de watervalmethode. Dat was tijdsintensief en ging negen van de tien keer fout. Daarom ontwikkelden zich nieuwe methodieken, waaronder Agile development. Je schrijft het nog steeds op, maar zo grof mogelijk. Vervolgens lever je steeds een klein stukje op.” Dat gebeurde ook bij de ontwikkeling van A2O, waar het team tussentijds steeds prototypes opleverden tot aan de livegang. Vervolgens pasten ze het weer aan naar de verwachting en bleven ze steeds evalueren met het team van CWZ. Een schoolvoorbeeld van incrementeel verbeteren, noemt Michiel het.
“Bij A2O zetten we prototyping in: zo lean en mean mogelijk naar een Proof of Concept. Alleen in sprints werkten we naar het concept toe. Toen dat oké was, startten we met herbouwen.”
Michiel Geurts, Business Consultant bij Proud Nerds
De beste technische oplossing
Binnen het team van Sjoerd is het startpunt altijd het .NET framework. Binnen de Microsoft Stack kiezen zij op basis van de klantvraag en mogelijkheden wat er het beste past. Sjoerd: “In het geval van A2O wilden ze een app waarin ze konden zoeken naar instrumenten. Dit moest supersnel en responsive zijn, waarbij ze direct resultaten wilden zien.” Rond die tijd kwam ook een nieuwe tak van sport uit, namelijk Blazor (van Microsoft). Sjoerd: “Het voordeel van Blazor is dat het heel snel reageert en fijn werkt. Wanneer ze in de operatiekamer iets willen bestellen, heb je geen tijd om te wachten op een app die steeds terug moet naar de browser. Je wilt een app die op zichzelf werkt, daarin bood Blazor een uitkomst”
“In zekere zin hebben we de vrijheid om binnen onze kaders te bepalen wat we gebruiken. Uiteraard houd je hier rekening met de volwassenheid van de ondersteuning voor een bepaalde technologie.”
Sjoerd de Wildt, Senior Developer in het .NET team bij Proud Nerds
Doorontwikkeling na afronding project
Na oplevering van een applicatie of website, sluit het Proud Nerds team een project niet zomaar af. Alle wensen die tussentijds voorbij komen, zetten zij op de backlog. Na de livegang van een app of website komen deze punten opnieuw voorbij. Zo kijkt het team samen met de opdrachtgever aan welke doorontwikkeling op dat moment het meeste behoefte is. Michiel: “Ons doel is om de eindgebruiker altijd goed te dienen. Zo kunnen er nieuwe wensen vanuit ontwikkelingen in de markt of op technisch gebied ontstaan. Om daarop in te spelen is het belangrijk dat we blijven optimaliseren.”
Dat doet het team niet zomaar, Michiel vervolgt: “Binnen Proud Nerds hebben we alles in huis dat daarvoor nodig is. Samen met de klant denken we zorgvuldig na over de contentstructuur, veiligheid, customer journey, klantcommunicatie, enzovoorts. Vervolgens zetten we onze eigen teams van specialisten in om die doorontwikkeling te waarborgen.”
