Susanne Kaiser - Optimizing for a fast flow of value with adaptive, socio-technical systems

[00:00:00] Oh, je suppose que c'est le signe. Les lumières s'allument. Bonjour à tous. J'espère que vous avez apprécié votre déjeuner. très délicieux d'ailleurs. J'ai mangé trop de sucreries. Alors, euh, bienvenue à cette conférence sur l'optimisation du flux rapide de valeur avec des systèmes socio-techniques adaptatifs. Et je dois vous donner un petit avertissement.
[00:00:28] Alors, euh, j'ai tendance à couvrir beaucoup de contenu pendant mes présentations, mais je fournirai, euh, un lien vers mon jeu de diapositives à la fin de ma présentation. Et deuxièmement, je suis également en train d'écrire un livre sur ce sujet, donc au cas où vous seriez intéressé à en explorer davantage.
[00:00:50] Alors, lorsque nous construisons des systèmes en général, nous sommes confrontés au défi de construire la bonne chose et de bien construire la chose. Et construire la bonne chose qui aborde l'efficacité et répond à des questions telles que : dans quelle mesure notre solution est-elle alignée sur les besoins de nos utilisateurs ? Ou, euh, créons-nous de la valeur pour nos clients ? Avons-nous compris le problème et partageons-nous une compréhension commune ?
[00:01:13] Et construire la chose correctement d'autre part, cela se concentre sur l'efficacité, par exemple, l'efficacité des pratiques d'ingénierie, et il est également non seulement crucial de générer de la valeur pour nos clients, mais aussi d'être capable de livrer cette valeur à nos clients, et à quelle vitesse pouvons-nous livrer des changements et à quelle vitesse et facilité pouvons-nous changer et nous adapter aux nouvelles circonstances.
[00:01:35] Et l'un ne va pas sans l'autre, mais comme l'a déclaré le Dr Russell Ackoff, l'un des pionniers du mouvement de la pensée systémique, faire la mauvaise chose correctement n'est pas aussi bon que de faire la bonne chose mal, ou comme le résume John Cutler, de la merde livrée rapidement reste de la merde. Et pourtant, à moins que vous n'en tiriez des leçons et que vous puissiez agir sur cet apprentissage.
[00:02:00] Donc, pour bien construire la bonne chose, nous devons construire des systèmes socio-techniques adaptatifs qui sont optimisés pour un flux rapide de valeur et un retour d'information rapide et constant. Et une approche que j'aimerais partager avec vous aujourd'hui, qui peut aider à construire, concevoir, faire évoluer des systèmes socio-techniques adaptatifs, est de combiner la cartographie de Wardley, la conception axée sur le domaine et les topologies d'équipe comme architecture pour le flux.
[00:02:26] Et nous pouvons commencer par créer une carte de Wardley qui visualise le paysage commercial dans lequel une organisation opère et est en concurrence. Et, euh, une carte de Wardley elle-même fait partie de la cartographie de Wardley, un cadre de stratégie commerciale inventé par Simon Wardley. Alors, qui d'entre vous a déjà entendu parler de la cartographie de Wardley ? Oh oui, pas mal de mains, je dirais 75 %. Euh, d'habitude, quand j'ai commencé à donner des conférences sur la cartographie de Wardley, peut-être deux, trois mains étaient levées. Ainsi, une carte Wardley en soi, qui fait partie de la cartographie Wardley, met l'accent, euh, sur le fait de commencer par les utilisateurs d'abord.
[00:03:06] Et partir de la perspective de l'utilisateur, cela correspond très bien à l'objectif de construire la bonne chose. Clayton Christensen, l'inventeur du dilemme de l'innovation et aussi l'inventeur de la théorie du 'job to be done', a déclaré que les gens achètent des produits et des services pour accomplir un travail. Donc, afin d'aider les utilisateurs à accomplir leur tâche, nous devons savoir qui sont nos utilisateurs et quelles tâches ils veulent accomplir. Nous devons donc identifier, euh, les résultats souhaités comme étant les besoins des utilisateurs que nos utilisateurs essaient d'atteindre lorsqu'ils accomplissent une tâche. Et les tâches à accomplir et les besoins des utilisateurs, ils décrivent l'espace problème, et resteront les mêmes quelle que soit la solution et l'espace de solution que nous fournissons.
[00:04:04] Alors, prenons l'exemple d'une solution d'école en ligne pour les étudiants juniors. Et les utilisateurs de la solution d'école en ligne sont généralement des enseignants et des étudiants. Et gardons les choses simples et concentrons-nous uniquement sur les enseignants. Et, euh, le travail fonctionnel essentiel des enseignants est de, euh, faciliter l'apprentissage à distance dans un contexte d'école en ligne. Et pour accomplir ce travail, les enseignants doivent préparer du matériel pédagogique, ou, euh, évaluer la compréhension des élèves avec des tests d'évaluation, des quiz, et ainsi de suite. Ou, euh, suivre les progrès des élèves au fil du temps, euh, faciliter la communication avec les élèves et également assurer et configurer un accès sécurisé à la, euh, plateforme d'apprentissage. Par exemple, via des mécanismes d'inscription et de connexion.
[00:05:00] Et lorsque nous passons à l'espace des solutions, euh, ces utilisateurs sont directement ou indirectement satisfaits par une chaîne de composants qui génèrent de la valeur pour nos utilisateurs en satisfaisant nos besoins d'utilisateurs. Et c'est là que nous pouvons intégrer la chaîne de valeur, euh, l'axe Y d'une carte Wardley, où les utilisateurs et les besoins des utilisateurs deviennent alors l'ancre de notre carte.
[00:05:28] Et dériver cette chaîne de valeur nous aide à nous assurer que nous abordons le bon problème et que nous créons une valeur très étroitement alignée sur les besoins de nos utilisateurs. Et cette chaîne de valeur montre comment différents composants se connectent afin de générer de la valeur et visualise également les dépendances de ces composants dans notre chaîne de valeur. Et nous pouvons commencer à créer cette chaîne de valeur, nous pouvons commencer très simplement et itérer plus tard.
[00:05:56] Ainsi, dans l'exemple de la solution d'école en ligne, les enseignants interagissent directement avec un composant d'école en ligne, et c'est le plus précieux, le plus visible pour les enseignants, et il est situé en haut de notre chaîne de valeur. Et ce composant d'école en ligne dépend d'autres composants, par exemple, il dépend de composants d'infrastructure fondamentaux, et qui sont moins visibles pour les enseignants, moins visibles pour les utilisateurs, et sont positionnés ou résident plus bas en bas de notre chaîne de valeur.
[00:06:34] Et les composants de notre chaîne de valeur sont généralement cartographiés le long de l'axe d'évolution sur l'axe X de notre carte Wardley, allant de gauche à droite. Ainsi, par exemple, à gauche avec la Genèse et de toutes nouvelles choses, puis du sur-mesure, puis des produits et de la location tels que des produits prêts à l'emploi ou des solutions logicielles open source, et des produits de base et des services publics à droite. Et chaque étape de l'évolution vient avec des caractéristiques différentes. Ainsi, vers le spectre gauche de notre carte Wardley, euh, les composants changent beaucoup plus fréquemment que les composants du spectre droit de notre carte Wardley vers la marchandise et l'utilité.
[00:07:13] Ainsi, à gauche, vers la Genèse, nous avons affaire à un niveau élevé d'incertitudes, d'inconnus inconnus et à un marché indéfini, mal compris. Alors que sur le spectre droit, les composants deviennent plus standardisés, stables, connus, répandus, industrialisés et les marchés sont généralement bien définis et matures.
[00:07:36] Et en général, la carte aquatique nous aide à créer une compréhension commune de notre paysage commercial, euh, et, euh, pendant que nous créons cette carte aquatique ensemble en groupe et essayons également, euh, également remettre en question notre propre hypothèse de notre propre paysage commercial. Et cela aide à identifier les domaines où investir, où innover, ce qu'il faut faire évoluer ou externaliser pour obtenir un avantage concurrentiel.
[00:08:02] Mais nous pouvons également utiliser la carte de Wardley, euh, pour évaluer notre flux de changement actuel. Donc, pour passer de la construction de la bonne chose à la construction de la chose correctement, et pour construire cette chose correctement, nous devons optimiser pour un flux rapide de changements. Et à cette fin, nous pouvons suivre les dépendances dans notre chaîne de valeur et analyser comment un changement traverserait notre système. Par exemple, lors de l'introduction d'un changement fonctionnel, nous pouvons analyser quels composants de notre chaîne de valeur vont être affectés en suivant les dépendances de notre chaîne de valeur.
[00:08:45] Et puis nous pouvons aussi nous poser des questions : quelle équipe possède ces composants impliqués dans ce changement ? Et comment ces équipes dépendent-elles les unes des autres et ont-elles besoin de communiquer et de se coordonner pour rendre ce changement efficace ?
[00:09:03] Donc, euh, en évaluant comment un changement traverserait notre système, nous pouvons également révéler des blocages potentiels au flux. Par exemple, en analysant ce qui empêche notre flux de changer, euh, le long de la chaîne de valeur sous différentes perspectives. Nous pouvons donc, par exemple, considérer notre perspective d'architecture. Donc, du point de vue de l'architecture, nous devons analyser comment les parties sont couplées, euh, comment les parties sont couplées ensemble. Donc, dans notre exemple de l'école en ligne, euh, le composant d'école en ligne lui-même a évolué au fil du temps et est devenu une grosse boule de boue monolithique avec un modèle désordonné et aucune frontière modulaire claire.
[00:09:50] Et, euh, ce qui conduit alors à un couplage de changement étroit, et avec un couplage de changement étroit, euh, cela affecte ou entrave notre flux de changement, ainsi les changements dans une partie de notre système, cela peut avoir des effets secondaires imprévisibles sur d'autres parties du système, ce qui augmente alors le risque de changements cassants ou, euh, et aussi d'introduire des retards.
[00:10:17] La prochaine perspective que nous pouvons apporter est la, euh, perspective de la propriété d'équipe. Ainsi, un modèle désordonné avec des frontières floues et imprécises, euh, rend difficile l'établissement de frontières de propriété claires, ce qui entraîne un manque de propriété ou une propriété claire, ce qui diminue la responsabilité. Et qui potentiellement mène aussi au syndrome ce n'est pas mon travail. Et cela peut également entraîner des retards de décision et entraver notre flux rapide de changements.
[00:10:52] Et avec, euh, une logique métier entremêlée dans un modèle désordonné sans modularité claire, cela augmente également notre effort mental pour comprendre un morceau de code, y compris également la saisie ou la compréhension des dépendances dans un grand système très imbriqué, très connecté.
[00:11:18] Et lorsque les équipes possèdent trop de parties interdépendantes ou trop grandes, ou trop de parties dépendantes, des parties couplées, euh, la charge cognitive de leur équipe peut être dépassée, et si la charge cognitive de l'équipe est largement dépassée, cela peut également devenir un goulot d'étranglement de livraison.
[00:11:38] Et nous devons également analyser, euh, où se trouvent nos dépendances d'équipe, c'est-à-dire où les équipes dépendent des activités et des tâches d'autres équipes, euh, pour mener à bien leur travail. Ainsi, par exemple, les équipes doivent-elles transférer à plusieurs reprises le travail à d'autres équipes à un stade ultérieur du flux pour que le travail soit terminé ? Ainsi, les équipes de notre solution d'école en ligne sont actuellement organisées en équipes fonctionnelles en silo.
[00:12:08] Donc, implémenter et publier des modifications du front-end au back-end nécessite de transférer les modifications entre l'interface utilisateur, le back-end et les équipes d'infrastructure. Ainsi, le transfert lui-même nécessite un haut niveau d'efforts de communication et de coordination entre plusieurs équipes, ce qui affecte et entrave également notre flux de changements.
[00:12:30] Et si les équipes manquent de capacités et ont besoin de faire venir des personnes de l'extérieur avec une expertise particulière afin qu'elles fassent quelque chose pour que notre travail soit terminé, cela peut également entraver le flux de changement. Et surtout lorsque ces personnes ne sont pas disponibles quand nous en avons besoin.
[00:12:54] Et aussi les équipes dépendent des décisions d'autres, par exemple de la direction, ou, euh, ou si nous devons attendre une approbation, cela peut aussi, euh, donc cela peut aussi nous empêcher de progresser et de terminer notre travail. Donc, et toutes les dépendances qui nécessitent un certain niveau de communication et d'efforts de coordination et qui augmentent également les probabilités de retards. Et particulièrement lorsque les personnes dont nous avons besoin ne sont pas disponibles, ou lorsque les ou lorsque d'autres équipes sur lesquelles nous comptons ne peuvent pas répondre aux demandes qui leur sont faites, alors cette autre équipe devient une contrainte, et alors cela ralentit également la performance globale.
[00:13:38] Donc, si les équipes doivent interagir avec de nombreuses autres équipes pour accomplir leur travail, cela ralentit notre flux de valeur.
[00:13:50] Un autre aspect, euh, que nous devons prendre en compte pour bien construire les choses est d'évaluer nos lacunes en matière d'efficacité. Donc, si le stade d'évolution des composants que nous utilisons en interne dans notre organisation diffère de celui de composants équivalents disponibles sur le marché avec une évolution supérieure, cela pourrait indiquer une lacune en matière d'efficacité. Ainsi, par exemple, euh, construisons-nous sur mesure des composants qui n'appartiennent pas à notre domaine central alors que des équivalents pourraient être disponibles sous forme de produits prêts à l'emploi ou d'utilitaires ? Ou utilisons-nous des composants dans notre organisation comme produits prêts à l'emploi, mais des équivalents sont disponibles en tant que marchandise ou utilité, par exemple, l'exemple de l'infrastructure sur site par rapport à l'utilisation de services hébergés dans le cloud ? Euh, cela pourrait indiquer que nous pourrions être en retard en termes d'efficacité, et surtout cela devient important lorsque nos concurrents construisent leurs produits sur des chaînes de valeur qui utilisent des composants mieux évolués que les nôtres.
[00:15:04] Ainsi, après avoir identifié les obstacles au flux et les inefficacités, une approche consiste à exploiter la modularité avec une forte cohésion fonctionnelle et un couplage lâche en concevant un système modulaire, bien encapsulé et faiblement couplé.
[00:15:18] Et nous pouvons utiliser la carte de Wardley comme un outil visuel qui nous guide à travers l'optimisation. Et pour optimiser le flux de changement, nous devons d'abord analyser ce qui créera de la valeur et ce qui entraînera le changement dans notre organisation. Cela nécessite donc d'identifier les changements les plus importants dans notre système, où se produisent les changements les plus importants, les flux de changements. Et, euh, les besoins des utilisateurs de notre carte de Wardley, ils représentent de bons candidats pour des flux de changements orientés activité ou tâche, axés sur le client. Nous devons donc structurer nos équipes dans ce système et dans l'interaction autour du flux de changements axé sur le client, en assurant un flux de valeur rapide là où cela compte le plus.
[00:16:05] Et l'utilisateur et les besoins de l'utilisateur ne représentent pas seulement l'ancre de notre carte de Wardley, mais représentent également le domaine du problème.
[00:16:13] Et c'est là que nous pouvons introduire la conception axée sur le domaine. Donc, la conception axée sur le domaine nous aide à acquérir une compréhension partagée de notre domaine problématique et nous aide à partitionner notre domaine problématique en parties plus petites, les sous-domaines.
[00:16:27] Mais tous les sous-domaines ne sont pas égaux, certains sont plus précieux pour l'entreprise que d'autres. Nous avons différents types de sous-domaines. Ainsi, euh, le domaine principal, qui est la partie essentielle de notre organisation procurant un avantage concurrentiel, est un sous-domaine dans lequel nous devons investir stratégiquement le plus, et c'est celui que nous devons construire en interne.
[00:16:49] Et les sous-domaines de soutien, ils aident à soutenir le domaine principal et ils complètent l'offre du domaine principal. Donc, ils ne fournissent pas d'avantage concurrentiel, mais sont nécessaires pour que l'organisation réussisse. Et, euh, et ils sont généralement prévalents dans d'autres solutions concurrentielles également.
[00:17:08] Donc, si possible, nous devrions chercher à, euh, acheter des produits prêts à l'emploi ou à utiliser des solutions logicielles open source pour les sous-domaines de support, et si ce n'est pas possible, si nous, euh, devons construire sur mesure les sous-domaines de support, nous devrions envisager, euh, de ne pas investir massivement dans cette partie du système car elle ne procure pas d'avantage concurrentiel.
[00:17:29] Et les sous-domaines génériques, ce sont des sous-domaines que de nombreux systèmes d'entreprise possèdent, non seulement nos concurrents, mais, euh, ce qui est répandu dans tout grand système d'entreprise ou système d'entreprise en ligne. Donc, ils sont essentiels, ils n'apportent aucun avantage concurrentiel, mais les entreprises ne peuvent pas fonctionner sans eux. Ainsi, l'achat ou, euh, l'utilisation de produits prêts à l'emploi ou l'externalisation auprès de fournisseurs de services publics, cela devrait être appliqué aux sous-domaines génériques. Par exemple, pour l'authentification et l'enregistrement, c'est un bon candidat pour les sous-domaines génériques.
[00:18:04] Ainsi, euh, en général, les types de sous-domaines, ils nous aident, euh, à concentrer nos investissements stratégiques et nous soutiennent dans les décisions de construire, d'acheter et d'externaliser.
[00:18:18] Nous avons donc découvert nos types de sous-domaines et nous comprenons où nous devrions concentrer nos efforts de développement. Mais quand nous passons à l'espace des solutions, euh, la solution de nos sous-domaines est actuellement résolue ou actuellement toute mélangée dans une seule grosse boule de boue monolithique avec un modèle désordonné et aucune frontière claire, des frontières modulaires. Ce qui entraîne alors un couplage de changement étroit, comme nous l'avons dit précédemment, un manque de propriété claire, une charge cognitive élevée de l'équipe et une concentration inefficace des efforts de développement sur des parties non différenciatrices qui, au total, bloquent notre flux de valeur.
[00:19:01] Pour atténuer les blocages de flux et les inefficacités, une approche consiste à tirer parti de la modularité avec une forte cohésion fonctionnelle et un couplage lâche en concevant un système modulaire, bien encapsulé et faiblement couplé.
[00:19:18] Et c'est là que, euh, nous devons décomposer notre composant d'école en ligne en composants modulaires, et cela nous amène aux, euh, contextes bornés de la conception axée sur le domaine.
[00:19:33] Un contexte délimité regroupe en général des comportements connexes, regroupe des comportements, euh, la logique de domaine ensemble. Et un contexte délimité définit où un seul modèle de domaine peut être appliqué qui encapsule une logique métier particulière d'une partie spécifique de notre système. pour exploiter la modularité avec une forte cohésion fonctionnelle et un couplage lâche en concevant un système modulaire, bien encapsulé et faiblement couplé. Et c'est là que nous devons décomposer notre composant d'école en ligne en composants modulaires.
[00:19:24] Et cela nous amène au contexte délimité de la conception axée sur le domaine. Un contexte délimité en général regroupe des comportements liés, regroupe un comportement, une logique de domaine ensemble. Et le contexte délimité définit où un seul modèle de domaine peut être appliqué et qui encapsule la logique métier particulière d'une partie spécifique de notre système. Et un contexte délimité lui-même ou les contextes délimités en général, ils appliquent une forte cohésion et une modularité, et ils indiquent de bons thèmes spécifiques à la logique de domaine pour diviser notre système en plus petites parties. Euh, et ils sont alors bien encapsulés et modulaires.
[00:20:11] Et ils servent également très bien de limites de propriété, et nous y reviendrons lorsque nous aborderons la perspective de l'équipe.
[00:20:20] Ainsi, pour concevoir des contextes délimités et des modèles de domaine, cela implique généralement une collaboration étroite entre les experts du domaine et les équipes de développement afin d'acquérir une compréhension partagée de notre domaine problématique. Et il existe plusieurs techniques, par exemple, pour concevoir ces modèles de domaine et ce contexte délimité, par exemple, l'event storming, le domain storytelling. Cartographie d'exemples, cartographie d d'histoires d'utilisateurs et plus encore. Et l'inventeur de l'event storming donne également une conférence, Alberto Brandolini aujourd'hui, pas sur l'event storming, mais il a inventé la technique de modélisation de l'event storming.
[00:20:56] Euh, maintenant, à ce stade, avec les types de sous-domaines découverts et le contexte délimité modulaire, nous pouvons alors mieux cibler notre investissement stratégique. Et nous pouvons alors concentrer nos principaux efforts de développement autour de nos contextes délimités liés au domaine principal qui offrent un avantage concurrentiel et afin de les construire également en interne.
[00:21:24] Et pour les non-différenciateurs, euh, nous devons donc évaluer si nous pouvons les exploiter avec les solutions existantes sur le marché. Ainsi, le contexte délimité générique lié au sous-domaine, par exemple, de l'identité et de l'accès, ne procure pas d'avantage concurrentiel, mais il implique des processus et des fonctionnalités communs, standardisés et largement répandus qui nécessitent peu ou pas de variation ou de personnalisation. Nous pouvons donc y exploiter les solutions existantes prêtes à l'emploi, open source ou de services publics disponibles sur le marché.
[00:22:03] Et pour le contexte délimité lié au sous-domaine de support, la décision de construire ou d'acheter est un peu plus nuancée. Ils ne sont donc pas essentiels, ils ne procurent aucun avantage concurrentiel, mais ils jouent un rôle important dans le soutien du contexte délimité lié au domaine principal. Donc, peut-être pour, dans notre exemple, pour notre contexte délimité lié au sous-domaine de support, il pourrait exister des produits sur le marché, mais l'analyse actuelle, euh, a montré qu'ils étaient insuffisants pour résoudre nos besoins. Et ils nécessitent donc une grande quantité, un niveau plus élevé de personnalisation, et donc la construction d'une solution personnalisée peut être justifiée dans ces cas, plutôt lorsque les coûts de développement et de maintenance sont inférieurs aux coûts d'intégration avec les produits existants, ce qui nécessite, par exemple, une quantité importante d'ajustements.
[00:23:04] Le prochain aspect à considérer est, euh, si nous pouvons exploiter des composants mieux développés que nous utilisons actuellement dans notre organisation et qui contribueraient à améliorer notre efficacité.
[00:23:18] Dans notre exemple, nous pourrions décider de migrer nos composants d'infrastructure sur site vers des services hébergés dans le cloud qui sont disponibles en tant que commodités afin de combler nos lacunes d'efficacité identifiées.
[00:23:34] Jusqu'à présent, nous avons débloqué certains obstacles au flux qui sont liés à l'architecture logicielle et aux lacunes d'efficacité. Et mais nous devons également considérer l'aspect socio-technique de notre système et où nous devons alors intégrer la perspective de l'équipe et la propriété de l'équipe et l'interaction entre plusieurs équipes. Et c'est là que les topologies d'équipe peuvent nous aider. Alors, qui a lu le livre de l'équipe ou a entendu parler des topologies d'équipe auparavant ? De Michael Skelton et M. Skelton Manuel Pash, oui. Donc quelques-uns, je suppose que beaucoup de mains se levaient, c'est génial. Ainsi, les topologies d'équipe, euh, fournissent des types d'équipe bien définis et des types d'interaction bien définis et des modes d'interaction. Un type d'équipe est celui des équipes autonomes interfonctionnelles qui sont alignées sur un flux de travail continu se concentrant sur un flux rapide de changements. Mais pour pouvoir produire un flux constant de livraison de fonctionnalités, pour pouvoir se concentrer sur un flux rapide de changements, les équipes streamline, elles ont besoin de support, ont besoin d'obtenir le support d'autres équipes, par exemple, des équipes de plateforme.
[00:24:41] Et les équipes de plateforme, elles soutiennent les équipes de développement en livrant leur travail et elles sont responsables des plateformes que les équipes de développement peuvent facilement consommer.
[00:24:51] Et la plateforme peut varier dans son niveau d'abstraction, donc à un niveau inférieur, une plateforme peut abstraire l'infrastructure, le réseautage, les capacités transversales, et à un niveau supérieur, une plateforme peut également abstraire un système de conception, une plateforme de données, et ainsi de suite. Ainsi, les équipes de plateforme fournissent des services et des outils internes en libre-service pour l'utilisation de la plateforme dont elles sont responsables.
[00:25:17] Ou les équipes d'activation peuvent obtenir le soutien de, pardon, les équipes de ligne de production peuvent obtenir le soutien de l'équipe d'activation, qui travaille ensuite à faciliter les équipes de ligne de production en tant que coachs et mentors internes, et elles aident à identifier et à acquérir des capacités désordonnées, à améliorer les compétences des équipes de ligne de production.
[00:25:38] Ou les équipes streamline peuvent obtenir le soutien des équipes de sous-systèmes compliqués en tant que type d'équipe optionnel, et elles soutiennent les équipes streamline sur un sous-système compliqué particulier qui nécessite des connaissances très spécialisées.
[00:25:55] Et tous ces types d'équipes visent à augmenter l'autonomie et à réduire la charge cognitive des équipes streamline afin que l'objectif principal soit de permettre un flux rapide de changements à la fin.
[00:26:11] Mais organiser ces équipes en ces types d'équipes ne suffit pas pour devenir efficace, donc la manière dont ces équipes interagissent entre elles et quand changer et faire évoluer le mode d'interaction entre les équipes est également très important pour l'efficacité organisationnelle. Donc et là, la topologie d'équipe offre trois modes d'interaction différents, donc avec la collaboration. Les équipes travaillent très étroitement ensemble sur une période de temps limitée, et elles sont adaptées à la découverte rapide et à l'innovation, par exemple, lors de l'exploration de nouvelles technologies ensemble. Et euh, mais la collaboration elle-même est censée être de courte durée. L'accès en tant que service convient bien lorsqu'une équipe a besoin d'utiliser une bibliothèque de code ou un composant, euh, une API ou une plateforme qui peut être efficacement fournie par une autre équipe en tant que service. Et cela fonctionne mieux là où une livraison prévisible est nécessaire. La facilitation, ce mode d'interaction, euh, entre en jeu lorsqu'une équipe bénéficierait de l'aide active d'une autre équipe et ce mode d'interaction est très typique des équipes d'activation.
[00:27:21] Donc, pour revenir à notre carte, euh, la prochaine étape serait alors, lorsque nous passons à cette perspective d'équipe, la prochaine étape serait de trouver des limites d'équipe appropriées qui sont alignées sur des flux continus de changements orientés client. Et comme je l'ai mentionné précédemment, les contextes délimités servent de frontières de propriété très bien définies, ce qui en fait des candidats appropriés, euh, en plus de diviser un système en plus petites parties, mais ils peuvent également très bien servir de bonnes frontières de propriété bien définies pour les équipes rationalisées.
[00:27:58] Donc, pour revenir à nos obstacles au flux, pour atténuer ou réduire nos obstacles au flux précédemment identifiés qui sont liés à la propriété d'équipe, nous devons optimiser notre charge cognitive d'équipe. Et pour optimiser notre charge cognitive d'équipe, nous devons limiter le nombre, la taille, la complexité du système logiciel avec lequel une seule équipe doit travailler. Et cela nous ramène aux étapes d'évolution de, euh, d'une carte d'eau. Ainsi, selon les caractéristiques que j'ai présentées au début, les étapes d'évolution, euh, plus un contexte délimité ou un composant est situé à gauche, par exemple, vers la Genèse et la construction sur mesure, euh, plus le niveau d'incertitude est élevé. Et euh, et ce qui alors, plus le niveau d'incertitude est élevé, nécessite alors des pratiques qui se concentrent davantage sur l'exploration et la découverte. Et les composants de la Genèse ont tendance à changer beaucoup plus fréquemment que les composants des produits de base à droite. Pour les composants de base, nous pouvons nous appuyer sur les meilleures pratiques offrant une voie claire vers l'action. Et si chaque étape d'évolution elle-même ajuste différentes pratiques pour le chemin d'action lié allant de la meilleure, bonne, émergente et d'autres pratiques.
[00:29:18] Et comme heuristique, plus le chemin vers l'action est flou, plus le niveau de charge cognitive de l'équipe pourrait être élevé. Et cela signifie qu'une seule équipe pourrait prendre en charge des contextes délimités plus nombreux ou plus grands résidant à droite, sur les produits de base et les utilitaires, puis résidant à gauche dans Genesis.
[00:29:41] Un autre aspect de l'optimisation de la charge cognitive d'équipe est d'établir des limites de responsabilité claires.
[00:29:49] Pour des limites de responsabilité claires, nous devons attribuer chaque contexte délimité à une seule équipe et ne pas partager les contextes délimités entre plusieurs équipes, car cela diffuserait la propriété des équipes et mènerait également au syndrome "ce n'est pas mon travail". Cependant, une équipe peut posséder plusieurs contextes délimités, et l'inverse est possible.
[00:30:11] Et pour pouvoir se concentrer sur un flux rapide de changements, les équipes de rationalisation, euh, s'appuient sur d'autres équipes, comme je l'ai mentionné précédemment, pour les soutenir dans la livraison du travail afin que les équipes de rationalisation puissent se concentrer sur leur flux rapide de changements. Et euh, donc ils s'appuient, par exemple, sur des équipes de plateforme fournissant des plateformes que les équipes rationalisées peuvent ensuite facilement consommer et pour réduire leur charge cognitive. Et cela nécessite d'identifier des services qui supportent un flux de changement fiable et peuvent être facilement consommés par l'équipe rationalisée offrant des capacités de libre-service. Donc, dans notre exemple, euh, le contexte délimité lié aux composants d'infrastructure de notre carte résidant dans la commodité et l'utilité, cela pourrait, cela pourrait être de bons candidats qui conviennent à la formation d'une plateforme qui peut être efficacement fournie en tant que service par les équipes de plateforme. Et fournir des capacités en libre-service qui visent à rendre les équipes interfonctionnelles qui consomment ces services,
[00:31:21] euh, cela les rend autonomes, ce qui élimine les dépendances bloquantes de transfert.
[00:31:29] Et également en diminuant, euh, la quantité élevée correspondante d'efforts de communication et de coordination entre les équipes.
[00:31:43] Et quand, euh, quand on parle des dépendances d'équipe et de la propriété, nous pouvons également créer une autre carte ou une autre chaîne de valeur. Nous pouvons donc maintenant passer de l'approche actuelle où nous avons abordé la vue produit externe de nos utilisateurs externes, nos clients, nos enseignants. Et maintenant, nous pouvons également créer une carte pour nos produits internes et considérer notre plateforme comme des produits internes que nos équipes internes consomment et utilisent. Donc, et en passant à la vue produit interne, nous pouvons piloter une chaîne de valeur de plateforme. Cela fait alors des équipes streamline les utilisateurs des services que l'équipe plateforme fournit. Et les équipes streamline, elles ont aussi des besoins utilisateurs, donc elles ont les besoins utilisateurs de provisionnement et de gestion d'infrastructure, elles ont les besoins utilisateurs de construction et de test, de publication et de déploiement, d'exploitation et de surveillance, euh, euh, de services ou de contextes délimités dont elles sont responsables. Et pour satisfaire les besoins des utilisateurs des équipes de rationalisation, euh, les équipes de plateforme peuvent fournir une variété de plateformes que les équipes de rationalisation peuvent ensuite facilement consommer en tant que services X.
[00:32:59] Par exemple, euh, euh, les équipes de ligne de production ont besoin d'une plateforme d'infrastructure qui leur permet de provisionner et de gérer l'infrastructure à la demande et aussi s'étendant des composants de calcul, des composants de sécurité de stockage et de réseau qui peuvent être fournis par les équipes de plateforme en tant que service X. Et en général, la plateforme peut commencer petite, elle n'a pas besoin d'être une plateforme entièrement numérique au début. Cela peut commencer par de la documentation ou des normes, des meilleures pratiques, des modèles et peut évoluer plus tard vers une plateforme numérique avec des API en libre-service et des outils.
[00:33:41] Et la plateforme de construction et de déploiement aide ensuite les équipes streamline à construire, tester, déployer et publier leurs services ou leurs contextes délimités. Et peut également être construit sur divers autres composants tels que le système de contrôle de version, le serveur de build, le pipeline CI/CD, l'automatisation des tests, etc.
[00:34:01] Et une plateforme, comme je l'ai dit précédemment, peut varier dans son niveau d'abstraction. Et à un niveau supérieur, une plateforme peut également refléter un système de conception, afin, par exemple, d'obtenir un langage visuel cohérent et bien défini à grande échelle. Et l'équipe de plateforme possédant ce système de conception, elle peut, par exemple, fournir des guides de style, des bibliothèques de widgets, des principes de conception en tant que service.
[00:34:31] Et pour opérer et surveiller les services, les équipes de ligne de production pourraient avoir besoin de tableaux de bord, de mécanismes d'alerte, euh, de gestion des incidents, de capacités d'observabilité, de gestion des lacunes et ainsi de suite, donc ces capacités peuvent être fournies par une équipe de plateforme en tant que plateforme d'exploitation et de surveillance.
[00:34:54] Un autre aspect que nous devons considérer pour optimiser le flux est d'identifier et de combler les lacunes de capacités, et c'est là que les équipes d'activation peuvent intervenir.
[00:35:04] Ainsi, les équipes interfonctionnelles et rationalisées doivent couvrir un large éventail de capacités telles que la conception et l'architecture logicielles, la sécurité des applications, l'expérience utilisateur et l'accessibilité, les tests d'assurance qualité et bien sûr le développement logiciel. Et c'est beaucoup à couvrir et où les spécialistes d'une équipe d'activation peuvent alors également être sollicités à la demande et améliorer les compétences des équipes streamline pour les rendre autonomes en ce qui concerne leurs niveaux de compétence à la fin. Mais aussi, les équipes d'activation peuvent faciliter les équipes de plateforme, elles peuvent également améliorer les compétences des équipes de plateforme, par exemple, en les coachant sur ce qui est important pour obtenir une excellente expérience développeur ou comment concevoir une plateforme évolutive, fiable et sécurisée. De plus, les équipes d'activation peuvent former les équipes rationalisées et les équipes de plateforme sur, euh, des compétences liées à la gestion de produit, à la communication efficace, à une bonne documentation, à l'amélioration des processus, au mentorat, au coaching, etc. Ainsi, les équipes d'activation, euh, facilitant en tant que mentors et coachs internes et aidant à améliorer les compétences des autres équipes sur les capacités manquantes.
[00:36:23] Et ainsi, les autres équipes deviennent autonomes, ce qui débloque alors les dépendances envers les personnes ayant une expertise particulière pour faire quelque chose avant que les équipes ne puissent terminer leur travail.
[00:36:37] Et les équipes d'activation s'intègrent également magnifiquement aux concepts d'organisations apprenantes. Ainsi, les organisations apprenantes, elles embrassent l'expérimentation continue de l'apprentissage partagé. Et l'apprentissage continu et l'expérimentation sont cruciaux pour l'adaptabilité afin de pouvoir répondre à des situations complexes avec beaucoup d'inconnues inconnues. Ainsi, dans le contexte de l'architecture pour le flux, euh, l'apprentissage partagé continu et l'expérimentation sont soutenus par des équipes d'activation qui visent à identifier et à combler les lacunes de capacités des autres équipes, les aidant à acquérir les compétences manquantes et à les rendre autonomes. Euh, ou un autre aspect est la collaboration de courte durée entre équipes, qui est mise en avant par les topologies d'équipe pour explorer et découvrir rapidement des domaines inexplorés. Euh, ou par la collaboration étroite entre les experts du domaine et les équipes de développement du point de vue de la conception axée sur le domaine afin de créer une compréhension commune, une compréhension partagée du domaine problématique et afin d'aligner la conception logicielle sur le domaine métier. Et cela peut également être complété par d'autres méthodes d'apprentissage en équipe, par exemple, en établissant une communauté de pratique afin d'échanger, euh, des connaissances et de développer une expertise de manière régulière.
[00:38:02] Mais vous devez également considérer, euh, que non seulement nos compétences et nos capacités sont pertinentes, mais aussi, euh, que nos préférences et nos mentalités des membres de l'équipe sont également d'une importance cruciale lors de la composition des équipes. Donc, lors de la composition des équipes, Simonley suggère de penser aptitude et attitude. Ce qui signifie que non seulement l'ensemble des compétences, euh, l'aptitude est pertinente pour les membres de l'équipe, mais aussi leur état d'esprit, leur attitude. Donc, et traiter des composants à différentes étapes d'évolution, cela nécessite des mentalités différentes. Et Simonley a introduit, euh, euh, l'état d'esprit de l'explorateur, des villageois et des urbanistes, qui étaient autrefois, étaient autrefois connus sous le nom de pionniers colonisateurs et urbanistes. Et mon point de vue ici est que, euh, il devrait exister un mélange d'états d'esprit dans chaque équipe et, en fonction de l'étape d'évolution que l'équipe spécifique possède, un état d'esprit pourrait être plus répandu que prédominant, plus existant que dominant que d'autres états d'esprit, par exemple. Les équipes possédant des composants dans la Genèse ou construits sur mesure, elles pourraient avoir tendance, elles pourraient avoir tendance vers un état d'esprit d'explorateur avec une préférence pour la découverte et l'expérimentation, donc elles sont très à l'aise avec l'échec et l'expérimentation de nouveaux et inconnus domaines inexplorés. étaient auparavant connus sous le nom de pionniers colons et urbanistes. Et mon point de vue ici est qu'il devrait exister un mélange de mentalités dans chaque équipe et qu'en fonction de l'étape d'évolution que l'équipe spécifique possède, une mentalité pourrait être plus répandue que prévalente, plus existante que dominante par rapport à d'autres mentalités. Par exemple, les équipes propriétaires de composants dans Genesis ou de constructions personnalisées, elles pourraient avoir tendance à adopter une mentalité d'explorateur, avec une préférence pour la découverte et l'expérimentation, elles acceptent donc très bien l'échec et l'expérimentation de nouveaux domaines inconnus et inexplorés. Et les équipes propriétaires de composants dans la location de produits, elles pourraient plutôt chercher à améliorer et à stabiliser avec une mentalité de villageois. Et les équipes propriétaires de composants dans le domaine des produits de base et des utilitaires, elles pourraient préférer mûrir et optimiser avec une mentalité d'urbaniste. Donc ce mélange de mentalités dans chaque équipe permet aux équipes de réagir de différentes manières à différentes situations. Ainsi, une équipe possédant des composants de base peut également passer en mode exploration en utilisant des techniques agiles et collaborer étroitement avec d'autres équipes pendant une période limitée, par exemple lors de l'exploration d'une nouvelle technologie, ou lors de la transition d'une infrastructure sur site vers des services hébergés dans le cloud pour lesquels elle n'a aucune connaissance préalable. Revenons à nos euh bloqueurs de flux. Jusqu'à présent, euh cette approche d'architecture pour le flux nous aide à euh identifier et débloquer euh une variété de bloqueurs de flux en théorie.
[00:40:45] Mais maintenant, la question est de savoir comment le mettre en pratique et comment passer à l'architecture conçue pour le flux que nous avons, euh, oui, conçue. Et une approche consiste à effectuer une transition avec une approche "l'équipe d'abord", en suivant une manœuvre de Conway inversée. Et la loi de Conway, euh, stipule que, euh, les organisations conçoivent des systèmes qui copient leur structure de communication, donc la conception du système est une copie de leur structure de communication. Et la manœuvre de Conway inversée suggère que nous devrions d'abord restructurer notre organisation afin d'atteindre l'architecture désirée à la fin. Et nous allons appliquer cette manœuvre de Conway inversée par le biais d'un re-teaming dynamique incrémental et de petites étapes impliquant l'interaction de l'équipe tout au long de cette transition.
[00:41:50] Ainsi, l'optimisation de notre système pour un flux rapide de changements est dans ce cas dirigée par le re-teaming dynamique des équipes silo fonctionnelles en équipes de plateforme et en équipes de rationalisation, étape par étape, de manière incrémentale.
[00:42:03] Et nous faisons évoluer leur interaction tout au long d'un parcours de migration vers le cloud, donc euh, et cette transition pourrait commencer par la formation de l'équipe de plateforme en premier, qui lance le parcours de migration vers le cloud par re-platforming. Et avec le re-platforming, du point de vue du parcours de migration vers le cloud, les composants d'infrastructure sur site vont être progressivement remplacés par des services hébergés dans le cloud, tout en conservant la même architecture d'application existante. Nous ne remplaçons donc que l'infrastructure sous-jacente pendant le parcours de migration vers le cloud par re-platforming. Et lorsque nous avons, euh, re-platformé nos composants d'infrastructure vers des services hébergés dans le cloud après un certain temps, alors euh, la première équipe de rationalisation peut se former, et l'équipe de rationalisation peut alors se charger de commencer à refactoriser l'application. Et avec la refactorisation dans ce contexte, dans le contexte de la migration vers le cloud, nous divisons l'architecture d'application existante en parties plus petites, et c'est là que nous pouvons utiliser les contextes délimités précédemment conçus comme base.
[00:43:18] Et le parcours de refactorisation est soutenu par une évolution des modes d'interaction des typologies d'équipe. Ainsi, la première forme d'équipes rationalisées peut collaborer étroitement avec la première équipe de plateforme au début afin d'évaluer les options cloud potentielles qui sont applicables pour le futur contexte délimité dont la future équipe rationalisée sera responsable. Et cette collaboration étroite peut ensuite évoluer vers une collaboration limitée à la demande, puis finalement devenir un service externe où l'équipe de plateforme fournit les meilleures pratiques, les normes, les outils et les API afin de consommer facilement les services cloud. Et ensuite, la prochaine équipe rationalisée peut se former et refactoriser son contexte délimité, et elle reçoit alors un soutien pendant son parcours de refactorisation de la part des équipes de plateforme et de rationalisation précédentes, qui facilitent le travail des nouvelles équipes rationalisées, partageant leurs connaissances et les coachant tout au long de leur parcours de refactorisation. Et ensuite, la prochaine équipe rationalisée peut se former et elle reçoit également le soutien des autres équipes, partageant leurs connaissances et les coachant sur les meilleures pratiques qu'elles ont appliquées.
[00:44:40] Ainsi, à la fin, nous avons pu résoudre nos blocages de flux grâce à une approche incrémentielle axée sur l'équipe, par le biais d'un redécoupage dynamique des équipes et d'une évolution des modes d'interaction des équipes, faisant évoluer l'interaction des équipes le long d'un chemin de migration vers le cloud. Donc, en résumé, la combinaison du mappage des what, de la conception axée sur le domaine et des typologies d'équipes nous aide à générer une valeur durable alignée sur les besoins des utilisateurs. Aide à débloquer les entraves au flux et à concentrer notre investissement en développement sur notre différenciateur, offrant un avantage concurrentiel. Cela nous aide à combler les lacunes potentielles en matière d'efficacité et à aligner nos équipes et à faire évoluer leur interaction avec le système que nous construisons et la stratégie que nous planifions. Et aussi établir une organisation apprenante qui embrasse l'apprentissage partagé continu et l'expérimentation afin de pouvoir répondre également à des situations complexes avec des inconnues inconnues et des domaines inexplorés. Ainsi, cette combinaison fournit un ensemble d'outils puissant pour concevoir, faire évoluer, construire des systèmes sociotechniques adaptatifs qui sont optimisés pour un flux rapide de valeur durable pour nos utilisateurs. et un retour d'information rapide et constant qui peut ensuite prospérer face à des changements rapides afin de construire la bonne chose, correctement, à la fin.
[00:46:13] Et c'est aussi que lorsque nous sommes capables d'avoir optimisé notre système pour un flux rapide de valeur et un feedback rapide et constant, nous pouvons aussi regarder vers l'avenir. Alors nous sommes maintenant en position de non seulement pouvoir répondre aux changements introduits par d'autres, mais aussi de pouvoir mener les futurs changements introduits par nous. C'est donc là que nous pouvons ensuite appliquer des actions stratégiques commerciales efficaces en termes, par exemple, de création de valeurs différenciantes supplémentaires afin d'accroître notre avantage concurrentiel ou d'être le premier à marchandiser des composants sur lesquels d'autres peuvent innover, ou en construisant des alliances de coopération avec d'autres afin d'accélérer l'évolution des composants et de développer notre écosystème. Nous sommes donc maintenant aux commandes du changement.
[00:47:03] Et si vous êtes intéressé par plus de détails, il y a différentes ressources que j'ai collectées, il y en a bien plus, mais ce n'est qu'un petit extrait. Et comme je l'ai mentionné plus tôt, euh, j'écris un livre sur ce sujet, toujours, pour être honnête, et euh. Je vous remercie beaucoup pour votre attention et elle a ce lien vers la diapositive que vous pouvez utiliser si vous souhaitez la télécharger. Merci beaucoup.
[00:47:31] Avez-vous des questions que vous aimeriez poser ?
[00:47:45] Euh, merci. Euh, c'est euh, beaucoup de choses intéressantes. Euh, vous avez mentionné euh, je ne sais pas si vous l'avez mentionné, mais quelque chose que vous avez dit concernait les domaines fondamentaux, ou quelque chose de similaire.
[00:47:59] Je suis désolée, répétez s'il vous plaît.
[00:48:02] Euh, à propos du domaine principal et du domaine principal, ça m'a fait penser aux cartes de domaine principal et euh, la question est, euh, il y a probablement un équilibre dans la taille de l'équipe entre l'équipe rationalisée, la plateforme, l'équipe d'activation, quel est l'équilibre en nombre de personnes, évidemment, euh quel est le point idéal selon vous ?
[00:48:20] Oui, alors euh, cela dépend de votre contexte, bien sûr, et de votre contexte délimité lié au domaine central, mais j'essaie généralement, en termes de nombre de membres d'équipe dans les équipes qui possèdent un contexte délimité lié au domaine central, par exemple, cela dépend vraiment du niveau de complexité et aussi du taux de changement, par exemple, et euh, pour déterminer quelle équipe peut posséder quel contexte délimité et aussi quelle est la taille des équipes. Il y a donc une recommandation de la part des topologies d'équipe en termes de se concentrer sur de petites équipes stables et durables, et ils recommandent une taille d'équipe de cinq à neuf personnes. Et euh, généralement, je dirais que cela dépend de la complexité de votre domaine central, c'est que parfois une équipe peut posséder un contexte délimité lié au domaine central, parfois cela dépend aussi de plus d'un contexte délimité lié au domaine central, cela dépend vraiment de la complexité et du taux de changement impliqués dans ce contexte délimité lui-même. D'un autre côté, pour les sous-domaines moins complexes ou moins, disons, pour le support générique, alors les équipes peuvent posséder au moins, oui, plus de deux ou trois contextes délimités, selon la taille et la complexité des autres sous-domaines qu'elles possèdent.
[00:49:47] Merci, j'ai une question.
[00:49:49] ici je suis debout. Oui, ici. Oui.
[00:49:50] Merci pour votre présentation. Euh, donc vous aviez une image où vous aviez des composants ou des parties du système et les équipes, et il y avait des flèches, comme si les équipes possédaient ce code, n'est-ce pas ? Et je pense que vous vous seriez assuré qu'il n'y avait aucun composant appartenant à plus d'une équipe, d'une certaine manière. Alors, qu'est-il arrivé à l'idée de la propriété collective du code qui était célèbre il y a 20 ans dans la communauté de la programmation extrême ?
[00:50:23] Oui, alors, comme je l'ai dit plus tôt, euh, la propriété partagée est parfois un défi en termes de fait que vous, euh, que vous diffusez la propriété d'une partie spécifique du système. Et euh, et spécifiquement si personne ne se sent responsable d'agir, par exemple, lorsqu'un bug est introduit ou quelque chose comme ça, alors cela conduit au syndrome "pas mon travail". Et donc dans certains domaines, vous avez des services partagés et euh, au début, vous pourriez ne pas trouver euh, une propriété claire de cette partie spécifique de la partie partagée. Et puis vous pouvez, par exemple, introduire euh, donc je recommanderais qu'au moins une équipe soit responsable d'un service partagé, mais d'autres peuvent, par exemple, avec euh, le développement en interne, euh, au lieu de l'open source, peuvent aussi euh, ajouter euh, des demandes de changement à ce contexte délimité spécifique. Par exemple, si d'autres équipes ont besoin qu'un système spécifique soit modifié. Je recommanderais donc fortement de ne pas partager les services, mais euh, d'un autre côté, vous pouvez bien sûr, vous pouvez toujours euh appliquer des mécanismes tels que euh le mob ou la programmation en binôme pour travailler ensemble, collaborer ensemble afin de construire un système.
[00:51:48] Clarifiez, donc, merci. Juste pour clarifier, faites-vous la promotion de la propriété privée du code par opposition à la propriété collective du code ces jours-ci ?
[00:51:58] la propriété privée du code, oui.
[00:52:00] Intéressant.
[00:52:00] Mais cela peut aussi être euh, cela pourrait aussi être euh, euh. Bien sûr, vous pouvez aussi dire, euh, donc les services partagés eux-mêmes, ils devraient, euh, principalement, donc les tendances ou le but n'est pas que les services partagés ne changent pas si souvent. Pour que vous ayez des services stables que vous partagez. Au moment où vous voyez que les services partagés changent beaucoup, il se peut que ce ne soit pas la bonne façon de les séparer ou de créer un service partagé, il se peut qu'il y ait une logique de domaine impliquée qui ne devrait pas faire partie d'un service partagé. Et euh, et cela peut appartenir à une autre équipe, mais par exemple, au moment où vous partagez quelque chose, vous pouvez considérer, est-ce que c'est quelque chose que d'autres équipes peuvent utiliser, consommer comme un service, et où alors l'idée de plateforme entre en jeu, où une équipe de plateforme fournit un service interne à d'autres équipes.
[00:53:05] Merci. Euh, en termes de euh, de gestion du changement, euh, avez-vous une recommandation sur le temps que cela devrait prendre pour passer d'un état à l'autre ?
[00:53:24] Euh, voulez-vous dire de réorganiser dynamiquement votre organisation ou combien de temps cela pourrait prendre ? Donc oui, cela dépend bien sûr de la taille de votre système en général et de son degré de couplage. Donc euh, mais je recommande, cela dépend aussi du contexte, je ferais alors une analyse de compromis avec les pour et les contre, en commençant, par exemple, par de petites euh, euh. par exemple, où vous pouvez avancer rapidement, puis peut-être en un mois ou quelque chose comme ça. Ou cela, et puis plus tard, intégrer d'autres équipes dans cet aspect. Mais ce que j'ai vu, c'est que la vitesse d'avancement et la est corrélée à une transition réussie. Euh, et spécifiquement l'adhésion des deux côtés, également de la direction euh et et de celui-ci. Mais en termes d'aspect temporel, euh, c'est aussi que certains contextes délimités ne peuvent peut-être pas être décomposés, par exemple, je ne parlais pas de microservices ou de quelque chose comme ça, car il se peut aussi qu'à un certain point vous laissiez certaines parties dans votre grosse boule de boue monolithique. Mais le refactoriser, pour qu'il soit plus modulaire, mais il reste dans ce monolithe, donc c'est aussi toujours une option que vous, à un moment donné, vous n'êtes pas. tout découper en un microservice séparé et indépendant, par exemple, ou quelque chose de similaire. Donc et il y a une sorte de situation où au début vous êtes plus rapide que lorsque vous atteignez le point où vous ne pouvez pas vraiment décomposer une partie très interdépendante et entrelacée du système, alors cela ralentit. Et euh, donc je suggérerais que plus vous pouvez aller vite au début, euh, c'est corrélé au succès à la fin.
[00:55:16] Merci.
[00:55:17] Merci.
[00:55:21] Nous sommes bons. D'accord. Merci beaucoup, et je suis là, alors n'hésitez pas à poser d'autres questions. Merci.

Transcription (Traduit)