Les pompiers pyromanes

L’un des profils de collaborateur les plus difficiles à manager sont les « pompiers pyromanes ». Voyons à quoi on reconnait un tel profil, les dangers qu’ils peuvent représenter et les solutions qui existent pour les gérer.

C’est quoi un pompier pyromane ?

Peut-être que vous vous êtes déjà retrouvés dans cette situation. Vous assignez des tâches à vos développeurs (ou ils se les répartissent eux-mêmes dans le cas d’une équipe auto-organisée) ; ces tâches sont souvent en deux groupes : les nouveaux développements d’un côté, et les débuggages ou micro-évolutions de l’autre.

Pour schématiser, les nouveaux développements prennent du temps, plusieurs jours voire plusieurs semaines, alors que les débuggages ont des durées qui se comptent en heures la plupart du temps. L’investissement nécessaire est donc très différent, que ce soit au niveau de la réflexion technique à mener que dans la durée de concentration à avoir sur son travail.

Un pompier pyromane, c’est avant tout un « pompier », c’est-à-dire quelqu’un qui se sent bien dans le rôle de sauveur. A chaque fois qu’il résout un bug, il est remercié chaudement par la ou les personnes qui étaient impactées au quotidien. Plus il est rapide dans la résolution de problèmes, plus sa valeur semble augmenter aux yeux de ses collègues. C’est normal, il leur facilite la vie, il résout leurs soucis.

Au fur et à mesure, ce genre de personne va vouloir de moins en moins travailler sur de nouveaux développements. Après tout, pourquoi vouloir bosser dans l’ombre pendant plusieurs jours, à se casser la tête à résoudre des enjeux techniquement complexes ? Quand un nouveau projet est mis en production, les développeurs qui ont travaillé dessus sont rarement acclamés ; ils reçoivent peut-être des félicitations par leur hiérarchie, mais pour les collègues des autres services c’est au final assez peu visible. Dans le pire des cas, c’est même une source de nouveaux bugs. C’est tellement mieux d’être vu comme celui qui corrige les bugs plutôt que d’être celui qui les crée, non ? Continuer la lecture de « Les pompiers pyromanes »

De la gestion de projet à la gestion de workflow

Il y a une chose qui me chiffonne lorsqu’on s’intéresse aux méthodologies agiles, telle qu’elles sont définies « by the book », ou telle qu’elles sont enseignées. On y décrit un fonctionnement à base de sprints de développement, qui s’enchaînent les uns après les autres, avec une durée de l’ordre de la quinzaine de jours. Même en décrivant la partie qui se situe en amont du développement (écriture de user stories, gestion du backlog), et celle qui se situe en aval (tests, validation, mise en production), tout reste centré sur le développement.

Au final, dans la vraie vie, ces périodes de conception et de validation finissent par manger sur la période de 2 semaines qui devrait être consacrée au développement. On se rend compte assez vite des limites du système…

De mon point de vue, il faut prendre la gestion de projet à un plus haut niveau. Et il faut définir un workflow global, qui va permettre à tous les intervenants du projet de savoir ce qu’ils ont à faire et pour quand. Je vais illustrer cela en expliquant ce qui est mis en place dan mon entreprise ; c’est le fruit d’un process dérivé de la méthode Scrum, qui est affiné sans cesse depuis plus de 5 ans. Continuer la lecture de « De la gestion de projet à la gestion de workflow »

Les tâches « gazeuses »

Est-ce que vous connaissez la particularité fondamentale de l’état gazeux ? Wikipédia le dit très bien :

Dans l’état gazeux, la matière n’a pas de forme propre ni de volume propre : un gaz tend à occuper tout le volume disponible.
 

Ce que j’appelle les « tâches gazeuses », ce sont les projets − ou les éléments d’un projet − qui ont la capacité de durer aussi longtemps que vous le permettez. Quel que soit le temps que vous pouvez y passer, ça ne sera jamais terminé ; il y a toujours un dernier truc à fignoler, quelque chose sur lequel il faut réfléchir, un point important qui nécessite d’y consacrer encore un peu de temps.

J’ai tendance à séparer ces tâches en 3 types : celles qui sont intrinsèquement gazeuses, celles qui ont été mal préparées, et celles qui sont mal gérées.

Les tâches intrinsèquement gazeuses

Il existe tout un tas de tâches dont la nature même implique qu’elles ne se terminent jamais. Il s’agit principalement de celles qui nécessitent du jus de cerveau, de la réflexion, de la cogitation. On peut passer un temps infini à réfléchir à une spécification, à penser une ergonomie, à échafauder des méthodes de travail.

Mais cela peut aussi concerner des choses qui sont plus concrètes, mais qui n’ont pas forcément une ligne d’arrivée bien visible : écrire une documentation la plus complète possible, chercher un code coverage de 110% sur ses tests unitaires, optimiser du code pour grappiller un dixième de seconde supplémentaire.

Dans ces cas-là, il existe deux solutions :

  • Se créer des objectifs atteignables et s’en satisfaire. Un design peut toujours être amélioré, mais il faut être capable de converger vers une version « suffisamment » bonne.
  • Se donner un budget-temps. Quoi qu’on en dise, une tâche possède toujours une valeur spécifique. Si on y passe plus de X heures, son coût devient trop élevé pour qu’elle vaille la peine d’être réalisée.

Les tâches mal préparées

Ça paraît super-évident. Quand une tâche ou un projet a mal été préparé, on est certain de générer de l’effet tunnel. Même avec de bonne spécifications fonctionnelles, il est assez facile de croire qu’on maîtrise techniquement son sujet, et qu’on peut se jeter dans le code de manière rock’n roll. C’est le meilleur moyen pour ne pas anticiper d’éventuels problèmes, voire simplement des choix techniques qui devraient être pensés en amont.

Fatalement, ce n’est qu’une fois qu’on est face aux questions techniques qu’on commence à y réfléchir. Ça fait perdre un temps précieux.
Mais surtout, on se retrouve ainsi à résoudre les points bloquants au fur et à mesure qu’ils apparaissent. On se dit tout le temps « Je résous ce truc, et après c’est bon !« , mais l’ennui c’est qu’on va ensuite tomber sur un autre truc à résoudre, puis un autre, etc. Aucune visibilité sur l’étendue du travail à réaliser, on nage en plein brouillard.

Dans ce cas-là, il n’y a pas tente-six solutions : Il faut se pencher sur la tâche et la décortiquer méthodiquement avant de commencer à travailler réellement dessus.

Les tâches mal gérées

Vous vous souvenez du triangle qualité-coût-délai ? L’enseignement principal qu’il nous apporte est qu’on peut fixer deux des trois paramètres d’un projet, et que le troisième en découle forcément.

Lorsqu’un projet est mal géré, cela provient rarement de la qualité du travail effectué dessus ou de la précision des spécifications fournies. Non, trop souvent le problème réside dans l’impulsion initiale du projet, dans la manière dont le client appréhende ses objectifs et qu’il les communique.

Si on veut faire un POC, on voudra créer un prototype rapidement et à faible coût. Mais trop souvent, le prototype donne satisfaction et se retrouve en production. Il faut alors gérer des contraintes qui avaient été laissées de côté. Au lieu de tout redévelopper (comme il aurait fallu le faire avant de mettre en production, c’est pour ça que ça s’appelle un prototype), on passe son temps à maintenir en vie le projet, qui devient alors gazeux : on ne sait pas combien de temps chaque évolution prendra à être ajoutée, car la base même n’est pas prévue pour recevoir ces évolutions.

Autre exemple, le projet qui a été fait dans les règles de l’art au niveau de sa réalisation, mais sur lequel on a pris quelques raccourcis pour réduire les délais de livraison. Tout va bien jusqu’au jour où le projet interne est ouvert à des partenaires, et qu’on s’aperçoit qu’aucune interface n’est prête. On se dépêche de les ajouter, pour se rendre alors compte que la documentation nécessaire n’a pas été écrite. Et ainsi de suite…

Il est donc important de communiquer avec son client (qu’il soit interne ou externe), pour s’assurer que sa vision des choses est suffisamment pragmatique pour éviter les déconvenues et les déceptions.

Skriv : Organisation de l’information

(ce billet fait partie d’un ensemble consacré au projet Skriv)

Cela fait longtemps que je n’ai pas écrit d’article au sujet du projet Skriv.
En ce moment, je cherche un moyen permettant de gérer les projets en autorisant 2 visions différentes :

  • Une vision macro, pour suivre l’avancement global des projets et des sous-projets. Sans avoir le détail de toutes les tâches qui composent chaque sous -projet, il faut savoir quelles sont les deadlines des sous-projets, et éventuellement à quel pourcentage de complétion ils se situent.
  • Une vision micro, pour accéder à toutes les informations liées aux différents sous-projets, les tâches, la documentation, etc.

La vision macro est absolument nécessaire pour prendre des décisions à moyen terme, ou simplement pour avoir une vision synthétique du travail. La vision micro est nécessaire pour tout le travail au quotidien : définir les priorités des tâches, accéder à la documentation, etc.

Découpage des projets

Je me creuse la tête depuis un moment au sujet de la meilleure manière de découper les projets. Avoir un seul niveau d’organisation n’est pas satisfaisant ; on se retrouve à avoir une liste de tâches interminable, sans pouvoir faire de regroupements logiques.

J’aime bien l’idée d’offrir un deuxième niveau d’organisation. Cela semble assez naturel de pouvoir découper un projet en plusieurs sous-projets. Dans ma tête, chaque sous-projet est un ensemble logique pouvant comporter :

  • une ou plusieurs listes (par exemple une liste de tâches et une buglist)
  • une collection de « pages » de wiki (spécifications du sous-projet, documentation technique, checklist, …)
  • un espace de stockage pour des pièces-jointes, elles-mêmes éventuellement réparties dans des sous-dossiers
  • une liste de messages portant sur le sous-projet

Si on suit cette vision, il faut proposer une vision complète au niveau du projet, qui rassemble toutes ces informations de manière agrégée (une liste avec les tâches de tous les sous-projets, toutes les pages de wiki, toutes les pièce-jointe, et ainsi de suite).

Faut-il proposer une organisation plus complexe ? Certain logiciels permettent de créer autant de niveaux de sous-sous-projets que l’on veut. Mais personnellement je trouve ça inutilement complexe ; on s’y perd et la productivité n’y gagne rien.

Informations liées aux sous-projets

Avec ce découpage en sous-projets, il m’est venu naturellement une idée : on pourrait donner une date de début et une date de fin à chaque sous-projet. De cette manière, il serait très facile de représenter graphiquement les sous-projets sur une ligne de temps, de manière à faire une sorte de diagramme de Gantt simplifié. C’est parfait pour la vision macro dont je parlais plus haut.
On aurait donc deux informations très synthétiques associées à chaque sous projet : ses dates de début et de fin, et son pourcentage de complétion (qui serait calculé à partir du statut des tâches faisant partie du sous-projet).

Continuer la lecture de « Skriv : Organisation de l’information »

Manymoon

Manymoon est un web-logiciel de gestion de projet. Il a fait un peu parler de lui ces derniers jours, suite à l’ouverture de la plateforme Google Apps à des applications tiers ; Manymoon y est montré en exemple d’application très utile pour les entreprises qui utilisent Google Apps.

Il n’en reste pas moins que Manymoon peut s’utiliser directement, sans passer par la plate-forme de Google.

Fonctionnalités

Manymoon est à la base assez classique dans son approche : On y crée des projets, auxquels on peut ensuite ajouter des éléments.

Tâches : Chaque tâche possède au minimum un titre, et on peut y ajouter une pièce-jointe (voir plus loin), un ordre de priorité, une date limite (voir plus loin), des tags, et un commentaire. Les tâches sont ensuite listée de manière à pouvoir facilement ajouter des commentaires, réassigner la tâche ou la remettre à plus tard. L’édition d’une tâche se fait en cliquant sur son titre, ce qui fait apparaître une pop-up contenant tous les champs modifiables.

Manymoon - Tâches

(image © Manymoon)

Jalons : Il est possible de créer des jalons, constitués d’un titre et d’une date limite. Ils agissent comme des groupes de tâches, permettant de voir d’un coup d’œil les grandes étapes d’un projet. On déplace les tâches d’un jalon à l’autre (ou en-dehors de tout jalon) par drag’n drop.

Manymoon - Jalons

(image © Manymoon)

Micro-blogging : C’est à la mode, et c’est au centre de l’utilisation de l’outil. Il est possible d’ajouter facilement des messages, en y ajoutant une pièce-jointe, un lien ou un événement. Il est aussi possible de juste signifier que l’on travaille sur un projet, voire une tâche. Ces messages s’affichent dans le “bulletin” du projet, qui affiche en plus toutes les actions effectuées (ajout ou modification de tâche, création de jalon, etc.).

Manymoon - MicroBlog

(image © Manymoon)

Continuer la lecture de « Manymoon »

Lancement du projet Skriv

J’en parlais récemment dans le post concernant l’avenir de ce blog : Je réfléchis à l’idée de développer un outil de gestion de projet ouvert à tous.

Quasiment depuis que je travaille, j’ai développé des outils pour suivre les projets ou traiter les bugs. Comme j’ai souvent bossé dans des entreprises de petite taille, pour ne pas dire des start-ups, ces outils comblaient des manques évidents et étaient adoptés rapidement.

  • Il y a maintenant un paquet d’années, j’avais fait un gestionnaire de buglist. Doté d’une interface web, il était écrit en C et stockait ses données dans un fichier XML. Technologiquement, ce n’était pas une très bonne idée, mais c’était l’occasion de tester des librairies XML et CGI que j’avais écrites en C. Au niveau des fonctionnalités, je ne me souviens plus trop. Je crois que c’était assez simple, avec pour chaque bug le niveau de criticité, une description, et le projet affecté.
  • J’avais par la suite repris le même genre d’outil, mais écrit en PHP/MySQL. Pus facile à faire évoluer, je n’ai pas souvenir qu’on l’ait utilisé à son plein potentiel.
  • Dans mon entreprise actuelle, j’ai dès le début mis en place des outils open-source, les plus important étant Flyspray pour la buglist et MediaWiki pour le wiki. Depuis, j’ai développé des extensions MediaWiki qui nous servent à gérer les projets. Ainsi, chaque projet a une page dédiée sur laquelle apparaissent : la liste des bugs du projet, une liste de tâches, des pages wiki liées au projet, et des fichiers en « pièce-jointe ».

Cette extension est clairement inspirée par Backpack. J’aime vraiment ce logiciel. Par rapport à d’autres outils plus orientés « projet », comme Basecamp par exemple (pour reprendre un autre logiciel développé par 37signals), j’apprécie le fait que toutes les informations soient regroupées sur une seule page.
Habituellement, les logiciels de gestion de projets offrent plusieurs vues différentes, chacune pour un type d’information. Il y a un onglet pour les tâches, un onglet pour le calendrier, un onglet pour les bugs (si l’outil les gère), un onglet pour les pages de wiki (si c’est disponible), un onglet pour les fichiers, et ainsi de suite.
Pour ma part, je préfère avoir la vue la plus « intégrée » possible. Cela implique de penser l’interface en conséquence, ce qui peut s’avérer plus délicat qu’il n’y paraît.

Je cherche donc maintenant à définir un outil que je pourrais utiliser aussi bien pour mes besoins en entreprise, que pour gérer mes projets personnels. Je vais donc m’intéresser à chaque aspect d’un tel logiciel dans une série de billets sur le blog. Je ferais appel aux avis des lecteurs du blog, en espérant réussir à dégager des principes clairs de fonctionnement. J’espère aussi trouver le temps de développer ce logiciel, pour que tout cela ne reste pas théorique (d’un autre côté, si un autre outil est développé à partir de spécifications dérivées de mes idées, je n’y verrais aucun problème, bien au contraire).

Ah, au fait, pourquoi appeler ce projet «Skriv» ? C’est un nom que j’affectionne, que j’ai donné par le passé à plusieurs logiciels que j’ai développé. Le plus important était une interface web qui intégrait un webmail, un gestionnaire de bookmarks, un bloc-notes, un carnet d’adresses, une gestion de compte bancaire. Je l’utilisais tous les jours pour centraliser ma vie numérique. De nos jours, c’est assez commun ; mais à l’époque où je l’ai développé (en 2002), c’était assez novateur.
Pour le nom lui-même, il signifie « écrire » dans plusieurs langues comme le breton et le suédois. Ça va bien dans l’idée d’un outil qui sert principalement à communiquer.

Des nouvelles du blog pour 2010

Ce blog a été ouvert il y a bientôt un an, c’est le moment de faire un petit bilan.

J’avais créé ce blog parce que je pensais avoir des choses intéressantes à partager. Au début je voulais écrire un livre, mais un blog me semblait finalement une meilleure solution ; plus simple à commencer, plus rapide à faire avancer. Les premiers temps, j’écrivais plusieurs articles par semaine, puis le rythme s’est stabilisé. Le blog a été plutôt bien référencé sur certaines expressions (tapez «cycle en v» ou «cycle itératif» sur Google pour voir), le nombre de visiteurs a augmenté continuellement.

Je tiens à remercier particulièrement toutes les personnes qui ont pris le temps de laisser des commentaires. Non seulement ça fait plaisir, mais cela débouche souvent sur des discussions intéressantes.

Vous avez pu remarquer que mon rythme d’écriture s’est fortement ralenti ces deniers temps. Il y a plusieurs raisons à cela. Les deux principales sont évidemment la naissance de ma fille il y a 3 mois (ça vous change la vie d’une manière qui dépasse tout ce qu’on peut imaginer), et mon implication dans mon entreprise (nous sommes passés de 13 à 22 personnes en l’espace d’un an, avons changé de locaux, je gère sans cesse plus de projets).

Mais il y a aussi d’autres raisons, qui ont un lien direct avec le blog : j’ai en préparation quelques projets qui me prennent du temps.

  • Je suis en train de reprendre le contenu publié sur le blog, pour en faire un livre. Oui, c’est un retour à l’idée initiale. En fait, la matière première du livre est présente sur le blog et il peut être intéressant de recompiler tout ça en une forme plus structurée, moins “bordélique” qu’un blog. C’est aussi une source d’inspiration, dans la mesure où j’identifie les contenus manquants pour le livre et que j’en profite pour écrire sur le blog les articles correspondant. Et je pense pouvoir faire un bouquin vraiment utile (les pavés de 500 pages dédiés à telle ou telle méthode de gestion de projet ou d’organisation personnelle sont majoritairement remplis de vide).
  • Je prépare une présentation «De geek à directeur technique», que je vais exposer dans des écoles d’ingénieur. Le but est de présenter les idées du blog (gestion de carrière, organisation personnelle, gestion de projet, création d’entreprise) d’une manière qui ne soit pas un cours magistral ni la vente d’un concept. La première présentation se tiendra le mois prochain, et j’espère renouveler l’expérience régulièrement.
  • Depuis le temps que je teste des outils de gestion de projet, et que j’en développe pour mes propres besoins professionnels (et pour les besoins des entreprises où j’ai travaillé), je commence à réfléchir à l’idée d’en développer un. En reprenant les fonctionnalités les plus intéressantes, en y injectant quelques principes originaux, je pense pouvoir faire quelque chose d’intéressant et utile. On en rediscutera très bientôt sur le blog, mais sachez que la gratuité d’utilisation et l’ouverture (d’une partie importante) du code sont au cœur de ma réflexion.

Ce blog va donc continuer à exister. Peut-être changera-t-il de forme au cours du temps. Je ne suis pas toujours à l’aise avec le principe même du blog.

  • Je pense avoir des choses à dire. Mais on m’a déjà dit que certains de mes articles avaient un ton un peu trop “professoral”. Cela se comprend si on remet en contexte le livre que je compte écrire. Mais je trouve difficile de garder un ton léger ou personnel lorsqu’il s’agit d’expliquer des concepts théoriques ou factuels.
  • Je suis parfois frustré par le manque d’échange. Très souvent, je souhaiterais discuter certaines idées et concepts ; savoir ce que les autres pensent d’un sujet donné, échanger des propos. Et un blog n’est pas du tout adapté à cela. Faut-il que je mette en place un forum ? (corollaire : connaissez-vous un bon forum sur la gestion de projet ?)
  • Pour partager les liens intéressants, j’utilise Google Reader et Twitter. D’ailleurs, ça m’énerve un peu de dupliquer les choses entre ces deux outils… Bref, n’hésitez pas à vous abonner à mes flux. Faites-moi signe si vous partagez des liens sur Google Reader.

Donc voilà où j’en suis. Il y a beaucoup de projets en cours, tous n’aboutiront peut-être pas, mais ce n’est pas grave. L’important est d’avancer.

Les premiers enseignements de Rework

J’ai déjà parlé plusieurs fois de l’entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d’information sur le livre, et je me suis arrêté sur le quatrième de couverture :

Je trouve que le texte qui s’y trouve est très intéressant, un brin controverse, et mérite qu’on s’y attarde. Voici une traduction très libre de son contenu, et ce que j’en pense.

“Dès que possible” est un poison

Il est vrai qu’en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d’accord sur la spécification d’une nouvelle fonctionnalité, et quand vient le moment d’en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s’agit souvent d’un pis-aller qui démontre que le projet n’est pas réellement pris en main.

Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :

  • La définition exacte du projet n’a pas été faite correctement. On sait bien qu’on n’a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu’ils se casseront les dents dessus, ce qui empêche d’apporter une quelconque valeur aux estimations qu’ils peuvent faire de leurs développements.
  • À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l’objectif au plus vite. Un aspect en pâtira forcément, qu’il s’agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, …
  • À l’inverse, l’absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j’estime que tout ce que j’ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c’était plus urgent que ça !».

Continuer la lecture de « Les premiers enseignements de Rework »

La R&D : pour ne pas confondre développement et veille techno

Il y a quelques temps, je vous ai parlé de la veille technologique. Je vous ai expliqué en quoi c’est un élément important de nos vies professionnelles.

Je voudrais cette fois-ci vous mettre en garde contre une dérive finalement assez commune chez les jeunes développeurs, qui est d’utiliser les projets professionnels comme un terrain de jeu pour réaliser leurs expérimentations. Ensuite nous réfléchirons aux moyens de canaliser la fougue qui conduit à ces dérapages.

Les expérimentations au boulot

Il y a quelques années, alors que j’étais chef de projet, un de mes développeurs – un prestataire externe, en fait – avait demandé une demi-journée de congé pour assister à une conférence organisée par Google France. J’étais content de voir qu’il prenait à coeur sa veille technologique.
À son retour, je lui ai évidemment demandé de me faire une présentation rapide de ce qu’il avait vu. Il s’agissait des premières versions des toolkits de Google, et ça avait l’air vraiment intéressant.

Nous étions alors en train de démarrer un nouveau projet, et ce développeur était en charge de certaines spécifications techniques. Quand j’ai vu dans ses specs qu’il envisageait d’utiliser les technologies Google qu’il venait d’entrapercevoir, j’ai eu une petite discussion avec lui.

Le message tient en 2 points :

  • Bien qu’absolument nécessaire, la veille technologie est une démarche personnelle. C’est à chacun de se trouver ses propres petits projets qui lui permettront de tester de nouvelles technos ou de nouveaux outils.
  • Un projet mené au sein de l’entreprise répond à des contraintes contractuelles et financières. Vouloir y glisser des technologies qui ne sont encore qu’à l’état de bêta, ou qu’on ne maîtrise absolument pas, est une erreur assez grave.

Canaliser et organiser

Il n’empêche qu’il n’est pas logique d’inciter à la veille tout en la réprimant dans le cadre de l’entreprise. L’entreprise a certains devoirs de formation vis-à-vis de ses employés, il faut s’en occuper de manière raisonnée et planifiée.

Continuer la lecture de « La R&D : pour ne pas confondre développement et veille techno »

Le triangle Qualité, Coût, Délai

Quand on doit choisir la manière d’aborder un projet, il existe 3 notions fondamentales qu’il faut connaître et évaluer : la qualité, le coût et le délai.

 

Comprendre le triangle

  • Qualité : Il s’agit du soin qui est apporté à la réalisation fonctionnelle et technique du projet. Un projet de médiocre qualité remplira les besoins immédiats du client, en s’autorisant un certain nombre de raccourcis. Un projet de bonne qualité aura été spécifié pour couvrir certains besoins futurs identifiables, et offrira une ergonomie adaptée, des performances homogènes, une évolutivité étudiée, une documentation complète.
  • Coût : Un client est prêt à dépenser une certaine somme pour un projet donné. La valeur du projet peut éventuellement s’adapter à un certain nombre de critères, mais il y a forcément un seuil au-delà duquel il est impossible de le rentabiliser. La notion de coût englobe aussi bien les frais d’étude (en fonction du temps passé aux spécifications fonctionnelles et techniques) et de réalisation (suivant le nombre de développeurs nécessaires, le matériel mis à leur disposition, la présence d’une équipe de test et de validation, …), que les frais d’exploitation (matériel nécessaire pour faire tourner le projet en production, salaire de l’opérateur de maintenance, …).
  • Délai : Savoir combien de temps doit durer la réalisation d’un projet n’est pas aisé, même si cela fait partie du travail d’un ingénieur. Certains projets ne sont pas urgents, ni même importants, mais ils comportent forcément une deadline à partir de laquelle ils deviennent caducs.

Continuer la lecture de « Le triangle Qualité, Coût, Délai »