5 pecados de la Administración de Proyectos de software
5 pecados de la Administración de Proyectos de software
La mala gestión ocurre en software. Una serie de decisiones y acciones conducen a esta situación. A lo largo del tiempo, he identificado cinco que siempre están presentes y te las describo
Durante mi vida profesional en desarrollo de software, ha sido común que los equipos emitan quejas por la forma en que son administrados, y que los managers emitan quejas porque sus creen que desarrolladores no se encuentran comprometidos con la organización. Es una especie de divorcio por incompatibilidad de ideas y prácticas, que no favorece la colaboración y mantiene un conflicto constante.
Ambas partes coinciden en lo siguiente:
No se sienten comprendidos ni apoyados por su contraparte
El equipo de desarrollo considera que el manager no entiende cómo es el trabajo del software, mientras que el manager considera que no le hacen caso
Cada grupo camina en direcciones diferentes
Las decisiones son impuestas, en lo técnico y en lo administrativo
Esto no ocurre de la noche a la mañana. Una serie de decisiones y acciones conducen a esta situación. A lo largo del tiempo, he identificado cinco que siempre están presentes y te las describo a continuación.
Nombrar un manager que no sabe de management
Muchas organizaciones definen un path de carrera para sus trabajadores, en el que solo pueden acceder a un mejor sueldo mediante ascensos. Sin embargo, los ascensos no tienen una coherencia con el perfil o los hacen con criterios como la antigüedad. Así, los perfiles técnicos ascienden en “seniority”, pero alcanzan un tope en ese camino y el siguiente nivel es management, donde ya no son competentes. Sin embargo, las organizaciones los ascienden; pierden capacidad técnica para ganar incapacidad gerencial.
Una persona que llegó al puesto por ascensos de “mérito” o “antigüedad” no tiene completamente desarrolladas las capacidades de gestión, mucho menos para hacerlo en solitario. Las organizaciones creen que un curso de unas pocas semanas serán suficientes, cuando desarrollar un buen manager requiere de meses, si no es que años. En el mejor de los casos, tendrán esa capacitación, pero lo habitual es que los dejen aprender sobre la marcha.
Otras organizaciones contratan a los managers, pero muchas se guían por las credenciales como las certificaciones o los títulos, que en varias ocasiones no son evidencia de capacidad.
En ambas situaciones, el trabajo de management será controlador, en lugar de facilitador.
Una sola persona hace todo el trabajo de gestión
El trabajo de desarrollo de software es muy complejo para que solo una persona lo administre. Muchas decisiones en dominios diversos, lo que requiere un amplio entendimiento de todos. Esto conduce al micromanagement, con resultados mixtos, pero usualmente malos.
Las organizaciones suelen nombrar a una persona como responsable del resultado de un desarrollo de software. Estas personas, si son capaces, sabrán delegar. Lo usual es que no lo hacen y quieren tomar todas las decisiones.
Además, cada persona tiene un dominio preferido diferente, en el cual basará sus decisiones: el cliente, la tecnología o su equipo. Un desarrollador de software que llegó a management por ascenso suele tomar decisiones basándose en aspectos técnicos, mientras que un manager contratado externamente al equipo estará ocupado primero del negocio.
Las mediciones son un método de castigo
Medir es importante en los equipos. Las métricas proveen información objetiva acerca del desempeño del trabajo y su análisis conduce a decisiones asertivas para mejorar. Claro está, cuando tienen ese fin.
Muchas organizaciones establecen los KPI y los OKR, a veces por mera costumbre, y los evalúan periódicamente, pero no son una forma de entender el estado actual de la organización y actuar asertivamente, sino para castigar y culpar. Esto es evidente cuando se establecen parámetros de medición irreales (calendarios muy apretados, por ejemplo) y las presiones y reclamos están a la orden del día.
En estas condiciones, los managers suelen hacer lo mismo con su equipo: definir métricas y mediciones individuales para evaluar el desempeño de las personas, lo cual solo se traduce en beneficio o perjuicio individual (aumento salaria, ascenso, adquirir derechos como home office, etc.) en lugar de impactar a todo el equipo.
Lo común es que los resultados de las mediciones sean falsos y no reflejen la realidad.
El plan de trabajo se impone y no se adapta
Planificar es tan importante que debemos hacerlo todo el tiempo, sobre todo en un trabajo como el software tan propenso a los cambios. Crear un único plan y seguirlo al pie de la letra resulta contraproducente. Sin embargo, es algo que muchas organizaciones quieren hacer.
Una planificación del trabajo incluye muchos elementos, pero varios managers suelen enfocarse en uno: la lista de tareas y sus fechas. Ellos hacen el calendario y lo comunican al equipo; después, verifican el cumplimiento de las fechas, sin hacerle cambios al plan. De aquí surge la creencia de que “el equipo no está comprometido”.
Un plan es una estrategia para lograr los objetivos. Si el plan no funciona, se debe de cambiar. Además, el equipo de trabajo debe hacer el plan, en lugar de provenir de una fuente externa.
Un proceso organizacional inflexible
Las organizaciones dedican tiempo y esfuerzo en definir su cultura, valores y principios. Quieren que eso esté en todas sus actividades, así que trabajan en crear procesos y políticas. Liberan esos procesos y esperan que todos los usen sin cambiarlos. Algunas organizaciones permiten los cambios, pero lo hacen a través de un método lento y burocrático. Una vez, en un empleo, solicité cambios en un proceso, y dos años después me respondieron que no sería posible implementarlos (para entonces, yo había dejado de trabajar ahí).
Un proceso organizacional inflexible entorpece el desarrollo de software, porque cada producto y equipo es diferente y requiere una práctica distinta. Muchos managers actúan como policías del proceso, previniendo modificaciones en la forma de trabajo y pidiendo que se siga el proceso definido. El trabajo burocrático aumenta, pero los resultados no son mejores.
Estas no son todas las decisiones y prácticas de management con impacto negativo, solo son las más comunes. Probablemente, tu equipo tenga otras, de las que me encantaría contigo discutir en los comentarios.
El management es importante y debe hacerse en el trabajo de desarrollo de software (de eso hablé en el video enlazado abajo), pero debe hacerse correctamente; para ello, hay que desarrollar las habilidades en todo el equipo y lograr la autodirección. En aprendIS te guiamos y acompañamos en este proceso, que te conducirá al alto desempeño y los resultados extraordinarios.
¡Hasta aquí la serie relacionada a project management! Si tienes preguntas o quieres discutir más al respecto, contáctame a este mismo correo electrónico o agenda una charla en https://www.edgarfernandez.com/booking/ ¡me dará mucho gusto hablar contigo!
Nos tomaremos un par de semanas de ausencia y volveremos con un tema nuevo. ¡Hasta pronto!