Réponse en bref
La moitié d'un brief typique est remplie de choses qui ne gagnent rien : les choix technologiques et le design décrits dans les adjectifs. Voici les huit points qui comptent et les trois endroits où les horaires passent réellement.
Pourquoi un bref, quand le développeur a déjà compris
Tout le monde est d'accord verbalement au début du projet. L'écart apparaît au passage, quand il s'avère que le catalogue signifiait vingt pages de produits d'un côté et vingt avec des filtres, des comparaisons et des exportations de stocks de l'autre.
Un brief n'est pas là pour lier les mains d'un développeur. C'est là que les deux parties comprennent en même temps ce qui est construit — et donc que trois mois plus tard il y a quelque chose à vérifier en dehors de la mémoire.
Un bon bref est plus court que prévu. Il s'étend sur quelques pages plutôt que quarante, et se compose presque entièrement de décisions plutôt que de descriptions.
Voici ce qui y va, dans quel ordre, et les trois endroits où les horaires passent le plus souvent. Écrit du côté du client : c'est un document que vous produisez, pas un qui arrive pour votre signature.
Ce qui n'appartient pas dans un bref
Commencez par ce qui remplit habituellement la moitié du document et ne rapporte rien.
Le choix de la technologie. Si vous n'êtes pas un développeur, exiger un cadre particulier restreint le champ des fournisseurs sans améliorer le résultat. Une exception : vous avez déjà une équipe qui la maintiendra.
Décrire le dessin en mots. Moderne, élégant, accrocheur ne peut ni être livré ni vérifié. Au lieu de donner trois ou quatre liens aux sites que vous aimez et une ligne sur ce que vous aimez dans chacun.
Listes de fonctionnalités recyclées. Les phrases comme la navigation intuitive et la conception réactive ne précisent rien : elles sont le point de départ, pas une exigence, et en bref elles ne diluent que ce qui compte réellement.
Tout ce que vous n'êtes pas prêt à tester à la remise. Une clause que vous ne pouvez pas marquer faite ou non ne fonctionne pas dans un bref.
Où ça commence : le travail, pas la liste des pages
La première page d'un mémoire n'est pas la structure du site. C'est la réponse à ce qui devrait changer dans l'entreprise après le lancement.
La formulation doit être testable. Pas de sensibilisation, mais de demande d'enquête sur le site, qui n'arrive actuellement que par téléphone. Pas en ligne, mais montrez le catalogue que nous envoyons en tant que fichier.
Alors qui sont ces gens. Un ou deux types de visiteurs, et pour chacun: quelle question ils arrivent avec, ce qu'ils doivent faire, et ce qui les empêche de le faire aujourd'hui.
Cette section prend une demi-page et détermine tout le reste. Une liste de pages construite sans elle sort toujours plus longtemps que nécessaire ou vise la mauvaise chose.
Le test est simple : si la première page du mémoire n'explique pas pourquoi chaque page énumérée plus tard existe, retournez-y.
La liste des pages et comment la connaître est complète
Maintenant la structure. Listez les pages, une ligne chacune, avec ce que chacun est pour à côté.
Marquez séparément les pages qui existent en quantité avec une construction identique : pages de produits, services, articles. Décrivez l'un d'eux — les autres sont construits selon ce modèle, et il est nettement moins cher que vingt dessins individuels.
N'oubliez pas les pages d'utilité : la page d'erreur, la confirmation du formulaire envoyé, la politique de données. Ceux-ci sont presque toujours manqués et ensuite faits en hâte.
L'exhaustivité est vérifiée à l'envers : marchez la liste des travaux de la première section et confirmez que chacun a une page où il se fait. Et l'inverse — que chaque page a un travail.
Si une page n'est attachée à aucun travail, soit elle devrait aller, soit vous avez trouvé un travail que vous avez oublié d'écrire.
Données : la section la plus débordée
C'est là que les attentes et les prix divergent le plus souvent, car la section semble terne et est écrite en dernier.
Tout ce qui existe au pluriel sur un site vit dans une table : produits, services, propriétés, personnel, articles. Chacun de ces ensembles a besoin de trois choses.
Combien il y en a maintenant et combien en un an. La différence entre cent et mille est une différence d'approche, et non de charge de travail.
Quels champs chaque enregistrement a. Écrivez-les par nom : titre, prix, photos, attributs, disponibilité. Cette liste détermine les filtres, la mise en page de la carte et la complexité.
Et d'où proviennent les données : entrées à la main, exportées d'un système de comptabilité, livrées par un fournisseur en tant que fichier. Une réponse de main pour un millier d'articles signifie qu'un importateur est nécessaire, et il est préférable d'apprendre cela avant et non après.
Intégrations : les nommer
Une liste des systèmes extérieurs auxquels le site doit parler. Ne pas intégrer avec un CRM mais le nom du CRM.
Pour chacun, ce qui devrait se passer et dans quelle direction. L'enquête va au CRM. Stock arrive du système de comptabilité horaire. Le paiement passe par une banque spécifique. Une notification atterrit dans un messager.
Marquez séparément ce à quoi vous avez déjà accès et ce qui doit être configuré. L'attente de l'accès est la cause la plus courante d'un décrochage au milieu du projet, et elle n'a rien à voir avec le développeur.
Et une question mérite d'être posée tôt : que devrait-il se passer lorsqu'un système extérieur ne répond pas. Une enquête perdue sur le serveur silencieux de quelqu'un d'autre ressemble exactement au client comme une enquête qui n'a jamais été envoyée.
Ce qui arrive à l'ancien site
Cette section est nécessaire pour tous ceux qui ont déjà un site, et presque tout le monde le saute.
Les anciennes adresses ne disparaissent pas avec l'ancien site. Un moteur de recherche se souvient d'eux pendant des années, les pages d'autres personnes lient à eux, ils sont assis dans les signets de quelqu'un. Après le lancement du nouveau site, chacune de ces adresses mène quelque part sensé ou renvoie une erreur.
Après notre propre déménagement d'une plate-forme précédente il y avait 673 de ces adresses. Ils ont dû être travaillés un à la fois, parce que la décision sur chacun est éditoriale: y a-t-il une page sur le nouveau site qui répond à la même question?
Donc le bref a besoin d'une clause : exporter la liste d'adresses de l'ancien site et dessiner la cartographie avant le début du développement. Prenez la liste de deux endroits — l'ancien système et la console de recherche — parce qu'ils ne correspondent pas.
Il coûte quelques jours de travail et économise des mois de récupération des postes.
Qui fournit quoi
Un tableau court qui empêche plus d'arguments que le reste du document combiné.
Texte : écrit par le client, le développeur ou un auteur séparé. Si le client, nommer une date, car le texte arrive presque toujours en dernier et maintient le lancement.
Photographie: images existantes, un nouveau shoot, ou stock. Chaque option a ses propres coûts et ses propres délais.
Accès : domaine, hébergement, courrier, analyse, système de comptabilité. Rassemblez-les tôt et confirmez qu'ils fonctionnent — le mot de passe vers un domaine enregistré il y a sept ans au nom d'un ancien employé prend un certain temps à trouver.
Garder après le lancement: qui ajoute des produits et écrit des nouvelles. Un site que personne n'est affecté à l'entretien est inexistant dans un quart de la construction.
Comment le travail est accepté
La section écrite le moins souvent et celle qui détermine la fin du projet.
Les critères d'acceptation doivent être vérifiables, les deux côtés étant présents. Le site fonctionne correctement n'est pas un critère. Une demande du formulaire arrive à l'adresse indiquée et dans le CRM dans une minute est une.
Acceptez d'avance ce que vous testez. Une liste des appareils et des navigateurs, et deux ou trois tâches réelles un visiteur devrait terminer fin à fin.
Séparément : ce qui compte comme défaut et ce qui compte comme changement. Un défaut est corrigé dans l'ouvrage convenu; un changement est cité séparément. Sans cette ligne, chaque désaccord devient une négociation sur l'argent.
Et indiquez la période pendant laquelle les défauts sont corrigés après le lancement. Un mois est raisonnable; le soutien gratuit à vie n'existe pas et est simplement payé.
Trois endroits où les horaires glissent
En pratique, presque chaque retard se produit ailleurs que prévu.
Texte. Il est écrit en dernier et tient tout. Le correctif est de l'écrire en même temps que le développement et de le remettre page par page plutôt que tous à la fois.
Accès. Il faut plus de temps pour obtenir, surtout pour les systèmes bancaires et comptables. Commencez la collecte le jour de la signature.
Approbation du côté du client. Si trois personnes décident et se réunissent tous les quinze jours, chaque révision coûte deux semaines. Nommez une personne dont le mot est définitif — l'accélération la moins chère disponible.
Un modèle d'une page
Si vous préférez ne pas écrire un document à partir de zéro, voici le minimum qui couvre la plupart des risques.
Le travail d'affaires et un ou deux types de visiteurs. La liste des pages avec le but de chacun. Ensembles de données avec leurs champs et leur volume. Systèmes extérieurs par nom, avec la direction de l'échange. Le sort des anciennes adresses. Qui fournit quoi et quand. Critères d'acceptation. La ligne entre un défaut et un changement.
Huit points, trois ou quatre pages. Assez pour obtenir des propositions comparables de différents fournisseurs, et assez que trois mois plus tard la conversation porte sur le travail plutôt que sur qui voulait dire quoi.
Une dernière chose: un bref écrit par le client est presque toujours meilleur que celui fourni par le développeur — pas parce que le client en sait plus, mais parce que seul le client sait à quoi il sert.
Checklist pratique
- Indiquer le travail d'entreprise sous une forme qui peut être testée.
- Décrivez un ou deux types de visiteurs et la question avec laquelle ils arrivent.
- Énumérez les pages et écrivez à quoi elles servent.
- Écrire les ensembles de données avec leurs champs et le volume attendu.
- Nommer les systèmes extérieurs et la direction de l'échange.
- Ajouter une clause couvrant l'exportation des adresses de l'ancien site.
- Écrire des critères d'acceptation testables avec les deux côtés présents.
- Tracer la ligne entre un défaut et un changement payé.
Questions et réponses
Faut-il préciser brièvement des technologies particulières?
Habituellement pas. Exiger un cadre particulier restreint le champ des fournisseurs sans améliorer le résultat, sauf si vous êtes un développeur vous-même. Une exception: vous avez déjà une équipe qui va maintenir le site après le lancement et qui a besoin d'une pile familière.
Qui devrait écrire le mémoire, le client ou le développeur?
Le client, au moins dans la première version. Non pas parce qu'ils comprennent mieux le développement, mais parce que seulement ils connaissent le travail d'entreprise. Le développeur ajoute ensuite la partie technique, mais l'objectif et les critères d'acceptation devraient provenir de qui paie.
Dans quelle mesure un bref mémoire doit-il être détaillé?
Assez détaillé pour que différents fournisseurs retournent des offres comparables, et pas plus. C'est généralement trois ou quatre pages. Tout ce que vous ne pouvez pas marquer fait ou non fait au transfert ajoute de la longueur sans ajouter de valeur.
Qu'est-ce qui se passe dans la section d'acceptation?
Critères testables et la liste de ce que vous testez sur: appareils, navigateurs, et deux ou trois vraies tâches de visiteur du début à la fin. Tracer séparément la ligne entre un défaut, fixé dans l'ouvrage convenu, et un changement, qui est cité par lui-même.
Que devrait dire le bref sur un site existant?
Ajouter une clause de sa propre : exporter la liste d'adresses de l'ancien site et dessiner la cartographie avant le début du développement. Prenez la liste de deux endroits, l'ancien système et la console de recherche, parce que les deux ne correspondront pas.

