archivo

Archivo de la etiqueta: quick win

Realizar primero aquellas funcionalidades más importantes para la aplicación y que sean más sencillas de implementar es lo que se denomina en el argot de la consultoría quick wins.

Para detectarlos Barry Boehm propone una estrategia simple, pero efectiva. Ante una funcionalidad solicitar al área usuaria que le asigne una prioridad de 1 a 10 (siendo 10 la mayor) y al equipo de desarrollo que le asigne un valor entre 1 y 10 en función de la complejidad del desarrollo (siendo un 10 la menor), ¿qué funcionalidad implementar primero? La que tenga un valor 10-10 (muy importante y sencilla de realizar) y así sucesivamente.

Partiendo de la hipótesis de que finalmente vamos a disponer de un listado de indicadores bastante amplio y que será necesario priorizar el conjunto de los mismos con los que vamos a trabajar, ya sea porque se quiera abordar el proyecto con una metodología en espiral o porque el presupuesto para realizarlo es limitado (o ambas cosas), tendremos que aplicar una estrategia que nos permita seleccionar aquellos indicadores que sean más significativos.

Se pueden plantear muchísimas estrategias y ser muchas de ellas válidas para un mismo conjunto de indicadores. No obstante, la que voy a comentar a continuación resulta bastante simple y entiendo que puede ser válida en un gran número de casos.

Consiste básicamente en asignar a cada indicador un valor para la variable importancia y otro valor para la variable complejidad (esta técnica, orientada a la obtención de quick wins, es muy antigua) y establecer unos umbrales para ambas variables, de manera que lo que quede dentro de los mismos es lo que se abordaría en la primera iteración del proyecto.

¿Cómo medir la importancia? Puede haber varias variables que le proporcionen a ésta su valor, como por ejemplo, el hecho de que el indicador permita dar respuesta a más de un departamento de la organización (a más departamentos, más importante) o que mida algún aspecto de negocio crítico o que tiene especial relevancia (lo indicarán los propios gestores). Por este motivo es importante que cuando se hable con los gestores se les pida, que si les resulta posible prioricen unos indicadores sobre otros. Como no siempre se va a poder obtener una priorización, será muy importante la experiencia de las personas que participan en el proyecto, para identificar qué indicadores pueden resultar más relevantes que otros. Otro aspecto importante para asignarle un nivel de importancia a un indicador, se obtiene a partir del estudio de la calidad del dato (no es necesario un análisis en profundidad, ya que los mismos usuarios de las fuentes de información o los responsables de las mismas, conocen aproximadamente la calidad de la información que se graba), debiéndose priorizar aquellos indicadores que tengan más calidad que otros.

¿Cómo medir la complejidad? Pues está relacionado principalmente con la fuente. Si no existe fuente para un indicador, directamente se debe descartar. Si el tratamiento de la fuente del dato es complejo (o la fuente del dato es susceptible de cambiar mucho) o no existe certeza en que siempre ésta esté disponible se le debe asignar una complejidad alta y así sucesivamente. Otro factor que hay que tener en cuenta para la medición de la complejidad lo tenemos en lo complicada que sea la explotación de la información almacenada en el almacén tanto con herramientas de exploración, como con cuadros de mando, listados, etc… (en esto se último también se puede considerar la naturaleza y características de los usuarios que van a realizar dichas actividades de explotación).

¿Cómo definir los umbrales? Antes de definir los umbrales definitivos es conveniente tener realizado el análisis de importancia/complejidad de cada indicador, ya que si se realiza a priori, lo mismo nos quedamos cortos con el número de indicadores que entran dentro de los mismos o lo mismo nos pasamos. Lo mejor es partir de unos umbrales provisionales y ver qué queda dentro de esos umbrales, cuando se realice el análisis y tomar a continuación la decisión de si moverlos o no, adaptando el trabajo a realizar a las necesidades estratégicas, temporales y presupuestarias del proyecto.

En el siguiente artículo comentaré la importancia que tiene la construcción del almacén de datos, por encima de la estrategia de explotación de la información almacenada en el mismo.

Un consejo: Intenta evitar la jerga de consultor (en general: lleva la conversación a una altura en la que tu cliente te entienda y no vea que vas de enterado, sabiondo o prepotente).

Es moneda muy común entre los consultores, el utilizar palabros, supongo que muchos de ellos se utilizan casi sin querer porque es lo que escuchan todos los días en su entorno laboral. Mi experiencia es que la utilización de esos términos no suele ser nada efectiva, ya sea porque en ocasiones no se entiende lo que se dice y en otras porque resulta poco natural y/o prepotente.

En este blog, en post ya publicados o en otros que se publicarán en un futuro voy a hacer muchas menciones a la comunicación y es fundamental para conseguir una comunicación efectiva con tu cliente o los usuarios de tu cliente (que son los que te tienen que explicar qué es lo que quieren en el sistema que vas a implementar o evolucionar) que sepas modular tu jerga informática a su nivel de conocimientos en la materia y que si tienes que prescindir de ella lo hagas.

Si realmente quieres demostrar que eres un técnico excelente, demuéstralo en el resultado de tu trabajo, eso son hechos, lo demás son palabras.

La psicología, por tanto, es un aspecto fundamental, se trata de modular tu lenguaje en función de las características del cliente y no de que independientemente de quien se encuentre delante aplicar como un robot tu jerga tecnológica o pseudotecnológica habitual.

Los clientes queremos resultados, comunicación, efectividad y calidad y no una máquina de hablar espanglish.