CHI Nederland


12 april 1999

Consumentgerichte software-ontwikkeling bij Davilex

door: Yohan Creemers

Samenvatting

Davilex Software is producent/uitgever van Nederlandse consumentensoftware.

Dit verhaal wil een beeld geven van de manier waarop Davilex omgaat met conflicterende belangen tussen techniek, marketing en andere disciplines.

Door een sterke specialisatie van de functies wordt voorkomen dat één persoon conflicterende belangen moet dienen. De tegenstellingen tussen de vakgebieden wordt benut om binnen een productteam een optimale mix te krijgen tussen functionaliteit, techniek en marketing.

Het belang van de eindgebruiker blijft altijd als uitgangspunt dienen. De -uit de praktijk ontstane- ontwikkelmethodiek die binnen Davilex gehanteerd wordt start daarom bij de gebruiker en zijn doel. Tijdens het hele ontwikkeltraject waakt de methodiek over het realiseren van het gebruikersdoel.

De ontwikkelmethodiek beschrijft het hele traject van productidee tot after-sales. Alle disciplines zijn bij het hele traject betrokken.

Het teammodel en de ontwikkelmethodiek zijn voor Davilex belangrijke gereedschappen, die voortdurend evolueren. Het hebben van deze gereedschappen is echter geen garantie voor succes.

Introductie van Davilex

De Davilex formule

Davilex Software is opgericht in 1986 en opereert vanuit het Utrechtse Houten. Davilex is marktleider op het gebied van software voor de Nederlandse consumentenmarkt.
Davilex ontwikkelt software volgens een duidelijk herkenbare formule. Het uitgangspunt van alle producten is dat onze software vooral gemakkelijk en betaalbaar moet zijn. Bij de ontwikkeling van onze pakketten staan daarom criteria als bedieningsgemak, duidelijkheid, flair, professionaliteit Èn een interessante prijsstelling voorop.

De toekomst

Software moet zich verder aanpassen aan de gebruiker en zijn gedachtewereld. De huidige norm voor gebruiksvriendelijkheid zal uiteindelijk verlegd moeten worden naar een niveau waarbij de software de gebruiker begrijpt.

In 1998 heeft Davilex met de verkoop van meer dan één miljoen pakketten een omzet van 31 miljoen gulden gerealiseerd. Voor 1999 streven we naar een omzet van 40 miljoen gulden.

De doelstelling voor Davilex als bedrijf is om binnen vijf jaar uit te groeien tot een Europees A-merk.

Teammodel

Bij Davilex werken momenteel ruim 190 mensen. Hiervan valt de helft onder de afdeling Ontwikkeling.

De ontwikkeling van software is georganiseerd in acht productteams. Elk team werkt aan een aantal producten binnen een productreeks. Doordat alle disciplines vertegenwoordigd zijn, kan een team nagenoeg zelfstandig werken.

Door een sterke specialisatie van de functies wordt voorkomen dat één persoon conflicterende belangen moet dienen. De tegenstellingen tussen de disciplines wordt benut om binnen een productteam een optimale mix te krijgen tussen functionaliteit, techniek en marketing.

De 'onderhandelingen' met andere teamleden, dwingen elk teamlid om de juiste prioriteiten te stellen voor zijn vakgebied.

In onderstaande tabel staan de functies en hun verantwoording binnen het productteam.

Voor alle teamleden is de ontwikkeling van een zo goed mogelijk product voor de eindgebruiker het primaire doel. Alleen de invalshoek verschilt per teamlid.
FunctieVerantwoording
ProjectleiderPlanning en algehele kwaliteit
ProductmanagerCommerciële kwaliteit: aansluiting bij en succes in de markt
ProductontwerperFunctionele kwaliteit: usability, learnability en/of playability
Technical LeadTechnische kwaliteit
Graphical LeadGrafische kwaliteit
RedacteurTekstuele kwaliteit en realisatie van documentatie
Software OntwikkelaarRealisatie van programmacode
GraficusRealisatie van graphics

Ontwikkelmethodiek

Acht stappen zorgen ervoor dat, uitgaande van een productidee en een deadline, een goed product kan worden afgeleverd in de daarvoor beschikbare tijd.

Alle teamleden zijn bij alle fasen betrokken: als uitvoerende, als klankbord of als controlerende.

Stap 1: Bedenkfase

De Productmanager van het team signaleert trends en vragen uit de markt en vertaalt deze in productideeën. Hij kan daarbij gebruik maken van marktonderzoek in binnen- en buitenland, discussies met klantenpanels en terugkoppeling van distributeurs, verkoopafdeling, klantenservice en helpdesk.

In een Productplan beschrijft hij het productidee en alle marketinggerelateerde zaken tot en met featurelist. De featurelist bevat alle functionaliteit die gecommuniceerd kan worden aan de doelgroep. Als er sprake is van een koppeling met gegevens van derden, moet in het productplan al duidelijk worden hoe een dergelijke koppeling er uit zou moeten. Het productplan gaat als discussiestuk naar de teamleden en naar andere mensen binnen de organisatie (helpdesk, klantenservice). De Productmanager vraagt goedkeuring aan de Directie om het voorgestelde product te gaan ontwikkelen.

Stap 2: Opstartfase

De Projectleider inventariseert op basis van het Productplan de benodigde tijd en middelen en beschrijft de opzet voor het project in een Projectplan.

Het Projectplan vormt een contract tussen de Projectleider en de Productmanager. Het is bedoeld om duidelijkheid te scheppen over wat het project precies omvat, wanneer het afgerond moet zijn, wie er aan deel neemt, enzovoort.

Stap 3: Ontwerpfase

De Productontwerper schrijft op basis van het Productplan een Functioneel Ontwerp. Omdat hierin de usability, learnability en/of playability bepaald wordt, gaat dit verhaal hier wat dieper op in.
Doelgroepcollage
Doelgroepcollage
Het functioneel ontwerp begint met een analyse en karakterisering van de doelgroep die de Productmanager wil bedienen. Vervolgens wordt het doel van de doelgroep onderzocht.

Omdat wij ontwikkelen voor consumenten spreken we niet van taakanalyse, maar van doelanalyse. De gebruiker heeft een bepaald doel als hij het programma gaat gebruiken, bijvoorbeeld een mailing versturen naar klanten, iets leren of zich ontspannen.

Op dit moment in het ontwikkeltraject wordt nagedacht over de gebruiksvriendelijkheid, didactiek of gameplay: de middelen waarmee het doel zo goed mogelijk bereikt kan worden. Door de productfilosofie in het begin te benoemen, kan deze voor alle facetten van het product op een consistente manier de basis vormen.

Met de gebruiker en zijn doel in het achterhoofd wordt er bepaald wat het nieuwe product minimaal voor eigenschappen en functionaliteit moet bezitten. (Wat maakt een product bijvoorbeeld tot een racespel?) Dit levert het archetype op van het product dat we willen maken.

In de volgende synthesefase wordt het archetype uitgewerkt tot een product dat voldoet aan de Davilex filosofie: "Geniaal in gemak".

Teamleden, helpdesk en andere Productontwerpers geven op gezette momenten terugkoppeling op het Functioneel Ontwerp. Daarna wordt goedkeuring gevraagd aan de Directie om op de voorgestelde wijze door te gaan met de ontwikkeling.

Een drietal teamleden gaan nu aan de slag met het Functioneel Ontwerp. De Technical Lead maakt een Technisch Ontwerp, de Graphical Lead een Grafisch Ontwerp en de Redacteur maakt een opzet voor de documentatie.

Stap 4: Planningsfase

De Projectleider maakt aan de hand van de verschillende ontwerpen een detailplanning. In dit stadium van het project kunnen er geen features meer toegevoegd worden aan het product.

Stap 5: Implementatiefase

Het product wordt opgedeeld in functionele eenheden. Een functionele eenheid is een gedeelte van het programma dat in zijn geheel geïmplementeerd moeten worden, anders is deze functionaliteit niet bruikbaar. Aan de andere kant kan een functionele eenheid vaak in zijn geheel weggelaten worden, zonder dat daardoor het programma onbruikbaar wordt. Door een goede prioriteitstelling worden eerst de essentiÎle onderdelen gemaakt en kunnen de minst belangrijke in geval van tijdnood afvallen.

In het algemeen is elke discipline in het team betrokken bij een functionele eenheid.

De Productontwerper beschrijft de functionele facetten van een functionele eenheid, de Technical Lead vult de beschrijving aan met technische aspecten. Op dit punt komen conflicterende belangen het duidelijkst naar voren. Normaal gesproken wordt er bij conflicten een compromis gevonden. Anders beslist de Projectleider op basis van de verschillende verantwoordelijkheden. Vervolgens gaan een programmeur, graficus en redacteur het echte werk doen.

Wekelijks worden alle functionele eenheden die voor 100% af zijn, samengevoegd tot een nieuwe versie van het product in wording. Pas als een functionele eenheid goedgekeurd is, kunnen programmeur, graficus en redacteur aan een nieuwe eenheid beginnen.

Elke versie wordt getest op technische en functionele aspecten van de opgeleverde functionele eenheden. De productspecialist van de helpdesk vervult een belangrijke rol bij het testen. Gevonden fouten moeten de week erna verholpen worden. Deze manier van werken levert een beheersbaar proces op. Een bijkomend voordeel is, dat er al relatief snel een versie op de plank ligt die geschikt is voor het doel van de gebruiker.

Stap 6: Testfase

Na de 'visual and functional freeze' wordt er alleen nog getest en verbeterd. De technische tests vinden met name plaats is een speciaal testlab. Voor functionele tests worden mensen uit de doelgroep gevraagd om een bètaversie van het product uit te proberen.

Stap 7: Afrondfase

Een van de vele praktische zaken die in de afrondfase moeten plaatsvinden is de presentatie van het product aan de helpdesk en verkoopafdeling, zodat zij onze klanten goed kunnen informeren.

Stap 8: Nazorgfase

De nazorg richting de klant wordt verzorgd door de helpdesk en klantenservice.

Vanaf de release van het product tot aan de release van een nieuwe versie is er contact tussen helpdesk en het ontwikkelteam. De helpdesk voorziet het team van informatie over wensen en problemen van gebruikers. Het ontwikkelteam ondersteunt bij het oplossen van technische problemen en maakt indien nodig een update.

De informatie uit de nazorgfase vormt vaak de basis voor de bedenkfase van een nieuw product, dat nog beter voldoet aan de veranderende eisen van de consument.


Davilex Software

Postbus 174, 3990 DD Houten
Internet: www.davilex.nl
T: (030) 635 42 22