archivo

Archivo de la etiqueta: microgestión

Lo he dicho en numerosas ocasiones y sigo pensando lo mismo: pensar que se puede controlar un proyecto es una forma de engañarnos. Pero una cosa es eso y otra es dejar que sea el proyecto el que te controle a ti. Entre ambos extremos hay muchos matices.

Para poder tener algo controlado implica que se pueden dominar los factores externos y prever las reacciones de las personas. Eso no lo vas a conseguir casi nunca. Lo que sí puedes hacer es analizar el enfoque que más le conviene, realizar ajustes o cambiar si es necesario, evaluar riesgos, analizar la situación y los resultados con los usuarios o con el cliente para obtener feedback, adaptar la carga de trabajo a lo que el equipo y el área usuaria pueden asumir y reajustar posibles plazos, costes y alcance.

¿Te asegura eso el control? No, pero sí es una lanzadera para adaptarte al cambio y a las necesidades del proyecto, pero, ¿solo con eso?, es más efectivo (mucho más) si todas las partes aceptan este esquema de trabajo y si las resistencias al cambio: rigidez de los procesos y deuda técnica, no suponen un porcentaje significativo del esfuerzo.

El camino no es la microgestión porque lo único que se obtiene a través de ella es el rastro de miguitas de pan o la traza del proyecto pero no aporta soluciones.

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).

La microgestión encorseta, resta libertad, en definitiva, resta agilidad a los equipos y personas afectadas por las mismas. Define tiempos pero que sea el suficiente para los equipos y personas puedan organizarse sus tareas, que puedan cambiar de unas a otras y repartan su dedicación como las mismas y ellos vayan necesitando. No hace falta que marques todo el camino con migas de pan (o por lo menos no debería ser el caso general), si el desarrollador es responsable sabrá lo que tiene que hacer y si no lo es (que no todos lo son) lo mismo hay que plantearse si debe permanecer en el equipo.

La microgestión surge para crear una falsa sensación de control. Falsa porque la mayoría de las personas que trabajan bajo este contexto “medio cumplen” (no tienen más remedio que ser creativos con las mismas porque de lo contrario no pueden sacar trabajo efectivo hacia adelante) esas planificaciones meticulosas y los datos que facilitan para el control de los trabajos no son del todo ciertos (maquillaje para hacer pensar que se está siguiendo a rajatabla lo que se pide). Y también falsa porque si tienes problemas de control del proyecto probablemente el problema no se resuelva imponiendo más mecanismos de control (porque entiendo que alguno tendrás) ya que se encontrará asociado a otros factores.

Si hay que correr dame las mejores zapatillas y dime dónde y cuándo hay que llegar, deja que dentro del camino elija bajo la responsabilidad de mi rol el mejor trayecto pero no me des de antemano el track y el paso de tiempo por kilómetro porque lo mismo pensaste que el cielo iba a estar despejado y hace tormenta, porque lo mismo pensaste que el firme era perfecto y estaba lleno de irregularidades y porque lo mismo me cambian la meta a mitad de camino.

La microgestión o gestión orientada al detalle tiene un importante overhead tanto por parte de quiénes realizan las tareas como por parte de quien las supervisa. Trabajar de esta manera requiere una gran disciplina de manera que solo se tiene actualizado el estado de las tareas si quienes se encargan de su ejecución tienen muy asimilada esta forma de trabajar.

Otro inconveniente importante es que se crea un contexto de escasa flexibilidad ya que los objetivos se equivocan: lo importante es realizar las tareas asignadas a tiempo sean o no lo que convenga al proyecto o aunque hayan cambiado las circunstancias. ¿Que no hay problemas en cambiar la planificación? Pues nada, a actualizar se ha dicho y el tiempo invertido en ese ajuste dependerá del cambio realizado en la planificación y de la cantidad de trabajo planificado. Este trabajo es a veces tan ingente que con tal de no tener que hacerlo se realiza la tarea y punto.

Pero de todos los posibles inconvenientes el más significativo y con diferencia es que la microgestión no se lleva bien por las circunstancias indicadas: excesivo overhead y falta de flexibilidad con una situación de incertidumbre como rodea a los proyectos de desarrollo de software.

No se trata de no saber qué es lo que se va a hacer hoy o de que podamos seguir como va evolucionando el proyecto pero la verificación del cumplimiento de los objetivos se debe realizar a más largo plazo, ¿cuánto? dependerá del contexto de la actividad, de la tarea o del proyecto.

Con la microgestión se crea una falsa sensación de control: “tengo todo planificado, al detalle, si surge un imprevisto siempre podré reaccionar a tiempo porque sé como va todo y qué está haciendo cada uno”, ¿alguien se cree que de esta forma se tiene un mayor control? Yo no digo que no, dependerá del gestor y del equipo, pero lo que no creo es que de esta manera se responda mejor al cambio, es decir, no creo que el esfuerzo que requiere (y si la gente es sincera indicando el estado real de las tareas) merezca los resultados que, por regla general, va a ofrecer.