archivo

Archivos diarios: agosto 23, 2010

Se ha liberado la primera versión oficial de Redmine 1.0. Personalmente me alegro mucho de que este proyecto siga evolucionando ya que es la opción de gestión de proyectos que hemos implantado en mi organización y con bastante éxito y satisfacción entre el resto de responsables de proyecto.

No fue idea mía implantar esta herramienta ya que fue una recomendación, pero lo importante, como he repetido en tantas ocasiones no es que a uno se le ocurra la idea sino que aunque sea de otro, el rendimiento que se le pueda sacar a la misma sea positivo.

Yo recomiendo el uso de este software ya que es tremendamente sencillo y potente y sobre todo por la capacidad de evolución que tiene que lo irá dotando progresivamente de cada vez más utilidades y además permite personalizar determinadas funcionalidades a través de plugins ya sean propios o desarrollados por terceros (los más significativos se van implementando dentro del núcleo del producto, como por ejemplo la posibilidad de definir subtareas que ya no requiere la utilización de plugins).

Para ver las novedades de esta versión os dejo un par de enlaces (de la página oficial de Redmine), uno referido a la última release candidate y otro a las novedades de la 1.0.1 respecto a la versión candidata:

Redmine 1.0.0 Release Candidate

Redmine 1.0.1

Anuncios

Mark Gibbs es un importante empresario, divulgador en el terreno de las TIC y consultor de importantes compañías, teniendo una experiencia de más de 25 años en este negocio.

En febrero de 2006 publicó la siguiente cita como parte de un artículo en la revista Network World en el que hablaba sobre una presentación no del todo exitosa de Microsoft en el Consumer Electronics Show en Las Vegas:

“No importa lo estupendamente que haya ido la demo en los ensayos, cuando lo haces frente a tu audiencia la probabilidad de que sea una presentación existosa es inversamente proporcional al número de personas mirando, elevado a la cantidad de dinero que hay en juego”

Mark Gibbs como bien comenta en su artículo hace una cita que perfectamente podría pasar a formar parte del compendio de la Ley de Murphy y detrás de esa frase y de lo que le pasó al gigante de Redmond podemos sacar dos mensajes claros:

– Que a todos nos puede suceder ese problema.

– Que como es posible que pase hay que tomar las debidas precauciones para reducir o mitigar el impacto.

A mi, en el contexto de mi trabajo, me ha pasado y no solo una vez y me volverá a pasar. Me gusta hacer demos de los productos en directo ya sea en el entorno de pruebas o de producción porque tengo interés en que los usuarios y los directores usuarios vean que lo que les estoy enseñando no es cartón piedra, me gusta que vean que se está trabajando ya que el proceso de desarrollo una vez finalizado el análisis se vuelve demasiado opaco para ellos y prefiero que si salen deficiencias lo hagan antes que el producto esté entregado (por supuesto que si se hubieran detectado o tenido en cuenta en el análisis, mejor, pero hay siempre que tener un resquicio de flexibilidad). Por supuesto, cuando el producto no está terminado o si está terminado pero todavía está en fase de pruebas les recalco el estado en el que se encuentra y que es posible que nos encontremos con incidencias en la presentación que se está realizando.

El peligro de enseñar el programa en funcionamiento es que pueden existir diversas contingencias que te puedan fastidiar la presentación, por eso siempre hay que llevar un plan B si no es posible continuar o realizar la presentación en línea. Ese plan suele ser tenerla preparada en diapositivas (pero bien preparada, no unas cuantas capturas de pantallas para salir del paso).

Evidentemente no me juego lo que se jugaba Microsoft en aquella presentación, pero supongo que salvando las enormes y kilómetricas diferencias buscaban con ese tipo de demostraciones llamar la atención de la audiencia y enseñar que detrás del producto no solo hay palabras sino también hechos.

No siempre hago presentaciones enseñando el programa directamente, depende de la audiencia y del propósito de la reunión, a veces es mucho más productivo trabajar directamente con diapositivas ya que te permite ir más al grano y no tener que pasar por funcionalidades del programa que no tienen por qué interesarles a tus interlocutores.