Sujet 7.0 — Structures d'équipe, rôles et responsabilités

En une phrase : La livraison de santé numérique réussit ou échoue selon comment vous dessinez les frontières entre équipes et comment clairement vous nommez qui fait quoi — donc structurez les équipes pour un flux de valeur rapide et sûr, dotez-les de manière multidisciplinaire, et rendez les responsabilités explicites.

Pourquoi c'est important dans la santé et l'action sociale#

La façon dont vous organisez vos équipes devient la façon dont vos services se comportent. La loi de Conway — qu'la conception d'un système reflète la structure de communication de l'organisation qui l'a construit — n'est pas une curiosité dans la santé et l'action sociale ; c'est un risque de sécurité patient. Des équipes fragmentées produisent des dossiers de soins fragmentés, des intégrations fragiles, et des passations où le risque clinique se cache.

Dans le NHS et l'action sociale, vous dépensez aussi de l'argent public et portez des devoirs statutaires : sécurité clinique sous DCB0129/DCB0160, gouvernance de l'information sous le UK GDPR et le devoir de confidentialité de common law, et obligations d'accessibilité. Ces devoirs ne peuvent pas être ajoutés à la fin. Ils doivent être représentés à l'intérieur de l'équipe, par des personnes nommées avec l'autorité et le temps de les décharger.

Faites la structure correctement et des équipes multidisciplinaires livrent un logiciel fonctionnel auquel les cliniciens font confiance et que les patients peuvent utiliser. Faites-la mal et vous obtenez des spécialistes occupés optimisant leur propre silo tandis que le service dans son ensemble cale — le motif classique derrière les programmes numériques en retard, au-dessus du budget, et discrètement abandonnés.

Concepts fondamentaux#

Équipes multidisciplinaires (MDT). Une équipe de livraison numérique devrait contenir chaque discipline nécessaire pour concevoir, construire, et exploiter un service sans dépendance externe constante — produit, livraison, design, recherche, ingénierie, données, et les perspectives cliniques et de gouvernance. Ceci reflète le concept de MDT clinique que le personnel connaît déjà : expertise mixte, responsabilité partagée pour un résultat.

Team Topologies. Un modèle (Skelton & Pais) qui réduit la conception d'équipe efficace à quatre types fondamentaux et trois modes d'interaction, tous au service du flux rapide de la valeur :

• Équipe alignée sur le flux — organisée autour d'un seul flux de travail précieux (un service, un parcours utilisateur, un produit) et le possédant de bout en bout. C'est le type d'équipe par défaut ; la plupart des gens devraient en faire partie.
• Équipe plateforme — fournit des capacités internes en libre-service (infrastructure partagée, un moteur d'intégration, un service de connexion, une API de dossier de soins partagé) afin que les équipes alignées sur le flux aillent plus vite sans les réinventer.
• Équipe habilitante — une équipe de spécialistes limitée dans le temps (par exemple, sécurité clinique, accessibilité, automatisation de tests) qui accompagne d'autres pour élever une capacité, puis se retire.
• Équipe de sous-système complexe — possède une partie nécessitant une connaissance spécialiste approfondie (un algorithme de notation de risque, une interface NHS Spine) qui surchargerait une équipe généraliste.

Les trois modes d'interaction gouvernent comment deux équipes se relient : collaboration (travailler étroitement pendant une période définie, haute bande passante, tolérant une certaine inefficacité pour découvrir des choses), X-en-tant-que-service (une équipe consomme la capacité d'une autre avec un minimum de tracas, le défaut à faible friction à l'échelle), et facilitation (une équipe aide une autre à apprendre). Nommer le mode prévient l'ambiguïté qui engendre les retards et le blâme.

Charge cognitive. Une équipe ne peut tenir que tant dans sa tête. Team Topologies soutient que vous devriez limiter le domaine que chaque équipe possède à ce sur quoi elle peut raisonner en toute sécurité — un principe décisif quand le domaine est clinique.

La loi de Conway et la manœuvre de Conway inverse. Puisque l'architecture suit la structure organisationnelle — une vue de système sociotechnique qui traite les équipes et la technologie comme une seule conception — façonnez délibérément les équipes pour produire l'architecture que vous voulez. Si vous voulez un dossier de soins modulaire et interopérable, ne le construisez pas avec une équipe monolithique unique.

Bonnes pratiques#

1. Dotez une équipe multidisciplinaire complète autour de chaque service. Incluez, au minimum, un product manager, un delivery manager, un chercheur utilisateur, un designer de service/interaction, des ingénieurs, et une capacité données/analytique, plus une contribution nommée en sécurité clinique et gouvernance de l'information. Une équipe manquant une discipline attendra sur quelqu'un d'autre ou sautera ce travail — et le travail sauté dans la santé est habituellement la sécurité, l'accessibilité, ou la gouvernance.

2. Rendez la plupart des équipes alignées sur le flux et donnez-leur une propriété de bout en bout. Organisez autour du parcours d'un utilisateur (par exemple « orientation ambulatoire ») plutôt qu'une couche technologique (par exemple « l'équipe base de données »). La propriété de bout en bout raccourcit les boucles de rétroaction et arrête les écarts de passation où le risque clinique s'accumule.

3. Construisez les plateformes comme des produits, consommées comme un service. Traitez votre moteur d'intégration, service d'identité, ou API de dossier de soins partagé comme un produit interne avec sa propre équipe, feuille de route, et utilisateurs. Publiez-le « en tant que service » afin que les équipes alignées sur le flux s'auto-servent, plutôt que de lever des tickets et attendre.

4. Utilisez les équipes habilitantes pour répandre l'expertise rare, pas pour la thésauriser. Les agents de sécurité clinique, spécialistes de l'accessibilité, et ingénieurs de sécurité sont rares. Déployez-les pour accompagner les équipes de livraison vers un standard plus élevé puis passez à autre chose, plutôt que de devenir un goulot d'étranglement permanent derrière lequel chaque équipe fait la queue.

5. Nommez chaque rôle et ses droits de décision explicitement. Utilisez un modèle de responsabilité — RACI (Responsible, Accountable, Consulted, Informed) ou une répartition « décideur/conseiller » plus simple — pour les décisions qui comptent : approbation de sécurité clinique, mise en production, approbation de gouvernance de l'information, dépense. L'ambiguïté ici est là où la responsabilité s'évapore.

6. Donnez à l'agent de sécurité clinique une véritable autorité et un véritable temps. DCB0129/0160 exigent un agent de sécurité clinique nommé et convenablement formé qui peut arrêter une release. Rendez le rôle explicite dans l'équipe, protégez son temps, et assurez-vous qu'il puisse dire non — un CSO en nom seulement est un échec de gouvernance attendant d'être trouvé par un incident.

7. Gérez la charge cognitive en délimitant le domaine. Si une équipe possède trop de services ou un domaine clinique trop complexe, divisez-la. Surveillez le signal : une équipe qui ne peut plus expliquer avec confiance les implications de sécurité de son propre changement est surchargée.

8. Appliquez la manœuvre de Conway inverse délibérément. Dessinez les frontières d'équipe pour correspondre à l'architecture et l'interopérabilité que vous voulez — équipes modulaires pour des systèmes modulaires basés sur des normes (par exemple HL7 FHIR). Ne laissez pas un organigramme accidentel concevoir votre dossier de soins pour vous.

Questions à discuter avec votre équipe#

1. Où notre organigramme actuel conçoit-il déjà notre architecture pour nous — et est-ce l'architecture que nous voulons réellement ? La loi de Conway n'est pas optionnelle : quelle que soit la forme de nos équipes, les systèmes en viendront à la refléter, donc le premier mouvement honnête est de regarder le dossier de soins, les intégrations, et les passations que nous avons déjà et demander quelle frontière d'équipe a produit chaque couture. Dans un cadre de santé et action sociale, ces coutures sont là où le risque clinique se cache — un dossier fragmenté, une interface Spine fragile, un dossier de sécurité qu'aucune équipe unique ne possède — donc c'est une conversation de sécurité patient, pas esthétique. La tension à débattre est que redessiner les frontières d'équipe pour obtenir l'architecture que nous voulons (la manœuvre de Conway inverse) est perturbateur, menace des fiefs établis, et traverse les structures de financement et de gestion hiérarchique que nous ne contrôlons peut-être pas entièrement. Considérez cartographier deux ou trois de vos intégrations les plus douloureuses jusqu'aux équipes qui possèdent chaque extrémité, et demandez si une frontière alignée sur le flux aurait retiré la passation entièrement. Une bonne réponse nomme au moins une frontière concrète que vous déplaceriez, est honnête sur qui résisterait et pourquoi, et distingue les changements valant la perturbation de ceux où une interface en-tant-que-service corrigerait la friction plus économiquement.

2. Nos spécialistes rares — sécurité clinique, gouvernance de l'information, accessibilité — siègent-ils à l'intérieur des équipes avec une véritable autorité, ou sont-ils des portes externes derrière lesquelles tout le monde fait la queue ? Chaque service de cette famille porte des devoirs statutaires (sécurité clinique DCB0129/0160, UK GDPR et le devoir de confidentialité de common law, droit de l'accessibilité) qui ne peuvent pas être ajoutés à la fin, pourtant ces capacités sont rares et coûteuses, ce qui tire les organisations vers leur thésaurisation centrale. Le compromis est réel : intégrez un agent de sécurité clinique dans chaque équipe et vous répandez une expertise mince jusqu'à ce qu'elle soit diluée ; centralisez-la et vous créez le goulot d'étranglement héroïque où une personne est Consultée sur tout et chaque release attend. Le motif d'équipe habilitante — spécialistes limités dans le temps qui accompagnent les équipes à exécuter leurs propres ateliers de risque et se retirent ensuite — est la résolution proposée, mais elle ne fonctionne que si la direction protège le temps des spécialistes pour enseigner plutôt que faire. Regardez honnêtement votre propre historique de release : à quelle fréquence la mise en production a-t-elle glissé en attendant une seule personne nommée, et cette personne avait-elle l'autorité et le temps protégé pour dire non en toute sécurité ? Une réponse forte affronte la rareté carrément, choisit une position délibérée sur intégrer-versus-habiliter pour chaque devoir, et nomme l'autorité spécifique (le pouvoir d'arrêter une release) qui ne doit jamais être diluée peu importe comment vous répandez la capacité.

3. Comment saurions-nous qu'une équipe a pris plus de charge cognitive qu'elle ne peut porter en toute sécurité — et que ferions-nous réellement à ce sujet ? La charge cognitive est le régulateur discret de la livraison sûre : une équipe ne peut raisonner que sur tant de domaine clinique et tant de services avant que sa confiance dans les implications de sécurité de ses propres changements ne commence à s'éroder, et dans la santé, cette érosion est invisible jusqu'à ce qu'un incident l'expose. La difficulté est que la surcharge s'annonce rarement — elle ressemble à une livraison légèrement plus lente, plus de défauts, plus de « laissez-moi vérifier avec quelqu'un », et les équipes sous pression tendent à absorber plutôt que signaler, particulièrement quand diviser une équipe est politiquement coûteux ou que les effectifs sont gelés. Débattez de quels seraient vos signaux d'alerte précoce (une équipe qui ne peut plus expliquer avec confiance le dossier de sécurité de sa propre release en est un fort), et si vous avez un mécanisme aujourd'hui qui ferait surgir la surcharge avant que la livraison ne cale visiblement. Considérez aussi la contre-pression : diviser les équipes crée de nouvelles frontières et passations, donc le remède peut réintroduire le risque de fragmentation de la première question. Une réponse honnête convient de signaux concrets et observables plutôt qu'un vague « nous le sentirions », nomme qui a l'autorité de délimiter le domaine d'une équipe ou de la diviser, et admet le compromis entre le soulagement de charge et la prolifération de frontières.

4. Lesquelles de nos capacités partagées devraient être exploitées comme des plateformes consommées en-tant-que-service, et les ressourçons-nous réellement de cette façon — ou re-étiquetons-nous simplement une file d'attente de tickets ? La promesse d'une équipe plateforme est que les équipes alignées sur le flux s'auto-servent un moteur d'intégration, un service d'identité, ou une API de dossier de soins partagé sans lever un ticket et attendre, afin que tout le système aille plus vite ; l'échec est d'appeler quelque chose une « plateforme » alors qu'elle reste une fonction centrale sous-dotée en personnel derrière laquelle tout le monde fait toujours la queue. Le compromis est réel : construire une capacité comme un véritable produit interne signifie lui donner sa propre équipe, feuille de route, documentation, et utilisateurs, ce qui est un investissement sérieux qui rivalise avec la livraison de fonctionnalités destinées aux utilisateurs, et dans un cadre NHS à trésorerie limitée, cet investissement est facile à reporter indéfiniment. Dans la santé et l'action sociale, les enjeux sont plus aigus parce que les capacités partagées sont souvent les critiques en sécurité — l'index de correspondance de personnes, les interfaces FHIR, la piste d'audit — où une équipe plateforme mince devient un point de défaillance unique pour chaque service par-dessus. Regardez les capacités dont plusieurs équipes dépendent déjà et demandez, pour chacune, si l'interaction est véritablement X-en-tant-que-service à faible friction ou une collaboration déguisée avec des attentes cachées. Une réponse honnête nomme quelles capacités méritent véritablement un investissement plateforme maintenant versus plus tard, est claire sur qui les finance et les dote en personnel, et résiste à la tentation de déclarer une plateforme qui n'a aucun propriétaire de produit, aucune feuille de route, et aucun chemin en libre-service.

5. Où dépendons-nous de fournisseurs contractés ou de personnel emprunté, et quels rôles devons-nous garder en interne pour rester un client intelligent plutôt qu'un client vidé de sa substance ? Une grande partie de la livraison numérique dans la santé et l'action sociale est externalisée, et un fournisseur peut apporter de la capacité et de la spécialisation rapidement — mais si la propriété du produit, l'assurance technique, et l'approbation de sécurité clinique quittent tous le bâtiment avec le contrat, l'organisation perd la capacité de juger ce qui lui est vendu, de spécifier ce dont elle a besoin, ou de posséder en toute sécurité le résultat. La tension est entre la vitesse et la capacité : l'augmentation de personnel et les constructions clé en main mettent quelque chose en production rapidement, pourtant elles peuvent discrètement éroder le muscle interne qui vous permet de tenir un fournisseur responsable, et elles livrent souvent des structures en forme de composant et lourdes en passations plutôt que des équipes alignées sur le flux qui possèdent un résultat. Dans ce domaine, les rôles retenus non négociables se regroupent autour de la responsabilité qui ne peut pas être déléguée — le Senior Responsible Owner, l'agent de sécurité clinique qui approuve la mise en production, le propriétaire de produit qui décide des priorités, et assez d'assurance technique pour inspecter ce que les fournisseurs construisent. Examinez votre livraison actuelle et demandez quelles capacités vous ne pourriez pas reconstituer si un fournisseur s'en allait demain. Une bonne réponse distingue le travail qui convient véritablement à l'externalisation du noyau de client intelligent qui doit rester en interne, insiste que les équipes contractées sont tenues à la propriété de résultat plutôt qu'à la dotation en personnel de type body-shop, et nomme les décisions de sécurité et gouvernance qui doivent toujours reposer sur vos propres personnes responsables.

6. Comment saurons-nous que notre structure d'équipe produit réellement un flux de valeur rapide et sûr — et qu'est-ce qui nous déclencherait à la redessiner ? La conception d'équipe est un moyen, pas une fin : le but des équipes alignées sur le flux, des plateformes, et des modes d'interaction nommés est une livraison de valeur plus rapide et plus sûre, pourtant les organisations instrumentent rarement si la structure livre cela, donc les réorganisations se produisent sur la politique et l'intuition plutôt que sur les preuves. La difficulté est de choisir des signaux qui reflètent le flux et la sécurité sans les jouer — la vélocité brute ou le débit de points d'histoire invite le mauvais comportement, tandis que les métriques de flux (délai de l'idée à la production, fréquence de déploiement, nombre de passations par changement) et les indicateurs de sécurité (à quelle vitesse les dangers sont fermés, si les équipes possèdent leur propre dossier de sécurité) vous en disent plus sur si les frontières aident ou nuisent. Il y a une véritable tension avec la stabilité : la réorganisation constante détruit la longévité d'équipe et l'espace cognitif partagé qui rendent la livraison sûre, donc vous avez besoin d'une barre élevée et de déclencheurs clairs avant de redessiner les frontières. Discutez de quelles preuves vous diraient qu'une frontière est fausse — des attentes inter-équipes persistantes, un dossier de sécurité qu'aucune équipe unique ne possède, une plateforme que personne ne s'auto-sert — et qui est habilité à agir dessus. Une réponse honnête s'engage à un petit ensemble de signaux de flux-et-sécurité que vous observerez réellement, fixe un seuil délibéré qui protège la stabilité d'équipe, et nomme les conditions de déclenchement et le décideur pour tout remodelage futur.

En pratique : un exemple de santé et d'action sociale#

Un système de soins intégrés (ICS) déploie un dossier de soins partagé à travers les soins aigus, communautaires, de santé mentale, primaires, et l'action sociale.

L'instinct est de créer une grande « équipe dossier de soins partagé ». Au lieu de cela, l'ICS applique Team Topologies. Une équipe plateforme possède le noyau du dossier partagé : l'index de correspondance de personnes, les API FHIR, et le moteur d'intégration, publiés comme des capacités en libre-service. Plusieurs équipes alignées sur le flux possèdent chacune un véritable parcours utilisateur par-dessus — « voir le dossier d'un patient aux urgences », « vue de protection de travailleur social », « réconciliation médicamenteuse de médecin généraliste » — et consomment la plateforme en-tant-que-service. Une équipe de sous-système complexe possède l'algorithme probabiliste de correspondance de patients, où une fausse correspondance est un véritable incident de sécurité. Une équipe habilitante de spécialistes de sécurité clinique et d'accessibilité tourne à travers les équipes alignées sur le flux, les accompagnant à exécuter leurs propres ateliers de risque DCB0160 plutôt que de le faire pour eux.

Chaque équipe a un product manager, delivery manager, et agent de sécurité clinique nommés, et un RACI rend clair que la mise en production est responsable devant le Senior Responsible Owner mais ne peut pas procéder sans l'approbation du CSO et de la gouvernance de l'information. Quand l'équipe des urgences a besoin d'un nouveau champ de données, le mode d'interaction est explicite : X-en-tant-que-service de l'équipe plateforme via une demande d'API documentée, pas une collaboration de six semaines. La livraison est plus rapide et, de manière cruciale, le dossier de sécurité pour chaque parcours est possédé par l'équipe qui le livre.

Angles sectoriels#

Startup#

Une startup de santé numérique de dix personnes ne peut pas doter en personnel quatre types d'équipe distincts — elle est habituellement une seule équipe alignée sur le flux dans laquelle une personne porte plusieurs chapeaux (un ingénieur qui exécute aussi la recherche utilisateur, un clinicien-fondateur qui est l'agent de sécurité clinique de facto). La priorité est de garder toute l'équipe à l'intérieur d'un seul espace cognitif partagé afin que les décisions soient rapides ; un RACI formel est excessif quand tout le monde est dans la même pièce. Le véritable risque est le goulot d'étranglement fondateur : la sécurité clinique et la gouvernance de l'information reposent sur une personne occupée, et les obligations DCB0129/0160 sont faciles à reporter. Alors que l'entreprise gagne son premier contrat NHS, les premières embauches spécialistes devraient être celles qui dérisquent cette porte — un CSO nommé et un responsable de gouvernance de l'information — avant d'échelonner les effectifs d'ingénierie.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, ou une clinique monosite — a de véritables patients et des opérations continues mais rarement une équipe numérique ou informatique dédiée, donc il n'y a pas de « topologie d'équipe » à concevoir ; le gérant de cabinet ou un responsable clinique est effectivement toute la capacité de livraison aux côtés de son travail quotidien. Le mouvement réaliste n'est pas de construire des équipes plateforme et habilitantes mais de nommer les responsabilités explicitement sur les personnes que vous avez déjà — qui est l'agent de sécurité clinique pour les systèmes que vous déployez, qui possède la gouvernance de l'information, qui approuve un changement — même si ce sont des chapeaux à temps partiel sur une poignée de personnel. Parce que les mêmes devoirs statutaires (DCB0129/0160, UK GDPR, accessibilité) s'appliquent comme ils le font pour un grand trust, le motif pratique est de s'appuyer sur les plateformes partagées et le support habilitant de vos fournisseurs et de votre ICS plutôt que de les réinventer, tout en conservant juste assez de capacité de client intelligent pour tenir les fournisseurs responsables. Le plus grand risque unique est le goulot d'étranglement à une personne : si la seule personne qui comprend le système clinique part, la sécurité et la continuité partent avec elle, donc écrire le RACI et former en croisement une seconde personne compte plus ici que tout modèle d'équipe formel.

Entreprise#

Un grand trust du NHS ou une entreprise de santé technologique a le problème opposé : trop d'équipes, dessinées le long de lignes de composants hérités et départementales, avec des passations partout. C'est là qu'un modèle de conception d'équipe délibéré gagne sa place — remodeler les équipes de composants en équipes alignées sur le flux, mettre en place des équipes plateforme pour les capacités de dossier de soins partagé et d'intégration, et utiliser des équipes habilitantes pour répandre l'expertise rare de sécurité clinique et d'accessibilité. Le RACI et les droits de décision explicites deviennent essentiels parce que le pur nombre de parties prenantes rend la coordination informelle impossible. La manœuvre de Conway inverse est un levier vivant ici : un organigramme vieux de décennies façonne déjà l'architecture, donc les dirigeants doivent redessiner les frontières d'équipe intentionnellement plutôt que de laisser la structure concevoir le dossier de soins pour eux.

Gouvernement#

Un organisme national (NHS England, DHSC) ou une autorité locale fixe les standards contre lesquels d'autres se dotent en personnel — le Government Digital and Data capability framework, le Service Standard, DCB0129/0160 — et est responsable devant le Parlement et le public de comment l'argent achète la capacité d'équipe. Les structures ici sont façonnées par les règles d'achats et de financement : beaucoup de livraison est contractée à des fournisseurs, donc les rôles cruciaux à retenir en interne sont ceux de client intelligent (propriété de produit, assurance technique, approbation de sécurité clinique) qui empêchent la capacité d'être vidée de sa substance. La responsabilité est formelle et auditable — un Senior Responsible Owner nommé, des contrôles de dépenses publiés, des devoirs de transparence — donc les modèles de responsabilité sont une question de dossier public, pas une hygiène optionnelle. Le risque caractéristique est que la structure se fige en conseils de programme permanents et portes qui étranglent le flux ; la contre-mesure est de tenir les fournisseurs à des équipes alignées sur le flux et possédant le résultat plutôt qu'à des body-shops d'augmentation de personnel.

Modes d'échec courants#

• Le piège de l'équipe de composant. Des équipes divisées par couche technologique (« équipe front-end », « équipe base de données ») créent des passations sur chaque fonctionnalité et ne possèdent aucun résultat. Réorganisez autour des flux de valeur.
• Le culte du cargo Spotify. Copier « squads, tribes, chapters, guilds » comme étiquettes sans l'autonomie, l'alignement, et l'investissement plateforme sous-jacents. Le modèle Spotify était un instantané d'une entreprise à un moment donné — même Spotify a évolué. Empruntez les principes, pas l'organigramme.
• Le goulot d'étranglement héroïque. Un CSO, un architecte, ou un responsable de gouvernance de l'information comme partie Consultée sur tout, donc chaque équipe attend. Convertissez-les en une capacité habilitante qui élève la compétence de tout le monde.
• La gouvernance comme réflexion après coup. La sécurité clinique et la gouvernance de l'information représentées comme des portes externes plutôt que des membres d'équipe intégrés, donc leurs préoccupations arrivent trop tard pour agir dessus économiquement.
• Équipes non bornées. Une équipe qui continue d'absorber des services jusqu'à ce que personne ne comprenne le tout. La surcharge cognitive se manifeste comme une livraison ralentie et une confiance en sécurité érodée.
• Collaboration permanente. Deux équipes « collaborant » indéfiniment est habituellement une frontière manquante. Limitez la collaboration dans le temps et déplacez vers une interface en-tant-que-service propre.

Modèle de maturité#

Liste de contrôle#

• Chaque service a une équipe alignée sur le flux qui le possède de bout en bout.
• Chaque équipe contient, ou a un accès nommé à, produit, livraison, recherche, design, ingénierie, données, sécurité clinique, et gouvernance de l'information.
• Un agent de sécurité clinique nommé et formé par équipe a un temps protégé et l'autorité pour arrêter une release.
• Les capacités partagées (intégration, identité, API de dossier de soins) sont exploitées comme des plateformes internes consommées en-tant-que-service.
• Les spécialistes rares travaillent via des équipes habilitantes limitées dans le temps, pas des goulots d'étranglement permanents.
• Un RACI (ou équivalent) existe pour l'approbation clinique, la mise en production, l'approbation de gouvernance de l'information, et la dépense, et est réellement utilisé.
• Chaque dépendance inter-équipes a un mode d'interaction nommé (collaboration / X-en-tant-que-service / facilitation).
• Les domaines d'équipe sont délimités à une charge cognitive gérable ; les équipes surchargées sont divisées.
• Les frontières d'équipe sont choisies délibérément pour produire l'architecture et l'interopérabilité que vous voulez.

Sources clés#

• Team Topologies — Matthew Skelton & Manuel Pais (four team types, three interaction modes, cognitive load): teamtopologies.com
• NHS Digital Service Standard and NHS Service Manual — multidisciplinary team roles and ways of working
• GOV.UK Service Manual (GDS) — "Set up a service team" and agile delivery guidance
• Government Digital and Data (formerly DDaT) Profession Capability Framework — role definitions: ddat-capability-framework.service.gov.uk
• Clinical Risk Management standards DCB0129 (manufacture) and DCB0160 (deployment), NHS Digital — Clinical Safety Officer role
• Conway's Law — Melvin Conway, "How Do Committees Invent?" (1968)
• Spotify engineering culture (Henrik Kniberg) — squads/tribes/chapters/guilds, read critically as a point-in-time model

Références#

1. Conway's law — Wikipédia — https://en.wikipedia.org/wiki/Conway%27s_law
2. Cognitive load — Wikipédia — https://en.wikipedia.org/wiki/Cognitive_load
3. Responsibility assignment matrix (RACI) — Wikipédia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
4. Interdisciplinarity — Wikipédia — https://en.wikipedia.org/wiki/Interdisciplinarity
5. Sociotechnical system — Wikipédia — https://en.wikipedia.org/wiki/Sociotechnical_system
6. Fast Healthcare Interoperability Resources — Wikipédia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
7. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais — https://teamtopologies.com
8. NHS Service Manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk
9. Service Manual — Government Digital Service (GDS), GOV.UK — https://www.gov.uk/service-manual
10. Government Digital and Data Profession Capability Framework — GOV.UK — https://ddat-capability-framework.service.gov.uk
11. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
12. "How Do Committees Invent?" (1968) — Melvin E. Conway — http://www.melconway.com/Home/Committees_Paper.html

Voir aussi Sujet 7.2 — Planification de la main-d'œuvre, Sujet 7.3 — Stratégie de main-d'œuvre, Sujet 7.5 — Personnes et développement organisationnel, et Sujet 8.1 — Gestion du changement.