Bon ou mauvais ?

Pour expliquer au Candide mon métier de développeur, j’utilise souvent l’analogie au métier de maçon (au sens large du terme). De la même façon qu’il construit des maisons, moi je construis des applications. Dans tous les métiers, il y a les bons et les mauvais, mais alors qu’il est plutôt facile pour le client de se rendre compte de la qualité de travail d’un bon, ou d’un mauvais maçon, comment le faire pour un développeur.

Le livrable?

En informatique, le livrable est un logiciel et le client ne voit que la partie visible de l’iceberg. Il voit que les portes et les fenêtres sont là où il les a demandé, que celles-ci s’ouvrent et se ferment correctement, que l’enduit et les tuiles sont de la bonne couleur, que les pièces sont bien placées, etc.
Peut-on à partir de là, dire que le travail a été bien fait et considérer les constructeurs comme de bons professionnels à recommander ou à recruter?

A 2 livrables identiques, comment juger du travail qui a été fait dans les règles de l’art, de l’autre, sans systématiquement en faire une étude ?
Comment convaincre et vendre un travail où ce qui n’est pas visible au premier abord fait toute la différence?

Ou bien cette différence n’est elle que subjective?

J’ai faim.

3 pensées sur “Bon ou mauvais ?”

  1. en règle général, ce qui fait « Tilte » chez les clients c’est quand on utilise des mots comme : robustesse, flexibilité, souplesse, maintenance allégé voir null.

    difficile pour l’utilisateur lambda de faire la différence entre 2 livrable. Tout comme il est difficile pour un néophyte de faire la différence entre 2 murs de briques. Par contre lorsqu’on explique que l’on travail de telle manière que l’application soit capable d’absorber une monter en charge sans faire planter le serveur on obtient beaucoup plus d’attention.

  2. Faire la différence entre 2 livrables est de la responsabilité du client.
    Dans le cas où il s’en moque, où il n’a pas la capacité de le faire, comme dans le bâtiment, il n’en verra rien, ou en subira simplement les conséquences.
    On a les clients qu’on mérite… c’est aussi expliquer en quoi notre méthode est meilleure, ce qui doit mettre le focus sur les manques des autres…qui n’en parlent pas ou ne le font pas.
    Enfin, une notion très utile dans ITIL… Il ne faut partir sur un projet (dev… autre…) que s’il est « rentable » pour les deux parties.
    Le fournisseur doit évaluer si étant donné ce qu’il pourra facturer, travailler avec ses méthodes, ses coûts, sera rentable… et ne pas s’engager en devant ensuite s’asseoir sur certaines étapes…
    Conclusion => au client de définir ses critères d’acceptabilité (contrat)
    Au fournisseur de voir s’il pourra s’y tenir.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *