El Blog de Pablo Fernando Sanchez

El modelo ha sido bastante difundido en los últimos años. Básicamente, la práctica conocida como offshoring se basa en la reubicación de procesos de negocio —tales como producción, manufactura o servicios— de un país a otro. Hay varios elementos que lo refuerzan en relación con la industria del software, como la diferencia de costos en la producción de software en los diferentes países, la imposibilidad de algunos países de autosatisfacer la demanda de software, etcétera. En parte por ello es que los países cuyos mercados necesitan adquirir este tipo de servicios a empresas de otros países, promueven la certificación o evaluación en modelos —como el Capability Maturity Model Integration (CMMI)— a empresas de estos otros países para que puedan proveer algún tipo de garantía en los procesos de producción —¿o creías que era de buenos nomás?

Sin embargo y más allá de cualquier certificación y/o evaluación, debemos hacer las cosas bien. Resulta que me han llegado algunos comentarios, uno de ellos de alguien que estuvo allí, sobre una charla titulada «Extreme Programming (XP) and Productivity Measures — What the Numbers Say» que dio Michael Mah y fue organizada por el grupo de la Software Process Improvement Network (SPIN) de la ciudad de New York. Para quien no sepa quién es, Mah es un referente en materia de Ingeniería de Software que mantiene su propio blog, Optimal Friction, y está al frente de QSM Associates.

En esta charla y entre otras cosas, Mah manifestó, tal como nos confirma el propio Ed Yourdon, que la enorme base de datos de proyectos que su empresa mantiene arroja un resultado preocupante: los desarrollos contratados off-shore poseen una tasa de defectos de 2,8x —¡un 280%!— con respecto al promedio. Casi nada, considerando que esta base de datos contiene información sobre 7.300 proyectos que representan unas 685 millones de líneas de codígo (LOCs), de 500 empresas en 18 países y escritas en 600 lenguajes de programación distintos.

Por supuesto, toda estadística tiene un margen de error, pero de todas formas este resultado es preocupante, tanto para el mercado que compra este tipo de servicios como para la industria mundial que los vende —o que pretende venderlos.

Entonces... ¿qué hacemos? ¿Seguimos cumpliendo como podemos los requisitos que tenemos que cumplir según normas, modelos, etcétera, o además hacemos lo que es bueno para el proceso de desarrollo? Sí, señores, no se trata sólo de certificarse y/o evaluarse en modelos —lo cual es necesario, no lo dudo—, sino pensar en lo que estamos haciendo y hacerlo mejor, empleando también modelos de bajo nivel y estándares, sin eludir responsabilidades para reducir costos, respetando a la gente, siendo éticos, sin «fabricar» evidencias y haciendo lo que se debe hacer para producir software. Les aseguro que funciona y da beneficios de todo tipo. Es más difícil, no es para cualquiera, pero funciona...