archivo

Archivos diarios: diciembre 17, 2012

Hay momentos en muchos proyectos donde te encuentras con la montaña. Es eso que piensas que es imposible de superar, eso que intentas aplazar pero al que tarde o temprano tendrás que enfrentarte si quieres sacar el trabajo adelante. Huir de ese obstáculo o las medias tintas afectarán al resultado final del proyecto.

La montaña parece gigante cuando la tenemos enfrente, nos parece infinito el esfuerzo que tendremos que realizar para superarla… y seguirá siendo infinito si te quedas contemplándola en lugar de dar el primer paso para escalarla. Es el paso más difícil porque supone superar tu miedo, pero no será suficiente, se requerirá constancia, aguante, creer en el proyecto, en tu equipo y en ti, tendrás tentaciones de arrojar la toalla en innumerables ocasiones y cuando eso ocurra será tu deseo de imponerte al reto que tienes delante lo que hará que continúes hacia adelante.

Muchos proyectos fracasan por dejarnos vencer por la montaña y lo peor de todo es que ni siquiera lo hemos intentando.

Si un Product Owner decide sobre la línea de desarrollo del producto indicando la prioridad de las tareas y facilitando la especificación o haciendo que se facilite (como coordinador del área usuaria para ese trabajo) de cada una de ellas también debe ser el responsable de informar al conjunto de usuarios sobre la evolución que va teniendo el sistema de información: nuevas funcionalidades, modificación de las existentes e incidencias resueltas.

Si es el responsable de decidir qué se hace y cuándo, también debe ser el responsable de comunicar a los usuarios (desde mi punto de vista antes y después) de la liberación de nuevas versiones del producto (o lo que es lo mismo el resultado de la ejecución del equipo de desarrollo de las especificaciones de las cuales el Product Owner es el último responsable).

Así debe ser. Puede contar con nuestra ayuda si necesita que le demos soporte para explicar algo pero la responsabilidad es suya. Puede delegarla en un tercero y exigirle responsabilidades (pero como en toda delegación de tareas el responsable último es el que delega).

Ni el equipo de desarrollo ni el Centro de Atención a Usuarios deben tener hacer ese trabajo porque el Product Owner también requiere (o debería requerir) del feedback de los usuarios y cuanto más directo mejor.

Eso no quita que el CAU pueda avisar al usuario que ya está resuelta la incidencia que ha reportado o que alguien del equipo de desarrollo ofrezca informaciones puntuales al respecto.

Si realmente no tenemos que depender de nadie en nuestro trabajo no tiene por qué existir la organización, no tiene por qué existir una visión de colectivo o de trabajo en equipo.

Salvo que trabajes solo y que tu seas tu propia empresa no te vas a encontrar en ninguna circunstancia donde no dependas de un tercero por lo que lo quieras o no debes mirar un poco más allá de ti mismo y tener una visión más amplia del trabajo que realizas.

Aunque parezca mentira no eres el ombligo del mundo, cuando antes lo asumas mucho mejor. Eres parte de una maquinaria, una parte muy importante, tu trabajo es importante para que todo funcione, si lo haces bien todo va un poco mejor, si lo haces mal todo va un poco peor. Y no lo olvides, en esa maquinaria todas las piezas (sin excepción) son sustituibles.

Somos individualistas, los desarrolladores de software todavía más, sobre todo cuando vienes de trabajar mucho tiempo en proyectos basados en enfoques clásicos, yo siempre he sido muy individualista (y todavía arrastro mucho de ello) pero con los años me he dado cuenta de la importancia del colectivo para sacar adelante el trabajo.

Los enfoques ágiles que tienen como pilares fundamentales la cooperación y la comunicación están sentando unas bases importantes para que con el paso del tiempo los desarrolladores consideren como algo natural el trabajo en equipo y no como un inconveniente necesario.

Sin embargo los equipos dentro de una organización tienden a cerrarse sobre sí, a crear ciudades estado que si bien rinden pleitesía a la organización no dan ni agua a la de al lado (solo a las que son aliadas). Hay mucho que trabajar en ese sentido porque el trabajo en equipo no es solo con tu compañero de proyecto o con quien te lleves bien (o con quien te convenga llevarte bien) sino que debe extenderse más allá porque de lo contrario no estamos hablando de organización propiamente dicha sino de microorganizaciones cada una de las cuales con su conocimiento, sus objetivos y dinámicas de funcionamiento.