Autor: Carlos Valls (https://www.linkedin.com/in/cvalls/)

Carlos Valls

Una de las tareas que suelen ser necesarias la fase de iniciación de los proyectos es el benchmarking; término sajón acuñado por Xerox que se refiereal desarrollo de comparativas entre distintos productos. Gracias a estas comparativas es posible identificar que herramienta es la mejor para cubrir un cierto conjunto de requisitos.

Sin embargo, aunque se trata de una tarea imprescindible, la realidad es que no es siempre bien recibida dentro de los equipos. Quizá por alguna de estas razones:

  • Su enunciado puede estar insuficientemente definido. Por ejemplo, “Hay que comprar un programa que permita editar texto”.
  • Hay desconocimiento del área de aplicación de las herramientas. Por ejemplo, “Necesitamos comparar equipos de tomografía axial para animales.”
  • Hay ideas preconcebidas sobre alguna de las herramientas. Por ejemplo, “Si ya tengo xxx que funciona, para qué buscar otra.”
  • Implica un esfuerzo inicial muy importante. Por regla general, se necesita leer y asimilar una gran cantidad de información.
  • Existe la sensación inicial de pérdida de tiempo. Únicamente aquellos que conocen el valor aportado, se sienten capaces de llevar a cabo una evaluación rigurosa.
  • Por regla general, hay presión para que los resultados estén cuanto antes.
  • No hay una metodología que asegure que el resultado será la elección de la mejor herramienta en función de parámetros objetivos.

Es un hecho: Si se desea calidad, hay que establecer un procedimiento que permita alcanzar los resultados. Las metodologías basadas en la improvisación como  “Avanced System Management”, -  traducida al castellano comoA Salto de Mata” -  no ayudan precisamente a mejorar los resultados.

Bromas aparte, en el presente artículo propongo un novedoso procedimiento para simplificar la vida a los equipos de desarrollo. En siete sencillos pasos se obtiene una puntuación objetiva sobre cada herramienta a comparar. Un paso adicional, determina cuál de estas herramientas es la que será elegida finalmente.

Paso 1.- Conocer el Objetivo.

Si no se conoce cuál es el objetivo será difícil alcanzarlo. Por lo tanto, el primer paso consiste en fijar el objetivo de la comparativa de productos. Las herramientas objeto de la comparación, deben de responder a un conjunto de necesidades a cubrir propias de un proyecto servicio o cliente concreto. No se trata simplemente de comparar dos o más herramientas, sino de hacerlo considerando su aplicación a un contexto. Por ejemplo, en una comparativa de base de datos, el contexto no es el mismo si se pretende almacenar datos de autenticación biométrica, datos para publicar indicadores o videos para hacer emisión bajo demanda. Los productos a comparar serán distintos; aunque comercialmente, todos sean bases de datos.

Paso 2.- Determinar cuáles son las herramientas a comparar.

Normalmente el conjunto de herramientas estará formado por productos que serán competencia unos de otros. Para identificar dichos productos se puede acudir a internet; pero también es posible consultar las clasificaciones que algunas empresas de investigación de mercados ofrecen (normalmente previo pago). Esto último, tiene la ventaja de ser más rápido porque ya hay una comparativa previa que puede permitir descartar algunas opciones.

Paso 3. Conocer las herramientas.

Tras haber seleccionado las herramientas a comparar, el siguiente paso consiste en recopilar información para conocer más sobre ellas. Es de esperar que exista un conjunto de características comunes a todas,  junto a otras peculiaridades propias de cada una. Las características y propiedades de cada herramienta deben ser almacenadas en una base de datos para su tratamiento posterior.

Paso 4. Definir los requisitos.

En este paso se debe pensar que requisitos es necesario cubrir y elaborar una lista con ellos. La lista de requisitos debe ser elaborada por los distintos stakeholders de la solución: cliente, equipos de desarrollo, de arquitectura, de implantación, de operaciones… La herramienta ideal es aquella en la que la intersección de los conjuntos de requisitos y características es mayor.

Es recomendable establecer una clasificación de requisitos porque no todos los requisitos son técnicos. Por ejemplo, requisitos basados en documentación o mantenimiento, basados en los dispositivos o ubicaciones donde se ofrecerá el servicio, etc. Todos ellos pueden contribuir a la elección de la herramienta con su propia ponderación.

Paso 5. Emparejar requisitos y características.

Con la lista de requisitos clara, es necesario asociar cada elemento con una o más propiedades de los productos elegidos. Este paso ofrece dos ventajas:

  1. Unifica el lenguaje: En la metodología de desarrollo de software "Domain Driven Design" existe un concepto muy importante denominado Lenguaje Ubicuo. Normalmente cada fabricante, tiene su propio lenguaje de presentación que no tiene porque coincidir con el lenguaje del equipo o de los equipos. Si las herramientas propuestas en este artículo deben perdurar a través del tiempo y de los equipos, es bueno que todos los implicados tengan los mismos conceptos y vocabulario.
  2. Determina el grado de cumplimiento de cada requisito: Es decir se puede saber si un producto cubre un requisito, no lo cubre o lo cubre parcialmente. El cerebro funciona mejor con datos cuantitativos que cualitativos, por lo tanto:
  • Se asignan cero puntos cuando un requisito queda vacío
  • Se asigna un punto cuando las propiedades del producto cumplen el requisito totalmente
  • Se asigna medio punto cuando un requisito tiene propiedades asociadas, pero no está totalmente cubierto.

El peso asignado al cumplimiento parcial es una simplificación útil, pero puede tener matices que quizá convenga desarrollar en alguna situación. Por ejemplo, una herramienta puede cumplir un 20% del requisito y otra un 80%. Ambas tendrían el mismo peso, cuando una es potencialmente mejor que otra. Es posible establecer el peso en el intervalo [0,1] en función del número de propiedades relacionadas con el requisito.

6.- Priorizar los requisitos.

En estos momentos se tiene una lista de requisitos obtenida gracias a la contribución de distintos stakeholders. La experiencia dicta que normalmente no se podrán satisfacer todos simultáneamente. Siempre habrá unos más importantes que otros. Por lo tanto es necesario priorizarlos.

Existen varias técnicas para esta priorización: basadas en riesgo, el modelo KANO, el modelo MOSCOW, el juicio de expertos… Se puede usar cualquiera; aunque de nuevo, las soluciones sencillas son más rápidas de implementar.

Lo realmente importante es tener claro que se debe asociar una puntuación numérica a cada nivel de la clasificación de prioridad elegida. Esta asignación puede ser lineal o no. Por ejemplo, se podría utilizar la serie de Fibonacci, que tanto se usa en metodología ágil para hacer estimaciones en base a puntos de historia o a puntos de función.

  • 5 puntos para MUST
  • 3 puntos para WONT
  • 2 puntos para SHOULD
  • 1 puntos para COULD

Recapitulando.

Si se han seguido todos los pasos anteriores, en este momento se dispone de los siguientes elementos:

1.      Una matriz de trazabilidad de requisitos para cada producto. El valor de cada celda indica el grado de cumplimiento del requisito por parte del producto. Si este requisito es soportado totalmente la celda tendrá un 1. Si no lo es, entonces la celda contendrá un cero. Y si lo cumple parcialmente, la celda contendrá el valor decidido en el quinto paso.

2.      Una puntuación asignada a cada requisito posible, en función de la situación de negocio a resolver.

3.      Una posible clasificación de los requisitos en familias con pesos distintos. Por ejemplo, en un contexto determinado, se puede indicar que todos los requisitos de usabilidad contribuyen con un 10% del total, los técnicos un 80%, y el soporte a usuarios por parte del proveedor de la herramienta con un 10%.

Paso 7. Calculo de la adecuación.

A partir de estos dos elementos el séptimo y último paso consiste en hacer las siguientes operaciones numéricas:

  • Obtener los factores multiplicando los pesos asignados a la prioridad del requisito por el grado de cumplimiento.
  • Sumar los factores que entran en cada familia de requisitos.
  • Multiplicar las sumas realizadas por el peso de la familia para conocer su contribución al total.
  • Obtener el resultado mediante la suma de las contribuciones de cada familia de requisitos. Esto es una medida de la adecuación de la herramienta al objetivo planteado.
  • Ordenar por puntuación la lista de resultados de adecuación.

Las herramientas más adecuadas serán aquellas que presenten mayor puntuación.

Siguiendo esta aproximación, es posible que un requisito considerado obligatorio contribuya a la puntuación total de un producto de la misma manera que otros factores de requisitos menos prioritarios. En este caso las puntuaciones finales de ambos serán similares. Este problema se puede solventar tanto aumentando la diferencia de puntuación entre los niveles de priorización como evitando incluir en el proceso aquellos productos que no cumplen con alguno de los requisitos de máxima prioridad.

Paso adicional. Efectuar análisis coste beneficio

Aunque la puntuación más alta será la que objetivamente es mejor solución para el grupo de requisitos fijado, hay que tener en cuenta que no siempre será la más barata. Por lo tanto, como paso adicional, se propone realizar un análisis de coste beneficio de los candidatos para facilitar el llegar a acuerdos de colaboración con el proveedor de la herramienta.

Finalmente, las ventajas de este método frente a la ausencia de método alguno son:

  • Se trata de un método de evaluación objetivo y cuantitativo.
  • Garantiza la seguridad sobre la elección realizada.
  • Permite repartir el trabajo entre el equipo.
  • Facilita compartir el análisis con el cliente.
  • Es muy flexible, el mismo proceso sirve para distintos escenarios sencillamente cambiando la priorización de requisitos.
  • Es muy sencillo ampliar a productos nuevos o a actualización de versiones
  • Facilita la negociación de acuerdos de colaboración con el fabricante de la solución elegida.
  • Es posible rentabilizar económicamente el modelo. Por ejemplo, mediante la exposición de un API de pago por uso.