archivo

Archivo de la etiqueta: autogestión

Una reacción frecuente por parte de los gestores, ya sea de la parte usuaria o del equipo de desarrollo, cuando aparecen problemas es tratar de ejercer un mayor control sobre el proyecto.

Esto puede tener efectos beneficiosos o perjudiciales en función de cómo realmente se enfoque ese control y si se toman o no decisiones para resolver los problemas reales que tiene el proyecto.

Creo en la autogestión pero por mucho que creamos en ella depende al final de al actitud de las personas que forman parte del equipo y del grado en que terceras personas que pueden ser otros gestores o no influyan en el día a día del equipo.

Si el equipo no es capaz de autogestionarse es necesario tratar de conseguir un orden con el objeto de que el equipo funcione de nuevo de manera adecuada e incluso sea capaz de autogestionarse. Las actuaciones deberán ir dirigidas a dar un orden y criterio a los trabajos y también a tratar de resolver los problemas que han provocado que el equipo no funcione como tal y/o hayan provocado que se llegue a esta situación.

Se trata por tanto de un mayor control orientado a buscar un equilibrio que permita volver a una situación de normalidad en la cual ya no sea necesario esa intensidad en el control.

El tiempo que se tarda en recuperar el equilibrio dependerá del caos que exista en el proyecto y los problemas en las relaciones entre cliente y proveeedor por lo que en muchas ocasiones no se consigue volver a una situación de normalidad y se requiere una alta implicación del gestor.

Evidentemente llegada a esa situación el gestor deberá hacer autocrítica porque si se llega a ese nivel de caos y contaminación en el proyecto es porque no ha sabido leer el estado en el que se encontraba y/o porque no ha tomado las decisiones adecuadas en el momento o momentos en que era preciso.

Pero una cosa es ejercer un mayor control y otra su exceso porque tal vez se consiga dar un cierto orden a los trabajos pero puede provocar que los desarrolladores se bloqueen y teman equivocarse lo que afectará a su productividad y a la búsqueda de soluciones que vayan más allá de su zona de seguridad.

El desarrollo de software requiere un importante esfuerzo intelectual por parte de las personas que participan en él. La efectividad depende de que el talento y experiencia de cada persona esté enfocada en el trabajo, tarea o proyecto que mejor se adapte a esa capacidad y que, además, le motive.

Dado que no se trabaja solo, resulta muy importante que las personas que conforman los equipos encajen.

Obtener el máximo rendimiento de las personas no es tarea fácil, ya que son muchos los factores que pueden influir en el mismo, para empezar sus propias circunstancias.

Sabiendo que no es sencillo y que es utópico pensar que el 100% del tiempo se va a tener un rendimiento óptimo de las personas y de los equipos, sí que existen una serie de aspectos a tener en cuenta, porque el hecho de que sea difícil no significa que no se intente, es más, es necesario dedicar el esfuerzo necesario para intentar aproximarnos lo máximo posible a ese límite:

– Fomenta la autogestión de las equipos. Los que viven el día a día del proyecto saben mejor que nadie cómo deben organizarse, quién se organiza tiende a ser más responsable con el resultado de su trabajo. Eso no quiere decir que los desatiendas, ya que muchas veces desde fuera se ven cosas que no se ven desde dentro y porque hay información ya sea del cliente o de la propia organización que llega a través de ti. Por otro lado, si respetas el espacio de tu equipo, ellos respetarán el tuyo y las retrospectivas sobre el trabajo que se está realizando serán más provechosas.

– Intenta minimizar los cambios de contexto. El fraccionamiento de las personas en múltiples proyectos es ineficiente para las personas y para los proyectos. Hay determinados tipos de perfiles donde no queda más remedio, en ese caso, trata de ajustar la capacidad de trabajo que puede absorber a su límite real.

– Trata de evitar los parones en los proyectos. Esto es algo que no dependerá de ti en la mayoría de los casos, pero sí que puedes intervenir para tratar de prevenirlo. Esto requerirá una atención tanto al proyecto como a la información que te haga llegar tu equipo.

– Las personas no son robots, ni sus aptitudes son las más adecuadas para todos los contextos, por tanto, no les trates como máquinas, conoce sus puntos fuertes y sus puntos débiles, dedica tiempo a saber qué le motiva y con qué grupo de personas puede encajar mejor. Si existen diferentes alternativas, pregúntale cuál se le apetece más, a cuál cree que puede aportar más y por qué. No es lo mismo que tu empujes a una persona a dar un paso a que sea ella misma quién lo decida, ya que el nivel de implicación no será el mismo.

La organización debe tratar de no ser rígida en la promoción profesional, centrándose exclusivamente en promociones verticales y en un itinerario establecido. Las personas son diferentes, plantea diferentes itinerarios.

– Buscar el rendimiento óptimo de las personas basado en mecanismos de recompensa, no suele proporcionar buenos resultados a la larga porque en el momento en el que por el motivo que sea esas recompensan menguan o desaparecen, la motivación se irá con ellas.

Es importante premiar a quién lo hace bien y eliminar de la organización la idea del “nunca pasa nada” aunque se falle estrepitosamente en una serie de proyectos, pero orientarlo más que a un hecho concreto a una trayectoria (lo cual no quita que puedan existir logros excepcionales con recompensas también excepcionales), esto implica la existencia de una carrera profesional, en donde buenos resultados se terminen consolidando en tus ingresos.

– Adapta la cantidad de trabajo que puede asumir un equipo a su capacidad real, lo contrario da lugar a situaciones de bloqueo y de pérdida de calidad que influyen directamente en los resultados. Es posible que el overtime consiga solventar estas dificultades durante un tiempo, pero poco después, la cantidad de trabajo real que se pueda sacar será menor que con el horario normal (fruto del cansancio y de modular tus fuerzas a la jornada laboral), a lo que habrá que sumar el sobrecoste de una mayor deuda técnica y tasa de fallos.

– Siempre hay trabajo que hacer, si hay una persona o un grupo de personas desocupadas y te interesa mantenerlas en la organización, crea un proyecto o proyectos internos, haz que actúen de soporte en proyectos que estén en marcha (siempre y cuando su entrada no rompa el ritmo de trabajo) y/o realicen tareas de testing, utilízalos de apoyo para tareas comerciales, etc…

En estas circunstancias, además, se puede saber si una persona está motivada o no por seguir en la organización, ya que quien quiere trabajar, se inventará el trabajo y si le preguntas te expondrá muy probablemente diferentes alternativas en las que poder ayudar.

Lo peor que se puede hacer es dejar a estas personas sin hacer nada porque muy probablemente afectarán directa o indirectamente a las personas que sí están implicadas en proyectos.

Lo deseable es que el equipo coja velocidad de crucero desde el primer sprint, sin embargo es algo que resulta muy complicado salvo en aquellos proyectos en los que el equipo esté habituado a trabajar junto y/o con una orientación a sprint, esté perfectamente habituado a la tecnología de desarrollo y en donde las historias de usuario sean de calidad y fácilmente asimilables por los desarrolladores.

Lo más normal es que el equipo pueda asumir menos carga de trabajo al principio y la vaya aumentando conforme los factores anteriores se van asentando, hasta llegar a esa velocidad de crucero, que, ¿por qué no?, podría ir mejorando con el paso del tiempo.

Trabajar con agendas puede implicar un nivel de exigencia alto al equipo desde el primer sprint, un nivel de exigencia que se sitúa por encima de lo que el equipo puede dar en ese momento. Desde mi experiencia os puedo asegurar que no es positivo porque no asegura el adecuado cumplimiento de los compromisos (que esté programada una funcionalidad no es cumplir el compromiso, cumplirlo es que funcione y esté en disposición de pasarse a producción si así se considerase oportuno) y porque el equipo empieza a desgastarse desde muy pronto y eso afecta negativamente a los trabajos teniendo en cuenta que todavía queda mucho proyecto por delante.

¿Qué hacemos? Si se puede intentar adaptar la agenda a lo que el equipo puede dar e incrementar si se puede el equipo o la dedicación de las personas que ya participan en él (si hay personas que puedan incorporarse al equipo en donde su saldo de participación neto: lo que aporta menos lo que el equipo tiene que invertir para conseguir esos resultados es positivo o puede serlo a muy corto plazo y hay trabajo por delante que lo justifique).

Por tanto, es conveniente dejar que el equipo vaya adquiriendo paulatinamente esa velocidad de crucero, no hay que olvidar que tienen que cumplir unos compromisos, que ponen mucho en juego y que por tanto, ellos de manera responsable deben autogestionar la capacidad de trabajo que pueden asumir en cada momento.

Un equipo de personas que no se entienden, que no conectan, que no está equilibrado, es una forma de tirar talento individual a la basura porque en el desarrollo de software se obtiene provecho de ese talento cuando se pone a favor de un colectivo, en el que se rompen las matemáticas porque su valor conjunto será mayor que la suma de las individualidades. Esto es así porque se complementan conocimientos y experiencias y porque visiones diferentes de un problema ofrecen mayores alternativas de solución.

Si un equipo no funciona, el proyecto no irá bien. Y no hace falta mucho para que un equipo no funciona, como tampoco hace falta mucho para que un código no compile. Por ese motivo, es necesario hacer un esfuerzo para conformar el mejor equipo posible dentro de la disponibilidad que exista en la organización.

Este antipatrón surge cuando no se le da importancia a la formación del equipo, seleccionándose exclusivamente perfiles sin tener en cuenta a las personas, como si fuéramos simples piezas de una maquinaria que se escogen al azar, y si hay algo que no es precisamente simple son los seres humanos.

El lado opuesto del antipatrón se encuentra en dar autonomía a los equipos para que sean ellos mismos los que seleccionen a las personas que lo van a formar y decidan sobre las entradas y salidas a lo largo del proyecto. Quienes están a pie de obra saben muy bien (aunque se equivoquen) quiénes pueden ser los mejores compañeros para este viaje.

Si no se cae en malas prácticas como el amiguismo o la falta de responsabilidad es una fórmula que puede funcionar muy bien, siempre y cuando exista comunicación fluida y en confianza con los gestores (recíproca) porque no todas las variables se encuentran en el equipo, ya que hay otras que se mueven a otro nivel ya sea dentro de la organización o en las relaciones cliente-proveedor.

Hay quienes consideran que el simple hecho de que el equipo sea designado por un tercero es un antipatrón (de hecho lo denominan: equipo designado). Yo no estoy de acuerdo con que ese simple hecho constituya una mala práctica, por mucho de que, por regla general, sean más óptimas soluciones más abiertas como la que comento en el párrafo anterior, ya que el antipatrón surge por no hacer esa selección de manera responsable, pensando más allá que en el simple hecho de cubrir huecos con personas.

Agilidad es intensidad. Es una diferencia fundamental con otros enfoques o estrategias de desarrollo de software. La intensidad requiere proximidad (no necesariamente física), en la que los componentes de los equipos se vean entendidos, apoyados y respaldados.

No vale con dar cuatro directrices generales basadas en enfoques ágiles, seguir los trabajos desde lejos y después pedir responsabilidades o esperar resultados. Autogestión sí, por supuesto, microgestión no, también, pero sobre todo responsabilidad a la hora de gestionar proyectos y saber cuál es tu papel.

Si sigues metodologías, estrategias, enfoques o prácticas ágiles, no te debes quedar en la teoría o en hacer que tus equipos cumplan con ella, sino que debes entender cuál es el contexto del proyecto, para saber en cada momento qué es lo que más le conviene, y conocer los problemas del día a día. No se puede ser facilitador desde la distancia, no puedes hacer sugerencias, definir estrategias o pedir correcciones si no sabes qué es lo que está pasando. Tienes que comprometerte con el proyecto y con las personas que lo están sacando para adelante.

Si no actúas de esa forma serás una resistencia más que un apoyo y si quieres dar una visión agilista al proyecto, se quedará fundamentalmente en el aspecto metodológico (cuando la agilidad realmente es cuestión de actitud) y en lo que el equipo de trabajo tenga a bien sacar adelante por sus propios mérito y esfuerzo. Este antipatrón podría considerarse como un caso particular de una definición más genérica como es la de “falso agilista“.

Llegado a un punto el esfuerzo necesario para mejorar el control que se tiene de un proyecto crece exponencialmente. Esto es así porque hay todo un universo de detalles dentro y fuera del proyecto que inciden en él.

El deseo de control lleva a la microgestión y ésta a su vez a una pérdida importante de la capacidad de autogestión del equipo, ya que todos los pasos se miden milimétricamente.

Otra consecuencia es que se tienden a centralizar muchas tareas, para ser ejecutadas directamente o, al menos, supervisadas por quien controla. Al ser la capacidad de trabajo mayor que la que puede asumir esa persona, su deseo de control se termina convirtiendo en un problema ya que se convierte en un cuello de botella y, además, su tasa de fallos se incrementa.

Las consecuencias de lo anterior son las siguientes:

– Falta de flexibilidad a la hora de adaptarse al cambio provocado por la pérdida de autonomía (llevado a un extremo, sus colaboradores dejarán de tomar decisiones incluso en aspectos de poca importancia, ante el temor de la reacción que pueda tener el controlador o por el escaso interés que muestra por opiniones de terceros), los cuellos de botella y por las normas estrictas de control que se han establecido.

– El equipo de proyecto al reducirse su margen de toma de decisiones, pierde implicación en el proyecto.

– Coste adicional en tareas, hitos o entregables relacionados con el control del proyecto y que no aportan un valor real al mismo.

La mayoría de nosotros ha caído en mayor o menor medida en este antipatrón, empujado generalmente por la presión externa y por el deseo de sacar adelante el proyecto. Es cierto que hay proyectos y equipos que requieren una gran implicación pero eso no debe confundirse con un control que sea nocivo para el proyecto.

Saber cuál es el punto exacto de control que requiere un proyecto no es fácil, porque en cada uno es diferente y es más que posible que a lo largo del proceso de desarrollo, cambie, incluso más de una vez. Una vez más, la experiencia te permitirá equivocarte menos (si es que has aprendido de los errores anteriores).

Para Jeff Sutherland: “El compromiso de trabajar juntos sólo ocurre cuando las personas están de acuerdo en objetivos comunes y luego luchan para mejorar como personas y como equipo”.

Precisamente por eso es tan complicado alcanzar ese compromiso y por eso creo que se requiere un cierto bagaje personal y profesional para entender qué ventajas supone trabajar de esta manera y lo necesario que resulta para sacar adelante los proyectos.

Los equipos funcionan cuando existe un compromiso entre los miembros del equipo. Cuando cada cual va por su cuenta no estamos hablando de equipo sino de un conjunto de personas que comparten un espacio físico.

El compromiso es dar lo mejor de nosotros mismos por el equipo y por el proyecto y exigir a los demás que hagan lo mismo. Si el nivel de exigencia no es justo favoreciendo a unos sobre otros, no se debe llamar compromiso, sino amiguismo ya que el compromiso solo tienes con unos cuantos y esos cuantos contigo.

Tampoco son buenas las políticas del todo el mundo es bueno, porque generalmente cuando se aplican es precisamente para evitar ciertas decisiones poco agradables. Lo fácil siempre es hacer la media aritmética y tratar a todos por igual lo hagan bien o lo hagan mal, estén comprometidos o no. Este tipo de estrategias hacen mucho daño a aquellas personas que precisamente ofrecen un mayor compromiso.

Cuando un equipo funciona tiene como consecuencia natural la autogestión en la que cada miembro del equipo asume su responsabilidad y se resuelven los conflictos en el equipo (salvo que por su trascendencia tengan que escalarse).