La forma en que se desarrolla software en la segunda década del siglo XXI es diferente a como se hacía cuando nació la industria de software. Esto debido a que la base de usuarios creció y las características de ellos son muy distintas a los usuarios iniciales; por tanto, sus demandas y necesidades requieren una atención adecuada a este entorno de entendimiento cambiante.

Es por esto que han surgido prácticas y propuestas para organizar equipos e individuos que hacen software, que están enfocadas en manejar esos cambios: ciclos de desarrollo más cortos, adaptación al cambio, comunicación e interacción constantes y una desaparición, por así decirlo, de un gestor que toma las decisiones importantes. Se dice que el enfoque “tradicional” de gestión de proyectos es inapropiado para las prácticas actuales.

La “administración tradicional” de proyectos

El enfoque que llaman “tradicional” se caracteriza por buscar el control y la predicción del trabajo: se hacen planes detallados para la totalidad del proyecto, aun con duraciones de años, y se pretende seguir rigurosamente ese plan para cumplir con los objetivos y evitar las desviaciones. Generalmente existe la figura del Project Manager, quien mantiene y controla el avance en el proyecto, y los trabajadores pocas o nulas veces se ven involucrados en la definición o corrección de ese plan.

Se ve como una estructura rígida, en la que el objetivo es seguir el plan en vez de buscar la satisfacción del cliente, y usualmente se asocia con la entrega de un producto inadecuado para las necesidades del usuario, que cambiaron significativamente desde que se elaboró el plan la primera vez.

El enfoque “nuevo” para administrar proyectos de software

Algunos dicen que el “enfoque tradicional” no funciona para la ingeniería de software porque el trabajo es distinto al que se hace con las manos o en líneas de producción. En una línea de productos se puede predecir y pronosticar con claridad porque el trabajo y las necesidades están bien comprendidas, algo que rara vez pasa en software.

Además, el desarrollo de software entra en la categoría de “trabajo intelectual”, donde los resultados se obtienen a través del esfuerzo mental en lugar del trabajo manual, y es muy difícil gestionar ideas, particularmente si dejamos que solo una persona lo haga.

La filosofía ágil, que se ha adoptado como el estándar actual en desarrollo de software, se enfoca en generar valor para el negocio y adaptarse al cambio: aprendizaje rápido y una respuesta al entorno cambiante también rápida. Los planes largos y detallados son imposibles porque no se puede predecir el futuro, y el equipo debe estar concentrado en entregar valor en ciclos cortos, no en seguir un plan.

Adiós a los diagramas Gantt, las listas de tareas, los reportes con gráficas del avance frecuentes y otras prácticas llamadas burocráticas. En ocasiones, también significa un “adiós” al Project Manager.

Y en otras ocasiones, también significa lanzar la gestión del proyecto por la ventana.

Ahora, cada ingeniero debe saber administrar proyectos

Detrás de la filosofía ágil y de otros marcos de trabajo para software existe un principio fundamental para que las cosas funcionen:

El equipo debe ser capaz de autoadministrarse

Tom Demarco los llama “jelled teams“, y son equipos que se caracterizan porque todos son partícipes y dueños de las decisiones, y suelen ser altamente efectivos porque cada integrante se hace responsable de su trabajo y sus compromisos.

Esto implica que cada uno es capaz de administrar correctamente un proyecto, que tiene el tamaño de una persona, es decir:

• Puede estimar el esfuerzo que requiere hacer el trabajo, para saber a qué se puede comprometer.
• Lleva un seguimiento de su trabajo, para identificar causas concretas de problemas y buenos resultados.
• Toma decisiones y acciones correctivas con base en mediciones y análisis comparativos entre sus expectativas y resultados.
• Comunica su estatus continuamente y sabe cuándo levantar alertas oportunamente para evitar problemas

La razón por la cual un equipo no requiere un Project Manager es porque cada ingeniero es su propio Project Manager.

Gestionar proyectos es seguir principios, no llenar documentos

La idea de administración de proyectos se puede asociar con la idea de métodos, procesos y artefactos rígidos: Aplicar algo dogmáticamente (como el PMBOK) al pie de la letra, pero es algo muy distinto.

Gestionar el proyecto significa guiar el proyecto hacia conseguir los objetivos y optimizar los recursos, no llenar documentos y ser el policía del cumplimiento del plan.

Administración de proyectos, antes que un método, es un conjunto de principios. Es muy importante que un Ingeniero de Software actual los conozca y sea capaz de aplicarlos, pues en la práctica actual es imposible que solo una persona lo haga, y si el ingeniero mismo no administra su trabajo, entonces nadie estará haciéndolo.