Votre équipe termine des tickets, pourtant la date de lancement recule. Avant de chercher des développeurs supplémentaires, examinez les fonctionnalités qui n'arrivent jamais jusqu'aux utilisateurs. Une attente de validation et une difficulté de réalisation demandent des réponses différentes.
Relire le parcours des derniers changements
Pour chaque livraison récente, notez le début du développement, la première revue, la validation métier et la mise en production. Ajoutez le motif des interruptions. Gardez les petits correctifs séparés des nouvelles fonctionnalités : leurs délais ne racontent pas la même chose.
Si les changements attendent surtout un arbitrage, désignez un responsable disponible. Si une compétence technique bloque plusieurs fonctionnalités déjà cadrées, préparez un renfort sur cette compétence.
Choisir un pilote qui renseigne la décision
Confiez un parcours complet à l'équipe externe, avec les règles métier et les dépendances identifiées. Votre référent interne doit pouvoir relire le code et accepter le résultat. Consignez aussi le temps qu'il y consacre ; ce temps appartient au coût du pilote.
Décider après la livraison
Comparez le délai de réalisation, les corrections nécessaires et les attentes évitées. Une hausse du nombre de tickets fermés ne prouve pas que le produit arrive plus vite chez le client. Demandez un dossier de livraison contenant les vérifications et les décisions encore ouvertes avant d'étendre le périmètre.
Un exemple de diagnostic à préparer
Supposons que votre prochain lot soit un import client. Le développement peut attendre un exemple de fichier, la décision sur les doublons ou la disponibilité d'une API. Notez ces attentes séparément. Une équipe supplémentaire peut développer les validations confirmées, mais elle ne peut pas décider seule quelle donnée fait autorité dans votre entreprise.
Préparez un dossier comprenant le parcours actuel, un exemple autorisé et les décisions encore manquantes. Demandez au partenaire de proposer le plus petit résultat utilisable. Son estimation doit distinguer réalisation, clarification et intégration. Le responsable produit peut ensuite voir quel travail avance réellement avec un renfort.
Les éléments à comparer dans les propositions
| Élément | Preuve à demander |
|---|---|
| Compréhension du retard | Causes confirmées et inconnues restantes |
| Premier lot | Parcours complet et critères d'acceptation |
| Contribution interne | Décideurs et revues nécessaires |
| Livraison | Code, tests et procédure de déploiement |
| Poursuite | Réserves à lever avant le lot suivant |
Un partenaire qui propose immédiatement plusieurs développeurs doit pouvoir expliquer leur travail simultané et les dépendances communes. Si chaque tâche attend la même personne interne, préparez d'abord sa disponibilité ou une délégation précise.
Relire le pilote avec le métier
À la fin du lot, demandez aux utilisateurs si le problème initial est effectivement traité. Vérifiez le fonctionnement sur les cas difficiles qui avaient été retenus. Le bilan doit mentionner les corrections, les décisions tardives et les points d'exploitation encore ouverts.
Gardez les observations sur plusieurs livraisons lorsque vous cherchez à estimer un rythme durable. Un premier lot peut comporter un temps de prise en main élevé ou bénéficier d'un périmètre exceptionnellement simple. Ces conditions doivent être explicites avant de comparer son résultat à la roadmap entière.
À lire aussi : Livrer une fonctionnalité SaaS promise à un client sans désorganiser la roadmap. Présentez votre périmètre à Sky Vaults.