Blog

Populismos y Factorías de Software

Las revistas digitales TECHWEEK, ITCIO, SILICON NEWS y TECNOLOGÍA acaban de publicar el interesante artículo escrito por Ignacio Lopéz Carrillo , Director del área del Gobierno del Riesgo Software en LEDAmc, que se títula Populismo y factorías de Software, en el que se recoge la comparativa entre las las tendencias populistas y las factorías de software.

El artículo nos hace reflexionar acerca de cómo las soluciones simples a problemas complejos a veces no son todo lo factibles que parecen ser por la falta de un sustento conceptual y la imposibilidad de tomar atajos o hacer las cosas de forma sencilla debido a la cantidad de implicaciones que hay en el proceso.

Link al artículo:

ARTÍCULO

En este momento en que en la política occidental están tan de moda los populismos de izquierdas y de derechas, veamos si a algunas de las cosas que hacemos con el Software se podrían calificar de populistas.

Populismo es un vocablo muy ambiguo y a la vez muy usado. La real academia española lo define como “Tendencia política que pretende atraer a las clases populares”. Los populismos se caracterizan principalmente por dar a las masas populares lo que piden, lo que significa en muchos casos proponer soluciones poco estudiadas (o simplistas) a problemas complejos, asumiendo que proponiendo soluciones simplistas atraerán a un mayor número de personas.

Desde el punto de vista de la resolución de problemas, aplicar soluciones simples es correcto siempre y cuando la solución propuesta sea factible y no genere problemas mayores de los que pretende evitar. Lo que ocurre es que muchas veces se confunde el aplicar una solución simple con el aplicar la solución más simple de las soluciones posibles.

Construir software y probarlo adecuadamente es un proceso complejo con muchas implicaciones, y no hay atajos ni soluciones sencillas.

Dejando al margen la política, el populismo en términos de la construcción de software equivaldría a pensar que basta con empaquetar el problema y asignar el trabajo a alguien para que todo vaya bien. Es decir, definir una Software Factory o una Testing Factory, encargársela a un proveedor, esperar a que la opere… y confiar en que todo vaya bien.

Así es como algunas grandes organizaciones intentan resolver sus problemas, aunque no siempre consiguen lo que esperaban, en los plazos, el coste y la calidad que esperaban.

Controlemos

Es en ese momento, al aplicar soluciones populistas, cuando se dan cuenta de que necesitan hacer algo más, y necesitan convertir la caja negra en una caja gris, dotándose de mecanismos para controlar de forma anticipada el trabajo y los resultados de las factorías.

De aquí surgen las oficinas de proyectos, los servicios de estimaciones, la gestión de requisitos, el control presupuestario, los servicios de productividad, la gestión de calidad y efectividad, la gestión de proveedores…

Existen muchas empresas dedicadas a realizar externalización de factorías de software y factorías de pruebas, pero muy pocas dedicadas a ayudar a las empresas a controlar a sus proveedores de factorías.

Estas empresas que quieran controlar a otros proveedores deben ser independientes, altamente especializadas, eficientes, con profesionales altamente cualificados (porque van a tener que controlar a otros profesionales y anticiparse a los errores que cometan) y no competir con los otros proveedores.

Pero, sobre todo, deben tener potentes mecanismos de control basados en cuadros de mando articulados en torno a unas métricas objetivas del tamaño funcional y de la calidad, y no de los costes de los desarrollos ni de los esfuerzos de los mismos, como se suele hacer.

Estimemos

Cualquier mecanismo de control que se quiera implementar tiene que partir de una buena estimación, que será la que nos tiene que permitir controlar la evolución del proyecto evitando las desviaciones de los resultados estimados.
Por ello es importante estimar el tamaño, el esfuerzo, el coste y la calidad esperada, usando métricas lo más estándares e internacionales posible para minimizar las diferencias de interpretación en las estimaciones.

Probemos

Desde el punto de vista de la calidad del software, el populismo en estado puro consistiría en pensar únicamente que como se paga a un proveedor para hacer un trabajo, ese proveedor por sí mismo y sin que nadie le controle se preocupara por entregar el software en perfectas condiciones de calidad.

Aunque así es como debería ser, hay que tener en cuenta las presiones a las que se somete a los equipos de desarrollo de software, en términos de cumplir plazos imposibles y, además, a unos costes muy baratos. En definitiva, los equipos de desarrollo y pruebas están formados por seres humanos, igual que la sociedad, que cometen errores.

Otra forma de populismo, un poco más elaborada, consistiría en pensar en contratar una Testing Factory para controlar a la Software Factory. ¿Pero quién controlaría la Testing Factory?

En cualquiera de los dos modelos anteriores se piensa que el problema se va a resolver sólo. Y no es así. Siempre hay que hacer algo para controlar el problema si se quiere garantizar el éxito, minimizar el riesgo y optimizar los costes.

La realidad, los problemas y la experiencia nos demuestra que estas soluciones simplistas no son las adecuadas para garantizar la calidad de las aplicaciones desarrolladas, y que hay que complementarlas con unas soluciones más elaboradas y que no se dediquen únicamente a controlar la calidad al final del proceso, sino que velen por la calidad durante todo el proceso.

En definitiva, para no caer en populismos tecnológicos, se trata de dejarse aconsejar por los expertos que han resuelto estos problemas complejos que minimizan el riesgo software en otras organizaciones, y además pedirles que implementen un modelo del control del retorno de la inversión realizada en las actividades implementadas.

¡Compártelo!Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+
Por El Equipo de LEDAmc en Noticias Publicaciones  el