Archives de catégorie : Management

L’innovation informatique rentabilisée

Lorsque l’on parle d’informatique, les directions générales ont trop souvent tendance à penser « coûts ». Certes, ça coûte, mais on peut regarder l’autre facette, on « INVESTIT« .

Ne confondez pas innovation informatique avec recherche !!

  • La recherche : c’est l’action de parvenir à une connaissance nouvelle
  • L’innovation : c’est l’art d’assembler d’une nouvelle façon des éléments connus

 

Il est de notoriété publique que sur 10 projets innovants, un seul va devenir rentable. De grands cabinets vous démontreront comment mesurer ce fameux ROI, ou RSI en français dans le texte, comment implémenter des KPI (BearingPoint dispose d’un très beau document sur le sujet ici). Mais faire de l’innovation pour faire de l’innovation, ce n’est pas la fonction première des entreprises. Ce sont les start-up à majorité qui sont à l’origine des innovations et qui, soit émergent, soit se font racheter.

Trop rares sont les grandes entreprises qui savent mettre en place, organiser et surtout exploiter ce qui fera d’elle « l’entreprise leader de demain ».

La méthode française de l’innovation : avoir un département innovation

Trop souvent on se plait à croire que l’innovation informatique, c’est le département de ceux dont on ne sait pas quoi faire, qui n’ont plus leur place dans la production de l’entreprise : en gros, la planque. Alors quand on veut mettre en place un département innovation, on réunit des génies dans une pièce et on leur dit « inventez-nous quelque chose pour notre métier ». Les seules contraintes sont alors, soit le budget, soit l’effectif. Peu d’obligation de résultat, peu de motivation et donc une dégradation progressive de la motivation des équipes et de résultats.

Dommage au début, ils étaient bien ces petits gars là !! Bilan, les bons qui ont faim d’avancer dans leur carrière vont partir, parce qu’ils ne veulent pas végéter, et les mauvais, ou déprimés, eux vont rester, parce que la situation est finalement pas si inconfortable : être payé pour occuper un siège sans beaucoup de contraintes !

Quand elle fonctionne cette équipe innovation, 15% du travail a été effectué. Il faut alors industrialiser la solution, et puis enfin la vendre : ce sont ces étapes qui coûtent le plus cher : convaincre le reste de l’entreprise du bien fondé du projet. C’est le point noir de ce système : personne n’aime le changement. Changer de comportement implique des changements d’habitudes et c’est là que ça se complique.

 

Filialiser les projets innovants et en faire des micro-structures

Mettre une contrainte de rentabilité sur chaque projet : C’est la méthode qu’a adopté Google depuis deux ans. 

  • Avoir une idée
  • Faire un POC (Proof of Concept) ou prototype en français
  • Constater qu’il est bien définir les attentes d’un tel projet
  • Créer une structure autonome avec les moyens et le soutien de la grande entreprise
  • En fonction du succès ou non du projet, se déployer à plus grande échelle et rayonner en faisant le buzz.

Attention, 9 projets sur 10 iront à la poubelle, ce n’est pas une raison pour se débarrasser des membres qui ont fait partie du projet ou qui l’ont mené. Quelque soit le résultat, pour peu que l’on sache impliquer les équipes dans le projet, si c’est un succès, ils seront fiers et travailleront d’autant plus pour le succès en perspective, et si c’est un échec, il faudra en analyser les causes de façon objective afin que tous puissent partager le fruit de l’expérience et ils auront progressé.

L’expérience ne se transmet pas, elle s’acquiert

Mais pour monter une telle structure, soit il faut un dirigeant d’entreprise qui veuille faire de son entreprise une entreprise à la pointe, donc l’appui de la direction générale est plus que nécessaire, soit il faut des directeurs qui sachent porter les projets, prendre des risques et parfois se mettre en danger pour faire valoir leurs convictions.

Malheureusement, toutes les entreprises n’ont pas cette capacité. Il devient alors impératif, pour le bien de l’entreprise de savoir porter l’innovation au fil des projets.

Comment donc faire de l’innovation tout en étant productif ?

Pour faire de l’innovation, hors cas exceptionnels, soit c’est un projet innovant qui est demandé, mais là, c’est la perle rare, soit aucune innovation n’est demandée, et on attend une productivité maximale. Dans les deux cas, c’est sur le manager que va retomber la responsabilité de faire les bon choix, accompagné de ses équipes.

Le projet innovant

Ça peut paraître simple. Il y a un projet dont l’idée vient du métier, il se trouve à la pointe de la technologie, il y a souvent un délai et un coût. Le triptyque du projet informatique rentre alors en ligne de compte : c’est la qualité qui en fera les frais.

Belle idée reçue et correspondant toujours aux situations rencontrées. Il existe pourtant un 4ième levier, méconnu : « Le raccourci technologique », la réutilisation de ce qui existe déjà, car ne rêvez pas, au moins une partie de ce que vous devez faire l’a déjà été.

Comme dans la vie, il n’y a jamais un seul moyen d’atteindre une destination. Il y a le chemin le plus court, le plus rapide et de nombreux compromis entre les deux. Dans cette multitude de chemins, ou de choix à faire, il existe des briques, toutes faites, qui font déjà une partie du travail.

 

Pourquoi refabriquer la roue, quand il suffit d’aller en acheter une ?

Charge alors au manager de savoir orienter le projet, sur des méthodologies qui permettront la réutilisation d’éléments existants. On peut les nommer bibliothèques ou libraries, framework si elles sont devenues état de l’art, ou encore codes sources s’il est possible de les réutiliser et ont déjà été développées par ailleurs. Tout l’art de la direction de projet est alors de déterminer ce qui sera le plus rentable, et de faire les bons choix pour y arriver.

C’est de la factorisation. Lorsqu’elle se répète sur de l’interne, elle porte un nom beaucoup plus connu : l’urbanisation, ou l’art de factoriser l’informatique de l’entreprise de façon modulaire. Réutiliser ce qui existe déjà et ne pas le recréer. Idée toute bête, qui existe depuis la nuit des temps, à qui l’on vient de donner un nom en informatique qui est à la mode.

Mais que faire si aucune idée innovante rentre en projet ?

La production, la rentabilité et son innovation

Tout le monde sait qu’une équipe ne peut pas être efficace à 100% de son temps. On parle en général d’un taux de 85% d’efficacité en production informatique. Bien entendu, tout dépend de la vélocité de chacun d’entre eux, mais globalement, c’est sur ce chiffre sur lequel on peut se baser.

Bien manager son équipe, c’est la faire progresser : toujours, tout le temps. Plus vite, plus performant, plus rentable, plus pointu. Un bon service informatique, c’est anticiper les besoins du client, ne pas simplement se baser sur ses attentes, mais intégrer ce qu’il en attend aujourd’hui et ce qu’il en attendra demain. Il faut donc prévoir, anticiper l’architecture pour permettre demain, de mener la phase 2 du projet à moindre coût et y insérer de l’innovation, des idées, des propositions.

Offrez un chocolat à quelqu’un, il en mangera.

C’est la même chose pour l’informatique, sachez proposer dans les produits et projets des choses nouvelles, au fil des projets, des fonctionnalités. Mettez du défis partout, prévoyez l’avenir, urbanisez et faites des économies d’échelle !

Si vous consacrez entre 10% et 20% de la bande passante d’une équipe à trouver de nouvelles visions de nouvelles façon de voir les choses, de les aborder, de nouveaux outils, du rattrapage de dette technique (oups …), à proposer des POC en rapport avec le produit ou le projet, à faire des points sur des problématiques envisagées ou des sujets à perfectionner, ce grand mot qui ne veut rien dire, « innovation », prendra tout son sens et l’équipe n’en sera que plus productive.

Ce principe est valable pour toutes les méthodologies projets : Scrum, XP, Clycle en V et est applicable à tous les langages : de l’assembleur en passant par du C# ou du PHP et peut prendre toute sorte de forme.

Innover c’est laisser l’esprit libre de trouver des solutions, des assemblages pour répondre à une problématique donnée. Nous ne sommes plus dans un monde où seul un penseur est détenteur de la vérité. Il faut savoir tirer le meilleur de chacun, c’est le monde de l’uberisation. Chacun à son niveau peut être contributeur d’un projet, et comme de par hasard, il interviendra toujours sur ce qui le motive, il sera donc plus impliqué que jamais et saura apporter sa propre contribution à l’entreprise.

Créez les conditions de liberté de penser pour qu’émerge l’innovation, et l’entreprise s’en retrouvera gagnante.

N’est-ce pas ce qui nous manque à tous, innover, se faire plaisir au travail, augmenter la productivité et aider nos entreprises à devenir les leaders de leur marché ?

LA MÉTHODE AGILE – OPTIMISATION DE LA RELATION « CLIENT / FOURNISSEUR »

Placer le client au centre des démarches et des personnes. C’est l’objectif des méthodes de développement dites « Agiles ». De quoi s’agit-il ? Et surtout quels en sont les avantages et y a-t-il des inconvénients ou des risques d’échecs ?

La méthode Agile est aujourd’hui très répandue dans les sociétés de services ou les agences web. J’ai souvent entendu qu’un des avantages de cette méthode était qu’on pouvait prendre ce qu’on voulait dedans, mais contrairement aux idées reçues, cette méthode ne portera ses fruits que si elle est respectée à la lettre. En effet, chaque étape est importante. Nous verrons ainsi les nombreux avantages ainsi que les inconvénients ou risques éventuels à utiliser cette méthode.
Principes de fonctionnement des méthodes « Agile »
Le principe de base des méthodes « Agile » est qu’il est contre-productif qu’avant de développer un produit, il faille le planifier et en spécifier les moindres détails. En effet, prévoir tous les aspects de la production entraîne dans la plupart des cas frustrations et pertes de temps car les aléas surviennent fréquemment. C’est cette approche prédictive et séquentielle de type waterfall ou cycle en V que les tenants des méthodes « Agile » veulent casser. Ainsi, au lieu de fixer les objectifs lointains, le mieux serait de procéder par étapes c’est-à-dire fixer des objectifs à court terme et commencer le développement sans perdre de temps. Chaque fois que cet objectif est atteint, on passe au prochain et ainsi de suite jusqu’à atteindre le but ultime. Au niveau d’un développement de logiciel, c’est le client qui transmet à l’équipe de développeurs sa vision du produit avec la liste des fonctionnalités qu’aurait ce produit. Il communique ainsi directement avec l’équipe et ensemble ils estiment le coût de chaque fonctionnalité pour aboutir à une idée approximative du budget final. De ce fait, on raisonne plus « produit » que « projet », d’où l’utilisation du terme « gestion de produit » au lieu de « gestion de projet ».
L’Agile manifesto 
Ces méthodes « Agile » se sont beaucoup développées et on a pu en recenser une dizaine de variantes jusqu’au début des années 2000. Conscientes qu’une certaine uniformisation était devenue nécessaire, 17 grandes figures du développement logiciel s’étaient réunies aux Etats-Unis en 2001 pour déterminer les critères communs et les principes fondamentaux de ce qui allait devenir un « Manifeste Agile ». D’après ce manifesto, les méthodes « Agile » demandent une plus grande implication du client et permettent une meilleure réactivité des développeurs face à ses demandes. Ce manifeste prône 4 valeurs fondamentales inhérentes aux méthodes « Agile » : l’équipe, l’application, la collaboration et l’acceptation du changement. De ces valeurs découlent 12 principes généraux qui se basent essentiellement sur une relation privilégiée entre le client et les développeurs. La priorité est ainsi donnée à la satisfaction du client et pour y arriver, une implication totale de l’équipe est requise. Cette équipe doit être capable de réagir très vite face aux éventuels changements requis par le client ou aux modifications de la méthode de travail face à des obstacles imprévus. Elle doit également être capable de se remettre en cause et de rechercher perpétuellement à évoluer.
La conception d’un produit « Agile »
La première étape consiste à effectuer une première planification de l’itération ou Sprint dans le jargon des développeurs. Cette réunion fera ressortir les éléments prioritaires de la liste des exigences fonctionnelles du produit. Chaque exigence représente une user storie (US) ou « histoire utilisateur ». Une US doit être rédigée dans un bon français et décrit e fonctionnement ainsi que le parcours de l’utilisateur de la fonctionnalité. Elle doit également contenir les cas de tests ainsi que les critères de validation de la fonctionnalité développée.
En accord avec le client, aussi appelé Product Owner, les premières livraisons devraient être effectuées à la fin de cette itération (une itération à une durée d’environ 2 à 3 semaines suivant le nombre d’US présentent dans le backlog). Le backlog est l’ensemble des US à développer durant l’itération en cours.
Une autre réunion appelée Revue de Sprint est organisée à la fin de chaque Sprint durant laquelle les développeurs présentent au client les fonctionnalités développées. Ce dernier pourra ainsi tout de suite donner son feedback, ce qui présente l’avantage de gagner beaucoup de temps et d’ajuster les fonctionnalités ou les méthodes de travail le cas échéant.
Vient ensuite une rétrospective de Sprint qui permet à tous les acteurs d’améliorer des choses et de s’améliorer également. Une autre particularité de la méthode « Agile » est la réalisation de mêlées quotidiennes qui permettent à l’équipe de développeurs de synchroniser leur travail. Appelée aussi Stand Up meeting, cette réunion qui ne dure pas plus de 15 minutes permet à chacun de déterminer ce qu’ils ont réalisé depuis la dernière mêlée, de ce qu’ils auront à terminer avant la prochaine Stand Up meeting et d’identifier les obstacles qui pourraient les bloquer. En effet, les trois questions « phares » du scrum master sont :
  1. Qu’as tu fais hier ?
  2. Que vas tu faire aujourd’hui ?
  3. As tu des points bloquants ?
Quelques  outils d’aide à la gestion d’une équipe « Agile »
De nombreux outils d’aide à la gestion d’une équipe « Agile » ont fait leur apparition ces dernières années. On peut en citer pêle-mêle Agilefant, IceScrum, Agilo, eXPlainPMT ou encore XPlanner. D’autres sont apparus dernièrement comme le JIRA Agile qui a l’avantage d’être facilement utilisable même pour les débutants. Il permet d’élaborer des tableaux de tâches, de créer et d’estimer les user stories (US), d’identifier l’engagement et la vélocité de l’équipe ou encore de créer divers rapports sur l’état d’avancement des projets. En outre, un outil comme PMTool offre un large choix de rapports dans une interface simple mais très complète. Ainsi, les développeurs tout comme les chefs de projet (Scrum master) dispose d’une interface simple pour saisir leur feuille de temps et rendre compte de leurs activités. Un tableau de bord personnalisable est également disponible pour permettre à l’utilisateur d’avoir sous ses yeux les principaux indicateurs pour le suivi de son projet/développement tout en prenant en compte l’itération en cours. Les questions/incidents pourront enfin être gérés de manière très aisé car cette action est centralisée et se fait en un seul clic grâce à un menu très discret qui s’affiche partout (quel que soit la rubrique en cours de consultation).
Conclusion
 
Avantages
  • Méthode fun !
  • Excellente réactivité vis-à-vis du client (product owners => PO)
  • Qualité accrue du fait de la présence des PO
  • Favorise et facilite la communication avec les autres membres de l’équipe
  • Développements hors sujet très peu probable
Inconvénients
  • Changement radical de gestion de projet/produit : fort impact sur tous les intervenants
  • Dans les grosses sociétés : collaboration/synchronisation difficile avec les autres équipes qui n’utilisent pas cette méthode. (délais différents donc réactivité plus longues)
  • Contraignante, surtout au début le temps que tout le monde s’y habitue.
  • Bonne volonté et bonne entente de tous les participants impératif.
  • Gros travail de rédaction pour les PO => création des « users stories » + cas de tests + critères de validation de l’US
  • Les développeurs doivent accepter le changement (revenir sur du code pour le modifier voir le supprimer).
  • Les développeurs doivent être autonomes (une équipe « Agile » doit être auto gérée)
  • La sociabilité doit être une qualité de tous les intervenants (communication)