Principes de produit d'Intercom : construire par petites étapes pour offrir une valeur client maximale

Les changements importants sont difficiles à comprendre et plus difficiles à déboguer.

Chez Intercom, nous livrons des changements complexes en une série de petites étapes contrôlées et faciles à comprendre. Les petites modifications sont plus faciles à créer et plus rapides à réviser, ce qui nous permet d'offrir plus rapidement de la valeur aux clients.

Ceci est le septième article d'une série explorant les principes de nos produits . Ici, Aidan discute de notre principe d'ingénierie "Construire par petites étapes".

Personne ne réussit tout le temps

Des erreurs se produisent dans chaque équipe, dans chaque entreprise du monde. Une fois que vous acceptez que vous n'allez pas tout faire correctement tout le temps, vous pouvez vous ajuster de l'une des deux manières suivantes :

• Essayez de corriger les erreurs avant de les expédier, en prenant des mesures pour valider ou vérifier votre travail.
• Accordez-vous de la place pour vous tromper, apprenez de l'erreur et ajustez-vous rapidement pour la corriger.

Si vous avez déjà plongé des semaines dans un changement, il y a souvent moins de place pour vous tromper. Cela peut vous amener à vous fier à la validation pour éviter les surprises lorsque vous expédiez votre modification. La validation a sa place, mais c'est un piètre substitut au déploiement de quelque chose de réel. Plus vous devez effectuer de validation avant l'expédition, plus il faut de temps avant de pouvoir itérer ou passer à la fonctionnalité suivante - cela vous ralentit finalement.

Lors de l'expédition d'un changement, nous visons à contrôler :

• Le nombre de variables affectées : plus il y a de variables affectées lors d'un changement, plus il est difficile de déterminer quelle partie du changement a causé le problème. En réduisant la taille de chaque étape, nous resserrons la boucle de rétroaction et nous préparons à apprendre et à nous ajuster beaucoup plus rapidement si nous en avons besoin.
• La taille du changement : en réduisant la taille de nos changements, nous réduisons également le rayon de souffle de chaque changement. Il est important de tester les modifications, mais il y a peu de choses que la validation initiale attrapera. De plus petits changements nous permettent de concentrer notre attention sur l'atteinte progressive de votre objectif, et de ne pas trop nous préoccuper de la perfection de chaque changement.
• Quels clients subissent le changement : nous nous appuyons sur les indicateurs de fonctionnalité pour valider les modifications apportées à la production et les diffuser progressivement aux clients.

Nous ne savons pas avec certitude si la fonctionnalité résoudra le problème d'un client tant qu'il ne l'aura pas entre les mains. Cet engagement à expédier rapidement de petites itérations est lié à un autre principe d'Intercom : expédier pour apprendre.

Gérer la complexité

Construire au sein de systèmes complexes est un défi. Lorsque des bogues apparaissent lors de changements importants ou que des fonctionnalités gonflées manquent la cible, il est difficile d'identifier le problème spécifique. De petites étapes facilitent la validation, la modification et la progression - en étant sûr que vous construisez sur un terrain solide.

Les grands changements incluent de nombreuses hypothèses :

• Hypothèses externes sur l'impact de votre changement sur les flux de travail de vos clients.
• Hypothèses internes sur la façon dont les différentes parties de votre changement interagissent et dépendent les unes des autres.

Bien que vous puissiez faire de votre mieux pour vérifier les hypothèses externes, il est souvent plus rapide et plus robuste d'expédier votre modification et de valider ou d'ajuster. Les hypothèses internes sont là où la complexité peut s'infiltrer. Lorsque votre changement devient suffisamment important pour englober plusieurs blocs de construction qui dépendent tous les uns des autres, les tester ensemble peut être risqué. Il est beaucoup plus sûr de les publier progressivement, en les construisant les uns sur les autres et en surveillant l'impact au fur et à mesure.

La vitesse durable donne de l'élan

La vitesse est excellente, mais une vitesse durable et fiable change la donne. L'expédition d'un changement important signifie qu'il y a beaucoup plus de chance qu'il réussisse et un risque plus élevé de surprises par rapport à une série de petites itérations rapides.

" Un cycle serré d'envoi de petits changements, d'apprentissage et d'itération crée une forte dynamique "

Un cycle serré d'envoi de petits changements, d'apprentissage et d'itération crée une forte dynamique. Il élimine le besoin d'avoir raison du premier coup, encourage une prise de décision plus rapide et réduit le rayon d'explosion des erreurs. De plus, la division du travail en unités plus petites signifie que les ingénieurs peuvent progresser en parallèle, ce qui permet à l'équipe d'avancer plus rapidement dans son ensemble.

Construire par petites étapes nécessite une bonne culture d'équipe

Construire par petites étapes ne se fait pas par accident, il faut une intention délibérée et le bon environnement. Notre culture d'équipe et notre pile d'infrastructures jouent un rôle crucial dans notre capacité à apporter rapidement de petits changements.

Une fois que les équipes ont compris l'importance d'expédier rapidement de petites modifications, les évaluations par les pairs sont priorisées et réalisées plus rapidement. Étant donné que les petits changements sont plus faciles à comprendre et à réviser, il y a plus de chances que des bogues soient détectés à chaque étape. Cette compréhension et cette urgence de l'équipe accélèrent l'ensemble du processus.

« Nous avons beaucoup investi pour nous assurer qu'une fois qu'une modification est examinée et fusionnée pour être maîtrisée, il faut moins de 15 minutes pour entrer en production, y compris les tests automatisés et la validation de la mise en scène »

Lorsque les temps de déploiement ralentissent, les ingénieurs sont plus enclins à effectuer des modifications par lots, ce qui entraîne un cycle de modifications plus importantes. Nous avons beaucoup investi pour nous assurer qu'une fois qu'une modification est examinée et fusionnée pour être maîtrisée, il faut moins de 15 minutes pour entrer en production, y compris les tests automatisés et la validation de la mise en scène. C'est complètement autonome et les ingénieurs reçoivent une notification Slack automatique une fois que le changement est en ligne.

Application du principe « construire par petites étapes » à l'intégration Salesforce d'Intercom

L'année dernière, nous avons cherché à intégrer plus profondément Intercom à Salesforce, permettant aux clients de créer automatiquement des cas Salesforce à partir de conversations Intercom. Nous avons vite compris la complexité ; les conversations et les cas ne correspondent pas toujours directement et la synchronisation des données dans une relation plusieurs-à-plusieurs serait difficile du point de vue de l'ingénierie et de la conception. De plus, il y avait une grande différence dans la façon dont les clients souhaitaient utiliser cette fonctionnalité et elle devait s'intégrer à l'intégration existante dont les clients dépendent fortement.

Après avoir étudié les nombreuses implications et les compromis de conception, nous avons parqué le projet en faveur de quelque chose qui, selon nous, aurait un impact plus fiable. Nous avons failli ne pas le construire parce que nous l'avons abordé comme un grand changement au lieu d'une série de petites étapes.

Nous avons revisité le projet avec une approche différente

Il n'a pas fallu longtemps avant que notre équipe des ventes ne revienne pour souligner à quel point cette fonctionnalité était importante pour nos clients - et nous avons décidé de lui donner un autre regard. Cette fois, nous avons adopté une approche différente, en commençant par la version la plus petite possible et en contournant une partie de la complexité jusqu'à ce que nous puissions savoir ce dont les clients avaient vraiment besoin.

« Les clients avec lesquels nous avons travaillé ont vraiment apprécié le rythme auquel l'équipe a itéré et comment la fonctionnalité a évolué au jour le jour, guidés par leurs commentaires »

En deux semaines, un autre ingénieur et moi avons construit la version la plus basique de cette fonctionnalité que nous pouvions partager avec les clients. Nous l'avons fait en plusieurs petites étapes en veillant à ne casser aucun des flux de travail existants que les clients utilisaient déjà. Cela a rendu la fonctionnalité beaucoup plus tangible et les clients ont pu donner des commentaires spécifiques sur les lacunes et les améliorations du produit.

Une fois que les clients l'ont utilisé, l'équipe a itéré par petites étapes, rendant rapidement la fonctionnalité plus flexible. Au fur et à mesure que la flexibilité augmentait, le nombre de clients qui l'utilisaient augmentait également et nous avons rapidement étendu la version bêta.

Il s'est avéré que la relation plusieurs à plusieurs n'empêchait pas les clients d'utiliser la fonctionnalité et nous l'avons lancée avec succès en toute sécurité et sans cette complexité supplémentaire, ce que nous n'avons découvert qu'en commençant petit et en itérant rapidement. Les clients avec lesquels nous avons travaillé ont vraiment apprécié le rythme auquel l'équipe a itéré et comment la fonctionnalité a évolué au jour le jour, guidés par leurs commentaires.

Construire par petites étapes fonctionne pour tout le monde

Nous construisons par petites étapes, principalement parce que cela nous aide à offrir de la valeur client plus rapidement, de manière plus sûre et plus durable. Mais en plus de cela, en tant qu'ingénieur, c'est une façon plus agréable de travailler. C'est beaucoup moins stressant que d'expédier de gros changements où il y a beaucoup à faire du premier coup - et vous obtenez un coup de dopamine régulier chaque fois que vous expédiez ce sur quoi vous travaillez à la production.

Donc, si rien dans ce billet de blog ne vous convainc d'optimiser pour réduire les risques et offrir une valeur supplémentaire, vous devriez le faire parce que c'est juste plus amusant.

Vous souhaitez en savoir plus sur la façon dont nous travaillons chez Intercom ? En savoir plus.