archivo

Archivo de la etiqueta: conocimientos

Hay muchos gestores de proyectos que asignan tareas (cuando no proyectos completos) a personas que en esos momentos no reúnen la capacitación necesaria para llevarlas a cabo. A veces esas personas se sobreponen a la adversidad y son capaces de sacar dignamente el trabajo adelante, pero por regla general no será así.

Si un proyecto de desarrollo de software tiene incertidumbre de manera inherente, estamos añadiendo todavía más riesgos al mismo ya que estamos asignado tareas y responsabilidades a personas que a día de hoy no tienen los conocimientos y experiencia necesarios para enfrentarse a ellas.

Esto ha hecho mucho daño al desarrollo de software presentando a personas como “el experto en…” (sin serlo) y después abandonándolas a su suerte en el proyecto.

Lo peor de todo es que cuando los gestores hacen esa asignación son conscientes de lo que están haciendo y de las consecuencias que eso traerá consigo. Al final echarán las culpas a los técnicos cuando el principal culpable es, sin dudas, el gestor. Quiero aclarar que a veces el gestor también será una víctima, cuando se le encarga un proyecto en el que no se le da margen de maniobra en la elección del personal.

El problema parte de la base de ignorar que se trabaja con personas, no con robots (o ganado), y que cada una de ellas tiene su singularidad y unas circunstancias que hacen que su rendimiento sea más efectivo en unas tareas que en otras, teniendo en cuenta, además, que van evolucionando de manera que con el paso del tiempo pueden realizar tareas más complejas o de más responsabilidad, haberse especializado en áreas concretas, etc…

También es necesario tener en cuenta cómo funciona esa persona en equipo y en qué tipos de equipos pueden rendir mejor.

Obtener el mayor rendimiento de cada persona implica conocerla bien y eso requiere trabajar con ella de cerca durante el tiempo suficiente, eso requiere que el gestor de proyectos se implique y no vea los trabajos desde la distancia (cosa que ocurre demasiado a menudo, en unos casos por tener una cartera de proyectos importante y en otros casos porque es más cómodo estar fuera de la línea de fuego).

El desarrollo de software no es solo son procesos, metodologías, arquitecturas, programación, etc… hay algo más, mucho más importante que es la relación entre las personas que intervienen en el proyecto.

Si falla esa relación, esa comunicación entre las personas, esa búsqueda de un objetivo común, esa necesidad de trabajar juntos para alcanzarlo difícilmente va a funcionar todo lo demás por muy bien que se trabaje.

También está el bagaje profesional y personal, ese background que te ayuda a intentar tomar las mejores decisiones (aunque no siempre se acierte) incluso en contextos complicados y/o que no son conocidos por nosotros.

Si se trabaja como un equipo se tendrá la capacidad de integrar el background de todos, si no es así no es ya que no se aproveche ese talento y esa experiencia sino que esas diferentes visiones tenderán a convertirse en fuerzas que empujan en distinto sentido y provoca situaciones de bloqueo en el proyecto, desgaste, etc…

Ken Schwaber considera que no todo son procesos y metodologías, sino que hay algo más: “Una metodología te dice lo que tienes que hacer, un proceso es un framework que establece algunas restricciones. Una metodología no puede decirle a la gente que hacer cuando nunca han estado allí”. Es decir, tras la metodología quedan los desarrolladores (las metodologías son generalizaciones y no pueden tener en cuenta cada situación concreta de un proyecto) que son los que al final tienen que tomar las decisiones.