Applicatie-development is te belangrijk om over te laten aan developers!

Marketeers zijn er een tijd geleden al mee geconfronteerd.

“Marketing is too important to be left to the marketing department.”
– David Packard, co-founder, Hewlett-Packard

Het combineren van prioriteiten gaat niet altijd goed samen. Een marketeer heeft in veel gevallen oog voor de eigen marketing-doelstellingen. Daarom is marketing voor kleine bedrijven juist zo goed uit te voeren door non-marketeers; die snappen het belang en de boodschap van het DNA van het bedrijf.

Development door developers

In veel situaties die ik tegenkom is hetzelfde te zeggen over developers. Een developer is iemand die problemen oplost en voorkomt, die logisch nadenkt en die processen in kleine deelprocessen opdeelt en behapbaar maakt. Een developer is vaak op de hoogte van het proces waarin de applicatie wordt gebruikt en kent de uitzonderingen.

Juist dat maakt een developer ongeschikt om een applicatie te ontwikkelen. Hieronder vijf redenen waarom een developer niet het laatste woord mag hebben in het ontwikkelen van de applicatie.

1. Developers maken niet graag fouten

Een developer denk vaak in code. Als […] dan […] of […]. En de taak is daar om fouten te voorkomen. Zo veel mogelijk logisch uitdenken, controleren en testen is een passende werkwijze. Dat werkt goed voor code, maar is funest voor user experience. Een gebruiker is vaak niet zo rigide als logica en breekt al snel de regels. Wat de developer weer kan voorkomen.

2. Developers mijden aanpassingen in bestaande code

Never change a winning team. Werkende code is al snel onbekend, fragiel of not invented here. Dus afblijven als het werkt, herschrijven als het beter moet. Maar bestaande code aanpassen? Liever niet. Want je weet maar nooit wat er gebeurt! Een kleine aanpassing? Dan is het beter de gebruiker op te voeden dan de user experience te verbeteren.

3. Developers denken in oplossingen

Een developer komt in actie als iets opgelost moet worden. Er toont iets verkeerds, iets niets of helemaal niets. Dus springt de developer in actie, kijkt naar de aangeleverde informatie en de gewenste output. Een oplosbaar probleem wordt gevormd. Vervolgens let de developer op het oplossen van het probleem en niet te lang op de context van het probleem.

4. Developers testen logica

Al aangestipt in punt één; developers werken in code. Ze testen logische handelingen en expressies. Gebruikers dienen dus aan deze logica te doen. Dat verklaart de uitgebreide handleidingen, instructiekaarten en trainingen om tools te kunnen gebruiken; gebruikers moeten de logica van de developers leren begrijpen.

5. Developers hebben trots

Laten we het beestje maar bij zijn naam noemen: ego. Developers zijn zelfverzekerd van de logische oplossing voor het geanalyseerde probleem. En dat heet trots. En als dit een tijd aanhoudt wordt het ego. Als de developer als een koning een eigen omgeving mag opbouwen en een paar problemen heeft opgelost is het risico voor diva-gedrag groot. Wiens applicatie is het eigenlijk? Van de developer of van de gebruiker?

En hoe dan wel?

Laat het ontwikkelen van een applicatie niet over aan een developer maar maak dit een groeps-product. Maak iemand verantwoordelijk voor field-testing, inventariseer gebruikerswensen, werk met persona’s om oplossingen in verschillende situaties te testen en vraag regelmatig af of iets een juiste oplossing is. Zorg dat iemand verantwoordelijk is voor gebruikers-acceptatie, die ook feedback kan geven naar de developers. Probeer zaken waarvan je overtuigd bent dat het niet werkt (en test je gelijk). Maar bovenal; blijf in contact met de gebruikers.