Amenez les développeurs dans le processus de conception plus tôt

La plupart des gens conviennent que les développeurs ne sont pas inclus assez tôt. Le changement de gauche améliore le fonctionnement des équipes – pas juste au moment où ils travaillent.

La recherche montre systématiquement que les développeurs ne sont pas inclus assez tôt dans le processus de conception. Selon le Rapport de la collaboration 2024 de l’état de développement de concepteurseulement 10% des concepteurs estiment que la collaboration est fluide, tandis que 51% des entreprises déclarent une utilisation inefficace du temps spécialisé en raison de transfert peu clairs.

Cela met en évidence un problème fondamental: les équipes fonctionnent toujours dans des silos, traitant la conception et le développement comme des phases distinctes plutôt que des parties d’un flux de travail unifié. Mais le vrai problème ne concerne pas seulement le timing – il s’agit de changer la façon dont les équipes collaborent.

Nous sommes souvent pris en compte dans le débat des processus, des domaines et de l’expertise de chacun. Au lieu de cela, nous devons adopter une perspective d’équipe de produits. En fait, Scrum lui-même indique qu’il n’y a pas de rôles fixes, seulement des responsabilités. Nous sommes des membres de l’équipe travaillant vers le même résultat.

Lorsque nous parlons de transferts, nous impliquons souvent un processus linéaire, où les concepteurs terminent leur travail, puis les développeurs prennent le relais. Plus cet écart est grand, plus le transfert est coûteux et long. Bien que l’amélioration des transferts puisse aider, elle ne traite que le symptôme. La vraie solution réside dans l’élimination de l’écart avec une collaboration continue.

Pour les concepteurs, la participation précoce des développeurs apporte de précieuses informations techniques qui façonnent de meilleures décisions de conception.

Pour les développeurs, participer plus tôt signifie une compréhension accrue et une mise en œuvre plus efficace. Au lieu de remettre des travaux, les équipes devraient co-créer des solutions dès le début, s’alignant ensemble sur les contraintes et les possibilités.

Le changement

Les équipes ne créent pas de solutions parfaites – elles trouvent la meilleure solution possible dans les contraintes. Le développement de produits est un défi économique. Les équipes doivent équilibrer le coût, la dette, le temps de marché, les gains potentiels, les besoins des clients et la valeur commerciale globale.

Le retour sur investissement est essentiel pour les concepteurs et les développeurs.

La collecte de preuves est essentielle. Les développeurs fournissent des informations critiques sur ce qui est réalisable et durable. Une erreur courante que les concepteurs font est de supposer qu’ils connaissent la meilleure solution sans prendre en compte dans les contraintes d’ingénierie. Les développeurs, en revanche, peuvent construire presque tout, mais à quel prix?

Comme un développeur avec qui j’ai collaboré l’a souvent dit: «Je peux transformer notre logiciel en cafetière. La question est de savoir combien de temps et d’argent avez-vous?»

Cette citation capture parfaitement la réalité du développement de produits. Il ne s’agit pas de savoir si quelque chose est possible – il s’agit de savoir si cela a du sens compte tenu des contraintes.

La participation précoce des développeurs apporte des informations techniques essentielles qui ont un impact direct sur les décisions de conception. Au lieu de concevoir de manière isolée et de découvrir plus tard des problèmes de faisabilité, les équipes devraient s’aligner tôt.

C’est l’essence de la collaboration, de la prise de décision et de la résolution de problèmes au début du processus, où elle a le plus grand impact.

Parce que dans le développement de logiciels, le timing est important. Plus un problème est découvert, plus il est cher et long qu’il est à résoudre.

Le piratage

Mais beaucoup d’entre nous opèrent dans des environnements avec des processus matures, une politique de produits complexes et une réalité précipitée.

Le changement est difficile. Mais il existe un moyen d’introduire une véritable collaboration sans trop de perturbation: les hackathons.

Récemment, j’ai travaillé sur un projet où nous avons dirigé des hackathons avec des experts du domaine et des utilisateurs. Au lieu de suivre notre cycle de mêlée normal, nous avons utilisé la collaboration croisée en temps réel:

• Les utilisateurs ont présenté des idées.
• L’équipe a rassemblé les exigences ensemble.
• Les concepteurs et les développeurs ont réfléchi dans la même pièce.
• Nous nous sommes concentrés sur les prototypes.
• Nous avons documenté des apprentissages et des travaux de suivi.

Le résultat? Une compréhension partagée, des commentaires plus rapides et une collaboration plus fluide – sans la friction d’un transfert traditionnel.

Les hackathons suppriment beaucoup de contraintes. Ils aident les équipes à se concentrer d’abord sur la résolution du problème de base. Ils favorisent également une collaboration plus approfondie, aidant les concepteurs et les développeurs à comprendre la pensée de l’autre.

Cela ne doit pas être un événement unique. L’intégration de «Hackathons de fonctionnalité» – même pour une demi-journée – peut améliorer considérablement la collaboration.

Mais un hackathon ne fournit pas de logiciel de qualité de production, alors que fait?

La spécification

Après avoir exécuté des hackathons, l’étape suivante consiste à l’intégrer dans votre cycle normal – avec des raffinements interactifs.

Les séances de raffinement dans SCRUM peuvent se transformer en conférences d’une heure ou en revues de documents. Au lieu d’une autre réunion passive, un raffinement interactif fonctionne comme un mini-hackathon.

Pour le faire fonctionner, le développeur ou l’architecte principal, le propriétaire du produit et le concepteur devraient préparer au préalable la portée pour en tirer le meilleur parti du temps.

La session suit le cadre du 4C:

• Collecter – Rassemblez le contexte, les exigences, les idées et les contraintes.
• Choisir – Identifier les décisions critiques, aligner et choisir la direction.
• Créer – Travaillez ensemble pour générer des solutions et des spécifications.
• Commettre – Finaliser les accords et mettre à jour la spécification.

À la fin de la session, l’équipe devrait avoir une spécification couvrant la plupart des travaux. Les travaux restants peuvent être affinés individuellement.

Le véritable avantage des raffinements interactifs est pré-alignement sur le pourquoi, quoi, comment et quand. Si l’équipe est déjà d’accord, avez-vous vraiment besoin d’un fichier Figma pour afficher chaque petit détail?

Mais la réalité est que les équipes communiquent principalement par le biais de réunions, de messages et de discussions – outils de gestion de projet. Seulement 28% de la collaboration se produit dans les outils de projet désignés, ce qui signifie que les décisions clés et la justification se perdent souvent, et la documentation partagée n’est pas priorisée.

Mais la conception consiste à capturer des décisions dans un document de spécification, à vérifier l’alignement avant le début du développement.

J’indique souvent les concepteurs de passer plus de temps sur une histoire utilisateur bien écrite plutôt que sur un fichier Figma parfait pour les pixels. Une spécification n’est pas seulement un document écrit – c’est une collection de tous les matériaux nécessaires, qu’ils soient visuels, textuels ou graphiques. Ensemble, ces éléments forment le fondement de la conception.

Dans un projet, j’ai travaillé en étroite collaboration avec les architectes sur les diagrammes C4 avant de commencer les conceptions. Ce type d’alignement supprime beaucoup d’ambiguïté et est un excellent exemple de spécification visuelle qui aide les concepteurs et les développeurs à rester sur la même longueur d’onde.

Déplacez-le, piratez-le, spécifiez-le

Le hack ultime ne consiste pas seulement à déplacer les choses plus tôt – il s’agit de rassembler les bonnes personnes au bon moment. En impliquant plusieurs perspectives tôt et en définissant en collaboration une spécification partagée, les équipes s’alignent dès le début.

Au lieu de simplement combler l’écart, nous commençons ensemble, divergeons pour explorer à la fois la conception et les perspectives techniques, puis converger vers un document de spécification unifié et bien informé – la spécification.

Ce changement améliore le fonctionnement des équipes – pas juste au moment où ils travaillent.

• Impliquez les développeurs tôt pour faire surface les contraintes avant de devenir des problèmes.
• Utilisez des hackathons pour favoriser la collaboration en temps réel et la compréhension partagée.
• Allez au-delà des réunions de raffinement passive. Les transformer en séances de travail interactives.
• Capturez les décisions où le travail se produit – dans une spécification, non enterrée dans des messages ou des fichiers de conception.

Une grande spécification n’est pas seulement la documentation – c’est un engagement envers la clarté, la collaboration et l’exécution.

Commencez petit. Exécutez un hackathon de fonctionnalité. Transformez votre prochaine session de raffinement en un atelier interactif. Plus vous vous alignez plus tôt, meilleur sera votre logiciel.