Whitten, N. (1990). Revisin post-proyecto: entendimiento del pasado para mejorar el futuro.

En Managing software
development projects : formula for success (pp.241 - 257) (Trad. Universidad ESAN) . New Jersey : Wiley. (C20708)

ESCUELA DE ADMINISTRACION DE NEGOCIOS PARA GRADUADOS

ESAN

12
Revisin Post-Proyecto:
Entendimiento del Pasado para
Mejorar el Futuro
El optimismo es eterno. Siempre tenemos la esperanza que el siguiente proyecto
de software funcionar con mucho menos problemas que el ltimo. Sabemos que no
somos tan tontos como para volver a cometer los mismo errores. Pero la historia nos
muestra que cometemos muchos de los mismos errores que cometimos la ltima vez
y la vez anterior a esa y la anterior a esa. Haremos esto sabiendo muy bien que los
errores cuestan dinero, tiempo y recursos. Estos errores podran causar la cancelacin
de un proyecto e inclusive nuestros trabajos. Sin embargo, la mayora de los proyectos
continuamente repiten muchos de los mismos problemas.

La historia se repite en la guerra, la economa, el amor y los proyectos de

desarrollo de software. Esta repeticin de la historia no es debido a la falta de
informacin registrada o buenas intenciones. Es la falta de equilibrio en el
entendimiento lo que estuvo mal en los proyectos anteriores, aplicando la experiencia
en campaas pasadas y exhibiendo la disciplina para aplicar este conocimiento y
experiencia. Este captulo le puede mostrar cmo aprender de sus errores anteriores.
Tambin demuestra cmo aplicar este nuevo conocimiento en su proyecto actual o
en el siguiente.

No se desanime! Volvamos a la carga!

Conforme las lecciones de errores pasados son ignoradas y el proyecto contina

cayendo a diario ms profundamente en un atolladero, se puede escuchar seales de
alerta. Estas seales vienen de la falta de un avance claro dentro del proyecto y de
los mismos participantes del proyecto. La siguiente coleccin de pequeos ejemplos
revela problemas de muestra que son histricamente comunes en los proyectos de
desarrollo de software. Aunque costosos para el bienestar de un proyecto, estos

Tomado de: MANAGING SOFTWARE DEVELOPMENT PROJECTS. Formula for Success. Por Neal
WIDTIEN; ed. John Wiley & Sons, lnc., USA., 1990
 242 Managing Software Development Projects

problemas representativos estn entre una multitud que tienen inclinacin por
repetirse.

El proyecto es joven, pero ya estn saliendo a flote las frustraciones de un nuevo frente

1
de batalla. El conductor de un equipo responsable de un pequeo grupo de
programacin percibe un sentimiento de impotencia y abandono. Cuando l
comprometi a su equipo para el desarrollo de 10,000 lneas-de-programa de cdigo,
l tambin estableci entre los requerimientos que el equipo debera contar con siete
programadores con habilidades especficas. l tambin expres el requerimiento que
el equipo estuviera con el personal completo dentro de los dos meses posteriores a su
compromiso. Cuatro meses despus, su equipo tiene cuatro miembros semi capacitados
y su producto tiene un atraso de seis semanas. l tema que esto sucediera, pero se
dej llevar por su optimismo y a las buenas intenciones del jefe del proyecto. La parte
realmente preocupante es que el jefe del proyecto todava lo hace responsable a l y a
su equipo por su compromiso original. Dado que al equipo le falta personal, el jefe del
proyecto ha dedicado personalmente gran parte de los ltimos cuatro meses ha ayudar
al equipo en el diseo y la codificacin. De alguna manera, el jefe del proyecto no ha
captado el mensaje que su tiempo sera ms provechoso para el departamento si l
apoyara activamente las necesidades del equipo y el departamento en lugar de hacer
el trabajo de un miembro del equipo.

* * *

El proyecto est en medio de sus numerosas reuniones de inspeccin del diseo. Estas
reuniones tienen el fin de descubrir defectos tempranamente en lugar de durante las
fases de codificacin y prueba. Desafortunadamente, todas las reuniones de inspeccin
no se realizan de la misma manera. Algunos de los moderadores han tenido
capacitacin o entrenamiento previo, mientras que otros parecen ser completamente
nuevos en lo referente al proceso de inspeccin. Algunos moderadores estn
rechazando inspecciones que tienen un problema serio, mientras que otros moderadores
estn aprobando inspecciones con varios problemas serios. Algunos moderadores
documentan los resultados de sus reuniones y luego monitorean los problemas
pendientes para asegurarse que sean resueltos a tiempo, mientras que otros
moderadores no documentan ningn resultado de sus reuniones. Algunas inspecciones
tienen representados a todos los inspectores y organizaciones requeridas, mientras
que otras inspecciones tienen una asistencia deficiente y con frecuencia pasan por alto
el invitar a ciertos inspectores claves. Dos participantes que han asistido a varias
reuniones de inspeccin se miran uno al otro y concuerdan "Ya hemos visto esta
'pelcula' antes. Yo pensaba que 'John' deba arreglar esto despus del caos del ltimo
proyecto. Oh Bien, por lo menos nos pagan por toda esta tontera y por volver hacer el
trabajo". (Se les paga, s. Pero por cuanto tiempo ms?)

* *

Es un proyecto nuevo. La fase de diseo ha sido completada y la fase de codificacin

est empezando. Dentro de otros tres meses, se requerir hardware de laboratorio
para implementar las diversas fases de prueba. Nunca parece haber suficiente hardware
para que todos utilicen, inclusive cuando se emplea en turnos mltiples de semanas 6
o 7 das. Esta situacin existi en los tres proyectos anteriores. Sin embargo, debido a
la apremiante y aparente atencin en el ltimo proyecto, la perspectiva es que

242
 Revisin PostProyecto: Entendimiento del Pasado para Mejorar el Futuro 243

probablemente esto no sea mayor problema esta vez. Despus de todo, parece ser que

1
todos tenan una opinin sobre cmo corregir el problema, y pareca que hubiese sido
un problema fcil de arreglar si se hubiese realizado un poco de planeacin anticipada.

Han pasado tres meses. Varios grupos convergen en el hardware disponible casi
simultneamente. Es deja vu. No slo el problema no ha sido corregido, no hay nadie
que tome la responsabilidad de entender los requerimientos de todos y llegar a una
solucin mutuamente compatible. "No puedo creer que hayan dejado que pase esto
otra vez! Este lugar no es real! Nunca aprenderemos!", se escucha una vez ms.

* * *

La prueba formal finalmente est lista para empezar. El cdigo ha sido entregado al
grupo que elabora el mdulo y, despus de mucho trabajo, ha sido vinculado
exitosamente. Pero, qu pena! El programa no corre! Varios de los encargados del
desarrollo corren hacia los listados y las mquinas para tratar de localizar el problema.
Se sospecha que el problema est en una pieza del cdigo que fue entregada por un
vendedor. Despus de dos das de esfuerzo concentrado, se descubre que el problema
no estaba en el cdigo del vendedor, sino en un cdigo interno. El problema es corregido
y se realiza otro intento por correr el programa. No tiene xito. Esta vez, despus de
todo un da de buscar el defecto, el problema es aislado en los mdulos provistos por
un vendedor. Se escuchan quejas: "Por qu no est aqu la gente del vendedor para
buscar las deficiencias de su propio cdigo? Por qu no hay aqu gente que represente
a los principales departamento?" Parece ser que nadie ha desarrollado un plan integral
para apoyar en la prueba formal. Aunque los grupos de desarrollo han acordado
arreglar sus problemas, nadie ha acordado gastar el tiempo necesario buscando un
problema que se sospecha es un mdulo defectuoso. Qu pasa si el programador se
pasa todo el da aislando el problema y se concluye que es el cdigo de otra persona?
Nadie tiene el tiempo para hacer eso. Dicho con mayor exactitud, nadie ha planeado
tiempo para eso. Nadie ha planeado asignar tiempo o personal a desempear este rol
esencial. Alguien dice sarcsticamente, "Aprenderemos alguna vez? Esto mismo
pas la ltima vez! Uno pensara que un jefe del proyecto diferente sera ms inteligente
que el anterior.

* *

El proyecto est completo en dos tercios. Los miembros del grupo de prueba de
desempeo estn listos para entrar en accin. Ellos descubren inmediatamente
problemas de desempeo que, despus de un anlisis cuidadoso por parte del equipo
de desempeo, causarn un mes de retraso para corregirlos. El equipo de desempeo
est orgulloso por haber sido capaz de descubrir estos problemas tan rpidamente. El
grupo de desarrollo est furioso por que la gente de desempeo no descubri esos
problemas antes. "Por qu la gente de desempeo no participo en nuestras reuniones
de diseo e inspeccin de cdigo meses atrs?" Podran haber obtenido toda la
perspectiva necesaria para establecer que se iban a dar estos problemas de desempeo.
Hubiese sido mucho ms fcil y mucho menos costoso haber descubierto esos
problemas entonces", dice un frustrado miembro del equipo de desarrollo a otro
compaero.

243
244 Managing Software Developme11t Projects

1
La opinin lleg al departamento de desempeo, cuya respuesta es, "Hubisemos
descubierto estos problemas de desempeo antes, si el departamento de desarrollo
nos hubiese invitado a todas sus reuniones de inspeccin. Y, adems, por qu nosotros
siempre somos los ltimos en enterarnos si se cambia una funcin o diseo? Parece
ser que desarrollo nunca aprende!" En una oficina ms abajo en el pasillo se puede
escuchar, "Parece ser que esos tipos de desempeo nunca aprenden!".

* * *

El trabajo de publicaciones estaba considerablemente retrasado segn el cronograma.

El primer anteproyecto estaba tena un retraso de casi seis semanas. An entonces, la
magnitud y el tipo de los comentarios caus que varios captulos pasaran por una
revisin exhaustiva. El siguiente anteproyecto estaba retrasado en dos meses. El
principal problema era que las funciones del producto continuaban cambiando
drsticamente de un anteproyecto a otro. Agravando este problema estaba la limitada
disponibilidad de programadores para revisar los primeros captulos y brindar el
material fuente necesario para los escritores. Un escritor de publicaciones comenta,
"Los programadores nos hacen esto todo el tiempo! Algunas veces me pregunto cun
comprometidos estn con sacar un producto de calidad. Particularmente un producto
de calidad a tiempo".

* * *

El producto est casi terminado. Las publicaciones estn casi listas. De pronto, el
grupo de garanta de calidad se da cuenta que los manuales del producto tienen muy
pocos ejemplo. A no ser que se aadan ms ejemplo, est visto que el producto no va
a ser lo suficientemente fcil de usar para los usuarios de la audiencia objetivo. Alguien
sale con la idea que los ejemplos pueden ser tomados de los escenarios de prueba y los
casos-prueba del sistema. Alguien ms exclama,"Esa es una buena idea! Me gustara
que los hubisemos pensado antes". El iniciador de la idea responde, 11No es una idea
nueva. En los dos ltimos proyectos que he trabajado, tambin hubo una deficiencia
en los manuales".

* * *

Al departamento de empaque y distribucin del producto (P y D) se le solicita un

plan. Se necesita un plan que defina con precisin cmo y cundo el producto nuevo
estar listo para ser entregado al cliente. El producto actualmente est en las primeras
etapas de su desarrollo. Problemas de tipo legal y otros dentro del P y D demoraron el
ltimo anuncio y entrega. El jefe del producto espera evitar esas demoras en este
producto. La jefa de P y D i nsiste que esto no volver suceder. Ella
slo necesita seis
partir de hoy tenemos diez meses. Sin embargo, ella
meses de tiempo de trabajo, y a
tambin dice que su departamento est ocupado con otros problemas, pero que pronto
comenzarn a trabajar en la solicitud. El jefe del producto, sintiendo que su trabajo de
formalizar la solicitud ha concluido, contina con sus propias deberes. Cuatro meses
antes de la fecha programada para la entrega del producto, alguien se da cuenta que P
y D no ha sido incluido en las reuniones de revisin semanales. Una vez ms, las
actividades de P y D estn demorando el anuncio y la entrega. Alguien comenta
cansadamente, "Esto es exactamente lo que sucedi la ltima vez".

244
 Revisin Post-Proyecto: Entendimiento del Pasado para Mejorar el Futuro 245

Conforme han ledo los escenarios anteriores, algunos pueden haber dado en
el clavo. Tal vez usted record ejemplos similares o inclusive adicionales de su propio
conjunto de experiencias. La parte restante de este captulo presentar un mtodo
efectivo que usted puede seguir para evitar repetir estos tipos de errores. Puede
utilizar este mtodo para aprender de sus propias experiencias y del conocimiento y
las experiencias a su alrededor.

Revisin del Proyecto

Aquellos que no pueden recordar el pasado estn condenados a repetirlo.

George Santayana
Filsofo, poeta, humorista americano-espaol

El objetivo de este captulo es explicar cmo aprender de los errores pasados.

Los errores son cosas que suceden accidentalmente. Son desaciertos resultado de
malos entendidos. Son cosas que son hechas por ignorancia, falta de atencin y no
pensar. Si usted acepta cualquiera de estas definiciones, entonces usted podra decir
que utilizar "error" como una razn para repetir los mismos errores de un proyecto
a otro es una mala interpretacin de la palabra. No repiten las personas
conscientemente los mismos problemas? La primera vez que ocurre una situacin
problema, se podra aplica la palabra "error". Pero la repeticin sucesiva de esta
misma situacin difcilmente es un error. Se llama negligencia.

Negligencia es el acto de ignorar, no tener en cuenta o no cuidar o dar la atencin

debida a algo de notable importancia. Dicho de otra manera, negligencia es
fallar, sea por descuido o por deseo, al utilizar completamente el conocimiento
y la experiencia.

Nadie es infalible -todos cometemos errores. Por lo tanto, este captulo toca la
negligencia; esto es; cometer los mismos errores ms de una vez. Esto involucra
condiciones que con frecuencia no son slo evitables sino que pueden ser muy
desagradables si no se les presta atencin tempranamente. Estas son condiciones
que, si no se chequean, pueden destruir un proyecto y el espritu de su gente.

La herramienta principal para contrarrestar la negligencia es la revisin del

proyecto. La revisin del proyecta brinda una oportunidad par aprender de las
experiencias pasadas. Es una secuencia de actividades que, cuando se siguen, darn
como resultado un intento consciente y planeado para evitar que el siguiente proyecto
tenga que repetir las mismas negligencias que sus predecesores.

Las revisiones del proyecto han sido llamadas por muchos nombres diferentes.
Algunos de estos nombres son revisin post proyecto, post mortem, revisin de la autopsia,
revisin del anlisis del proyecto, revisin del mejoramiento de la calidad, y equipo de
mejoramiento de la calidad. Este ltimo trmino es mi favorito debido a su enunciado
positivo y debido al objetivo fundamental de su nombre:

245
246 Managing Software Development Projects

Trabajar como un equipo para mejorar la calidad del siguiente proceso y el siguiente producto.

Un revisin del proyecto se programa para ocurrir al final del proyecto. (Hay
excepciones. Ver el final de la seccin, "Algunos Beneficios adicionales".) La Figura
12.1 muestra la secuencia de los pasos a seguir para obtener una exitosa revisin del
proyecto. Cada uno de estos pasos es explicado en las secciones a continuacin. Sin
embargo, aqu se presenta una simple visin general de la revisin del proyecto.

1
Una revisin del proyecto comienza con la seleccin de las personas que representan a
todas las principales organizaciones dentro del proyecto. Estas personas, entonces,
identifican independientemente los elementos que estuvieron bien y aquellos que
estuvieron mal. Entonces, cada representante asiste a una reunin de grupo para
compartir sus descubrimientos. Luego cada grupo crea dos listas: la lista buena de
aquellas cosas que estuvieron bien, y la lista problema de aquellas cosas que estuvieron
mal. Los tems en las dos listas son ordenados independientemente en orden de
importancia. Se desarrolla una solucin recomendada para cada uno de los problemas
ms importantes establecidos en la lista problema. Luego se realizan las presentaciones
tanto a la jefatura del proyecto como a los miembros del proyecto. En este punto los
jefes del proyecto declaran su nivel de apoyo para asegurar que tanto la lista buena
como la lista de soluciones identificadas sean implementadas en los siguientes
proyectos.

246
 Revisin Post-Proyecto: Entendimiento del Pasado para Mejorar el Futuro 247

Figura .12.1
Pasos en una exitosa revisin del proyecto

10
Declarar la intencin

2
Seleccionar participantes

3
Preparar el taller

4
/ Reali7.ar el taller

5
Presentar los resultados

Adoptar recomendaciones

247
248 Managing Software Development Projects

Paso 1: Declarar Intencin

Al inicio del proyecto, la cabeza del proyecto debe establecer su intencin de tener
una revisin del proyecto al final del proyecto. Mejor es comunicar esta intencin
verbalmente en una reunin organizacional, luego dirigir una carta a todos los
participantes del proyecto. La carta debe establecer los objetivos de la revisin del
proyecto. Todos deben entender que, no slo los jefes del proyecto quieren hacer las
cosas de la mejor manera, sino que tambin estn receptivos a que sus decisiones
sean revisadas en retrospectiva. El objetivo claro es aprender tanto de sus errores
del pasado as como de aquellas cosas que funcionaron, y aplicar estas lecciones en
proyectos futuros. Para un efecto mximo, la carta debe incluir un apndice que
describa el proceso de revisin del proyecto. En este apndice debe incluirse la
identificacin de un conjunto mnimo de organizaciones que se espera participen en
el proyecto, dejando abierta la opcin de agregar ms para el momento en que se
termine el proyecto. El apndice tambin debe identificar los puntos o tpicos a los
que responder cada organizacin. (Ms sobre esto en la siguiente seccin, "Paso 3:
Preparar el taller".) Esto dar como resultado que algunas organizaciones prestan
mayor atencin a estas reas de sus procesos a lo largo de todo el ciclo de desarrollo
del producto.

Si esta es la primera vez que se seguir este enfoque en su organizacin, entonces

se encontrar con una mezcla de emociones. La mayora lo ver con algn
escepticismo, pero todos tendrn esperanzas que sea realidad. Arrisguese y declare
tempranamente su compromiso con la revisin del proyecto. Sin embargo, asegrese
de seguir hasta el final del proyecto y hacer que esta revisin del proyecto suceda.
Como tcnica de planeacin, aada este evento a la lista de chequeo de las actividades
del proyecto a monitorear. Hay mucho que ganar si se declara estas expectativas al
inicio del ciclo de desarrollo del producto.

Paso 2: Seleccionar Participantes

Una vez que el proyecto ha sido completado, entonces es el momento de comenzar

la revisin del proyecto. El primer acto es seleccionar a los participantes. Por lo
menos se debe seleccionar a una persona de cada una de las principales
organizaciones. Ejemplos de principales organizaciones son planificacin, desarrollo,
prueba, publicaciones, desempeo, utilidad, grupo de elaboracin de modulo,
garanta de calidad y otros que usted sienta adecuados.

Las personas seleccionadas deben tener un gran conocimiento de los procesos

que fueron utilizados en el proyecto. Tambin deben ser personas que se relacionan
con grupos de fuera de sus propias reas inmediatas. Los mejores candidatos son
los jefes de equipo. Las experiencias que aportaron originalmente al proyecto as
como sus roles de liderazgo dentro del proyecto los hacen las opciones favoritas. El
objetivo es seleccionar gente que ofrecer una percepcin amplia y profunda requerida
para una revisin completa del proyecto.

248
 Revisin Post-Proyecto: Entendimiento del Pasado para Mejorar el Futuro 249

Los gerentes, aquellos jefes del proyecto en una posicin de evaluar el

desempeo de las personas, no deben participar en el equipo de revisin. Este es el
momento para que los no gerentes utilicen su percepcin para evaluar el proceso
que pasaron muchos meses o inclusive aos desarrollando. Los no gerentes estn en
la mejor posicin para ofrecer tanto alabanza por las cosas que salieron bien como
crtica por aquellas cosas que necesitan mejorarse. Los gerentes del equipo pueden
inhibir a los candidatos del grupo y el libre flujo de ideas. Empero, el liderazgo del
proyecto no debe sentirse dejado de lado. Las recomendaciones hechas por el equipo
de revisin deben tener el apoyo y el compromiso del liderazgo del proyecto antes
de ser implementadas.

El liderazgo del proyecto escoger al director y puede ser cualquiera del equipo
de revisin. Sin embargo, la persona a cargo del equipo debe ser alguien que sea
respetado por los miembros del equipo. El jefe del equipo debe ser alguien que
pueda dirigir tan bien corno escuchar y facilitar la discusin entre los miembros. Si
el representante de desarrollo est calificado como para dirigir el equipo, entonces
est es la persona recomendada como primera opcin. Dado que desarrollo con
frecuencia es el mayor grupo organizacional y con frecuencia el grupo con el mayor
impacto a lo largo de todo el proyecto, se obtiene un beneficio especial si desarrollo
asume el rol de jefe de equipo. Esto puede influir para que desarrollo sienta una
mayor propiedad de las recomendaciones finales del equipo.

La participacin de cada representante en el equipo de revisin debe ser

obligatoria. Todas las organizaciones deben ser escuchadas y deben sentir que los
resultados finales tienen su compromiso. Si el liderazgo del proyecto es
verdaderamente un apoyo, la participacin en este equipo de revisin ser vista corno
una forma de reconocimiento positivo. La gente quiere ser escuchada y tambin
quieren ser miembros de una organizacin progresiva.

Paso 3: Preparar el Taller

Despus que se han seleccionado los participantes del taller, el siguiente paso es
definir la tarea a completarse antes de la reunin del taller. Se le pide a cada
participante que responda a un conjunto de tpicos. Las respuestas se deben
relacionar principalmente con la misin de cada encuestado dentro del proyecto.
Estos tpico pueden ser generalizados como se muestra en la Figura 12.2. De esta
manera, cada participante responde a las mismas reas generales de inters. Estos
ternas son de alguna manera amplios y pueden ser enunciados, si se desea, con mayor
precisin. Por ejemplo, el tpico "productividad" puede ser tratado ms
refinadamente con estas preguntas adicionales:

Qu nivel de productividad se logr en sus tareas? Cmo se compara con lo

que usted esperaba?
Qu podra haber cambiado para mejorar su productividad? Cunto hubiese
mejorado su productividad cada cambio?

249
250 Managing Sofiware Development Projects

Personal

Objetivos de la misin

Cronogramas

Procesos que salieron bien

Procesos que no salieron bien

Productividad

Herramientas

Calidad

Comunicaciones personales dentro de su rea

Comunicaciones personales desde fuera de su rea

Apoyo de otras reas

Mejorar en el ciclo de desarrollo del producto

Otros problemas y 1 o sugerencias

Figura 12.2
Tpicos generales a tratar por cada organizacin.

Otro enfoque es personalizar un subconjunto de tpicos que seran nicos para

cada organizacin. La Figura 12.3 brinda un ejemplo de tpicos personalizados que
sern tratados por el grupo de prueba de componentes. Este enfoque puede asegurar
que sern tratados tpicos muy especficos. Estos tpicos tambin pueden ser
refinados hasta otro nivel de detalle. Por ejemplo, el tpico "problemas descubiertos
en el cdigo del producto" podra ser respaldado por las siguientes preguntas:

Cuntos problemas encontrados fueron reportados por cada 1000 lneas-de

cdigos? De estos problemas reportados, cuntos fueron verdaderos defectos?
Error del encargado de la prueba? No reproducibles?
Cmo se compara el nmero real de problemas reportados con lo que se
esperaba?
Cul fue la severidad de los problemas encontrados? Cul fue el tiempo
respuesta promedio (en das) requerido para arreglar cada categora de
severidad asignada? El tiempo de respuesta estaba dentro del rango esperado?

Cada uno de estos enfoques, generalizado o personalizado, puede ser efectivo.

250
 Revisirt Post-Proyecto: Entertdimiertto del Pasado para Mejorar el Futuro 251

Cualquiera sea el mtodo utilizado, no pase por alto el pedirle a cada organizacin
que identifique esas cosas que salieron particularmente bien. Un enfoque solo en las
noticias malas puede ser deprimente. De hecho, en cada organizacin siempre hay
actividades que "salieron bien". Asegrese que estas reas positivas sean
conscientemente llevadas a los proyectos futuros.

Disponibilidad de la informacin del producto necesaria

Plan de prueba

Cobertura funcional de los procedimientos de prueba

il Desarrollo de los procedimientos de prueba

Inspecciones del procedimiento de prueba

Realizar los procedimientos de prueba

Automatizacin de los procedimientos de prueba

Problemas descubiertos en el cdigo del producto

Auto-documentacin de los procedimientos de prueba

Herramientas requeridas y 1 o utilizadas

Disponibilidad de hardware

Figura 12.3
Tpicos para la organizacin prueba de componentes

Paso 4: Realizar el Taller

Se puede esperar que la duracin de la reunin del taller sea de medio da a dos das,
dependiendo del tamao del proyecto y el nmero de participantes del taller. Un
da podra ser un tiempo razonable para la mayora de los proyectos. Se debe tratar
de evitar que la reunin o cualquiera en la reunin sea interrumpido por asuntos de
fuera. Los participantes de la reunin deben estar libres para concentrar su atencin
en este valioso ejercicio.

El taller es una reunin de trabajo. La primera parte de este taller ser asignada
a escuchar la presentacin de cada representante de sus respuestas a los tpicos que
les fueron distribuidos con anterioridad. Sera til si el orden de los presentadores
es el mismo que la secuencia general de las fases en el ciclo de desarrollo del producto.
Por ejemplo, el representante de planificacin presentar antes que el representante

251
252 Managng Software Development Projects

de desarrollo, quien a su vez presentar antes que el representante del grupo de

prueba y as sucesivamente. Tambin es beneficioso establecer un lmite de tiempo
para cada representante -algo dentro del rango de 10 a 30 minutos es suficiente para
la mayora de los talleres, pero usted puede elegir un rango ms especfico que se
adapte mejor a su proyecto. Por ejemplo, permita 10 minutos para los representantes
de las organizaciones pequeas y 30 minutos para los representantes de las
organizaciones ms grandes.

Se deben estimular las preguntas de la audiencia participante. Es de vital

importancia que los asistentes compartan sus diferentes puntos de vista. Se debe
esperar que surjan puntos de vistas encontrados en muchos tpicos. Esto es saludable
para la atmsfera de la reunin y brinda una gran oportunidad para que cada grupo
comprenda los puntos de vista de otros grupos. Esta perspectiva y la camaradera
cada vez mayor es un beneficio adicional de la reunin. Se debe estimular la crtica
del proceso. Sin embargo, se debe prohibir la crtica de las personas, no importa si
est dirigida a personas en la reunin o personas en otro lugar de la organizacin.

Una vez que todas las respuestas han sido presentadas y compartidas dentro
del equipo del taller, el siguiente paso es crear dos listas. La primera lista es de las
cosas que "salieron bien". Estas son las cosas que se quieren llevar a los proyectos
futuros. Es til ordenar la lista, poniendo los tems ms beneficiosos en lo alto. Los
tems en lo alto sern mostrados ms adelante al liderazgo del proyecto y a los
miembros del proyecto.

La segunda lista es de las cosas que "salieron mal" en el proyecto (no los defectos
en el producto). Esta lista de problemas debe ser ordenada dando prioridad,
enumerando primero los problemas ms importantes. Lo que en realidad nos interesa
es enfocar en la parte superior de 5 a 10 problemas. Los problemas que no llegan a
estar en la significativa lista no deben ser ignorados. Los miembros de cada
organizacin con estos problemas deben resolverlos independientemente a su propia
satisfaccin.

Una vez que los problemas ms importante han sido identificados, la siguiente
tarea es desarrollar las propuestas -para ser sometidas al liderazgo del proyecto- que
traten estos problemas. Se pueden dividir en grupos ms pequeos o trabajar
colectivamente en la solucin de estos problemas. En cualquiera de los enfoques,
todo el equipo debe llegar a un consenso sobre cada recomendacin antes de
presentarla al liderazgo del proyecto. Estas recomendaciones deben tratar o responder
las siguientes preguntas:

Quin tiene la propiedad para asegurar el cierre de cada problema?

Qu constituye el cierre de cada problema?
Cmo se monitorea la solucin? Cul debe ser la frecuencia del monitoreo?

Noten que es poco probable que todos estos problemas puedan ser resueltos en
una sola reunin. Algunos problemas requieren de una considerable investigacin
con datos y habilidades que an no estn disponibles en el taller. En estos casos, es

252
 Revisin Post-Proyecto: Entendimiento del Pasado para Mejorar el Futuro 253

aceptable no tener una solucin final. En cambio, se puede elaborar un plan para
recomendar que se forme un grupo para realizar un mayor estudio de un problema
dado, con el objetivo de proponer una o ms soluciones. Sin embargo, recuerden
asegurar que se asigne un propietario para trabajar en cada problema no resuelto.
Esto asegurar que cada problema sea tratado exitosamente al enfocar la
responsabilidad en un sola persona. Tambin, asegurar que se establezcan las fechas
objetivo de manera que el avance puede ser monitoreado apropiadamente.

En este punto, es el momento reunir los cuadros finales que sern revisados
por el liderazgo del proyecto. Estos cuadros tambin formarn parte del Informe de
Revisin del Proyecto para propsitos de seguimiento e histricos. Se sugiere que el
cuadro con las buenas noticias se presente primero. Este cuadro enumera las cosas
que "salieron bien" -en el grado que valga la pena resaltar estos tems.

Los cuadros restantes enumeran los problemas que el equipo de revisin pens
eran lo suficientemente relevantes para recibir una visibilidad especial. Cada
problema debe ir acompaado por una solucin recomendada o un plan para elaborar
una solucin. Cuando sea apropiado, usted querr proporcionar al liderazgo del
proyecto ms de una solucin de la cual puedan escoger. Esto no slo le da a los jefes
del proyecto flexibilidad, tambin les da un mayor sentimiento de propiedad y
compromiso sobre las soluciones finales que ellos eligen.

Paso 5: Presentar los Resultados

En este punto se recomiendan dos reuniones. La primera reunin se utiliza

para presentar los resultados del taller al liderazgo del proyecto. La segunda reunin
se convoca para presentar los resultados finales de la reunin con el liderazgo del
proyecto a todos los otros miembros del proyecto.

La asistencia en la reunin de los jefes del proyecto debe ser, como mnimo, del
primer y segundo nivel del liderazgo del proyecto. Estos niveles son tpicamente
aquellos definidos en la Figura 6.1 como jefes de equipo (primer nivel) y de
departamentos (segundo nivel). (En algunos proyectos, los jefes pueden ser todos
definidos como un" grado" superior: El jefe del primer nivel es definido como el jefe
del departamento, y su jefe es el jefe de segundo nivel.)

Normalmente el primer nivel abarca a los jefes de proyecto que son responsables
de tratar los problemas y sus soluciones recomendadas. El siguiente nivel de jefes
de proyecto asiste dado que ellos necesitarn saber qu recursos estn siendo
comprometidos y cul ser el impacto de estos compromisos. Los jefes tambin
necesitarn brindar apoyo a los jefes subordinados del proyecto as como medir el
compromiso de sus jefes de proyectos en el seguimiento de los planes.

Tambin es beneficioso incluir a los niveles por encima del segundo nivel del
liderazgo del proyecto. Es til para los niveles ms altos del liderazgo del proyecto

253
254 Managing Software Development Projects

el entender, de primera fuente, los problemas experimentados en el proyecto. Con

frecuencia; su apoyo ser requerido para tratar algunos de los problemas del proyecto.
Tambin, su insistencia en el monitoreo de la accin tomada por el primer y segundo
nivel del liderazgo puede tener un efecto profundo y positivo en la solucin de los
problemas.

El objetivo de la reunin con el liderazgo del proyecto debera ser que el equipo
de revisin del proyecto obtenga el respaldo total del liderazgo para implementar
las recomendaciones. Esto significa que se debe realizar un intento por obtener la
aceptacin de las recomendaciones. Sin embargo, noten que algunas soluciones
pueden no prestarse a decisiones rpidas y ms bien pueden requerir de un mayor
anlisis por parte del liderazgo del proyecto.

En la reunin con los miembros del proyecto, los jefes del proyecto tienen la
oportunidad de expresar su compromiso con la calidad del producto, los procesos y
el ambiente laboral en general. Este evento puede demostrar que el liderazgo del
proyecto est escuchando y respondiendo con una accin positiva.

El presentador recomendado para la reunin con el liderazgo del proyecto es el

director del taller. El presentador en la reunin con los miembros del proyecto puede
ser un jefe de proyecto o el director, dependiendo de la estructura organizacional y
las preferencias.

Paso 6: Adoptar Recomendaciones

El arte de la vida se basa en un reajuste constante de nuestros alrededores.

Kakuzo Okakura
Crtico de arte japons

El beneficio de la revisin del proyecto no termina despus que los resultados han
sido presentados al liderazgo del proyecto y los miembros del proyecto. Muy por el
contrario. El beneficio real de la revisin del proyecto es aprender de los errores
pasados y de aquellas cosas que salieron de acuerdo al plan, y aplicar esas lecciones
en proyectos futuros. El primer punto es completar el Informe de Revisin del
Proyecto. Este informe, como mnimo, debe contener los cuadros que fueron
presentados al liderazgo del proyecto. Tambin se deben incluir las recomendaciones
finales que fueron adoptadas por el liderazgo del proyecto. Opcionalmente, se puede
incluir los cuadros originales que cada representante present en el taller.

Despus que cada informe es terminado, se debe manda una copia a cada jefe
del proyecto. A su vez, cada jefe del proyecto debe hacer que una copia est disponible
para sus empleados. Otra opcin es que la cabeza del proyecto distribuya el informe
a todo el personal del proyecto -tanto a los jefes del proyecto como a sus miembros.
Cuando se inician proyectos nuevos, se debe contar con una lista de chequeo o una
lista de actividades con la cual poder comparar el proyecto. Los Informes de Revisin

254
 Revisin Post-Proyecto: Entendimiento del Pasado para Mejorar el Futuro 255

del Proyecto deben ser revisados por si pudiera tomarse una accin en el proyecto
nuevo. Esto debe ser monitoreado como una actividad requerida antes de aprobar
los cronogramas y actividades del proyecto nuevo. Est tcnica no slo hace que sea
ms difcil olvidar o pasar por alto los resultados de tma revisin del proyecto anterior,
tambin es un seguro cuando importantes participantes del proyecto en proyectos
pasados han dejado la organizacin. De esta manera, las valiosas experiencias del
pasado pueden continuar influyendo en el futuro.

El liderazgo del proyecto es responsable por actuar en lo relacionado a las

recomendaciones comprometidas. Si en cualquier organizacin en particular se
requieren chequeos y revisiones, adicionales a aquellos recin descritos, este es el
momento de realizar esos chequeos. Todos los ojos estarn puestos en el liderazgo
del proyecto para ver si se da el respaldo prometido. Este no es el momento de
retrica, sino de respaldo y accin.

Algunos Beneficios Adicionales

Secciones anteriores en este captulo hablan de las revisiones de los proyectos

como eventos que suceden al final del proyecto. Secciones anteriores tambin indican
que las revisiones del proyecto son implementadas de manera que los proyectos
subsiguientes pueden evitar repetir los mismos errores. Sin embargo, todos estos
pasos que han sido definidos para una exitosa revisin del proyecto se pueden aplicar
igual de efectivamente a otras dos actividades interesantes y beneficiosas: revisiones
de fases y revisiones de certificacin del producto.

Revisiones de Fases

Para un proyecto con una duracin de 6 a 12 meses, colocar una revisin del
proyecto al final del mismo ha demostrado ser constructivo y productivo. Sin
embargo, para proyectos que tienen una duracin de ms de un ao, esperar hasta el
final del proyecto para implementar una revisin global puede dar como resultado
la prdida de datos valiosos, o por lo menos dar como resultado datos menos
objetivos y por lo tanto, menos significativos. No slo los miembros del proyecto
olvidan piezas de informacin tiles, el movimiento de miembros del proyecto hacia
nuevos trabajos tiene muchas probabilidades de ocurrir. De manera que, qu hara
usted en un caso donde el proyecto excede el ao de duracin? Realiza revisiones
por fases a lo largo de todo el camino.

Las fases en el ciclo de desarrollo del producto se pueden definir de diversas

maneras. La Figura 5.2 sugiere estas fases tpicas:

Definicin del producto

Diseo del producto

255
256 Managing Software Development Projects

Cdigo
Prueba informal
Prueba Formal

Sin embargo, algunos proyectos pueden definir las fases como actividades
especficas. Una vez ms, la Figura 5.2 enumera las actividades que tambin pueden
ser tratadas como fases. Por ejemplo, la parte del ciclo de desarrollo del producto
que fue nombrada como 11prueba formal" puede ser vista a su vez como seis fases:

Plan de prueba de componentes

Prueba de componentes
Plan de prueba del sistema

Prueba del sistema

Plan de prueba de regresin
Prueba de regresin

Una vez que se han definido las actividades o fases claves que se ven representan
puntos significativos, entonces puede ocurrir la planeacin de las revisiones por fases.
Los pasos a seguir en la revisin de la fase son idnticos a los pasos descritos
anteriormente para la revisin del producto, con dos excepciones: el alcance de la
revisin y el impacto en el siguiente conjunto de actividades.

El alcance de la revisin de la fase es, por supuesto, menor que el de la revisin

de proyectos. La atencin se enfoca en una sola actividad o un pequeo conjunto de
actividades. Tambin, hay menos organizaciones involucradas, dependiendo de su
participacin en las actividades que se estn revisando. Las recomendaciones hechas
por el equipo de revisin de fase no vern slo las maneras de evitar errores similares
en el siguiente proyecto, tambin vern planes de recuperacin que podrn ser
aplicados en actividades posteriores. Estos planes de recuperacin abarcarn las
deficiencias en la calidad del producto en este punto en el ciclo de desarrollo del
producto (como, "El cdigo tiene ms defectos de lo esperado") y describirn maneras
de compensar esas deficiencias.

Revisiones de Certificacin del Producto

Una revisin de certificacin del producto se realiza inmediatamente antes que

el producto sea aprobado para su anuncio, y otra vez antes que el producto sea
aprobado para su entrega al primer cliente. Los pasos a seguir en la revisin de la
certificacin del producto son idnticos a los pasos discutidos anteriormente para la
revisin de proyectos, con una gran diferencia: El anlisis de la revisin de la
certificacin del producto est dirigido principalmente hacia el producto en lugar
del proceso. Ms especficamente, el enfoque de la revisin est en determinar la
aptitud del producto. Este anlisis culmina con una sea de "Pasa" o 11NO Pasa"
para anunciar o entregar el producto. La decisin final es tomada por el liderazgo
del producto, pero la recomendacin es presentada por el equipo de revisin de
certificacin del producto.

256
 Revisin Post-Proyecto: Entendimiento del Pasado para Mejorar el Futuro 257

Resumen

Espero que ustedes estn de acuerdo que el concepto de revisiones; ya sea que
sean de proyecto, fase o certificacin; tiene un gran valor para una organizacin y
finalmente l a aceptacin del producto por parte de su(s) clientes(s). Las
organizaciones que demuestran visin al planear para estas revisiones tambin son
aquellas organizaciones que probablemente reportarn menos problemas durante
las revisiones reales.

La negligencia siempre conlleva un costo alto. Al entender los proyectos

anteriores, esto es, que estuco bien y qu estuvo mal-una organizacin puede realizar
grandes ahorros. Aplicando este conocimiento a los proyectos futuros puede significar
llevar mayores utilidades al banco.

257