Réponse en bref
Un bon bref fixe la portée plutôt que le goût. C'est ce qui fait partie de l'une d'entre elles : les cinq réponses nécessaires avant toute citation, pourquoi la liste de pages conduit l'estimation, qui possède la copie et les traductions, et comment le…
Qu'est-ce qu'un bref et ce qu'il n'est pas: Un bref fixe la portée: le nombre de pages, le…
Il existe un mémoire pour fixer la portée. C'est le document qui transforme une conversation au sujet d'un site Web en une liste qu'un développeur peut comparer, programmer et ensuite mesurer. Tout un bref fait bien, il fait en rendant l'une de ces trois choses moins négociable.
C'est un travail différent de la description du goût. Une référence à un site que vous admirez parle au développeur du registre visuel que vous voulez ; il ne leur dit pas combien de pages existent, qui écrit le texte, ou quel système le formulaire de commande doit atteindre. Le goût appartient à un bref, mais il ne peut pas le porter.
Le test pratique est simple. Donnez le document à quelqu'un qui ne vous a jamais rencontré et demandez-lui de nommer le nombre de pages, la date de lancement et la personne responsable de la copie. S'ils ne le peuvent pas, le mémoire reste une liste de souhaits.
Ce qui suit est la forme d'un bref qui survit à ce test, section par section, avec les propriétaires de pièces généralement laisser dehors marqués au fur et à mesure qu'ils viennent. Il se termine par la façon dont le document fini se présente sur les paquets qui portent déjà des prix fixes et des échéanciers.
La version d'une page: cinq choses avant que personne ne cite
Avant tout détail, cinq réponses décident si une citation est même possible: ce que le site est pour, combien de pages il a, qui fournit le contenu, ce qui doit se connecter à lui, et quand il doit être en direct. Un développeur qui a ces cinq personnes peut mettre un numéro sur le travail.
Tout le reste dans un bref est l'élaboration de ces cinq. Si vous êtes à court de temps, écrivez une page contenant seulement et envoyez-la. Un mémoire d'une page qui répond à tous les cinq obtient une citation plus ferme qu'un document de vingt pages qui répond à trois.
L'ordre compte aussi. But sélectionne la liste des pages, la liste des pages sélectionne la charge de travail du contenu, et la charge de travail du contenu définit habituellement le calendrier réel. À partir de la conception inverse plutôt cette chaîne et produit une estimation qui se déplace chaque semaine.
Traitez l'une des pages comme une ébauche que vous conserverez. Le brief plus long n'est pas un remplacement pour elle ; c'est les mêmes cinq réponses avec le détail joint, et l'une-pager reste utile que le résumé tout le monde peut tenir dans sa tête.
But : nommer la seule action que le site doit produire
Écrivez la seule action que vous voulez qu'un visiteur prenne. Une réservation, un appel, un formulaire rempli, une commande complétée, un fichier téléchargé. Un site peut supporter plusieurs, mais un bref qui donne un nom à chaque décision ultérieure un tiebreaker.
C'est la phrase qui résout les arguments sur la mise en page. Lorsque deux personnes ne sont pas d'accord sur la question de savoir si le prix appartient au-dessus ou au-dessous de la description, l'action nommée décide, et la discussion prend une minute au lieu d'une semaine.
Il vous dit également ce qu'il faut mesurer. Si l'action est un formulaire rempli, alors les présentations de formulaire sont le nombre qui compte, et le trafic est le contexte plutôt que le résultat. Le nommer dans le bref signifie que la configuration analytique a quelque chose de concret à enregistrer.
Écrivez-le en langage clair et mettez-le en haut. "Un visiteur doit pouvoir voir les prix et envoyer une demande sans nous appeler" est un but utilisable. "Augmentation de la notoriété de la marque" n'est pas, parce que rien dans une construction en découle.
La liste des pages est la colonne vertébrale de chaque estimation
Énumérez les pages. Accueil, services, à propos, contact, puis ceux qui vous sont propres — un catalogue, un flux de réservation, un portfolio, un ensemble de pages légales. Comptez-les, et marquez ceux qui répètent un modèle et qui sont une sorte.
La distinction entre un modèle et une page unique est l'endroit où les estimations sont gagnées ou perdues. Quarante entrées de catalogue sur un modèle est un travail plus petit que quatre pages que chaque besoin de leur propre mise en page, et seule la liste des pages rend cela visible.
Ajoutez ce que chaque page doit contenir, dans une ou deux lignes. Pas le libellé — les blocs. "Page de service: description, prix, ce qui est inclus, ce qui n'est pas, formulaire de demande." Cette ligne est suffisante pour un développeur pour voir le travail et assez pour que vous remarquiez un bloc manquant.
Marquez les pages que vous pouvez lancer sans. Un brief qui sépare l'ensemble de lancement de l'ensemble ultérieur vous donne un levier que vous voudrez : lorsque la date est à risque, la deuxième liste est ce qui bouge, et rien n'a besoin de renégocier.
Contenu: qui l'écrit, qui le traduit, quand il arrive
Le contenu est la partie d'un projet de site Web le plus susceptible de glisser, et la partie un bref laisse le plus souvent en blanc. Notez qui produit le texte pour chaque page, qui fournit les photos, et la date est due.
Nommez de vrais gens, pas des départements. "Marketing enverra la copie" n'a pas de propriétaire; "Anna envoie les descriptions de service avant le 12" fait. Le point n'est pas la bureaucratie, c'est qu'un propriétaire manquant est invisible jusqu'à la semaine où vous avez besoin du texte.
Dites explicitement si les traductions sont nécessaires et qui les produit. VITON13 n'écrit pas le contenu ou les traductions du client — qui est assis avec vous, et feignant autrement au stade bref est ce qui transforme une construction de cinq jours en une attente de cinq semaines.
Si le contenu n'existe pas encore, dites-le et donnez une date. Un développeur peut construire contre le texte placeholder et l'échanger plus tard, mais seulement si le plan dit que c'est ce qui se passe. La découvrir au passage est une conversation différente et pire.
Design: ce qui existe déjà et ce qui doit être fait
Séparez ce que vous avez de ce dont vous avez besoin. Un logo, une palette de couleurs, une licence de typographie, des photographies, un livre de marque — énumérez ce qui existe et où se trouvent les fichiers. Tout ce qui ne figure pas sur cette liste doit être produit, et la production prend du temps.
Si vous avez un livre de marque, dites quelles parties sont liées. Certains sont stricts sur la couleur et la typographie et détendus sur la mise en page; certains sont l'inverse. Un développeur qui sait quelles règles ne peuvent être pliées arrête de deviner et arrête de demander.
Deux ou trois sites de référence sont utiles ici, avec une phrase sur ce que vous voulez de chacun. "Celui-ci pour la façon dont le prix est présenté" vaut plus qu'un lien nu, car il sépare la partie que vous admirez des parties que vous ne faites pas.
Dis ce qui ne doit pas arriver aussi bien. Une couleur qui appartient à un concurrent, une mise en page de votre site précédent utilisé, un style photographique qui est mauvais pour votre marché. Les contraintes déclarées tôt sont moins coûteuses que les corrections apportées tard.
Fonctions: exécutez chaque fonction à travers une phrase
Pour chaque fonction que vous voulez, écrivez une phrase : qui fait quoi, et ce qui se passe ensuite. "Un visiteur choisit une date et une heure, soumet le formulaire, et la demande apparaît dans notre courriel et dans le CRM." Cette phrase est la spécification.
La phrase filtre les caractéristiques qui semblent simples et ne le sont pas. La "réservation en ligne" cache la question de savoir si le calendrier doit connaître les rendez-vous existants; la version de phrase la couvre avant que quelqu'un y cite.
Triez la liste dans ce qu'exige le lancement et ce qui peut suivre. Presque chaque projet a des caractéristiques qui se sentent essentielles dans une réunion et se révèlent être confortablement en deuxième phase une fois la date de lancement est réelle. Décider que dans le mémoire est moins cher que de le décider sous pression.
Soyez précis sur les applications mobiles natives si vous en imaginez une. Un site Web réactif et une application dans un magasin sont des produits distincts avec un travail séparé; VITON13 Les paquets de développement couvrent la construction web, et les applications mobiles natives sont nommées comme non incluses.
Intégrations: nom des systèmes et qui détient les comptes
Listez tous les systèmes externes que le site doit atteindre: un CRM, un fournisseur de paiement, une plateforme d'analyse, un outil de messagerie, un système de réservation, un service de livraison. Nommer le produit, pas la catégorie, parce que deux CRM avec le même travail peut différer par une semaine de travail.
Pour chacun, dites qui détient le compte et qui peut accorder l'accès. Une intégration ne peut pas être construite contre un système auquel personne ne peut se connecter, et l'attente d'un mot de passe est l'une des façons les plus silencieuses de glisser une chronologie.
Dis ce qui doit aller dans chaque direction. Un formulaire d'envoi d'une piste dans un CRM est un emploi; un catalogue de lecture de stock en direct d'un système de comptabilité et d'écriture des commandes est un autre. La direction des données est la plupart des estimations.
Le paiement mérite sa propre ligne. Quel fournisseur, quel pays, quelle entité signe le contrat et qui est responsable de la licence. VITON13's Product Build package nomme la licence de paiement hors de sa portée, de sorte que la responsabilité devrait être réglée dans le mémoire.
Contraintes : date, fourchette budgétaire et ce qui ne peut changer
Indiquer la date et dire à quoi elle est liée. Un salon, une saison, une campagne, un bail. Un développeur qui connaît la date est un plan immobilier différent de celui qui pense que c'est une préférence, et la différence montre dans ce qui est proposé.
Donnez un budget plutôt qu'un seul chiffre ou rien du tout. Une bande permet à un fournisseur de vous dire honnêtement lequel de vos besoins correspond à l'intérieur, ce qui est une réponse plus utile qu'un devis construit à un nombre que vous n'avez jamais voulu dépenser.
Énumérez la technologie que vous devez conserver. Un CMS existant, un contrat d'hébergement avec le temps restant, un arrangement de domaine, un système comptable qui ne peut être remplacé cette année. Les contraintes de ce genre sont des faits neutres, et elles changent l'estimation si vous les mentionnez ou non.
Ajoutez les exigences légales que vous connaissez déjà: un avis de confidentialité, le traitement des cookies, un standard d'accessibilité que votre secteur attend. La référence rapide WCAG 2.2 du W3C est la liste de contrôle pratique pour le dernier de ceux-ci et vaut la peine d'être nommée plutôt que d'invoquer.
Acceptation : notez comment vous déciderez qu'elle est terminée
Un bref qui décrit le travail mais pas la ligne d'arrivée laisse la fin du projet sans état. Écrivez les conditions d'acceptation pendant que vous êtes calme : ce que vous allez ouvrir, ce que vous allez cliquer et ce qui doit être vrai avant de signer.
Gardez-les en béton. Chaque page charge sur un téléphone et sur un bureau; le formulaire arrive dans la boîte de réception et dans le CRM; le prix indiqué correspond à la liste de prix; le site est accessible à la bonne adresse sur HTTPS. Chacun est un oui ou un non.
Inclure ceux qui sont mesurables. La vitesse est un bon exemple, car la documentation de performance de MDN donne un vocabulaire partagé pour elle, et "la page d'accueil est rapide" n'est pas une condition que tout le monde peut passer ou échouer.
Nomme qui signe. Une personne, avec un délai pour effectuer les vérifications. Un processus d'acceptation avec trois évaluateurs et aucune date limite est le mécanisme par lequel un projet fini reste ouvert pendant un autre mois.
Qu'un mémoire ne doit pas contenir
Il ne devrait pas contenir de choix de mise en œuvre que vous n'avez pas de raison pour. Nommer un cadre parce que vous lisez à ce sujet limite la construction sans l'améliorer. Indiquez l'exigence — une page que tout le monde dans le bureau peut éditer — et laissez le fournisseur y répondre.
Il ne devrait pas contenir de chiffres devinés. Un chiffre de trafic inventé ou une cible de conversion spéculative établit une attente contre laquelle le travail sera mesuré, et la mesure ne sera pas équitable pour personne.
Il ne devrait pas contenir d'exigences que personne ne possède. Chaque ligne qui dit que le site « devrait » faire quelque chose a besoin d'une personne attachée, ou il survivra à chaque examen et sera découvert manquant à l'acceptation.
Et il ne devrait pas être long pour son propre bien. Le document existe pour être lu par les personnes qui sont les prix et la construction. Six pages claires ont battu trente qui enterrent la liste des pages au milieu d'un récit de stratégie.
Comment les cartes courtes terminées sur les paquets fixes
Un bref vaut la peine d'écrire en partie parce qu'il vous permet de comparer les offres sur le même pied. VITON13's service de développement prix cinq paquets, et une fois que votre liste de page et le plan de contenu existent, le mémoire choisit habituellement l'un d'eux sur son propre.
Site Fix Pack est de 70 $ et fonctionne 1-2 jours ouvrables pour jusqu'à cinq correctifs convenus, avec une vérification mobile et de bureau et une liste avant/après à la remise; il porte une série de révisions et ne couvre pas de nouvelles pages, refonte ou migrations. Le site de lancement est de 380 $ sur 3-5 jours ouvrables pour une configuration de montage, de câblage de base ou de déploiement, avec deux séries de révisions avant le lancement et le contenu et les traductions fournies par vous.
Product Build est de 880 $ sur 2-3 semaines et couvre la livraison des fonctionnalités, l'état et la logique de route, test et durcissement, avec deux tours de révisions par fonction livrée; applications mobiles natives et licence de paiement s'assoient en dehors de lui. Lancer Site Express est de 520 $ et offre la portée du site de lancement dans une file d'attente prioritaire sur 2 jours ouvrables avec des constructions quotidiennes, une liste de vérification de lancement et un appel de remise, une série de révisions après la première construction complète, et le contenu, la photographie et le soutien continu exclus.
En cours Dev Support est 290 $ par mois sur un cycle mensuel avec un préavis de 30 jours pour s'arrêter, couvrant les mises à jour prioritaires, un rythme de sortie hebdomadaire et la maintenance technique; le volume est convenu au début de chaque cycle, et une nouvelle construction ou une refonte est projetée séparément. Lisez les termes du paquet que vous choisissez en fait — ils diffèrent les uns des autres dans l'intention.
Checklist pratique
- Écrivez la version d'une page avec les cinq réponses et envoyez-la avant le document long.
- Énumérez chaque page et marquez chacune comme un modèle répété ou une mise en page unique.
- Nommez une personne et une date pour la copie, la photographie et les traductions.
- Mettre chaque fonction demandée à travers le test de phrase: qui fait quoi, et ce qui se passe ensuite.
- Nommer chaque système externe par produit et dire qui détient son compte.
- Écrire les conditions d'acceptation et nommer la seule personne qui signe.
Questions et réponses
Ai-je besoin d'un bref si le site est petit?
Oui, mais un petit. Pour un petit site, une seule page contenant cinq réponses suffit : à quoi sert le site, combien de pages il a, qui fournit le contenu, à quoi il doit se connecter et quand il va en direct. C'est ce qui transforme une fourchette en une citation ferme.
Quel est le coût du développement et comment le mémoire l'affecte-t-il?
VITON13 prix cinq forfaits: Fix Pack site à 70 $ sur 1-2 jours ouvrables pour jusqu'à cinq correctifs convenus, Lancez site à 380 $ sur 3-5 jours ouvrables, Lancez site Express à 520 $ sur 2 jours ouvrables, Construisez produit à 880 $ sur 2-3 semaines, et Soutien Dev continu à 290 $ par mois. Le mémoire ne modifie pas le prix d'un paquet; il indique dans quel paquet l'œuvre appartient.
Qui écrit le texte: le client ou le développeur?
Contenu et traductions restent avec le client: VITON13 ne les écrit ni ne les traduit. Le mémoire a donc besoin d'une personne nommée et d'une date pour la copie sur chaque page, ou l'horaire se termine par le temps que le matériel prend pour arriver plutôt que par la construction.
Le bref devrait-il nommer un cadre spécifique?
Seulement si vous avez une raison — un système existant que vous devez conserver, ou une équipe qui maintiendra le site après. Sans un, énoncez plutôt l'exigence, comme une page que quiconque dans le bureau peut éditer, et laissez le fournisseur répondre.
Et si le contenu n'existe pas encore ?
Dites-le dans le dossier et donnez une date. Une construction peut fonctionner sur le texte de placeholder et l'échanger plus tard, mais cela doit être le plan plutôt qu'une découverte au transfert. Marquer les pages qui peuvent être retenues dès le premier jour.