menu_superior

Actualizar el servicio de pruebas de rendimiento

Una de las grandes virtudes de un proveedor, tanto si es un profesional autonomo como si es una empresa, es la de escuchar y transformar el servicio que se está prestando según las necesidades, inquietudes y sugerencias del cliente. Es vital ser capaz de darle la vuelta al calcetín y cambiar la concepción original de acuerdo a la evolución de las circunstancias. Es decir, nosotros tenemos que hacer una propuesta magnífica, que esté muy bien diseñada, que se ajuste muy bien a lo que el cliente pide,  a lo que tiene y a lo que nosotros sabemos hacer Y ADEMÁS hay que tener la valentía de no considerarla como un dogma, como algo inalterable en el tiempo: si se dan las circunstancias es muy importante saber reorientar la propuesta y dar respuesta a los desafíos del cliente que nos contrata.

Lo ilustraré con una experiencia personal. Cuando aterricé en nuestro actual cliente el proyecto inicial era crear una oficina de pruebas, ponerla en marcha a partir de un área de desarrollo muy grande e ir extendiendola a las demás áreas de desarrollo posteriormente. Esta Oficina de Pruebas estaba centralizada y daba un servicio de testing transversal a toda la organización. Estaba compuesta por 3 especialistas que se encargaban de la infraestructura (Quality Center), de las pruebas funcionales automáticas (Quick Test Professional) y de las pruebas de rendimiento (Load Runner). Por debajo de estos especialistas habría que ir sumando a los analistas de negocio, a los analistas de pruebas y a los testers. Había más cosas definidas, estaban las herramientas, algunos analistas a tiempo parcial, etc… La idea era buena (quizá un poco convencional) y seguramente hubiera funcionado.

Lamentablemente hubo cambios a nivel organizativo, los nuevos responsables no compartían el emfoque y la oficina de pruebas fue dividida. Las partes funcional y de infraestructura pasaron a un área y la parte de las pruebas de rendimiento fue a parar al área de producción que, obviamente, no tenía la misma visión sobre el rendimiento que tenía la propuesta inicial.

Antes de este proyecto en pocas ocasiones me había planteado yo al área de producción de cualquier compañia para albergar un servicio de pruebas de rendimiento. En algún caso, dependiendo de la compañía y de cómo estuviera organizado el trabajo podría tener sentido, pero no sería algo que se pudiera generalizar. Hemos visto no solo que es posible si no que es muy recomendable utilizar las herramientas y los procedimientos de control del rendimiento del software antes y después de salir a producción. Y así lo hemos hecho, hemos continuado haciendo pruebas de aplicaciones previo a su paso a producción, detectando errores (eliminando sorpresas desagradables y malas noticias) y además dando servicio cuando el aplicativo ya está en producción controlando su rendimiento con la actividad real para que el sistema que lo soporta no se vea desbordado, para prevenir pérdidas de servicio y para ahorrar dinero en mantenimiento y en confianza de los clientes.

De fondo esta es una historia en la que un planteamiento inicial perfectamente válido se ve comprometido por un evento externo y el proveedor, lejos de atarse al proyecto y reivindicar la aceptación de la propuesta como un derecho adquirido, la actualiza ajustandose a las necesidades, al nuevo contexto y añadiendo valor en un escenario totalmente diferente al que se había valorado inicialmente.

Yo creo esta flexibilidad además de ser positiva para nosotros y para el cliente fortalece nuestra relación y nuestra posición. Esta forma de actuar nos refuerza ya que nos hace diferentes, competitivos y resolutivos a los ojos de nuestros clientes… Y eso siempre es un factor que nos colocará por delante a la hora de optar a nuevos servicios.

, , , ,

Comments are closed.