Comprendre pourquoi certaines fonctionnalités ne sont pas fournies peut souvent s'avérer difficile. La direction peut blâmer les équipes techniques, tandis que les équipes techniques pointent du doigt la direction. Pendant ce temps, les entreprises sont prises entre deux feux, essayant d’identifier la cause profonde tout en s’efforçant d’obtenir des résultats quelles que soient les circonstances. Ce scénario survient généralement après une croissance importante de l’entreprise ou lorsque des problèmes antérieurs, auparavant faciles à résoudre, ont été négligés au fil du temps. C'est une idée fausse très répandue selon laquelle tous les problèmes dans une entreprise technologique sont purement techniques ; c'est loin d'être la vérité.

Dans cet article, je décrirai les domaines au sein de l'organisation d'une entreprise qui peuvent entraver considérablement la fourniture de fonctionnalités. Je suggérerai également des pistes d'enquête pour identifier les causes profondes, qui pourront ensuite être signalées ou résolues au sein de votre niveau d'autorité.

Il est essentiel de comprendre notre environnement de travail avant de mettre en œuvre des changements ou des améliorations. Même si de nombreux ouvrages instructifs ont été écrits sur ce sujet, toutes les approches ne conviennent pas à toutes les entreprises. Cela ne reflète pas une erreur, mais plutôt une reconnaissance de la nature unique de chaque entreprise.

Il est important de noter que les informations partagées ici sont principalement liées au développement de logiciels et sont plus applicables aux entreprises ou aux départements de 50 employés ou plus.

Structure organisationnelle

Avant tout, comprenez la taille et la structure de votre entreprise. Identifiez les différents départements et clarifiez vos attentes vis-à-vis de chacun. Évaluez si tous ces départements sont nécessaires. Créez un diagramme de la structure organisationnelle, détaillant chaque département et ses rôles, en vous assurant de comprendre ce qu'ils font et pourquoi ils existent. Souvent, chaque département se compose de plusieurs équipes. Incluez-les également dans votre diagramme, mais ne les décrivez pas pour l'instant, restez simplement les noms des équipes.

À mesure que les entreprises se développent, les structures organisationnelles peuvent devenir complexes, ce qui rend difficile le suivi des progrès. Dans cette complexité, vous risquez de perdre de vue la logique initiale derrière la création de certains départements ou équipes. Certaines équipes ont peut-être été créées pour résoudre des problèmes qui ne sont plus pertinents. Voici à quoi cela peut ressembler à un niveau élevé.

Une fois que vous avez un schéma clair de votre structure organisationnelle, que se passe-t-il ensuite ?

Hiérarchie des employés

Ensuite, il est essentiel de cartographier la hiérarchie de vos collaborateurs. Comprendre qui rend compte à qui et pourquoi est crucial. Les supérieurs hiérarchiques doivent communiquer efficacement avec leurs subordonnés, qu'ils gèrent une grande unité commerciale ou une petite équipe. La communication doit être claire, que ce soit dans un langage technique ou commercial, car gérer les deux peut s'avérer difficile. Dans les grandes entreprises, il peut y avoir des managers directs et fonctionnels avec des domaines de responsabilité distincts, qui doivent être clairement représentés dans votre diagramme hiérarchique.

Une hiérarchie des employés clarifie non seulement les lignes hiérarchiques, mais aide également à identifier les secteurs verticaux au sein de l'organisation. Les verticales sont des structures hiérarchiques qui servent de ressources partagées entre plusieurs départements, tels que les concepteurs, les ressources humaines, DevOps et même les développeurs. Même si les secteurs verticaux peuvent être très bénéfiques, ils peuvent parfois devenir des goulots d'étranglement, en particulier lorsque les développeurs travaillent sur différents projets et relèvent de gestionnaires qui ne connaissent pas les objectifs commerciaux ou les défis techniques. En conséquence, les développeurs ne reçoivent pas de retours appropriés, et les managers ne disposent pas d'un contexte approprié. Par conséquent, comprendre la hiérarchie est essentiel pour identifier et analyser les problèmes potentiels ou la priorisation des tâches. À la fin, vous aurez quelque chose comme ça.

Annotation

PDG Président directeur général
CPO — Chef de produit
CTO — Directeur technique
COO — Directeur opérationnel
HD — Responsable de la conception
PO — Propriétaire de produit
HE — Responsable de l'ingénierie
HS — Chef des ventes
HM — Responsable du marketing
D — Développeur
PM — Chef de produit
TL — Responsable technique
EM — Responsable Ingénierie
S — Directeur des ventes
M — Spécialiste du marketing

Comparez votre structure organisationnelle avec vos lignes hiérarchiques pour avoir un aperçu de l'implication de chaque employé dans diverses activités. De plus, aligner votre structure organisationnelle sur la hiérarchie des employés peut aider à déterminer si les individus travaillent au sein des mêmes départements et équipes et vers un objectif commun. Le modèle de cartographie dépend entièrement de vous, mais il pourrait aimer celui-ci.

Responsabilités de l'équipe

Il est important de définir clairement le domaine dans lequel chaque équipe opère. Si une équipe travaille avec du code, précisez les services qu'elle utilise et ceux qu'elle possède. Étonnamment, ces valeurs peuvent souvent être différentes. Déterminez si l'équipe opère uniquement au sein d'un seul département ou s'il s'agit d'une équipe de plate-forme travaillant sur des fonctionnalités de base utilisées par d'autres équipes sans les modifier directement.

Créer un tableau peut être très utile, avec les colonnes suivantes : nom de l'équipe, département, liste des services détenus, liste des services généraux que l'équipe peut modifier mais ne possède pas (idéalement, il ne devrait pas y avoir de tels services) et une brève description. . Ce tableau vous aidera à déterminer si plusieurs équipes travaillent sur la même base de code, ce qui entraîne des conflits, ou s'il y a un manque de clarté concernant leurs domaines de responsabilité. Cela peut également révéler si une équipe corrige principalement des bugs ou se lance dans diverses tâches sans objectif clair.

Ce niveau de détail est crucial pour identifier les chevauchements, les conflits et les lacunes dans les responsabilités de l'équipe, garantissant ainsi une collaboration plus fluide et une exécution plus efficace du projet.

Responsabilités de l'employé

En plus de décrire les équipes, il est crucial de comprendre les postes des employés en général et de préparer une description détaillée de leurs responsabilités. Souvent, ce que la direction envisage peut différer considérablement de ce que font réellement les employés. Le secteur du développement de logiciels occupe des postes très variés et les attentes peuvent varier considérablement d’une entreprise à l’autre. Par exemple, le rôle d'un responsable de l'ingénierie peut différer considérablement, sans parler des rôles tels que les responsables de la livraison, les scientifiques des données, les architectes, les responsables techniques, etc. Dans certaines entreprises, une seule personne peut être amenée à remplir plusieurs rôles.

Définir des attentes claires pour chaque poste est essentiel. Cette clarté permet non seulement de suivre correctement les activités, mais garantit également que les employés comprennent ce que l'on attend d'eux et ce qui ne relève pas de leur champ d'action. Cela s'applique à tous les postes au sein de l'organisation. Des définitions claires des rôles aident à éviter les chevauchements, à réduire la confusion et à garantir que chacun travaille vers des objectifs communs de manière efficace et organisée.

Processus de livraison des fonctionnalités

À présent, vous devriez avoir une compréhension claire de la structure de votre entreprise, de la hiérarchie des employés et de leurs responsabilités. Même si les choses peuvent sembler déroutantes, l’objectif est d’abord de comprendre l’état actuel avant d’apporter des modifications. Il est maintenant temps de décrire votre processus de livraison de fonctionnalités, c'est-à-dire comment les fonctionnalités métier passent de l'idée initiale à la production.

S'il vous plaît, ne vous concentrez pas ici sur les aspects techniques tels que CI/CD, mais sur le flux de l'entreprise vers les développeurs, en supposant que les développeurs écrivent du code et le déploient directement en production. L'objectif est d'identifier tous les problèmes de votre processus, de l'entreprise à l'équipe, et de voir dans quelle mesure les employés s'y conforment.

Considérez ces aspects :

• À quelle fréquence planifiez-vous de nouvelles fonctionnalités et assignez-vous du travail à chaque service et équipe ?
• Comment définir et mesurer les indicateurs clés de performance ?
• Utilisez-vous des jalons ? Qui est impliqué dans leur préparation initiale ? Comment les planifiez-vous avec l’équipe ?
• Qui coordonne le processus de planification et d’exécution ?
• Êtes-vous vraiment une entreprise agile ? Utilisez-vous des frameworks comme SAFe, Prince2 ou PMP, ou avez-vous quelque chose de personnalisé qui fonctionne pour vous ?
• Comment gérez-vous les tâches complexes inter-équipes et contrôlez-vous les progrès ? Avez-vous une approche structurée ou comptez-vous que les problèmes seront résolus d’une manière ou d’une autre ?

N'oubliez pas que chaque niveau de gestion et de reporting ajoute de la complexité et de l'incertitude, quelle que soit la direction. En fin de compte, votre diagramme de processus doit répondre à une question simple : « Comment ?

Vous pouvez jouer avec les modèles et les ajuster à vos besoins. Voici un exemple de très haut niveau de processus de livraison sans acteurs clés qui régulent la livraison mais avec des délais.

Si vous ne savez pas comment créer ce diagramme, envisagez d'utiliser BPMN (Business Process Model and Notation) ou un format plus simple comme des rectangles et des lignes pour garantir la clarté et la compréhension entre toutes les parties prenantes. La clé est de rendre le processus clair et compréhensible.

Recueillir des commentaires

Une fois que vous avez cartographié la structure de l'entreprise, la hiérarchie des employés, les équipes et les responsabilités des postes, ainsi que le processus de livraison, partagez toutes vos conclusions avec l'organisation et menez une enquête, de préférence anonyme. Cette référence met en évidence le fonctionnement de votre entreprise. Même si vous avez peut-être préparé cet aperçu vous-même ou délégué certaines tâches, il est probable que les développeurs, les concepteurs et les analystes n'aient pas été directement impliqués. Leurs commentaires sont cruciaux pour évaluer l’exactitude de vos résultats.

Demandez aux employés d’évaluer la qualité de votre documentation. Que pensent-ils du processus de livraison ? Est-ce que cela reflète vraiment la façon dont les choses sont faites ? Où voient-ils des obstacles ?

Attendez-vous à une variété de plaintes et de commentaires qui vous aideront à affiner vos conclusions pour mieux correspondre à la réalité des opérations de l'entreprise. Ces commentaires sont essentiels car le contexte se perd souvent à travers plusieurs niveaux hiérarchiques, et la collecte des commentaires de tous les niveaux fournira une image plus claire et plus précise de l'organisation.

Résultats de l'estimation

Maintenant que vous disposez d’une description complète du fonctionnement de votre entreprise ou de vos services, vous pouvez commencer à analyser et rechercher les problèmes potentiels. Cette base de référence fournit un point de départ clair pour comprendre et résoudre les problèmes.

Voici quelques domaines sur lesquels se concentrer :

• Vos départements sont-ils structurés ? Les lignes hiérarchiques sont-elles claires ?
• Les supérieurs hiérarchiques peuvent-ils réellement fournir un feedback concernant leur domaine de responsabilité ?
• Y a-t-il de la confusion ou de l’incertitude dans la transformation des exigences métier en tâches techniques ?
• Y a-t-il des dépendances envers d’autres équipes qui entraînent des retards lors du développement ?
• Les employés sont-ils impliqués dans des activités qui ne relèvent pas de leur domaine de responsabilité principal et qui entravent leurs tâches principales ?
• Dans quelle mesure la hiérarchie des employés s’aligne-t-elle sur la structure de l’équipe ?
• La hiérarchie hiérarchique est-elle efficace ou existe-t-il des lacunes dans la communication et le contexte ?
• Est-ce que différentes équipes travaillent sur les mêmes services, ce qui entraîne des conflits et une perte de temps pour décider de la répartition des tâches ?
• Existe-t-il des équipes ou des départements sans responsabilités clairement définies ou avec des acteurs clés manquants ?
• Certaines équipes ne sont intégrées dans aucun département ?

À la fin, vous pourrez préparer une liste des problèmes réels rencontrés par votre entreprise, sur lesquels vous travaillerez. Donnez-leur la priorité, depuis les améliorations critiques qui nécessitent une interaction immédiate jusqu'aux améliorations « bonnes à avoir ».

Comment apporter des modifications

Vous vous demandez peut-être : « Tout cela semble bien, mais comment puis-je réellement améliorer les choses ? » C'est une bonne question, et la réponse honnête dépend des problèmes spécifiques que vous identifiez et des besoins de votre entreprise. Cependant, un conseil crucial est d’éviter de tenter de tout changer d’un coup. Au lieu de cela, mettez en œuvre de petits changements progressivement, évaluez les résultats et itérez. N'oubliez pas que l'approche agile fonctionne non seulement dans le développement de logiciels, mais peut être appliquée à tout type de changement organisationnel.

Voici quelques étapes pour guider votre processus d’amélioration :

• Assurez-vous que les employés savent exactement ce qu’impliquent leurs rôles et ce qui ne relève pas de leurs responsabilités.
• Créez des départements ou des domaines bien définis et affectez des équipes spécifiques à chaque domaine.
• Définissez des domaines de responsabilité clairs et minimisez les chevauchements entre les départements et les équipes.
• Pensez à vous familiariser avec l'approche Team Topologies, qui présente des équipes de plate-forme, alignées sur les flux, habilitantes et sous-systèmes complexes pour couvrir divers aspects du développement logiciel.
• Examinez et ajustez la hiérarchie de vos employés pour l'aligner sur les domaines et les équipes nouvellement créés.
• Assurez-vous que les structures de reporting sont claires et que le suivi des progrès est simple.
• Choisissez la méthodologie ou le cadre que vous utiliserez pour la fourniture de fonctionnalités et le suivi des résultats.
• Testez les changements sur n'importe quel département, de préférence non critique, et évaluez l'impact, affinez votre approche en fonction des commentaires et des résultats.
• S'améliorer continuellement en appliquant l'état d'esprit choisi aux changements organisationnels.

En suivant ces étapes, vous pouvez apporter des changements éclairés et progressifs qui amélioreront progressivement l'efficience et l'efficacité de votre organisation.

Résumé

Mon objectif était de mettre en évidence les problèmes courants qui peuvent survenir dans n'importe quelle entreprise ou département. J'ai intentionnellement évité de recommander des cadres ou des approches spécifiques, car chaque entreprise a des objectifs et des structures uniques, et il est crucial de décider ce qui vous convient le mieux.

Encore une fois, il est facile de rejeter la faute sur les développeurs, mais n'oubliez pas qu'ils peuvent ne pas être au courant des priorités de l'entreprise ou être bloqués par un processus de livraison peu clair. Parfois, l’entreprise elle-même crée inconsciemment des bloqueurs. J'espère que cet article vous aidera à faire les premiers pas vers une amélioration.