Pourquoi le mandat décide de la soumission
Un studio qui chiffre votre projet estime des heures. Là où votre mandat est clair, l’estimation est juste. Là où il est vague, le studio doit deviner, et chacun devine différemment : l’un suppose la version la plus simple pour garder le chiffre bas, l’autre la plus complexe pour se protéger. Vous finissez par comparer des suppositions plutôt que des prix.
Un bon mandat élimine les suppositions. Il n’a pas besoin d’être long et ne devrait pas tenter de concevoir le logiciel. Il doit décrire qui l’utilisera, ce que ces personnes doivent faire, à quoi il se connecte, quelles données il contient et sous quelles contraintes il vit. Ces réponses décident de la plupart des heures, donc de la plus grande partie de la soumission.
Ce que contient un bon mandat
- 01
Le problème, en un paragraphe
Ce qui ne va pas aujourd’hui, pour qui, et ce que cela vous coûte en temps, en erreurs ou en affaires perdues. C’est ce qui permet à un studio de proposer une réponse plus simple s’il y en a une.
- 02
Les utilisateurs
Chaque type de personne qui l’utilisera : clients, personnel, gestionnaires, administrateurs, partenaires. Pour chacun, les trois à cinq choses qu’il doit pouvoir faire.
- 03
Les écrans
Une liste approximative des pages ou des écrans. Elle n’a pas besoin d’être juste; elle doit exister. Les écrans sont la mesure de taille la plus claire qui soit.
- 04
Les intégrations
Chaque système avec lequel il doit communiquer : comptabilité, CRM, ERP, fournisseur de paiement, courriel, authentification unique, API d’un partenaire. Nommez le produit et sa version si vous les connaissez.
- 05
Les données
Ce qu’il conserve, à peu près en quelle quantité, si une partie est personnelle ou réglementée, et si des données existantes doivent être migrées d’un ancien système.
- 06
Les plateformes
Le web seulement, ou aussi des applications iOS et Android. Quels navigateurs et appareils comptent. S’il doit fonctionner hors ligne.
- 07
Les contraintes
Les échéances réelles (un événement de lancement, une date réglementaire) et celles qui ne sont que des préférences. Les exigences d’hébergement, comme des données gardées au Canada. Les exigences d’accessibilité et de langues.
- 08
Ce qui existe déjà
Des maquettes, un guide de marque, un ancien système, un prototype, de la documentation. Chacun peut épargner du travail, ou en créer.
- 09
Après le lancement
Qui l’exploitera, qui soutiendra les utilisateurs, et si vous voulez un plan de soutien ou que votre propre équipe prenne le relais.
- 10
Une fourchette de budget
Cela ressemble à un risque de négociation, mais c’est le moyen le plus rapide de savoir si votre idée entre dans le cadre, et quoi couper sinon. Un bon studio vous dira ce qui est réaliste à l’intérieur.
Comptez écrans et utilisateurs
C’est dans les listes de fonctions que les mandats dérapent. « Gestion des utilisateurs » peut vouloir dire une page de connexion ou tout un système de rôles, d’invitations, d’approbations et de journaux d’audit. Une liste d’utilisateurs et d’écrans se lit plus difficilement de travers, parce que chaque écran doit être conçu, construit et testé, et que chaque type d’utilisateur ajoute des permissions à chacun d’eux.
| Qui | Les écrans utilisés |
|---|---|
| Client | Inscription, connexion, parcourir les services, réserver un créneau, payer, mes réservations, annuler ou déplacer, profil |
| Personnel | Horaire du jour, détails d’une réservation, marquer la présence, notes sur un client |
| Gestionnaire | Calendrier du personnel, services et prix, heures d’ouverture, rapports |
| Administrateur | Utilisateurs et rôles, réglages, fournisseur de paiement, modèles de courriels |
Une vingtaine d’écrans et quatre types d’utilisateurs, écrits en cinq minutes, en disent plus à un studio que trois pages de descriptions de fonctions. Si vous ne savez pas si quelque chose fait un écran ou deux, dites-le; c’est une bonne question pour le premier appel.
Nommez intégrations et sources de données
C’est dans les intégrations que les estimations dérapent le plus souvent, parce que l’autre système échappe au contrôle de tout le monde. Sa documentation peut être périmée, son environnement de test peut ne pas exister, et ses limites peuvent n’apparaître qu’en usage réel. Un mandat qui nomme chaque intégration permet au studio de vérifier chacune avant de chiffrer, plutôt que de la découvrir au deuxième mois.
- Nommez le produit : « QuickBooks en ligne » plutôt que « notre logiciel comptable ».
- Précisez dans quel sens circulent les données : lecture seule, écriture seule ou les deux, et à quelle fréquence.
- Indiquez si vous avez déjà un accès à l’API, ou qui devrait l’accorder.
- Mentionnez toute migration de données depuis un ancien système, avec un ordre de grandeur du nombre d’enregistrements et leur état de propreté présumé.
Énoncez clairement les contraintes
Les contraintes changent le travail plus que la plupart des fonctions : mettez-les par écrit, même quand elles semblent évidentes.
- L’accessibilité : si le logiciel est public, dites quel niveau il vous faut. Les règles d’accessibilité du W3C définissent les niveaux A, AA et AAA [1], et en nommer un transforme un souhait vague en exigence qui peut être chiffrée et testée.
- La confidentialité : s’il contient des renseignements personnels, dites-le. La LPRPDE canadienne repose sur des principes relatifs à l’équité dans le traitement de l’information, comme le consentement, la limitation de la collecte, les mesures de sécurité et l’accès aux renseignements personnels [2]. Vos conseillers peuvent vous dire ce qui s’applique; le studio doit savoir que cela s’applique.
- Les données réglementées : les données de santé, financières ou gouvernementales ont leurs propres règles. Mentionnez-les dès la première conversation, pas après la soumission.
- L’hébergement : si les données doivent rester au Canada, si vous avez un fournisseur infonuagique préféré, ou si le tout doit tourner sur vos propres serveurs.
- Les langues : le français et l’anglais dès le premier jour, c’est un autre projet que l’anglais maintenant et le français plus tard.
- Les échéances : quelles dates sont fixes, et pourquoi.
Ce qu’il faut laisser de côté
Un mandat n’est ni une maquette ni un cahier des charges technique, et tenter d’en écrire un se retourne habituellement contre vous.
- Laissez de côté la technologie, sauf si c’est une vraie contrainte (votre équipe exploite déjà certains outils, ou un organisme de réglementation exige un certain hébergeur). Laissez le studio proposer son choix et l’expliquer.
- Laissez de côté les maquettes détaillées, à moins de les avoir déjà. Un croquis d’un écran important aide; une maquette au pixel près de chaque écran fige des décisions avant que quiconque les ait testées.
- Laissez de côté les fonctions dont vous n’êtes pas sûr, ou listez-les à part sous « plus tard ». Une soumission gonflée de peut-être se compare plus mal.
- Laissez de côté les détails confidentiels que vous n’avez pas encore besoin de partager. Un studio peut chiffrer à partir de la forme du problème; il n’a pas besoin des noms de vos clients ni de vos résultats financiers.
Un mandat, transformé en estimation
Le portail de réservation du tableau ci-dessus, avec une application web, des applications iOS et Android, des paiements par carte, une connexion au système comptable du client, le français et l’anglais, et des renseignements personnels, ressemble à ceci dans notre estimateur. L’exemple ci-dessous montre la fourchette selon notre grille tarifaire d’aujourd’hui, avec les heures par rôle et l’échéancier de paiement.
Exemple chiffré en direct
Un portail de réservation à partir d’un mandat d’une page
Une vingtaine d’écrans sur le web, iOS et Android pour les clients, le personnel, les gestionnaires et les administrateurs, avec paiements, intégration comptable, avis, en français et en anglais.
- Développement
- ≈ 99 100 USD à 152 000 USD, livré en 27 semaines au plus141 100 $ CA à 215 800 $ CA
Les prix dans votre devise sont des estimations au taux du jour de la Banque du Canada. Toute la facturation se fait en CAD ou en USD.
Effort estimé par rôle
- Développement
- 539 à 824 h
- Concepteur de produits
- 101 à 154 h
- Gestionnaire de projet
- 75 à 115 h
- Concepteur de produits principal
- 67 à 103 h
- Développeur dorsal principal
- 67 à 102 h
- Ingénieur assurance qualité
- 63 à 97 h
- Développeur dorsal
- 62 à 95 h
- Développeur frontal
- 61 à 94 h
- Ingénieur principal
- 40 à 62 h
- Développeur frontal principal
- 37 à 56 h
- Architecte logiciel
- 36 à 55 h
- Développeur mobile
- 34 à 52 h
- Développeur dorsal junior
- 31 à 47 h
- Développeur mobile principal
- 27 à 41 h
- Développeur frontal junior
- 25 à 38 h
- Développeur mobile junior
- 15 à 23 h
- Ingénieur DevOps
- 13 à 20 h
- Rédacteur technique
- 11 à 17 h
Modalités de paiement
- Acompte 20 %
- 28 220 $ CA à 43 160 $ CA
- Découverte 9,2 %
- 12 981,20 $ CA à 19 853,60 $ CA
- Maquettes approuvées 9,2 %
- 12 981,20 $ CA à 19 853,60 $ CA
- Fonctions principales 7,6 %
- 10 723,60 $ CA à 16 400,80 $ CA
- Développement complet 5 %
- 7 055 $ CA à 10 790 $ CA
- Première version sur appareils 20,1 %
- 28 361,10 $ CA à 43 375,80 $ CA
- Tests et corrections 2,5 %
- 3 527,50 $ CA à 5 395,00 $ CA
- Soumission aux boutiques 6,7 %
- 9 453,70 $ CA à 14 458,60 $ CA
- Mise en ligne 9,7 %
- 13 686,70 $ CA à 20 932,60 $ CA
- Retenue, 30 jours après la mise en ligne (10 %)
- 14 110 $ CA à 21 580 $ CA
Ouvrez-le dans l’estimateur et changez une réponse à la fois : retirez les applications mobiles, ajoutez des mises à jour en temps réel, passez à un design standard. Voir la fourchette bouger est le moyen le plus rapide de comprendre quelles parties de votre propre mandat comptent le plus.
Envoyer le même mandat à plusieurs studios
Obtenir plus d’une soumission est sensé, et c’est un mandat écrit qui les rend comparables. Envoyez le même document à chaque studio, répondez par écrit aux questions de chacun et transmettez chaque réponse à tous. Sinon, le studio qui a posé la meilleure question obtient le portrait le plus juste, et sa soumission paraît moins bonne parce qu’elle est honnête.
- Demandez à chaque studio la liste des hypothèses derrière son chiffre, et comparez-les avant les totaux.
- Demandez les heures par rôle, pour voir si les tests, le design et la gestion de projet sont inclus.
- Demandez ce qui est exclu : l’hébergement, le soutien, les frais de tiers, le contenu et la migration des données.
- Méfiez-vous d’une soumission bien en dessous des autres. Cela veut habituellement dire qu’une partie du mandat a été lue autrement, ou oubliée.
Un modèle d’une page
- Le nom du projet et une phrase sur ce qu’il est.
- Le problème actuel, en un paragraphe.
- Les utilisateurs : chaque type, avec les trois à cinq choses qu’il doit faire.
- Les écrans : une liste approximative, regroupée par utilisateur.
- Les intégrations : chaque système, le sens des données et si l’accès existe.
- Les données : ce qui est conservé, si c’est personnel ou réglementé, et toute migration.
- Les plateformes : web, iOS, Android, hors ligne.
- Les contraintes : échéances, hébergement, accessibilité, langues, conformité.
- Ce qui existe : maquettes, marque, anciens systèmes, documents.
- Après le lancement : qui l’exploite et qui le soutient.
- La fourchette de budget, et ce qui compte le plus s’il faut faire des choix.
Ce qui se passe après l’envoi
- 01
Des questions
Nous lisons le mandat et revenons avec les questions qu’il soulève, habituellement sur les intégrations, les données et les rôles des utilisateurs.
- 02
Une estimation avec ses hypothèses
Vous recevez une fourchette, les heures par rôle et la liste des hypothèses sur lesquelles elle repose, pour voir exactement ce qui a été chiffré.
- 03
La découverte
Si vous allez de l’avant, la première étape confirme en détail les écrans, les intégrations et les données, et la fourchette se resserre en un prix fixe pour le développement.
- 04
Des changements chiffrés avant le travail
Tout ce qui change ensuite fait l’objet d’une demande de modification approuvée avant tout travail.