archivo

Archivo de la etiqueta: implicación

Los proyectos se pueden llevar más de lejos o más de cerca. Personalmente prefiero realizar un seguimiento más directo del proyecto y tener un mayor contacto con el área usuaria, con el equipo de proyecto y otras áreas implicadas en el proyecto.

Es posible que tengas que realizar una gestión del proyecto desde más distancia debido a que tal vez la carga de trabajo que tengas asignada sea excesiva, ante ese tipo de circunstancias lo más que se puede hacer es tratar de estar lo más implicado posible y saber muy bien dónde y cómo priorizar el esfuerzo, ya que prácticamente lo que te tocará es ir apagando fuegos.

Tener a un jefe de proyectos sobrecargado presenta sus inconvenientes porque los separa de lo que se cuece en los proyectos. A veces los informes que te envían o los números del proyecto te pueden dar una idea, pero la verdad no está ahí, sino en lo que pasa en el día a día.

Esa mayor implicación traerá consigo ir más lejos porque te permite de primera mano atender a las necesidades del proyecto, sentir más empatía con tu equipo y el resto de stakeholders, tomando decisiones y realizando acciones que no harías si no te sintieses parte del proyecto.

Se puede tener talento, ser un gran desarrollador y todo eso puede marcar la diferencia, no lo dudo. Sin embargo, el contexto en el que toda esa aptitud presenta y aprovecha todo su potencial es cuando a eso se le suma la implicación, las ganas.

No se trata de una frase hecha, tampoco pretendo generalizar y que solo con talento no se puedan conseguir cosas, sin embargo, si hacemos media aritmética es la actitud la que permite sacar partido a esa calidad y es la actitud la que acorta distancias e incluso permite superar a talentos que deciden no acompañar ese potencial con trabajo y con un enfoque adecuado del mismo con el resto de personas de su equipo y del proyecto.

Por eso valoro el talento pero también valoro las ganas y la capacidad de trabajar con otras personas. Debe haber un equilibrio y dar la oportunidad a que personas con menos conocimiento y experiencia tengan la posibilidad de evolucionar.

En proyecto largos, complicados (complejos o no), es fundamental la implicación personal en el proyecto y con tus compañeros. Todos sabemos como son los proyectos, sus dientes de sierra, los momentos buenos, los regulares y los malos. Es cierto que es complicado mantener una línea constante todo el tiempo, somos personas, será la actitud personal la que conseguirá tener el mayor rendimiento posible incluso en circunstancias donde no sea sencillo.

Muchos de esos talentos, de esas referencias que están en tu equipo de proyecto o en tu organización, lo son porque otras personas le dieron la oportunidad de desarrollarse profesionalmente y de adquirir los conocimientos y experiencia necesaria. No olvidemos que el aprendizaje tiene un efecto motivador muy importante y que ayuda a la implicación de las personas en el equipo, lo que hace también que aquellos que tengan más conocimiento, sigan tratando de hacer su trabajo de la mejor manera posible y seguir progresando.

No lo da un cargo. No lo da una apariencia porque se construye día a día. Lo da una actitud.

El respeto se parece mucho a la confianza, si bien, es algo menos frágil. Para conseguir respeto necesitas tiempo, para perderlo mucho menos. También suelen ir de la mano ya que sueles respetar a quien confías y confiar en quien respetas.

El respeto tiene mucho que ver con la objetividad (también con la implicación), primero contigo mismo, ¿exiges a los demás lo que te exiges a ti?, ¿crees realmente que si las cosas no van bien no tiene nada que ver contigo?, ¿tratas con respeto a quiénes quieres que te respeten?, después con los demás, ¿creas situaciones de injusticia por dar un trato desigual a diferentes personas por la relación personal que mantienen contigo? (ten en cuenta que estamos hablando en el terreno profesional y no en el personal o familiar), ¿escuchas en la misma proporción que te escuchan?, ¿estás dispuesto a ir a las trincheras cuando hay problemas?…

El respeto no se compra, se gana, no se provoca, surge.

Quien piense que desarrollar con metodologías ágiles es más tranquilo o más sencillo, está totalmente equivocado, bien porque no sabe realmente qué es esto o porque los proyectos en los que ha participado o seguido y en los que teóricamente se aplican principios y prácticas ágiles no lo son en realidad.

Si hay algo que caracteriza a los desarrollos aǵiles es la intensidad. ¿Cómo si no se puede sacar cada poco tiempo una versión del producto potencialmente dispuesta para pasarse a producción?. Esto solo se consigue si todas las partes: desarrolladores, usuarios y restos de implicados participan con gran implicación en el proceso de desarrollo.

Si te duermes no cumples los compromisos.

A cambio de eso encuentras otras satisfacciones como el hecho de que se valore más el trabajo de las personas, la comunicación e interacción entre las mismas y el concepto de equipo (hay de todo, pero si las personas y el producto no son el centro de todo, estaremos hablando de metodologías ágiles pero no de agilidad real), la posibilidad de autogestionar tu trabajo y algo muy importante, ver como poco a poco vas construyendo un producto que sabes que va a resultar de utilidad y que no se va a quedar en una rama perdida en el sistema de gestión de versiones.

Los enfoques clásicos son mucho más irregulares en ritmo y si no hay premura en los plazos tienden a eternizarse, esto se hace más evidente en el desarrollo de grandes sistemas de información que parece que no terminan de ponerse en producción nunca y no es raro encontrarnos con sistemas que llevan más de dos o tres años de desarrollo (incluso con exigencia) y que no terminan de rematarse, algo que no es, en absoluto, una buena señal, porque se pondrá en marcha una aplicación mastodóntica sobre la que se tendrán que realizar ajustes, siendo el número de ellos proporcional a su tamaño y complejidad.

Se asocia ágil a desorganizado, a improvisación y no es así, si así fuera sería impensable tratar de cumplir unos compromisos cada poco tiempo. Muchas veces lo que parece organizado por el simple hecho de tener definidos ciertos entregables no es más que una fachada que esconde una gestión caótica.

No es lo mismo hacer sprints sobre productos consolidados o basado en modificaciones leves o moderadas sobre funcionalidades ya implementadas, que los primeros sprints relacionados con el desarrollo del sistema, con el desarrollo de una nuevo subsistema o con modificaciones sensibles de su funcionalidad.

La diferencia es el esfuerzo que hay que dedicar para preparar el siguiente sprint, para tener esa materia prima necesaria para que la maquinaria no pare.

Ese esfuerzo se realiza en paralelo con el sprint en curso por lo que es necesario tener en cuenta ese aspecto a la hora de estimar la velocidad de desarrollo si hay personas del equipo que participan en la obtención de la materia prima, ya que no se debería contabilizar una dedicación del 100% de las mismas al sprint.

De lo contrario estas personas tendrán una dedicación superior al 100% en la iteración y la consecuencia de esto es el overtime y la imposibilidad material en determinadas circunstancias de atender a demandar ya sea del propio desarrollo o de la preparación del siguiente sprint.

Trabajar con sprints requiere una gran implicación porque se trata de una maquinaria que no para: termina un sprint y empieza el siguiente, se trabaja en un sprint mientras se prepara el siguiente. Estas condiciones no la aguantan todos los responsables funcionales (el equipo de proyecto, como comentaba antes, sí que puede si modula bien los esfuerzos) y es una de las circunstancias que hacen complicada la puesta en marcha de este tipo de enfoques.

Si el responsable funcional, product owner o como lo queramos llamar no se implica, no entiende esta dinámica de trabajo o sencillamente no puede dedicar el tiempo necesario a esto se rompen las reglas del juego y obligará a enfocar el proyecto de otra manera.

¿Por qué? No tendremos la materia prima necesaria para el siguiente sprint, ¿alternativas? parar el desarrollo por sprints o reducirlo a lo que se pueda abordar con la materia prima disponible y pactar con el responsable funcional un tiempo para seguir definiendo funcionalidades del sistema, ¿es esto volver a lo de antes?, ¿es esto volver al enfoque clásico?, no es así exactamente ya que el enfoque sigue siendo iterativo incremental, lo que sucede es que se pierde el ritmo de desarrollo que tienen los sprints y como consecuencia se disminuye la velocidad con que se agrega valor al producto y la capacidad de adaptación al cambio.

La respuesta a esta pregunta dependerá de si eres programador o tester y de la experiencia que hayas tenido en modelos de trabajo en los que intervienen ambos tipos de perfiles.

Como he leído en más de una ocasión: el objetivo del testing no es encontrar incidencias sino de proporcionar información sobre la calidad del producto (algo que cubre un dominio mucho más amplio de actuaciones).

Alcanzar ese objetivo no es fácil porque requiere un cierto background previo:

– Que los programadores consideren a los testers y los testers a los programadores como parte de un mismo equipo que busca un mismo fin: el desarrollo de un software de calidad que satisfaga las expectativas de los usuarios. Esto requiere tirar muros para conseguir una mayor cercanía (no necesariamente física, aunque si lo es, mejor).

– Un mismo fin no se ve de igual manera si existen diferentes niveles de implicación: Todos somos, dentro de nuestro rol, importantes para alcanzar los objetivos del proyecto y por tanto nuestro nivel de implicación para conseguirlo debe ser el mismo.

– Que los objetivos de calidad del software estén consensuados entre todas las partes y sean acordes a la naturaleza del producto y al contexto del proyecto. Además se debe dar la posibilidad a que sean modulados en función de los cambios que a buen seguro se producirán a lo largo del proceso de desarrollo.

– Que los mecanismos y métricas para medir el grado de cumplimiento de los objetivos sean conocidas y objetivas.

– Que los procesos no obstaculicen un modelo de trabajo que requiere flexibilidad y comunicación continua (sin comunicación este modelo no funciona).

Si se desarrolla software para un tercero es esencial la participación intensiva del mismo, no solo para mejorar el producto como consecuencia del feedback sino para que se sienta implicado en el mismo.

Cuando un cliente o un conjunto de usuarios se sienten implicados en el desarrollo del producto es muy diferente ya que defenderán el mismo en una fase tan complicada como es la implantación y puesta en marcha y serán más conscientes del impacto que tiene el cambio de prioridades o de requisitos en el producto final.

De hecho buena parte de los proyectos que fracasan son precisamente por la falta de participación e implicación de los usuarios ya que en lugar de pararse los desarrollos, que es lo que habría que hacer para volver a reorientar a las personas implicadas o para rescindir el contrato (a la larga en un proyecto de estas características todos pierden), se decide huir hacia adelante dejando que el equipo de proyecto rellene las lagunas que no ha especificado el usuario y no tenga la oportunidad de recibir su feedback.

La necesidad de colaborar con el cliente se encuentra implícitamente en el Manifiesto Ágil cuando se refuerza la interacción de las personas por encima de los procesos y explícitamente cuando se refuerza la colaboración con el cliente por encima de la negociación contractual.

El cliente no es el enemigo, después las circunstancias en el proyecto puede provocar que llegue a serlo (en ese caso hay que intentar cerrar el proyecto o el contrato cuanto antes, ya que el desgaste no favorece a nadie y puede condicionar relaciones futuras), pero de base no lo es y es necesario que vaya de la mano con nosotros para alcanzar los objetivos.

A veces esto requerirá bastante trabajo adicional y mucha mano izquierda pero si realmente se consigue que estén alineados con el proyecto merecerá la pena ese esfuerzo.