Zo schrijf je een briefing die leidt tot een scherpe offerte
Een vage briefing leidt tot een vage inschatting. Dit is wat een developer echt nodig heeft om jouw project te kunnen offreren.
Een vraag als "ik heb een app nodig voor mijn bedrijf" is onmogelijk te prijzen. Niet omdat developers moeilijk doen, maar omdat de prijs van software bijna volledig afhangt van details die nog niet genoemd zijn. Een betere briefing levert je een betere, snellere en scherpere offerte op.
Begin bij het probleem, niet bij de oplossing
Het is verleidelijk om de software te beschrijven die je voor ogen hebt, in plaats van het probleem dat je wilt oplossen. Maar dat probleem is wat er echt toe doet: welk proces is nu kapot, traag of handmatig? Een developer kan vaak een eenvoudigere of goedkopere oplossing voorstellen dan waar je zelf aan dacht, maar alleen als het onderliggende doel duidelijk is.
Wat een developer wil weten
Nuttige informatie is bijvoorbeeld wie de software gaat gebruiken en hoe, met welke systemen gekoppeld moet worden, om welke data het gaat, en of er een deadline of budgetplafond is waarbinnen gewerkt moet worden. Je hoeft niet alle antwoorden al te hebben, maar aangeven wat je nog niet weet is nuttiger dan gokken.
Kort is beter dan lang
Een samenvatting van één pagina die de kern raakt is veel bruikbaarder dan een uitgebreid document waarin de belangrijke details verdwijnen. Het doel is geen specificatie schrijven, maar een developer genoeg meegeven om de juiste vervolgvragen te kunnen stellen.