Qu'est-ce que le team as a service (TAAS) et qu'est-ce que ce n'est pas ?

Team as a Service (ci-après TaaS) est à la fois un produit et une proposition organisationnelle. SEIDOR offrait déjà ce service depuis quelques années, mais en plein tsunami COVID19, il acquiert la dénomination de "obligatoire" en ce qui concerne le développement de logiciels.

Je dis que TaaS est un produit parce que chez SEIDOR nous avons quantifié les prix et les conditions de service, en attendant de convenir de la portée et de la durée du projet pour chaque cas concret. Et je dis que c'est une proposition organisationnelle, car il ne s'agit pas de mettre un groupe de personnes à partir de zéro pour écouter le client... ce n'est pas du bodyshopping. TaaS a une organisation précise qui, bien qu'elle puisse s'adapter dans des détails spécifiques au projet concret, doit respecter une structure de base bien définie.

Mais alors, en quoi le TaaS se distingue-t-il de toute autre forme d'organisation d'une équipe de travail ? L'élément différenciateur réside dans les valeurs directrices. Celles-ci ne sont pas exclusives au TaaS, elles se retrouvent dans certaines méthodologies bien connues de développement de logiciels et de gestion de projets. Et dans le TaaS, nous avons créé notre propre petit manifeste basé sur les connaissances acquises au cours de décennies d'expérience dans des projets IT.

Quels sont les valeurs directrices de TAAS ?

• Responsabilité partagée : l'équipe participe aux décisions, de sorte que chaque membre est habilité à proposer des améliorations dans la méthodologie, identifier les risques, assumer des responsabilités (ou les déléguer)... Tous les membres de l'équipe sont constamment informés de l'objectif du projet, de l'état actuel et de ce que font les autres.
• Compagnonnage : vital pour une bonne collaboration. Et c'est surtout ce dont on a besoin pour que le TaaS soit performant, une collaboration ouverte entre tous les membres de l'équipe et avec le client. Puisque le compagnonnage fonctionne mieux dans des équipes réduites, de pas plus de 10 personnes, nous maintenons les équipes TaaS en dessous de ce chiffre. Il n'y a aucune raison pour qu'il n'y ait pas plus d'une équipe TaaS travaillant sur le même projet si l'ampleur le nécessite.
• Transparence : elle doit être la même que celle d'un bon restaurant japonais qui permet de voir le travail en cuisine à travers une vitre. Étant donné que l'équipe TaaS travaille à distance, et non pas dans les bureaux du client, la transparence se matérialise par la publication du travail réalisé sur un outil en ligne auquel accèdent à la fois les membres de l'équipe et notre client.
• Mise à jour quotidienne : c'est fondamental. La discipline de mettre à jour quotidiennement le degré de progression permet la détection précoce des écarts et facilite leur atténuation. En fait, savoir que les progrès sont examinés chaque jour prédispose psychologiquement à atteindre de petits objectifs en vue des objectifs généraux du projet. Chaque jour, les risques du projet sont examinés, les blocages ou les dépendances entre les tâches sont partagés.
• Confiance, entre les membres de l'équipe et avec le client. Dans le modèle TaaS, le client peut agir comme un membre de l'équipe. Il est informé de tout et a accès à tout à tout moment. Toutes les informations sont dans le cloud.

Qu'est-ce qui ne fait pas fonctionner le TAAS ?

Il est également nécessaire de bien garder à l'esprit les éléments qui ne font pas fonctionner le TaaS. Voici quelques-uns des points fallacieux dans lesquels il est facile de tomber et qui, malgré leur valeur apparente, sont souvent plus un fardeau qu'une aide efficace :

• Les outils : parfois, il semble que nous utilisons des jouets plutôt que des outils. Nous avons trop souvent vu toute la confiance dans l'organisation d'un travail être placée dans l'outil utilisé, comme si tout allait bien fonctionner simplement parce qu'on utilise un logiciel coûteux. C'est l'une des fausses idées les plus étonnamment répandues dans notre domaine. Un bon TaaS peut fonctionner même avec seulement un crayon et du papier, bien que ce soit un peu absurde de faire cela. Nous pouvons utiliser Redmine, Jira, Trello, Miro... l'univers est infini et l'outil n'a pas d'importance, ce qui compte, c'est comment il est utilisé.
• Le fanatisme méthodologique : la ligne qui sépare la rigueur du fanatisme dans les méthodologies de gestion de projets est étonnamment floue. Par coïncidence des directives générales, les méthodologies itératives s'accordent mieux avec le TaaS que les méthodologies en cascade. Cela ne signifie pas que les méthodologies en cascade ne peuvent pas être appliquées, mais que leur application peut nécessiter un effort plus important. Cela dit, les méthodologies sont comme les lois : elles ne peuvent pas prévoir tous les cas de l'univers et de la même manière qu'il existe quelque chose appelé l'esprit de la loi qui s'applique lorsque la lettre conduit à la confusion, nous avons aussi l'esprit de la méthodologie, qui nous permet d'assumer des degrés de liberté lorsque nous rencontrons des imprévus.
• La centralisation : l'une des grandes craintes du chef de projet traditionnel est la décentralisation. Le besoin de "tout contrôler" peut devenir vraiment compulsif et doit être évité à tout prix. Chaque membre d'une équipe TaaS a sa responsabilité et l'assume, y compris le client.

En résumé, le TAAS s'inspire directement du manifeste Agile (attention, du manifeste, pas de ses méthodologies) et avant tout, il vise la coopération, le progrès durable et l'amélioration continue.