Wat je een softwareontwikkelbureau moet vragen voordat je tekent

Een ontwikkelbureau kiezen is een beslissing die de meeste bedrijven maar een handvol keer in hun bestaan nemen, wat betekent dat de meeste kopers iets beoordelen waar ze weinig oefening in hebben. Dit is de checklist met vragen die wij vinden dat een koper daadwerkelijk zou moeten stellen, inclusief de vragen die enigszins ongemakkelijk zijn om rechtstreeks te stellen, want de ongemakkelijke vragen blijken meestal het nuttigst.

Wie specifiek aan mijn project werkt, met naam en rol, niet alleen wie er in het verkoopgesprek zit. Het komt vaak voor dat een sterk team een project pitcht en een ander, junior team het uiteindelijk bemenst. Vraag rechtstreeks of de mensen in de kamer degenen zijn die de code gaan schrijven, en als het eerlijke antwoord nee is, vraag wie dat dan wel zijn en hoe hun ervaring eruitziet.

Kan ik rechtstreeks met een huidige of recente klant praten, geen testimonial lezen die voor de website is geschreven. Een gepolijst citaat op een landingspagina vertelt je dat het bureau een goed citaat kan schrijven. Een rechtstreeks gesprek met een referentie, waar je kunt vragen naar gemiste deadlines, hoe scopewijzigingen daadwerkelijk werden afgehandeld, en of ze het bureau opnieuw zouden inhuren, vertelt je iets dat een testimonial niet kan. Een bureau dat vertrouwen heeft in zijn werk zou het comfortabel moeten vinden om je te verbinden.

Wat gebeurt er met de code, omgevingen en accounts na afloop van het traject, besloten voordat het traject begint, niet onderhandeld erna. Vraag specifiek: krijg je toegang tot dezelfde repositories, cloudaccounts en omgevingen die zijn gebruikt om het systeem te bouwen, of behoudt het bureau toegang die je later zou moeten opvragen? Een bureau dat dit als een vanzelfsprekend ja behandelt, natuurlijk bezit je wat je hebt betaald, geeft een ander antwoord dan een bureau dat daar vaag over blijft.

Hoe ga je om met scopewijzigingen en gemiste schattingen, want elk echt project krijgt daar uiteindelijk mee te maken, en hoe een bureau dit beantwoordt voordat je hebt getekend, vertelt je meer dan hoe zelfverzekerd ze een vaste tijdlijn offreren. Vraag naar hun daadwerkelijke proces, gefaseerde mijlpalen, afhandeling van wijzigingsverzoeken, hoe communicatie werkt wanneer iets achterloopt, in plaats van "we houden je op de hoogte" als volledig antwoord te accepteren.

Hoe ziet de daadwerkelijke beschikbaarheid en communicatiecadans van het team er dagelijks uit, niet alleen bij de kick-off. Vraag hoe vaak je echte updates krijgt, of je toegang hebt tot een stagingomgeving om zelf voortgang te zien, en wie je specifieke aanspreekpunt is wanneer iets snel een antwoord nodig heeft. Vage antwoorden hier voorspellen vaak hoe communicatie er drie maanden in het project daadwerkelijk uitziet.

Wat is jullie ervaring specifiek met projecten zoals het mijne, niet alleen softwareontwikkeling in brede zin. Een team dat tien interne dashboards heeft gebouwd voor logistieke bedrijven brengt patroongestuurd inzicht naar een elfde dat een team dat nog nooit zoiets heeft gebouwd niet heeft, ongeacht hoe bekwaam ze in het algemeen zijn. Vraag om specifieke, vergelijkbare voorbeelden, niet een algemene capaciteitenpitch.

We voegen er nog één aan toe, want we krijgen hem vaak genoeg gesteld om het rechtstreeks te zeggen: vraag een bureau om je te verbinden met een referentie in plaats van te vertrouwen op testimonials, en wees achterdochtig bij een bureau dat dat niet kan of wil. Wij bieden precies dat, rechtstreekse gesprekken met klanten in plaats van uitgekozen citaten, omdat een koper die een bureau beoordeelt waar hij maandenlang mee gaat samenwerken een beter signaal verdient dan marketingtekst, en we winnen liever de opdracht op basis van een echt gesprek dan op een gepolijste testimonial, hoe dan ook.