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.

Para Pete McBreen: “La maestría o la sabiduría no han sido nunca resultado de encontrar la mejor manera, sino el resultado de un viaje de descubrimiento en que nuevas ideas son posibles, incluso en las más mundanas de las tareas”.

Por tanto, se trata de un viaje sin fin, en el que vamos evolucionando conforme vamos ampliando nuestras experiencias y conocimientos y, en donde en cualquier situación y con cualquier persona tenemos la capacidad de mejorar.

Las ideas están ahí fuera es muy pretencioso pensar que todas las tenemos en nuestra cabeza.

En el momento en que pensamos que lo sabemos casi todo y que muy pocas situaciones o personas nos pueden aportar cosas, estamos limitando, no solo nuestro conocimiento sino nuestro margen de maniobra ante un determinado problema si pensamos que la solución al mismo solo puede proceder de nosotros mismos.

Cuando trabajas con más personas, pensar que nadie te puede aportar nada o que solo algunos de ellos puede hacerlo estás cometiendo un error, te estás poniendo límites sin necesidad, estás dejando que tu arrogancia ponga resistencia al éxito.

Este tipo de actitudes llevadas al campo de los proyectos de desarrollo de software producen resultados nefastos ya que tiendes a crear castas: aquellos a los escuchas y aquellos que solo están para ejecutar trabajo y eso produce división y desmotivación entre aquellos que consideran que su opinión o conocimientos no vale para nada.

Es ciertamente potente, muy potente. Conocer de un solo vistazo el estado de las tareas y detectar cuellos de botella (aplicando Kanban o no) y que esté siempre presente supone una guía muy importante (cómo va cada cosa, qué está terminado, qué no ha empezado, etc…) para el equipo de proyecto y para el conjunto de personas implicadas en el proyecto.

Esa información se puede tener en la cabeza pero la efectividad no es la misma que captarla con la vista, es lo de siempre, no es lo mismo una imagen abstracta, por muy claro que se tenga la situación, que algo que estás viendo con tus propios ojos y más cuando se trata de un trabajo en equipo y hay una serie de personas que tienen que dialogar y tomar decisiones en base a esa información (en general y más allá de la visualización de un flujo de trabajo resulta de mucha utilidad tener esas reuniones cerca de una pizarra, es más, si te es posible pon todas las pizarras que puedas cerca de tu equipo de proyecto).

Hay muchas formas de implementar esto (orientación horizontal o vertical del flujo de trabajo, aplicar Kanban o no, hacer una separación por proyectos o no, etc…), no hay fórmulas magistrales para definir el flujo de trabajo, dependerá del proyecto y también del equipo de trabajo.

Un desarrollador de alto nivel en el rol que desempeña es capaz de rendir exponencialmente mejor que otro que no tenga sus conocimientos, experiencia y brillantez.

Cuando se trata de proyectos donde el equipo es muy reducido unas buenas individualidades pueden compensar un mal funcionamiento colectivo.

Cuando el equipo es más numeroso no vale solo con tener buenas individualidades sino que debe funcionar como tal, no se trata del no aprovechar el talento sino optimizarlo como parte del talento colectivo de manera que la suma de todo el conjunto supere a la suma de las individualidades.

Un héroe puede salvarte una vez, dos, tres veces…, tal vez incluso pueda salvar el proyecto pero no es el camino, a medio y largo plazo serán muchos los proyectos que fracasen mientras esperan que el héroe vuelva a hacer un imposible.

Hay mucho trabajo que hacer en el proyecto y cada cual se tiene que encargar de lo suyo sin olvidar que forman parte de un equipo por lo que debe existir comunicación e interacción con los demás y estar siempre a disposición del equipo para echar una mano donde haga falta. Si cada cual hace la guerra por su cuenta está creando una resistencia para el resto de sus compañeros, los cuales verán mermada su eficacia.

Bob Martin realiza la siguiente reflexión: “Un equipo de desarrolladores medios que se comunican bien tienen más probabilidades de tener éxito que un grupo de superestrellas que fallan al interactuar como equipo”.

Muchos proyectos fracasan porque no se consigue formar ese equipo (dentro de los desarrolladores) y en extensión cuando no se consigue formar un equipo con el resto de implicados en el proyecto.

Es muy importante construir ese equipo y eso no se consigue simplemente juntando una serie de personas. Muchos gestores olvidan eso y piensan que todas las combinaciones pueden ser válidas y no es así. Dentro de las opciones existentes hay que procurar conformar la mejor, a partir de ahí, con un buen equipo, se tendrá una buena base para luchar por el éxito en el proyecto.

Una vez elegida una buena combinación toca consolidar el equipo y mantenerlo que es lo más difícil teniendo en cuenta el desgaste existente en un proyecto de desarrollo de software sobre todo en circunstancias de presión, algo que por desgracia ocurre casi siempre.