Cada engagement empresarial comienza igual: alguien pide una fase de descubrimiento. Dos semanas para "entender el panorama". Un mes para "alinear stakeholders". Para cuando alguien escribe código, la mitad del presupuesto se ha ido y el problema original se ha transformado en algo que nadie reconoce.
Strike existe para prevenir eso. Es una prueba de presión de 72 horas donde determinamos si un Proof Sprint es viable, lo cotizamos y definimos las condiciones exactas bajo las cuales lo mataremos si no funciona. Sin teatro de descubrimiento. Sin talleres de alineación. Solo decisiones.
Por qué las reuniones se convierten en agujeros negros
La reunión empresarial tradicional tiene un defecto fatal: recompensa hablar sobre decidir. La persona que plantea más preocupaciones parece diligente. La persona que pide más investigación parece minuciosa. Nadie recibe culpa por ralentizar las cosas, pero todos reciben culpa si algo se lanza y falla.
Así que las reuniones se expanden. Generan subcomités. Crean elementos de "parking lot" que nunca salen del estacionamiento. Tres semanas después, tienes 47 personas en una invitación recurrente, una carpeta de SharePoint llena de presentaciones que nadie lee, y exactamente cero decisiones tomadas.
Protocolo uno: disciplina de reloj
Cada tema en Strike tiene un segmento de 12 minutos. Eso no es una sugerencia—se aplica. Cuando se acaba el tiempo, registramos el resultado y avanzamos.
Doce minutos suena brutal, y lo es. Pero esto es lo que hemos aprendido: la mayoría de los temas no necesitan más tiempo. Necesitan menos ambigüedad. Cuando le dices a alguien que tiene una hora para presentar, llenará la hora. Cuando le dices que tiene doce minutos, irá al grano.
Protocolo dos: evidencia sobre opiniones
Los debates en Strike ocurren en el repositorio, no en la sala.
Si crees que la arquitectura propuesta no escalará, muestra una prueba de carga. Si crees que el modelo de datos está mal, envía una alternativa de esquema con notas de migración. Si crees que el cronograma no es realista, señala una construcción similar y su duración real.
Hemos prohibido una clase específica de objeción: la preocupación sin evidencia. "Me preocupa la seguridad" no es una objeción. "Aquí hay un modelo de amenazas que muestra tres vectores de ataque sin mitigar" es una objeción.
Protocolo tres: criterios de salida visibles
La salida más importante de Strike no es la luz verde. Son las líneas rojas.
Antes de que alguien se comprometa con un Proof Sprint, definimos exactamente qué nos haría abortar. No un lenguaje vago de "si las cosas van mal"—condiciones específicas y medibles. Latencia por encima de 200ms en la ruta crítica. Revisión de seguridad que detecte cualquier vulnerabilidad P0. Integración con el sistema legacy que requiera más de 40 horas de ingeniería inversa.
Quién se sienta en la sala
Strike requiere exactamente cuatro roles, no más: propietario del negocio, líder técnico, representante de seguridad, y adquisiciones/finanzas. Si alguna de estas personas no puede asistir las 72 horas completas, no ejecutamos Strike.
Qué sale
Al final de 72 horas, tienes uno de dos resultados:
Adelante: Un Proof Sprint con precio, alcance fijo, cronograma definido (siempre 10 días o menos), criterios de salida firmados, y un backlog que tu equipo de ingeniería ya revisó y aceptó.
No adelante: Una decisión documentada de no proceder, con razones específicas. Esto es un éxito, no un fracaso. Descubrir en 72 horas que algo no es viable es infinitamente mejor que descubrirlo en 6 meses.
Por qué esto funciona
Strike funciona porque trata la toma de decisiones como un proceso de producción, no social. La mayoría de la planificación empresarial falla porque está diseñada alrededor del consenso. Strike optimiza para la claridad. Es incómodo. Pero les gustan los resultados.