Por qué cada proyecto de software automotriz tarda el doble de lo que debería
Dos proveedores, dos versiones ligeramente diferentes de la misma spec, días depurando la capa equivocada. El traspaso OEM-proveedor está roto de una forma estructural de la que nadie habla — aquí está el patrón, por qué persiste y qué hacer al respecto.
Hace unos años estaba en el lado del proveedor en un programa automotriz, construyendo un sistema de comunicación según una spec que el OEM nos había dado. Construimos exactamente según esa spec. El código estaba limpio, las pruebas unitarias pasaban, las pruebas de integración en nuestro banco funcionaban. Entonces conectamos al bus para hablar con el sistema de otro proveedor — y nada funcionó.
Pasamos días investigando. Cada capa de nuestro stack se revisó de nuevo. Las trazas del bus se peinaron línea por línea. El código se recorrió pulgada por pulgada. Finalmente descubrimos que el problema no estaba en nuestro código en absoluto. Al otro proveedor le habían dado una versión diferente de la misma spec, y habían construido — también correctamente — según esa. Ambos sistemas eran técnicamente correctos. Juntos estaban rotos.
Nadie había sido pagado para notar que esa discrepancia existía antes de que enviáramos a integración.
Esta es la historia más ordinaria en software automotriz, y explica una pregunta que cada ingeniero en esta industria acaba haciéndose: ¿por qué cada proyecto tarda el doble de lo que debería?
¿Por qué los proyectos de software automotriz se alargan al doble de lo previsto?
La respuesta habitual son "problemas de comunicación" entre OEM y proveedores. Mejor tooling, mejor Jira, mejores syncs diarios, menos correos. Ninguna de esas arregla el problema.
Los problemas de spec no son problemas de comunicación. Son problemas de propiedad. Concretamente: nadie a ninguno de los dos lados de la línea OEM-proveedor es dueño de la spec de extremo a extremo. La autoridad está distribuida entre departamentos y contratos de una forma en la que nadie tiene la posición ni el presupuesto para hacer nada al respecto. El sistema produce de forma fiable detalles olvidados, requisitos contradictorios y cambios tardíos — no porque alguien sea incompetente, sino porque eso es lo que la estructura paga.
Vale la pena nombrar dos mitades de la disfunción.
Mitad uno — silos internos del OEM
La spec no la escribe una sola persona. Se cose entre múltiples departamentos del OEM — ingeniería de sistemas, programas, compras, a veces legal — cada uno dueño de una pieza de los requisitos. Estos departamentos no siempre están de acuerdo internamente antes de que la spec salga. A veces ni siquiera se hablan entre ellos.
Cómo se ve esto desde el lado del proveedor: tienes una pregunta de aclaración. Mandas un correo al OEM. El ingeniero de sistemas dice una cosa. El líder de programa dice otra. Ninguno se compromete por escrito. La pregunta va y viene durante dos meses y se resuelve en "lo abordamos en integración". Rara vez se aborda en integración.
Cuando el OEM actualiza una spec a mitad de desarrollo — y siempre lo hacen, porque el alcance del programa también está cambiando bajo sus pies — la actualización se envía a cualquier proveedor que recuerden copiar. Otros proveedores construyendo a la misma interfaz se enteran en integración, si es que se enteran.
No hay una sola persona en el OEM cuyo trabajo sea mantener la spec consistente de extremo a extremo y responder por los cambios. La spec es responsabilidad de todos, lo cual es lo mismo que de nadie.
Mitad dos — los Tier-1 compiten en precio, no en comprensión
En el lado del proveedor, la estructura empuja en la misma dirección.
Los contratos automotrices van a quien hace la oferta más baja y rápida. Un Tier-1 que quiere el contrato tiene que parecer productivo desde el día uno. Pasar la primera semana de un encargo leyendo en silencio la spec, haciendo preguntas detalladas, mapeando ambigüedad — ese trabajo es invisible para las métricas de compras. El proveedor competidor que se saltó ese paso y empezó a codificar inmediatamente parece más adelantado.
Así que la estructura castiga al equipo que hace lo correcto. El proveedor que se tomó la spec en serio se queda atrás en el primer mes y recibe presión para acelerar. El proveedor que no se la tomó en serio saca a la luz los mismos problemas tres meses después, salvo que ahora son problemas de fase de integración en lugar de problemas de fase de diseño, y cuestan diez veces más arreglar. Todos pierden, pero el perdedor que corrió rápido al menos parecía ocupado.
La tesis real: no es una empresa conjunta
Los programas de software automotriz se alargan al doble de lo planeado porque los OEM y los proveedores Tier-1 tratan el proyecto como una cadena de transacciones en lugar de una empresa conjunta. El OEM esconde sus desacuerdos internos detrás de un documento llamado La Spec; el proveedor esconde sus lagunas de comprensión detrás de un documento llamado El Calendario. Cada lado tiene un muro que puede defender en una reunión de contrato. Ninguno actúa como si estuviera trabajando en el mismo problema. La solución es estructural y pequeña: una semana de revisión conjunta de la spec con el equipo de ingeniería del OEM en la sala, antes de comprometer ningún calendario.
| Comportamiento | Cadena de transacciones (hoy) | Empresa conjunta (lo que funciona) |
|---|---|---|
| Propiedad del pliego | Repartida entre departamentos del OEM | Un único responsable de extremo a extremo |
| Ambigüedad del pliego | Se resuelve en integración, si es que se resuelve | Se resuelve antes de comprometer ningún calendario |
| Cambios a mitad de proyecto | Se envían al proveedor que se recuerde copiar | Se hacen visibles a todos los proveedores del mismo interfaz |
| Inicio de la colaboración | Pujar bajo, programar rápido, parecer productivo | Leer el pliego juntos, firmar los supuestos |
| Dónde se van los meses | Aparecen en integración, diez veces más caros | Aparecen en diseño, arreglables en papel |
Ambas mitades se remontan al mismo fallo. El proyecto se trata como una cadena de transacciones, no como una empresa conjunta.
El OEM esconde sus desacuerdos internos detrás de un único documento llamado La Spec. El proveedor esconde su falta de comprensión detrás de un único documento llamado El Calendario. Cada lado ha construido un muro que puede defender en una reunión. Ninguno de los dos está actuando como si trabajaran sobre el mismo problema.
En una empresa conjunta, una spec poco clara es problema de todos y se resuelve aguas arriba. En una cadena de transacciones, es una patata caliente. En una empresa conjunta, ambos lados son dueños del resultado de integración. En una cadena de transacciones, ambos lados son dueños solo de lo que está en su contrato, y los huecos entre contratos son donde se van los meses.
Lo frustrante de esto es que todos en la industria lo saben. Los ingenieros del OEM saben que están enviando specs sin alinear internamente. Los ingenieros de Tier-1 saben que están empezando a codificar sin entenderlas. Ambos lados han ido a las mismas conferencias y leído los mismos post-mortems. La estructura persiste porque los contratos y las métricas la recompensan, no porque nadie crea que funciona.
Lo que hacemos diferente
No voy a fingir que he resuelto esto desde fuera. NeuraByte es un estudio pequeño, no un Tier-1 con miles de millones en ingresos. Pero hay un cambio específico en cómo nos comprometemos que ha hecho que cada proyecto sea más corto y menos doloroso, y cualquier proveedor podría hacer lo mismo:
Empezamos cada engagement con una semana dedicada a entender la spec — con el equipo de ingeniería del OEM en la sala.
Eso es todo. Una semana. Nos sentamos con los ingenieros reales — no compras, no líderes de programa, las personas con las que necesitaremos hablar durante la integración — y leemos la spec juntos. Llevamos nuestras preguntas por escrito. Ponemos las inconsistencias sobre la mesa mientras todavía hay tiempo para resolverlas. Salimos de esa semana con una lista de supuestos sobre los que estaremos trabajando, firmados por el OEM, antes de comprometernos con un calendario de entrega.
El modelo de compras estándar trata esto como overhead — normalmente se espera un precio fijo por un alcance fijo antes de que comience cualquier trabajo conjunto de descubrimiento. En su lugar, posicionamos esta semana de descubrimiento como el primer entregable, y los OEMs que aceptan obtienen un proyecto que se entrega a tiempo.
Una semana de alineación al principio ahorra meses al final. Siempre.
Lo que un ingeniero atrapado en esta disfunción puede hacer hoy
La mayoría de los lectores de este post no tienen el peso para cambiar cómo escribe contratos su empresa. Tres cosas que puedes hacer mañana:
1. Documenta cada aclaración por escrito — con un plazo. Cuando plantees una pregunta al OEM, ponla en este formato: "Procedemos con el supuesto X salvo que se nos indique lo contrario antes del [fecha dentro de una semana]." Esto traslada el coste del silencio de tu equipo al de ellos. Si no responden, tienes algo por escrito a lo que referirte cuando la integración se rompa.
2. Usa un plan de entregables dinámico, no fijo. La mayoría de los planes automotrices fingen que el alcance está bloqueado. No lo está. Planificamos nuestros entregables de forma dinámica — si la spec de una funcionalidad no está clara, empujamos esa funcionalidad a un release posterior y traemos al frente funcionalidades que sí están claras. El alcance total puede mantenerse fijo; lo que se flexibiliza es el orden. Esto es lo más importante que los ingenieros pueden hacer para dejar de estar secuestrados por specs poco claras y aún así cumplir hitos.
3. Construye interfaces que esperan cambios. Si un cambio tardío de spec del OEM requiere tocar cuarenta archivos, el diseño está mal. Las fronteras deben ser explícitas y las configuraciones externas, para que un cambio de spec toque el menor radio de impacto posible. Esto es disciplina de ingeniería, no negociación contractual — está completamente en tu control.
Ninguna de estas arregla el problema estructural. Reducen su coste de "el proyecto tarda el doble" a "el proyecto tarda un 30% más", que es la diferencia entre perder dinero y perder el contrato.
Volviendo al bus
Dos proveedores. Dos specs. El mismo bus. Ambos equipos produjeron el código correcto; el código correcto no sumó un sistema funcional, porque el trabajo que debería haber ocurrido aguas arriba del código no ocurrió en absoluto.
Hasta que la industria automotriz esté dispuesta a tratar los programas de software como empresas conjuntas — con propiedad compartida de la spec, responsabilidad compartida de integración, y contratos que paguen por el trabajo de alinearse antes de que nadie escriba una función — cada proyecto seguirá tardando el doble de lo que debería. A los ingenieros se les seguirá culpando por ello, y seguirán mudándose a otras industrias para escapar.
Los buenos ya lo están haciendo.
Sobre el autor
Fundador y Director Técnico
Richin es el fundador de NeuraByte, una pequeña consultora que construye software para clientes que quieren hacerlo bien a la primera. Ha pasado más de una década en ingeniería embebida y automotriz — en microcontroladores, plataformas Linux y sistemas críticos en seguridad ISO 26262 — y escribe aquí sobre cómo esa experiencia da forma a la manera en que construye hoy.