Web, mobile, IA, SaaS, cloud et travail produit

Les étapes se chevauchent volontairement. Le design commence dès que le premier slice est clair. Le build n'attend pas un fichier parfait. L'échelle est déjà en tête pendant que nous livrons la première version — nous ne la sur-construisons simplement pas dès le premier jour.

1. 01

   Discover

   Nous écrivons la mission avant que quiconque n'ouvre un éditeur de code.

   Les premières conversations portent sur le produit, pas sur une stack. Pour qui c'est, ce qui existe déjà, ce qui ne doit pas casser, et à quoi « terminé » ressemblerait vraiment. Si le brief est brouillon, c'est normal — nous posons des questions jusqu'à ce que ce soit assez précis pour construire dessus.

   Vous obtenez une forme écrite du travail : ce qui est dedans, ce qui est dehors, un premier slice, les risques et une façon de travailler. Vous pouvez la prendre ou la laisser. Nous préférons nous arrêter ici plutôt que de démarrer un build auquel personne ne croit.

   Ce que vous emportez

   • Un périmètre écrit court et des critères de succès
   • Ce qui est dedans, ce qui est dehors, et ce qui peut attendre
   • Un premier slice que vous pourriez livrer et dont apprendre
   • Comment nous parlerons, ferons des démos et déciderons
   
2. 02

   Design

   Vous pouvez discuter le produit tant qu'il est encore bon marché de le changer.

   Nous transformons le périmètre en quelque chose sur lequel cliquer : parcours, écrans et les quelques composants qui se répéteront. Le but n'est pas un joli fichier. C'est de trouver les endroits gênants — états vides, permissions, le troisième tap auquel personne n'a pensé — avant qu'ils ne deviennent des tickets.

   Si un prototype statique ne suffit pas, nous le spikons dans la stack réelle. Vous revoyez avec les personnes qui l'utiliseront, pas seulement celles qui l'ont commandé. Quand nous sommes d'accord, ce fichier est ce que nous construisons. Il ne part pas dans le vide.

   Ce que vous emportez

   • Des parcours cliquables et les écrans centraux
   • Un petit design system, pas un kit de 200 composants
   • Les questions ouvertes nommées, pas cachées dans les commentaires
   • Une séquence de build alignée sur le premier slice
   
3. 03

   Build

   Du logiciel qui fonctionne chaque semaine. Vous le voyez, vous l'essayez, nous ajustons.

   Les personnes du kickoff sont celles qui écrivent le code. Vous avez un dépôt sous votre contrôle, une démo hebdomadaire de quelque chose sur lequel cliquer, et un seul endroit pour les décisions. Si la semaine a été mince, nous le disons. Un statut sans logiciel qui fonctionne n'est pas un rapport d'avancement.

   Les tests, les logs et une façon de livrer s'ajoutent en cours de route — pas comme un nettoyage à la fin. Si quelque chose cloche, nous l'attrapons tant que c'est encore petit. Le périmètre peut changer ; nous écrivons le compromis pour que la facture ne soit pas la surprise.

   Ce que vous emportez

   • Un dépôt, des environnements et un chemin de release que vous possédez
   • Des démos hebdomadaires de logiciel qui fonctionne
   • Des décisions écrites, pas un historique de chat que personne ne retrouve
   • La qualité et le monitoring dans le produit, pas un projet plus tard
   
4. 04

   Scale

   Le lancement n'est pas la fin de la relation.

   La mise en production, c'est quand les vraies questions commencent : un bug en production, un changement dans l'activité, une nouvelle personne dans votre équipe qui a besoin de comprendre le code. Nous durcissons ce qui tourne déjà, mesurons ce qui compte, et continuons à livrer le slice suivant si vous nous voulez dessus.

   Vous devriez pouvoir reprendre le produit en interne. L'architecture, les tests et les notes restent chez vous. Si vous voulez que nous restions, nous resterons. Si non, vous ne devez pas vous sentir coincé.

   Ce que vous emportez

   • Un système de production que vous pouvez opérer
   • Des notes de passation que vos ingénieurs peuvent suivre
   • Le slice suivant cadré, si vous voulez continuer
   • Un support qui répond, pas un ticket dans le vide