Ooit wel eens afgevraagd hoe wij over onze klanten denken tijdens een project? Vandaag ga ik een aantal van de best bewaarde geheimen onthullen.
“Waarom klagen ze nu al over het design, dit zijn alleen nog maar de wireframes”
In het ontwikkel proces zijn er een aantal fases die we zo veel mogelijk proberen te doorlopen.
- Concept
- UI/UX
- Design
- Development
- Testen
- Livegang
In de UI/UX-fase brengen wij de grote lijnen in kaart. Gebruiksgemak en de te gebruiken functionaliteiten staan hier centraal. Design speelt hier nog maar een minimale rol.
We houden tijdens het ontwikkelen van de wireframes dan ook nog geen rekening met pixel-perfect design. Het gaat ons puur om de flow en het gebruikersgemak.
Voor de klant
Maak je nog geen zorgen om het design. Feedback op de wireframes? Beargumenteer helder waarom jij gelooft dat andere keuzes beter zijn voor het eindresultaat. Durf ook bepaalde mogelijke keuzes uit te stellen tot na de eerste resultaten (lees: data) binnen zijn.
Voor het projectteam
Zorg altijd voor fysieke meetings tijdens feedbacksessies. Geef vooraf duidelijk aan wat de verwachtingen en de gewenste uitkomst van de meeting is. Beargumenteer en onderbouw je keuzes.
“Snapt de klant soms niet dat het tijd kost om iets te ontwikkelen?”
Bij Keytoe zijn we vaak met nieuwe ontwikkelingen bezig. We willen vooraan lopen en daarnaast uiteraard ook gewoon ‘schone’ code schrijven. Minimaal, maar met maximaal effect. Dit zorgt voor minder problemen en maakt het mogelijk om makkelijk op door te ontwikkelen.
Daarnaast kost het gewoonweg een hoop tijd. Neem het volgende voorbeeld:
Deze code zorgt enkel en alleen voor de volgende knop en zijn functionaliteit:
Wanneer je nagaat dat dit ook nog eens twee ‘talen’ zijn, HTML en Javascript, kun je misschien wel nagaan wat voor gigantische hoeveelheid code er moet worden geschreven om een heel platform te ontwikkelen.
Voor de klant
Ontwikkelaars doen echt hun uiterste best om effectiviteit met efficiëntie te combineren. Gun ze de tijd om iets te ontwikkelen. Houd er ook rekening mee dat het vooraf heel helder is wat je verwacht. Tussentijdse veranderingen zijn heel tijdrovend.
Voor het projectteam
Wees helder in de verwachtingen. Hoeveel werk is het om een platform te ontwikkelen. Spreek de taal die je onderling naar elkaar spreekt niet een-op-een naar de klant. Maak het voor hen duidelijk dat developer tijd kost en waarom het zoveel tijd kost.
“Waarom wil de klant altijd gelijk het ‘perfecte’ neer zetten?”
In de branche waarin wij werken is er dagelijks zo’n gigantische ontwikkeling gaande. Wat vandaag perfect is, is volgend kwartaal weer oud nieuws. Toch krijgen we met enige regelmaat de vraag vanuit de klant om in een keer een totaalplaatje neer te zetten. Een product wat jaren mee gaat. Wij snappen hier vaak de essentie; liever in een keer goed, dan staat het maar.
In de praktijk werkt het echter anders. Juist door die continue groei en innovatie binnen onze sector. Wij prediken daarom ‘lean en mean’. Om met andere vaktermen te smijten: Release early, release often*.
Waarom is dit zo interessant (lees: belangrijk)? Op de eerste plaats geeft dit de mogelijkheid om continu bezig te blijven met de ontwikkeling. Hierdoor blijf je scherp op de kwaliteit. Ten tweede breng je een risicomarge in. Je kunt een piramide beter met 100 blokken bouwen in plaats van één blok. Breekt je blok is heel je piramide naar de klote. Vergeet daarbij niet dat het ook nog eens slim naar je gebruikers toe is. Je houdt hen betrokken, je verrast ze steeds weer met nieuwe features en je geeft ze de tijd om te wennen aan het ‘nieuwe’. Op de laatste plaats is het ook kostentechnisch interessant. Je verspreidt de kosten. En doe je het goed, kun je de inkomsten uit eerdere releases gebruiken voor het bekostigen van je nieuwe releases.
Voor de klant
Zie het product wat je graag wilt als een lange termijn project. Door continu bezig te blijven met kleinere onderdelen binnen het totale product, kun je kwaliteit veel beter waarborgen en kosten veel beter spreiden. Neem van ons aan de ‘lean en mean’-methode in vrijwel alle gevallen de meest succesvolle methode is.
Voor het projectteam
Wees concreet in de voordelen van lean en mean ontwikkelen. Maak het helder met voorbeelden en geef inzichten in waarom het voor de klant beter is (kan zijn). Bespreek samen met de klant de mogelijke releases en hoe dat een win-win-win-situatie kan betekenen (Klant – Gebruiker – Keytoe).
De term ‘Release early, release often’ komt uit een essay (The Cathedral and the Bazaar) geschreven door Eric S. Raymond. Dit essay over software engineering-methodes, gebaseerd op zijn observaties van het ontwikkelingsproces van de Linuxkernel en zijn ervaringen met betrekking tot het opzetten en onderhouden van een opensource-project fetchmail. Het werd voor het eerst gepresenteerd door de auteur op het Linux Kongress op 27 mei 1997 en werd gepubliceerd als een deel van het gelijknamige boek in 1999. Het wordt dikwijls gezien als een manifest van de open source movement.
“Dat kan de klant toch prima zelf doen?”
Ons doel is om altijd een product op te leveren dat niet alleen gebruiksvriendelijk is voor de eindgebruiker, maar ook voor onze klant. We werken veelal met open-source platformen zoals WordPress. Deze kennen hun oorsprong uit een gebruiksvriendelijke interface, zodat ook de minder technisch aangelegde personen er mee kunnen werken.
Toch krijgen we vaak simpele vragen om het e.e.a. aan te passen. Bijvoorbeeld het verwisselen van een afbeelding, het aanpassen van tekst of het toevoegen van een extra pagina. Het zijn handelingen waar wij vaak van denken: ‘Dat kan de klant toch prima zelf?’
Voor de klant
Onze uren zijn duur. En het is zonde om die uren te moeten betalen, terwijl het werkzaamheden zijn die in sommige gevallen prima door jullie zelf opgelost kunnen worden. Uiteraard staan wij altijd klaar voor vragen en voor hulp. Kom je er niet uit? Let us know.
Voor het projectteam
Help de klant op gang met de handelingen die de klant zelf moet kunnen verrichten. Stel een helder document op met de handelingen en hoe deze te verrichten. Geef de klant een headstart en stimuleer de klant om het zelf te doen. Daar wordt de klant slimmer van.
Ons denken is niet alleen maar negatief
Ondanks dat wij wel eens klagen over, zouden we niet weten wat we zonder onze klanten moeten. Onze klanten geven ons de uitdagingen waar we beter en slimmer van worden, waar we echt het verschil kunnen maken en waar we uiteindelijk trots op zijn. En niet te vergeten; de klant betaalt ons salaris. Hierdoor kunnen wij elke dag weer doen wat wij zo graag doen. Digitale programma’s en concepten ontwerpen en ontwikkelen.
Veel kan voorkomen worden door heldere communicatie, duidelijke verwachtingen en een goede samenwerking.
En verder: Perfectie is een mooi doel om na te streven, maar wat vandaag perfect is, is morgen weer achterhaald. Blijf (door)ontwikkelen, vertrouw zowel op data als op je eigen gut-feeling.