Objectifs de l’équipe – Collaboration

Poursuivant notre série sur les objectifs d’équipe, il existe plusieurs formes de collaboration qui sont essentielles, mais souvent déroutantes pour les organisations de produits, car elles optimisent l’autonomie et l’autonomisation des équipes.

Objectifs partagés

La première et la plus fondamentale des formes de collaboration est le concept d’objectif partagé. Pour un objectif important, il n’est pas du tout inhabituel que plusieurs équipes aient le même objectif.

Ceci est particulièrement courant dans le cas des initiatives de grande entreprise (qui sont essentiellement des problèmes suffisamment importants pour nécessiter l’aide de nombreuses, voire de toutes les équipes produit).

L’exemple le plus simple en est le cas lorsqu’une équipe produit d’expérience et une équipe plateforme ont le même objectif, car l’équipe plateforme doit fournir un ou plusieurs nouveaux services pour permettre à l’équipe produit d’expérience.

Dans ce cas, normalement, les équipes collaboreront pour établir une forme simple de contrat les unes avec les autres sous la forme d’une API, puis les deux procéderont à la découverte de leurs côtés, puis elles collaboreront à nouveau sur les tests et la livraison.

Une autre forme d’objectif partagé est lorsque plusieurs équipes combinent temporairement leurs talents pour résoudre un problème particulièrement difficile. Surtout sur des problématiques bénéficiant d’une palette de compétences différentes, le rapprochement des équipes peut souvent apporter les connaissances et la synergie nécessaires pour trouver rapidement une solution efficace.

Dans certaines situations, les équipes co-localiseront pendant quelques jours ou une semaine dans ce qu’on appelle parfois un «essaim», qui est une technique intense et hautement collaborative pour plonger ensemble sur l’un ou les deux de travail de découverte ou de livraison, pour un problème particulièrement difficile.

Objectifs communs

Une autre forme de collaboration consiste à demander à plusieurs équipes de résoudre le même problème, mais de manière différente.

La raison en est vraiment la gestion des risques. Si le problème est difficile, nous savons qu’il est très difficile de savoir quelle approche, le cas échéant, produira les résultats nécessaires. Nous pouvons donc demander à plusieurs équipes de poursuivre et espérer qu’au moins une de ces équipes sera en mesure de générer l’impact nécessaire. Ce serait bien sûr encore mieux si tous avaient un impact significatif, mais nous savons que c’est peu probable.

Un bon exemple de ceci pourrait être lorsque l’un des domaines prioritaires est le taux de désabonnement d’abonnés, où trop de nos clients quittent le service. Il existe bien sûr de nombreuses façons de résoudre ce problème, et avoir plusieurs équipes pour résoudre ce problème sous plusieurs angles est souvent une bonne stratégie.

Dans ce cas, les équipes devront communiquer pour s’assurer qu’il n’y a pas de conflits entre les travaux, mais normalement, chaque équipe traite en fonction de la perspective et de l’angle de son équipe, et du code et de la technologie qu’elle possède, de sorte que ces approches sont généralement largement indépendant et cumulatif.

L’une des questions qui se posent souvent avec des objectifs communs est de savoir comment attribuer les progrès à une équipe spécifique lorsque plusieurs équipes effectuent des changements en parallèle. C’est ce qu’on appelle le problème d’attribution de produit, et la réponse standard à cela est le test A / B, qui isolera la contribution d’une équipe spécifique (gardez à l’esprit que parfois le travail aide, parfois ça fait mal, et parfois impact).

Le point d’ordre supérieur est qu’il est normal et souvent sage d’avoir plusieurs équipes poursuivant les mêmes objectifs sous une forme ou une autre.

Les entreprises qui évitent les objectifs partagés ou communs au nom de l’autonomie ou de la communication, limitent souvent leur capacité à résoudre les problèmes les plus difficiles et les plus importants.