Archives par étiquette : Humeur

image

Ce qu’il ne faut pas faire pour vendre un produit…

C’est le week-end je vous propose donc une petite note légère afin de vous relater une expérience récente.

Nous sommes en train d’étudier une nouvelle solution afin de réaliser le programme d’installation de notre solution et après discussion avec des collègues, je me mets donc à télécharger la version d’essai d’u très célèbre InstallShield bien que je ne l’avais même pas évoqué dans l’étude que j’avais réalisé et dans le rapport que j’avais rédigé à cet effet.

Pourquoi ne pas avoir abordé InstallShield ? La raison est très simple, je considère qu’InstallShield fait parti des produits que beaucoup de personnes achètent mais qui au final restent dans la boite. Je l’ai constaté chez mes précédents employeurs mais également chez mes anciens clients, InstallShield parait très bien au début, mais dès qu’on souhaite qu’il réponde à des besoins précis, c’est le début de la fin, c’est le début des galères.

Durant mon étude j’avais quand même bien évidemment fait quelques recherches sur internet afin d’avoir un ressenti global des dernières versions du produit et ce ressenti était négatif. On trouve en effet assez facilement des retours d’expériences très négatifs de personnes qui déconseille fortement d’utiliser ce produit.

Un petit tour sur Twitter confirme d’ailleurs cette impression :

image
(cliquer pour agrandir)

Après discussion avec des collègues ayant lu mon rapport, je décide donc quand même de télécharger une version d’essai de cet outil sur le site officiel. Et en garçon bien élevé je remplis donc le formulaire de téléchargement avec mes coordonnées.

Quelle ne fut pas ma surprise de voir le chef de produit de Flexera Software m’appeler au téléphone alors que je venais à peine de finir de télécharger l’outil (oui nous avons une connexion internet qui aime bien faire le tour du monde avant de nous renvoyer les paquets direction Pau…).

Suite à ce (court, je vous l’avoue) échange téléphonique, je vous propose donc une petite liste d’éléments à éviter de faire si vous souhaitez me vendre un produit :

  • Règle n°1 : Ne pas me téléphoner alors que je viens à peine de finir de télécharger une version d’essai ! Cela laisse un sentiment d’agression très désagréable. Si je viens de télécharger une version d’essai c’est que… euh… je veux juste essayer le produit. Pour une enquête de satisfaction, un mail ou un appel à la fin de la période d’évaluation est plus pertinent qu’un appel alors que l’on a rien essayé du tout.
  • Règle n°2 : Se présenter correctement afin d’être facilement indentifiable. Hint : La marque InstallShield est immensément plus forte que Flexera Software. Se présenter avec le nom de cette société, c’est être certain de ne pas être identifié par l’aimable personne qui répond au téléphone.
  • Règle n°3 : Si l’on tombe sur quelqu’un de patient qui se dit prêt à prendre 5min pour répondre à des questions, poser des questions PERTINENTES ou à QCM. Le QCM est une excellente forme de questionnaire pour donner l’illusion au sondé de ne pas avoir à réfléchir et de rester passif. Plus le sondé aura l’impression d’avoir à faire avec des questions stupides où les réponses sont évidentes et/ou à des questions qui demandent de réfléchir, plus il y a de chances qu’il se dise “rah il me fait c**** avec ces questions à la ***”. Le QCM permet d’avoir des réponses simplement et rapidement, pas besoin de réfléchir à la formulation de la réponse = peu de rejet.

Sur ce, vous l’aurez deviné, attendez-vous à avoir un feedback sur InstallShield dans les prochains jours sur ce blog…

image_312

Et oh il y a quelqu’un ?

C’est un peu le sens de la question que l’on m’a posé il y a quelques instants jours où mon interlocuteur me demandait si je connaissais des flux RSS à propos de .net intéressants et en français.

imageJ’ai en effet un “catalogue” de flux assez important que je m’efforce de maintenir régulièrement (autant en ajoutant des abonnements qu’en en supprimant) et il s’agit d’une des rares choses que j’ai toujours refusé de partager intégralement.

Mettre en place une veille technologie via RSS demande du temps, et de l’expérience pour arriver à ce qu’une veille journalière soit simple et rapide à faire, bref, pour qu’elle soit efficace. Je ne souhaite donc pas partager l’intégralité de ce travail de fourmi mais j’en partage à l’occasion un extrait par thème pour indiquer par exemple, quels sont les meilleurs flux sur WPF, sur TFS, etc. Je partage néanmoins certains résultats de ma veille via les News de la semaine.

Revenons donc à nos flux français, et sans avoir besoin de trop réfléchir, je sais déjà que la majorité des flux FR auxquels je suis abonné ne sont pas des flux RSS techniques (alors que la très grande majorité de l’ensemble des flux auxquels je suis abonné l’est…)

Afin d’avoir une idée plus précise je me suis donc lancé dans un parcours manuel, et je vais partager cette liste avec vous :

Lionel Limozin http://www.paslatek.net/ [14/03/11]
Romain Verdier http://codingly.com/ [18/04/10]
Mitsu Furuta http://mitsufu.wordpress.com/ [21/12/10]
Guillaume Belmas http://blogs.codes-sources.com/kangoo/default.aspx [28/10/10]
Michel Perfetti http://blogs.codes-sources.com/miiitch/default.aspx [14/03/11]
Guillaume Andre http://www.guillaumeandre.com/ [07/11/10]
David Catuhe http://www.catuhe.com/ [14/03/11]
Benoit Laut http://benoitlaut.net/ [11/03/11]
Simon Ferquel http://www.simonferquel.net//blog/Default.aspx [14/06/10]
Sebastien Pertus http://www.dotmim.com/ [02/03/11]
Guillaume Lacasa http://blog.adhess.net/ [01/03/11]
Etienne Margraff http://blogs.codes-sources.com/etienne/ [08/03/11]

Quelques remarques à propos de cette liste :

  • Je connais personnellement toutes ces personnes. Je pourrais m’auto congratuler en me disant que c’est le résultat d’un excellent networking mais je pencherais plutôt vers une interrogation plus primaire “Euh… Mais ils sont les où les autres, on est les seuls à faire du .net ?”
  • L’exacte moitié d’entre eux sont des anciens collègues
  • Et une moitié seulement ont blogué quelque chose… depuis le  début de l’année
  • En plus de ces flux, je consulte assez régulièrement les blogs de CodeS-SourceS, je m’abonnerais volontiers à certains d’entre eux mais je DETESTE m’abonner à des flux qui n’exposent pas leur contenu en entier. Je considère que l’objectif du RSS est de syndiquer du contenu et non des résumés, il faut donc que je considère que la valeur ajoutée du blog soit assez importante pour que je transige à cette prise de position.
  • En volume, cette liste représente … moins de 5% de mes flux.

Bloguer (et qui plus est régulièrement) est compliqué et nécessite d’y investir BEAUCOUP de temps. Même si l’on trouve au tout début la motivation pour arriver à consacrer le temps nécessaire à cette activité, il n’en reste pas moins que faire vivre un blog tout au long de l’année est une tâche hardue. Il n’est donc pas très étonnant de voir ce faible nombre de flux et de constater que l’activité de ces flux est en moyenne assez faible.

De plus, une bonne partie de ces blogs fournissent un contenu qui (et ce n’est que mon avis personnel) ne devrait pas être dans un blog. Le contenu est souvent assez structuré pour ne pas être présenté sous la forme d’un post qui sera lu uniquement par les lecteurs du blog mais devrait faire l’objet d’un article posté sur un des sites communautaires disponibles en France. (ASP-PHP.net, TechHeadBrothers, pour ne citer qu’eux)

Ces sites permettent d’avoir une visibilité bien supérieure que sur les blogs et permettent de syndiquer du contenu de bonne qualité puisque relu et validé par ses administrateurs / modérateurs. Je pense que le premier réflexe des auteurs est de se dire que le temps investi dans la rédaction d’un article doit leur revenir directement et intégralement. Ce sentiment est légitime mais je reste convaincu qu’il s’agit d’une démarche contre productive pour les raisons évoquées ci-dessus.

Bon maintenant que je me suis permis d’indiquer que je pensais qu’il y avait moyen de bien mieux faire pour animer et faire vivre la « communauté », je me dois de partager quelques idées/pistes :

  • Mettre en place des blogs multi-auteurs. Parvenir à publier des posts (intéressants et intelligents qui plus est) tous les jours de l’année à 07:00 du matin, et avoir plus d’une année de posts d’avance est réservée à une élite unique, il est inutile de songer à atteindre un tel niveau. La solution si l’on souhaite publier régulièrement des posts de qualité autant sur le fond que la forme (pour le fond et la forme  Codingly est une bonne référence) est de s’y mettre à plusieurs. Si Jean Marc Morandini l’a compris depuis des années, je suis persuadé que des développeurs peuvent faire de même !
  • « Laisser tomber les blogs » et écrire des articles !

Pour conclure, je tiens à préciser que l’intégralité de ce post ne reflète que mon avis personnel (même si je sais que les idées décrites sont partagées par les quelques personnes qui l’ont lu avant publication) et c’est d’ailleurs bien pour cette raison que cela fut l’objet d’un post de blog et non d’un article 😉

Et vous qu’en pensez-vous ?

Le principe de précaution

“Quelqu’un peut il m’expliquer pourquoi il arrive fréquemment, dans une équipe
projet, d’avoir une ou deux personnes qui ne peuvent écrire une classe sans écrire,
systématiquement, une ou plusieurs interfaces ou classes abstraites qui, en fin de
projet, ne sont finalement implémentées que par une classe voir pas du tout ?”

Voilà en substance un mail qui a lancé un débat intéressant entre collègues. Et je
dois dire que je suis d’accord avec ce constat et qu’il est vrai que j’ai parfois
l’impression que certains développeurs pensent que savoir développer proprement et
professionnellement signifie devoir implémenter 9879798 interfaces et classes abstraites
et ajouter 98770754 niveaux d’abstractions. Après tout, rajouter de l’abstraction
est le premier réflexe que l’on peut avoir lorsque l’on essaie d’atteindre l’objectif
premier de tout développeur qui se respecte :

Ecrire du code maintenable

Cet objectif est en effet primordial afin de réduire le coût de développement (et
de maintenance) d’un projet. Mais il mène parfois vers le travers évoqué ci-dessus.

Cette
mauvaise habitude appelée “le syndrome du “ocazou”” par David,
se rapproche beaucoup du principe de précaution dont on parle beaucoup en ce moment.
Adapté au développement logiciel celui-ci pourrait se traduire par :

“ l’absence de certitudes, compte tenu des connaissances techniques du moment,
ne doit pas retarder l’adoption de mesures effectives et proportionnées visant à prévenir
un risque de dommages graves et irréversibles au projet de développement à un coût
économiquement acceptable ”

Seul problème avec ce genre de principe de précaution, il est très souvent difficile
d’arriver à proportionner correctement son action afin d’éviter les problèmes par
la suite. L’actualité récente l’a montré, le principe de précaution incite souvent
à exagérer la menace, et a dans quasi tous les cas une certaine faculté à faire exploser
les coûts pour un résultat… souvent peu mesurable.

En réalité, la maintenabilité doit certes être basé sur du code propre et bien structuré,
mais il repose également sur deux principes fondamentaux :

  • Le principe KISS (Keep
    It Simple and Stupid)
    : Plus un code est simple et plus il sera facilement
    compréhensible et maintenable. Ajouter de la complexité en ajoutant des niveaux d’abstractions
    inutiles ne fait… qu’ajouter de la complexité.
  • Le principe
    YAGNI
    (You aren’t going to need it)
    : Ce principe indique qu’il
    ne faut pas ajouter des fonctionnalités ou du code tant que l’on n’en a pas réellement
    besoin.

Ces deux principes sont d’autant plus valables que nous avons à présent des outils
efficaces (comme ReSharper) permettant
de refactoriser intelligemment son code afin de faire évoluer son architecture quand
on a en besoin
. Inutile donc de rajouter de la complexité en prévision
du futur, il ne sera pas trop tard pour le faire par la suite…