Produits et projets web

Je lis en ce moment "Système Lean".

Ce livre nous fait découvrir le lean manufacturing des entreprises industrielles de sa première mis een place chez Toyota à nos jours.

C'est vendredi et le vendredi c'est détente. Je vous propose aujourd'hui le feuilleton reportage du journal de 13h de France 2. L'équipe de journaliste a suivi pendant plus de 6 mois la conception et la réalisation de la nouvelle Citroën C3 à travaers les concepteurs, ingénieurs, ouvrier de lignes qui ont mené à terme ce projet de réalisation d'une voiture.

Ce reportage est vraiment complet. Il y a énormément à puiser dans les processus de l'automobile. On le sait les méthodes lean sont empruntés à Toyota. Ici, c'est Citroën qui est filmé.

Quand on cherche à industrialiser des processus lié à des produits et des projets, les contraintes sont les mêmes. Automobile et web, la rigueur dans l'approche et la concrétisation du projet doit être la même.

A voir absolument (25 min). Naissance d'une automobile.

Il y a  deux choses qui sont partulièrement difficiles en gestion de projet : les relations humaines, et les relations au temps. Cette relation au temps se décompose en deux : le délais et la vélocité qu'il faut fournir (en jour homme) pour atteindre l'objectif.

S'il nous arrive souvent d'être rattrapé par le temps, c'est qu'il est une contrainte forte. Elle est même si forte qu'elle fait oublier les béabas. Le mois dernier je reçois un coup de fil d'un ancien collègue qui en me donne de ses nouvelles :

- Je comprend pas quand tu bossais avec nous, on avait moins de retours clients, on arrive pas à comprendre pourquoi ?

- Tu as des exemples de retours ?

- La semaine dernière on a raté une mise en production, il y a une partie du site qui répondait plus. Les ingénieurs ont réparés en catastrophe, mais le client était pas content.

Tu m'étonnes ! En cherchant à savoir si les exigences de chaque environnement (de développement, de préproduction, tests et production) étaient respectées, je me suis aperçu que la préproduction était devenu l'espace de développement.

En réalité, ce n'est jamais aussi flagrant, et les ingénieurs sont persuadés de faire leur développement en local, et une fois terminé, de le passer en préproduction. Mais ce qui biaise la procédure, c'est que par manque de temps, certains développements, à peine terminés, sont intégrés aux travaux stables en préproduction sans même être testé par le développeur sur son environnement local. Plusieurs raisons sont fréquentes : le délais pour livre la fonctionnalité, l'environnement n'est pas à jour des contributions des coéquipiers, une contrainte spécifique au client l'empêche de reproduire fidèlement l'espace de production. Par suite, le bêta testeur va se focaliser sur les erreurs les plus énormes. Il y aura beaucoup d'aller-retour sur l'environnement de préprod. Au final, les bugs plus "cachés" ne sont détectés qu'en production.

Comment redresser la situation ?

1°) Les indices de ce "glissement d'environnement" font penser illico qu'il faut ajouter une étape à la procédure entre la préprod et le dév : une recette sur l'environnement de développement. En premier lieu j'ai eu le réflexe de conseiller cette méthode, puis me suis raviser.

En fait, oui pour une étape supplémentaire si elle est automatisé (cas de x programming) : jeu de tests unitaires, fonctionnels, ... dans ce cas elle est intégré au build. Non si c'est pour une recette des bêta testeurs : le développeur lui même doit livrer un travail le plus parfait possible et fonctionnel.

Si on ajoute une étape en croyant que cette contrainte sera un passage de plus dans un tamis garantissant moins de bugs, on se trompe. Si on ne contient pas ce phénomène de glissement d'environnement, en établissant les raisons, on ajoutera des tamis et toujours plus de tamis. Cela apportera une rigidité à l'ensemble néfaste pour la bonne conduite du projet. (voir l'algorithme de mon médecin)

2°) Rédiger simplement par écrit les procédures et en faire la communication

Il me semble important que l'équipe comprenne pourquoi le respect de chaque espace est important pour ne pas mettre en péril la qualité des mises en production. Dans la plupart des projets web, les procédures doivent rester à la mesure du projet, donc légères.

Finalement, c'est la communication qui sauvera l'affaire pour expliquer que certains raccourcis ne sont pas à prendre quand le temps presse en fin de sprint ou quand le délais du projet arrive à échéance.

Avoir un produit high-tech, avec plein de fonctionnalités pour satisfaire le besoin de l'utilisateur, c'est génial. Cependant, et spécialement avec les logiciels, il est rare qu'un soft soit utilisé à 100% de ses capacités. Prenez MS Word. Qui utilise plus de 20% de ses capacités ? Quasiment personne !

Dans la plupart des cas, on s'aperçoit que le client ne connaît pas telles ou telles fonctionnalités ou possibilités offertes par le produit. Quand on travaille en B2B, il est concevable d'apporter ce savoir faire sous forme de service, mais certains clients n'ont pas forcement le temps de s'occuper de l'art et la manière d'utiliser leur produit.

Disposer d'une base de connaissance solide, de documentations techniques orientées client, d'exemples d'utilisation est un plus incontournable. La liste des fonctionnalités ne suffit pas ! Et la diffusion de plus en plus large d'API (webservices) pour relier les applications nécessite d'ouvrir également sa documentation pour tirer le maximum de profit du produit.

Une des clés des méthode Agile, c'est de répondre au besoin des clients. Ainsi les priorités de développement sont celles du clients et non de la facilité de développement cet tel ou tel module. Les itérations de développement, cycle d'environ un mois qui répond à un objectif déterminé à l'avance, sont priorisés pour répondre aux fonctions essentielles du projet. A la fin de chaque itération, il est toujours temps de faire des retours ce qui ne remet pas la totlité du projet en cause. Il est entendu que l'intégration du client (ou client interne) au sein du projet est un bénéfice, car lui est mobilisé pour la réussite du projet et les développeurs sont obligés de sortir de leur "mutisme" légendaire de l'informaticien. Pour organiser, à la fois les retours lors du développement et ensuite lors de la maintenance, mettre en place un outil de tickets clients permet une meilleure maîtrise des coûts de retours qui doit être obsession pour chasser le gaspillage.

Faire son possible pour que les développements soient cadrés, c'est intégrer de la qualité continue grâce à l'extrem programming, qui permet de baisser le nombre de retours, car les bugs sont corrigé au plus tôt grace aux tests. Pour savoir si un projet a déraillé, il faut absolument mettre en place des indicateurs de performance, le nombre de retours clients est l'un d'entre eux.

J'ai testé OTRS un outil de gestion de tickets. Conserver l'historique des demandes des clients et leurs réponses permet d'allier la qualité de service, tracer les échanges, organiser les échanges et améliorer les chances de succès du projet et des suivants. Un client envoie un mail au service maintenance qui est reçu et archivé par OTRS, comme un help desk digne de ce nom ! Les statistiques du help desk permettent de suivre l'activité des retours. Seul bémol à cet outil, les API encore dans la "todo list". La conséquance est évidente, impossibilité de remonter les stats dans l'outil de X-Programming (Hudsons).

Liens utiles :

• Comparatif des outils de tracking
• Demo de OTRS

Après avoir terminé de configurer un load balancer rebelle, me voilà sur le départ de nouvelles aventures et quitterais mes activités de directeur technique pour prendre de nouvelles fonctions.

Depuis un mois, je me suis mis dans la peau d'un responsable produits et projets à travers ce blogs, dénomination interne qui ne correspond pas forcement aux standards rapporté dans ce blog, mais peu importe la fonction, l'objectif est le plus important. Comme dirait l'autre, on se comprend.

J'ai dit "On se comprend." ? Oui, le principal est et reste que parmi toutes les méthodes management, management par la qualité, management par les tests, ... c'est d'avoir une communication efficace tand avec le client que les équipes.

J'ai incarné la fonction virtuellement, il va falloir passer au concrêt et retomber sur terre : commander des stickers colorés, des stabilos, .... et faire connaissance avec mes nouveaux défis, clients, projets et coéquipiers !

Pour en conclure avec le Sonnet pour Hélène de Ronsard de ces deux derniers jours: "Vivez, si m’en croyez, n’attendez à demain : Cueillez dès aujourd’hui les roses de la vie."

Vous aurez reconnu l'allusion à la génération Y, qui profite du temps présent avec désinvolture au risque de semer le trouble des managers du temps jadis (sic) ;)

Parmi les choix startégiques à faire, il me semble indispensable de maîtriser son core business. Une fois de plus cela va sembler être des portes ouvertes pour certains, mais dans le milieu des start up, le temps est compté et on commet souvent quelques raccourcis.

C'est tout bête. Emporté par l'euphorie, certains entrepreneurs, et c'est là que l'on reconnais les meilleurs, oublient ou ne savent pas qu'il est impératif de maitriser les techniques qui font l'activité de l'entreprise. Un projet web, un site social networking par exemple, qui externaliserait tous ses développements, sans avoir de compétences en interne pour juger de la qualité du travail s'expose à des difficultés :

• Difficultés pour modifier les développements au quatidien / réactivité
• Soin pour la qualité et la sécurité du site web
• Vision et orientations techniques du projet à long terme
• ...

Cela ne veut pas dire qu'il ne faut pas faire appel à des expertises extérieurs ou externaliser une partie du travail. L'expertise permet justement de monter en compétence sur des techniques qui ne sont pas maitrisés en interne et que l'on a conscience que c'est un point à travailler. Demême, l'externalisation, pour des raisons économiques ou de surcroît d'activité permet d'améliorer la capacité de l'entreprise à répondre aux besoins des clients dans de meilleurs conditions.

Je poursuis ma note d'hier avec un cas concret. Faut-il choisir un framework open source ou développer en interne ?

Choisir un framework se fait souvent dès le début du projet. Quels sont les critère à retenir ?

Le temps

La formation à un framework est souvent longue car il faut que chaque développeur comprenne la physionomie du framework en question. Mais une fois acquise, ce sera un gain car développer et maintenir un framework maison, c'est un gouffre qu'il faut savoir rentabiliser.

Les fonctionnalités

Aujourd'hui, les framework PHP embarquent des outils de type tests unitaires, ... c'est un gain de ne pas avoir à tout refaire. Cela dit avoir le choix des armes quand on est expérimenté, cela est un avantage.

Une expertise nécessaire

Qu'il 'agisse d'un framework maison ou open source, il est nécessaire de dégager un expert de celui ci qui garantira le développement dans les règles de l'art. Cependant, pour garantir le niveau, des sociétés de conseil autour des framework php sauront apporter un regard extérieur sur les développements et donc une valeur ajoutée : ils peuvent être cette expertise en attendant qu'un "guru" dans l'équipe émerge.

Les ressources humaines

Il est plus facile de trouver un développeur qui a déjà codé sur un outil open source qu'un projet maison !

Ma conclusion est plutôt favorable au framework PHP pour une équipe qui n'a pas formcément une expérience et une formation d'architecte logicielle. L'utilisation de nombreux plugin disponible me semble un plus mais il ne faut pas oublier un principe essentiel en développement : détourner un outil ou un soft qui n'est pas prévu pour être utilisé comme on a l'intention de le faire répond toujours de manière bancale au besoin. Pour être claire, on n'utilise pas un marteau pour faire office de tourne-vis. Ne riez pas, c'est tellement courrant !

..., c'est le meilleur moyen de ne pas l'être. Et réciproquement.

Encore un article qui décape les idées reçues et qui va faire pleurer mon patron ;) ! N'ait peur, je suis juste de la génération Y.

Ceux qui me connaissent savent que se rendre absolument incontournable dans son poste pour le conserver savent que c'est une réation qui ne me correspond absolument pas. Certains (voire tous) de mes employeurs en ont fait les frais. Pourquoi une telle surprise ?

Question de génération

Je lisais dernièrement un article de Management du mois d'août ("Le culot ça paie") sur la Génération Y, dont je fais parti. D'abord l'arrivée du web et réseaux sociaux facilite la mise à disposition d'un plus grand choix d'offres de job. Ensuite parce que la génération Y a la culture du zapping, du travail collaboratif, du travail en ligne. Crise ou pas crise, si le jeune y ne se sent pas à son aise, il claque la porte. Je vous invite à poursuivre sur Génération Y 2.0. Il faut ajouter qu'un job est un deal qui se fait à deux entre l'entreprise et le "talent" : pour le jeune Y, il faut se confronter au réel et tester pour apprendre.

Question de choix de carrière

Je lisais dans le même magazine un article sur les dirigeants de transition. Ce sont ces séniors qui vont diriger une entreprise pour une période de transition parce que la société est en redressement ou que le PDG est gravement malade, ... Ce sont des situations extrêmes qui nécessitent une adaptation et d'être à fond tout de suite et pendant 6 mois à 2 ans.

J'aime bien cette approche de job transitoire, parce que c'est paradoxalement penser à long terme pour l'entreprise et pour soi. On pourra évolluer vers une autre mission (même au sein de la même entreprise) sans que l'entreprise prenne de risque. Le cycle d'un ingénieur est de changer de job tous les 2 ans, autant qu'un dirigeant de transition finalement. Cela laisse le temps d'apporter de l'enrichissement et une valeur ajouter. Encore faut-il avoir les mêmes exigences de travail bien fait que les dirigeants de transition ! Apporter du résultat tout de suite et construire un avenir serein.

Question de valeur ajoutée

Personnellement, je pense que si je n'apporte plus suffisamment de valeur ajoutée et que le projet arrive à maturité, je peux me retirer et laisser le soin de l'exploitation à des gens bien formés. Encore faut-il avoir préparé cela !

Comment se rendre non indispensable dans son poste et donc indispensable pour l'entreprise ?

1. Les méthodes Agile donnent pour rôle au chef de projet (ou scrum master, celui qui encadre l'équipe de développeur) un facilitateur et non pas un dirigeant qui impose ses solutions techniques. Il est là pour dénouer les problèmes, apporter une vision au projet (définir les objectifs de délais qualités, ...).
2. Participer à la formation de ses collaborateurs et à la transmission des connaissances des séniors vers les juniors.
3. Une vision longtermiste permettra de laisser son emprunte positive pendant longtemps après le départ. Entamer des chantiers structurer dès le départ permettra à l'équipe de vivre sur des acquis.
4. Ne pas repousser au lendemain ce qui parait indispensable de faire de suite car cela apporte une valeur ajoutée importante.

En fait, il n'y a rien d'exceptionnel à vouloir rester non indispensable. Ces exigences au quotidien correspondent au besoin des entreprises au jour le jour pour peu que l'individualisme ne soit pas le centre de vos motivations. L'entreprise a besoin de jouer collectif.

Demain un exemple pour rester concrêt.

Ajouté aujourd'hui à 10h02 :

• Article du journal du net : Comprendre et manager la génération Y

Comment dire ? Je suis litéralement tombé sous le charme de Hudson. Bon je sais, je m'emporte, mais en 2 heures, je suis arrivé à ce que je voulais !

Nous avons un outils de versioning pour faire nos branches, patch, .... Pour le déployement en préproduction ou production, nous utilisons des scripts bash (via rsync). Nous avons des tests unitaires à jouer mais ils étaient joués quand quelqu'un y pensais. Nous avons un bug tracker pour rapporté les bugs des développeurs...

Nous avions pleins d'outils mais ils se sentaient seuls, limite ils faisaient de la dépression ;). Alors nous avons décider de les réunir autour d'un superviseur. Je préfère ce terme à "outil d'intégration continu" car c'est de cela qu'il s'agit. En fait derière Hudson, il n'y a rien, c'est juste un outil qui réuni tous les autres et qui permet d'avoir une vue consolidée de tous les autres.

Nous débutons un projet PHP, qui tourne avec le framework Symfony. Alors j'en ai profité pour installer Hudson. Je vous avoue que la première fois que j'ai installé Hudson, je me suis démandé à quoi ça servait tellement c'était vide. Et, j'ai installé quelques plugins et en moins de deux heures, j'ai configuré un environnement qui check le style du code PHP, déploye une version en préproduction en utilisant lançant mes scripts habituels (script + nouvelle base de données) et jeu de tests unitaires via le framework de test de symfony. Si un test casse toute l'équipe reçois un mail (avec le reporting du test qui a cassé). Les tâches s'enchaînent sur le succès des uns et des autres.

En peu de temps on peut installer un environnement pour commencer à s'aguerrir à l'intégration continue. Me consernant, je me pose encore des questions d'organisation :

• Comment organiser les tâches ?
• Ne vaut-il mieux pas découper au niveau de Hudson chaque taches élémentaires et les enchaîné ?
• Est-il plutôt préférable de regrouper plusieurs actions (déployeemnt et jeu de test) au sein d'un "build" (tache hudson) ?
• L'intégration de Phing est-elle nécessaire car l'exécution de script bash est possible directement via Hudson ?

L'usage me donnera les réponses ?