|
Necesitaré 3 recursos Java |
|
|
|
14.08.2005 |
A lo peor estoy equivocado, pero no me encaja que un gestor de proyectos tome una lista de requisitos, la desconponga en un WBS, genere un gráfico de Gantt y tras analizarlo le diga al responsable de personal: "necesitaré 3 recursos java".
Primero, un aspecto de forma: ¿Por qué "recursos"?. ¿Por qué no tratar a las personas como personas?. Programadores, analistas, ingenieros... Si, es posible que sea un poco maniático, pero es que no comprendo esta suerte de eufemismo. Puedo entender que para evitar posibles connotaciones peyorativas se hable de invidente y no de ciego; pero que se emplee un tropo similar para no llamar a una persona persona, y preferir "recurso" ¿?.
Segundo, ¿se puede tratar un proyecto de software, como el de contrucción de un edificio?.
Una excavadora extrae x m3 de tierra en cada jornada de trabajo, las estadísticas de días de lluvia y de averías de maquinaria son también datos objetivos para una previsión de riesgos. Pero, ¿los modelos formales de gestión de proyectos resultarían válidos si la producción de las excavadoras no fuera homogénea, y entre ellas hubiera diferencias de "por 10", o mas?. O si la motivación de los palistas, perdón de los "recursos", fuera un factor de primera relevancia en la eficiencia y la calidad del resultado?.
Hay una gestión de proyectos de corte mecanicista, que mira los proyectos con las gafas de ver tareas, actividades, tiempos que consumen, recursos necesarios, Gantt, ruta crítica, riesgos, presupuesto, ROI, etc. Es la escuela "formal" que se basa en la premisa de que el conocimiento y las prácticas de gestión para los proyectos son comunes para todas las industrias: farmacéutica, construcción, software... (premisa fundacional de PMI. PMBOK, edición 2000, pág. 167.)
Pero también hay modelos ágiles para la gestión de proyectos que no emplean diagramas de Gantt, o en las que el gestor no asume las responsabilidades de gestión y organización de los "recursos", porque los cambian por equipos de personas auto-gestionados y auto-organizados.
¿Es posible un modelo único de gestión de proyectos?. ¿Una talla única para todo?
|
En las metodologías ágiles, nos centramos más en las personas, y se debe tener en cuenta que no hay dos iguales. Sin duda las herramientas "formales" tienen su lugar, pero por detrás de las personas.
Un diagrama de Gantt puede dar una idea muy buena de las iteraciones que se esperan suceder de entregas al cliente, aunque las fechas no sean sino orientativas, una gestión de riesgos seguirá siendo necesaria, puesto que las metodologías ágiles, obviamente, no eliminan los riesgos de los proyectos, y por supuesto, sin presupuestos no hay ningún proyecto.
Pero es la filosofía la que debe cambiar, que las maneras de trabajar entre personas distintas son diferentes, y no se pueden homogeneizar. Eso es con lo que intentan trabajar las metodologías ágiles.
Joserra
Najaraba