Efron está consolidando su Centro de Excelencia, ¿qué tipo de servicios ofrece concretamente?
Efectivamente, lo abrimos hace más o menos un año, aunque no lo hemos terminado hasta finales de 2012. Tenemos un expertise y una metodología y procedimientos estandarizados que creemos que podían ser empaquetados dentro de un Centro de Excelencia, de ahí su origen. Efron no quiere especializarse exclusivamente en estos servicios de calidad de software, pero sí es cierto que un 25% de la compañía está dedicada a la prestación de dichos servicios, unas 135 personas en total, por lo que consideramos que era un buen momento.
Contamos con un equipo de personas especializadas en un sector determinado, lo que supone que combinamos tanto la presencia física en las oficinas del cliente como la externalización de la ejecución de las pruebas y de los despliegues de software. Igualmente, somos capaces de funcionar como un centro offshore, y de hecho ya tenemos un cliente en Estados Unidos. Ofrecemos todo lo relacionado con calidad de software en todo su ciclo de vida, incluso hacemos una detección temprana de los defectos, y por supuesto, también las pruebas antes de su puesta en marcha, y la puesta en producción.
Con la cada vez mayor presión sobre los tiempos del lanzamiento del software, ¿se pueden cumplir los plazos estimados? Una de las ventajas de contratar nuestro Centro de Excelencia es que los clientes pueden mantener durante todo el año los recursos dimensionados para lo que ellos creen que pueden necesitar. Estos servicios tienen muchos picos y valles de trabajo, y lo que suele suceder es que el desarrollo normalmente se retrasa, aunque la fecha de producción nunca se mueve, con lo cual al final del camino se produce un pico de trabajo impresionante. Si el cliente tiene que estar dimensionado en recursos para atender esos picos de trabajo, los costes se disparan.
Nosotros sí somos capaces de cubrir esos picos de trabajo, y el cliente no tiene por tanto que desplazar las fechas o postergarlas, ya que nosotros le ayudamos a cubrirlo. Además, facturamos por el servicio, y no por las personas dedicadas; es el concepto de testing as a service: pagas por lo que pruebas, y no por los recursos.
¿Por qué muchas compañías fracasan en su intento de asegurar la calidad del software?
Para mí, la principal clave del fracaso es no entender cuál es la madurez de la compañía e intentar implantar una función de calidad que esté muy por encima de los que la compañía puede asumir. La calidad tiene muchas fases, y por eso hay que adaptar el modelo que se quiere implantar a la propia compañía. Otra causa de fracaso es que esta iniciativa no cuente con el respaldo de la dirección. Es muy importante también ser consciente de que la calidad está para ayudar a los proyectos, no para poner trabas. Por supuesto es importante contar con una metodología, pero ésta no puede ser rígida, sino flexible, capaz de adaptarse a las circunstancias particulares de cada compañía. Además, conviene saber que el problema de la no calidad es no localizar un defecto, porque sin ese defecto no puedes elaborar un plan de contingencia. Si lo conoces, no pasa nada, porque tienes una alternativa. Si los errores son conocidos, eso también es calidad.
¿Las empresas son conscientes del coste de no tener calidad de software?
Eso es algo muy difícil de medir, porque conlleva muchos costes añadidos. El mantenimiento correctivo es muy fácil de medir, pero hay costes que no son tan evidentes, y muchas variables intangibles, como por ejemplo los posibles clientes que se han marchado por los fallos en el software, o el dinero que se ha dejado de ingresar por esos clientes que se han marchado, o el daño a la imagen. Sí es cierto que hay algunos estudios que hablan de ROI y los ahorros por la calidad de software, que oscilan entre un 20 y un 25%, pero en realidad es muy difícil de saber, aunque esa cifra es para mí la más fiable.
¿Por qué es recomendable separar la parte de testing de la de desarrollo? ¿Se está haciendo en las compañías españolas? El estado inicial es que el testing esté incluido dentro del ciclo de vida del desarrollo. Lo que sucede es que el desarrollador es experto en desarrollo, y no es experto en pruebas. Por supuesto, estos profesionales son capaces de probar, pero unas pruebas de testing van mucho más allá, porque la profesión de tester es independiente y diferenciada de la de programador. A un programador, el testing no le aporta ningún valor, porque supone probar con todas las variables y combinaciones posibles. Se trata de dos formas distintas de ver el software. Por eso es aconsejable separarlo, para garantizar que hay una mayor objetividad y que el resultado final sea mucho mejor.
En España, las compañías grandes deberían de estar más avanzadas, y esa separación de funciones lo empezaron a liderar grandes compañías de telecomunicaciones y banca. Pero es verdad que el testing inicialmente es costoso, por lo que en grandes compañías es más frecuente esa separación que en otras más pequeñas o en aquellas que tienen un único proveedor, ya que puede haber una especie de monopolio, ya que no suelen aclarar a sus clientes si hay errores de calidad o no, lo cual puede ser un riesgo. En cualquier caso, todo llegará.
