« Minimum Viable Product [revisado] | Main | On the evolution of technologies »

09/16/2009

Comments

Mario López de Ávila Muñoz

Gracias a tí por comentar, José L.
En realidad, el mérito es del Dr. Holt :-)

José L. Peris

Muchas gracias Mario por este más que interesante enlace en el que describes de manera sencilla la aplicación de la gestión de proyectos siguiendo el método de Cadena Crítica. Está muy detallada y muy clara, de aplicación casi inmediata.

 Mario

Nadie vuelve a comentar... mmm... me veo respondiendo a nadie! A riesgo de que me tomen por loco, allá voy.

Si yo estuviera en la situación en la que nadie se encuentra... ejem... eh... en fin, especificaciones ambiguas, alta incertidumbre con respecto de la duración de las tareas, desarrollo pésimo, etc..., probablemente trataría de lidiar con toda esa mierd* adoptando un enfoque muy muy ágil ["Agile"] en la gestión del proyecto.

Es decir, buscaría la cercanía, casi diría la 'intimidad' con el cliente, hasta el punto de incorporarle en el equipo como un miembro más, si fuera posible.
Trabajaría con ciclos de desarrollo ultra-cortos, centrados en la entrega frecuente de funcionalidades que aporten un valor real.
Protegería al equipo de desarrollo de interferencias externas durante los ciclos de desarrollo montando un buen sistema de backlog para recoger las peticiones de cambio [que serían cuidadosamente analizadas por el equipo, en colaboración con el cliente, para determinar su impacto real en el desarrollo].
Introduciría o al menos trataría de introducir algo parecido a un Test-Driven Development - diseñar el test antes de escribir ni una línea de código - para mejorar la calidad del resultado y evitar reprocesamiento del código de última hora.
Haría un seguimiento diario, tipo daily scrum, del trabajo del equipo. Etc...

En paralelo:

* Entiendo que la incertidumbre se refiere a la duración de las actividades, no al establecimiento de las relaciones de dependencia lógica y/o de recursos... en otras palabras, que sabes qué tienes que hacer y en qué orden o secuencia, aunque no sepas cuánto te va a llevar. En esas circunstancias, el hecho de que la incertidumbre sea muy alta no te impide utilizar Buffer Management para proteger / controlar tu proyecto, antes al contrario. Si no te sientes cómodo con el tamaño del búffer del proyecto que te proporciona la regla del 50%, utiliza un porcentaje mayor: 60 o 70. Después procede como con cualquier otro proyecto CC.

* A menudo puedes reducir la incertidumbre con relación a una actividad descomponiéndola en "trocitos" más pequeños, por ejemplo utilizando algo llamado Work Breakdown Structure (WBS);

* A elaborar especificaciones se puede aprender. Disciplinas como Requirement Engineering están bien documentadas. Podrías formar a los encargados de elaborar las especificaciones en metodologías propias de esta disciplina.

* Pondría en marcha un proceso de selección para sustituir al 80% del equipo de desarrollo que no vale ni para tomar por cul*.

* Empezaría a buscar trabajo en otra empresa.

nadie

Todo lo que cuentas esta muy bien siempre y cuando no tengas actividades con tanta incertidumbre que nadie es capaz de indicarte cuando finalizaran (falta de recursos apropiados eso lo tengo muy claro, pero es lo que tengo) . Ejemplo:En un proceso de pruebas de un software. Cierto que las especificaciones son ambiguas [=incapacidad de hacerlo mejor ], desarrollo pésimo [=muy limitados como desarrolladores] y con eso es con lo que tienes que lidiar. Prueba-error-prueba-error y nada no hay manera de que sean capaces de saber cuando finalizarán, en cualquir momento puede aparecer algo que no se dijo o que se entendió mal.
La teoría esta muy bien pero cuando lo llevas al día a día te pegas cada "ostia"


pablo

Pues que el Azar lo permita, que yo aprendo mucho de tí y tus homenajes :-)

 Mario

Hombre Pablo, ya deberías saber que no se trata de copiar, sino de hacer un modesto homenaje al Dr. Holt :-)

Volveré a Cadena Crítica, sí, y también a S-DBR y Througput Accounting muy pronto... Si el Azar lo permite, claro está.

pablo

Mario, tenías razón!! Tenía que haber comentado este post, pero como sabes estuve de viaje y me falló la conexión unos dias...
El post es bueno, buenísimo!! Como se nota que es copiado :-) Fantástica exposición en pocas líneas de que es Cadena Crítica. Está guardado y reenviado, como tantos otros de los que aquí posteas. Gracias.

Me alegro que vuelvas al "origen", a hablar de Goldratt y, sobre todo, de CC!! Que se repita, que hacía mucho que no lo nombrabas...

A Manuel Parra: hay algunas empresas que utilizan CC en construcción y en arquitectura, con resultados espectaculares. Si bien es cierto que algunas veces en contrucción el ejecutar la obra en plazo, tiempo y coste puede que no sea la prioridad :-) Yo he utilizado este sistema en construcción y arquitecura, y me quedé enamorado de los resultados. A tu disposición estoy.

Un saludo a todos,
Pablo.

 Mario

Manuel, tienes toda la razón. Sólo conozco dos personas/empresas del sector que aplicasen regularmente Cadena Crítica. Una está en Málaga, fue cliente de Manuel Rodríguez, uno de los mayores expertos en Cadena Crítica de nuestro país y llevan casi una década trabajando con CC. Otro está en Vigo, es un estudio de arquitectura que lleva la dirección de obras en muchos concursos públicos. No conozco más referencias que éstas.

Manuel Parra

Muy interesante y aplicable aunque todavía en aplicaciones de construcción no se está poniendo en servicio mucho la teoría de critical chain

 Mario

Gracias a ti, Antonio :-)
¿Te has dado cuenta de lo mucho que se parece el punto 10. de Holt a un Daily Scrum? Siempre he dicho que CC es sinónimo de Agile :-)

Antonio Ramos

Espectacular, im-presionante

Gracias Mario por compartir con todos este HOW TO que va tan al grano y, como no, por tus, más que útiles, puntualizaciones...

Se acaba de convertir en uno de mis posts del kit de herramientas básicas de TOC y de Gestión de Proyectos.

Sin más: muchas gracias!!

The comments to this entry are closed.

Categories