Gestión de Proyectos

Muchas veces en la literatura para desarrollo de software se ha hecho la analogía acerca de una construcción de una casa con la construcción de un software. En esta analogía normalmente, los distintos planos de la casa son los distintos modelos de diseño empleados para la construcción del software.

Meses atrás empecé a escribir un artículo sobre cómo creo que será la Administración de proyectos en la era del Big Data. Antes de compartir mis comentarios, quiero revisar el concepto general.

Jhon Weathington (2012) propone la siguiente definición: grandes cantidades de datos que fluyen con rapidez.

Ante la necesidad de un consenso acerca de los elementos que definen la calidad del software, ISO desde hace tiempo creo estándares en este sentido. El primero es el ISO 9126, originalmente publicado en 1991 y posteriormente revisado en 2001. Posteriormente desarrolló el estándar ISO/IEC 25010: SQuaRE (Software Product Quality Requirements and Evaluation), que fue publicado en 2011 y viene a ser el reemplazo de ISO 9126.

Tradicionalmente, los equipos de desarrollo de software tienen una estructura jerárquica, con la fuerte presencia del jefe de proyecto y alto énfasis en la asignación de roles y especializaciones a personas, que solo se dedican a efectuar el trabajo de su rol o especialización. Este tipo de estructura restringe la interacción entre los miembros del equipo.

Para planear el desarrollo de un software es necesario estimar de una u otra forma su tamaño y por supuesto su costo. Existen diversas mecanismos para estimar el tamaño de un software y el esfuerzo requerido para construirlo, en las páginas de SG anteriormente se han publicado artículos sobre métodos como la estimación por puntos de función, así como el recurrir a información histórica de proyectos anteriores.

Esta es la historia de un líder de proyecto llamado Jekyll, el cual alegremente —al menos al comienzo—  lideraba un nuevo proyecto de desarrollo de software como tantos otros que existen, han existido y existirán.

En la edición anterior describimos y mostramos un ejemplo en el cual una mala estimación puede ocasionar desde problemas de negociación hasta problemas económicos por tener que absorber costos no planeados. Esta situación es bastante común en la industria. De hecho, de 49 organizaciones que yo he entrevistado, tanto consultoras de software como corporativos e instituciones públicas, solamente 3 (6%) me han manifestado la ausencia de problemas en el tema relativo a las estimaciones.

La disciplina de dirección de proyectos es compleja. Involucra nueve áreas de conocimiento que conforman cinco grupos de procesos. El gerente de proyecto tiene que entender los principios y dinámicas que se dan al trabajar en grupo, el ciclo de vida de las expectativas y cómo administrarlo adecuadamente; además de entender los aspectos técnicos del proyecto y del negocio, también debe tener excelentes habilidades interpersonales, particularmente la de ser un buen comunicador.

La versión original de este articulo fue publicada en la edición de enero 2009 del Cutter IT Journal. La versión que presentamos aquí fue traducida y editada por SG, y publicada con el permiso de Cutter Consortium México.