Qué se rompe al escalar un producto

En diseño industrial aprendemos que el volumen de producción es una restricción de diseño. No elegimos el mismo proceso para fabricar veinte piezas que para fabricar veinte mil. Cambian la inversión inicial, los materiales disponibles, las tolerancias, el tiempo de preparación y la forma de controlar la calidad. Un procedimiento magnífico para una serie corta puede convertirse en una mala decisión cuando se intenta repetir miles de veces.

Conozco diseñadores industriales cuyo trabajo bien podríamos describir como gestión de producto o de portafolio: deciden qué producir, para quién, con qué recursos y bajo qué promesa comercial. Algunos han enfrentado una demanda superior a la prevista y han descubierto que vender más no resolvía sus problemas. El taller no podía entregar a tiempo, el capital quedaba inmovilizado en materiales o el retrabajo se comía el margen de cada pedido adicional.

Una máquina puede abaratar la conformación de una pieza y, al mismo tiempo, exigir una inversión que solo se recupera con un volumen sostenido. Si la demanda dura menos que esa recuperación, el costo unitario prometido nunca se materializa. También puede ocurrir que el nuevo equipo produzca más de lo que el horno, el área de acabado o la distribución pueden procesar. La capacidad útil pertenece al sistema completo; comprar capacidad en una estación no garantiza aumentarla al final de la línea.

En tecnología sucede algo parecido. Un producto puede resolver muy bien el problema de un negocio pequeño y necesitar una reconstrucción profunda para operar en una organización empresarial. Si digo, por ejemplo, que habría que rehacer el 70 % del producto, esa cifra ilustra la magnitud posible del cambio; no es una estadística del sector. Lo importante es reconocer que un caso de negocio validado en una escala no valida automáticamente otra.

Un cliente empresarial no siempre representa miles de usuarios adicionales. A veces representa unos pocos usuarios con permisos distintos, integración con sistemas heredados, trazabilidad de decisiones, compromisos de servicio y una operación que no puede detenerse cuando el fundador sale de vacaciones. El volumen importa, pero también importan la diversidad de los casos, la criticidad y las consecuencias de equivocarse.

Imaginemos una plataforma de pedidos en la que una persona resuelve manualmente las excepciones. Durante el piloto, esa intervención puede ser una forma razonable de aprender. Cuando llegan cientos de excepciones diarias, la persona se convierte en una dependencia crítica, las respuestas se retrasan y el costo de atender cada pedido cambia. El sistema quizá siga disponible, pero la promesa de servicio ya está fallando.

Por eso conviene separar el crecimiento cuantitativo del cambio de condiciones. Más transacciones pueden exigir capacidad; más mercados pueden exigir nuevas reglas; más clientes empresariales pueden exigir aislamiento de datos y formas diferentes de contratación. Si confundimos esas necesidades, terminamos comprando servidores para resolver un problema de coordinación o contratando personas para compensar una decisión de arquitectura que necesita revisarse.

La primera conversación sobre escala debería precisar qué esperamos que crezca, en qué plazo y con qué mezcla de demanda. Debe incluir horas pico, tareas costosas, dependencia de terceros y excepciones, además del volumen promedio. Decir «tenemos que estar listos para diez veces más» es una aspiración. Describir diez veces más de qué, manteniendo qué calidad y a qué costo, empieza a ser una especificación de producto.

Antes de evaluar si la plataforma soportará la demanda, necesitamos entender si el negocio puede sostenerla. El costo de infraestructura es apenas una parte. También crecen la incorporación de clientes, el soporte, los errores, la conciliación, las devoluciones y el trabajo de coordinación. Algunas partidas aumentan por unidad; otras aparecen de golpe cuando necesitamos otro turno, una nueva especialidad o una cobertura de servicio más amplia.

Propongo un ejercicio ilustrativo. Una operación cobra 100 unidades monetarias por pedido y consume 60 en costos variables, por lo que conserva 40 para contribuir a sus costos fijos. En un segmento nuevo, el descuento comercial baja el ingreso a 85, mientras las integraciones y la atención elevan el costo variable a 75. Ahora quedan 10. Harían falta cuatro veces más pedidos para obtener la misma contribución total, antes de pagar los costos fijos adicionales de esa expansión. Las cifras son inventadas; la pregunta que muestran es real.

Una evaluación de infraestructura debe partir del recorrido que produce valor. En una plataforma logística podríamos seguir un envío desde la cotización hasta la confirmación de entrega y localizar las dependencias de cada paso. Ese mapa permite distinguir una falla visible en pantalla de un problema que se está acumulando en una cola, una base de datos o un proveedor externo.

Para la revisión estructurada, AWS Well-Architected ofrece un marco y una herramienta con los que examinar cargas de trabajo, registrar riesgos y dar seguimiento a mejoras.¹ Lo útil no es obtener una calificación decorativa, sino convertir cada hallazgo en una decisión con responsable, evidencia y fecha. Un diagnóstico sin plan de intervención solo describe el riesgo que ya aceptamos seguir corriendo.

Las pruebas de carga complementan esa revisión. Herramientas como k6 permiten ensayar carga habitual, aumentos bruscos, presión sostenida y límites de capacidad.² Antes de ejecutarlas necesitamos una mezcla representativa de operaciones, datos de tamaño realista y criterios de éxito. Consultar repetidamente una página ligera no demuestra que un sistema pueda procesar pedidos complejos mientras concilia pagos.

La observabilidad permite entender lo que ocurre durante esas pruebas y durante la operación. OpenTelemetry aporta instrumentación para señales como métricas, trazas y registros.³ La práctica de SRE destaca latencia, tráfico, errores y saturación.⁴ Para producto, esas señales cobran sentido cuando se relacionan con una promesa: cuántos usuarios completaron su tarea, cuánto esperaron y qué consecuencias tuvo el fallo.

Pensemos ahora en un taller de porcelana. Para mantener preciso el paralelismo, hablaré de colada a presión, una técnica de fabricación de vajilla que introduce material cerámico fluido en moldes; no debe confundirse con la inyección de plástico. Existen sistemas de colada tradicional con moldes de yeso y de alta presión con moldes de resina.⁵ Incorporar maquinaria cambia la conformación, pero no elimina las demás etapas del producto.

Antes de comprarla, necesitamos revisar cómo se comportan la pasta, el secado, la cocción y el acabado dentro del proceso elegido. Un molde repetible no corrige por sí mismo una deformación posterior ni decide qué variaciones son aceptables para la colección. Una máquina también introduce tareas nuevas: preparación, mantenimiento, control de parámetros y respuesta ante desviaciones.

El artesano puede seguir aportando valor en pintura, detalle, selección y criterio de aceptación. Parte de su conocimiento tendrá que convertirse en muestras, instrucciones o límites observables para que otros lo reproduzcan. Otra parte puede permanecer deliberadamente manual porque sostiene la identidad de la pieza. La decisión no debería depender de si una actividad es antigua o moderna, sino de qué aporta y cómo se comporta en la nueva escala.

La matriz siguiente es una propuesta de trabajo para discutir la transición, no una receta universal. La misma pregunta puede aplicarse a una línea de cerámica, a un producto digital o a un servicio: ¿qué función cumple esta actividad y cómo demostraremos que el cambio conserva su valor?

Evaluar al equipo para una nueva escala exige empezar por el sistema de trabajo. Una persona puede parecer lenta porque concentra todas las revisiones delicadas o porque recibe los casos que nadie más sabe resolver. Si medimos únicamente tareas cerradas, podemos castigar el criterio que protege la calidad y premiar a quien deriva el trabajo difícil a otros.

En equipos de software, DORA ofrece métricas de desempeño de entrega: tiempo de cambio hasta producción, frecuencia de despliegue, tiempo de recuperación de despliegues fallidos, tasa de fallos de cambio y tasa de retrabajo de despliegues.⁸ Deben usarse para comprender y mejorar el desempeño del equipo o del servicio en su contexto, no como una tabla de clasificación de personas. Su lectura se completa con resultados del producto y condiciones de trabajo.

Para equipos físicos o de servicio, la misma intención requiere otras medidas: unidades aceptadas a la primera, tiempo total de entrega, devoluciones, resolución efectiva y carga de trabajo pendiente. Un aumento en piezas fabricadas importa poco si crece todavía más el rechazo. Del mismo modo, un aumento en respuestas de soporte no demuestra que los clientes estén resolviendo sus problemas.

La evaluación individual necesita además evidencia de competencias, conversaciones y oportunidades reales de aprendizaje. Propongo una escala descriptiva por habilidad: necesita acompañamiento, actúa con autonomía o puede enseñar y mejorar el proceso. No la sumaría para producir una nota única. Me interesa identificar qué capacidad falta, dónde existe una dependencia y cómo puede cubrirse.

Una matriz de capacidades puede revelar que necesitamos formar a quienes ya están, reorganizar responsabilidades o contratar una especialidad que todavía no existe. Esas decisiones no son equivalentes. Cambiar el organigrama no crea conocimiento; contratar a alguien experimentado tampoco resuelve una operación en la que nadie tiene autoridad para decidir.

Antes de abrir una vacante, escribiría qué problema de escala esperamos resolver y qué evidencia demostraría la aportación de esa persona. Si el problema está en la confiabilidad, necesitamos capacidad para diseñar y operar con fallos. Si está en la incorporación empresarial, quizá necesitemos integración, implementación o gestión del cambio. El nombre del puesto debería llegar después de comprender la necesidad.

También buscaría disposición para enseñar, escuchar y conservar lo que funciona. Quien llega con experiencia de una empresa mucho más grande puede aportar perspectiva, pero también introducir una complejidad innecesaria. La experiencia relevante incluye reconocer cuándo una práctica sirve y cuándo su costo sería mayor que el problema que intenta resolver.

La transición debe tener capacidad asignada. Pedir al mismo equipo que sostenga la operación, aprenda una plataforma, migre datos y mantenga intacta su velocidad de entrega equivale a prometer la misma producción mientras cambiamos todas las máquinas del taller. Reducir el trabajo simultáneo y reservar tiempo de aprendizaje son decisiones de planeación, no concesiones a la falta de compromiso.

La IA vuelve especialmente visible esta discusión porque modifica el esfuerzo necesario para producir determinados resultados. Puede ayudar a redactar, programar, clasificar información o preparar alternativas. Sin embargo, una reducción en el tiempo de generación no equivale por sí sola a una mejora del producto. Todavía debemos saber si el resultado sirve, qué errores introduce y cuánto trabajo exige verificarlo.

La comparación con la porcelana resulta útil. Automatizar la conformación puede liberar tiempo para diseño, acabado o atención al cliente, pero ese valor no aparece solo: alguien tiene que decidir dónde invertir la capacidad liberada. Con IA ocurre algo semejante. Si producimos más propuestas de las que podemos evaluar, quizá solo hayamos trasladado el cuello de botella de la ejecución a la revisión.

Yo evaluaría su incorporación comparando el proceso anterior con un piloto sobre casos representativos. Mediría el tiempo hasta un resultado aceptado, los errores que llegan al usuario, el retrabajo, el costo completo y la necesidad de intervención humana. Incluiría casos difíciles, no solo aquellos en los que la herramienta se luce. Si la generación tarda menos, pero corregir y verificar consume más, la mejora todavía no está demostrada.

No haría del número de prompts, del volumen de texto o de las líneas de código generadas una medida de valor. Me interesa qué puede hacer ahora el usuario, con qué confianza y a qué costo. Eso también exige claridad sobre los datos utilizados, los límites de actuación y quién responde cuando una decisión afecta al cliente.

Mucho de lo valioso de un producto tecnológico vive en la idea, el concepto, el mercado y la forma en que nos acercamos a él. El trabajo de ejecución es indispensable, pero su dificultad no garantiza que lo producido sea valioso. Podemos dedicar meses a construir algo que nadie necesita, o utilizar una herramienta que reduzca el esfuerzo y dedicar ese tiempo a entender mejor el problema.

Esto no vuelve irrelevante la calidad técnica. Un concepto atractivo que pierde información o entrega resultados inconsistentes también destruye confianza. La calidad surge de unir intención y realización: comprender qué merece hacerse y sostenerlo con una operación que cumpla. La automatización debería ayudarnos a cuidar esa relación, no a disimular que no la hemos definido.

Como el artesano que sigue pintando y afinando detalles en una pieza conformada industrialmente, las personas pueden concentrar su criterio en los lugares donde la diferencia importa. A veces será un acabado visible; otras, una conversación difícil, una excepción bien resuelta o la decisión de no automatizar un momento que requiere acompañamiento. La calidez también necesita diseñarse y recibir tiempo dentro de la operación.

Para mí, la dedicación y la pasión tienen sentido cuando se convierten en cuidado perceptible para otra persona. No hace falta afirmar que ninguna máquina podrá producir algo bello para defender esa responsabilidad humana. Somos nosotros quienes decidimos qué promesa hacemos, qué aceptamos como suficiente y cómo respondemos cuando el producto no está a la altura.