La plupart des méthodologies agiles prévoient l’application d’un Technical Spike pour explorer une nouvelle technologie ou les zones à risque d’un produit. La méthodologie SAFe (Scaled Agile Framework) définit le Spike comme un type d’histoire d’exploration et de catalyseur.
Il existe un certain nombre d’approches qui ont été recommandées pour les Technical Spike.
Il s’agit notamment de :
Estimation et dimensionnement d’une histoire de Technical Spike
Limiter dans le temps (Timeboxing) un Technical Spike.
Le Technical Spike est de nature exploratoire et il est contradictoire d’essayer d’estimer la complexité d’un travail qui n’est pas bien compris. D’après mon expérience, la plupart des équipes préféreraient limiter dans le temps les efforts nécessaires pour réaliser un Technical Spike.
Il y a quelques semaines, j’ai eu une conversation avec un développeur qui était à mi-chemin d’un spike et j’ai eu un moment « ah-ha », et cet article est une tentative d’expliquer ce qui pourrait être une approche alternative aux Technical Spikes.
Je suggérerais au Product Owner / Business Analyst en collaboration avec unmembre technique de l’équipe, par exemple un architecte, un responsable technique, de définir les exigences de haut niveau à l’aide de la méthodologie de développement axée sur le comportement.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Les avantages de la spécification des exigences axée sur le comportement dès le départ sont les suivants.
L’objectif du Technical Spike est clairement défini à l’avance et, en tant que tel, le développeur est clair sur ce qu’est le livrable.
La définition de DONE pour le Technical Spike est dès que toutes les exigences spécifiées sont satisfaites.
Le développeur ou un testeur peut automatiser le script de développement axé sur le comportement en exigences exécutables.
Le risque de consacrer trop de temps/d’efforts au Technical Spike est minimisé.
Une ligne de base d’exigences pour la mise en œuvre réelle évolue à partir du Technical Spike.
Comme pour tout le reste, il n’y a pas de solution miracle, mais il faut veiller à ne pas aller trop loin avec les exigences. Étant donné qu’il s’agit d’un Technical Spike, il est nécessaire de s’assurer que l’exigence est à un niveau très élevésuffisant pour décrire les objectifs du Technical Spike et qu’elle ne soit pas prescriptive.
Cela semble bien fonctionner pour ce projet, alors n’hésitez pas à l’essayer.
Sam Adesoga, Principal Coach and Lead Trainer
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
L’expérience professionnelle de Sam comprend Développeur, Développeur de logiciels, Test and Release Manager, Scrum Master et récemment coach Agile d’entreprise
Sam utilise des approches agiles comme fondation, et s’intéresse à aider les individus, les équipes et l’ensemble des organisations à développer l’état d’esprit et la culture nécessaires pour réussir dans un monde VUCA.
Nombre total d’années d’expérience dans le développement et la livraison de produits à l’aide de cadres de travail agiles – 17 ans.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les projets CRM sont complexes et nécessitent un Product Owner dédié et compétent pour assurer leur succès. Un Product Owner est chargé de combler le fossé entre les besoins de l’entreprise et les équipes de développement, tout en optimisant le système pour réussir.
Laissez-moi vous parler des avantages à avoir un Product Owner sur un projet CRM.
Comprendre les besoins et les exigences de l’entreprise
Le Product Owner travaille en étroite collaboration avec les utilisateurs et les parties prenantes pour comprendre leurs besoins et leurs exigences. En cartographiant les processus métier et les parcours des utilisateurs, le Product Owner comprend mieux comment le CRM peut être adapté pour répondre aux besoins spécifiques de l’entreprise. Cela permet de s’assurer que le système est conçu et construit de manière à s’aligner sur les processus métier et les besoins des utilisateurs, tout en offrant une réelle valeur ajoutée.
Guider le processus de développement
Une fois les processus métier définis, le product owner collabore avec l’équipe de développement pour concevoir et mettre en œuvre la solution CRM. Cela implique de définir les histoires et les exigences des utilisateurs, de hiérarchiser les fonctionnalités en fonction de la valeur business et de travailler en étroite collaboration avec l’équipe de développement pour s’assurer que le système est conçu et construit d’une manière qui s’aligne sur les processus métier et les besoins des utilisateurs. Tout au long du processus de développement, le Product Owner fournit des conseils et des commentaires pour s’assurer que le système répond aux exigences qui ont été définies avec les utilisateurs et les parties prenantes.
Trouver l’équilibre entre les besoins de l’entreprise et la convivialité
Trouver le bon équilibre entre les besoins des uns et des autres.
L’un des rôles les plus importants du Product Owner est d’équilibrer les besoins de l’entreprise avec les besoins des utilisateurs. Bien que le Product Owner soit chargé de s’assurer que le système répond aux besoins de l’entreprise et apporte une réelle valeur ajoutée, il donne également la priorité à la facilité d’utilisation pour s’assurer que le système est intuitif et facile à utiliser pour les utilisateurs.
Cet équilibre entre les besoins de l’entreprise et la facilité d’utilisation peut parfois être un défi.
Par exemple, une entreprise peut exiger que certaines données soient saisies dans un certain format à des fins de reporting, tandis que les utilisateurs peuvent trouver ce format fastidieux et long à utiliser. Le product owner doit travailler à la fois avec l’entreprise et les utilisateurs pour trouver une solution qui réponde aux besoins de chacun. Il peut s’agir de trouver un compromis satisfaisant pour les deux parties, ou de trouver une solution de contournement qui répond aux exigences de l’entreprise tout en facilitant la saisie des données par les utilisateurs.
Communiquer avec les parties prenantes
En plus de travailler avec l’équipe de développement, le Product Owner communique régulièrement avec les parties prenantes de l’entreprise. Il s’agit notamment de fournir des mises à jour sur l’état d’avancement du projet, de solliciter des commentaires sur les conceptions et les fonctionnalités, et de s’assurer que le système répond aux besoins de toutes les parties prenantes. Cela permet de s’assurer que toutes les personnes impliquées dans le projet sont tenues au courant et ont leur mot à dire dans le processus de développement.
Assurer le succès du lancement et de l’adoption
Enfin, le Product Owner est responsable de s’assurer que le CRM est lancé et adopté avec succès par l’entreprise. Il s’agit de contribuer à des activités de formation et de soutien aux utilisateurs afin de s’assurer qu’ils sont à l’aise avec le nouveau système et qu’ils sont en mesure de tirer pleinement parti de ses capacités. En optimisant le système pour qu’il réussisse et en comblant le fossé entre les besoins de l’entreprise et le développement, le propriétaire du produit peut assurer le succès du projet CRM.
En conclusion, avoir un Product Owner sur un projet CRM offre de nombreux avantages.
Le Product Owner apporte la plus grande valeur possible, aussi rapidement que possible.
Un Product Owner s’assure que le système répond aux besoins de l’entreprise et apporte une réelle valeur, fournit des conseils et des commentaires tout au long du processus de développement, équilibre les besoins de l’entreprise avec les besoins des utilisateurs, communique régulièrement avec les parties prenantes et veille à ce que le système soit lancé et adopté avec succès par l’entreprise.
Si vous vous lancez dans un projet CRM, il est essentiel d’investir dans un Product Owner solide et expérimenté pour en assurer le succès.
Mohamed Michael Kazak
Mohamed Michael Kazak
Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.
« Préparez le succès de votre projet numérique » par Michaël Tartar
Michaël Tartar
En tant que chef de projet informatique, vous disposez d’un arsenal de méthodologies et d’outils.
Votre objectif est de livrer un composant logiciel répondant aux attentes de votre client (interne comme externe) avec
un coût maîtrisé,
un délai convenu et
des ressources définies
et de qualité !
En vous concentrant sur ces 3 aspects, vous avez le sentiment de bien faire votre travail.
Vous avez raison… …partiellement, car votre projet est en réalité le préambule d’une nouvelle étape : L’expérience utilisateur de ce que vous avez créé.
Avant de vous lancer, posez-vous les questions qui surgiront lorsque les utilisateurs s’empareront enfin des livrables du projet logiciel.
Vont-ils adopter ce nouvel outil et les changements de processus qu’il introduit ?
Les modifications qu’ils ne manqueront pas de demander seront-ils réalisés aussi rapidement que nécessaire ?
Les données collectées et créées seront-elles faciles à contrôler pour respecter l’évolution du cadre réglementaire ?
L’infrastructure technologique retenue sera-t-elle facile à adapter pour répondre aux enjeux de performance et de sécurité ?
Pour optimiser le succès de votre projet numérique, toutes ces questions et bien d’autres doivent être anticipées.
De nombreux aspects ne dépendent pas strictement de l’informatique.
Au sein de l’entreprise, plusieurs acteurs en dehors de la direction des systèmes d’information (DSI)et des directions métiers sont impliquées : Marketing, communication, ressources humaines, finance, juridique, stratégie, etc.
Il vous faut comprendre les enjeux de chacun et leur rôle dans la vie opérationnelle du nouvel outil.
Une analyse de la maturité digitale à 360 degrés vous aidera.
Qu’est-ce que la maturité digitale d’une entreprise à l’instant « T » ?
Le livre
La maturité digitale de votre entreprise permet d’apprécier sa capacité, à un instant « T », d’opérer dans le monde numérique dans lequel nous vivons toutes et tous.
Elle se traduit par une note de 1 à 5, facile à appréhender par toutes les parties prenantes et par votre management.
Chaque indicateur est construit de la même manière, en 5 niveaux d’exigence.
Meilleure est la pratique courante dans votre entreprise sur cet indicateur, meilleure est la note.
Les 6 leviers de digitalisation selon Michaël Tartar
Quelle que soit la taille de votre entreprise.
Toutes les tailles d’entreprises sont considérées.
Alors que la totalité des indicateurs est applicable aux grandes entreprises, pour répondre aux contraintes propres aux petites entreprises (TPE/PME) ou aux administrations, le livre précise les indicateurs applicables à chaque type de structure.
Des spécificités sectorielles sont également prises en compte pour coller aux particularités propres à votre industrie ou secteur d’activités, et surtout aux différences de niveaux de maturité digitale de ceux-ci.
Pour réussir votre projet numérique, vérifiez que votre entreprise est bien prête !
En amont d’un projet informatique, il vous faudrait toujours vérifier la maturité digitale de votre entreprise à utiliser le nouveau logiciel.
Cette revue permet d’identifier les faiblesses que le nouvel outil rencontrera dans sa vie réelle, une fois livré.
Ainsi, en tant que manager de projet, vous pouvez conseiller en amont votre sponsor et comité de projet en les invitant à régler certains points qui doivent l’être pour garantir le succès de leurs investissements dans ce développement logiciel.
Comprenez chaque indicateur présenté dans le livre, évaluez ceux qui s’appliquent ou pas à votre entreprise et utilisez la méthode de calcul pour obtenir une note entre 1 et 5.Puis présentez et discutez ce résultats avec vos parties prenantes les plus importantes.
Visitez le site pour davantage de détails.
Michaël Tartar a développé une plateforme dimmup.com, à la fois pour aller plus vite dans la phase initiale puis pour mettre en place un cadre vertueux de pilotage de la transformation digitale, par la mesure régulière et répétée des indicateurs.
Cela vous permet de prendre en compte les évolutions du numérique dans votre société et environnement (nouveaux standards, nouveaux usages, nouvelles réglementations, etc.).
En faisant cet exercice d’évaluation de la maturité digitale de votre entreprise, vous percevez beaucoup plus vite les facteurs de succès de votre projet informatique, au-delà des approches classiques de management de développement logiciel en mode Agile/évolutif comme Cascade/prédictif.
De plus vous pouvez identifier ainsi d’autres besoins de développement pour répondre aux attentes des utilisateurs métier.
C’est la raison la raison d’être de DIMM.UP et de la plateforme dimmup.com.
partagez ce billet avec vos amis, collègues et relations professionnelles
Votre entreprise est-elle prête pour ce nouveau projet que l’on vous charge de mener à bon port ?
Préparez le succès de votre projet numérique.
En tant que chef de projet informatique, vous disposez d’un arsenal de méthodologies et d’outils. Votre objectif est de livrer un composant logiciel répondant aux attentes de votre client (interne comme externe), dans un coût maîtrisé, de la meilleure qualité possible, dans un délai convenu avec les ressources dont vous disposez. En vous concentrant sur ces aspects, vous avez le sentiment de bien faire votre travail. Vous avez raison… partiellement. Car votre projet est en réalité le préambule d’une nouvelle étape : la vie de ce que vous avez créé.
C’est alors que les utilisateurs se saisissent (ou pas) de votre travail.
Vont-ils adopter ce nouvel outil ?
Les changements qu’ils ne manqueront pas de demander seront-ils réalisés aussi rapidement que nécessaire ?
Les données collectées et créées seront-elles faciles à contrôler pour respecter l’évolution du cadre réglementaire ?
L’infrastructure technologique retenue sera-t-elle facile à adapter pour répondre aux enjeux de performance et de sécurité ?
Pour optimiser le succès de votre projet numérique, toutes ces questions et bien d’autres doivent être anticipées. Vous vous apercevez alors que de nombreux aspects ne dépendent pas strictement de l’informatique. Au sein de l’entreprise, plusieurs acteurs en dehors de la DSI et des directions métiers sont impliquées : Marketing, communication, RH, finance, juridique, stratégie, etc. Il vous faut comprendre les enjeux de chacun et leur maîtrise de leur rôle dans la vie opérationnelle du nouvel outil. Une analyse de la maturité digitale à 360 degrés vous aidera.
Qu’est-ce que la maturité digitale d’une entreprise ?
Le livre
La maturité digitale d’une entreprise permet d’apprécier sa capacité, à un instant « t », d’opérer dans le monde numérique dans lequel nous vivons désormais.
Elle se traduit par une note sur 5, facile à appréhender par le management.
Chaque indicateur est construit de la même manière, en 5 niveaux d’exigence. Meilleure est la pratique courante dans l’entreprise sur cet indicateur, meilleure est la note.
Pour répondre aux contraintes propres aux petites entreprises (TPE/PME) ou aux administrations, le livre précise les indicateurs applicables à ce type de structure. La totalité des indicateurs est applicable aux grandes entreprises. Les spécificités sectorielles sont également prises en compte pour coller aux particularités propres à chaque secteur, et surtout à leurs différences de niveaux de maturité digitale.
Le livre complète la description du modèle par une explication détaillée des concepts qui le sous-tendent et par de nombreuses illustrations par des praticiens du digital, dans tous les corps de métier concernés.
Vérifiez que votre entreprise est prête pour votre projet
En amont d’un projet informatique, il est ainsi vivement conseillé de vérifier la maturité digitale de l’entreprise qui sera amenée à utiliser le nouveau logiciel. Cette vérification permet d’identifier les faiblesses que le nouvel outil rencontrera dans sa vie courante. Ainsi le chef de projet peut conseiller son donneur d’ordre en l’invitant à régler certains points qui doivent l’être pour garantir le succès de son investissement.
Vous pouvez suivre chaque indicateur présenté dans le livre, évaluer ceux qui s’appliquent à votre entreprise et appliquer la méthode de calcul qui vous donnera une note sur 5. Pour aller plus vite, vous pouvez utiliser la plateforme dimmup.com. Au-delà de cette première mesure de maturité digitale, la plateforme crée aussi un cadre vertueux de pilotage de la transformation digitale, par la mesure régulière des indicateurs, et la prise en compte des évolutions du numérique dans nos sociétés (nouveaux standards, nouveaux usages, nouvelles réglementations, etc.).
Ainsi, en faisant cet exercice d’évaluation de la maturité digitale de votre entreprise, vous percevez beaucoup plus vite les facteurs de succès de votre projet informatique, au-delà des approches classiques de gestion de développement logiciel. De plus vous pouvez identifier ainsi d’autres besoins de développement pour répondre aux attentes des utilisateurs métier.
Enfin vous créez les conditions du succès à long terme de vos travaux, en dépassant les aspects techniques.
Qui est Michaël Tartar ?
Michaël Tartar
Fondateur & CEO de DIMM.UP, Michaël accompagne la transformation digitale des entreprises depuis bientôt trois décennies. Issu de l’ingénierie logicielle, son parcours professionnel l’a amené à réaliser de nombreux projets numériques, dans des entreprises privées comme publiques, de petites tailles comme internationales. Il a normalisé son approche à 360 degrés de la transformation digitale en créant un modèle de maturité digitale. Publié pour la première fois en 2014, mis à jour en 2019, la version 2022 (La transformation digitale pour tous !, co-écrit avec David Fayon) est best-seller chez l’éditeur, Pearson. Au-delà du modèle, le marché attendait aussi des méthodologies et des outils pour le mettre en œuvre.
C’est la raison la raison d’être de DIMM.UP et de la plateforme dimmup.com.
partagez ce billet avec vos amis, collègues et relations professionnelles
Comparer un chef de projet à un « chef d’orchestre » est plutôt valorisant, sympathique, et assez parlant.
Sauf que la métaphore étant posée, elle ne dit rien de très précis sur les qualités et le rôle d’un chef de projet ou d’orchestre, ou tout du moins ce que j’ai pu en lire est généralement une projection de certaines compétences clés du chef de projet sur le chef d’orchestre, plus que l’inverse.
S’il est plaisant de pratiquer une analogie entre ces deux postes en termes de direction-coordination, peu d’entre nous savent diriger un orchestre ou comprennent comment et sur la base de quelles qualités opère cette fonction.
En réalité, l’interprétation d’une œuvre symphonique préexistante par des musiciens virtuoses, selon une écriture suivie à la lettre et connue sur le bout des doigts est très éloignée des projets que nous avons en charge.
La comparaison reste intéressante mais je crois qu’on oublie l’essentiel :
Ce qui fait un bon chef d’orchestre, ce n’est ni la baguette, ni la partition, ni même la qualité des musiciens, c’est son acuité.
Cette sensibilité élevée qui permet d’appréhender le subtil et de conduire de manière fine en harmonie avec des « parties-prenantes » sur une « recette » définie, une partition préexistante.
Louis de Funès ne joue pas le chef d’orchestre dans « la Grande Vadrouille ». Il est ancien musicien professionnel et a, en 1966, plus de quarante années d’expérience en tant que pianiste.
Il me semble que notre époque techno-centrée se concentre beaucoup (trop?) sur les méthodes (Agile, Prince, Prédictive, Cascade…) et les outils informatiques associés (MS Project, Jira…) au point d’oublier la substance basale de la gestion de projet : l’acuité.
Aussi, le bon chef de projet n’est-il pas le plus virtuose en technique ni le plus doué sur Excel, mais celui ou celle dont l’acuité permet d’observer, analyser, comprendre et coordonner. De manière aigüe.
L’observation est le préliminaire de toute science.
L’accélération de la transformation digitale nous permettrait-elle d’abandonner notre acuité ?
Au même titre qu’aucun tournevis ne sait visser, aucun logiciel de projet ne sait coordonner. De même qu’aucune méthodologie projet ne fonctionne par elle-même.
Plus les projets deviennent complexes, plus il devient réflexe de nous fier à des outils (prototypage, coordination, décisionnel, reporting…) moins nous sommes centrés sur la vue d’ensemble et moins nous gardons l’œil sur l’objectif, la cible.
Et il ne s’agit pas simplement de regarder pour voir mais de regarder pour comprendre, écouter pour comprendre. Les outils et méthodes arrivent ensuite par leur support.
L’observation est essentielle et devient particulièrement puissante quand elle prend en compte simultanément la « big picture » ainsi que les détails les plus fins.
Serions-nous arrivés dans une ère de perte de l’acuité à mesure que des outils ne serviraient plus à aider ou confirmer celle-ci mais s’y substitueraient ?
Pourrions-nous désormais nous le permettre ?
La comparaison au chef d’orchestre tiendrait-elle toujours ?
Y a-t-il un pilote dans le projet ?
Prenons peut-être l’exemple d’un pilote d’avion : son acuité est primordiale, aussi bien dans un petit Cessna monomoteur d’école que dans le dernier Rafale bourré d’informatique.
La gestion de projet risque-t-elle moins le crash qu’un pilote d’avion myope sans lunettes qui ne se fierait qu’à ses instruments flous ?
Alors, oui, nous croisons parfois ces vidéos d’un passager capable de faire atterrir un Boeing sans aucune connaissance de pilotage. Mais que ce soit en simulateur ou dans le réel, ce dernier est totalement guidé par quelqu’un qui connaît les outils et procédures à la lettre, mais surtout, l’acuité du passager est maximale afin de bien entendre les indications radio et d’actionner le bon levier au bon moment.
Cet exemple se transposerait plus difficilement s’il s’agissait de remplacer un chef d’orchestre de la même manière, l’interprétation tomberait probablement à plat.
Je lis beaucoup de sujets sur la gestion du risque en tant que chef de projet.
A-t-on déjà quantifié l’absence ou les lacunes d’observation et donc de compréhension de ce qui est simplement visible ?
Quel est celui qui regarde tout ce qui est monitoré et comment le comprend-il ?
Re-focaliser les équipes sur la cible plutôt que sur la flèche !
Issu de l’industrie du Broadcast et chef de projet depuis les années 90, j’ai vu les process et les équipes se remodeler au fil des innovations technologiques permanentes. Nous ne parlions pas « d’adaptation au changement », nous le faisions. J’ai fréquemment été témoin de la fascination pour les nouveaux outils au détriment du résultat final. Il m’a régulièrement fallu re-focaliser les équipes sur la cible plutôt que sur la flèche. Qu’elles ne demeurent pas aveuglées ni centrées sur les innovations.
La chance d’un secteur dont le livrable est audio et visuel est qu’on ne peut pas se permettre de totalement « oublier » d’observer. Il demeure pourtant des accidents industriels au cinéma, à la télévision et dans les créations de commande :
Quelqu’un n’a pas vu le désastre arriver malgré des tableaux Excel impeccables, de la technologie de pointe et de la méthode.
Mettre la charrue avant les bœufs n’est jamais un projet viable.
« Cart before horse » en anglais.
Lorsque que j’ai, un peu par hasard, intégré un secteur industriel très différent du mien au sein d’une multinationale spécialisée dans le déploiement de technologies ferroviaires j’ai été très surpris.
En dépit des exigences manifestes en termes de coûts, délais, logistique, client ou équipes projetées un peu partout géographiquement il n’y avait en apparence aucune coordination.
N’occupant pas moi-même de poste de pilotage sur ce contrat, ma vue parcellaire des activités aurait pu me tromper dans mon appréciation à priori de la situation, cependant, les différentes visios de cadrage et de suivi que j’entendais et qui se déroulaient dans le bureau jouxtant le mien me confirmèrent très vite l’absence d’organisation et sans doute de méthode. Pendant que certains intervenants brassaient de l’air, d’autres, chefs de projets, énuméraient les postes de leur tableau MS Project comme s’ils tentaient de compléter les lignes du jeu Tetris.
Le centre d’attention de ces réunions était un logiciel à remplir, pas une activité complexe à coordonner. Ou alors considéraient-ils que remplir une ligne d’un logiciel revenait à coordonner ?
En deux ans, ces chefs de projet ne sont jamais venus voir le réel de l’activité qu’ils avaient en charge de conduire. Nous avons par contre du faire face à des charrues placées avant les bœufs, de la logistique qui ne suivait pas, des équipes perdues qui couraient comme des poulets sans têtes, des points d’arrêt imposés par le client mécontent, probablement des millions d’euros de marge partis en fumée…
Des millions d’euros de marge partis en fumée…
De mon côté, bien que ne possédant qu’un aperçu très fragmentaire de l’ensemble, je me hâtais de créer mon propre tableau de suivi afin de pouvoir potentiellement endiguer et prendre en charge des problèmes divers qui ne manqueraient d’arriver jusqu’à notre équipe. Ce tableau, actualisé à la volée, simple et visuel, nous sauva plus d’une fois.
Pour revenir à l’allégorie du chef d’orchestre sur cette anecdote, nous avons interprété une véritable cacophonie, avec professionnalisme et sérieux – selon la gouvernance opérée.
Les crashs étaient courants.
Depuis toujours, le boulanger regarde son pain, il écoute le craquement de la croûte et sent son odeur pour considérer qu’il est bon. Avant même de le goûter.
Transformer son pain en « baguette connectée 4.0 » reviendrait-il à mettre en sourdine ses sens au profit d’un outil informatique de pilotage ou de prise de décision ? Serait-il toujours Boulanger ? Mais surtout, la baguette serait-elle bonne ?
On pourra me trouver caricatural.
Pour moi la caricature, ce sont les formulaires en ligne pleins de bugs ou les applis dysfonctionnelles avec des UX/UI incongrues : tout a pourtant été testé et le code doit sûrement être magnifique, mais personne n’a VU que ça ne fonctionne pas…
Un chef de projet doit observer pour comprendre, pas pour répondre.
Ne déléguons pas notre réflexion aux machines et méthodes.
Cyril Verbrugghe vous propose une approche, la Project Omniscience, pour adapter le management de projet et les défis de planification au monde en perpétuel mouvement dans lequel vous réalisez vos projets.
Près de 65% de vos projets dans l’industrie ne sont pas considérés comme des réussites, du point de vue du respect des délais et de la maîtrise des coûts. Les causes sont nombreuses, et dépendent fortement du contexte du projet, mais l’approche de la gestion et de la planification en sont les principales.
Dans cet article, je vous propose de penser une approche à même d’adapter la gestion de projet et la planification aux enjeux de l’industrie dans son ensemble : la Project Omniscience.
D’ici 2027, la gestion de projets emploiera 88 millions de personnes dans le monde, et la valeur économique des activités orientées projet aura atteint la barre des 20 000 milliards de dollars. En parallèle, les projets industriels actuels, qui travaillent à résoudre des problématiques liées aux enjeux majeurs rencontrés par l’humanité (l’agro-alimentaire, la mobilité, l’énergie, le spatial, …) sont de plus en plus complexes, nécessitant une approche systémique du processus de décision pour assurer leur réussite.
Cette approche est loin d’être généralisée : seuls 35% des projets lancés dans le monde sont couronnés de succès (entendre dans le respect des délais, de la rentabilité, de la qualité des livrables). Ce qui est loin d’être à la hauteur des enjeux : ces échecs entraînent une perte considérable d’argent, d’opportunités et de temps. Or, nous manquons justement de temps…
L’approche systémique du projet : les défis pour une planification consolidée
L’approche systémique du processus de décision et du projet repose sur une prise en compte de l’ensemble des paramètres susceptibles d’influer sur son succès : charges, ressources humaines, matérielles, contraintes d’occupation de site, etc. La planification consolidée est donc en ce sens la pierre angulaire de l’approche systémique du projet.
Or une planification consolidée nécessite de lourds investissements en temps et en argent. La capitalisation du savoir est au mieux hypothétique, et les acteurs de la planification sont contraints pour chaque projet de s’atteler à de la saisie de données (entre autres tâches répétitives). La productivité en est rongée : 1 acteur de la planification sur 4 considère la saisir de donnée comme leur principale source de problèmes, et 54% des chefs de projets dans l’industrie déclarent consacrer un jour par semaine à des tâches fastidieuses qui nécessitent peu ou pas de créativité.
Ainsi, les efforts actuellement nécessaires pour envisager les impacts de scenarii stratégiques sont disproportionnés par rapport à des résultats limités : le coût d’une planification consolidée est trop lourd à porter.
Garantir le succès d’un projet, répondre aux aléas et opportunités (COVID, guerre en Ukraine, innovations disruptives, …) et anticiper dans leur globalité les impacts requiert donc une évolution majeure dans la capacité à capitaliser sur notre savoir et notre expérience issus de précédents projets. Il s’agit de fiabiliser les décisions et sécuriser notre avenir en rendant accessible le savoir industriel projet, pour dépasser la segmentation de la connaissance et les limites intellectuelles à la scénarisation du futur.
Un obstacle à surmonter : la planification « personne-dépendante »
Cette problématique ne reste pas sans réponse : procédures, logiciels de planification 2.0, process mapping, … Toutes ces initiatives visent à améliorer la capitalisation du savoir dans le cadre de la gestion de projet et à consolider le volet de la planification.
Toutefois, peu de technologies peuvent être considérées comme de véritables « outils » au sens littéral du terme, et l’être humain reste le principal vecteur et moteur de la donnée, avec des solutions basées sur les principes Excel.
De ce fait, la bonne sécurisation de nos projets reste « personne-dépendante ». Seuls quelques rares élus ont suffisamment d’expérience pour jongler à la fois avec la connaissance des processus métiers et la technique de planification. Deux ingrédients obligatoires pour nourrir rapidement la stratégie d’un plan clair et exhaustif.
Cette situation génère du stress pour ces experts, dont 41% ont envisagé de quitter la gestion de projet au cours de la dernière année. Elle est également dangereuse pour l’organisation industrielle, car un départ représente des années de connaissance perdues et met en péril la maîtrise des projets.
La Project Omniscience : modéliser le projet grâce à l’IA
Pourtant le monde dans lequel nous entrons nous donne les armes pour adresser cette problématique centrale d’une planification « personne-dépendante », repenser notre gestion de l’information et généraliser l’approche systémique dans la gestion de projet.
Les nouvelles technologies offrent en effet des opportunités d’aller au-delà des limites intellectuelles des êtres humains. Les systèmes intelligents, notamment grâce au deep & machine learning, peuvent stocker et traiter d’énormes quantités de données, et peuvent être utilisés pour aider les chefs de projet à prendre des décisions plus rapidement et plus efficacement.
Ces systèmes intelligents nous ouvrent la porte d’un nouveau monde, celui de la “Project Omniscience”.
Leur puissance de traitement, leur capacité d’apprentissage et les technologies de datavisualisation peuvent permettre de créer un véritable “Jumeau numérique” de votre organisation projet. Une telle modélisation permettrait de simuler instantanément et vérifier les différents scenarii stratégiques, avertir en temps réels sur les signaux faibles, …
Augmenter les leaders projet par la « Project Omniscience ».
Dans ce monde, depuis votre tablette tactile et, en un instant, vous pourrez définir le meilleur moment d’un lancement spatial. Le tout avec précision, en prenant en compte toutes les dimensions nécessaires au succès : occupation du site, capacité de chaque équipe, disponibilité des moyens, budget à disposition.
Dans ce monde, les contraintes business sont intégrées par tous les acteurs du projet ; les décisions commerciales sont optimisées selon les capacités réelles. Un paiement conditionné à un premier livrable ? Vos chefs de projets adoptent immédiatement le meilleur scénario pour livrer les jalons correspondant au plus vite.
Nos projets sont nos meilleurs investissements. Et si la Project Omniscience était moyen le plus sûr de les transformer en actifs financier stables ?
Sources :
Harvard Business Review “The Project Economy Has Arrived” – Antonio Nieto-Rodriguez
Project Management Institute “2022 Jobs Report”
Project Management Institute “AI at work new project new thinking”
Gartner “Project Management Technology Trends at the Gartner Program & Portfolio Management Summit”
Capterra “Project Management Software Market Research Report”
PMI is a registered mark of Project Management Institute, Inc.
Qui est Cyril Verbrugghe ?
Cyril Verbrugghe
Depuis 2020, Cyril Verbrugghe est Co-Fondateur et PDG d’OFFOLIO. Il travaille actuellement à libérer le potentiel de la planification projet en y apportant Intelligence Artificielle, automatisation et apprentissage.
Double diplômé de l’université Dauphine (Projets & Systèmes d’Information) et de Business School Montpellier (Finance), il a démarré sa carrière en finance de marché. Son parcours en consulting l’a mené sur des missions de déploiement de systèmes d’information, de transformation des organisations puis de stratégie au sein de grands groupes.
Il a ensuite dirigé les activités Europe Moyen Orient Afrique de la technologie Canadienne GlobalTrade Corporation durant 4 années, ou il a œuvré à la transformation digitale de l’écosystème Trade Finance.
partagez ce billet avec vos amis, collègues et relations professionnelles
Faire des recherches sur les clients est une perte de temps pour un développeur. (N’hésitez pas à remplacer « développeur » par cadre exécutif, Analyste Qualité, etc.).
L’argument se poursuit avec
Nous avons embauché nos développeurs pour écrire du code et que tout ce qui les éloigne de cette tâche est une distraction à minimiser.
Un bon code est bien plus que des bogues ou des performances
Cet état d’esprit trahit une croyance organisationnelle selon laquelle fournir du code est la même chose que fournir de la valeur aux clients. Il n’y a que deux choses que la livraison de code vous garantit d’obtenir : (1) plus de code et (2) plus de dette technique. Chaque ligne de code écrite par un développeur vivra pour toujours dans les systèmes que vous construisez. Le code nécessitera de la maintenance. Il accumulera de la dette au fil du temps. Si nous ne pouvons pas garantir que chaque ligne apportera quelque chose de valeur à nos utilisateurs et à l’entreprise, nous ne devrions pas l’écrire. À tout le moins, nous ne devrions pas la pousser en ligne.
Bien sûr, nous avons besoin que le code soit exempt de bogues, performant, sécurisé et évolutif. Un bon code devrait avoir toutes ces qualités. Mais toutes ces qualités ne valent rien si la fonctionnalité que nous avons livrée n’améliore pas l’expérience de l’utilisateur. Trop souvent, nous poussons les fonctionnalités précisément pour la croyance organisationnelle que les développeurs doivent livrer quelque chose à un moment donné. Mais avec un petit investissement de temps, nous pouvons considérablement améliorer les chances que le code de haute qualité que nous expédions ait réellement un impact significatif sur nos clients.
Les développeurs qui parlent aux clients écrivent un meilleur code
Les ingénieurs qui ont des contacts réguliers avec les clients comprennent les problèmes qu’ils résolvent pour leur public. Ils ont une idée claire de ce qui empêche les utilisateurs de réussir en ce moment. Ils peuvent même apprendre ce que nos clients font en ce moment pour atteindre cet objectif particulier. Toutes ces informations donnent un sens et un but au code écrit par ces développeurs. Cela les pousse à créer des logiciels qui vont bien au-delà du « fonctionne tel que conçu ». Les informations obtenues en écoutant les clients incitent les développeurs à affiner une expérience à un niveau supérieur à celui du code qui n’a pas bénéficié de la connaissance utilisateur.
Comprendre ce qu’un utilisateur essaie d’accomplir signifie que les fonctionnalités que vous livrez ont plus de chances de réussir. Cela se traduit directement par moins de refactorisation, moins de refonte et une utilisation et un succès accrus pour ces idées. Les développeurs impliqués dans ces fonctionnalités réduisent en fait le codage inutile en ne créant pas de fonctionnalités dont personne ne veut ou qui ne résolvent pas le problème réel de nos utilisateurs.
Davantage de connaissance des clients signifie un meilleur code, moins de gaspillage
Les principes Lean nous apprennent à éliminer les déchets du processus. Tout ce que vous faites qui ne génère pas de valeur pour le client doit être retiré du processus. Écrire du code pour des fonctionnalités dont personne ne veut est du gaspillage. Maintenir des fonctionnalités que personne n’utilise est du gaspillage. Ajouter de l’embonpoint à un produit est du gaspillage. Passer du temps à négocier des priorités sans contexte fondé sur des données probantes est du gaspillage. Tout cela peut être minimisé si vous amenez votre développeur à parler aux clients car c’est la voie de la moindre résistance.
Ce n’est pas un concept difficile à mettre en œuvre, mais il faut un changement fondamental de mentalité dans ce qu’un développeur devrait faire au travail et ce que l’organisation définit comme « valeur ».
partagez ce billet avec vos amis, collègues et relations professionnelles
Une préparation diligente, des flux de travail clairement définis et une surveillance vigilante sont essentiels pour livrer un projet DevOps hautement performant. Szymon Piasecki, responsable DevOps chez STX Next.
DevOps: 3 steps to plan and execute a successful project par Szymon Piasecki
Bien que DevOps ne soit pas une nouvelle expression ou idée pour quiconque évolue dans l’industrie high-tech, c’est devenu un mot à la mode ces dernières années. Sa popularité est telle qu’il est maintenant crucial de comprendre comment structurer et déployer au mieux une équipe DevOps, et il existe plusieurs points de vue et méthodologies différents sur ce sujet.
En termes simples, DevOps est l’intégration des développeurs et des opérateurs informatiques en un seul groupe, avec l’objectif commun d’améliorer la vitesse et la qualité du déploiement des logiciels. Il a d’abord été créé en réponse aux préoccupations concernant la ségrégation des équipes et la façon dont cela entraînait souvent des ruptures de communication et un manque de cohésion.
Depuis que le terme a été inventé pour la première fois en 1993, DevOps n’a fait que gagner en popularité. 83% des décideurs informatiques en 2021 ont déclaré avoir mis en œuvre ce style de travail sous une forme ou une autre.
Changer l’orientation business de cette manière ne garantit pas un changement immédiat de résultats. Cependant, cette dynamique représente un changement de culture informatique, avec un accent accru sur la collaboration et les compétences relationnelles interpersonnelles. Pour que ce modèle fonctionne à long terme, les ingénieurs doivent être ouverts à cette nouvelle façon de travailler.
Alors, quelles étapes vitales une équipe DevOps doit-elle prendre pour assurer la réussite d’un projet ?
1. Comprendre le pourquoi
Les étapes préliminaires d’un projet DevOps sont cruciales. Sans une direction claire et une compréhension commune au sein de l’équipe, l’initiative est vouée à l’échec.
Pourquoi ce changement ?
L’équipe et le client doivent donc être prêts à consacrer le temps nécessaire pour comprendre les objectifs de chacun et s’assurer que leurs visions s’alignent. Cela peut se faire par le biais de réunions et d’ateliers, où les participants identifient les objectifs et les membres de l’équipe établissent un objectif clair sur ce à quoi le produit final devrait ressembler.
Lorsque cette mise au point est exécutée correctement, l’équipe DevOps quittera la première phase du projet avec un briefing bien défini et une compréhension claire des objectifs du client. Si cette étape est précipitée, les ingénieurs seront gênés par un manque de direction, ce qui augmentera la probabilité que le produit fini ne réponde pas aux exigences du client.
2. Développer
La deuxième phase est celle où le développement de l’application commence. Ceci est généralement facilité par l’utilisation d’une solution basée sur le cloud, où l’équipe commence à préparer l’environnement, à travailler sur les composants qu’il doit contenir et à comprendre comment ils doivent être configurés pour maximiser l’efficacité.
Les meilleures équipes DevOps sont agiles et polyvalentes, avec des membres qui peuvent facilement s’adapter à un nouveau rôle ou aider dans divers domaines.
Pendant cette période, l’équipe doit s’assurer que la version finale de l’application est aussi sécurisée que possible. Pour cette raison, l’équipe DevOps a besoin de compétences diverses, y compris au moins un expert en cybersécurité.
Une phase de développement réussie se caractérise par des flux de travail clairement structurés dans lesquels le projet est décomposé, étape par étape. Tous les membres de l’équipe doivent comprendre où ils s’inscrivent dans le plan et comment ils peuvent contribuer.
Il est important de se rappeler que les projets DevOps sont rarement une promenade de santé du début à la fin. Le développement est souvent entravé par des délais manqués, des bugs et des conflits de priorité qui éloignent les ingénieurs de leurs responsabilités projet. Pour cette raison, les meilleures équipes sont agiles et polyvalentes, avec des membres qui peuvent facilement s’adapter à un nouveau rôle ou aider dans divers domaines. Cette agilité est extrêmement importante pour assurer la continuité lorsque les flux de travail sont perturbés.
3. Tester, surveiller et améliorer
Une fois qu’un produit est mis en ligne, le travail entre dans une nouvelle étape cruciale. Les meilleures équipes DevOps ne se reposent jamais sur leurs lauriers à la fin de la phase de développement.Les développeurs doivent surveiller attentivement l’application à ses débuts afin que tout bug puisse être identifié et immédiatement corrigé.
Des ingénieurs devraient être en place pour surveiller l’environnement, y compris la façon dont il est affecté et comment il réagit aux flux variables de nouveaux utilisateurs. Les données obtenues constituent une ressource précieuse et doivent être traitées comme telles, les équipes triant et étiquetant les résultats dès qu’ils sont collectés.
Une fois les données de référence recueillies, l’équipe doit analyser les résultats pour identifier les parties de l’application qui pourraient nécessiter des améliorations ou une refonte. Après cela, le résultat final devrait être un produit qui fonctionne de manière optimale et répond aux spécifications du client.
Se préparer au succès
Les équipes DevOps qui suivent les étapes décrites ci-dessus auront la certitude absolue que leur projet est sur la bonne voie et qu’il est prêt pour réussir.
Concevoir un produit bien fait est beaucoup plus facile lorsque votre équipe inclut des spécialistes de diverses disciplines qui sont enthousiastes à l’idée de collaborer et de communiquer. Avoir la bonne équipe facilitera également la transition entre chaque étape d’un projet DevOps et garantira que le client est satisfait.
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez du mal à expliquer DevOps et tout ce qu’il englobe aux non-techniciens ? Les gens se demandent-ils ce que font réellement les ingénieurs DevOps de votre équipe ?
Ces définitions et analogies vous aideront à leur répondre.
Le terme DevOps a été créé il y a plus de 10 ans, et ce qui a commencé comme un hashtag est devenu un mouvement culturel dans l’informatique. Cette philosophie encourage les développeurs à aller vite, à expérimenter et à itérer. DevOps est devenu intrinsèquement lié à la transformation numérique. Mais en ce qui concerne la terminologie informatique, une décennie est amplement suffisante pour accumuler des définitions, des interprétations et une grande confusion autour de ce que DevOps signifie réellement.
DevOps est-il la même chose qu’Agile ? Est-ce une méthodologie ? Est-ce juste une autre façon de dire collaboration ? Que font réellement les ingénieurs DevOps ? Avons-nous besoin de ce titre, ou n’est-ce qu’un effet de mode ?
Parce que DevOps englobe de nombreux concepts différents (livraison continue, intégration continue, automatisation, etc.), il peut être difficile, en particulier pour ceux qui sont les plus passionnés par ce sujet, d’essayer de réduire DevOps à une courte phrase. Mais, rappelons-nous, les petites phrases peuvent être utiles, que vous essayiez de vendre l’idée dans la chaîne de management ou d’expliquer ce que vous faites à quelqu’un lors d’une fête. Donc, pour l’instant, mettons de côté les nuances autour de termes spécifiques à DevOps et concentrons-nous sur la vue d’ensemble.
Qu’est-ce que DevOps en 6 définitions et analogies ?
Nous avons demandé aux experts DevOps comment ils expliquent DevOps avec leurs mots les plus courts et les plus simples afin que tout le monde puisse comprendre sa valeur, quelle que soit sa formation technique. Voici quelques définitions percutantes et quelques analogies utiles pour vous aider à raconter votre propre histoire DevOps.
1. DevOps est un mouvement culturel
Visitez ce site
« DevOps est un mouvement culturel où les deux principaux groupes de parties prenantes (développeurs de logiciels et opérations informatiques) conviennent que le logiciel n’ajoute pas vraiment de valeur tant qu’il n’est pas utilisé par quelqu’un – clients, utilisateurs, employés, etc. » explique Eveline Oehrlich, directrice de recherche en chef au DevOps Institute.
« Pour cette raison, les deux équipes veillent ensemble à ce que les logiciels soient livrés avec rapidité et qualité. »
2. DevOps responsabilise les développeurs
DevOps permet aux développeurs de posséder, d’exécuter et de manager de bout en bout la livraison d’une application.
« Il est communément admis que DevOps permet une livraison en production plus rapide en mettant en œuvre et en exploitant des processus automatisés. Pour moi, c’est beaucoup plus fondamental », explique Jai Schniepp, propriétaire de produit senior de plates-formes DevOps sécurisées chez Liberty Mutual.
« DevOps permet aux développeurs de posséder, d’exécuter et de manager de bout en bout la livraison d’une application ou d’un logiciel. DevOps élimine la confusion autour de la propriété et conduit l’équipe vers une infrastructure automatisée et managée par les développeurs. »
3. DevOps est une approche collaborative de création et de livraison de logiciels
« En termes simples, DevOps est une approche de création et de fourniture de logiciels informatiques dans laquelle tout le monde travaille ensemble », explique Gur Steif, président de l’automatisation des activités numériques chez BMC.
4. DevOps est comme une chaîne de montage
Pour qu’une chaîne de montage fonctionne, les composants doivent être conçus pour s’assembler de manière transparente.
« Je comparerais DevOps à une chaîne de montage », déclare Gur Steif. « L’idée est de concevoir et de construire toutes les pièces à l’avance, de manière à ce que toutes les pièces s’emboîtent. Pour qu’une chaîne de montage fonctionne, les composants doivent être conçus pour s’assembler de manière transparente. Les gens qui conçoivent et construisent les moteurs doivent penser au châssis et aux supports de moteur. Les gens qui construisent des freins doivent penser aux jantes et aux pneus, et ainsi de suite. C’est comme ça que ça doit être dans le logiciel. Les développeurs qui écrivent la logique métier ou l’interface utilisateur doivent penser à la base de données qui stocke les informations client, à la sécurité qui protège les données utilisateur et à la façon dont tout cela fonctionne lorsque le service est exposé à ce qui peut être des millions d’utilisateurs.
« Amener les gens à collaborer et à penser au travail effectué par d’autres plutôt que de se concentrer uniquement sur leur(s) tâche(s) individuelle(s) est le plus grand obstacle à surmonter. Si vous y parvenez, vous avez d’excellentes chances de réaliser la transformation numérique », ajoute Steif.
5. DevOps est une recette – combinant les personnes, les processus et l’automatisation
Jayne Groll, PDG du DevOpsInstitute, a une excellente analogie culinaire pour expliquer DevOps :
DevOps est une recette qui repose sur des ingrédients de trois grandes catégories : les personnes, les processus et l’automatisation.
La plupart des ingrédients peuvent être adaptés à partir d’autres pratiques et sources bien connues telles que Lean, Agile, SRE, CI / CD, ITIL, le leadership, la culture et les outils. Le secret derrière DevOps est la façon dont ces ingrédients sont combinés et dans les bonnes proportions (comme toute bonne recette) afin d’augmenter le flux et la valeur pour le client.
6. Les équipes DevOps sont comme les équipes de course NASCAR
Les équipes de course ne réfléchissent pas du départ à l’arrivée; Elles tournent la table pour considérer la course de la ligne d’arrivée au départ.
« Lorsque je parle des résultats souhaités pour une initiative DevOps, je mentionne NASCAR ou les courses de F1 », explique Chris Short, responsable marketing technique principal, plates-formes cloud, chez Red Hat, et éditeur de la newsletter DevOps’ish.
« Les chefs d’équipe de ces équipes de course n’ont qu’une mission : Finir à la meilleure place possible avec les ressources dont ils disposent tout en surmontant l’adversité à laquelle ils sont confrontés. Les équipes de course ne réfléchissent pas du départ à la ligne d’arrivée ; Elles renversent la problématique pour regarder la course de la ligne d’arrivée au départ. Elles se fixent un objectif, un objectif ambitieux, puis commencent à travailler à rebours à partir de ces objectifs pour déterminer comment y arriver. Le travail est délégué aux membres de l’équipe pendant la semaine de la course pour atteindre l’ensemble des objectifs qui permettent d’obtenir le résultat souhaité. »
« Les équipes de course pratiquent les arrêts aux stands toute la semaine avant la course. Elles suivent des programmes de musculation et de cardio pendant la semaine pour se garder physiquement prêtes pour les conditions exténuantes du jour de la course. Elles collaborent continuellement pour résoudre tout problème qui pourrait survenir. De même, les équipes logicielles devraient pratiquer souvent les livraisons. Si les systèmes de sécurité sont en place et que les essais se déroulent bien, la mise en production se produit plus fréquemment. La vitesse rend les choses plus sûres avec cet état d’esprit », explique Short.
« Il ne s’agit pas de faire la « bonne » chose », ajoute-t-il, « il s’agit d’adresser autant de choses qui pourraient vous empêcher d’obtenir le résultat souhaité que possible. Collaborez et ajustez en fonction des retours en temps réel que vous observez. Attendez-vous à des anomalies et travaillez pour améliorer la qualité afin de minimiser l’impact de ces anomalies sur l’objectif. Ce sont les attentes de chacun dans un monde DevOps. »
Qu’est-ce qu’un ingénieur DevOps ?
Un mouvement culturel, une méthodologie, une recette pour réussir : Remarquez comment personne n’a fait référence à DevOps comme à un rôle.
Pourtant, l’ingénieur DevOps figure en bonne place sur la liste des meilleurs emplois de Glassdoor en Amérique, et ce chaque année depuis 2017. Est-il logique d’étiqueter le mot « DevOps » sur le titre d’une personne lorsque des organisations informatiques toutes entières sont invitées à travailler d’une nouvelle manière ?
Certains croient fermement que la réponse est non.
« DevOps est une méthodologie, pas un rôle», explique Neelan Choksi, président et chef de l’exploitation chez Tasktop. « Plutôt que d’étiqueter vos ingénieurs « ingénieurs DevOps », vous devez reconnaître que le rôle de l’ingénieur dans le développement et les opérations a évolué et continue de le faire. Parce que le cloisonnement des organisations en départements appartient au passé, le changement perpétuel n’est plus le travail d’un département et le problème d’un autre.
En fait, trop se concentrer sur les rôles individuels peut freiner les organisations, dit Choksi. « Si [dans votre organisation] la culture DevOps est plutôt considérée comme un job ou un rôle unique, vous pouvez toujours apporter de petites améliorations locales en adoptant les meilleures pratiques DevOps, mais l’impact de ces pratiques sera limité. »
A l’autre extrémité du débat, certains soutiennent que les titres sont significatifs, surtout lorsque les industries traversent des transformations majeures. Inclure le terme DevOps sur un CV ou une description de poste indique un niveau de compétence qui est actuellement difficile à trouver, dit Oehrlich.
« J’ai suivi la transformation DevOps en tant qu’analyste de l’industrie depuis ses débuts », a récemment écrit Oehrlich. « Aujourd’hui, l’utilisation de la méthodologie DevOps est de 74 % (en dehors des méthodologies complémentaires), avec une adoption à l’échelle de l’entreprise de 24 % et une adoption projet (ou projets multiples) de 42 %, selon le rapport Upskilling 2020 : Enterprise DevOps Skills Report. »
Le défi numéro un auquel est confronté DevOps est de trouver et d’attirer des personnes DevOps qualifiées. 58 % des personnes interrogées ont déclaré que trouver des personnes qualifiées est un énorme défi, tandis que 48 % disent que la rétention de personnes DevOps qualifiées est un challenge.
Quelle que soit votre position dans le débat en cours sur les ingénieurs DevOps, Choksi et Oehrlich ont tous deux des conseils sur ce qu’il faut rechercher chez les personnes qui dirigent DevOps dans votre organisation :
« Les ingénieurs DevOps doivent se concentrer sur leurs compétences en résolution de problèmes et sur leur capacité à accroître l’efficacité, à gagner du temps et à automatiser les processus manuels et, surtout, à se soucier de ceux qui utilisent leurs livrables », explique Choksi. « L’ingénieur à l’épreuve du temps est capable de travailler entre les équipes et les fonctions, non seulement au sein de l’informatique, mais aussi dans l’ensemble de l’entreprise. Ils sont en mesure de tirer parti de spécialistes et d’intégrer les approches et méthodologies optimales qui offrent de la valeur dans un environnement concurrentiel rapide avec la qualité requise par les clients. »
« Le titre d’ingénieur DevOps décrit une façon différente de concevoir », explique Oerhlich. « Bien qu’il existe des responsabilités fondamentales pour un ingénieur DevOps (codage, script, ré-ingénierie, automatisation, collaboration et communication), le rôle lui-même est un rôle d’ingénierie. L’ingénierie est une question d’innovation, la créativité étant un trait humain fondamental qui stimule le développement de nouvelles technologies et de nouveaux produits, processus ou services. La combinaison des mots « DevOps » et « ingénieur » met en avant que l’avenir est à l’innovation autour de la façon dont le développement et les opérations sont effectués ensemble : Le titre « ingénieur DevOps » souligne cet état d’esprit. »
partagez ce billet avec vos amis, collègues et relations professionnelles
Chez les managers de projets comme dans de très nombreuses autres professions, les différences entre adopter et bien utiliser le bon ou le mauvais outil sont du temps, de l’argent et de la sécurité !
C’est presque un cliché chez les menuisiers et autres artisans qui créent avec leurs mains. La différence entre le bon et le mauvais outil est du temps, de l’argent et de la sécurité. La satisfaction d’avoir un levier approprié à votre effort est extraordinaire.
Il est autant question de qualité d’outillage que de savoir bien se servir des outils que l’on a !
Regarder les gens se débattre avec leur téléphone ou leur ordinateur portable est triste et frustrant. Les gens continuent d’utiliser de mauvais outils. Peut-être que ce sont ceux qu’ils ont appris à utiliser il y a longtemps. Peut-être qu’ils sont arrivés gratuitement avec l’appareil. Plus probablement, ils sont le résultat d’une société de développement de logiciels qui ne prend pas suffisamment en compte les besoins de l’utilisateur.
Il existe probablement un meilleur outil numérique pour ce que vous essayerez de faire la prochaine fois en ligne. Cela vaut peut-être la peine de prendre quelques instants pour vous questionner, découvrir et apprendre.
Investissez une fois, profitez-en pendant très longtemps.
Téléchargez aussi ce guide sur le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
Après avoir lu le billet de Donald Hook sur les raisons d’échouer dans une initiative de transformation numérique (de digitalisation), j’ai choisi d’en reprendre le propos mais en regardant plutôt les raisons et conditions pour réussir ces projets méritants et si difficiles !
Les entreprises se sont lancées dans des efforts de transformation numérique pour réduire les coûts, accroître l’efficacité et mieux servir leurs clients. Mais c’est plus facile à dire qu’à faire. Une transformation numérique réussie nécessite une stratégie bien définie et des équipes expérimentées.
Du point de vue du client, fournir les informations dont il a besoin quand il en a besoin et rendre les interactions faciles et sans friction signifie que votre transformation numérique a été pleinement réussie.
D’un point de vue informatique, il s’agit de rapidité et d’agilité et de mise en place des outils, des technologies et des processus nécessaires pour fournir rapidement des solutions. Les équipes informatiques doivent être organisées de manière à inclure des représentants du produit, de la technologie et de l’expérience utilisateur.
La transformation numérique couvre l’ensemble de l’organisation, y compris les entités commerciales, les fournisseurs, les usines, les centres de distribution et l’informatique. Pour réussir, les dirigeants de tous ces domaines doivent être impliqués, alignés et responsables. Un plan et une feuille de route solides décrivant les initiatives, les dépendances, les investissements, la valeur opérationnelle, les rôles et responsabilités, le calendrier et la gouvernance doivent être définis.
La transformation numérique nécessite un investissement important en argent, en temps et en engagement. La dernière chose que les entreprises veulent faire est de se lancer dans une initiative d’entreprise, pour ensuite la faire échouer. L’échec peut avoir un impact négatif sur la crédibilité des dirigeants, des chefs d’entreprise et du service informatique.
Visitez le site de notre partenaire Virage Group
10 moyens de réussir votre transformation digitale
Considérez ces dix approches qui permettent aux initiatives de transformation numérique de réussir et laissez-les vous guider pour vous assurer que la votre est un succès.
#1 – Concentrez-vous sur les bonnes choses
Assurez-vous que chaque initiative entraînera une transformation ou sera un élément pour soutenir la transformation.
Concentrez-vous sur la transformation de l’expérience client, de l’efficacité commerciale, de l’expérience employé ou de l’efficacité informatique.
Vous concentrer sur des initiatives qui ne génèrent pas de valeur ou de transformation serait une perte de temps et un gaspillage de ressources.
#2 – N’attaquez pas trop de choses à la fois
Vous devez prendre en compte le fait que les équipes sont déjà souvent en difficulté pour suivre les projets en cours et réaliser le support opérationnel.
Ne les surchargez pas à outrance car cela entraînerait des retards dans les projets, de la frustration et, en fin de compte, cela coûtera plus de temps et d’argent.
#3 – Faites appel à des partenaires externes
La réalité est que peu d’organisations possèdent les talents et le leadership en interne pour comprendre les dernières tendances et les technologies émergentes.
De plus, comme vu au point précédent, les ressources internes sont généralement enlisées dans le support opérationnel quotidien et des projets en cours. Gagnez du temps et de l’argent en faisant appel à un partenaire.
#4 – Établissez une stratégie et une feuille de route claires
La transformation numérique s’étend à l’ensemble de l’entreprise et nécessite un alignement au sein de toute l’organisation, voire de l’entreprise. Vos initiatives doivent être axées sur la transformation.
Si ce n’est pas le cas, les ressources seront gaspillées et la transformation échouera. Comme la stratégie technologique est un élément clé, la future plate-forme, les technologies et l’architecture d’entreprise doivent être bien définies pour supporter et faciliter la transformation numérique.
#5 – Soyez clair sur vos objectifs
Pour réussir, il vous faut connaitre intimement vos objectifs finaux.
Des buts et des objectifs clairs vous fournissent ainsi qu’à l’équipe le périmètre de votre effort de transformation numérique et serviront de garde-fous pour rester focalisés sur ces objectifs.
#6 – Assurez-vous de l’engagement et de l’alignement de la direction
Les initiatives d’entreprise nécessitent le plein support, l’engagement et la responsabilisation de la direction.
Les dirigeants prendront les décisions finales sur les nouveaux processus opérationnels et fourniront des conseils sur la meilleure façon de résoudre les problèmes.
De plus, les dirigeants doivent s’assurer que leurs équipes sont engagées, concentrées et comprennent les priorités. Ceci vous permettra de ne pas accumuler des retards qui auraient un impact sur l’ensemble de l’effort.
#7 – Managez TOUT le changement
La transformation numérique ne se limite pas à la technologie :
Le changement survient rarement en un claquement de doigts. Il se fait le plus souvent dans la durée.
Il s’agit aussi de la transformation des personnes.
Les processus opérationnels, les technologies et les modèles budgétaires vont souvent être radicalement modifiés.
Cela signifie que les contenus des jobs de nombreuses personnes vont changer.
Élaborez une stratégie et un robuste plan de management du changement. Faites voir à ces personnes la valeur de la transformation pour éviter les rejets. Les personnes doivent être à l’aise avec cet inconfort et ont besoin d’aide pour embrasser le changement.
#8 – Menez cette transformation comme un programme
Communiquez de manière ouverte à tous les niveaux
La taille, la portée et l’ampleur de la transformation numérique peuvent être énormes. Comme pour toute grande initiative informatique, vous devez la manager comme un programme.
Vous devez communiquer fréquemment auprès de toutes les parties prenantes sur les progrès, les coûts, le calendrier, les risques et l’état d’avancement.
Et vous devez vous assurer que ceux-ci sont bien compris. En particulier les risques qui doivent être identifiés et traités proactivement.
#9 – Mettez en place une gouvernance et des métriques
La gouvernance d’entreprise et les Key Performance Indicators (KPI) sont essentiels pour que l’effort de transformation numérique soit suivi comme prévu.
Avec une gouvernance et des métriques bien en place, vous saurez à tout moment si vous atteignez vos objectifs et si vous réalisez des progrès.
Les KPI peuvent fournir une indication précoce que des ajustements sont nécessaires.
10 – Ayez une bonne vision technique de l’initiative
La technologie est à la base de la transformation numérique. Les plates-formes et applications technologiques existantes n’utilisent peut-être pas l’architecture et les outils les plus récents.
Les microservices, le cloud, edge computing, l’intelligence artificielle (IA) et le machine learning sont des technologies émergentes qui doivent être prises en compte.
Cependant, si votre informatique ne sait pas quelles technologies émergentes peuvent être exploitées, elle risque de créer davantage de dette technique.
C’est un voyage
N’oubliez pas que la transformation numérique est un voyage et non pas une destination finale. C’est un processus continu, pas quelque chose qui se fait du jour au lendemain. La transformation numérique est également unique à chaque entreprise. Il n’existe pas d’approche universelle.
Quand vous vous lancez dans la transformation numérique, il est essentiel que vous restiez au fait des nouveautés et poursuiviez les efforts de transformation. Sinon, votre investissement en temps, en argent et en ressources n’aura servi à rien.
partagez ce billet avec vos amis, collègues et relations professionnelles
Si vous êtes en réflexion sur vos besoins en matière d’outillage pour votre management de portefeuille de projets, voici une fiche pratique pour vous aider à bien définir le cahier des charges !
Quel que soit votre choix final en matière de logiciel, je pense que vous trouverez ce modèle très utile et structurant. J’espère surtout qu’il vous permettra de n’oublier aucun aspect critique dans votre recherche en fonction de vos propres besoins.
Comment rédiger un cahier des charges pour un logiciel de gestion de portefeuille projets ?
Les points clés à ne pas oublier
Un guide de rédaction avec les rubriques principales pour expliciter votre besoin en matière de management de portefeuille de projets
Les informations à donner à l’éditeur pour qu’il vous réponde avec la bonne offre : Logiciel + prestations d’accompagnement.
Téléchargez ce guide sur le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
Les outils de planification vous aident et cependant, comme toute autre technologie, ils peuvent vous être défavorables. Déjouez ces principaux pièges !
Comme un couteau tranchant pour un chef, un outil de planification est un élément indispensable pour un manager de projet.
Les outils de planification, comme toute technologie, peuvent aider ou blesser.
Voici cinq conseils pour utiliser votre outil de planification de projet avec moins de drama.
#1 – Utilisez un modèle ou réutilisez un plan réussi
Bien que les projets soient uniques, ils sont rarement totalement différents des projets antérieurs. Utilisez un modèle de projet ou copiez et modifiez un échéancier d’un projet passé qui a bien fonctionné. Vous pouvez gagner du temps, tirer parti du succès de ces échéanciers et capturer des tâches que vous pourriez autrement négliger.
#2 – Gardez simples les relations entre les tâches
La relation directe entre taches de type finish-to-start fonctionne la plupart du temps et c’est la plus facile à comprendre pour les gens.
Utilisez cette relation simple à moins qu’il n’y ait une raison pressante pour le start-to-start ou finish-to-finish.
#3 – Personnalisez le calendrier et les heures/jours par défaut
Les paramètres de calendrier que vous utilisez doivent correspondre aux horaires de travail de votre organisation et des membres de votre équipe, sinon votre échéancier ne sera pas exact. N’oubliez pas d’ajouter les jours fériés et autres jours non travaillés comme les périodes de maintenance des locaux à votre calendrier de projet. De plus, envisagez d’ajuster les heures par défaut par journée ou autres paramètres du calendrier pour tenir compte du temps de travail réel du projet. Bien qu’une journée de travail de 8 heures soit courante, les membres de l’équipe travaillent rarement 8 heures sur vos tâches de projet. Des réunions d’équipe, d’autres travaux de projet et opérationnels sont souvent nécessaires. Vous pouvez changer le nombre d’heures par journée travaillée à 6 ou même moins en fonction de votre environnement. Ou vous pouvez affecter des personnes à temps partiel sur leurs tâches. Parlez aux membres de votre équipe de ce qui est réaliste.
#4 – Simplifiez les affectations de ressources
La gestion et la modification des affectations de ressources sont d’énormes sources de problèmes de planification. Une pratique exemplaire consiste à répartir le travail du projet afin que les tâches soient plus courtes que vos périodes de reporting et ont seulement une ou deux ressources affectées. Avec de telles tâches, il est beaucoup plus facile de créer des affectations de ressources et de les modifier une fois le travail commencé.
#5 – Formez les gens à utiliser l’outil de planification
Les outils de planification vous aident à produire des rapports faciles à comprendre. Parfois, les gens croient qu’ils peuvent modifier vos plannings ou produire des rapports de projet sans aucune formation. C’est une recette pour des rapports inexacts, des problèmes de management des attentes et une migraine pour le chef de projet ! Assurez-vous que toutes les personnes qui utiliseront l’outil de planification pour tenir à jour l’échéancier et produire des rapports soient correctement formées.
Visitez le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
Virage Group est un éditeur de logiciels qui accompagne les managers dans l’exécution de leurs stratégies.
2 solutions sont proposées :
Logiciel de gestion de portefeuille projets (Project Monitor)
Logiciel de pilotage de plans d’actions (Perf Monitor).
Prenez le contrôle de votre portefeuille projets au sein d’un seul outil
Virage Group est partenaire de notre catégorie de billets PMO & Portfolio.
Découvrez Project Monitor, logiciel de Gestion de Portefeuilles Projets, adapté aux structures de plus de 50 collaborateurs et gérant +100 projets actifs. Facilitez la conduite de vos projets avec un outil tout-en-un : tableaux de bord multi-projets, plan de charge, planning, tâches, collecte et suivi des demandes informatiques, et suivi budgétaire.
Un outil de gestion de portefeuille projets adapté pour :
DSI : Pilotez l’ensemble de votre activité & vos projets IT
PMO : Dotez-vous d’un quartier général pour vos projets
Direction générale : Une vision complète sur vos projets stratégiques
Visitez le site de notre partenaire Virage Group
Comment savoir si vous avez besoin d’un logiciel de gestion de portefeuille projets (PPM) ?
Téléchargez gratuitement ce guide
Estimez votre retour sur investissement pour l’acquisition d’un outil de gestion de portefeuille projets.
Retrouvez dans ce guide :
Une fiche pratique des enjeux en gestion de portefeuille projets et les bénéfices d’une solution PPM associés
Les clés de dimensionnement de l’investissement et le déploiement à prévoir pour que les gains soient au rendez-vous
Exclusif : Les bénéfices obtenus avec la mise en place d’un logiciel PPM via des retours clients : Chronopost, Intermarché, Haute Savoie, Wurth.
Téléchargez ce guide sur le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
Contrairement aux méthodes de gestion de projet traditionnelles, le rôle de testeur dans les projets Agiles dépasse être simplement un exécuteur. Il comprend des activités qui génèrent et fournissent des retours (feedback) non seulement sur l’état du test, la progression du test et la qualité du produit, mais également sur la qualité du processus en collaborant de façon rapprochée avec toute l’équipe et ses parties prenantes.
En plus de compétences techniques reconnues (les tests d’acceptation, boîte blanche, boîte noire, les automatisations de test …), un testeur agile doit avoir de bonnes compétences interpersonnelles.
CSP est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Ayez une attitude constructive et une approche communicative
Une grande partie des problèmes se résument à un manque de communication. En tant que testeur, impliqué du concept au produit final, il est important de communiquer de manière ouverte et honnête. Il est également important de considérer la façon dont nous disons les choses. Il est préférable de dire « Je ne pense pas que cela fonctionne comme il se doit, il manque la fonctionnalité X » au lieu de « Cela ne fonctionne pas ».
Une discussion en face à face est souvent plus efficace.
En outre, il est important de déterminer quand utiliser des outils digitaux pour communiquer ou quand une bonne conversation en face à face est nécessaire.
Coachez les autres membres de l’équipe sur les aspects pertinents du test .
En partageant les connaissances de test avec l’équipe, vous leur montrez que, non seulement vous êtes un apprenant passionné, mais vous voulez les aider à apprendre et à améliorer le travail de l’équipe.
L’objectif d’un testeur n’est pas de trouver plus de bugs mais de construire un produit de valeur et de qualité.
Collaborez avec les développeurs, le Product Owner et les stakeholders pour clarifier les exigences, spécialement en termes de testabilité, consistance et complétude.
Le travail d’équipe rend les choses meilleures. Pour les testeurs de logiciels, travailler seul peut devenir la situation par défaut même si vous faites partie d’une équipe. N’oubliez pas que vous n’êtes jamais seul sur un projet.
Les testeurs doivent être impliqués dans les sessions de Pré-planification et de user stories grooming (analyse détaillée des besoins des utilisateurs) en ajoutant de la valeur lors de la :
Définition des user stories et des critères d’acceptation
Participation aux analyses de risques et de qualité de projet
Création de tests d’acceptation pour les user stories
Participez pro-activement aux rétrospectives d’équipe, suggérez et implémentez des améliorations .
Soyez impliqué, proactif, coopératif et soyez le membre de l’équipe avec qui vous aimeriez travailler. Soyez un modèle de bon membre d’équipe et, espérons-le, les membres de votre équipe le reconnaîtront et travailleront ensemble, avec vous, pour développer des pratiques de travail d’équipe.
Les testeurs Agile doivent ajouter de la valeur à chaque étape de la livraison du logiciel dans un projet agile.
Reportez les défauts et travaillez avec l’équipe pour les résoudre.
Au sein d’une équipe Agile, chaque membre de l’équipe est responsable de la qualité du produit et joue un rôle dans l’exécution des tâches liées aux tests. Le retour d’information dès que possible vers l’équipe en cas de problème économise temps et budget.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le chapitre 5 de ce livre blanc sur le développement d’apps mobile en « Low-Code et No-Code » est spécifiquement dédié au management de ce type de projets.
Face aux mutations, les organismes gagnants ne seront pas forcément les plus forts mais vraisemblablement les plus véloces à s’adapter.
Avec un fort taux d’équipement, l’évidence de notre dépendance (addiction pour certains) vis-à-vis des smartphones et des applications mobiles, est devenu un fait bien enraciné.
Les tendances observées d’usage et de comportements des mobinautes, l’adaptation des organismes à la recherche d’agilité avec le numérique et le cloud, confirment la nécessité de créer et exploiter des applications mobiles très facilement et très rapidement.
Créer de la valeur via des applis mobiles, avec la capacité de les modifier, les faire évoluer simplement malgré un manque de compétence en développement, le contexte est donc à l’évidence propice au « No-code » « Low-Code » !
Bruno Doucende est PDG de Synertic et anime de longue date les activités du PMI en région Provence avec une belle équipe de managers de projet venus de tous horizons.
partagez ce billet avec vos amis, collègues et relations professionnelles
Une vidéo tente de l’expliquer le plus simplement possible (avec des Lego) à qui que ce soit.
Les principes positifs dans le paradigme de l’open source sont nombreux et pas limités au monde du logiciel informatique. Aussi, même pour les personnes n’ayant aucune connaissance préalable du logiciel libre ou gratuit comprendront les analogies et exemples choisis.
Bien sûr, la vidéo elle-même est en open source, pour que vous puissiez l’utiliser, la modifier et la partager.
partagez ce billet avec vos amis, collègues et relations professionnelles
Cette année se placera sous le signe des outils de la Maturité en Projets des organisations soucieuses d’améliorer leur système de pilotage des projets et du portefeuille.
La Gestion de Projets et Portefeuille By IQar, découvrez la plateforme de Maturité en Projets !
Nouveauté 2017/2018 : L’outil PPM d’IQar, SuiteProG : un pilotage pragmatique, simple d’accès et pédagogique !
Démonstration de l’outil
Plus de 1000 utilisateurs,
Une équipe Produit constituée pour un outil full SaaS : les consultants experts associés à notre une cellule R&D informatique développent les prochaines feuilles de route de SuiteProG
Une nouvelle version de SuiteProG présentée prochainement lors du Club Utilisateurs SuiteProG ! Première édition prévue en Juin 2018
Pour en savoir plus, demandez-nous une démonstration personnalisée de SuiteProG : cliquez ici.
Évaluez la maturité ’Projets’ de votre Organisation : Faites les tests !
En ligne, tests gratuits avec rapports complets d’audit !
Et appuyez-vous sur le référentiel français SMPP, le métier et les conseils d’IQar pour décliner cette maturité en plan de progrès
IQar, auteur du référentiel français du système de management des portefeuilles de projets (SMPP), met à disposition des organisations, une plateforme d’information sur l’évaluation et le développement de la maturité en management des portefeuilles projets.
Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Quand Henry Ford a conçu ses usines en 1913 pour construire la Modèle T, il a réduit le temps nécessaire pour assembler une voiture de plus de 12 heures à 2 heures 30 minutes. Ce processus a permis la production d’une automobile à prix ciblé pour “le travailleur”. Toutes les voitures avaient la même conception et toutes étaient peintes en noir.
Les designs préconfigurés fonctionnent quand les prévisions rencontrent les attentes (qui en 1913 aurait demandé une voiture rouge ?) et quand un spécialiste peut remettre son travail au suivant sans aucune perte de temps dans la transmission.
Quand une société est dans le business de produire des produits et des services innovants, ses plans reposent sur une ou plusieurs estimations et suppositions. Ces évaluations ne sont rien de plus que des probabilités. Baser un plan de projet sur des suppositions exige que votre système puisse manager les changements.
Livre sur Amazon
Marie Poppendieck a exposé dans Lean Software Development, An Agile Toolkit, “le simple fait mathématique ici au travail est que toute variation est toujours amplifiée comme elle déplace le long d’une chaîne d’événements connectés. Une petite variation dans une étape peut représenter une énorme variation cinq étapes plus loin”. Donc la question reste entière quant à pourquoi les managers continuent à planifier des projets en se basant sur des suppositions séquentielles.
Pour comprendre comment un changement inattendu peut causer des retards significatifs en aval, visualisez une chaussée très occupée avec des voitures se déplaçant selon la limitation de vitesse. Le trafic s’écoule régulièrement jusqu’à l’entrée d’un nouveau véhicule ou autre événement qui fasse qu’un conducteur actionne ses freins. Le trafic sur la chaussée ralentit ou s’arrête alors pendant une brève période puis recommence à s’écouler de nouveau sans signe apparent de pourquoi il a ralenti en premier lieu. L’exemple de cette route illustre comment, à moins que les systèmes ne soient conçus pour se concentrer sur le flux, ils ne fonctionneront pas efficacement à pleine capacité. Parce que le développement de logiciel est un effort complexe dans lequel les suppositions et les décisions devraient être prises le plus tard possible. Le fait de prendre des décisions au dernier moment possible permet à l’équipe Scrum de changer pour travailler sur les articles d’arriéré de produit de plus de valeur en fonction des données les plus récentes.
CertYou est partenaire de DantotsuPM
L’empilement de beaucoup de suppositions l’une après l’autre dans un plan de projet réduit significativement la probabilité d’un résultat positif.
Par exemple, considérez cinq tâches tout d’une probabilité de 90 % d’achèvement en une semaine: (0.9 * 0.9 * 0.9 * 0.9 * 0.9 = 0.59). Dans ce cas, nous avons cinq tâches sur lesquelles nous nous sentons confiants, mais le résultat cumulatif est que nous sommes à seulement 59 % de probabilité de finir ces cinq tâches en cinq semaines. Je soutiendrais que basé sur mon expérience de professionnel en management de projet, il est aussi peu probable que cinq tâches séquentielles atteignent jamais chacune un niveau de confiance de 90 %. Alors, êtes-vous encore étonné quand vous lisez Standish Group’s Chaos Report qui indique qu’approximativement 70 % de tous les projets des technologies de l’information échouent à atteindre leurs objectifs et sont significativement en retard et sur-dépensent ?
Ceci n’empêche pas que vous devriez adorer les statistiques 🙂
La meilleure façon d’optimiser la livraison de valeur est de faire des tâches ajoutant une valeur visible pour les parties prenantes. La documentation de chaque flux de valeur mettra en évidence l’avancée et les retards entre les transitions. En évaluant quantitativement des activités du flux de valeur, le coût des retards devient aussi visible. Cette visibilité aidera l’organisation à déterminer où la constitution d’équipes fonctionnelles transverses améliorera immédiatement les temps de réponse.
L’utilisation de Scrum pour rendre ces inefficacités visibles est seulement le premier pas.
Le leadership a-t-il le désir et l’engagement d’effectuer le changement ? Craig Larman, l’auteur des Laws of Organizational Behavior, a observé que les organisations sont implicitement optimisées pour éviter de changer les positions de statu quo et les structures de pouvoir. Il a aussi noté que si vous voulez changer la culture d’une société, vous devrez changer la structure de votre organisation parce que la culture/comportement et la mentalité suivent les systèmes organisationnels et leur design.
Les organisations comme des sociétés d’assurance et banques ont typiquement les silos de spécialisation fortifiés autour des applications, technologies et fonctions. Chacun de ces départements a développé des règles soigneusement travaillées et des procédures interdisant le changement. Ces processus administratifs ont pour conséquence fortuite de perturber le flux de valeur qui va du concept à la livraison au client.
avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets
Marie Poppendieck a décrit cette situation Lean Software Development: An Agile Toolkit, “la règle établie pour résoudre un problème renforcera souvent le problème, créant une spirale vers le bas : Comme un problème empire, les managers appliquent encore plus agressivement la même politique qui cause le problème.” La mise en place d’équipes fonctionnelles transverses qui ont toutes les compétences pour achever le travail sans avoir à traverser des silos fonctionnels aura un impact étonnamment positif sur la capacité des organisations d’améliorer la qualité et le temps nécessaire pour commercialiser.
Votre direction a-t-elle le courage et l’engagement d’entreprendre le dur labeur d’éliminer les processus et les procédures qui n’ajoutent pas de valeur ?
La plupart des sociétés considérant l’adoption de Scrum devront changer leurs structures organisationnelles pour soutenir des équipes fonctionnelles et transverses autonomes. Si la structure organisationnelle ne change pas, les comportements ne vont pas probablement changer. Si votre modèle business dépend de l’innovation, ce changement devrait être d’une priorité supérieure.
partagez ce billet avec vos amis, collègues et relations professionnelles
Avec le mode projet, la hiérarchie s’estompe et les équipes doivent apprendre à collaborer efficacement pour aller au bout de leur mission.
85% des équipiers reconnaissent avoir été confrontés à plusieurs formes de conflits durant leurs projets
Le logiciel Entr’UP Teams qui améliore la collaboration des équipes, leur cohésion et leur efficacité, à travers la maîtrise des interactions est utilisé par de nombreuses équipes. Entr’UP recrute pour participer à un atelier des chefs de projet, directeurs de projets qui vont évaluer les futures fonctionnalités de Smart Assistant, Entr’UP Teams.
Comme pour tout le reste, il n’y a pas de solution miracle, mais il faut veiller à ne pas aller trop loin avec les exigences. Étant donné qu’il s’agit d’un Technical Spike, il est nécessaire de s’assurer que l’exigence est à un niveau très élevé suffisant pour décrire les objectifs du Technical Spike et qu’elle ne soit pas prescriptive.
Praticien agile et agnostique ainsi qu’un formateur professionnel Scrum avec Scrum.org
DantotsuPM.com 