Quick ‘n dirty

J’ai appris.

En bon ingé­nieur j’ai beau­coup poussé l’idée qu’il faut un produit très bien foutu, sans erreur, sans zone d’ombre, perfor­mant et que, quand tout ça va, les utili­sa­teurs vont venir tout seuls.

J’ai appris qu’un produit beau avec des erreurs fonc­tionne mieux qu’un produit moche sans erreurs. C’est contre-intui­tif pour moi et pas dans mes attentes mais c’est la réalité du terrain. J’ai appris qu’au-delà du beau, l’ex­pé­rience utili­sa­teur dans la mani­pu­la­tion des inter­faces était une vraie exper­tise qui faisait toute la diffé­rence. J’ai appris que l’adé­qua­tion aux besoins métier primait encore plus sur tout ça.

J’ai appris qu’un produit qui répond parfai­te­ment au besoin avec une super expé­rience utili­sa­teur ne ferait pas le poids face à un produit qui a un bon marke­ting. C’est agaçant, injuste même, mais c’est la réalité du terrain. S’il faut en vivre, inves­tir dans le busi­ness prime même large­ment par rapport à la qualité intrin­sèque.

J’ai vu des boîtes mourir en lais­sant derrière elles un excellent code tech­nique ou un produit perfor­mant.

Les boîtes qui ont une trac­tion busi­ness, elles, conti­nuent à vivre même si le produit est tech­nique­ment très moyen.

Je suis certain que tout le monde a à l’es­prit plein de produits de tous les jours qui sont défaillants mais qu’on conti­nue à utili­ser, même si c’est malgré-nous. C’est vrai en infor­ma­tique comme dans n’im­porte quel métier.

Ça ne veut pas dire que la qualité tech­nique ne compte pas. Je suis même convaincu que la bonne qualité tech­nique est inves­tis­se­ment massi­ve­ment rentable sur le long terme.

Ça veut dire que la qualité tech­nique est un outil et pas une fina­lité.

Si on confond les deux et qu’on fait de la qualité tech­nique un objec­tif en soi, on risque fort de faire les mauvais choix.