viernes, 24 de junio de 2016

Proyectos MDM: errores y razonamientos (I)

14:13 by Rafael Flores · 0 comentarios

Comienzo con este post a escribir sobre el tipo de sistemas con los que trabajo actualmente, los sistemas MDM (Master Data Management).

Recientemente leí un artículo que trataba sobre las "8 peores prácticas en Master Data Management y cómo evitarlas" escrito por "Hub Designs". Me parece un tema interesante y quería aportar mi propia visión sobre el tema, ya que por desgracia después de tantos años los Proyectos Informáticos siguen tropezando en las mismas piedras...

La visión que daba el artículo, si lo traducimos al castellano y lo simplificamos es esta:


En general estoy de acuerdo con los errores que se detallan, pero he realizado una pequeña modificación: los círculos en naranja representan errores comunes a todo proyecto TIC mientras que los azules tratan de errores específicos de proyectos MDM/PIM.

Veamos más en detalle cada uno...

Errores comunes en proyectos TIC (IT)

La gestión de los proyectos TIC, y casi de cualquier proyecto, es una tarea muy compleja como bien saben mis amigos del Asociación Navarra de Gestión por Proyectos. La toma de requerimientos, la gestión de los recursos, los plazos... son tareas que pueden resultar enormemente complejas y requerir mucho esfuerzo, y que si no se llevan a cabo correctamente darán al traste con el proyecto.
Lo que sí conocemos y de lo que voy a hablar aquí, son una serie de errores que si no los corregimos pronto harán que nuestro proyecto fracase sin importar el esfuerzo que dediquemos al resto de tareas. (Aclaro que entiendo por "fracaso" el hecho de que un proyecto no se reconozca como éxito o beneficioso, a pesar de que se haya entregado por completo, en tiempo y en costes; vamos, que si no nos reconocen el resultado ¿para qué hemos trabajado?)

Olvidarse del caso de negocio

O, dicho de otra manera ¿para qué estábamos haciendo esto? Aunque parezca mentira, a veces los proyectos desarrollan soluciones que no son lo que se necesitaba o no solucionan completamente el problema que se pretendía solucionar. Sobre esto, las Metodologías Ágiles como SCRUM ayudan enormemente a no cometer este error ya que siempre se mantiene el foco en lo que el cliente quiere solucionar en todo momento. De este modo el resultado es lo que el cliente espera (y por tanto supondremos que es lo que le soluciona sus problemas :) ). Otra técnica, más simple y que no implica necesariamente cambiar el proceso de desarrollo que tengamos implantado, es la metodología Lean y sobre todo el concepto de Producto Mínimo Viable un concepto que debería ser obligatorio en todo desarrollo software y que comprendí mucho mejor de la mano de expertos como Mario López de Ávila o Rodrigo Corral: (simplificando el concepto muchísimo) desarrolla la solución necesaria mínima, e itera sobre esta.
En cualquier caso, hay que tener siempre presente lo que buscamos solucionar y asegurarnos de hacerlo, sin florituras. El resto, para más adelante.

Sin Sponsor ejecutivo

Esto es un problema que demasiadas veces se obvia en los proyectos, y luego causa enormes dificultades: ¿quién es la persona (o personas) dentro del cliente que apoya este proyecto y tiene capacidad para hacerlo? Si no la hay sinceramente sería mejor no realizar el proyecto. Porque cuando haga falta buscar aprobaciones, información, respuestas, apoyos, formalizaciones, firmas... si no existe esta figura vamos a tener que perder mucho tiempo (y dependiendo del cliente puede ser mucho-mucho...) y esfuerzo para conseguir algo que debería ser muy simple.
Esto, que puede parecer trivial, nos va a causar dos problemas mayores:
  • Si somos estrictos en nuestros requerimientos, va a causar retrasos y más retrasos en el proyecto (que potencialmente podrán encima ser achacados a la tarea del PM...)
  • Y como PMs tenemos muchas otras tareas en las que dedicar nuestro esfuerzo y nuestro tiempo. Soportar estos temas es más que probable que nos cause una percepción negativa del proyecto.
Por tanto, aunque parece algo trivial este error nos puede causar unos problemas muy graves. Así que lo trivial debería ser determinar esa figura.

Tecnología errónea

Esto sí que está claro, sin duda :) El elegir una tecnología errónea para una solución nos va a dar muchísimos dolores de cabeza. En ocasiones no es fácil o posible conocer de antemano qué es lo que nos interesa más, por lo que se hace preciso realizar un buen análisis de las soluciones existentes para conocer cómo solucionarían el problema concreto.
Además, también es muy conveniente tener en mente una visión amplia de hacia dónde queremos que evolucione en el futuro nuestra solución o plataforma, de tal manera que no nos quedemos "atados" a sistemas legacy o con muy poco recorrido a futuro.
Aquí me permito hacer una pequeña "cuña publicitaria": STEP de Stibo es la mejor solución de MDM del mercado, para ambos puntos ;) 

No planificar el cambio organizativo y cultural

Esta es una parte que los programadores "de siempre" hace años pensábamos: "ya se adaptará el usuario y si no que aprenda". Y aprendimos a las duras que eso no es así, y que encontrarnos con un grupo de usuarios finales que hecha pestes del proyecto no es bueno, y trae problemas...
Así que hay que preocuparse de esto debidamente, planificarlo, desarrollarlo, etc. como un subproyecto del proyecto, con su propio PM si es preciso, recursos, tiempos, etc... 
El asegurarnos de que el usuario final entiende y conoce cómo utilizar nuestro desarrollo es una parte esencial si luego queremos lograr ese reconocimiento del resultado. En esto un proyecto es como cualquier otro negocio: si entregas algo mal y sin instrucciones claras lo más posible es que no te valoren "5 estrellas"...

Sin métricas para evaluar el resultado

Este es el último de los problemas "genéricos" de cualquier proyecto, el que podemos traducir como "ni sabemos dónde estamos ni dónde queremos llegar". Y es que en muchas ocasiones (demasiadas) los proyectos nacen de una "idea feliz" o impresión sobre que algo es necesario, pero no se sabe muy bien ni por qué ni para qué. Sólo unas métricas adecuadas (y nunca "impresiones") pueden aclarar esto debidamente. Y siempre es posible determinarlas. Todo software proporciona valores o datos que son medibles. Toda actividad de una persona puede representarse de acuerdo a algún parámetro que se puede medir. Por tanto, por complicado que parezca esto, es posible. Y muchas veces nos encontramos con que los proyectos no se miden de ninguna manera más que por el tiempo y el coste de los mismos. ¿Y qué hay del resultado?
Por eso las métricas son necesarias, para conocer y documentar lo qué se ha hecho y por qué se ha hecho. Y en consecuencia que se reconozca el éxito del proyecto.


Hasta aquí esta entrada, en la próxima me centraré en los errores más "puros MDM". Espero haber aportado un poco sobre este tema, y por supuesto que cualquier comentario, crítica u opinión es más que bienvenida. Entre todos mejoramos :)