Plusieurs étapes dans un logiciel, une application web ou une application mobile, se retrouvent dans le devis ou la proposition commerciale que vous avez proposée votre prestataire informatique. Il arrive que vous y trouviez une ligne, souvent assez conséquente : Tests et qualité logicielle. Pourquoi devoir penser à la qualité de votre logiciel, de votre application mobile, ou votre application web ?
L’image du développement informatique est souvent ternie par :
Il est bien difficile de faire confiance à son prestataire informatique pour créer, développer des applications sur-mesures, ou même créer un site web avec wordpress.
La confiance a été abîmée, et la méfiance est bien souvent au rendez-vous.
Il est vrai qu’un bon pourcentage des bugs vient des développeurs et développeuses.
On les dit étourdis, ne comprenant pas les besoins clients, allant trop vite, ne testant pas assez.
Attardons-nous sur la non compréhension des besoins clients.
Lorsqu’on a un métier, on a une idée en tête, et on a bien souvent des difficultés à exprimer ce que l’on veut vraiment.
On va décrire son projet comme « identique à Uber », ou bien « vous prenez cette application, et c’est identique ».
Et pourtant votre business, ce qui fait que vous êtes unique sur le marché, est aussi votre force.
Ces spécificités se retrouveront dans votre application, votre site web, e-commerce.
Or, votre prestataire pour bien comprendre ce que vous souhaitez va avoir besoin d’analyser vos besoins.
Combien de fois, je comprends le logiciel grâce à des échanges téléphoniques, des réponses à des mails !
Et pour tout vous dire, j’en suis très heureux : le client échange, réfléchit, et est capable de poser des mots sur ce qu’il attend du logiciel.
Pour penser à la qualité de votre logiciel, de votre site web, ou votre application mobile, écrire vos attentes, ce qu’il faut dans l’outil, l’application, il est préférable de tout rédiger dans un cahier des charges.
Même si c’est sommaire, sa présence a le mérite de commencer à cadrer ce qui est attendu.
Souvent le client demande une ferrari, alors qu’il n’a besoin que d’une berline normale
Et ça amène sinon à des demandes comme celles décrites plus haut : « un site comme Uber », ou bien « faire un e-commerce comme Amazon ».
Bien rédiger un cahier des charges ça s’apprend.
Pourtant l’essentiel, c’est de réfléchir, avec votre prestataire, en amont de toute fonctionnalité à créer.
Et surtout de cadrer, d’accepter de ne pas tout faire.
Se concentrer sur les 20% qui seront utilisées par 80% des utilisateurs, qui rapportent d’abord 80% de votre CA.
Si le triptyque suivant n’est pas respecté, des bugs, dits fonctionnels, donc inhérents à une mauvaise compréhension fonctionnelle, à une découverte tardive des besoins (du client et / ou du prestataire), vont apparaître dans votre application.
Triptyque à respecter :
Il existe également des bugs qui sont causés par le stress, par le rythme imposé par le projet, par le client, … (il existe de nombreuses raisons).
Je vous offre ce cahier de recette !
Avec ce cahier de spécification fonctionnel, vous pourrez :
Or, ce stress est tout sauf bénéfique, comme certaines ou certains pourrait le croire.
Il va engendrer :
Bien sûr, il existe aussi de mauvais développeurs, mauvaises développeuses qui ne savent pas bien coder, qui ne respectent pas les patrons de conception, qui n’appliquent pas des principes DRY.
Ceux là, bien sûr, il ne faut pas travailler avec eux.
Mais c’est comme dans tout métier, il existe un pourcentage (<= 10% en moyenne) qui ne devrait pas proposer de services à leurs clients.
Je vous pose la question : est-ce que 90% des prestataires doivent payer pour moins de 10% de mauvais prestataires ?
Je ne pense pas.
Si vous trouvez une ligne dans la proposition commerciale de votre prestataire, du type :
Surtout, ne demandez pas à la supprimer !
Cette ligne vous assure qu’un engagement est pris par votre prestataire pour tendre vers une grande qualité logicielle.
La qualité a toujours un coût
Saviez-vous, par exemple, qu’elle peut représenter pour les logiciels ou applications les plus complexes, plus de 50% de surcoût ?
Ainsi, pour un logiciel de 10 000 euros, il vous coûtera en fait 15 000 euros.
Le premier réflexe sera donc de demander à le supprimer, dans le pire des cas.
Mais on a bien souvent une configuration où le client demande à rogner sur cette ligne.
La négociation d’un devis pour créer un logiciel, une application passe hélas bien souvent par cette ligne.
Il faut réussir à penser la qualité logicielle comme un investissement !
Vous acceptez alors de perdre en qualité logicielle.
Attention, cela ne veut pas surtout pas dire qu’il faut tout le temps un surcoût de 50% pour assurer une qualité optimale de votre logicielle.
Une qualité optimale, exhaustive n’existe que dans la théorie.
Vous avez un budget, et avec ce budget, des directives, des choix à faire :
Alors comment faire pour s’assurer un minima d’avoir un logiciel de qualité, et qui répond bien à vos attentes, à vos besoins ?
Grâce au cahier de recette, au cahier de tests fonctionnels, vous allez pouvoir réagir sur l’une des causes de bugs : la mauvaise compréhension des attentes.
Le cahier de recette, parfois proposé par votre prestataire en développement informatique, va vous aider, le prestataire et vous-même, à bien spécifier toutes les attentes, pour tous les scénarios possibles.
Vous y retrouverez :
![[Formation] - Recette - Patron conception - Google Sheets - Google Chrome](https://i1.wp.com/evanboissonnot.fr/wp-content/uploads/2018/01/Formation-Recette-Patron-conception-Google-Sheets-Google-Chrome.jpg?resize=900%2C111)
Je vous offre ce cahier de recette !
Avec ce cahier de spécification fonctionnel, vous pourrez :
Il peut servir de base contractuelle pour décider d’une livraison en production.
Par exemple, même si 70% des tests sont validés, vous pourrez statuer avec le prestataire pour une livraison en production.
C’est un contrat gagnant / gagnant entre vous et votre prestataire, pour le bien de votre application, de votre application mobile ou votre e-commerce, et aussi pour les utilisateurs finaux !
L’idéal serait qu’il remplace même le cahier des charges.
Mais il est bien difficile de décrire proprement les besoins, les attentes, les scénarios sans déjà avoir réfléchi à ce que vous souhaitez vraiment dans votre application web ou mobile, votre logiciel.
En tout cas respectez toujours les règles suivantes :
Une exception à prendre en compte tout de même :
Attention, le prestataire ne peut pas décider sans vous de cette exception. Et c’est une exception qui est validée mutuellement.
Et vous, avez-vous déjà mis en place ce cahier de recette avec votre prestataire informatique ?
Découvrons ensemble une méthode pour amener un code de qualité. Car bien coder, c’est bien, mais coder sans penser au reste de l’application, ça amène des risques forts pour tout le projet,
Comment réussir à bien estimer, alors que vous ne connaissez même pas ce que vous allez devoir réaliser ? Comment bien estimer un planning de tests, pour assurer la qualité de votre
One thought on “Comment un demi va vous aider à mieux communiquer? Découvrons la règle du demi”
Amazing YouTube video lessons posted at this website, I am going to subscribe for regularly updates, since I don’t want to fail to take this series.