[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"site-version":3,"blog-doc-it-brief-per-sviluppatore":4},"2.2.0",{"id":5,"title":6,"body":7,"category":312,"credit":313,"date":316,"description":317,"extension":318,"faq":319,"image":332,"imageAlt":333,"keyword":334,"meta":335,"navigation":336,"path":337,"related":338,"seo":340,"seoTitle":341,"service":342,"slug":343,"stem":344,"tags":345,"__hash__":351},"blog\u002Fit\u002Ftips\u002F2026-10-15-brief-per-sviluppatore.md","Come scrivere un brief per uno sviluppatore: requisiti, vincoli e criteri di accettazione",{"type":8,"value":9,"toc":289},"minimark",[10,14,19,22,26,31,34,38,41,45,48,52,55,74,78,81,85,94,98,101,105,108,112,115,119,178,182,185,189,239,246,250,253,256,260,263,266,269,273,276],[11,12,13],"p",{},"Due sviluppatori che ricevono lo stesso brief vago produrranno due preventivi incomparabili, perché ognuno ha riempito i vuoti con le proprie ipotesi. Il brief serve a ridurre le ipotesi: non a descrivere la soluzione, ma a definire il problema, i vincoli e come si capirà che il lavoro è finito. Lo scrivo dal punto di vista di chi riceve brief ogni settimana, soprattutto dalle agenzie.",[15,16,18],"h2",{"id":17},"problema-non-soluzione","Problema, non soluzione",[11,20,21],{},"L'errore più frequente è un brief che descrive l'implementazione: «serve un plugin che faccia X», «vogliamo un'app». Meglio partire dall'obiettivo misurabile e dal contesto: chi usa il sistema, che problema ha oggi, cosa deve succedere dopo. La soluzione tecnica è il lavoro dello sviluppatore, e un brief che la impone spesso impone quella sbagliata.",[15,23,25],{"id":24},"le-sezioni-che-servono","Le sezioni che servono",[27,28,30],"h3",{"id":29},"contesto-e-obiettivo","Contesto e obiettivo",[11,32,33],{},"Chi è il cliente finale (se scrive un'agenzia), che attività svolge, perché il progetto nasce adesso. Un obiettivo verificabile: «ridurre le richieste telefoniche sugli orari», non «migliorare la comunicazione».",[27,35,37],{"id":36},"utenti-e-ruoli","Utenti e ruoli",[11,39,40],{},"Chi userà il sistema e con quali permessi: visitatori, clienti registrati, redattori, amministratori. Ogni ruolo in più è complessità in più, ed è bene saperlo subito.",[27,42,44],{"id":43},"requisiti-funzionali-con-priorità","Requisiti funzionali, con priorità",[11,46,47],{},"Elenco delle funzioni, divise in indispensabili, importanti e desiderabili. Questa divisione permette di stimare un perimetro minimo e di ragionare per fasi invece che per tutto o niente.",[27,49,51],{"id":50},"requisiti-non-funzionali","Requisiti non funzionali",[11,53,54],{},"Sono quelli che mancano quasi sempre e che generano le discussioni a fine progetto:",[56,57,58,62,65,68,71],"ul",{},[59,60,61],"li",{},"obiettivi di prestazione (per esempio Core Web Vitals «buoni» sui template principali);",[59,63,64],{},"livello di accessibilità (WCAG 2.1 AA o 2.2 AA);",[59,66,67],{},"lingue e gestione delle traduzioni;",[59,69,70],{},"browser e dispositivi supportati;",[59,72,73],{},"requisiti di sicurezza e privacy, inclusi i dati personali trattati.",[27,75,77],{"id":76},"sistemi-esistenti-e-integrazioni","Sistemi esistenti e integrazioni",[11,79,80],{},"Cosa c'è già: sito, hosting, dominio, gestionale, CRM, piattaforma di pagamento. Per ogni integrazione: esiste un'API documentata? Chi fornisce l'accesso? C'è un ambiente di prova? Un'integrazione senza documentazione è la prima fonte di sforamento dei tempi.",[27,82,84],{"id":83},"contenuti-e-materiali","Contenuti e materiali",[11,86,87,88,93],{},"Chi fornisce testi, immagini, traduzioni, e quando. Se il design esiste, in che formato e con quale grado di completezza: un file Figma con componenti e stati è un'altra cosa rispetto a tre schermate statiche (ne parlo in ",[89,90,92],"a",{"href":91},"\u002Fconsigli\u002Fda-figma-a-wordpress-e-token-design","Da Figma a WordPress",").",[27,95,97],{"id":96},"tempi-budget-decisioni","Tempi, budget, decisioni",[11,99,100],{},"Scadenze reali e il motivo (un evento, una campagna), una forbice di budget, e chi approva. Un solo referente che decide accorcia i progetti più di qualunque scelta tecnica.",[27,102,104],{"id":103},"proprietà-e-consegna","Proprietà e consegna",[11,106,107],{},"Di chi è il codice, dove vive il repository, chi detiene gli account (hosting, dominio, store), cosa si consegna a fine lavoro: documentazione, accessi, ambiente di staging.",[27,109,111],{"id":110},"criteri-di-accettazione","Criteri di accettazione",[11,113,114],{},"Come si stabilisce che il lavoro è concluso. Per ogni funzione indispensabile, una frase verificabile: «l'utente registrato vede solo le proprie prenotazioni», «il modulo invia la richiesta e mostra conferma anche senza JavaScript». Sono il contratto tecnico tra le parti.",[15,116,118],{"id":117},"un-modello","Un modello",[56,120,121,128,133,138,143,148,153,158,163,168,173],{},[59,122,123,127],{},[124,125,126],"strong",{},"Contesto e obiettivo misurabile:"," …",[59,129,130,127],{},[124,131,132],{},"Utenti e ruoli:",[59,134,135,127],{},[124,136,137],{},"Funzioni indispensabili \u002F importanti \u002F desiderabili:",[59,139,140,142],{},[124,141,51],{}," (prestazioni, accessibilità, lingue, sicurezza): …",[59,144,145,147],{},[124,146,77],{},", con documentazione: …",[59,149,150,127],{},[124,151,152],{},"Contenuti e design disponibili:",[59,154,155,127],{},[124,156,157],{},"Scadenza e motivo:",[59,159,160,127],{},[124,161,162],{},"Budget (forbice):",[59,164,165,127],{},[124,166,167],{},"Referente che decide:",[59,169,170,127],{},[124,171,172],{},"Proprietà del codice e degli account:",[59,174,175,127],{},[124,176,177],{},"Criteri di accettazione:",[15,179,181],{"id":180},"come-leggere-le-risposte","Come leggere le risposte",[11,183,184],{},"Un buon preventivo restituisce il brief con domande, ipotesi esplicite ed esclusioni. Diffiderei di chi risponde in un'ora con una cifra secca su un progetto complesso: non ha letto, o ha riempito i vuoti a modo suo. Il confronto tra preventivi ha senso solo se le ipotesi sono le stesse.",[15,186,188],{"id":187},"gli-errori-più-comuni","Gli errori più comuni",[56,190,191,197,203,209,215,221,227,233],{},[59,192,193,196],{},[124,194,195],{},"Descrivere la soluzione invece del problema",": «serve un plugin», «serve un'app», senza dire per fare cosa.",[59,198,199,202],{},[124,200,201],{},"Nessuna priorità",": tutte le funzioni sembrano indispensabili, e la stima diventa un tutto o niente.",[59,204,205,208],{},[124,206,207],{},"Requisiti non funzionali assenti",": velocità, accessibilità e lingue scoperte a fine progetto.",[59,210,211,214],{},[124,212,213],{},"Integrazioni date per scontate",": «si collega al gestionale», senza sapere se il gestionale ha un'API.",[59,216,217,220],{},[124,218,219],{},"Contenuti «in arrivo»",": testi e immagini che arrivano a progetto finito e cambiano il layout.",[59,222,223,226],{},[124,224,225],{},"Troppi decisori",": ogni revisione apre un nuovo giro di opinioni.",[59,228,229,232],{},[124,230,231],{},"Budget taciuto",": lo sviluppatore propone una soluzione fuori scala, in un senso o nell'altro.",[59,234,235,238],{},[124,236,237],{},"Scadenze senza motivo",": una data arbitraria impedisce di ragionare per fasi.",[11,240,241,242,245],{},"Se il progetto è ancora vago, la scelta più onesta è una ",[124,243,244],{},"fase di analisi"," separata e pagata, che produce il brief e una stima affidabile. Costa poco rispetto al progetto e riduce molto il rischio di entrambe le parti.",[15,247,249],{"id":248},"un-criterio-di-accettazione-che-si-può-collaudare","Un criterio di accettazione che si può collaudare",[11,251,252],{},"«L’utente vede solo le proprie prenotazioni» è un inizio, ma il collaudo deve includere le API. Prepariamo due account di prova: A crea una prenotazione; B tenta di leggerla e modificarla usando direttamente il suo identificativo. Il server deve negare entrambe le operazioni, anche se B conosce l’indirizzo dell’endpoint. Nascondere il pulsante non è un controllo di accesso.",[11,254,255],{},"Per i requisiti di prestazione distinguo obiettivo sul campo e prova prima del lancio. Il brief deve specificare pagine, dispositivi, condizioni di rete, metrica e metodo di misura. Un punteggio di laboratorio non equivale ai Core Web Vitals dei visitatori reali; senza traffico sufficiente serve un criterio provvisorio dichiarato, seguito da monitoraggio in produzione.",[15,257,259],{"id":258},"come-la-vedo-io","Come la vedo io",[11,261,262],{},"Il brief migliore che ricevo è quello che ammette ciò che non sa. Lavorando soprattutto con agenzie, preferisco un documento breve con obiettivi e vincoli chiari a un capitolato lungo che descrive già la soluzione. Poi lavoro per anteprime: ogni settimana una versione online consultabile (con Netlify ogni modifica ne genera una), così il brief si verifica sul prodotto vero e non sulla carta.",[11,264,265],{},"E chiedo sempre di mettere per iscritto proprietà del codice e degli account: non per sfiducia, ma perché è la domanda che, fatta tardi, crea più problemi.",[11,267,268],{},"Un brief onesto, per me, vale più di un capitolato perfetto.",[15,270,272],{"id":271},"perché-affidarlo-a-me","Perché affidarlo a me",[11,274,275],{},"Ricevo brief dalle agenzie da molti anni: dal 1999 ho consegnato più di 300 progetti e collaboro con più di 30 agenzie, da Roma e da remoto. Rispondo a un brief con domande, ipotesi esplicite e una stima per fasi, non con una cifra secca.",[11,277,278,279,283,284,288],{},"Se hai un progetto da impostare, ",[89,280,282],{"href":281},"\u002Fcontatti","scrivimi",": in una chiacchierata di circa 20 minuti trasformiamo l'idea in un brief che regge. Il servizio è in ",[89,285,287],{"href":286},"\u002Fservizi\u002Fsoftware-su-misura","Software su misura",".",{"title":290,"searchDepth":291,"depth":291,"links":292},"",2,[293,294,306,307,308,309,310,311],{"id":17,"depth":291,"text":18},{"id":24,"depth":291,"text":25,"children":295},[296,298,299,300,301,302,303,304,305],{"id":29,"depth":297,"text":30},3,{"id":36,"depth":297,"text":37},{"id":43,"depth":297,"text":44},{"id":50,"depth":297,"text":51},{"id":76,"depth":297,"text":77},{"id":83,"depth":297,"text":84},{"id":96,"depth":297,"text":97},{"id":103,"depth":297,"text":104},{"id":110,"depth":297,"text":111},{"id":117,"depth":291,"text":118},{"id":180,"depth":291,"text":181},{"id":187,"depth":291,"text":188},{"id":248,"depth":291,"text":249},{"id":258,"depth":291,"text":259},{"id":271,"depth":291,"text":272},"Sviluppo software",{"name":314,"url":315},"Swanky Fella","https:\u002F\u002Funsplash.com\u002F@swankyfella","2026-10-15","Un brief che produce stime affidabili: obiettivi, requisiti funzionali e non funzionali, integrazioni, ambienti, proprietà del codice e criteri di accettazione. Con un modello da usare.","md",[320,323,326,329],{"q":321,"a":322},"Quanto deve essere lungo un brief?","Quanto serve a rendere le stime confrontabili. Due pagine ben scritte valgono più di venti generiche: conta che obiettivi, vincoli e criteri di accettazione siano espliciti.",{"q":324,"a":325},"Devo indicare il budget?","Sì, anche come forbice. Senza budget lo sviluppatore deve indovinare il livello di soluzione: con la stessa richiesta si può proporre un tema pronto o un'applicazione su misura, e le stime non saranno confrontabili.",{"q":327,"a":328},"Cosa sono i requisiti non funzionali?","Sono le qualità che il sistema deve avere oltre alle funzioni: prestazioni, accessibilità, sicurezza, lingue, browser supportati, disponibilità. Sono quelli che più spesso mancano nei brief e che più spesso generano contestazioni.",{"q":330,"a":331},"E se non so ancora cosa mi serve?","Si fa una fase di analisi pagata e separata, che produce il brief. È più onesto di un preventivo a corpo su un progetto indefinito.","\u002Fimages\u002Ftips\u002F2026-10-15-brief-per-sviluppatore.jpg","Penna appoggiata su un libro aperto","brief sviluppatore",{},true,"\u002Fit\u002Ftips\u002F2026-10-15-brief-per-sviluppatore",[339],"white-label-agenzia-sviluppatore",{"title":6,"description":317},"Brief per sviluppatore: modello con requisiti e vincoli","app-su-misura","brief-per-sviluppatore-web","it\u002Ftips\u002F2026-10-15-brief-per-sviluppatore",[346,347,348,349,350],"brief","preventivo sviluppo","requisiti","criteri di accettazione","agenzie","1cvTJZjOMHMC9pdkX7-zIvYYqWGQSXTjUnzYq6sD_o0"]