Chaque engagement entreprise commence pareil : quelqu'un demande une phase de découverte. Deux semaines pour « comprendre le paysage ». Un mois pour « aligner les parties prenantes ». Le temps que quelqu'un écrive du code, la moitié du budget est partie et le problème original s'est transformé en quelque chose que personne ne reconnaît.
Strike existe pour empêcher ça. C'est un test de pression de 72 heures où nous déterminons si un Proof Sprint est faisable, le tarifons, et définissons les conditions exactes sous lesquelles nous l'arrêterons s'il ne fonctionne pas. Pas de théâtre de découverte. Pas d'ateliers d'alignement. Juste des décisions.
Pourquoi les réunions deviennent des trous noirs
La réunion entreprise traditionnelle a un défaut fatal : elle récompense parler plutôt que décider. La personne qui soulève le plus de préoccupations semble diligente. La personne qui demande plus de recherche semble minutieuse. Personne n'est blâmé pour ralentir les choses, mais tout le monde est blâmé si quelque chose est livré et échoue.
Protocole un : discipline horaire
Chaque sujet dans Strike a un segment de 12 minutes. Ce n'est pas une suggestion—c'est appliqué. Quand le temps est écoulé, nous enregistrons le résultat et passons à autre chose.
Douze minutes semble brutal, et ça l'est. Mais voici ce que nous avons appris : la plupart des sujets n'ont pas besoin de plus de temps. Ils ont besoin de moins d'ambiguïté.
Protocole deux : preuves plutôt qu'opinions
Les débats dans Strike se passent dans le repo, pas dans la salle.
Si vous pensez que l'architecture proposée ne passera pas à l'échelle, montrez un test de charge. Si vous pensez que le modèle de données est faux, soumettez une alternative de schéma avec des notes de migration.
Nous avons banni une classe spécifique d'objection : la préoccupation sans preuve. « Je m'inquiète pour la sécurité » n'est pas une objection. « Voici un modèle de menaces montrant trois vecteurs d'attaque non atténués » est une objection.
Protocole trois : critères d'arrêt visibles
La sortie la plus importante de Strike n'est pas le feu vert. Ce sont les lignes rouges.
Avant que quiconque s'engage dans un Proof Sprint, nous définissons exactement ce qui nous ferait abandonner. Pas un langage vague « si les choses tournent mal »—des conditions spécifiques et mesurables.
Qui s'assoit dans la salle
Strike requiert exactement quatre rôles, pas plus : propriétaire business, lead technique, représentant sécurité, et achats/finance. Si l'une de ces personnes ne peut pas assister aux 72 heures complètes, nous ne lançons pas Strike.
Ce qui en sort
Go : Un Proof Sprint tarifé avec un scope fixe, une timeline définie, des critères d'arrêt signés, et un backlog que votre équipe d'ingénierie a déjà revu et accepté.
No-go : Une décision documentée de ne pas procéder, avec des raisons spécifiques. C'est un succès, pas un échec.
Pourquoi ça marche
Strike marche parce qu'il traite la prise de décision comme un processus de production, pas social. L'inconfort est une fonctionnalité. Si votre processus de planification est confortable, il ne produit probablement pas de décisions.