Du lancement jusqu’au régime de croisière, il convient d’adapter son équipe pour se plier aux besoins liés aux développement de sa solution logicielle SaaS. Cette nécessité d’organiser le travail se pose pour un lancement d’une nouvelle activité mais également pour un changement de modèle économique notamment en basculant du modèle on-premice au modèle SaaS.
Mettre le produit au coeur du dispositif
Comme principe structurant de l’organisation, on peut partir de la capacité technique pour faire le produit ou à l’inverse partir du besoin produit et aller vers la réalisation technique. Sans que cela soit une règle infaillible, adopter une approche sur la base du besoin marché semble permettre le bon déroulement car au final c’est le marché qui aura le dernier mot. Il faut donc mettre le produit au centre de l’organisation
Un responsable produit doit être impliqué dans l’équipe de développement, en interaction directe avec les développeurs et en charge de la définition des lignes directrices. Pour construire les réflexions produit, il convient de s’appuyer sur les besoins des clients et d’adapter en permanence le produit en fonction des usages effectivement observés.
Scinder en « teams »
Pour gagner en efficacité, en agilité, il convient de mettre en place des équipes restreintes de 5 personnes environ. Dès que l’équipe grossit, il ne faut pas hésiter à garder cette logique de petite cellule projet et d’organiser le travail en « teams ». C’est un moyen d’augmenter l’implication de tous, d’éviter des redondances qui diffusent les responsabilités. Aussi, dans une petite équipe, chacun comprend ses responsabilités, se concentre sur son périmètre d’intervention et peut s’engager sur les livrables.
En outre, cela permet de mettre en place une dynamique globale entre les équipes, avec des pratiques différentes qui peuvent donner lieu à des échanges d’une équipe à l’autre. Plutôt que de mettre en place un cadre stricte sur les modes opératoires à appliquer systématiquement, cela permet de travailler sur les objectifs et de laisser la liberté aux équipes pour s’organiser entre elles sur la base des livrables et des engagements qu’elles ont pris en charge.
Soutenir l’esprit d’équipe
La mise en commun de l’équipe passe par un lieu physique réunissant tous les membres, avec des bureaux permettant de rapidement voir les autres membres. La disposition physique des bureaux permet de créer un sentiment d’appartenance. C’est également un moyen de faciliter les communications rapides, de faire circuler plus rapidement l’information.
La place de travail pour l’équipe doit aussi permettre d’accentuer les pratiques collaboratives, chaque « team » pouvant s’approprier son lieu de travail et le personnaliser. Il peut s’agir de grands tableaux blancs pour collaborer, d’affichages, … tout ce qui peut rendre le travail de la team visible a vocation à être dans l’espace de travail.
Les réunions de l’équipe devraient également se dérouler dans cet espace, sans doute sans dépasser la fréquence hebdomadaire pour éviter de se surcharger en réunion l’équipe. Un tableau de synthèse de l’avancement et des grands jalons à suivre est affiché et mis à jour à l’occasion de ces réunions périodiques d’équipe. Il s’agit de rester « macro », le détail des tâches étant dans des outils de suivi mais surtout il faut garder cette routine de partager pour garder une dynamique d’équipe.
Coordonner les équipes
Ce qui n’est pas dans les outils de suivi n’est pas fait! Chacun est responsable d’enregistrer son travail et de le remonter dans les outils de gestion collaboratifs. Il convient de systématiser la documentation du code, les intégrations dans les dépôts de codes, les tests, pour permettre à ce que le travail développé soit intégrable par le reste de l’équipe. Les travaux qui ne sont pas intégrés doivent être considérés comme non réalisés.
Un outil de suivi de l’avancement et de l’état du code sert de référence :
- suivi de l’avancement des tâches en lien avec les objectifs de développement
- traitement des bugs applicatifs en prenant en compte la criticité
- contrôle de la qualité du code (notamment avec les tests automatiques)
- mise à jour des documentations techniques (release note, wiki…)
- enregistrement des informations pour permettre le travail ultérieur (notes pour les soumissions de code, notes pour les résolutions, explications dans le code…)
- stabilité du processus de développement
==> suivre l’avancement
La logique de cycles de développements (Sprints) permet de définir les livrables sur lesquels l’équipe s’engage pour la date de livraison. Il est donc essentiel de construire une distribution des objectifs pour le cycle de développement en découpant les tâches pour obtenir des tailles comparables et relativement indépendantes.
==> traiter les bugs applicatifs
La part des actions de correction des bugs à traiter dans le cycle est également à prendre en compte. C’est une nécessité pour garantir la confiance dans la solution tant en interne qu’en externe. Si la taille des équipes de développement le permet, il est possible de dédier une tank force pour les corrections. Si cela n’est pas possible, il convient d’affecter des travaux de correction au sein de chaque équipe.
==> contrôler la qualité du code
La mise en place d’un dépôt des sources qui sera partagé par toute l’équipe technique doit également s’accompagner de tests automatiques pour permettre le travail en équipe et de garantir que les modifications ne vont pas perturber la solution existante. IL conviendra donc de rendre les test systématiques et de s’assurer qu’ils couvrent une part très importante de la solution SaaS
==> mettre à jour les documentations
De manière transverse, il conviendra de partager des documentations pour partager la connaissance au-delà de la Team. De manière globale, il conviendra de s’assurer de la présence de documentations tant d’un point de vue purement technique (architecture logicielle, choix techniques …) que d’un point de vue fonctionnel (formation produit).
==> s’assurer de la présence des informations
Lors des revues des informations centralisées, il sera validé la présence de commentaires pour aider à pérenniser les travaux.
==> garantir une stabilité du processus de développement
Les priorités des tâches doivent être mises en place dès le début du cycle et suivies durant toute la période de développement. Les indicateurs d’avancement ont également leur importance pour piloter le travail des équipes. Il convient de ne pas bousculer les priorités de manière trop fréquente pour garder la vertue du développement selon une méthodologie incrémentale.
Mettre en place un suivi fédérateur
Il est essentiel de mettre en place une transparence sur les objectifs et leurs réalisations; si vous êtes un éditeur SaaS, votre produit est le réacteur de votre entreprise. Il faudra donc mettre en place une solution de suivi des progrès en offrant à toute votre organisation la possibilité de suivre l’avancement.
Ce partage d’information doit être suffisamment synthétique pour être compréhensible par toutes les fonctions de l’entreprise. En particulier, une vision globale sur la Roadmap produit facilement communicable aux équipes marketing, aux commerciaux voire aux clients doit être très facilement disponible. Pour ce partage d’information, il ne s’agit pas de données techniques mais bien de données d’usage produit.
Il faut également projeter les évolutions à moyen terme, en lien avec la vision de votre produit et les ambitions de votre solution SaaS. En ayant établit une dynamique d’équipe forte, sur la base de principes organisationnels simples, vous serez en mesure de gérer une montée en puissance rapide sans délaisser la qualité de votre solution SaaS.
