Depuis maintenant quelques jours, je me suis attaché au début de la rédaction d’un manifeste, d’une charte bi-partie qui établie certaines règles pour un bon fonctionnement de la relation (parfois difficile) client – fournisseur dans le web (cette dualité s’applique aussi pour les TravailleursDuWeb employés qui sont aussi à mon sens dans une relation client-fournisseur sans échange d’argent certes mais la relation reste globalement la même).

Ce n’est pour l’instant qu’une ébauche (que j’arrêtes pas de modifier) et je vous en livrerais sous peu la première version… mon but étant ici de pouvoir mettre certains mots sur certains maux de la gestion de projet: tentative de passage en force, pression, manque de clarté pour que les relations de travail soient plus sains et surtout pour promouvoir un comportement qui me semble plus professionnel.

Donc la question est (largement ouverte): quels sont les points importants, ou les droits et devoirs des deux parties (client – fournisseur) à appuyer ou souligner?

Pendant la durée de vie d’un projet beaucoup de choses peuvent mal se passer… mauvais choix technologique, outils pas adaptés, concurrent qui sort du bois avec un meilleur produit, etc… mais la réelle partie problématique d’un projet, le plus gros danger de merdasse reste la gestion de projet.

Pourquoi?
Il y a beaucoup de raisons à un “foirrage” de projet, mais la gestion de projet reste la partie essentielle pour plusieurs raisons:
- timing du projet et planning
C’est sans aucun doute une des causes les plus apparentes à un plantage de projet: votre projet a été plannifié correctement, mais plusieurs personnes n’étaient pas dispo, le projet a pris du retard, puis les différents postes s’enchaînent mais avec une certaine latence entre les différentes personnes, qui peut faire prendre littéralement des semaines de retard à un projet qui paraissait relativement simple.
- objectif fluctuant
Là aussi, une mauvaise définition du projet initial, un scop flou, ou un résumé de votre site/application mal définit et très vite vous pouvez vous retrouver avec un site ou une application qui n’a rien à voir avec ce que vous pensiez avoir signé.
- maîtrise des couts
S’assurer que le développement de votre projet reste “dans les clous” au niveau budget reste la combinaison entre planning/timing et coût des différents acteurs attachés à votre projet (aussi bien en interne qu’en externe)
- gestion des hommes
C’est peut être la question la plus critique et précipite bon nombre de projets dans les abysses du développement-hell… deux personnes dans une même équipe qui se détestent et c’est e début de la fin! Si la mayonnaise de votre équipe ne prend pas, vous allez au devant de conflits sans fin, avec à la clef retard et dépenses supplémentaire dans le meilleur des cas, au pire les gens qui quittent le navire et votre projet qui prend l’eau.

Comment faire pour bien “guider” son projet?
- trouver un vrai gestionnaire
Ce sera votre première tâche, trouver un vrai chef de projet, expérimenté, un vrai gestionnaire qui sait anticiper les problèmes, prévoir le timing du projet, manager les susceptibilités, etc…
- bien s’entourer
Construire votre équipe… un boulot difficile, essayer de constituer une équipe cohérente avec des compétences et caractères épars, qui permettra à votre projet d’aller dans le bon sens. Je n’ai malheureusement pas de recette miracle pour vous (sinon je serais riche aujourd’hui), mais fiez vous à votre instinct.
- savoir se restructurer et s’adapter
Souvent dans un projet, on s’obstine, alors que la bonne tactique reste de contourner momentanément l’obstacle, ou de changer radicalement d’objectif.

Par expérience, 75% des projets foirrent à cause d’une mauvaise équipe ou de personnes pas qualifiées ou qui ne s’entendent pas. C’est pourquoi constituer une équipe est un art à part entière.
Et vous vos expériences de projet boiteux, ça venait d’où?

Voilà une erreur assez commune en gestion de projet: penser qu’engager plus de gens pour travailler sur le projet va permettre d’accélérer sa mise en ligne…

Le raisonnement pour cela est simple (mais faux):
on projet fais X jours hommes, j’ai Y personnes pour le faire donc cela me prendra Z jours…
Si j’utilises A personnes, mon projet prendra B jours et sera donc prêt beaucoup plus tôt…

Pourquoi un raisonnement faux?
Tout d’abord parce que les personnes qui travaillent sur le projet n’occupent pas tous les même postes, que chacun a ses facilités, ses difficultés… aussi parce que pour qu’une personne débarquant sur un projet soit productive, elle a besoin de quelques jours d’adaptation pour rentrer dans le code, s’adapter à la méthodologie de l’entreprise, etc…
Mais la raison principale et celle qui pose toujours problème est qu’on ne gère pas de la même façon 3 ou 10 personnes. Les méthodes, les outils, le temps alloué, etc… tout cela est bouleversé fondamentalement.
La principale erreur consiste à penser qu’on peux gérer une équipe de la même façon que ce soit une micro-équipe ou une équipe plus conséquente.
Oui l’afflux de personnes est censé booster votre production, encore faut-il avoir les épaules pour absorber cette croissance quasi-instantanée.

Comment accélérer le projet?
Personnellement et d’après mon expérience une seule solution pour accélérer votre projet, qui se déroule en X phases:
1. Core du projet: définir le coeur du projet, le noyau dur, les fonctionnalités qui font l’essence même de ce projet, ainsi que les fonctionnalités qu’on considère comme annexes ou beaucoup moins indispensables.
2. Définition précise et passerelle: le but est de pouvoir scinder le dev core du reste, cela veut dire specs fonctonnelles et techniques et s’assurer que le développement des fonctions annexes peut se faire indépendamment du core de votre application
3. Répartition du travail: donner le core définit à vos dev maison, les plus productifs (en tout cas tout de suite) et confier certaines parties annexes du développement à des tiers, soit des indépendants soit une autre entreprise.
Pourquoi?
Le but ici est de décharger vos développeurs de toutes les fonctionnalités annexes qui prennent beaucoup de temps et ne sont pas indispensables. La seule et unique restriction est de pouvoir scinder votre application entre fonctions indispensables et annexes, et que celles ci puissent être développés indépendamment.
Ne vous attendez pas non plus à un miracle, mais cela peut vous faire économiser un temps précieux.

Et vous c’est quoi votre méthode pour booster le timing d’un projet?

Voilà une question existentielle intéressante, envoyée par Olivier:

“Je me pose la question depuis des années sur l’écriture de l’unité de mesure ‘jour/homme’
Pour moi, il faut écrire jour.homme puisqu’on est dans une unité de mesure d’énergie. On multiplie une puissance (un homme) par du temps (un jour)
Comme l’énergie dans une facture EDF qui s’exprime en kWh.
Ce qui est facturé, c’est l’énergie consommée. Peu importe que ca soit 1 W pendant 1000 heures ou 1kW pendant 1 heure, ou 1 homme pendant 20 jours ou 4 hommes pendant 5 jours.
Il y a d’ailleurs sur la puissance et l’énergie des incompréhensions terribles, y compris chez les professionnels, qui mélange allégrement les 2 concepts.
On voit d’ailleurs parfois la meme ecriture de kw/h qui est un non sens physique.
Est-ce l’abus de langage de tous les chefs de projet du monde qui écrivent cette unité en divisant des jours par des hommes (ce qui n’a aucun sens) ?
Ou est-ce qu’une subtilité m’échappe ?”

Aucune idée… l’argumentaire d’Olivier m’a l’air solide, mais moi je voyais ça plutôt comme un notion de jours pour une seule personne à répartir ensuite par rapport à la taille/capacité de son équipe.

Et vous, vous en pensez quoi, quelle syntaxe est-on censé utiliser?

Les mises en ligne sont toujours des moments délicats, que ce soit votre site perso, le site de votre client ou pour votre entreprise, une mise à jour importante voir critique… voilà donc quelques conseils accumulés par quelques années d’expérience.

1. Serveur de dev ISO-PROD
C’est peut être le premier conseil à mettre en place le plus vite possible, si vous développez sur une machine qui n’est pas conforme à celle qui est en ligne (même version d’applicatif web, de base de données, même configuration, etc…) vous pouvez vous attendre à quelques surprises, des comportements étranges, des librairies pas implémentées, des erreurs de gestion de fichiers, etc…
Tout particulièrement si vous êtes sous MAMP, un serveur de dev ne coûte pas cher, donc installez une version ISO-PROD, cela vous simplifiera beaucoup la vie.

2. Tester, tester, tester et re-tester (en dev)
On ne le dit jamais assez, mais avant de livrer une modification mineure (ou qui semble mineure) ou un site complet, testez le en local, sur une machine de dev, faites le tester par vos camarades, par les chefs de projets, etc… faites le tester par des inconnus (au projet) pour éviter les surprises. On ne teste jamais assez (on a jamais non plus vraiment le temps…) donc mettez vos petits camarades à contribution et mettez vous dans l’optique d’un utilisateur standard (évitez le Lorem machin truc, introduisez des vrai phrases avec des accents, des apostrophes, etc…).

3. Avoir une méthode infaillible (packaging)
Suivant la méthode de livraison (fichier par fichier, package ou SVN) vous devez trouver LA méthode qui vous permettra de ne jamais être pris en défaut. Notez tous les fichiers qui doivent être mis en ligne et recheckez pour ne pas en oublier. Etablissez une méthode simple et efficace que vous devez suivre tout le temps à la lettre, cela vous évitera de vous poser des questions sur la méthode de mise en ligne et vous pourrez ainsi vous concentrer sur d’autres aspects foirreux de votre mise en ligne.
Personnellement j’aime l’update SVN ou la méthode de pacquets. Vous faites tout simplement un tar avec la reproduction de l’arborescence des fichiers modifiers, vous transférerez détarrez et hop c’est fait.

4. Eviter les livraisons hasardeuses
Evitez les livraisons bancales de développements pas testés ou trop peu, les ajouts de modules par des entreprises tiers dont vous n’avez pas confiance, etc… au final c’est vous qui devrez redresser la situation, donc en cas de gros doute, bottez en touche.

5. Eviter les livraisons du vendredi à 18h37
C’est peut être un des conseils les plus avisés… ne JAMAIS, je dis bien jamais faire une mise en ligne précipitée un soir, sans l’appui de votre équipe (et tout particulièrement des développeurs qui ont écrit le code), je sais que le cas arrive (trop?) souvent, mais c’est la pire des configurations: vous êtes fatigué, vous avez envie de rentrer à la maison, vous bâclez votre mise en ligne, le serveur est en rade, vous tenter de réparer dans la précipitation et vous aggravez le cas… une horreur
Si ce n’est pas une mise à jour critique, refusez tout simplement la mise en ligne!

6. Une seule personne en charge
Une des (nombreuses) sources de problèmes peut venir de la multiplication des personnes en charge de la mise en ligne (et du partage des accès root – berk ça c’est vilain, mais bon). Au lieu de X personnes qui mettent en ligne leur bouts de code respectifs, choisissez une seule personne en charge de la mise en ligne et donc de récupérer tous les éléments à mettre en ligne. Au moins vous savez qui a mis en ligne quoi, à quel moment (et vous évitez la chasse aux sorcière pour l’envoi d’un fichier corrompu ou tronqué)

7. Penser à TOUT (et le noter)
Souvent dans la précipitation ou le stress on oublie des choses: modification une configuration, changer le modèle de données, remonter un bout de base de données, supprimer certains anciens fichiers inutiles, etc…
La SEULE méthode qui fonctionne correctement est de se faire une mini check-list et de s’y tenir.

8. Responsabiliser les développeurs
Même si vous mettez en ligne, les développeurs ont certaines responsabilités:
- tester ses développements et s’assurer qu’il ne reste aucun bug
- vous fournir une liste exhaustive des fichiers modifiés ou créés (et ça veut dire TOUS les fichiers)
- etc…
en cas de problèmes, vous devez leur remonter gentiment (mais fermement) les bretelles pour leur rappeler leurs devoirs.

9. Eviter les livraisons multiples à la chaîne
C’est aussi une source d’embrouille… vous avez mis une version en ligne qui a été semi testée, on vous envoi ensuite 27 demandes de mise en ligne partielles de bouts de code toutes les 9 minutes. Il y a u grand risque que vous fassiez ces livraisons à la barbare sans trop vous soucier des effets de bord (voir en écrabouillant par mégarde certains fichiers).
Temporisez et mettez en place des règles de test et de livraison unitaire (qui représente un développement finalisé et testé)

10. Savoir dire NON
Au final c’est vous qui serez dans la merde, donc si vous voyez un problème se profiler, n’hésitez pas à dire non, à refuser une livraison si elle vous paraît risquée. Proposez un autre planning incluant tests divers plus réaliste et plus conforme à vos règles de sécurité.

11. Bonus spécial: Sauvegardez!!!
On ne le dis jamais assez mais avant une livraison qui peut s’avérer foireuse, il est important de pouvoir rétablir la version antérieure du serveur en quelques minutes. Donc sauvegardez (code et base de données de préférence) et en cas de besoin vous pourrez faire un roll-back rapide et efficace.

Par expérience une mise en ligne est toujours une opération délicate, qui peut se solder par de vrais catastrophes… seule parade: une méthode infaillible pour ne rien (ou le moins possible) laisser au hasard.

Et vous des conseils, quelques anecdotes croustillantes ?