Que celui qui n’a jamais pêché lui lance la première pierre.

Très c(h)ri(s)tique comme entrée en matière, mais à défaut de présenter le sujet de la victimisation au travail, je veux commencer par abattre le syndrome du bourreau. (niark niark)

Pour critiquer quelqu’un il vaut toujours mieux être blanche neige, pure, sans tâche, sans défaut, et surtout, sans écarts, jamais.

Le risque de dire « ouais moi tous les matins à la clope, je la vois arriver en retard à n’importe quelle heure » c’est de vous prendre en retour un « ouais enfin si c’est pour venir à 8H et fumer jusqu’à 11 tu n’es pas plus productive qu’elle, et on t’as pas embauché pour être concierge.

Blanche neige vous dis-je.

Soyez toujours factuels dans les éléments que vous montrez : « il/elle a du mal à finir dans les temps » (quelle que soit sa raison, on s’en fout) « il/elle produit des livrables où certaines erreurs persistent » (plutôt que « il/elle fait que de la merde ») « Il a beaucoup de réunion, et très peu de disponibilités » (plutôt que « il est jamais dispo, c’est la grosse merde » même si pour le coup ce n’est que la vérité).

Evitez tout jugement personnel, tout le monde a des mauvaises passes et vous n’êtes pas à l’abri que cela vous arrive, en particulier quand vous râlez ou vous mettez en colère, ça ne doit pas être une habitude, mais une chose plutôt rare, car vous ne montrez pas que votre insatisfaction par cela, vous montrez aussi que vous êtes instable.

Si vous n’êtes pas satisfait d’un employé rappelez-vous qu’un employé qui ne connait pas ses limites c’est d’abord un manager qui a oublié de les lui fixer.

Dans le meilleur des mondes ne soyez pas celui qui jette la première pierre, commencez par dialoguer. Le fait d’envoyer une critique c’est s’exposer à ce qu’elle revienne en boomerang dès que l’occasion se présente (Que vous soyez manager ou pas, mais surtout surtout si vous n’êtes qu’un passe plat, les opérationnels sont les ouvriers de la production, il faut savoir les encourager et les respecter avant que de les juger et de les sanctionner). Commencer par lapider quelqu’un c’est légitimer  la généralisation, la reproduction, de ce comportement. C’est légitimer qu’on vous le fasse à vous, et bon, avouons-le bien, on aime bien pourrir la gueule des autres, mais on n’aime pas se la faire pourrir soi (enfin tout dépend de vos penchants hein, mais on n’est pas là pour parler de vos préférences sexuelles).

Rappelez-vous que dans le cadre professionnel on ne veut pas savoir votre sentiment, vos impressions, ou votre avis « humain » on cherche votre opinion par rapport à un cadre, un contrat, un client, une situation, et un potentiel de perdre ou de gagner de l’argent. Non ce n’est pas inhumain, bien au contraire c’est le meilleur moyen d’être juste et équitable, dans ressources humaines, il y a d’abord ressources, ensuite, il y a humaines.

Les ressources sont toujours épuisables, parfois épuisées, parfois lassées, parfois démotivées, pour pratiquer le renouvellement il ne faut pas toujours miser sur le changement de ressources, mais sur la progression de celles-ci, la prise de conscience et la responsabilité, et ça, ça n’a jamais fonctionné à coup de lynchage, ni à coup de pressions « habituels ». A la fin, une ressources qui se fait tout le temps gueuler dessus, jamais féliciter, ce n’est qu’une ressources qui peut, ou veut partir, et forcement qui ne fait QUE de la merde n’ayant plus rien à gagner, ni à perdre.

Du management au ménagement.

Entre Management et Ménagement, il n’y a qu’une seule lettre, et pourtant pour certains parfois, il existe un gouffre. Qui veut voyager loin ménage sa monture. C’est un vieil adage mais qui malgré tout, trouve encore sa place dans le monde professionnel.

Une ressource qui travaille à 100% tout le temps est difficilement disponible pour faire du 130, 140, voire 150 %. Toutefois, si elle travaille à 80% tout le temps il sera plus facile de lui faire faire du 100 voire 120 % de temps en temps.

La qualité des relations avec les ressources risquent aussi d’être altérées si on se met à leur trouver un défaut de productivité (alors qu’elles travaillent déjà comme des chevaux de postes). Une personne qui se sent, et se sait, haïe, ou du moins peu appréciée, ne fera rien pour vous prouver que vous avez tort,  mais passera plutôt son temps à vous donner raison : lorsqu’on a rien à perdre, et plus rien à gagner, pas même le respect, on se limite au stricte minimum. Et là plus moyen de parler de qualité lorsqu’on a le nez collé à la quantité.

Afin de tirer le meilleur des ressources comme d’un bon café il faut partir d’un optimisme permanent et d’une foi sans borne : elles peuvent toujours devenir meilleures, et il faut le leur montrer. A défaut d’avoir la possibilité de pouvoir augmenter leur salaire, autant les faire apprécier ce qu’elles font en en leur donnant le bénéfice du doute, de l’utilité et la valorisation du travail fait avec le meilleur de soi, redonner de l’égo vaut parfois plus que donner de l’argent. Même si l’un ne remplacera jamais l’autre.

Aussi, il faut écouter les « attentes » des ressources. Un chef de projet n’est chef que d’un projet, c’est très abstrait et très inhumain pour le coup. Il faut alors se demander ce qu’on peut apporter, quels inputs sont nécessaires aux équipes pour qu’elles travaillent correctement. Souvent on découvre aussi ici qu’il suffit d’arrondir les angles, de limer un peu les bords … de soi-même : d’améliorer son discours, et la qualité des informations transmises. Parfois ça passe par un reporting bug précis, parfois par une documentation complète qui fait le tour de tout ce qu’il y a à savoir, parfois, c’est aussi une réponse positive, claire, réactive, à une demande : si une personne vous dit qu’il lui manque quelque chose pour travailler, ça ne veut pas dire qu’elle ne le fera pas, mais cela veut dire qu’elle le ferait mieux, avec plus de confort, de sécurité, et d’assurance de la précisions et de l’adéquation de sa réponse à votre demande. C’est un peu de la cuisine, ou de la danse classique, il faut parfois ajuster beaucoup de détails pour obtenir un résultat plus que simplement regardable ou comestible, mais pour ce dire que « c’est très bon » voire « appétissant ».

D’ailleurs, parfois, agrémenter un « tout est ok » par un « ok, c’est bon, ça fonctionne, et c’est conforme à ce qu’on t’a transmis/demandé » même si la qualité ne vous semble pas totalement au rendez-vous, permet de vous remettre en question en vous demandant ce que vous auriez pu, vous-même, mieux transmettre, mieux exprimer, mieux formuler. Au fond c’est même plutôt sain de résonner ainsi, ça veut dire que vous aussi, votre métier, vous l’apprenez, de mieux en mieux, et vos ressources n’en seront que plus heureuses de vous savoir progresser, comme elles, à l’unissons.

Et Dieu Créa l’Agilité pour les projets…

Au départ, au commencement, la gestion de projet Agile c’était meugnon, plein de grands principes et de jolis propos, visant à rendre une meilleure et plus rapide qualité de service, de faire apparaitre plus vite des outils… Ben oui, au lieu de faire de gigantissimes expressions besoins, des spécifications à n’en plus finir, des cas d’utilisations discriminant, et déterminant, à la pèle en veux-tu-en-voilà , le tout pour partir gentiment en excursion sous marine de mise en œuvre pour parfois revenir, au mieux, en ayant été oubliés (mais payé) ou, au pire, en ne correspondant plus aux attentes qui avaient évoluées entre temps (les coquinoutes), on pouvait alors prôner l’Agilité, la Souplesse, le Dynamisme ! Et c’était aussi émouvant que la déclaration d’indépendance, que l’abolition de la l’esclavage et que l’invention de la roue.    

Les développeurs étaient  tout le temps, à s’agiter sous les yeux d’un représentant métier et à lui demander tout plein de choses à faire, et le chef de projet passaient son temps à poser des questions  ça donnait la garantie certaine qu’ils bossaient et qu’ils essayaient au mieux de répondre aux besoins…  

Oui mais voilà, du coup, il a fallu mettre en place des modes de fonctionnement très très rigoureux, parce que le manifeste qui disait que la « collaboration des parties » devait prendre le pas sur la contractualisation, a fait déborder un peu les caprices de la clientèle dans des proportions budgétaires aussi hasardeuses qu’exponentielles.

C’était de fait, donc, plus cher mais au moins là du coup, on savait dans quoi on dépensait, puisqu’on le suivait à la semaine parfois à la journée, alors open-bar on faisait sa liste de course et en toute mauvaise foi on osait dire que les développeurs, qui travaillaient déjà comme des chevaux de poste qu’on remplaçait régulièrement, tellement on les usait moralement, n’en faisaient pas assez dans le périmètre du projet.

Et c’était bien là tout le problème. Le périmètre du projet n’étant défini que dans ses grandes lignes, il devenait le tonneau des développeurs à défaut de celui des Danaïdes.

Ce qu’on tricotait avec ses petits doigts de développeurs, un jour, on le détricotait le lendemain pour faire une autre partie. A la fin, on était à la fois plus tellement sûr de réaliser un pull-over tellement on y avait mis de poches, de raccords, de bout de laines ou de ficelles, de ci de là et on avait tellement découpées de parties, remplacés des bouts par d’autres, que la cohérence technique ET fonctionnelle de l’ensemble en pâtissait, mais on était un peu incapable de comprendre comment on en était arrivé là, puisqu’on avait quand même assigné des chefs de projets qui étaient sensés assurer la maitrise de l’ouvrage, et donc, tout l’équilibre de l’ensemble…

Vite fait bien fait, il a donc fallu mettre en place un mode de gestion budgétaire tangible, compréhensible, pilotable, et à défaut d’un processus (puisque le manifeste encourageait plus à la compréhension humaine qu’à la rédaction de spécifications) mettre en œuvre une méthodologie et une flopée de bonnes habitudes :

Dans les grandes lignes ça a donné ça :

Phase 1 : Définir un périmètre fonctionnel à grosse maille, et un pré-découpage fonctionnel rapido –et les chiffrages correspondants) –Et demander la production en conséquence d’un budget pour cela.

Phase 2 : Prévoir le bas de laine : laisser quelques cases vides avec de quoi faire dedans, pour les fonctionnalités supplémentaires à venir (inévitablement) –et les clients, quand ils peuvent faire quelque chose, ils auraient tort de se priver, alors ils font-   

Phase 3 : Surveiller, quotidiennement la consommation des ressources et vérifier la cohérence entre la vélocité des équipes, le consommé, le reste à faire, et les briques fonctionnelles (et là tous les outils sont bons pour réaliser cela : de votre cerveau en passant par votre calculette, votre tableau Excellent, ou votre pur outil de gestion de projet qui envoi du poney),

Phase 3.1  s’affoler vigoureusement si à 1/3 du budget, 1/3 des fonctionnalités n’ont pas été réalisées. –à noter que s’affoler vigoureusement, ne consiste pas agiter les bras frénétiquement mais bel et bien de faire un rapport d’identifications des raisons du retard, et d’en avertir le client-

Phase 4 : A 2/3 du budget consommé, procéder à un contrôle rigoureux du Reste A Faire (le RAF) et des fonctionnalités ajoutées dans les cases vides, et déterminer s’il faut rentrer en phase 5.

Phase 5 : Commencer à faire de la gestion des priorités –et donc commencer les exclusions voire la chirurgie- et/ou à demander à nouveau du budget.  

(Bon, ça ne s’applique pas si vos budgets sont infinis, vos clients adorablement réalistes, vos investisseurs peu exigeants, et que le monde autour de vous est peuplé de Bisounours)

Et en contrepartie ça obligeait :

– A chaque nouvelle « évolution » demandée par le client, à défaut de la refuser, de tracer les changements (et donc de quantifier les impacts (non, les méthodes agiles ne réduisent pas le temps de travail, surtout pas du Chef de Projets) pour pouvoir faire un ratio du Delta entre ce qui était prévu à T0, ce qui s’est passé à T1, T2, T3…TN et à faire la différence finale entre TN et T0 pour en apprendre un peu plus.

– A accepter que les temps de réalisation que vous aviez communiqués étaient a) Soit compressibles (et du coup, un tout petit peu bidons ;)) b) Soit incompressibles (et du coup, un tout petit peu pas réalistes) c) n’étaient pas les éléments sur lesquels on devait faire reposer la « dynamiques » de la gestion de projet agile, mais uniquement les bonus de celle-ci. –je vous laisse réfléchir sur quoi on plaçait la souplesse alors ;)-

A Ranger sa timidité ET son stress au placard pour communiquer, collaborer et joyeusement interagir avec les équipes techniques mais aussi ne pas leur transmettre de parasites (entendez sollicitations directes qui auraient pu être évitées), parce que déjà bien assez sollicitées (même si bon, c’est connu, les teckos sont des gurus, et on ne leur confierait pas ce travail s’ils n’étaient pas experts ( ?!) –Mais oui, ayez la foi… et, si vous n’avez pas la foi : persuadez vous !-)

– A apprendre à dire « non » en souriant, ou à répondre « ok pour ça, mais du coup, on doit retirer quelque chose, on enlève quoi ? » comme on faisait avant, sans Agile, et qu’il fallait placer son sacro-saint « oui, mais » dans les conversations avec le client.

En conclusion, agile c’est ni mieux ni moins bien que les méthodes de gestion de projet « classiques », c’est différent, cela dit, ça ne doit pas empêcher d’avoir un peu de rigueur, et donc d’en connaitre les écueils.

Il tape sur des bambous….

 

La première chose qu’on vous apprendra dans un séminaire de management, c’est que dire « c’est moi le chef » sous toutes les formes de déclinaisons possible (de « les décisions, c’est moi » en passant par « elle me donne pas des ordres ! » ou encore « non mais j’vais lui mettre des claques ») c’est le BAD.

Je ne vous expliquerai pas, puisque vous êtes chef, vous savez tout, et vous avez toujours raison, et donc vous savez parfaitement pourquoi il ne faut pas le dire.

La première chose qu’on vous demandera dans votre métier de collaborateur (et parce que vous avez des petits camarades), c’est qu’exprimer ses sentiments au travail ne mène a rien (oui, je sais, c’est dur, des fois je me dis que je suis mal placée pour parler, m’enfin…) « mon opinion c’est que c’est ça » (basé sur quel faits ?) « Mon sentiment c’est qu’on devrait faire comme ça » (pourquoi ?) « Non mais moi je pense qu’on devrait faire comme ça » (c’est bien de penser, c’est un bon début, cela dit, votre pensée ne vous rend pas pour autant plus crédible si elle n’est basée que sur un vague sentiment de supériorité intellectuelle qui vous laisse croire que vous êtes dispensé de justification)

Oui, c’est sûr, c’est dur d’avoir des arguments, déjà parce qu’il faut les trouver (oui et parfois, ça, c’est pô facile, et google ne trouve pas tout pour vous), ensuite parce de fait, quelqu’un peut (éventuellement) les contredire, ou ne pas être d’accord avec (peut-être), ou qu’un autre argument pourrait y être opposable (bon je veux pas vous rendre parano, mais c’est la vie hein, j’vous réexplique pas les globules, si ?).

Et c’est encore plus dur, de réaliser qu’on est persuadé d’avoir raison, et de s’entendre dire qu’on a tort. (et parfois, on a tort) (si, je vous assure) (ne doutez pas j’ai raison)

Cela dit… C’est le principe même du débat, de la confrontation, de l’avancement. Trouver un consensus, avec des sacrifices de chaque coté. Le sacro-saint WIN-WIN de toute négociation commerciale digne de ce nom, mais qui passe toujours par un juste milieu.

Quoi qu’il en soit, et en conclusion de cet article que je trouve, et pense excellent (oui, sans argument, du coup, c’est lourd hein ;)), je dirais qu’il ne sert jamais de taper du point sur la table pour imposer son avis, que la menace ne mène à rien, quelque soit le niveau hiérarchique qu’on a (surtout si tu es en dessous tiens !) mais (de nombreux consultant en management, vous dirons qu’) utiliser la méthode douce, l’humour, l’auto dérision, ou la caricature, seront autant de méthode beaucoup plus efficaces pour ne pas passer pour un tyran, et vous faire gagner la confiance (avec bien sûr, temps, et patience) de vos collaborateurs.

Il vaut mieux un bambou qui plit qu’un bâton qui casse.

Partnership : Main dans la main dans le même bâteau ?

Il n’y a pas de méthode miracle en matière de partenariat. Il n’existe pas un type de partenariat pour un type de stratégie : Le principe même du partenariat c’est « juste » Gagnant-gagnant, le tout c’est de savoir :
– ce qu’on gagne,
– combien on gagne, et…
– comment (par quels moyens) on gagne.
Bon pas d’illusions non plus, il faut identifier ce qu’on y perd aussi, le partenariat pouvant devenir une activité très chronophage, en particulier quand il s’agit d’un partenariat officiel, scellé par un joli contrat, une forme de Pacte de solidarité professionnelle, ou un mariage (Denis, si tu me lis…)

Quels sont les limites à fixer à un partenariat ? Les mêmes que pour les amis : je te prête mon appartement, mais pas ma femme : Pour un temps définis, et avec les limitations d’usage : que mes slips restent dans le tiroir, et si tu  vides le frigo, tu penses à refaire les courses. Bref, rien que de très surprenant, mais aujourd’hui le partnership s’apparente plus à du couchsurfing qu’à de la franche amicalité, ça reste cordiale, mais on peut le faire parfois avec de parfait inconnus, et tout particulièrement des gens qui font complètement autre chose que nous. Et c’est donc là qu’intervient la notion de stratégie.
Comme pour le couchSurfing peut permettre de multiplier des contacts « exotiques » avec des gens de différentes cultures pour échanger, partager, apprendre, et voyager aussi, faire du nouveau, le partenariat peut s’inscrire dans la conquête de nouveaux marchés inexplorés, ou simplement toucher du doigt des consommateurs dont on ne soupçonnait pas encore l’existence qui peuvent s’avérer fort rentables (pour peu qu’on apprenne un minimum la langue), et avec la diversification des produits, la diversification des offres, peut apparaitre une stratégie de partenariat atypique.

La problématique d’un partenariat c’est qu’il engage deux (ou plus) entités à échanger dans un format très… formalisé, avec des quantifications… très quantifiées, des rétributions très… marchandisées, mais rien que de très fructueux en soi.
Pourquoi ?

–          Parce qu’on perd du temps à vérifier que les taux de rétributions sont bien du montant fixé sur le contrat,

–          Parce qu’on doit limiter les échanges à des données particulières, mais ne pas rendre autonome, le partenariat c’est aussi une interdépendance de principe.

–          Parce qu’on doit affecter des ressources à la gestion des partenaires que ce soit pour la conquête ou pour le suivi.

–          Parce qu’on prend le risque d’être le point de réception des insatisfactions clients pour les services que ne fournissent que nos partenaires et que ça pourrait nuire à notre relation client.

Le partenariat tant donc à la frilosité la plupart du temps pour ces raisons (et bien d’autres) alors que les exemples de partenariats, entre frères ennemis comme entre lorel et hardy, sont profusion sur le marché des success story. Regardez Cocal-cola et Pepsi qui font des campagnes comparatives jumelées en se tapant la bourre sur les parts d’un marché du soda qu’ils ne divisent presque qu’en deux. Regardez les opérateurs téléphoniques, qui ne pratiquent pas les même type de forfaits pour éviter les comparaisons, lancent quasiment en même temps leurs offres « similaires », récupèrent les insatisfaits les uns des autres, et s’assurent une place sur le bateau (ce n’est qu’un secret de polichinelle). Bon, ces stratégies de partenariats sont basé sur la concurrence, c’est l’amour vache, ou partenariat B2B (Back to Back – dos à dos ou multi facette, si on souhaite changer de visage on fait pivoter le manège et on change de monture –mais finalement on paye pareil…). Mais on rencontre d’autres type de partenariats un petit moins évidant, et plus de l’ordre du lardon avec la patate basés sur l’union de 2 expertises pour une même cible potentielle, mais pour des services différents et complémentaires : ce sont les sociétés de type  coursier et vendeur de café ou de type assurance et crédit, ou encore hardware-software. Bien sûr dans ce cas de figure on essaye tant que faire se peut de se mettre à l’abri de se faire voler sa compétence par le ou les partenaires, on inscrits des clauses qui dispensent gentiment (et avec force avocats) de s’approprier le corps de métier (sans lubrification préalable).

Quoi qu’il en soit le partenariat vise surtout à rendre toujours plus de services que ce soit aux marchands ou aux consommateurs, qui comme les lemmings suivent gentiment le label jour de la garantie et aiment qu’on leur dise quoi devenir de leur courte existence…

Tu la sents ma grosse inclusion dans ton système d’information ?

La démarche d’harmonisation des procédures et processus, qui fait directement suite après la cartographie des processus doit s’accompagner de plusieurs éléments, et les plus complexes ne sont pas foncièrement ceux qu’on croit.

– D’abord harmonisez les processus avec l’organigramme de l’entreprise (en gros affectez des tâches de processus à des entités organisationnelles)

– Ensuite Harmoniser les moyens de communications : la base documentaire associée avec formalisme (définir le titre, les objectifs, le cadre, la cible, la source –les auteurs-les inputs, les outpouts, les étapes éventuelles, les documents relatifs, la date de prise d’effet et éventuellement la date de fin de prise d’effet, la version…) –Tout cela avec des modèles de document, avec règles d’utilisation, de validation et règles de répartition.

– FAIRE ADOPTER. (et c’est finit ? euh… presque)

Ha ha !!! Voilà le morceau le plus délicat ! FAIRE ADOPTER. Si rédiger des best pratices ne semble pas forcement aisé (Comment faire AU MIEUX ? selon quels critères ?), décrire l‘organisation de l’entreprise n’es pas foncièrement simple (qui fait quoi REELEMENT ?), recenser l’existent ne s’avère pas folichon (particulièrement fastidieux) « Faire adopter » est antinomique !!!! 

 Si L’adoption en soit procède de la volonté, Faire faire, est un acte de coordination ou du moins, de pilotage, et qui dit pilotage, dit capitaine et qui dit capitaine dit hiérarchie… (On en revient toujours à se problème d’insubordination on ne peut plus légitime, mais somme toute quand même un peu problématique dans les sociétés actuelles)

Et l’un ne va pas avec l’autre. Pourquoi ? Parce que l’adoption demande de faire entrer quelque chose de nouveau, amélioré, voire « différent » dans un environnement existant, ou tout le monde n’est pas foncièrement prêt à accepter le changement. Et là, une grande phase d’argumentaire, non pour convaincre mais pour expliquer, peut-être même « justifier » fait partie de la démarche.

Le premier mot d’ordre : Rassurer. L’accompagnement au changement se fait avec une bonne grosse dose de lubrifiant psychologique, ça passe donc, comme pour une visite chez un psychologue par une écoute attentive et poussée des gens dans leur métier, et leur corps de métier pour trouver comment il pourront adopter quelque chose le plus naturellement du monde, et pour que cela ne perturbe pas violemment leur mode de fonctionnement : mettez une pellicule autour du comprimé à avaler, et accompagnez le d’un verre de lait.  

Le deuxième mot d’ordre : Aider, Accompagner. Expliquer c’est aussi Former. Ne pas dire « voilà c’est bien mieux, regarde, ça va aller avec ce que t’as l’habitude de faire !» sans manuel, ni adaptation individuel, préparez donc tout ce qui est nécessaire pour l’adoption, la prise en main (et là, ne lésinez pas sur le moyens, manuels utilisateurs, formations, campagne de lancement, et comme pour la communication, vos meilleurs armes seront la simplicité, l’ergonomie et l’humour, la forme prime même bien souvent sur le fond, le fond lui-même étant souvent susceptible de changer)

Le troisième mot d’ordre : Patienter. Pas de mode « Big Bang voici un nouvel univers ! ». Si vous êtes persuadé du bien fondé des changements que vous apportez, gardez la foi, vos collaborateurs finiront d’eux-mêmes par adopter « la mode » que vous lancez: par conséquent, montrez l’exemple, commencez progressivement à répandre la bonne parole dans votre division d’appartenance, et contaminez lentement les autres. Vous aurez toujours des villages gaulois, qui feront de la résistance plus ou moins active, mais restez convaincu, tout vient à point…

Conclusion : ayez du lapin et de la tortue : ayez de grandes oreilles (pour écouter), soyez chaud (motivé), agitez votre ponpon (fédérez), faites preuve de sagesse et de patience (acceptez les points de vue sortez de votre carapace), avancez lentement mais surement (soyez progressif) gardez le rythme et partez à point (conservez des objectifs).

Processus Itineris Institutum

Lorsqu’on embarque dans une société où les processus ne sont pas « usages très courant » et où les procédures sont produites avec parcimonie (même s’il en existe toujours !) et où on doit cartographier ce petit monde, on se retrouve face à la problématique de devoir expliquer à quoi on sert. Et ça n’est pas aussi simple que ça…

Ce qu’on sait très largement, à grosse mailles (et si possible le plus macro possible) c’est que les procédures servent à mettre en place du contrôle, et les processus, de la marche à suivre. Bon accessoirement, les procédures et processus servent aussi à donner de la visibilité pour des investisseurs, garantir d’une méthode, d’un savoir-faire, de la maitrise de son activité… Mais dans notre mentalité de Français post-soixante-huitards-adepte-du-téléchargement-et-de-communication-libre, on n’aime pas trop le « contrôle ». Le contrôle ça ressemble encore beaucoup trop à tout ce qui est relatif à hiérarchie, et plus on tend vers du management 2.0 moins on croit dans l’horizontalité… et pourtant, la définition de la liberté est bien celle de choisir ses propres contraintes, sinon c’est l’anarchie.

Alors ? Alors, je suis moi-même plutôt du genre à aimer mon autonomie, une forme d’autarcie où je puise de l’information à droite et à gauche, ou j’engrange un maximum d’informations et où je fais mes propres synthèses. Je gère mon organisation de temps de travail avec mes méthodes, mes habitudes, mes petites routines bien organisées (mon planning, mes jalons, mes rapports, mes bilans, mes schémas…) tout cela en soit défini mon travail, l’organise pour les jours à venir, et à moi de me caler sur les priorités qu’on me fixe, et de communiquer.

Pour aller droit au but : Cartographier les processus d’une entreprise, c’est comme cartographier les sentiers de randonnée dans un circuit.

Je m’explique : On peut avoir différents but de randonnée : -rapidité, défi, découverte de la nature, recensement géologique… On peut aussi avoir différents niveaux : – débutant, confirmé, excellence, guide…

Pour chaque profil, chaque but, il faut se définir un chemin dans ceux répertoriés. Comment savoir lequel prendre si les sentiers de randonnée ne sont pas crées, parcourus, marqués ?

Un processus c’est donc un sentier éventuel de randonnée. Une procédure ce sont les étapes fortement recommandées. (Bon delà à dire que la vie en entreprise c’est une ballade de santé, je n’oserai pas… quoique). Cartographier les processus c’est donc donner les chemins à suivre de chaque personne pour couvrir toute la montagne que représente un métier. Pour les nouveaux arrivants c’est une méthode utile pour prendre en main les affectations qui seront les siennes en fonction de sa mission et de son niveau estimé, de s’approprier le terrain. Cela permet aussi de savoir quels pôles du métier ne sont pas décrits en termes de processus, quels sont les terra incognita par conséquent, qu’il faut créer. Le processus, comme le sentier se veut adaptable, (il doit pouvoir changer en cas d’éboulis, ou de flaque infranchissable) il doit donc évoluer au fil des besoins, toutefois, comment faire évoluer quelque chose qu’on n’a encore jamais décrit, tracé ? Les processus sont donc là pour l’accompagnement au changement. (Mais  je reviendrai sur le changement dans un autre sujet)  Et les procédures, donnent une marche à suivre, un modèle de cheminement métier.

C’est un peu un travail de fourmis, et il faut avoir un minimum de connaissance de la topographie générale des entreprise, une expérience de l’existant géographique métier, et puis, avoir un peu d’imagination aussi…

Be-High

Lors des quelques points projets, vous avez surement du voir débarquer un manager clinquant arborant le beau t-shirt de superman, pour vous annoncer, messianique, que votre étude sur votre problématique qui vous prend la tête depuis des mois « s’affinera avec les métrique » ou « les métriques nous en diront plus long » ou encore « les métriques vont diriger le môôôônde »  (informatique s’entend, mais bon, reconnaissez que c’est un bel grand univers) sans que sur le moment ça évoque beaucoup de chose pour vous,  ou vaguement un chapitre que vous auriez abordé en génie logiciel, ou en gestion décisionnelle des SI de l’IT de pointe, bref, un TRUC en vous demandant ce qu’il entendait par là.

Alors posons les bases, les métriques, aussi simplement que leur nom l’indique, sont des outils de mesures de quantités. Ca va un peu plus loin que l’indicateur, parce que ça donne du concret sous forme de chiffres.  En gros, c’est un peu comme une prise de sang, avec le taux de sucres, d’hormones, de cholestérols, on connait les bonnes fourchettes, et celles « à risque », les métriques donc servent à des comparaisons.

C’est un peu la vie de l’administrateur système le métrique, et le chef de projet doit en tirer de beaux indicateurs, pour faire de belles communications.

Le reflexe métrique c’est donc de se poser d’abord les questions :

– Je veux mesurer quoi ?

– Pourquoi je veux le mesurer ?

Mesurer le nombre d’enregistrements d’une Table dans une Base de donnée, ou mesurer le nombre de fois ou votre utilisateur clique sur « plein écran » ou encore comptabiliser le nombre de caractère d’un code source… C’est trop meugnon, mais il faut vraiment avoir envie de perdre son temps,  enfin je crois, je manque peut-être d’imagination, je reste donc ouverte à toute possibilité d’exploitation…

Cela dit, il faut se mettre quand même dans l’optique stratégique d’une société :

– « Quelle valeur ajoutée ? »

– « Quelle exploitation ? »

Sont donc des éléments primordiaux dans l’élaboration du calcul et de l’interprétation d’une métrique (et donc parfois de la mise en œuvre  parfois assez couteuse qui s’en suis).

Aussi, on voit trop souvent des logs applicatifs polluer des serveurs et ne pas être exploités à terme, faute d’outils, de temps, et de réelle motivation économique de le faire. Oui bon on loggue, pour la forme, c’est bien, potentiellement on peut retracer beaucoup de trucs, si il se passe un machin dans le gros bidule des incidents, m’enfin idéalement, il faut être proactif (oui toujours mon coté utopique) et anticiper au maximum les incidents dès la conception, donc finalement le log, il sert que de contrôle… si on le consulte (et puis, pour les plus velus, si on parle aussi la langue) mais je m’égare.

Les métriques doivent servir (à quelque dessein, oui !) de bases aux indicateurs des facteurs clé de la performance et du bien-être des utilisateurs (et donc aussi du développeur qui ne sera pas toujours obligé de fonctionner en mode pompier, et qui aura de quoi montrer pourquoi ses utilisateurs devraient être contents et avoir le sourire, parce que bon, 50% c’est déjà plus que 40 quoi, et que bon, l’évolution, là elle prendra N jours, donc arrêtez de lui demander pour hier)

Bref, le métrique doit rassurer, conforter, ou permettre de se remettre en question, être calculé sur les base de quelques chose de raisonnable, d’exploitable et de compréhensible et être mis à profit dans un but pécunier.

Les métriques, et les indicateurs associés c’est la vie… du Chef de Projet.

Needle in the haystack.

Quand tout est déjà écrit, quand l’aire est à l’ouverture numérique massive, vers la légalisation des échanges, et de la gratuité de la connaissance ou de la culture, que le mot directeur de notre société est l’OUVERTURE, que reste-il à écrire et à faire découvrir ?

Probablement pas grand-chose. Ou Si, peut-être, une méthode d’apprentissage. On prétend partout que ce qu’on apprend à l’école c’est apprendre à apprendre. Qu’en est-il ? Peut-on dire qu’on apprend en lisant ? En regardant la télévision ? En écoutant des gens parler ? En lisant des white papers ? En écoutant de la musique ? En prenant des photos ? En lisant des livres ? En regardant des films ?

Quand vous avez un problème, une question, vous utilisez pourtant inconsciemment toujours le même schème de comportement : moteur de recherche + mot(s) clé(s). C’est l’ancêtre du « Si tu ne connais pas, va voir dans l’encyclopédie »

Est-ce que c’est une recherche intelligente ? Est-ce que ça peut s’améliorer ? Allez ! essayons tout de même :

Je vous donne 3 petites astuces :

–          Le net n’est pas homéostatique, une information a une date, et probablement une péremption. Intéressez-vous à la date des articles que vous consultez. Certains sont très vieux, plantés sur des blogs et jamais relayés. Malgré tout ce qu’on peut dire sur la rareté et sa prétendue qualité, une information peut être jugée fiable, quand elle est répétée, remise en question, remise au goût du jour.

–          Intéressez-vous aux auteurs, à ce qu’ils ont déjà produits, à ce qu’ils continuent de produire, ce qu’ils font dans la vie : soyez critique par rapport à la réputation numérique des auteurs, consultez leur CV si vous le pouvez, tout comme la vie des auteurs d’un autre siècle permettait une meilleur compréhension de leur écrit, s’intéresser à la vie internetique des auteurs d’article pourra éventuellement vous offrir des clés de compréhension et d’imprégnation du sujet, plus pertinente.

–          Parlez la langue ! Les traductions sont plus que littérales quand elles ne sont pas réalisées à la va-vite elles sont fournies par des moteurs de traduction avec de beaux dictionnaires intérieurs, mais pas vraiment le sens de la formule. Vous pouvez perdre beaucoup de temps à essayer, à chercher dans une langue qui ne possède pas non plus de traduction. Faites des recherches multilingues, et on ne le dira jamais assez, tâchez d’être multilingue.

En conclusion : Date, Auteur, Langue => pertinence, et ça, tant que les moteurs de recherche ne les afficheront pas dans les résultats de recherche, ça restera de votre boulot !