Menu

Software-ontwikkeling samen met de klant

HP Hans-Peter Harmsen heeft dit geschreven in september 2015

Bij Oberon hebben wij in onze missie staan dat we samen met onze klanten betere online producten ontwikkelen. Dat woordje samen is cruciaal want dat duidt op een groot verschil met de traditionele manier van softwareontwikkeling.


Bij Oberon hebben wij in onze missie staan dat we samen met onze klanten betere online producten ontwikkelen. Dat woordje samen is cruciaal want dat duidt op een groot verschil met de traditionele manier van softwareontwikkeling.

In deze whitepaper het waarom, wat de verschillen zijn met de traditionele manier van werken, en wat dat aan werkzaamheden betekent voor de klant.

Waarom software ontwikkelen samen met de klant?

In het kort: omdat het leidt tot een beter resultaat.

Software ontwikkelen samen met de klant betekent dat je gezamenlijk een project aan gaat; de klant is deel van het team. Zij heeft een plek in de ruimte waar de ontwikkelaars zitten en is aanwezig bij de projectmeetings. Dit betekent niet dat ze per se elke dag aanwezig moet zijn maar ze is er wel vaak. Ze levert input en sturing aan het team.

In het verleden ging dit anders. De klant kwam met een wens, wij als ontwikkelaar interpreteerden deze wens en maakten een offerte. Vervolgens gingen we aan de slag om het afgesprokene te bouwen. Natuurlijk waren er tussentijdse opleveringen maar die waren eerder een bron van problemen dan een oplossing. Zoals dat gaat met de ontwikkeling van een nieuw product ontdekte de klant dat dat zij toch iets anders wilde of dat er nog iets miste. Dit leidde tot extra werk voor ons (we hadden dingen voor niks gedaan) of bijbegrotingen voor de klant. Geen van beide prettig.

"Walking on water and developing software from a specification are easy if both are frozen."

In het samenwerkingsmodel gaat het anders. Omdat de klant veel aanwezig is, kan ze direct aangeven wat er belangrijk is en welke onderdelen minder prioriteit hebben. Ze is direct beschikbaar voor vragen van de ontwikkelaars en kan daarmee een boel onduidelijkheden wegnemen. Dit levert een eindproduct op dat veel beter aansluit bij de wensen van haar organisatie.

Flexibele scope

Een van de dingen die het samenwerken met de klant mogelijk maakt is het werken met een flexibele scope. Je timmert niet meer van te voren alles dicht maar je werkt samen naar een zo ideaal mogelijk eindproduct.

Leiden nieuwe inzichten tot nieuwe wensen? Dan kan dat per direct opgepakt worden in het project. De klant is er bij; en zij beslist. Dat dit vaak betekent dat andere features dan afvallen, is meestal helemaal niet erg.

De flexibele scope en het op dagelijkse basis samenwerken van de 'business' mensen en de ontwikkelaars zijn beiden onderdeel van de agile filosofie. Zie kader. Bij Oberon werken we graag agile. Meestal gebruiken we daar scrum http://www.oberon.nl/whitepaper/11_scrum/ voor maar dat hoeft niet. Er zijn ook andere agile ontwikkelmethodes waarin de ontwikkelaars samen met de klant optrekken zoals Extreme Programming http://nl.wikipedia.org/wiki/Extreme_programming en DSDM http://nl.wikipedia.org/wiki/Dynamic_systems_development_method.

Wat doet de klant concreet in een project?

Wat de klant precies doet in het project verschilt. Dat hangt af van het project en van haar competenties. De volgende dingen horen hier in ieder geval bij:

Het aangeven van prioriteiten
De klant geeft aan welke onderdelen er echt belangrijk zijn en welke minder prioriteit hebben. Dat is een doorlopend proces want prioriteiten kunnen altijd veranderen. Bij scrum is dit de rol van de product owner http://www.oberon.nl/whitepaper/13_de_ideale_product_owner/.

Beschikbaar zijn voor vragen
Natuurlijk zijn er allerlei communicatiemiddelen om op afstand vragen te stellen. Maar dat is toch niet hetzelfde als face-to-face communicatie. Tijdens een project komt een ontwikkelaar honderden kleine dilemma's tegen. "Moet de gebruiker hier een bevestiging van krijgen?", "Is dit de juiste stijl?", "Wil je hier nog uitleg bij?", "Hoe zullen we het inloggen doen?" etc. etc. Even vragen aan iemand die aanwezig is, is zo gedaan maar mailen en dan wachten op het antwoord zorgt voor vertragingen; de ontwikkelaar zit vast.

Zorgen dat de juiste input er is
Een team heeft altijd input nodig die vanuit de organisatie van de klant moet komen. Voorbeelden hiervan zijn testdata, accountgegevens, prijslijsten etc. Maar je moet ook denken aan teksten die op de site of in de applicatie moeten komen en meldingen die getoond moeten worden.

Beslissingen nemen
Tenslotte kan de klant beslissingen nemen in het traject of in ieder geval regelen dat die beslissingen verderop in de organisatie genomen worden. Hierdoor kan het team snel door met de juiste werkzaamheden.

Waar dat handig is, kan een klant het team ook andere dingen uit handen nemen zoals testen, copywriting en data-invoer.


Bezwaren

Voor veel klanten is deze manier van werken een behoorlijke verandering ten opzichte van wat ze gewend zijn. Dat leidt wel eens tot tegenwerpingen. Hierbij een aantal:

Dat kost me te veel tijd.
Ja, het kost tijd. Dat is gewoon waar. Maar die investering levert het dubbel en dwars op doordat je een veel beter product krijgt.

Zo weet je van tevoren niet precies wat je uiteindelijk krijgt.
Klopt. Maar je weet wel dat wát je krijgt, precies is wat je wilt hebben.

Leuk die flexibele scope maar wat nou met de onderdelen die aan het eind niet af zijn?
Wat belangrijk is, is wel af. En meer dan dat! Een aantal nieuwe features die pas later naar voren zijn gekomen zijn ook al af. Daar ben je zelf bij.

Conclusie

Een gezamenlijke projectaanpak tussen klant en ontwikkelteam heeft drie grote voordelen:

1. Doordat de klant aanwezig is voor vragen en zelf direct kan bijsturen is het eindresultaat veel beter.

2. Omdat er geen onnodige features worden ontwikkeld of onderdelen die later toch weer anders moeten, wordt het ontwikkelbudget efficiënter besteed.

3. Samen een mooi product maken leidt tot enthousiaste reacties. Het ontwikkelteam is er blij mee en de klant is er blij mee. Klanten zitten daarom graag bij ons. Het werkt fijn, het is altijd duidelijk hoe het gaat met het project en het eindresultaat wordt er veel beter van.

HP

Hans-Peter Harmsen

MANAGEMENT

Oprichter en managing director; verantwoordelijk voor grote accounts en strategie.

E-mail:
hph@oberon.nl
Telefoon:
+31 654 337 275

“We maken samen met onze klanten betere online producten, zowel voor het web als in mobiele apps”

Meer informatie op Oberon.nl