Lo que podemos aprender de un barco construido para ayer
Rápido, bonito, barato. Imposible.
Durante la Segunda Guerra Mundial la construcción de los cargueros clase Liberty era de extrema urgencia, se buscaba reemplazar rápidamente los barcos hundidos en el conflicto y recuperar la línea de suministros de EE.UU. hacia Inglaterra.
Se planificó todo de tal manera que cada barco pueda ser armado en 244 días. Nueva metodología, nuevas técnicas en soldadura y nuevo sistema de producción en cadena. Se logró construir el primer buque en solo 70 días. El ritmo de construcción llegó a ser de 42 días por unidad. El récord se alcanzo con el CSS Robert E. Peary, que tardó tan solo 4 días, 15 horas y 29 minutos en armarse.
Así entraron en servicio los nuevos barcos, pero otra fue la historia. El SS John P. Gaines se partió a la mitad y se perdió tripulación y carga. Luego dos buques más sufrieron el mismo destino. El 30% de las naves recién construidas presentó fallas estructurales. 1200 unidades tenían grietas en cubiertas y casco. En bajas temperaturas el acero del casco se volvía quebradizo. Toda la producción tuvo que volver al astillero para ser reparada y reforzada.
El origen de los problemas fue la mala supervisión, la mano de obra poco calificada y el uso inadecuado de materiales.
¿Le suena conocida la historia?
La supervisión requiere conocimiento y experiencia, tan simple como eso. El conocimiento necesario para entender cada paso y la experiencia de haber participado desde abajo en otros proyectos. Y sí, también haber metido la pata un par de veces cuenta. La experiencia genera respeto.
Ambas cosas aseguran la calidad. ¿Cómo revisar diseño si no se conocen los principios generales del diseño de interacción? ¿Cómo hablar de aseguramiento de la calidad sin la elaboración del plan de pruebas? Las microdecisiones diarias comprometen la calidad.
Si la contratación de programadores no pasa por una prueba de escribir código o al menos código funcionando en algún repositorio público, es contratar a ciegas. Para el programador el código es lo que vale, el resto son palabras. Lo mismo con los diseñadores o analistas. Necesitamos pruebas de que eres bueno.
La elección de la tecnología de un proyecto depende de diversos factores: la madurez y el uso, el diseño de las herramientas, el soporte (o la cantidad de información en Stack Overflow que es lo mismo), la cantidad de programadores en el mercado que conozcan el tema etc. Todas razones válidas y discutibles. Solo un consejo: no escoja nada por moda.
Entregar rápido y a tiempo es un arte que se domina con la práctica. Y no se hace solo, debe ser una cultura de equipo. Esta cultura requiere disciplina y control. Disciplina para respetar los procesos a pesar de la presión y control, hitos verificables de cumplimiento, métricas internas.
Evitar pasos en el proyecto como las revisiones de usabilidad, los test funcionales o pruebas con usuarios es prepararse para un rally sin casco ni cinturón de seguridad confiando en un viaje tranquilo. Y los productos digitales no son un viaje tranquilo.
Referencias
