jegounblog.overblog.com

La maîtrise d'ouvrage informatique pour les nuls (et les blogueurs)

Dans la vraie vie comme dans les blogs, on me demande
parfois ce que je fais comme métier, mais comme il est assez rare, j’ai du mal
à l’expliquer et mes interlocuteurs n’arrivent pas s’imaginer. Si j’étais
barman, je dirais : je suis barman. Les gens savent ce que c’est. Si j’étais
informaticien, je dirais : je suis informaticien. Les informaticiens
comprendraient, évidemment. Les autres imagineraient un type plongé dans un
clavier à faire « des programme ». En déjeunant
avec des copains hier, j’ai trouvé la manière d’expliquer mon boulot à partir
des blogs.



Pierre a un blog dans une plateforme qu’il ne supporte plus
et souhaite tout migrer sous Blogger qu’il connaît bien. Il nous dit ça ainsi qu’il
voulait récupérer les flux RSS de l’ancien pour le mettre dans le nouveau.



Dans mon boulot, Pierre est « l’utilisateur » (d’une
application informatique). On dirait qu’il exprime un besoin (changer de plateforme
de blog) et je suis le type chargé de recueillir le besoin afin de l’exprimer à
l’informaticien.



Nous sommes trois à table. Pierre est l’utilisateur. Je suis
la maîtrise d’ouvrage. Le troisième, Hip, représente l’informaticien (mais pour
les besoins du récit, je noircis beaucoup ses traits).



L’utilisateur a exprimé un besoin : migrer son blog
vers Blogger en récupérant l’historique à partir des flux RSS.



Le premier travers de l’utilisateur est de farcir sa
demande de spécifications techniques alors qu’il n’y comprend absolument rien.
En l’occurrence, les spécifications techniques sont :

-
l’ouverture d’un blog Blogger,

-
l’import à partir du flux RSS.



C’est toujours pareil, c’est plus fort que lui, il est
persuadé connaître quelque chose en informatique et pose déjà, avant de savoir
ce qu’il voulait réellement faire, des jalons techniques.



L’informaticien a généralement tendance à plonger dedans. Il
a une demande d’un client et peu la facturer. Tant mieux. Souvent, l’utilisateur
s’en fout du prix : ce n’est pas lui qui paye, son chef n’a qu’à se
démerder auprès de la direction pour avoir du budget.



En fait, c’est même pire, sur les deux spécifications
techniques de l’utilisateur, l’informaticien réussira à faire sauter la bonne,
en l’occurrence Blogger, parce qu’il préfère Dotclear qu’il maîtrise mieux, mais il conserva l'intégration des flux RSS.



C’est là que j’interviens. Je connais un peu le métier (les
blogs, j’en tiens 6 mais en amateur, c’est-à-dire en me foutant des aspects
financiers) et je connais un peu l’informatique (j’ai été développeur pendant
huit ans). Je suis la « maîtrise d’ouvrage ».



Je réponds à Pierre : « Oui,
pour l’utilisation que tu vas à en faire, utiliser Blogger est un bon choix
puisque tu connais déjà un peu. Par contre, ce n’est pas à partir des flux RSS
que tu vas récupérer l’historique. Tu as dans l’ancien blog une fonction d’exportation
et, dans le nouveau, une fonction d’importation mais je ne sais pas comment ça
marche. »



A ce stade, dans une entreprise (et évidemment pour un sujet
plus important), un de mes homologues aurait proposé de prendre un consultant
pour étudier les différentes méthodes pour incorporer l’historique d’un blog.



Pas moi. Et c’est pour ça que mes chefs m’aiment bien :
j’arrive à leur faire économiser du pognon.



J’interviens donc avant que l’informaticien, Hip, ne l’ouvre
et propose d’étudier les différentes méthodes pour incorporer l’ancien blog
dans l’autre et vendre la prestation correspondante.



« Pierre, ce dont tu as un besoin :
ouvrir un blog sur une nouvelle plateforme pour écrire des billets mais comme
tu blogues au sujet de l’actualité, comme moi, es-tu sûr d’avoir besoin de l’historique ? »



Lui : « Ah ben non, tu
as raison, je vais repartir de zéro. »



L’utilisateur avait inventé un besoin (migrer un blog) alors
qu’il en avait un autre (créer un blog). C’est très souvent le cas, d’autant qu’il
y a généralement un tas d’intermédiaires qui ne comprennent pas vraiment ce qu’il
faut mais qui tiennent à leur poste et à leur budget. Le fait que je puisse
voir Pierre en face à face a fait que j’ai pu l’aider à faire le raisonnement.



Ainsi, il s’imaginait passer un week-end à galérer alors que
ça va lui prendre 35 minutes.



Un week-end : ben oui, quand on ne sait pas comment
faire, il faut faire des recherches. Dans la vraie vie, on fait appel à un
informaticien qui va facturer très cher une prestation parce que l’utilisateur
sera bloqué et pressé de changer de plateforme.

35 minutes : j’avais fait le test, tout compris, dont
la blogroll et le compte twitter pour balancer le flux (et le passage chez Feedburner
mais c’est dépassé,
semble-t-il).



Voila mon métier : simplifier et économiser. Et voila
pourquoi mes chefs m’aiment bien : je le fais à fond et sans avoir besoin
de consultant…



Ce n’est pas fini mais je vais m’attarder un peu.



Dans la pratique, une tache que Pierre aurait probablement
mis douze heure à accomplir aurait pu être faite en deux heures pas Hip mais il
l’aurait facturée 8 (dans la vraie vie, Hip étant un copain, il aurait fait ça
pour une bouteille de vin). En passant à une demi-heure, j’abuse un peu. Pierre
n’ayant pas mon habitude de créer des blogs et des comptes Twitter, il aurait
mis une heure. J’ai donc fait diviser la facture finale par huit.



Dans la vraie vie, ça veut dire que j’aurais pu faire passer
un projet informatique de 400 000 euros à 50 000, soit une économie
de 350 000… en y consacrant une demi-heure au cours d’un déjeuner.



Ce n’est pas fini, disais-je…



Pierre : « Oui, mais je
fais comment pour récupérer mon nom de domaine ? » Et là, je
suis sec. Je ne sais pas quoi lui répondre mais j’ai immédiatement une idée :
« Mais qu’est-ce que tu en as à foutre ? On
est moins de 10 à le connaître, je suppose. Tu peux en prendre un nouveau ! »



Pierre : « Oui, mais j’y
tiens, moi, à mon nom de domaine. » Me voila emmerdé. L’informaticien,
Hip, voyant qu’il a presque tout perdu intervient alors, puisque c’est bien son
domaine de compétence. « Ah ! Mais je vais
te le faire, moi, ça va me prendre quelques minutes mais ton blog sera hors
service environ 48 heures. »



Je cède. Il faut toujours céder un peu. L’utilisateur aura l’impression
d’avoir remporté une victoire et obtenu gain de cause. L’informaticien ne me
détestera pas et accèdera à mes prochaines demandes.



Le plan d’action est défini :

-
Pierre va créer son nouveau blog,

-
Pierre et Hip vont prendre rendez-vous
pour paramétrer le nom de domaine.



Mais je suis un vieux briscard. Je sais à peu près comment
ça va se passer : ils ne prendront jamais rendez-vous parce qu’ils n’auront
pas le temps. En fait, je n’en sais rien mais dans la vraie vie, ce qui va se
passer est que le chef de l’informaticien va gonfler un peu le devis. Même s’il
n’est pas trop élevé, Pierre ne trouvera personne dans sa hiérarchie pour un
truc aussi peu important.



Alors, c’est là que je reviens. En fin de projet, quand on
tombe sur un os.



Pierre va lancer son nouveau blog mais sans nom de domaine,
je vais aller voir son nouveau blog puisque ça fait partie de mon job et je
vais constater qu’il n’aura pas récupérer le nom de domaine. Je vais lui
demander : « Bon, qu’est-ce qu’il se passe ? »
Lui : « Bah ! On n’a pas encore fait,
trop chiant… ».



Moi : « Mais au fait,
pour ton nom de domaine, tu n’as qu’à garder le nom et remplacer le « .com »
en « .net », il sera toujours aussi chouette ! » Lui :
« Ah ben oui, tiens ! »



Il sera content et me bénira (ce qui veut dire qu’il m’invitera
à nouveau à déjeuner), le service qu’il voulait lui sera totalement rendu. Le
besoin qu’il avait exprimé au départ aura été oublié et il pourra avoir l’usage
qu’il voulait de son nouveau blog.



Le besoin et l’usage…



Hip, l’informaticien sera également content et me bénira (je
vais prendre du ventre, si ça continue). Il avait promis de résoudre le
problème de Pierre mais il n’a pas pu le faire à cause de leurs hiérarchies
respectives, il n’était pas fier de lui. J’ai trouvé un palliatif. Il est
sauvé.



Résumons…



Dans la vie, il y a les utilisateurs d’applications.
Concrètement, ce sont généralement des « services marketing » qui
doivent proposer des nouveaux produits ou services aux clients et des « services
organisation » qui doivent organiser le travail des employés.



Ils font des expressions de besoin mais qui :

-
coûteraient extrêmement chers,

-
ne correspondraient pas exactement aux
besoins que pourraient en avoir les utilisateurs parce qu’ils n’ont pas
nécessairement le recul nécessaire,

-
contiendraient des contraintes techniques
totalement inutiles.



Dans la vie, il y a les informaticiens qui :

-
ne connaissent pas le métier du client
donc ne sont pas à même d’apporter le conseil nécessaire : ils répondent
aux demandes,

-
ont tendance à surfacturer, notamment
pour se couvrir (mais aussi pour plein d’autres raisons).



Il faut un gugusse pour que les deux se comprennent et pour
modérer leurs ardeurs réciproques.

http://bit.ly/R2k2SJ