Qué es una «software factory» (fábrica de software) y por qué una empresa de quince personas no debería comprar una

«Buscamos una software factory.» Oigo la frase varias veces al año, de compradores de España y de Latinoamérica, y antes de empezar la conversación ya me dice dos cosas: que han comprado desarrollo externalizado antes, y que lo compró el departamento de compras. Porque una fábrica es lo que pides cuando piensas en el software como unidades entregadas contra una especificación, y es lógico pensarlo así si el último proveedor te lo vendió de esa manera.

Quiero tomarme la frase en serio, porque tiene detrás una historia y un modelo reales, y después explicar por qué ese modelo no encaja con la empresa que más a menudo me lo pide.

La expresión tiene cincuenta años y nunca fue pensada para startups

«Software factory» no es un invento de marketing. Viene de los años setenta y ochenta, cuando las grandes electrónicas japonesas —Hitachi, Toshiba, NEC, Fujitsu— organizaron la producción de software a imagen de sus plantas industriales: procesos estandarizados, componentes reutilizables, productividad medida y miles de ingenieros sobre sistemas de larga vida. Michael Cusumano lo documentó en Japan's Software Factories (1991), y la idea viajó: a los contratistas de defensa estadounidenses, a los modelos de madurez CMM y, al final, a la industria del outsourcing, donde «fábrica» pasó a significar una gran organización de entrega que convierte especificaciones en código a un coste por unidad previsible.

En España y Latinoamérica el término arraigó más que en ningún otro sitio. Fábrica de software es como los grandes integradores llaman a sus centros de entrega offshore y nearshore, y es como les compran las corporaciones: contrato marco, tarifa por seniority, proceso de peticiones de cambio y acuerdo de nivel de servicio sobre defectos. El modelo de fábrica optimiza la previsibilidad y el volumen a lo largo de muchos proyectos, a costa del criterio en cada uno de ellos. No es un defecto. Es lo que necesita un banco con cuarenta proyectos en paralelo.

Qué vende una fábrica y qué no vende

Sin la marca, una software factory vende cuatro cosas:

1. Capacidad bajo demanda: decenas o cientos de ingenieros que pueden asignarse a tu proyecto y reasignarse cuando termina.
2. Un proceso repetible: entran requisitos, salen estimaciones, se entrega contra un plan y los defectos se siguen contra un SLA.
3. Coste previsible: una tarifa, a menudo mezclada entre seniorities, y precio cerrado para el trabajo bien especificado.
4. Traspaso del riesgo organizativo: un contrato, un responsable de cuenta, un único cuello al que apretar.

Lo que no vende, y no puede vender a esa escala, es lo que una empresa pequeña más necesita: alguien senior que decida qué construir y responda de que la decisión sea la correcta. Una fábrica ejecuta una especificación. Cuando la especificación está mal —y con dos a quince personas la especificación siempre está en parte mal, porque la empresa todavía está descubriendo qué es—, el proceso de la fábrica entrega a tiempo lo que no tocaba y después factura una petición de cambio para arreglarlo. La tarifa mezclada lo empeora: el ingeniero que podía haberte dicho en la primera semana que la especificación estaba mal es el senior, y una tarifa mezclada es la forma de no pagarlo.

Dónde la fábrica es la compra correcta

Voy a reconocerle lo suyo al modelo, porque la objeción más fuerte a este artículo es «tú vendes squads, claro que no te gustan las fábricas». Tres casos en los que la fábrica es la opción correcta:

• Volumen con una especificación estable. Migrar cuatrocientas pantallas de un framework a otro. Mantener un sistema de back-office regulado con un ritmo de cambio conocido. Trabajo en el que el criterio ya se ejerció y lo que queda es ejecución.
• Compra dirigida por procurement. Una corporación cuyas normas de compra exigen proveedor homologado, SLA y tarifa mezclada no puede contratar un squad de cinco personas por bueno que sea.
• Muchos proyectos pequeños a la vez. A una empresa con veinte herramientas internas en marcha le rinde más un proceso común para todas que la excelencia en una sola.

Si eres uno de estos, compra la fábrica, y cómprasela a uno de los grandes integradores que llevan décadas con el modelo. Para eso existen.

Por qué una empresa de quince personas obtiene peor producto de una fábrica que de cinco personas

Ahora la empresa que me lo pide de verdad. De dos a quince personas, uno o dos fundadores, un producto con los primeros clientes y una idea de la siguiente versión acertada más o menos en un sesenta por ciento. Esto es lo que el modelo de fábrica le hace a esa empresa, en el orden en que ocurre:

La fase de especificación dura seis semanas y produce un documento que el fundador firma sin entenderlo del todo, porque el documento es un artefacto de la fábrica, no suyo. Los ingenieros asignados son los que hay disponibles, que con tarifa mezclada quiere decir sobre todo perfiles intermedios, más un «arquitecto» senior que aparece en el comité de seguimiento. La primera entrega coincide con el documento y no con el mercado, porque el mercado se movió durante esas seis semanas y nadie en el lado de la entrega tenía autoridad para decirlo. Empiezan las peticiones de cambio. En el sexto mes la empresa ha pagado dos productos y tiene uno: el del documento.

La alternativa no es «contratar en plantilla», que con quince personas es lento y caro. Es un equipo senior pequeño —cuatro o cinco personas con un Tech Lead que responde de la arquitectura— trabajando dentro del repositorio de la empresa con retainer mensual, con el fundador en la daily y una demo cada dos semanas. Ese equipo cuesta más por hora que una tarifa mezclada de fábrica y menos al mes que la fábrica, porque necesita menos horas para construir lo que toca. Y, sobre todo, puede decirte en la segunda semana que la especificación está mal, y cobra por hacerlo. Es el modelo que dirijo, y dejé el proceso por escrito para que se pueda comprobar en vez de creer.

Cómo saber cuál de las dos te están vendiendo

Los proveedores en España usan ya «software factory», «squad», «equipo dedicado» y «partner» como sinónimos, así que la etiqueta no te dice nada. Cuatro preguntas sí:

1. «¿Quién, de vuestro lado, puede decirme que mi especificación está mal, y está en el proyecto cada día?» Una fábrica responde con un rol en un comité. Un squad responde con un nombre y un usuario de Slack.
2. «¿Cuál es la mezcla de seniority de las personas asignadas de verdad?» La tarifa mezclada la esconde. Pide los nombres y su trayectoria en sistemas como el tuyo.
3. «¿Qué pasa si el alcance cambia en la tercera semana?» Una petición de cambio con precio es la respuesta de fábrica. Un backlog repriorizado en la siguiente planificación es la respuesta de squad. Las dos son legítimas; solo una encaja con una empresa que todavía descubre su producto.
4. «¿Cómo termina el contrato?» Los contratos marco tienen cláusulas de salida medidas en trimestres. Un retainer con preaviso de 30 días termina cuando deja de ser útil.

La versión corta

Una software factory es un modelo industrial de hace cincuenta años para producir software en volumen contra una especificación estable, y funciona para las corporaciones para las que se diseñó. Una empresa de dos a quince personas no tiene una especificación estable; tiene una hipótesis, y lo que necesita son unas pocas personas senior capaces de cambiar la hipótesis mientras la construyen. Eso es un taller, no una fábrica. Compra la que corresponda al tamaño de la apuesta que estás haciendo.

Si estás intentando averiguar cuál de las dos necesitas, te lo decimos en una llamada de 30 minutos, también cuando la respuesta sea la fábrica.