la maîtrise de l’amélioration de la qualité

quand je vous disais que le besoin du programmeur est plus important que le besoin du client, je voulais bien évidemment dire le besoin de l’équipe de développement. vous aurez corrigé par vous mêmes.

je ne suis pas vraiment un programmeur, en tout cas pas dans le cadre de mon travail actuel. et quand cette sensation désagréable de manque de visibilité sur le projet a commencé a se faire sentir, je me suis rendu compte que moi aussi j’avais quelques besoins inassouvis. j’ai beau me dire que mon travail, en tant que gestionnaire du projet, consiste a être disponible pour l’équipe; une autre partie de moi ne cesse de clamer mon appartenance a l’équipe et de ce fait, l’importance de me donner les moyens.

quelque part l’équipe avait besoin de repères et de références, et moi même j’avais besoin de ces références pour leurs demander des comptes . c’est comme ça que ça marche. et j’ai décidé que cette référence serait une version courante du logiciel toujours disponible a une adresse publique, pour que tout le monde puisse se faire sa propre idée de où on en est réellement (par opposition à « où j’en suis personnellement », dans mon petit module, que je dois développer, sur ma petite machine) .

pour qu’il y ait une version courante, il fallait que l’installation de l’application soit automatique. il fallait un installeur. je me suis attelé à la tâche. il fallait quelques scripts et j’étais bien décidé à les faire. il a fallu remettre de l’ordre dans mes priorités, déléguer quelques taches que j’avais sur d’autres projets a Anis qui travaille déjà dessus, et me concentrer exclusivement sur ce projet là. il en avait besoin. c’est une grosse application, un système d’information complet qui doit être la seule application que vont utiliser pratiquement tous les employés de l’entreprise client, tous départements confondus. à un moment, la petite équipe a commencé a ne plus tenir tous les bouts du projet. le projet est tellement grand.

j’ai commencé à programmer toutes les tâches nécessaires a l’installation de l’application, une a une au fur et a mesure que j’installais moi même l’application. l’installation de la base de données et sa mise à jour, le paramétrage,… ce travail m’a rapproché physiquement de l’équipe et ce rapprochement, comme prévu, à porté ses fruits. les livraisons sont toujours en retard, mais la qualité est plus maîtrisée. c’est que nous avons mis en place de nouvelle procédures sur la base des observations de terrain que j’ai faites. rien d’extraordinaire : réunion quotidienne de « qu’est ce que je fais », et réunion hebdomadaire sur la qualité. la première, chaque un présente ce qu’il est entrain de faire, la deuxième, Bechir examine tout ce qui a été fait la semaine dernière, décide ce qui est bon, de ce qui va être refait et nous informe pendant la réunion et nous explique pourquoi. ces bonnes pratiques étaient connues, mais on ne pouvais pas les appliquer vu mon manque de disponibilité. on se contentait d’une réunion hebdomadaire de définition des objectifs de chaque un.

les choses allaient de mieux en mieux et on commençait a se demander si l’installeur et la version courante étaient la solution. après tout les mesures que nous avons prises n’avaient rien a voir et ont bien marché. d’autant plus qu’il n’était toujours pas prêt, l’installeur. ne valait t-il pas mieux l’abandonner? est ce que ce ne serait pas une perte de temps? les démons du « good enough » nous hantaient. nous avions obtenu une qualité satisfaisante et le risque de passer encore une semaine de travail sur l’installeur commençait a paraître inutile. le risque est une notion contextuelle, le risque qui était bon a prendre quand nous livrions des modules de qualité médiocre (j’exagère à peine), ne l’est plus maintenant que la qualité s’est améliorée.

mais c’est une fausse piste. d’abord, le fait que la qualité se soit améliorée ne signifie pas que nous la maîtrisions plus. et évidemment nous ne la maîtrisions pas plus qu’avant. pour la maîtrise il faut le contrôle, et pour le contrôle il faut la référence. pour améliorer la qualité, nous avions tous simplement amélioré nos processus; ce faisant nous avons assuré la qualité. et l’assurance qualité n’est pas le contrôle qualité. rien ne garanti le gain que nous avons acquis. sans maîtrise il n’y a pas d’assurance.

No comments yet

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :