Errores clásicos en la gestión de desarrolladores

Muchos de los profesionales que nos dedicamos a los “Recursos” Humanos intentamos demostrar que nuestro trabajo es clave en cualquier organización, no creemos que deba limitarse a dar servicios sino que proyectamos mucho más allá. Nuestro valor es la búsqueda, la selección y la gestión del talento, una pieza estratégica en este complicado puzzle de las organizaciones.

Si trasladamos esta reflexión al sector de las empresas de tecnología, nuestra labor se complica un poco más. Los técnicos creen que no entendemos su trabajo, los directivos creen que nuestro trabajo lo puede desempeñar “cualquiera”, y el resto de población cree que trabajamos con profesionales aislados del mundo con ese ordenador mágico que se lo hace todo. Evidentemente estoy exagerando, pero no me distancio mucho de la realidad 😕

Una de las mayores dificultades desde que llevo trabajando en el sector de la tecnología es la incompetencia en la gestión del talento. Steve McConnell (una de las tres personas más influyentes en la industria del software, junto con Bill Gates y Linus Torvalds, según los lectores de la revista Software Development) demostró que en cualquier proyecto de software suelen producirse 36 errores, de los cuales 13 están directamente relacionados con la gestión de personas, otros 13 con los procesos, 5 con el producto y 4 con la tecnología. Prácticas de desarrollo de software que son llamados por McConnell Errores Clásicos” porque se repiten con frecuencia, provocando resultados predecibles y que se siguen repitiendo desde la publicación de su obra Rapid Development: Taming Wild Software Schedules,  ¡sorprendentemente desde hace casi 20 años!, pero más increíble es saber que de los 36 errores, 32 tienes que ver en mayor o en menor medida con gestión y un 36% están directamente relacionados con la mala gestión de personas.

Tirá cómica realizada por Autentia

¿Qué hacemos si no llegamos a la fecha de entrega de un proyecto? ¿incorporamos a más desarrolladores?¿reclutamos a todos los desarrolladores habidos y por haber (inclusive sin experiencia en las tecnologías del proyecto)? ¿obligamos a hacer horas extras? ¿premiamos por llegar a la fecha de entrega como un gran acto heroico? , ¿Y si además, tienes un equipo desmotivado y a más de un profesional generando problemas? ¿sacamos inmediatamente a aquellos que estén perjudicando el clima y la productividad del equipo? ¿esperamos a que termine el proyecto? Seguro que a todos nos resultan muy familiares cada una de las cuestiones. 😳

Siempre nos han dicho que de errores se aprende pero cuando hablamos de gestión de personas, podemos estar cometiendo los mismos errores una y otra vez sin aprender de ellos. El autor de Code Complete, Software Estimation y la obra de la que estamos hablando Rapid Development, nos deja claro que en cualquier proyecto de software, se producen siempre los mismos errores:

  1. No dar importancia a la motivación
  2. Contratar profesionales no cualificados y sin nivel técnico necesario
  3. La incapacidad de gestionar profesionales conflictivos
  4. Privilegiar el “Heroismo” en lugar del buen desempeño continuo
  5. Incorporar más desarrolladores a un proyecto retrasado
  6. Trabajar en oficinas ruidosas, con muchas personas que impiden la concentración y el trabajo en equipo
  7. Fricciones entre desarrolladores y clientes
  8. El mal manejo de las expectativas, llegando a compromisos no realistas
  9. Falta de liderazgo efectivo en el proyecto
  10. Carecer de apoyo de interesados (stakeholders)
  11. No involucrar a los usuarios finales
  12. Dar más importancia a la burocracia que a los resultados
  13. Exceso de optimismo

Algunas de las soluciones para prevenir muchos de estos errores clásicos se han solucionado gracias a las metodologías ágiles, coaching de equipos y otras metodologías y procedimientos no etiquetados ni tan oídos basados en una psicología del sentido común, pero creo que todos coincidimos en que no hay nada más complicado que las personas.

¿Habéis conseguido en vuestros proyectos aprender y no volver a repetir esos errores ? 🙄