8 tips voor een succesvolle samenwerking met je ontwikkelbureau
Op het moment dat je software of een app laat maken door een extern ontwikkelbureau, begin je met een omvangrijk en complex project. Om het succes van dat project zo groot mogelijk te maken, is een goede en transparante samenwerking met je ontwikkelbureau cruciaal. Hoe pak je dat aan?
De samenwerking met je ontwikkelbureau is voor een groot deel op vertrouwen gebaseerd; de kans is groot dat jij niet veel wijzer wordt van de code die zij schrijven en zij jouw bedrijfsvoering niet volledig begrijpen. Toch zijn er een aantal belangrijke aspecten binnen de samenwerking die je van tevoren goed kunt inrichten. Acht tips.
1. Vuistregel: een derde van je budget voor de eerste versie
Bij de ontwikkeling van je product, of dat nu software, een website of een app is, is het verstandig om je in eerste instantie te richten op een Minimum Viable Product, een MVP. De naam verklapt de betekenis al; een product dat aan de minimale eisen voldoet om te kunnen werken. De toeters en bellen laat je hierbij dus achterwege, het gaat erom dat het werkt.
Enerzijds zorg je er zo voor dat je de investering in je eerste versie zo laag mogelijk houdt. Anderzijds kun je wel al aan de slag met het product; werkt het goed? Wat mis je nog? Slaat het product aan? Je hebt nog twee derde van je budget over voor de verdere ontwikkeling. En als je aan de hand van die eerste versie besluit dat een andere oplossing beter bij de richting van je organisatie past of simpelweg meer oplevert, heb je nog een groot deel van je budget over om bij te sturen.
2. Vertel niet alleen wat je wilt, maar ook waar je behoefte vandaan komt
Vaak is de weg ernaartoe belangrijker dan het punt waar je op uitkomt. Hoe beter een ontwikkelbureau begrijpt waar jouw behoefte op is gebaseerd, hoe beter zij in staat is om het product goed op je organisatie af te stemmen. Leg dus uit waarom je een bepaalde wens hebt en welk doel daarbij hoort; wil je kosten besparen, een proces efficiënter maken, je omzet verhogen?
Zie het ontwikkelbureau maar als een architect die je huis gaat bouwen. Stel dat je de architect die jouw huis ontwerpt vertelt dat je veel bergruimte wilt, dan is het nog maar de vraag wat voor oplossing hij of zij daarvoor kiest. De kans bestaat dan dat je met een wijnkelder eindigt voor je collectie racefietsen.
3. Leer elkaar eerst kennen
Zie het als een huwelijk; toch wel fijn als je elkaar eerst goed kent voordat je elkaar het ja-woord geeft. Is er sprake van een cultuurclash? Een jong bedrijf dat zich graag afzet tegen de gevestigde orde is niet altijd de juiste partner voor een bureaucratische reus. Natuurlijk kun je van de verschillen in elkaars bedrijfscultuur leren, maar zorg ervoor dat het verschil niet zo groot is dat je elkaars processen niet begrijpt.
Bezoek elkaar dus eerst, in het echt. Leer elkaar en elkaars cultuur kennen. Speel een potje tafeltennis, vertel over de nieuwe gadgets die je hebt gekocht en ontdek wanneer de halve afdeling development op vakantie is. Gewoon omdat het fijn is om aanknopingspunten te hebben, je elkaar daarna niet meer alles hoeft uit te leggen en omdat je weet naar wie je moet vragen aan de telefoon op het moment dat je een vraag hebt.
4. Investeer in de conceptfase
Bij complexe (web)applicaties geldt dat één uur ontwerp doorgaans resulteert in acht tot zestien uur ontwikkeling. Dat leert je twee dingen. Eén: houd er rekening mee dat een kleine toevoeging aan het ontwerp meestal grote gevolgen heeft voor de ontwikkeling die nodig is. Twee: een ontwerp dat van tevoren niet helemaal goed uitgedacht is, leidt vaak tot grote budgetoverschrijdingen.
Met name in het geval van maatsoftware zorg je er daarom voor dat er een ontwerp ligt dat goed is uitgedacht, van begin tot eind, rekening houdend met elk mogelijk scenario en elke verre uithoek van het product. Echt overal rekening mee houden kun je nooit. Maar hoe nauwkeuriger het totaalplaatje van tevoren op tafel ligt, hoe beter de keuzes op het gebied van ontwerp, interactie en techniek gemaakt kunnen worden. En hoe rechter de koers richting de stip aan de horizon zal zijn.
5. Werk met sprints van twee weken
Of je nou scrumt of niet, zorg dat je in ieder geval met je ontwikkelbureau afstemt dat er in sprints van ongeveer twee weken wordt gewerkt. Daarbij spreek je af dat er aan het einde van elke sprint een deliverable wordt opgeleverd. Zo heb je als opdrachtgever veel meer inzicht in de voortgang van het project en kun je tussentijds testen en bijsturen: werkt het zoals je vooraf in gedachten had? Zijn er dingen die anders moeten? Of blijkt uit het testen dat er nog belangrijke dingen moeten worden toegevoegd of juist moeten worden weggelaten?
6. Bouw trust points in
Heb je elkaar het ja-woord gegeven? Ga er dan niet zomaar vanuit dat een ja-woord voor altijd geldt. Voor de zekerheid bouw je daarom trust points in; doorslaggevende punten in het proces waarop je met elkaar afspreekt om te evalueren. Je kunt tijdens die momenten bepalen of je nog steeds vertrouwen hebt in het ontwikkelbureau en bent daarbij vrij om voor de volgende stap naar een ander partij over te stappen.
Belangrijke voorwaarde daarbij is dat het ontwikkelbureau alles netjes documenteert. Want de reden dat je die trust points inbouwt, is dat je op dat moment kunt overstappen op een andere partij als dat nodig is. Dat andere ontwikkelbureau kan dan, met behulp van die documentatie, verder bouwen op dat wat er al is.
Bedenk dus welke deliverables (concrete stukjes van je product, klaar om te testen) aanleiding geven om tussentijds te evalueren. Dat zijn je trust points.
7. Derde partij voor een second opinion
Ondanks je weloverwogen keuze voor een bureau om je project te ontwikkelen en het vertrouwen dat je in dat bureau hebt, kan het geen kwaad om er een derde partij bij te betrekken voor een second opinion. Hoe groter het project, hoe groter het belang van zo’n derde partij. In het geval van maatsoftware bijvoorbeeld, zijn in veel gevallen al je klanten én al je werknemers afhankelijk van de kwaliteit van de software die je laat bouwen. Bovendien is het voor jou niet eenvoudig om te beoordelen of de code de kwaliteit in zich heeft die jij als organisatie nodig hebt.
Die derde partij kan een persoon zijn, of een bureau dat verstand heeft van het soort project dat je laat ontwikkelen. Het is altijd goed om een soort waakhond achter de hand te hebben die in geval van twijfel met je mee kan kijken en aan de bel trekt op het moment dat er slechte keuzes zijn gemaakt, de code kwalitatief niet goed in elkaar zit of een stuk software anders gebouwd had moeten worden.
Bijkomend voordeel is dat wanneer je tijdens de ontwikkeling van je project besluit dat je wilt overstappen naar een ander bureau, die derde partij je kan helpen bij de overdracht – of misschien zelf wel het project kan overnemen.
8. Offerte met deliverables en vaste prijs
Voordat je met de ontwikkeling van het project begint, wil je een duidelijke offerte. Zorg ervoor dat je een vaste prijs afspreekt; zo stimuleer je het ontwikkelbureau om een weloverwogen schatting van het aantal uren te maken en draag je het ondernemersrisico samen. Daarbij staat onderaan de streep van de volledige offerte een indicatieve prijs voor het hele project en per los onderdeel, één sprint per onderdeel, een vaste prijs. Mochten er extra onderdelen bijkomen tijdens de ontwikkeling van het project, dan beweegt de totaalprijs mee, maar van tevoren weet je precies wat je betaalt per onderdeel.
Optimale samenwerking, optimaal eindproduct
Pas je alle acht de tips toe? Je zult merken dat ze de samenwerking én het succes van je project ten goede komen. Zowel opdrachtgever als opdrachtnemer weten precies waar ze aan beginnen en starten met een gevoel van rust en overzichtelijkheid aan het project.
Heb jij nog meer tips om de samenwerking tussen opdrachtgever en opdrachtnemer te optimaliseren? Ik ben benieuwd, discussieer je mee in de reacties?
Afbeeldingen met dank aan 123RF.