archivo

Archivos diarios: julio 24, 2012

Es cierto que hay muchas variables que influyen sobre tu motivación pero hay una que tiene una especial relevancia (no digo que sea capaz de revertir situaciones imposibles pero que sí es bastante efectiva incluso en contextos que te invitarían a una permanente bajada de brazos) y es sentir que aportamos valor con nuestro trabajo (que mediante nuestro esfuerzo intelectual y físico influimos positivamente en el producto) y que lo que hacemos permite mejorar ya sea un proceso, una herramienta, una organización, un conjunto de personas o el mundo.

Ese sentimiento debe nacer de uno mismo si bien es importante que los gestores ayuden a forjarlo y a consolidarlo algo que no es demasiado habitual ya que generalmente se destacan más los fallos que los aciertos y no se comunica los efectos que el desarrollo produce sobre sus destinatarios (es cierto que no siempre se puede saber con certeza pero también lo es que no se suele prestar demasiada atención a obtener esa información).

Ya que tenemos que ir a trabajar y que pasamos allí un buen número de horas cada día resulta mucho mejor sentirnos importantes y sentir que lo que hacemos vale para algo.

La siguiente cita de Dave Thomas creo que resume perfectamente el contenido de este artículo: “Para motivarte y mantenerte comprometido necesitas estar orgulloso de lo que estás haciendo. Si por el contrario te consideras un trabajador de una línea de ensamblaje cuyo único trabajo es coger una especificación y convertirla en bytes, no vas a tener suficiente interés en lo que estás haciendo como para hacerlo bien”.

Es cierto que hay personas que se sienten encantadas con ser meros ejecutores de tareas, lo respeto, pero mi visión sobre el papel que debe desempeñar cada persona en un proyecto de desarrollo de software va mucho más allá de eso y está en consonancia con el contenido de este artículo.

La comunicación es básica en los proyectos de desarrollo de software y no solo entre los miembros de un equipo (algo que es esencial) sino también entre los stakeholders.

Una vez que se consigue que la comunicación sea fluida (no es tan fácil ya que no solo depende de uno mismo) o por lo menos que exista cuando sea necesario es importante que de vez en cuando haya encuentros cara a cara (cuanto mayor sea la relación que se tenga que tener más frecuentes deberían ser esos encuentros).

Es cierto que el contexto en el que se desarrolla el proyecto condiciona mucho y si tu cliente está a 500 kilómetros o en otro país no es tan sencillo conseguir esa cercanía, lo cual no quita que se busque el mecanismo de comunicación que permita una mayor proximidad dentro de esas condiciones y en el que ambas partes se sientan cómodos.

Y es que la comunicación previene de muchos problemas y también permite resolver otros tantos. Cuando hay un malentendido, un conflicto o un desencuentro lo mejor es hablarlo y hacerlo cuanto antes. A veces, en función del carácter que tenga cada uno es interesante esperar un poco ya que a veces es mejor dar tiempo a reflexionar y ver las cosas desde otras perspectiva. Esperar un poco no es aguardar a que el problema desaparezca porque en este tipo de circunstancias suele quedar un poso que tarde o temprano termina saliendo afuera, sino hablar unas horas o unos días después.

Pero no es solo útil en este tipo de circunstancias, ya que permite armonizar las visión del conjunto sobre el proyecto, resolver dudas y lo más importante desarrollar y consolidar paulatinamente la relación de confianza.

Generalmente muchos problemas en los proyectos no vienen por un exceso en la comunicación sino por su defecto.

La agilidad vista como una orientación al producto exacerbada donde nada ni nadie importa por conseguir un resultado favorable no es agilidad, llamadlo como queráis, pero no agilidad.

Claro que importa obtener un producto que satisfaga las expectativas del usuario además de otras condiciones (mantenibilidad, robustez, etc…) pero no hay un solo camino para conseguirlo aunque generalmente se opte la mayoría de las veces por el más corto y es no tener en cuenta prácticamente nada más que el sistema que se está desarrollando como si fuera un elemento aislado dentro de la organización.

¿Cuál es el resultado de esto? La fragmentación de los sistemas de información y de los datos que gestionan. En el primer caso es una deuda técnica que generalmente nunca se tiene en cuenta pero que es real en el momento en que te pones a pensar en la diversidad de tecnologías que se terminan utilizando, de la compatibilidad con navegadores, servidores de aplicaciones, servidores de bases de datos, etc… En el segundo caso dificulta la realización de consultas integradas de información y os aseguro que los Datamart pueden ayudar a eso pero no hacen milagros.

¿Por qué el camino más corto? Pues porque es el más fácil, no dependo de nada así que quito resistencia al desarrollo del proyecto que bastante tiene ya de manera inherente, además siempre habrá una excusa (porque seguro que hay motivos para ella) para alegar que es la mejor solución porque no es fácil integrarse con terceros sistemas cuando estos están gestionados por otras personas con otros intereses y la existencia de situaciones de bloqueo, de falta de entendimiento y dificultades a nivel técnico o de datos para integrar son riesgos que de alguna u otra manera suelen materializarse cuando tenemos en cuenta estos factores.

¿Cuándo se actúa de manera adecuada? Cuando de la manera más objetiva posible se entiende que lo mejor (haciendo balance entre beneficios e inconvenientes) para el proyecto y para el producto teniendo en cuenta la organización y dentro del contexto actual.