Comment évaluer et analyser un projet existant pour le reprendre

Table des matières

Comment évaluer et analyser un projet existant pour le reprendre

Il y a quelques jours, j’ai eu l’incroyable mission d’analyser un projet existant d’un client dans le télésecrétariat médical et réalisé par un développeur Freelance.

Je vous mets un peu dans le contexte. La problématique est la suivante : le projet est dans une impasse. Il est loin d’être fini et surtout loin d’être en production.

Le dialogue entre le Freelance et le client est un dialogue de sourds. Chacun campe sur ses positions.

Le client ne veut pas payer ce qu’il lui reste à payer et le Freelance ne veut plus rien faire, car il en a tout simplement marre et il réclame le reste de son argent.

Je ne vais pas rentrer dans les détails, mais on a réussi à désamorcer la situation entre les 2 et on a obtenu le code source de l’application de la part du Freelance.

Mieux encore on a évalué rapidement avec le client ce que l’application doit faire pour lui et le Freelance nous a expliqué concrètement comment fonctionne l’application qu’il a codée.

Le souhait du client ? Trouver un nouveau partenaire (on n’aime pas trop le mot prestataire) qui pourra reprendre leur projet pour faire en sorte qu’il fonctionne et qu’il soit conforme suivant leurs demandes.

Et c’est là que j’interviens dans l’histoire. Analyser ce qui a été effectué par le Freelance et évaluer si la reprise sera possible de notre côté.

Je vais vous communiquer les étapes par lesquelles on est passé pour réaliser ce travail et donner une conclusion à notre client. Attention ! Il y a quelques légers coups de gueule dans l’article.

Un argument qui n’en ait pas un

Vous avez peut-être bloqué sur ces derniers mots « si la reprise sera possible ». Le Freelance a choisi de travailler avec un framework PHP nommé Laravel.

Ce qui est un très bon choix techniquement, car c’est un bon framework et une valeur sûre. Le projet est donc en PHP/MySQL/Redis, des langages web quoi.

Et vous vous dîtes sûrement ? OK, tu es développeur web, le PHP/MySQL tu connais alors tu peux reprendre ?

Bah non, cela ne veut strictement rien dire !

Ce n’est pas parce que je connais très bien cet environnement et que techniquement je saurais le reprendre qu’on pourra le reprendre. C’est d’ailleurs ce genre d’argumentaires qui me révoltent. Ils sont tout à fait légitimes, mais ils sonnent tellement faux et ils ont juste une forme, mais pas de fond.

C’est d’autant plus navrant de voir ce genre d’argumentaire pour vendre un projet web et je parle en connaissance de cause, puisque où je travaillais avan, c’était le genre d’argument que l’on avançait.

«  Le PHP/MySQL sont des technologies Open Source, populaires et standard sur le marché. Énormément de développeurs sur le marché dans ses technologies. Votre projet pourra donc toujours évoluer même si ce n’est pas nous qui intervenons, ça vous donne une certaine sécurité et une stabilité dans le temps. »

C’est du bullshit et rien d’autre ! Parce que ça ne veut rien dire !

Le client s’en fout complètement que ce soit des technologies populaires ou un standard sur le marché. Il n’a pas besoin d’entendre ça.

Il a besoin au contraire d’entendre que son projet sera fait dans les règles de l’art, c’est à dire bien coder, bien documenter tant techniquement que niveau utilisateur permettant ainsi une compréhension et un passage de flambeau sans embûche.

Ça, c’est de l’argument parce que c’est professionnel et ça respecte non seulement votre travail, mais également le client.

Alors vous doutez bien que bien entendu tout ce que je viens de vous dire ce projet ne respecte aucun de ces critères. Il est donc temps d’entrer dans le détail.

La première chose à faire : se retrouver avec le client pour qu’il nous explique son projet

La première chose à faire c’est de faire une réunion avec le client pour évaluer et comprendre son projet. Il doit vous expliquer en détail ces enjeux et pourquoi il a fait ce projet. C’est vraiment le point de départ et peu importe la situation ou le contexte.

Que ce soit pour auditer, pour rajouter une fonctionnalité ou pour reprendre un projet en cours comme c’est notre cas.

Il doit vous expliquer ce que fait son application ou ce qu’elle est censée faire. Le premier point est de comprendre le concept du projet.

N’hésitez pas à rentrer dès le début dans le détail pour vraiment bien comprendre. Et profitez-en d’ailleurs pour répertorier tout ce qu’elle fait, mais également ce qu’elle est censée faire et ce qu’elle doit faire dans l’avenir (si le client vient avec ces nouvelles demandes).

Le mieux pour tout répertorier et avoir une vision claire de tout ça c’est de faire un MindMap.

Pour le coup, nous avons aussi eu affaire au Freelance en charge du projet. Car le projet est toujours en cours, je vous le rappelle.

Suivant le contexte, l’ancien Freelance ne sera pas nécessaire surtout si l’application est en production et pas très sûre que vous aurez la chance, comme nous, d’avoir le ou les développeurs qui ont réalisé le projet.

Mais à la limite ce n’est pas grave c’est juste qu’au niveau de notre contexte, c’est vraiment un atout de l’avoir pour la réunion.

Ce sera aussi l’occasion de demander sur l’infrastructure technique de l’application : où elle est hébergé, sur quelles technos elle tourne et si l’accès au code source est facilement accessible.

Le mieux est de vous faire une check-list pour ne rien oublier. En voici une non exhaustive pour ne pas oublier une information :

1. Explication du projet par le client
   1. Pourquoi ce projet ?
   2. Ses enjeux
2. Que veut-il faire exactement ?
3. Challenger sa ou ses demandes
4. Qu’attend-il de moi ?
5. Cartographier l’application pour bien s’immerger
6. Guide utilisateur ?
7. Demander les informations techniques essentielles : technos/infrastructure utilisées, accès aux codes sources, à la base de données, etc.

Ce que l’application est censée faire, ce qu’elle fait et ce qu’elle fait réellement

source : http://www.commitstrip.com/fr/2013/07/23/de-limportance-de-la-passation-de-projet/

On a dû faire quelque chose en plus. Vu que l’on est dans une éventualité de reprise d’un projet en cours, il est important de faire un état des lieux afin de pouvoir croiser les informations et en tirer des conclusions.

En prime on a permis de permettre aux différentes parties de s’exprimer et désamorcer les tensions (ou pas).

On a donc recensé en MindMap ce que le client veut pour son application (ce qu’elle est censée faire). Puis on a écouté le développeur nous expliquer ce que fais l’application qu’il a codait (ce que l’application fait actuellement) et la dernière étape c’est à nous de la faire un peu plus tard.

C’est parcourir techniquement ce que fait vraiment l’application en ce faisant notre propre avis.

Grâce à cet exercice redoutablement efficace, vous allez pouvoir voir tout de suite ce qui va et ce qui ne va pas. Vous pourrez ainsi estimer au plus juste si le projet est conforme aux attentes du client et donc s’il y aura beaucoup de travail pour remettre en ordre l’application.

Je peux déjà vous dire qu’entre ce que le client nous a expliqué et ce que le développeur nous a fait comme démonstration et explication, il y avait un grand fossé entre les 2. L’analyse technique n’a fait que confirmer nos doutes (j’y reviens un peu plus tard).

La deuxième chose à faire : analyser le projet existant

Il est temps de mettre les mains dans le cambouis comme on dit ! Il faut faire sa propre analyse (la 3e partie de la cartographie) pour ensuite croiser l’ensemble et en tirer des conclusions.

La première chose à faire c’est d’installer l’application et l’utiliser d’un point de vue utilisateur. Pour l’installation, pas vraiment de problème.

C’est un Laravel donc il suffit de suivre la documentation du framework pour lancer le projet. Puis on vient à l’utilisation et là, c’est le drame ! Je ne vais pas rentrer dans tous les détails, mais beaucoup de choses ne vont pas.

Beaucoup de détails, mais qui ont leur importance et qui ne m’ont pas permis de tester l’ensemble de l’application correctement :

• un champ en base de données manquant
• un champ qui n’a pas de valeur par défaut
• l’impossibilité d’enregistrer certains formulaires car un champ n’est pas rempli mais qui n’existe pas dans le formulaire
• une liste qui ne liste rien malgré que l’on vient de créer un enregistrement…

La liste est longue, très longue ! Mais les 2 choses les plus choquantes sont les suivantes :

• Lors de nos réunions avec le client, nous avons capté l’élément central qui doit être au milieu de  l’application (dans notre contexte ce sont les patients). Sans cet élément, l’application n’a pas de sens et n’aurait pas lieu d’exister. L’application contient bien une notion de patient, mais elle ne fait rien concrètement donc c’est pas bon signe pour la suite des choses, car cet élément n’est pas assez considéré. En clair, on sent nettement que c’est une véritable erreur de conception.
• La gestion des rôles et des permissions est tout simplement bancale et incompréhensible. Dans Laravel, on a un rôle qui se nomme « super-admin ». Cela sous-entend que si je suis « super-admin », je peux tout voir et surtout tout faire dans l’application. Et bien ici ce n’est pas du tout le cas. Même avec ce rôle, je n’avais pas accès à grand-chose. En creusant de manière plus technique, j’ai alors remarqué qu’il existe une notion de type d’utilisateur. Et en jouant avec les rôles et les types d’utilisateurs, on arrive à plus ou moins avoir accès à tout. Un sacré bordel je trouve.

Tout cela pour vous dire que mon constat global est le suivant : le code reste assez lisible et bien construit (en même temps c’est un framework bien construit, mais au final on s’aperçoit que l’application ne fait pas grand-chose), la conception de l’application et de la base de données a été très mal pensée.

J’irais même jusqu’à dire qu’elle n’a pas été réfléchie du tout. Cela sent l’amateurisme à plein nez. Pour imager, j’avais l’impression d’avoir un projet personnel d’un développeur débutant que venait à peine de débuter.

On voit tout de suite que le projet était bien trop ambitieux pour ce développeur Freelance et c’est dommage, car c’est le client qui subit (le Freelance ayant touché une grosse partie de ce qu’il avait budgété).

Vous comprenez que mon avis concernant la reprise du projet est plus que mitigé, mais il ne faut s’arrêter là.

Si vous voyez que la reprise va être très compliquée

Si vous vous retrouvez dans la même situation que moi, que vous voyez que ça va être assez casse-gueule à reprendre et à faire évoluer alors ce qui va suivre va peut-être vous intéresser. Vous ne pouvez pas simplement dire au client, ce n’est pas pour moi et je ne touche pas à ce truc-là, car tout est à jeter.

Non vous devez argumenter et donner un avis pertinent sur cette non-reprise. Et le plus simple, mais aussi le plus stratégique c’est de proposer 2 solutions :

• La première c’est de déployer un plan d’action à réaliser en répondant à cette question : « admettons que je reprenne quand même le projet pour le continuer, le faire évoluer ou autre. Que dois-je mettre en oeuvre en premier lieu afin de pouvoir réaliser ce que demande le client de manière la plus correcte possible ». Dans notre cas, le plan d’action serait très simple : remettre en ordre ce qui ne fonctionne pas, solutionner toutes les erreurs de conception qui existent dans l’application, remettre en conformité les parties de l’application par rapport à la demande du client et enfin poursuivre le développement.
• La deuxième c’est un plan d’action en partant du principe de repartir de zéro : Atelier avec le client pour bien définir et brainstormer chaque partie de son application et la réaliser tout simplement

Et de confronter les deux pour y apporter les bons arguments. On ne peut pas dire au client : vous avez claqué de l’argent dans le vide. Il faut quand même le valoriser en termes d’expérience.

Le client sait maintenant que son projet est beaucoup plus complexe qu’il ne le pensait, que ça prendra beaucoup plus de temps et que la méthode de travail adopté par le Freelance n’est pas la bonne et ne lui correspond pas.

Il en ressort certainement de cette expérience que le client sait un peu plus précisément ce qu’il veut exactement.

En tout cas, reprendre techniquement le projet actuel sera très fastidieux et un vrai casse-tête. On pense que l’on passera autant de temps à nettoyer le projet existant et à le faire évoluer qu’à recommencer d’une page blanche.

La dernière chose à faire : annoncer la bonne ou la mauvaise nouvelle au client

Concrètement si tous les voyants sont au vert alors vous pouvez y aller. Non seulement vous aurez une vision extrêmement claire et précise de chacune des parties du projet, mais vous aurez non seulement une grande plus-value à apporter à votre client en plus de ses demandes.

Vous monterez que vous êtes très organisé, très engagé et très professionnel, mais en plus de cela, le fait d’avoir cartographié l’application de votre client sera un bonus pour lui.

Vous ne gagnerez que des points pour le bon déroulement du projet, mais en plus de cela vous serez capable d’estimer au plus juste le temps pour réaliser ce que demande votre client.

Dans le cas contraire où les voyants sont au rouge (comme c’est mon cas), vous devez être honnête et complètement transparent avec le client. Si vous avez plusieurs options à lui proposer alors, proposez-lui en faisant bien la distinction entre les 2 et en apportant vos arguments pour lui conseiller la meilleure solution.

Si votre argumentaire ne fait pas mouche et que vous estimez que cela va à l’encontre de vos valeurs et que vous risquez de vous tirer une balle dans le pied en acceptant cette mission, alors refuser tout simplement.

Cela ne sert à rien de vous faire violence pour une mission qui ne vous correspond pas et dont vous m’en tirerez rien. Ce qu’on a prévu de faire pour notre client en tous cas, mais on étudie d’autres alternatives pour ne pas le décevoir.

Epilogue

Je vous ai fait l’épopée d’un projet dans le but de le reprendre, mais il peut s’appliquer dans le cas d’un projet existant et que vous devez faire évoluer. Les étapes sont quasiment les mêmes et peuvent être appliquées.

Je vous remets les étapes clés à suivre pour mettre toutes les chances de votre côté tout en minimisant les risques :

• Faire une réunion pour découvrir le projet et en profiter pour tout cartographier pour avoir une vue d’ensemble.
• Profitez de la réunion pour poser des questions élémentaires et récurrentes (voir ma check-list en première partie de l’article et vous créer votre propre check-list pour ne rien oublier)
• Analyser techniquement le projet pour évaluer la faisabilité et savoir si vous allez répondre ou non favorablement au client
• Profitez de l’occasion pour estimer au plus juste la demande du client en fonction de ce que vous avez vu. Prenez en compte l’existant au niveau de l’application et la qualité du code.
• Annoncer si oui ou non vous vous engagez à la réaliser

J’espère que cet article vous aura appris des choses et que cela vous montre qu’avant de coder, il faut bien réfléchir et bien penser son architecture en premier lieu. Donc, ne faites pas comme ce que ce Freelance a fait, par pitié.

N’hésitez pas à laisser un commentaire juste en dessous pour me dire ce que vous en pensez ou si vous avez quelque chose à partager, ça me fera plaisir.