Hoe schrijf je een goede briefing voor maatwerk software?

Je hebt een idee voor maatwerk software. Of eigenlijk meer dan een idee, je hebt een probleem dat je opgelost wilt hebben. Je zoekt een developer, stuurt een mail, en dan? Dan begint het briefen. En daar gaat het bij de meeste projecten al mis.

Niet bij het bouwen. Bij het briefen.

Ik heb in 25 jaar honderden briefings voorbij zien komen. Van twee zinnen in een WhatsApp-bericht tot PDF's van vijftig pagina's met wireframes en al. De lengte zegt niks. Ik heb fantastische projecten gedraaid op basis van een half A4'tje, en rampprojecten gezien die begonnen met een keurig dossier.

Je beschrijft een oplossing. Doe dat niet.

Dit is de fout die ik het vaakst tegenkom. Iemand mailt: "Ik wil een app waarmee klanten kunnen inloggen en hun bestellingen volgen." Prima. Maar waarom?

Misschien bellen klanten je tien keer per dag waar hun pakketje is. Misschien haken mensen af in je bestelproces en kost je dat omzet. Dat zijn twee compleet verschillende problemen met compleet verschillende oplossingen.

Als ik weet dat het gaat om "klanten bellen te vaak over bezorging", dan kan ik meedenken. Misschien is een koppeling met je verzendsoftware die automatisch een track-and-trace mailt het enige wat je nodig hebt. Geen portal, geen inlogscherm. Scheelt je tienduizend euro.

Maar dat kan ik alleen bedenken als je me vertelt wat het probleem is. Niet wat je denkt dat de oplossing moet zijn.

Twee A4'tjes. Meer hoeft het niet te zijn.

Ik merk dat mensen opzien tegen het schrijven van een briefing. Alsof het een projectplan moet zijn. Dat hoeft niet. Twee tot drie A4'tjes met de juiste informatie is genoeg.

Wat erin moet: een stukje over je bedrijf. Niet je hele geschiedenis, maar genoeg zodat ik snap waar je zit. Tien bestellingen per dag is een ander verhaal dan duizend. Een webshop die vooral aan particulieren levert, werkt anders dan een B2B-platform met contractprijzen en goedkeuringsflows.

Dan je huidige situatie. Werk je nu met Excel? Met een pakket dat niet meer doet wat je wilt? Heb je al software draaien die aangepast moet worden? Ik heb eerder geschreven over wanneer aanpassen duurder wordt dan opnieuw bouwen. Die afweging begint hier, bij een eerlijke blik op wat je nu hebt.

En dan je doelstellingen. In resultaten, niet in features. "Ik wil dat klanten zelf hun retourzending regelen" werkt. "Ik wil een retourmodule met een formulier, een dropdown voor de reden, en een koppeling naar PostNL" werkt niet. Het eerste geeft mij ruimte om mee te denken. Het tweede maakt me een typist.

Vertel me wie ermee moet werken

Dit vergeten mensen bijna altijd. Ze beschrijven wát ze willen, maar niet wie het moet gaan gebruiken.

Een buitendienstmedewerker die in de auto op zijn telefoon snel iets moet invoeren is een totaal ander uitgangspunt dan een administratief medewerker die de hele dag achter twee schermen zit. Die context bepaalt keuzes die je later niet meer makkelijk terugdraait.

En vergeet de mensen op de achtergrond niet. De directie die rapportages wil zien. De IT-beheerder die het ding moet hosten. De boekhouder die een export nodig heeft. Die wensen komen er toch, het liefst aan het begin in plaats van halverwege.

Noem een budget. Echt.

Hier lopen veel opdrachtgevers omheen. Snap ik. Je bent bang dat als je een bedrag noemt, ik precies op dat bedrag ga zitten. Maar het tegenovergestelde is waar. Als ik niet weet of je tienduizend of honderdduizend in gedachten hebt, kan ik niks.

Het verschil is als naar een autodealer stappen en zeggen "ik wil een auto" zonder te vertellen of je aan een Polo of een Porsche denkt. Een bandbreedte is genoeg. Het helpt mij om te bepalen wat haalbaar is en waar ik moet inleveren. In de echte kosten van maatwerk software heb ik dat uitgeschreven.

Hetzelfde geldt voor je tijdlijn. Een harde deadline door een beurs of een wetswijziging is prima, maar vertel het me aan het begin. Niet als we al twee weken bezig zijn.

Laat ruimte voor de vakman

Ik krijg soms briefings waar ik weinig mee kan. Niet omdat ze te vaag zijn, maar omdat ze te precies zijn. Elke knop beschreven. Elke schermindeling vastgelegd. Iedere stap uitgetekend in Visio.

Dat voelt voor de opdrachtgever als grondigheid. Maar het levert bijna altijd een slechter resultaat op. Je weet alles van je bedrijf. Maar je bent geen software architect, en dat hoeft ook niet. Daar huur je iemand voor in.

Ik werk het liefst met opdrachtgevers die beschrijven wát ze nodig hebben en mij het hóe laten invullen. Dat is ook waarom één vast aanspreekpunt zo goed werkt. Ik leer je situatie kennen. Ik stel vragen. En dan bouw ik iets dat past. Niet iets dat ik van een tekening heb nagebouwd zonder te snappen waarom.

Nog zoiets: kopieer niet de features van je concurrent. Dat zij een bepaalde functie hebben, zegt niks over wat jij nodig hebt. Misschien lost het bij hen een probleem op dat bij jou helemaal niet speelt.

Software is nooit af. Schrijf dat in je briefing.

De meeste briefings stoppen bij de lancering. Alsof het project dan klaar is. Maar software is nooit af. Er komen wensen bij, er veranderen regels, er worden bugs gevonden die je in de testfase niet zag. Onderhoud is geen luxe, het hoort erbij.

Schrijf in je briefing hoe je dat voor je ziet. Wil je een vaste partij die het systeem kent? Of ga je het intern beheren? Het maakt uit voor hoe ik bouw. Software die ik zelf blijf onderhouden schrijf ik anders dan software die ik overdraag aan een team dat ik niet ken.

En denk na over groei. Niet in de zin van "het moet miljoenen gebruikers aankunnen", want dat is bijna nooit de werkelijkheid. Maar gaan er meer mensen mee werken? Komen er nieuwe functies bij? Ga je uitbreiden? Dat soort informatie helpt me om een fundament te leggen dat niet over twee jaar al kraakt. Technische schuld is veel makkelijker te voorkomen dan te repareren.

De korte versie

Wat er in je briefing moet:

• Wie je bent en wat je bedrijf doet
• Wat het probleem is dat je wilt oplossen
• Wat je nu gebruikt en wat daar mis mee is
• Wie het gaat gebruiken, en in welke situatie
• Wat je wilt bereiken, niet hoe het gebouwd moet worden
• Een indicatie van je budget
• Wanneer het af moet zijn
• Hoe je onderhoud en doorontwikkeling voor je ziet
• Wie er beslist

Stuur het maar op

Een briefing hoeft niet perfect te zijn. Het is geen contract. Het is het begin van een gesprek, en de beste projecten die ik in 25 jaar heb gedaan begonnen met een opdrachtgever die gewoon eerlijk vertelde wat hij wel en niet wist.

Ik ga vragen stellen bij je briefing. Dat is geen kritiek. Het betekent dat ik je situatie probeer te snappen. Het alternatief is een developer die ja knikt, een offerte stuurt en er halverwege achter komt dat er stukken missen. Daar word je niet blij van.

Heb je een idee en wil je sparren? Neem contact op. Ik denk graag mee, ook als het nog niet meer is dan een idee op een bierviltje.