Ga voordat je een softwarepartner inschakelt precies na wie de code schrijft, welke vergelijkbare systemen ze hebben opgeleverd, hoe scope en acceptatie worden vastgelegd en wie vanaf de eerste dag eigenaar is van de code. Vage antwoorden op een van deze vragen zijn een sterker waarschuwingssignaal dan een hoge prijs.
Zoek uit wie de code echt gaat schrijven
De mensen in het verkoopgesprek zijn vaak niet de mensen die je systeem bouwen. Vraag naar de namen, rollen en ervaring van de engineers die aan het project gaan werken, en vraag om een gesprek met de technisch lead voordat je tekent.
Vraag of er werk wordt uitbesteed of door freelancers wordt gedaan. Beide kunnen goed werken, maar je moet het weten, en de partner moet instaan voor iedereen die hij inzet. Vraag ook wat er gebeurt als een sleutelfiguur halverwege het project vertrekt, en wie de inwerktijd van een vervanger betaalt.
- Wie is de technisch lead, en hoeveel van zijn of haar tijd gaat naar dit project?
- Welke engineers zijn in dienst, en welke zijn onderaannemers of freelancers?
- Hoe selecteer en controleer je de specialisten die je inzet?
- Wat is de procedure als iemand vertrekt of niet goed past?
Vraag naar een trackrecord dat bij jouw probleem past
Een lange lijst met klanten zegt weinig als niets ervan op jouw project lijkt. Vraag naar voorbeelden met vergelijkbare randvoorwaarden: hetzelfde soort systeem, vergelijkbaar verkeer of even gevoelige data, en een vergelijkbare regelgevende context. Vraag daarna wat dit team in elk geval deed, niet wat het programma van de klant als geheel bereikte.
Wees precies over wiens ervaring je inkoopt. Sommige bedrijven presenteren het individuele trackrecord van hun engineers, en dat is legitiem als het eerlijk wordt vermeld. Vraag wanneer het bedrijf is opgericht, welk werk onder eigen contracten is gedaan en of je een eerdere klant kunt spreken.
Leg scope, mijlpalen en acceptatie schriftelijk vast
Veel geschillen komen voort uit een scope die nooit precies is opgeschreven. Een goed voorstel noemt de op te leveren resultaten, deelt het werk op in mijlpalen en legt vast hoe elke mijlpaal wordt geaccepteerd, bijvoorbeeld tests die slagen, een demo op een stagingomgeving of opgeleverde documentatie.
Vraag hoe wijzigingsverzoeken worden behandeld en geprijsd, en wat het commerciële model is. Een vaste prijs past bij goed omschreven werk, regie (time and materials) bij verkenning en eisen die zich nog ontwikkelen. Hoe dan ook moet je de aannames achter de schatting kunnen zien.
Regel het eigendom van de code en de overdracht voordat je begint
In het contract moet staan dat jij eigenaar bent van de code en het bijbehorende intellectuele eigendom, en vanaf wanneer dat eigendom overgaat. Vraag om repositories, cloudaccounts en domeinen vanaf de eerste dag in jouw organisatie aan te maken, met de partner als uitgenodigde medewerker, zodat je nooit van hem afhankelijk bent voor toegang.
Plan de overdracht aan het begin, niet aan het eind. Vraag wat je krijgt: documentatie, vastgelegde architectuurbeslissingen, runbooks voor het beheer en werksessies met je eigen team. Controleer welke licenties van derden en open source het project gebruikt, want daar horen verplichtingen bij.
Spreek af hoe je de voortgang te zien krijgt
Je zou nooit hoeven te vragen of het project op schema ligt. Spreek een vast ritme af, zoals een wekelijkse demo van werkende software en een korte schriftelijke status over voortgang, risico's en beslissingen die van jou nodig zijn.
Vraag om directe toegang tot de issuetracker en de repository, en om één vaste contactpersoon die verantwoordelijk is voor de oplevering. Maak duidelijk hoe problemen worden geëscaleerd en hoe snel je een reactie kunt verwachten.
Toets hun beveiligingspraktijk, niet hun keurmerken
Vraag hoe engineers toegang krijgen tot je systemen en data, hoe geheimen worden bewaard, hoe code wordt gereviewd voordat hij live gaat en hoe dependencies worden gecontroleerd op bekende kwetsbaarheden. Concrete antwoorden zeggen meer dan een slide vol logo's.
Gaat de partner namens jou persoonsgegevens verwerken, dan heb je een verwerkersovereenkomst nodig die aan de eisen van de AVG voldoet. Claimt een leverancier een certificering, vraag dan om het certificaat en de reikwijdte ervan, en controleer of het het team en de diensten dekt die je inkoopt.
Alarmsignalen waarbij je het gesprek beter stopt
Eén waarschuwingssignaal kan een verklaring hebben. Meerdere tegelijk betekenen meestal dat het project moeilijker wordt dan nodig.
- Ze kunnen de engineers die het werk gaan doen niet bij naam noemen.
- Casestudy's tonen resultaten, maar niet wat dit team zelf deed.
- De schatting komt binnen voordat iemand gedetailleerde vragen over je systeem heeft gesteld.
- Repositories en cloudaccounts blijven onder beheer van de partner.
- Mijlpalen hebben geen schriftelijke acceptatiecriteria.
- Op beveiligingsvragen volgt een algemene geruststelling in plaats van concrete werkwijzen.
De kern
- Spreek de technisch lead en weet wie de code schrijft voordat je tekent.
- Beoordeel een trackrecord op hoe goed het bij jouw randvoorwaarden past en op wat het team zelf deed.
- Schriftelijke mijlpalen met duidelijke acceptatiecriteria voorkomen veel discussie over de scope.
- Houd repositories en cloudaccounts vanaf de eerste dag in je eigen organisatie.
- Vraag naar concrete beveiligingspraktijken en naar bewijs voor elke certificering die een leverancier claimt.
Veelgestelde vragen
Met hoeveel partners praat je voordat je kiest?
Met genoeg om echte verschillen in aanpak te kunnen vergelijken, wat voor de meeste projecten neerkomt op een paar. Geef ze allemaal dezelfde briefing en dezelfde vragen, zodat de antwoorden vergelijkbaar zijn.
Kies je een contract met vaste prijs of op regiebasis?
Een vaste prijs past bij werk dat je vooraf in detail kunt specificeren. Regie (time and materials) past bij verkenning, eisen die zich ontwikkelen en doorlopende ontwikkeling, mits je transparante rapportages en regelmatige demo's krijgt.
Wat bespreek je in een eerste gesprek met een mogelijke partner?
Je doel, je randvoorwaarden, je planning en je bestaande systemen, en hun vragen aan jou. Een partner die in het eerste gesprek gedetailleerde vragen over je systeem stelt, maakt meestal ook een eerlijke schatting. Bij SDK Enterprises is dat eerste gesprek een gesprek van 30 minuten in het Frans of het Engels.