Chess - antoniomartel.com

Archivos de Autor: antoniomartel

Mi ponencia en las V Jornadas de Sostenibilidad

Hace unas semanas la Viceconsejería de Medio Ambiente del Gobierno de Canarias tuvo la amabilidad de invitarme a dar una ponencia en las V Jornadas de Sostenibilidad en Canarias que tuvieron lugar el pasado jueves 3 de octubre. Mi ponencia trató sobre el Sistema de Información de Residuos de Canarias y otros sistemas software que ayudan al Servicio de Residuos a controlar los residuos producidos en las islas. ¡Espero no haber aburrido mucho a los no versados en sistemas de información sobre residuos peligrosos!

Les dejo aquí un enlace a mi presentación del jueves

Las V Jornadas sobre Sostenibilidad en Canarias estaban presididas por la Viceconsejera de Medio Ambiente y tenían como lema los retos en la gestión de residuos en territorios insulares por lo que varios representantes de Cabo Verde asistieron para poder compartir experiencias sobre la gestión de residuos en ambos archipiélagos.
Las ponencias trataron sobre:

  • [Sal, una isla sin plástico] por una representante de la Cámara Municipal de la Isla de Sal en Cabo Verde.
  • [Modelos y plan de residuos en Cabo Verde] por D. Gilberto Silva, Concejal de Medio Ambiente de la Cámara Municipal de Praia.
  • [El Hierro 100% reciclable] por Dña. Fabiola Ávila, Técnico de Medio Ambiente del Cabildo de El Hierro.
  • [El impacto de los residuos en el Cambio Climático] por D. Fernando Herrera, Jefe del Servicio de Prevención y Control de la Contaminación del Gobierno de Canarias.
  • Buenas prácticas en la gestión de residuos a cargo de representantes del Grupo Lopesan y Martínez Cano Canarias.

Podrán encontrar toda la información y algunas fotos del evento en la siguiente dirección: Guacimara Medina inaugura en Las Palmas las V Jornadas de Sostenibilidad en Canarias.

Por último, les dejo un enlace a una entrada en este blog sobre una ponencia previa en las Jornadas sobre Sostenibilidad que tuvieron lugar el pasado mes junio: Gestión avanzada de residuos – Sistema de Información de residuos de Canarias (GUIRRE)

¿Qué significa ser ágil?

Debido a mi trabajo, por el blog o por lo que sea, estoy usando cada vez con más frecuencia muchas de esas palabras de moda como Ágil, Sprint, Historia de usuario, velocidad de la iteración o backlog del producto. He repasado algunas de mis entradas en este blog y lo veo lleno de expresiones un tanto huecas como ‘ser ágil’ o no serlo, aportar valor al producto o aceptar el cambio.

¿Qué significa realmente todo esto? ¿Qué es eso de ser ágil y por qué iba nadie a querer ser ágil? Esto de la agilidad es más una filosofía que un concepto claro y bien definido. Supongo que es una forma de ahorrar palabras y evitar tener que dar una definición completa de cada concepto cada vez que hablamos pero quien nos escuche debe estar pensando ¿qué diablos dice?

No sé si será suficiente pero quizás pueda aportar algo de luz utilizando la presentación de Henrik Kniberg en el Paris Scrum Gathering (échenle un vistazo, no tiene desperdicio) Pongo aquí un par de puntos que me parecen muy destacados:
Esta imagen de la torre Eiffel es bastante descriptiva por sí misma. Representa bien este balance entre el caos y la burocracia (exceso de documentación, formalismos o rigidez del contrato) Uno nunca se puede mantener un equilibrio perfecto, algunas veces te quemarás un poco y otras uno recibirá un pinchazo. Mientras se esté intentando no caer en la burocracia sin abrasarse mucho no iremos por muy mal camino.
Estas dos imágenes de arriba explican también de forma muy clara lo que significa ser ágil: ¿Alguien tiene una idea? Vamos a probarla, ¿son aburridas esas reuniones? ¿Probamos a quitarlas y vemos qué tal nos va?
Y por último, la idea que a mí más me gusta y la que, al mismo tiempo, me parece más divertida (aunque aún me falta para llegar a esto):

Ágil en todos los sentidos

Hace algunas semanas, una persona cercana a mí me pidió que le ayudara con la revisión de un trabajo académico que debía presentar a comienzos de septiembre.

Cuando le eché un vistazo, vi que había un gran trabajo hecho, se había leído muchísima documentación, notas y referencias a libros, artículos, ponencias y otra bibliografía estaban por todos lados y las hipótesis y las conclusiones eran claras. Sin embargo, aún era necesario dar cuerpo a todo el documento, revisar que se cumplían las normas de citación para cada elemento de la bibliografía y cumplir muchos otros aspectos.

Lo primero que hicimos fue tratar de saber qué quedaba por hacer para dar por concluido el trabajo. Elaboramos una lista de los puntos pendientes: revisión de citas, síntesis, abstract en inglés, palabras clave, relectura del documento para comprobar los errores gramaticales o de expresión, cumplir con los estilos de la institución académica, incluir mapas de localización, etc. Mucho por hacer y sólo quedaban unas semanas para entregar.

Después de preparada la lista, la priorizamos, colocando siempre en los primeros puestos aquellas tareas que eran imprescindibles para poder entregar el trabajo, seguidas luego de aquellas otras que sólo darían puntos extra o no eran imprescindibles para el aprobado.

Cuando la lista estaba avanzada nos dábamos cuenta de que necesitábamos añadir nuevos elementos a la lista. Preparábamos una nueva lista y volvíamos a priorizar siempre con la idea en mente de ‘Si tuviéramos que entregar mañana ¿qué tendríamos que tener hecho?’ A medida que íbamos eliminando elementos de la lista comprobábamos que las tareas eran cada vez de menor importancia y dificultad y la desesperanza del principio daba paso a las ganas de dar los últimos remates al trabajo.

Finalmente se completó el trabajo dos días antes de la fecha tope de entrega. El día anterior se dedicó a una última lectura y revisión entregándolo solo unas horas después.

Podemos llamarlo Ágil, GTD o simple sentido común pero ¡yo prefiero trabajar así!

Revista Proiectus

Hace algún tiempo algunos decidimos colaborar con la idea de Iván Tejera, al que algunos ya conocéis, en la creación una revista sobre la dirección de proyectos en Canarias.

Esta idea ha ido tomando forma, unos cuántos hemos escrito algún artículo, unos más largos que otros, para incluir en el contenido de esta nueva revista. Por algún artículo que he podido ver, todos me han parecido muy interesantes, así que recomiendo su lectura!

Su lanzamiento será en breve pero, mientras tanto, pueden ver una presentación de la revista en el siguiente Prezi:

¡Espero que les guste!

¿Por qué fallan los proyectos?

Razones hay muchas, seguro que parándonos a pensar un poco se nos ocurren unas cuantas, pero hay una que no siempre es tan obvia. Las estadísticas parecen indicar que si reducimos el tamaño de nuestro proyecto podemos aumentar en un 50% su probabilidad de éxito.

Un estudio indica que los proyectos de más de 1 millón de dólares tienen un 50% más de probabilidades de fallar que los proyectos de menos de 350.000 dólares. ¿Cómo no se nos había ocurrido antes? Los proyectos pequeños son más fáciles de gestionar y ejecutar que los grandes.

En proyectos grandes con duraciones superiores a un año tendemos a establecer las reuniones, hitos y revisiones con una periodicidad mayor, mensuales, bimensuales o incluso trimestrales. No es suficiente para tomar el pulso al coste del proyecto y comprobar si se está trabajando en la línea correcta, si se entrega lo que se necesita o si nos estamos desviando mucho de lo previsto.

Por otro lado, con proyectos de duración superior a un año o incluso menos se corre el riesgo de que hacia la finalización del proyecto, los objetivos y necesidades del negocio del cliente hayan cambiado con respecto a lo que le motivó a contratarlo. Si desarrollamos una aplicación para móviles ¿el mercado será el mismo dentro de 1 año cuando queramos venderla? Si quisiéramos hacer una aplicación basada en la legislación laboral actual ¿será útil dentro de uno o dos años cuando vea la luz nuestro producto? Parece mejor ver los grandes proyectos como ‘programas de actuación’ divididos en proyectos más pequeños, en los que con cada uno de ellos se entrega una parte del resultado global.

Yo añadiría un aspecto más: los proyectos grandes suelen planificarse y presupuestarse de ese modo porque con ellos se trata de conseguir objetivos complejos. Lamentablemente, con cada orden de complejidad adicional se multiplica el tiempo necesario para resolverla.

Si nos fijamos atentamente, el mundo IT parece ir en una línea muy distinta a ésta y trata de mantener los productos a desarrollar tan simples como sea posible. Hace unos años, los productos software más populares tenían menús llenos de características, funcionalidades y opciones de configuración (recordemos cada versión de MS Office o MS Outlook) En cambio, la mayoría de los productos actuales, los que residen en la nube o en nuestros dispositivos móviles, son mucho más simples: un par de casillas de texto y un botón para aceptar ¡no hay más!

David Karp, fundador de Tumblr, dijo acerca de esto: «Every feature has some maintenance cost, and having fewer features lets us focus on the ones we care about and make sure they work very well»

Me parece un gran planteamiento ¡Cuántas funcionalidades no habré desarrollado que me parecían muy útiles inicialmente pero que nunca fueron usadas!

Fuentes: thisiswhatgoodlookslike y startupquote.