archivo

Archivo de la etiqueta: equipo de proyecto

Si empiezas a tomar decisiones sin escuchar a nadie llegará un momento donde los componentes de tu equipo dejarán de expresarte su opinión y se perderá con ello todo ese valor que pueden aportar al proyecto, porque muchas veces no se trata exclusivamente de que las personas realicen sus tareas habituales, sino de que puedan aportar su visión sobre otros aspectos o circunstancias (técnicas o no) que pueden ocurrir en el proyecto.

No sabes de todo, no entiendes todo, no lo ves todo. Más personas tienen más capacidad de interpretar un problema desde distintas perspectivas. No creas que tienes siempre la respuesta para todo y que no hay mejor solución que la que tienes en mente, puede que sea buena, pero con las aportaciones de tu equipo es muy probable que sea mejor.

Todas las personas del equipo de proyecto son importantes, demuéstralo, escúchales, de esta forma no solo consigues aprovechar mejor su potencial sino que también estarán más implicados en el proyecto.

Soy muy partidario de escuchar diferentes opiniones y si al final mi solución no es válida o es mejorable, no pasa nada, se rectifica. No se trata de tener siempre la solución sino de hacer que la mejor solución posible llegue al proyecto venga o no de ti.

Siempre existe la posibilidad de que te toque la lotería (si la juegas) pero en el desarrollo de software lo mejor es no dejar cosas al azar.

Cuando de manera desestructurada “sueltas” a un conjunto de personas en un proyecto sin analizar si realmente tienen la capacidad para llevarlo a cabo, estás esperando prácticamente que el azar haga que las cosas vayan bien, para ello, sería necesario entre otras cosas que dicho grupo se autoorganizase de manera adecuada, fuera capaz de motivarse y ser más productivo y de tener la resistencia necesaria para hasta adquirir las habilidades requeridas (no solo técnicas) para sacar adelante el trabajo. Esa transformación es posible pero muy complicada.

Ese grupo, además, contará con muy poco apoyo de la organización, salvo que sus resultados sean lo suficientemente llamativos, ya que poco se puede esperar de quiénes han confiado de manera tan pobre en el proyecto y no le han dedicado lo que necesita.

En el caso de que ante tantos obstáculos se consiga el éxito hay algo de lo que no tendrá que preocuparse ese equipo y es el de levantarse temprano el día que repartan las medallas ya el día anterior los mismos que los pusieron en el disparadero se la habrán llevado todas.

Abrir la mente es fundamental, no basta solo con poner los oídos sino que hay que estar dispuesto a escuchar y a poner en tela de juicio tus opiniones y tu punto de vista sobre los temas que se están tratando. Si de entrada crees que tienes la razón, la solución o la respuesta y que los demás, digan lo que digan, no la tienen, no hay forma de poder enriquecerse con las aportaciones que te hagan.

Si todo el equipo tuviera esa actitud solo quedaría como salida el “ordeno y mando” y eso limita mucho su capacidad porque se desaprovecha el talento individual y el colectivo y no se crea el contexto necesario para tener un equipo de proyecto dinámico y colaborativo en el que todos se sientan importantes, algo fundamental para un desarrollo ágil y generalizando, para cualquier enfoque que se vaya a utilizar.

Eso de considerar que mis ideas o mi código son los mejores son una resistencia al proyecto y no por el hecho de serlo, sino por la actitud que se toma con respecto a ellas ya que si se consideran como la verdad absoluta pueden provocar el descarte o minusvaloración del trabajo, apreciaciones, visiones u opiniones de otros componentes del equipo de trabajo y/o de otras personas que colaboran en el proyecto.

Comenta Kent Beck que: “Los buenos equipos no sólo hacen su trabajo sino que además piensan cómo y por qué están trabajando. Analizan por qué tuvieron éxito o fracasaron. No tratan de ocultar sus errores en su lugar los exponen y aprenden de ellos. Nadie tropieza en la excelencia”.

Parece que es parte de nuestra condición huir de los errores, sin embargo, tratar de hacerlo es como intentar escaparnos de nuestra propia condición de seres humanos ya que todos cometemos errores, nadie es infalible. Piensa en alguien que crees que nunca se equivoca, pues sí, esa persona en la que estás pensando seguro que se equivoca tanto o más que tú, la diferencia realmente está en qué hacemos con nuestros errores, si lo utilizamos para evolucionar o simplemente los esquivamos.

Kent Beck insiste mucho en la oportunidad que se abre tras un error. Y me parece muy consecuente que lo haga porque tiene bien claro que la naturaleza del desarrollo de software es evolutiva y que en ese proceso de evolución hay aciertos y errores porque todos sabemos que acertar siempre a la primera es muy difícil y porque el mayor atajo para una solución compleja no es la línea recta sino pasar por soluciones más simples en las que se vayan afianzando ideas que tienen un origen abstracto.

En el fútbol se puede jugar muy bonito y no ganar ningún partido. Se puede jugar muy feo y conseguir tus objetivos. Puede que prefieras que tu equipo juegue bien a ganar o bien que tu equipo gane sea como sea.

En el desarrollo de software para ganar has tenido que jugar bien, no hay otra opción. Y jugar bien no implica aplicar tal o cual metodología sino haber sabido interpretar qué le ha venido mejor al proyecto en cada momento, que las personas que participan en él hayan estado implicadas y acertadas, que el talento colectivo haya predominado sobre el individual y que de entrada el partido no estuviera perdido (Death March Project).

En el fútbol juega un equipo contra otro, en un proyecto de desarrollo de software todos deberían jugar en el mismo equipo. Cuanto más evidente sea la diferencia entre las diferentes organizaciones, departamentos o áreas de las personas que intervienen en el proyecto, tendremos más equipos pero menos equipo.

Cuanto tenemos equipos y no equipo sí que empiezan a ponerse sobre la mesa planteamientos de ganar (o de no perder) y anteponer eso a los intereses generales del proyecto, es decir, de tratar de conseguir un resultado como sea, aunque perjudique a un tercero. Cuando eso sucede, cuando se buscan victorias parciales, es el proyecto quien pierde el partido.

Es difícil delegar. Resulta complicado tomar la decisión de perder control a cambio de que tu equipo sea más autónomo. Pero más complicado resulta que tu equipo crezca si lo tienes maniatado.

Tienes que definir líneas de actuación, establecer un marco, consensuar métodos de trabajo y tomar decisiones, pero también debes dejar que tu equipo aplique todo su potencial.

Proporcionarán puntos de vista diferentes que enriquecerán, las decisiones y actuaciones que se realicen en el proyecto, ¿qué crece el margen de error? Es posible, como es posible que no. En cualquier caso, sabemos que equivocarse es un paso necesario para adquirir experiencia. No se trata de poner en riesgo el proyecto, para eso estás tú, para tratar de detectar los fallos a tiempo o intentar que su impacto sea el menor posible, se trata de que tu equipo vaya ganando en conocimiento, en iniciativa y en entender de primera mano que no es tan fácil tomar decisiones.

Recordemos que un líder entre otras funciones debe crear el caldo de cultivo necesario para que aparezcan nuevos líderes que permitan repartir entre todos ellos, la carga y complejidad que tiene cualquier proyecto de desarrollo de software.

Ya lo dijo Lao-Tsé: “Gobierna mejor quien gobierna menos”.

Tenemos un guest star principalmente cuando se producen una de las siguientes circunstancias:

– Cuando tenemos a una o varias personas que deberían formar parte del equipo de proyecto, aunque sea en un área concreta o especializada, y que no sienten que el proyecto sea cosa suya, lo que provoca que no atiendan a compromisos o que su participación sea intermitente y generalmente para dar más problemas que soluciones.

– Cuando tenemos a una o varias personas que no forman parte del equipo de proyecto pero que en determinadas circunstancias intervienen en el mismo (llamados o no) para dar una serie de directrices o instrucciones que generalmente suponen una resistencia al proyecto.

El problema de este antipatrón es que es muy complicado de contrarrestar.

En el primer caso se puede intentar implicar en el proyecto a los guest stars dialogando con ellos, intentando que el proyecto esté más presente en su día a día pero al final será su decisión formar parte activa del proyecto o no. ¿Se puede intentar por las malas haciendo que su superior le obligue a estar implicado en el proyecto? Sí, pero salvo que su superior esté muy encima la participación seguirá siendo insuficiente o con malos resultados (porque a la falta de implicación se le sumará ahora su enfado) y en el caso de que sea aceptable será cortoplacista porque entenderá que la llamada de atención es injusta y provocada por los responsables del equipo de proyecto y a las primeras de cambio volverán a poner las mismas trabas que antes.

En el segundo caso la solución pasa por tener identificados a priori los posibles guest stars e impedir su participación en el proyecto. El problema lo tenemos cuando tienen que intervenir al ser una parte interesada, en esos casos nos tocará dialogar y razonar para intentar reducir (eliminar va a ser complicado) las resistencias que pongan.