General

Problem: gestión de proyectos basada en lentes

Una de las partes más importantes de mi actividad profesional en la actualidad es la gestión de varios proyectos tecnológicos de forma paralela con muchos clientes dentro y fuera del país.Hasta principios del 2008 en mi radar sólo habían dos formas posibles de gerenciar o participar en un proyecto: la forma tradicional (planificación, diseño, implementación, control, et al.) y la desorganizada, basada en excusas. Sí, esa que es tan común en organizaciones burocráticas públicas o privadas e incluso en varios proyectos comunitarios nacionales e inteacionales.No voy a mentir, las excusas siguen allí (no hay dinero, no hay gente, no hay tiempo) pero he trabajado en un enfoque holístico que me permite obtener los resultados deseados en plazos de tiempo razonables y flexibles y sin comprometer el resto de los recursos. Es esencialmente iterativo y, lo más importante, me permite paralelizar los recursos siendo lo más transparente posible con todos los actores del proyecto, incluyendo al cliente. A la fecha, sólo lo he aplicado a proyectos tecnológicos que han involucrado integración de tecnologías libres y de estándares abiertos.¿Qué es Problem?La gestión de proyectos basada en lentes (Problem) es un modelo de gestión de proyectos orientado a objetivos que permite paralelizar el uso de los recursos humanos y tecnológicos a la vez que presenta una vista transparente del mismo ante todos los actores exteos.Lentes FTWEl concepto fundamental de este modelo es el de lente, una vista que la gerencia del proyecto le da al problema en un momento predeterminado. Para que el proyecto se cierre se deben haber cumplido un conjunto de objetivos, y la ejecución del proyecto es el resultado de verlo con distintos lentes. Algunas vistas pueden tener prelaciones y, por supuesto, cada organización puede mantener una lista de lentes.Por ejemplo, yo suelo manejar estos lentes:

  • Preventa, suele tratarse de un esfuerzo integral, no medible, a veces sin plazos fijos y cuyo objetivo específico es lograr que el resto del proyecto ocurra.
  • Planificación, que incluye la planificación de recursos, la presentación del proyecto al cliente, la configuración de los ambientes de trabajo y aspectos operativos como sitio de trabajo, puntos focales, mecanismos de comunicación con el cliente, et al. Mientras menos gente se involucre, mejor.
  • Arquitectura, un lente abstracto cuya mejor definición la encontré en Brooks, 1995. También es tarea para una sola persona.
  • Desarrollo, la parte sucia del asunto, que puede tener muchos lentes asociados dependiendo del objeto de cada proyecto. Aquí suelen participar varias personas, y la paralelización depende del detalle de los lentes.
  • Integración, una parte muy importante que depende de que se hayan definido los elementos de arquitectura y diseño y donde se le empieza a ver el queso a la paralelización con Problem
  • Ingeniería de detalles, al mejor estilo del worrier, usualmente innecesario durante el resto de las fases del proyecto a diferencia de la metodología tradicional y por lo tanto ¡mucho menos costoso!
  • Soporte, lente altamente paralelizable que se encarga de aplacar los demonios de la interacción con el consumidor final.
  • Closure, en el que se presentan las actividades y su relación con el cumplimiento de los objetivos, se cierra el proyecto y a posteriori se hacen tareas inteas como difusión de conocimiento o documentación.

Closure lensesEl ojo avizor notará que tomé algunas características iterativas de SCRUM y compañía, aunque en la práctica mi experiencia con SCRUM no ha permitido la paralelización de recursos. La metodología es compatible con una vista tradicional en la que se hace pueden definir logros y tiempos a-la-PERT, pero esto suele requerir un esfuerzo adicional y sólo lo he hecho cuando el cliente lo solicita explícitamente.La metodología es muy ligera y flexible, en ningún momento busca ser vinculante o imponer restricciones. Lo que busca es ponerle término al proyecto. Es por ello que he utilizado la denominación orientado a objetivos ya que existen en el mercado buenas metodologías de gestión de proyectos que fallan en el caso general por estar orientadas a entregables tradicionales. A veces un proyecto tiene como objetivo transferir tecnología o diseminar conocimiento. El entregable es intangible en muchos de esos casos.Have fun.

Standard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s