Étiquette : software

Savez-vous que les utilisateurs n’interagissent en moyenne qu’avec 6 % des fonctionnalités de votre produit ?

Le par mopertodans experience sharingLaisser un commentaire

Votre équipe se concentre-t-elle sur des fonctionnalités qui ne sont pas ou très très peu utilisées par vos utilisateurs finaux ?

Users engage with only 6% of product features: Product benchmark findings par Louron Pratt

https://www.mindtheproduct.com/users-engage-with-6-of-product-features-product-benchmark-findings/

Avec le passage aux licences logicielles par abonnement, il est plus important que jamais pour les utilisateurs de voir la valeur d’un produit. Les meilleurs chefs de produit utilisent l’adoption des fonctionnalités pour mesurer et améliorer la valeur de leur produit. Cette enquête benchmark vise à évaluer la façon dont les fonctionnalités sont reçues par les utilisateurs.

Qu’est-ce que l’adoption d’une fonctionnalité ?

L’adoption des fonctionnalités vise à répondre à une question fondamentale : Les utilisateurs découvrent-ils vraiment la valeur de votre produit et de ses outils de base ?

En comprenant comment (ou si) les clients utilisent des fonctionnalités spécifiques, vous aurez une idée claire de si ces fonctionnalités atteignent leurs objectifs.

Combien d’utilisateurs utilisent les nouvelles fonctionnalités ?

Notre enquête comparative a révélé que le taux moyen d’adoption des fonctionnalités pour les produits est de 6,4%. Ainsi, pour 100 fonctionnalités que votre équipe analyse, construit et livre, seules 6,4 d’entre elles génèrent 80% du volume de clics. Pour les produits du top 10 %, l’adoption des fonctionnalités augmente de 15,6%, soit 2,5 fois plus que la moyenne.

Nous avons constaté que même les meilleures équipes produit se concentrent sur des fonctionnalités qui ne sont pas utilisées par leurs utilisateurs finaux. Alors que 6,4% des fonctionnalités génèrent 80% des clics, près de 94 % des fonctionnalités sont intactes et ignorées.

Adoption des fonctionnalités par industrie

À première vue, l’industrie peut ne pas sembler importante en rapport à l’adoption de la fonctionnalité. Cependant, de petits détails tels que le public cible, la saturation du marché et les nuances de l’industrie s’additionnent pour avoir un impact sur vos benchmarks de produits. Un produit de service aux entreprises avec un taux d’adoption de 7% peut être un succès retentissant. Cependant, l’adoption par 7% des utilisateurs de la nouvelle fonctionnalité de messagerie d’une application de médias sociaux pourrait tirer la sonnette d’alarme.

En moyenne, les produits de l’industrie manufacturière et des biens de consommation ont le taux d’adoption de fonctionnalités le plus élevé. Les produits dans les médias sont légèrement plus faibles, à 4,9%. En fonction de l’adoption moyenne des fonctionnalités de votre secteur d’activité, il peut être important de vous concentrer sur l’amélioration de l’adoption de vos outils les plus importants.

Adoption des fonctionnalités par taille d’entreprise

En moyenne, les entreprises de moins de 200 employés ont le taux d’adoption de leurs fonctionnalités le plus élevé, soit 7,4%. Cela peut s’expliquer par le fait que les petites entreprises n’en sont qu’aux premiers stades de l’expansion de leur produit et que leurs fonctionnalités majeures constituent souvent une plus grande partie de leur produit. D’autre part, les grandes entreprises disposent d’un écosystème tentaculaire de produits, avec plus de ressources pour développer et améliorer les fonctionnalités.

Pourquoi l’adoption des fonctionnalités de suivi est-elle importante ?

Mesurez et comprenez le succès.

Le suivi de l’adoption des fonctionnalités révèle si les utilisateurs trouvent votre produit utile ou non. Associé à votre voix du client (Voice of Customer), vous pouvez comprendre le « pourquoi » d’une adoption plus faible ou plus élevée.

Sachez comment améliorer l’engagement du produit.

Comprenez quelles fonctionnalités vos utilisateurs apprécient réellement et lesquelles ils ignorent. Ceci est fondamental pour fidéliser et fidéliser vos utilisateurs. Utilisez l’adoption de fonctionnalités pour guider vos priorités : Que devez-vous améliorer et que devez-vous supprimer de votre produit ?

Éliminez le gaspillage des ressources.

Une mauvaise adoption des fonctionnalités entraîne un gaspillage des ressources, mais de nombreux produits souffrent d’une prolifération des fonctionnalités. Une fois que vous avez évalué l’adoption des fonctionnalités, vous pouvez avoir une meilleure idée de ce dont vos utilisateurs ont besoin et de ce dont ils n’ont pas besoin.

Améliorez vos résultats finaux.

Des fonctionnalités inutilisées peuvent nuire à vos résultats à plus d’un titre. Payer pour des fonctionnalités inutilisées réduit la valeur perçue d’un client et, en fin de compte, affecte sa volonté de renouveler au niveau de prix actuel, voire de renouveler tout court.

Quatre façons d’améliorer l’adoption des fonctionnalités

  1. Simplifiez l’adoption grâce à des procédures pas à pas.
  2. Annoncez de nouvelles fonctionnalités dans l’application.
  3. Indiquez clairement la valeur et l’action souhaitée.
  4. Ciblez vos communications.

 

  1. Simplifiez l’adoption grâce à des procédures pas à pas : Il doit être aussi facile que possible pour les clients de trouver et d’utiliser les fonctionnalités. Une fois que vous avez annoncé une nouvelle fonctionnalité, créez des procédures pas à pas au sein même de votre produit pour guider les utilisateurs à travers les étapes souhaitées, en particulier pour les fonctionnalités qui nécessitent plusieurs étapes dans le flux de travail.
  2. Annoncez de nouvelles fonctionnalités dans l’application : L’un des meilleurs outils pour promouvoir des fonctionnalités est votre produit lui-même. Lorsque vous annoncez des fonctionnalités dans l’application à l’aide de guides ou d’ infobulles, vous atteignez les utilisateurs au moment et à l’endroit où le message est le plus pertinent.
  3. Indiquez clairement la valeur et l’action souhaitée : Lorsque vous créez des messages dans l’application ou d’autres contenus sur les fonctionnalités, utilisez un langage simple qui communique clairement la valeur. Ensuite, dirigez les utilisateurs vers la prochaine action que vous souhaitez qu’ils entreprennent (comme visionner une démonstration guidée).
  4. Ciblez vos communications : Toutes les fonctionnalités ne sont pas pertinentes pour tous les utilisateurs. Créez des segments au sein de votre plateforme d’expérience produit par rôle, autorisations et compétences techniques.

Tracez l’adoption des fonctionnalités de votre produit par rapport à vos pairs dans Mind the Product.

Comment pouvez-vous surmonter le défi que seulement 20 % des fonctionnalités que votre équipe livre soient réellement utilisées ?

Le par mopertodans experience sharingLaisser un commentaire

Nishita Hathi, chef de produit, partage des stratégies pour augmenter l’utilisation des fonctionnalités du produit et améliorer la fidélisation des clients.

Overcoming the 20% feature usage challenge par Nishita Hathi

https://www.mindtheproduct.com/overcoming-the-20-feature-usage-challenge/

Beaucoup d’entre nous dans la communauté des produits sont confrontés au défi de l’utilisation limitée des fonctionnalités du produit. Une enquête Pendo a révélé que la plupart des utilisateurs de produits n’utilisent pas 80 % des fonctionnalités du produit. Microsoft a également observé qu’un utilisateur moyen de PowerPoint utilise moins de 10 % des fonctionnalités PowerPoint disponibles. Ma propre expérience s’aligne également sur les résultats de l’enquête Pendo. Pourtant, l’augmentation de l’utilisation des fonctionnalités est cruciale pour fidéliser vos clients et favoriser votre croissance grâce à la vente incitative.

Dans cet article, je partage mes observations sur les motivations derrière l’introduction de nouvelles fonctionnalités, pourquoi les utilisateurs finaux sous-utilisent les fonctionnalités, quel en est l’impact potentiel et je décris les approches que j’ai utilisées pour augmenter l’utilisation des fonctionnalités.

Motivations pour l’introduction de nouvelles fonctionnalités

En tant que chef de produit, vous introduisez de nouvelles fonctionnalités et capacités dans vos produits pour plusieurs raisons :

  • Vous assurer que le produit est aligné sur les tendances du marché et de la technologie.
  • Vous assurer que le produit présente des caractéristiques uniques et différenciatrices.
  • Répondre aux demandes et défis spécifiques de vos clients.
  • Vous assurer que le produit est comparable à celui d’un concurrent.

Dans le monde B2B, les équipes des achats privilégient souvent les produits riches en fonctionnalités. La plupart des appels d’offres exigent de fournir une gamme complète de fonctionnalités, ce qui oblige les fournisseurs à les prendre en charge dans leurs produits afin de remporter le marché. De plus, dans des secteurs tels que les télécommunications mobiles, les normes technologiques évoluent constamment, ce qui oblige également les fournisseurs à prendre en charge les nouvelles technologies en fonction de l’évolution des normes.

Observations sur l’utilisation des fonctionnalités

Malgré la disponibilité de fonctionnalités complètes, les utilisateurs finaux n’en utilisent souvent qu’un petit sous-ensemble.

D’après mon expérience, cela est attribué à plusieurs facteurs :

  1. Se concentrer sur les besoins immédiats : Les utilisateurs finaux utilisent des fonctionnalités qui les aident à accomplir leurs tâches actuelles.
  2. Manque de temps : Les utilisateurs manquent souvent de temps pour explorer des fonctionnalités supplémentaires, même si celles-ci peuvent apporter une valeur supplémentaire.
  3. Manque de notoriété : Parfois, les utilisateurs ne sont pas au courant ou ont oublié ce qui est disponible dans le produit.

D’autres facteurs limitent également l’utilisation des fonctionnalités, notamment l’inertie à apprendre quelque chose de nouveau ou à faire quelque chose de différent. Avec des fonctionnalités complexes, la facilité de configuration ou le temps nécessaire à l’exécution de tâches spécifiques peuvent également dissuader de les utiliser.

Impact d’une faible utilisation des fonctionnalités

Une faible utilisation des fonctionnalités peut entraîner les conséquences suivantes :

  • Réduction des opportunités de vente incitative : Une utilisation limitée rend plus difficile la vente de fonctionnalités supplémentaires.
  • Risque accru de désabonnement : Si les utilisateurs n’utilisent que des fonctionnalités de base ou très limitées, ils peuvent plus facilement se tourner vers des concurrents offrant la même chose.

Approches pour stimuler l’utilisation des fonctionnalités

Afin d’augmenter l’utilisation des fonctionnalités, les utilisateurs finaux doivent être conscients de la valeur des fonctionnalités supplémentaires et doivent être en mesure de les utiliser avec très peu de friction.

Voici les approches que j’ai utilisées ces dernières années pour faire bouger l’utilisation des fonctionnalités :

  • Engagement régulier des utilisateurs – Apprendre, informer et éduquer

Un engagement régulier avec vos clients vous permet de comprendre leurs besoins et vous donne l’occasion de présenter des fonctionnalités qui peuvent apporter une valeur ajoutée dans le contexte de votre client.

Dans mes interactions avec les clients, j’ai rencontré des situations où le client essaie de résoudre un problème et n’est pas conscient de la capacité du produit à résoudre le problème, comme des moyens plus simples de configurer le produit pour leur cas d’usage ou la possibilité d’effectuer des types de modélisation spécifiques.

En plus d’informer et d’éduquer, ces interactions régulières peuvent également conduire à de nouveaux cas d’utilisation des capacités existantes.

  • Mises à jour fréquentes des fonctionnalités et accès facile aux informations

La présentation des fonctionnalités dans le cadre d’un atelier aide vos utilisateurs à comprendre l’étendue des capacités. Cependant, il est probable qu’ils ne se souviendront pas de tout ce que vous avez présenté. Par conséquent, il est important de fournir des mises à jour fréquentes. Il peut être difficile d’avoir du temps en face à face avec vos clients sur une base régulière et cela peut devenir écrasant. Il est important d’exploiter différents formats pour promouvoir les fonctionnalités de vos produits.

L’une des approches que j’ai utilisées consiste à partager de brèves vidéos explicatives (2 à 3 minutes) sur une base mensuelle par e-mail et sur les plateformes de médias sociaux. Chaque vidéo se concentre sur un aspect très spécifique du produit. Il peut s’agir d’un ensemble de fonctionnalités d’utilisabilité qui entraînent une réduction du nombre de clics ou d’une fonctionnalité technologique qui leur permet de modéliser une nouvelle technologie. L’objectif est de démontrer et d’informer l’utilisateur de la valeur ajoutée que votre produit peut créer.

La disponibilité de plateformes de synthèse vocale telles que Synthesia facilite la création de vidéos explicatives.

  • Mise en œuvre simplifiée

Une fois que l’utilisateur est convaincu qu’une fonctionnalité ou une capacité particulière peut apporter une valeur ajoutée, il est important de s’assurer qu’il y a très peu de frictions lors de la configuration et de l’exécution de cette capacité. Lorsqu’il s’agit de fonctionnalités complexes, les utilisateurs s’abstiennent souvent de les utiliser car elles sont complexes à configurer. Même si le produit peut disposer d’un ensemble complet de documents de support tels que des guides d’utilisation, des guides techniques, des vidéos explicatives, il est souvent difficile de s’y retrouver dans un volume élevé d’informations.

Plus récemment, j’ai exploré l’utilisation de l’IA générative pour changer la façon dont les utilisateurs interagissent avec les différents supports de produit. Au lieu de rechercher dans des documents individuels, l’utilisateur peut poser des questions spécifiques et obtenir une réponse cohérente, ce qui rend le processus beaucoup plus fluide.

  • Culture interne d’apprentissage continu

En plus de faire référence aux garanties, vos utilisateurs auront parfois besoin d’un soutien supplémentaire de la part des équipes en contact avec les clients. Il est important d’établir une culture interne d’apprentissage continu afin de s’assurer que vos équipes en contact avec votre clientèle peuvent promouvoir et défendre les capacités de votre produit.

Voici quelques-unes des approches que j’ai mises en œuvre :

  • Un webinaire interne mensuel régulier sur un sujet ou une fonctionnalité spécifique.
  • Une plateforme LMS (Learning Management System) interne pour héberger le matériel de formation sur les produits.
  • Un programme d’évaluation interne qui mène à une certification et à d’autres récompenses.

Réflexions finales

À l’avenir, l’IA offre des opportunités pour accroître drastiquement l’utilisation de toutes vos fonctionnalités. Lors du lancement de Microsoft Office 365 Copilot, son vice-président principal, Sumit Chauhan, s’est demandé :

Et si les outils pouvaient apprendre comment vous travaillez, plutôt que l’inverse ?

Cela signifierait que les utilisateurs seraient automatiquement informés des fonctionnalités qui généreraient plus de valeur pour eux et guidés sur la façon d’exploiter les fonctionnalités, ce qui entraînerait une utilisation beaucoup plus élevée de celles-ci !

« Cher client, la vérité sur les projets informatiques… » par Allan Kelly

Le par mopertodans experience sharingLaisser un commentaire

Dans cette lettre personnelle et directe aux clients, Allan Kelly n’y va pas par quatre chemins et explique pourquoi les projets informatiques ne se déroulent pas toujours parfaitement pour toutes les parties concernées.

Je ne suis pas en accord avec tous les constats mais ils ont au moins le mérite d’être clairement énoncés. Quels sont vos propres retours d’expérience sur ce sujet assez controversé ?

Dear Customer: The Truth about IT Projects

https://www.agileconnection.com/article/dear-customer-truth-about-it-projects par Allan Kelly

Cher client,

Je pense qu’il est temps que nous, dans l’industrie informatique, disions la vérité sur la façon dont nous vous facturons, pourquoi nos factures sont parfois un peu plus élevées que ce à quoi vous pourriez vous attendre et pourquoi tant de projets informatiques entraînent des déceptions. La vérité est que lorsque nous commençons un projet informatique, nous ne savons pas combien de temps et d’efforts il faudra pour le mener à bien. Par conséquent, nous ne savons pas combien cela coûtera. Ce n’est peut-être pas un message que vous aimez entendre, d’autant plus que vous êtes absolument certain de savoir ce que vous voulez.

C’est là que réside une autre vérité, que je vais essayer d’exprimer aussi poliment que possible. Vous êtes, après tout, un client, et, vraiment, je ne devrais pas vous offenser. Vous connaissez le dicton « Le client a toujours raison » ? La vérité, c’est que vous ne savez pas ce que vous voulez. Vous le savez peut-être en termes généraux, mais le diable est dans les détails et plus vous essayez de nous donner de détails à l’avance, plus vos désirs sont susceptibles de changer. Chaque fois que vous nous donnez plus de détails, vous offrez plus de prise au hasard.

L’expert en génie logiciel Capers Jones pense que les choses que vous voulez (« exigences », comme nous aimons les appeler) changent de 2% par mois. Personnellement, je suis surpris que ce pourcentage soit si faible !

Relisez ce billet sur VUCA

Pour compliquer les choses, le monde est incertain. Les choses changent, et des entreprises font faillite. Vous vous souvenez d’Enron ? Vous vous souvenez de Lehman Brothers ? Les goûts des clients changent. Vous vous souvenez de Cabbage Patch Kids ? La mode change, les gouvernements changent et les concurrents font de leur mieux pour vous rendre la vie difficile. Donc, vraiment, même si vous savez absolument ce que vous voulez lorsque vous nous parlez pour la première fois, il est peu probable que cela reste statique très longtemps.

J’ai peur de dire qu’il y a des gens dans l’industrie informatique qui vont profiter de cette situation. Ils souriront et seront d’accord avec vous lorsque vous leur direz ce que vous voulez, jusqu’au moment où vous signerez. À partir de ce moment-là, c’est une autre histoire ; Ils savent que les changements sont inévitables et ils prévoient de tirer un profit substantiel des demandes de changement et des ajouts tardifs à vos frais.

plaquer à l'or fin - gold plating deliverablesPendant que j’y suis, il aussi est vrai que « nous plaquons parfois les choses en or ». Vous n’aurez peut-être pas besoin d’un entrepôt de données pour votre magasin en ligne dès le premier jour. Oui, certains de nos ingénieurs aiment faire plus que ce qui est nécessaire, et oui, nous avons un intérêt direct à ajouter des choses afin de pouvoir vous facturer plus.

Il est également vrai que vous pensez tout à fait légitimement aux caractéristiques et aux fonctionnalités que vous aimeriez avoir après que nous ayons commencé. Vous supposez naturellement que quelque chose est « à l’intérieur » du périmètre lorsque nous supposons qu’elle est « à l’extérieur ». Et, dans un esprit d’ouverture, pouvez-vous honnêtement dire que vous n’avez jamais essayé de nous imposer un de ces sous-entendus ? (Ne parlons même pas des bogues pour l’instant, cela ne fait que compliquer l’ensemble.)

Franchement, compte tenu de tout cela, il est touchant que vous ayez autant confiance en la technologie pour livrer des solutions. Mais, quand l’informatique tient ses promesses, elle livre gros. Regardez ce qu’elle a réalisé pour Bill Gates et Larry Page, ou Amazon et FedEx. N’est-il pas intéressant que lorsque l’industrie informatique développe des choses pour elle-même, nous nous retrouvons avec des multimillionnaires. Lorsque nous développons pour d’autres personnes, celles-ci finissent par perdre de l’argent.

Un best seller qui fut une surprise sur Amazon

Comment avons-nous pu vous convaincre de tout cela ? Eh bien, nous emballons joliment ce gâchis disgracieux et essayons de vous le vendre. Pour ce faire, nous devons cacher tous ces désagréments. Nous commençons par un rituel appelé estimation, c’est-à-dire le temps que nous pensons que le travail prendra. Ces « estimations » ne valent guère mieux que des suppositions. Les humains ne sont pas capables d’estimer. Nous le savons depuis au moins la fin des années 70, lorsque Kahneman et Tversky ont décrit le « sophisme de planification » (“planning fallacy”) en 1979 et remporté un prix Nobel. Fondamentalement, les humains sous-estiment constamment la durée du travail et sont trop confiants dans leurs estimations.

Pour aggraver les choses, nous avons une mauvaise habitude dont nous devrions vraiment nous débarrasser. Entre l’estimation du travail et l’exécution du travail, nous changeons généralement l’équipe. L’estimation peut être faite par l’équivalent informatique de Manchester United ou des Mets de New York, mais l’équipe qui fait réellement le travail est plus que probablement un groupe hétéroclite de codeurs, d’analystes et de managers qui ne se sont jamais rencontrés auparavant.

Les données historiques (données sur les estimations, les données réelles, les coûts, etc.) peuvent aider à éclairer la planification, mais la plupart des entreprises ne disposent pas de leurs propres données. Pour ceux qui ont des données, la plupart d’entre elles sont pires qu’inutiles. En fait, Capers Jones suggère que des données historiques inexactes sont un facteur majeur d’échec du projet. Par exemple, les ingénieurs logiciels sont rarement payés pour leurs heures supplémentaires, de sorte que les systèmes de suivi oublient souvent ces heures supplémentaires.  En effet, certaines entreprises interdisent aux employés d’enregistrer plus que leurs heures officielles dans leurs systèmes.

Donc, nous faisons cette supposition (pardon, estimation) et la doublons, nous pourrions même la tripler. Si le nouveau nombre semble trop élevé, nous pourrions le réduire. Une fois que nos ingénieurs ont fini de malaxer les chiffres, nous les donnons aux vendeurs, qui les malaxent un peu plus. Après tout, nous voulons que vous disiez oui au prix le plus élevé que nous puissions obtenir. Cela peut sembler horrible, mais rappelez-vous : nous aurions pu le deviner dès le départ.

S’il vous plaît, ne me tirez pas dessus, je ne suis que le messager.

Nous ne savons pas quel chiffre est « correct », mais pour le rendre acceptable pour vous, nous prétendons qu’il est certain et nous assumons le risque. Nous ne pouvons le faire que si le nombre est suffisamment gras (et, même dans ce cas, nous nous trompons). Si le risque est payant, alors nous obtenons un gros bénéfice. Si ce n’est pas le cas, nous n’obtenons aucun profit et nous risquons de subir des pertes. Si c’est vraiment mauvais, vous n’obtenez rien et nous nous retrouvons devant les tribunaux ou fermons boutique.

L’alternative est que vous preniez le risque – et le bazar – et que vous le fassiez vous-même. Malheureusement, une autre triste vérité est que l’informatique interne est généralement encore pire que les fournisseurs spécialisés.  Pour une entreprise de logiciels, le développement est une compétence de base, de telles entreprises vivent ou meurent en fonction de leur capacité à fournir des logiciels et si elles sont peu performantes, elles cessent leurs activités.  L’évolution élimine les mauvais élèves.

L’informatique d’entreprise, en revanche, détruit rarement une entreprise, bien qu’elle puisse nuire aux bénéfices. En effet, les recherches de Capers Jones suggèrent également que les fournisseurs spécialisés sont généralement meilleurs que les services informatiques des entreprises.

Les vendeurs sont peut-être absents, mais l’ensemble du processus d’estimation est ouvert aux jeux provenant de nombreuses autres sources et pour de nombreuses autres raisons. En fin de compte, si vous décidez de prendre ce risque, vous risquez en fait d’augmenter le risque.

Je sais que cela ressemble à un scénario sans issue. Vous pouvez simplement vous asseoir sur un banc et attendre que Microsoft ou Google résolvent vos problèmes avec une solution packagée, mais vos concurrents resteront-ils immobiles pendant que vous le faites ? Serez-vous toujours à la tête d’une entreprise lorsque Google produira une version gratuite de ce dont vous avez besoin ?

Soit dit en passant, méfiez-vous des charlatans qui vendent des applications prêtes à l’emploi. Une fois que les gens commencent à parler de « personnalisation » ou de « configuration », vous vous engagez sur une pente glissante.  La configuration d’une grande installation SAP ne consiste pas à sélectionner des outils, des options, puis à cocher une case. La configuration de logiciels volumineux est une activité majeure de développement logiciel, peu importe ce qu’on vous a dit.  Les personnes qui entreprennent la configuration peuvent être appelées « consultants », mais ce sont en réalité des développeurs de logiciels spécialisés.

Les problèmes complexes ont souvent de multiples solutions et chemins pour les atteindre.

Il n’y a pas vraiment de solution simple et agréable à tout cela. Nous ne pouvons pas résoudre ce problème pour vous. Nous avons besoin de vous, mais vous devez travailler avec nous. En tant que client, vous devez être prêt à travailler avec nous, le fournisseur, encore et encore afin de réduire les risques.  Gérer les risques de manière opportune et rentable implique des décisions et des compromis au niveau de l’entreprise.  Si vous n’êtes pas là pour vous aider, nous pouvons soit prendre la décision pour vous (en ajoutant le risque que vous ne soyez pas d’accord), soit consacrer votre temps et votre argent à la résoudre.

Vous devez être prêt à accepter et à partager le risque avec nous. Si vous n’êtes pas prêt à prendre le moindre risque, nous vous facturerons beaucoup pour tous les risques que nous prenons.

Le partage du risque a pour effet de réduire le risque, car une fois le risque partagé, vous, le client, êtes motivé à réduire le risque.  L’un des risques majeurs sur les projets informatiques est le manque d’implication des clients. Vous pouvez y contribuer simplement en restant impliqué.

En fin de compte, tous les risques sont les vôtres. Vous êtes le client et vous payez pour ce projet, d’une manière ou d’une autre. S’il ne parvient pas à créer de la valeur, c’est votre entreprise qui en souffrira. Lorsque vous partagez les risques et que vous êtes étroitement impliqué dans ce processus, les risques peuvent être traités immédiatement plutôt que d’être laissés s’envenimer et se développer.

Enfin, vous avez peut-être de grandes ambitions, mais nous devons travailler par petits morceaux. Je sais que cela peut ne pas sembler très sexy, mais la création de logiciels fonctionne mieux lorsqu’elle est petite. Les économies d’échelle n’existent pas. En fait, nous avons des déséconomies d’échelle, nous devons donc travailler par petits morceaux encore et encore. Si vous êtes prêt à accepter ces suggestions, alors appuyons sur le bouton de réinitialisation de notre relation et allons un peu plus loin.

Cordialement, L’industrie de l’informatique

Allan Kelly

 

Allan Kelly

Allan Kelly inspire les équipes numériques à fournir efficacement de meilleurs produits grâce aux technologies agiles. Ces approches permettent de raccourcir les délais, d’améliorer la prévisibilité, d’augmenter la valeur, d’améliorer la qualité et de réduire les risques. La plupart de son travail se fait avec des équipes innovantes, des petites entreprises – y compris des scale-ups ; Il est spécialisé dans le développement de produits et l’ingénierie. Il utilise un mélange de formation expérientielle et de  consultation continue.

Livre sur Amazon

Il est à l’origine des Retrospective Dialogue Sheets, Value Poker et Time-Value Profiles.

Allan est l’auteur de l’essai : « Dear Customer, the truth about IT » et de plusieurs livres, dont : « Xanpan – team centric Agile Software Development » et « Business Patterns for Software Developers ». Il a récemment terminé « Continuous Digital », le livre #NoProjects.

 

Mener un spike technique à l’aide du développement axé sur le comportement par Sam Adesoga

Le par mopertodans agileLaisser un commentaire

Mener un spike technique à l’aide du développement axé sur le comportement

https://samadesoga.me/posts/driving-a-technical-spike-using-bdd/ de Sam Adesoga

Visitez le site SAFe

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 un membre 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.

Y-a-t-il des avantages à avoir un Product Owner sur un projet CRM ? par Mohamed Michael Kazak

Le par mopertodans agile, experience sharingLaisser un commentaire

La réponse courte est OUI !

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écédents billets de Mohamed Michael Kazak

Avez-vous suffisamment de maturité digitale pour réussir votre projet numérique ?

Le par mopertodans forum de discussion, outils et méthodes1 commentaire

Votre entreprise est-elle prête pour ce nouveau projet numérique/digital que l’on vous charge de réussir ?

« 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

  1. un coût maîtrisé,
  2. un délai convenu et
  3. 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.

Sur un plan plus opérationnel, pour la mesurer, le livre La transformation digitale pour tous ! (Michaël Tartar – David Fayon, éditions Pearson, 2022) propose une décomposition en 115 indicateurs de maturité digitale organisés en 6 leviers de digitalisation

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.

La réussite d’un projet numérique dépend de la maturité digitale par Michaël Tartar

Le par mopertodans experience sharing, outils et méthodesLaisser un commentaire

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.

Sur un plan plus opérationnel, pour la mesurer, le livre La transformation digitale pour tous ! (Michaël Tartar – David Fayon, éditions Pearson, 2022) propose une décomposition en 115 indicateurs de maturité digitale organisés en 6 leviers de digitalisation :

6 leviers de digitalisation

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.

 

Chef de Projet : Acuity is the key ! (L’acuité est la clé !) par Olivier Husser

Le par mopertodans best practicesLaisser un commentaire

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.

Observer pour comprendre

(crédit : https://www.linkedin.com/in/fix-dessinateur-9366b9/)

Galilée, Pythagore, Einstein… tous, en leurs temps et selon les moyens techniques à leur disposition, savaient la nécessité d’observer.

Léonard de Vinci préconisait par exemple la méthode Observation, Expérience, Induction, Déduction.

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.

Acuity is the key.

Olivier Husser

Olivier Husser

Chef de projet dans l’industrie du broadcast et de la prestation audiovisuelle depuis 1997.

« Garantir le succès du projet : vers la Project Omniscience » par Cyril Verbrugghe

Le par mopertodans outils et méthodesLaisser un commentaire

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.

Parler aux clients n’est pas une perte de temps pour un développeur.

Le par mopertodans experience sharingLaisser un commentaire

Le concept est rarement contredit. Dans la pratique, cependant, il y a plus de résistance à cette idée que de mise en œuvre réussie…

Talking to customers is not a waste of a developer’s time par Jeff Gothelf

https://jeffgothelf.com/blog/talking-to-customers-is-not-a-waste-of-a-developers-time/

J’ai souvent plaidé en faveur d’une pratique large et inclusive consistant à parler à vos clients. Le concept est rarement contredit. Dans la pratique, cependant, il y a plus de résistance à cette idée que de mise en œuvre réussie de celle-ci. L’argument principal ?

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 ».

DevOps : 3 étapes pour planifier et exécuter un projet réussi

Le par mopertodans best practices, experience sharingLaisser un commentaire

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

https://enterprisersproject.com/article/2023/1/devops-3-steps-plan-execute-successful-project

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.

Comment expliquer DevOps de manière simple ?

Le par mopertodans outils et méthodesLaisser un commentaire

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.

DevOps in plain English Par Carla Rudder

https://enterprisersproject.com/article/2019/8/devops-explained-plain-english

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 DevOps Institute, 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. »

Le bon outil pour le travail

Le par mopertodans experience sharing, pmo et portofolioLaisser un commentaire

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é !

The right tool for the job by Seth Godin

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

10 bonnes pratiques pour réussir vos initiatives de transformation numérique

Le par mopertodans best practices, experience sharing, pmo et portofolioLaisser un commentaire

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 !

Billet de Donald : Digital transformation – 10 reasons your IT initiatives fail

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.

Voici un modèle de cahier des charges pour votre logiciel PPM élaboré par Virage Group

Le par mopertodans pmo et portofolioLaisser un commentaire

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 !

𝗖𝗮𝗵𝗶𝗲𝗿 𝗱𝗲𝘀 𝗰𝗵𝗮𝗿𝗴𝗲𝘀 𝗹𝗼𝗴𝗶𝗰𝗶𝗲𝗹 𝗣𝗣𝗠: Téléchargez cette fiche pratique de Virage Group en format PDF.

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

5 conseils pour réduire les maux de tête liés à l’outil de planification

Le par mopertodans outils et méthodes, pmo et portofolioLaisser un commentaire

Les outils de planification vous aident et cependant, comme toute autre technologie, ils peuvent vous être défavorables. Déjouez ces principaux pièges !

5 Tips to Reduce Scheduling Tool Headaches

http://www.bonniebiafore.com/5-tips-to-reduce-scheduling-tool-headaches/ par Bonnie Biafore

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

faire monter en puissance, développerLes 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

J’ai le plaisir d’accueillir un nouveau partenaire du blog DantotsuPM : VIRAGE Group !

Le par mopertodans pmo et portofolioLaisser un commentaire

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

Le rôle et les compétences d’un testeur dans une équipe agile par Fidaa Berrjeb

Le par mopertodans agile, best practices, experience sharingLaisser un commentaire

Voici le troisième billet de Fidaa pour préciser le rôle du testeur dans les projets Agiles.

Les 2 premiers billets Fidaa Berrjeb que vous souhaiterez peut-être relire :
  1. Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.

    « La bonne compréhension et l’utilisation des valeurs du manifeste agile et du manifeste du test vous garantit être un bon testeur agile »

  2. Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?

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.

La conduite de projet de création d’apps dans les solutions No-Code et Low-Code pour les mobiles par Bruno Doucende

Le par mopertodans outils et méthodes, pointeurs utilesLaisser un commentaire

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.

Téléchargez gratuitement ce livre blanc
Voici le lien de la page de téléchargement : https://www.synertic.fr/livre-blanc-les-plateformes-no-code-low-code-au-service-des-apps-mobiles/

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.

 

Vous êtes-vous déjà demandé dans votre projet ou organisation : Qu’est-ce que l’open source ?

Le par mopertodans outils et méthodesLaisser un commentaire

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.