De desarrollador a líder de proyecto: desafíos de la gestión para el técnico recién ascendido.

¿Se puede liderar un proyecto de desarrollo de software sin conocimientos técnicos? ¿Son imprescindibles para la gestión, o sólo una ayuda? ¿Los mejores líderes son aquellos que ocuparon puestos técnicos en el pasado? ¿O los mejores son aquellos que han estudiado y ganado experiencia específicamente en la gestión, tal vez en varios rubros? ¿La gestión tiene nada, poco o mucho que ver con lo técnico?

Comencemos por dividir (arbitrariamente, claro está) a los líderes de proyecto en dos grandes grupos: los que llegan al puesto habiendo comenzando su carrera desde el lado técnico y aquellos que llegan comenzando desde del lado de la gestión de proyectos.

Los primeros (digamos "los gestores-técnicos") serían aquellos que comienzan como programadores y progresan naturalmente hacia líderes o referentes de su equipo.

Con el tiempo las funcionalidades bajo su responsabilidad son cada vez más amplias, el equipo cada vez más grande y eventualmente abandonan del todo la programación para dedicarse exclusivamente a la gestión de uno o varios proyectos.

Bajo su responsabilidad pueden caer ya no sólo programadores sino también analistas funcionales, testers, diseñadores, administradores de sistema, de base de datos, personal de mantenimiento, soporte al cliente, etc.

Los segundos (digamos "los gestores de carrera") serían los estudiantes de carreras como Administración o Gestión de Empresas, que comienzan ayudando en la gestión de proyectos (de cualquier tipo) y van progresando hasta alcanzar el liderazgo de uno.

Así que a la pregunta "¿se puede liderar un proyecto de desarrollo de software sin conocimientos técnicos?" yo respondo "sí, absolutamente".

Por supuesto que el gestor de carrera deberá tomar experiencia en el rubro, que como cualquier otro tiene sus particularidades, su jerga, sus recovecos. Dispone para ello de un marco teórico: sabe de métodos de estimación de tiempos, de seguimiento, de ajuste, de administración de recursos, de manejo de personas, de motivación, etc.

Tendrá que aprender cuáles son las diferentes etapas del desarrollo, las muchas posibilidades que existen para recorrerlas, sus ventajas y desventajas, cuáles son los requerimientos, los productos, los tiempos y el personal necesario para cada una de ellas.

Para el gestor técnico el salto es inverso y simétrico: conoce el rubro pero deberá aprender a tratar con personas, a motivar, a liderar, a coordinar más allá de lo técnico, a evaluar y negociar cuestiones económicas, políticas, emocionales.

Desde un lado o de otro se puede llegar a cualquier nivel de excelencia o chapucería.

Pero hay un tema. El conocimiento técnico ayuda, por supuesto, sólo si no se hace abuso de él. Obviamente, el único que puede presentar estas tendencias hacia el abuso del conocimiento técnico es aquel líder con un pasado como desarrollador, ya que tiene que ver justamente con ese origen.

¿A qué me refiero cuando digo tendencias hacia el abuso del conocimiento técnico? Es más fácil dar ejemplos que tratar de definirlo, así que invento algunos:

• Imponer estimaciones de acuerdo a su conocimiento técnico. Pero ya no es él quien ejecuta las tareas (eso era antes), y puede que no acepte que los tiempos de su equipo ya no son necesariamente los que él hubiese presentado.

  Por otro lado, un gestor de carrera confía necesariamente en las estimaciones de su equipo, simplemente porque como él no puede evaluarlas técnicamente no puede discutirlas. Podrá negociarlas, requerir más esfuerzo o más recursos, pero jamás objetarlas en términos de "esto está bien o mal".

  Claro que el gestor de carrera puede imponer estimaciones. Como dije antes, a la chapucería se llega desde cualquier lado.

• Reservarse la resolución de cuestiones técnicas y no transmitir requerimientos funcionales. Es un poco lo que comentaba en Requerimientos: cuando no son asteroides sino sólo polvo cósmico.

  Si el líder no controla su "corazoncito técnico", puede tender a resolver requerimientos y distribuir sólo directivas técnicas ("armar una base de datos así y asá") en vez de directivas funcionales ("hay que hacer un módulo de ventas").

  Pueden seguir la entrada referenciada para ver los problemas que (en mi opinión) ello ocasiona. Por otro lado, el gestor de carrera transmite sólo requerimientos funcionales ya que no conoce de soluciones técnicas.

• Evaluar técnicamente al equipo de acuerdo a parámetros propios. Estos parámetros pueden estar obsoletos o no ser objetivos.

  Es el caso del líder de proyecto "del ciclo de vida" que evalúa "cantidad de líneas de código escritas".

  El gestor de carrera no cuenta con criterios propios para evaluar técnicamente al equipo por lo que deberá buscar parámetros objetivos: una opinión externa, una auditoría de código o similar.

  Buen momento para recalcar nuevamente lo de la chapucería: el gestor de carrera también puede confiar ciegamente en las capacidades técnicas de su equipo, o no preocuparse por ellas y evaluar sólo los resultados... hasta que todo colapsa como una cáscara vacía.

• Desestimar nuevas herramientas, nuevos lenguajes, nuevas tecnologías. Tal vez por rechazo a perder del todo el control: si se adoptan nuevas tecnologías su conocimiento previo ya no se aplicaría al proyecto, por lo que perderá cierto grado de poder de decisión.

  Un gestor de carrera no tiene pretensiones de control técnico del proyecto. Sólo le interesará el rumbo funcional o de negocio, que es lo que cae bajo su responsabilidad.

• Desestimar herramientas metodológicas o mejores prácticas de la gestión de proyectos, por considerarlas demasiado formales o informales, demasiado simples o complicadas, o simplemente inútiles.

  Una suerte de desprecio por la teoría del campo de la gestión de proyectos (que no es el propio), sobrevalorando las cuestiones técnicas frente a las administrativas.

  Al revés también se da: muchos gestores de carrera desprecian las tareas de codificación. Pero lejos de dañar al proyecto esto lo beneficia: cada uno a su trabajo.

Verán que todos los puntos tienen una raíz en común. En el fondo está mi propia visión del líder de proyecto: un profesional entre profesionales, un profesional de la gestión.

Una cuestión cultural, una estructura (tal vez en decadencia pero de todas maneras) muy extendida, ubica al líder de proyecto "por encima" de otros profesionales: programadores, técnicos en hardware, administradores de base de datos, etc.

Eso hace que a veces se olvide que el trabajo del líder es obtener y administrar a las personas y a los recursos, coordinar el trabajo en equipo y llevar las riendas de las negociaciones y gestiones necesarias entre el equipo y el exterior... (entre otros, claro).

El tema es, ningún profesional debería decidir en el campo del otro. Pensemos en estas situaciones: programadores decidiendo funcionalidades, líderes de proyecto imponiendo fechas en las que "tiene que estar todo", clientes requiriendo (caprichosamente) determinada tecnología, programadores haciendo testing, analistas funcionales diseñando reportes en SQL.

Son todas situaciones en las que un actor de esta comedia a la que llamamos "desarrollo" invade el terreno del otro. Es allí donde se originan los problemas.

Recordemos que el tema de este post fue: las tendencias, los sesgos que debe afrontar un técnico que deviene en líder de proyecto. No creo que ningún pasado X impida ser buen líder o que el mejor líder es aquel que estudió la teoría en una facultad. Otra vez: ambos caminos pueden conducir tanto a la chapucería como a la excelencia.