jueves, 26 de enero de 2012

Problemas informáticos y el #PMBOK -#softwareengineering #software #project

Es frecuente que la literatura señale muchos y variados problemas que aparecen en los proyectos informáticos. Enfrentarlos, asumirlos, gestionarlos o simplemente afrontarlos requiere esfuerzos de diverso tipo. En este post se clasifican problemas informáticos reportados por varios autores según las áreas de conocimiento y las fases de la gestión de proyectos que presenta el PMBOK. Esta clasificación que propuse el año 2002 ha servido como base para resolver diversos problemas informáticos y aún es válida luego de 10 años.

A continuación se presenta la tabla que relaciona problemas con áreas y fases. La idea es que sabiendo el problema, se le puede hacer frente con las herramientas de gestión de proyectos que el mismo PMBOK señala para una fase y un área en cuestión.


Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Christian A. Estay-Niculcar (c)

Textos usados como fuentes de problemas:

  • MCCONNELL, STEVE. (1997). Desarrollo y gestión de proyectos informáticos. España: McGraw-Hill. 691 pp.
  • GLASS, ROBERT L. (1998). Software Runaways. Lessons Learned from Massive Software Project Failures. Prentice Hall. 259 pp.
  • GLASS, ROBERT L. (1999). Computing calamities. Lessons learned from product, projects, and companies that failed. Prentice Hall. 302 pp.
  • PURBA, SANJIV; SAWH, DAVID; y SHAH, BHARAT. (1995). How to Manage a Successful Software Project. Methodologies, Techniques, Tools. John Wiley & Sons. 370 pp.
  • REDMILL, FELIX. (1997). Software Projects. Evolutionary vs. Big Bang Delivery. Wiley. 254 pp.










Una nota sobre los #proyectos y su constitución comunicativa -#projectdesign #projectmanagement


Este post es una forma de organizar lo mucho que se debe saber de un proyecto y sus comunicaciones, que al fin de cuentas es lo normal en toda organización de actividad humana. 

Para comprender un proyecto lo primero que hay que tener presente es que evoluciona según las necesidades de adaptación que le impone el medio. Esto lleva al proyecto a buscar continuamente nuevas estructuras organizacionales que le permitan subsistir a las diversas fases de desarrollo y a los cambios del medio, además de buscar continuamente nuevos estados de sinergía que le permitan aprovechar al máximo los recursos con que cuenta.

Con esto, las diversas fases de desarrollo (o construcción), a la par de las diversas fases o etapas de gestión (iniciación, planificación, control, ejecución, cierre), incluyen actores diversos que aparecen o desaparecen en las diversas tareas y actividades consideradas a discreción y por conveniencia al proyecto, en roles de protagonista o como un actor secundario. Según los grados de participación, los actores se posicionan dentro de la estructura organizacional del proyecto que sea conveniente al momento, y se relacionan entre ellos según la configuración de equipo de trabajo que se considere pertinente.

Actores de un proyecto
Reconocer a priori cuál será la organización del proyecto por cada fase no es sencilla. Solamente se puede tener conciencia y relativa certeza que en ciertas fases determinados actores son necesarios con un determinado grado de participación o actividad. Según nuestras previsiones de las tareas que cada actor cumplirá, y considerando que a lo largo del proyecto nuevos y más actores intervendrán, resulta que la complejidad del proyecto evoluciona.

Evolución longitudinal de la estructura organizacional del proyecto
Esta situación solamente refleja la estructura organizacional del proyecto. Pero, conforme un proyecto es un transitorio, una instancia temporal y situada del esfuerzo humano por conseguir un resultado concreto a la solución de un conflicto social y/u organizacional, los actores partícipes del proyecto en ocasiones son parte intrínseca del proyecto, o sea, contratados a tiempo y dedicación total y absoluta al proyecto, mientras otros, y comúnmente ocurre así, provienen de otras organizaciones.

Integración transversal de organizaciones e individuos en la estructura organizacional del proyecto
Mientras la evolución longitudinal obliga a tratar con la complejidad del cambio continuo, la integración transversal obliga a resolver el problema continuo de mantener la cohesión del proyecto especialmente cuando hay actores que pueden mantener compromisos con las organizaciones de donde provienen. Esta situación obliga a precisar entonces que un proyecto es una sucesión de encuentros de personas a lo largo del tiempo, encuentros que son ni más ni menos que reuniones de trabajo donde los actores, sea cara-a-cara o a distancia, exponen sus avances, resuelven problemas y comparten experiencias.

El proyecto como un esfuerzo comunicativo
Con esto, se intenta dejar en claro que el proyecto finalmente es un esfuerzo de comunicación cuyo fin es la cohesión e integridad estructural del grupo constitutivo del proyecto. Y, con esto, se tiene en claro que el principal problema del jefe o director de proyecto es crear, sostener y apoyar los lazos de comunicación y, por supuesto, darle una prioridad pues un mensaje perdido puede tener consecuencias imprevistas, desconocidas, e impensables y, en cualquier caso y lo más importante, siempre afectará a una persona.



___________________
Fuentes:
  • Torrealba, Alvaro. (2000). La organización del proyecto. En Cuadernos de Ingeniería de Proyectos III: Dirección, Gestión y Organización de Proyectos. Universidad Politécnica de Valencia. Valencia-España: UPV. 238 pp.
  • Estay, Christian; y, Blasco, Jaume. (2000). El universo de proyectos: una epistemología sistémica para proyectos. En V International Congress of Project Engineering. LLeida, España. 4-6 Octubre.
  • Blasco, Jaume; Cisteró, Manuel-Jordi; Cremades, Lazaro V.; Estay, Christian A.; García, Águeda; Gracia, Santos; y, Masarnau, Joan. (2001). Experiencia docente presencial-no presencial colaborativa en la formación de Proyectos. En III Jornadas Multimedia Educatiu. Barcelona, España. 25-26 Junio.


miércoles, 25 de enero de 2012

Una nota sobre el Incapability #Maturity Model -#maturitymodel #pmbok #software

Fuente: Photo by Lynn Jordan on Unsplash

Esto lo encontré a inicios de los 90s del siglo Pasado. No apto para puristas ni sensibles.

Indagando sobre cómo mejorar la producción de Software, encontré un trabajo de Anthony Finkelstein denominado Capability Inmaturity Model. 

Fue, aparte de relajante y realista, un llamado de atención, pues mostraba que mucho se hablaba en esa época de que había que certificarse con el Capability Maturity Model, pero nadie se preocupaba de cuan lejos se estaba de un primer nivel 0. 

 Con mucho sentido del humor, y bastante conocimiento de causa, Anthony Finkelstein indicaba que hay organizaciones que no han alcanzado siquiera el nivel 1 de CMM (en el qué, aunque sea de modo heroico, se comienza a producir software). 

Por esta razón, Finkelstein proponía que existen niveles negativos o de inmadurez. 

Este «Modelo de Incapacidad e Inmadurez», que fue refinado posteriormente por Tom Schorsch, incluye tres niveles de lo que se llamaría idiotez de la producción de software. 

Finkelstein, proponía/propone: 

0 Tonto. Organizaciones negligentes. Impiden cualquier desarrollo de software con éxito. Su gran preocupación es la reutilización del software. 

-1 Estúpido. Organizaciones obstructivas. Imponen procesos contra-productivos para impedir cualquier avance. Se concentran en desarrollar entornos de desarrollo y repositorios. 

-2 Lunático. Organizaciones desdeñosas. Desprecian cualquier institucionalización de buenas prácticas. Su gran objetivo es la programación automática. 

 El trabajo Torsch añade más niveles y proponía/propone: 

0 negligente o de indiferencia. El mismo que Finkelstein. 

-1 Obstructivo o contraproductivo. El mismo que Finkelstein. 

-2 Despectivo o de arrogancia. El mismo que Finkelstein. 

-3 Campo minado o de sabotaje. Organizaciones que viven con situaciones de riesgo, en lugar de dar soluciones plantean acciones que en el fondo son minas para la organización. 

-4 Sicótico. Organizaciones alejadas de la realidad, la única realidad es la suya. 

-5 Sociopático. Organizaciones que no están en contacto con el entorno social e industrial.  
-6 Ritual del sacrificio humano. Todo vale para salir adelante. 

-7 Equipo-programador-Jefe. Todo centralizado en el jefe, quien dirige, coordina y 'dictatoriza'.

Habría que pensar cuánto de estos modelos son validos hoy en día. 

Mirando los niveles, algunas cosas son muy visibles en los equipos de desarrollo y en las organizaciones de software aún hoy en día. 

O algo más arriesgado, cuánto se oculta en metodologías recientes como eXtremme Programming, o métodos Ágiles que conforme permite formalizar un desarrollo de software, no es menos cierto que incluye elementos centralizadores -por ejemplo-. 

Si alguien desea saber algo más, simplemente coloque en un buscador "Capability Inmaturity Model".

martes, 24 de enero de 2012

#Gestión del #proyecto: problema, finalidad y salida … en imágenes … -#projectmanagement

Resumen de algunas ideas clave sobre la gestión del proyecto

______________________________________________________________________________
El problema de la gestión de proyectos: la realidad supera la gestión ... el desarrollo supera la planificación ... la gestión de proyectos olvida sus principios fundamentales ... 


 ______________________________________________________________________________
El fin de la gestión de proyectos: orquestar especialistas sin que pierdan su creatividad individual ... la gestión de proyectos de manera tácita orquesta recursos pero olvida que algunos de esos recursos son personas singulares inclasificables ... 
 ______________________________________________________________________________
La gestión demanda liderazgo: algo a practicar ... la gestión de proyectos recurre mucho a la evidencia pueril de que siempre hay emergencias y urgencias lo cual convierte al jefe de un proyecto  en un "apaga incendios" y no le deja espacio para liderar y como siempre ocurre, en condiciones muy poco estables y seguras ...
post relacionados "El liderazgo, organización y supervivencia" -Agosto 26, 2010- y "El liderazgo en condiciones riesgosas ..." -Diciembre 13, 2010-.


Blog ganador Premio Novagob Excelencia 2017