Mon idée sera un excellent projet web #4 : les bons ingrédients d'une bonne recette

Votre projet est sur des rails. Votre prestataire, ce héros, cravache fort et semble bien gérer la situation. Semble ?

Cet article est le 4ème épisode de la série "Mon idée sera un excellent projet web". Au niveau où vous êtes, vous avez déjà trouvé votre prestataire ! Si ce n'est pas le cas, vous êtes invités à lire les deux premières étapes de cette suite d'articles :

• Mon idée sera un excellent projet web #1 : Définir son prototype
• Mon idée sera un excellent projet web #2 : Le cahier des charges
• Mon idée sera un excellent projet web #3 : Mon prestataire sera un héros
• Mon idée sera un excellent projet web #4 : les bons ingrédients d'une bonne recette

Des outils pour suivre les développements

Normalement, vous devez à cette étape, avoir une adresse de staging/dev pour votre projet fournie par votre prestataire.

Vérifiez rapidement qu'elle soit bien protégée en accès par une restriction utilisateur/mot de passe. C'est important de se préserver des potentielles fuites mais surtout d'une indexation accidentelle par les moteurs de recherche.

Vérifiez aussi que cet environnement de développement soit bien séparé de votre production (sur deux serveurs distincts). En effet, cela vous garantira une base vierge et un serveur sain le jour J. C'est aussi le meilleur moyen d'éviter des contaminations inappropriés entre vos deux environnements.

Votre prestataire vous fournira un accès à une solution de ticketing du type Jira ou Redmine. Cet outil sera essentiel pour suivre les développements et échanger avec l'équipe technique.

@ Ne sous-estimez pas cette partie qui va vous permettre d'optimiser d'une manière considérable le temps de développement en évitant des potentielles dérives ou incompréhension.

Oui, les échanges sont nécessaires. Oui, vous devrez être rigoureux dans vos retours. Non, vous ne devez pas tout contrôler !

Il est ici question d'équilibre et de trouver la bonne posture dans le suivi du projet et pour cela soyez réactif ! Répondez le plus précisément possible et venez aux nouvelles régulièrement.

Programmez donc dès le départ des points téléphoniques par Skype (par exemple ?) et ainsi balayer 90% des quiproquos, des zones d'ombre et le moindre blocage.

@ Retenez une chose : la majorité des retours lors de la phase de recette sont généralement dû à une mauvaise compréhension ou explication entre le client et le prestataire lors de la phase de briefing.

Je ne comprends pas (toujours) mon prestataire

C'est classique ; Votre prestataire a tendance à parler et analyser vos problématiques avec sa vision technique, alors que vous parlez avec votre vision métier.

Ainsi, de chaque côté, un effort est nécessaire pour "passer l'information" à l'autre. Cet effort doit être démultiplié lorsque le projet est très "métier" et très "complexe".

@ Dans une situation de blocage ou de conflit, les torts se trouvent souvent partagés entre vous et votre prestataire.

Pour améliorer ces situations, épurez le plus possible votre discours, couchez sur papier le plus possible, et enfin, schématisez, schématisez et schématisez....

• Comment s'affichera cette fonctionnalité?
• Que verra l'utilisateur si il clique sur ce bouton ?
• Que pourra-t-il faire ensuite?

Autant de questions qui vous paraissent claires mais qui nécessitent un effort de déchiffrage.

@ Décrivez vos règles métiers même si elles vous paraissent logiques, nettoyez votre discours des abréviations et des termes techniques et enfin, clarifiez votre lexique (un onglet n'est pas un menu, un bandeau n'est pas un fil d'Ariane....).

^ Ces conseils, je le rappelle, valent autant pour le prestataire que pour le client !

Enfin, si votre prestataire vous fait le coup du "on va mettre en place un workflow à base d'un broker rabbit consommé par un worker node ok?" c'est qu'il est temps de lui faire lire cet article.

Je recette et je ne suis pas content

Oui. La phase de recette est ingrate. C'est juste un mauvais moment à passer mais qui est clairement nécessaire.

Votre prestataire pensera (mais ne vous le dira pas) sûrement la même chose. Pour vivre ce moment d'une manière positive, voici quelques conseils.

• Soyez précis dans vos retours. Pas de "j'ai une erreur" mais plutôt "quand je clique ici une erreur s'affiche avec le message xxxx"
• Décrivez le plus possible l'environnement de test (navigateur, OS, utilisateur connecté/non connecté...). Plus ces informations seront précises et plus la solution sera rapide à trouver.
• Évaluez le degré du bug versus la complexité de la fonctionnalité pour donner une priorité à votre demande.
• Faites un point méthodologie pour vérifier que le prestataire travaille dans la bonne direction et surtout qu'il a tous les éléments pour bien travailler.

Si vous constatez que les développements n'avancent pas correctement et qu'il y a beaucoup de régressions dans le code, informez au plus vite votre prestataire et n'attendez pas que la situation s'aggrave.

@ Si vous êtes satisfait du travail et que le projet avance vite. Il ne vous est pas interdit d'exprimer votre satisfaction à votre prestataire.

Si vous avez choisi de mettre en place des tests fonctionnels ou unitaires (on l'espère), vous devriez pouvoir demander qu'ils soient rattachés au processus de développement pour vous assurer un minimum de stabilité.

Pour finir, si votre méthode de développement est proche de l'agile, vous aurez forcément des sprints. Vos tests seront essentiels et vous engagent personnellement dans le processus de développement et de qualité.

Les dernières étapes vers le live

À partir de la livraison du dernier sprint, vous allez rentrer dans la phase alpha. Toutes les fonctionnalités v1 sont développées, il s'agit maintenant de peaufiner l'ensemble.

Un travail minutieux vous attend pour tester les interfaces, stresser le site et penser aux multiples manipulations qu'un utilisateur pourrait effectuer (même si cette étape à déjà été imaginée avant, hein ?).

Mettez ensuite en place un groupe de testeurs (piochez dans vos amis) et encouragez les à exprimer pleinement leurs ressentis. Vous aurez forcément l'occasion de rectifier certaines ergonomies ou wordings.

Passée cette étape, votre projet rentre en phase beta : vous pouvez l'ouvrir aux utilisateurs/testeurs lors d'une phase intermédiaire.

Si au cours de cette expérience, vous relevez beaucoup de retours similaires, prenez le temps de faire travailler votre prestataire sur un lot de nouvelles fonctionnalités dans ce sens.

@ Un projet web ne peut être figé ; il est vivant. Cette recommandation est encore plus vraie lorsque votre activité est centrée autour d'une application ou d'un site web. Prévoyez dès le départ un budget pour maintenir et faire évoluer régulièrement votre projet.

Enfin, vous êtes aux portes du succès (on l'espère). On vous livre nos derniers conseils pour ne pas faire d'erreurs dans cette dernière ligne droite :

• Oui mon fichier robots.txt ne contient pas un Disallow: /
• J'ai un joli favicon personnalisé (ça fait plus pro)
• J'ai à minima une procédure de backup et de recovery.
• La procédure de déploiement est bien rodée et n'engendre pas (ou très peu) de downtime (temps de coupure)
• J'ai un système qui vérifie et alerte la disponibilité de mon site
• J'ai un contenu suffisant et surtout pas de lorem ipsum qui reste sur mon site

Et vous ? Vous avez d'autres points points à checker ?

Ainsi se termine notre petite série "Mon idée sera un excellent projet web" que nous avons souhaitée facile d'accès et remplie de conseils pratiques. Si vous avez des questions de méthodologie ou des interrogations su un projet que vous souhaitez développer ? Venez prendre un café !