En una vieja
drdobbs journal encontré el concepto
quic-
kill project o proyecto de calendario
imposibleUn proyecto imposible es una
aberración conceptual.
porque solo se hacen proyectos factibles o posibles los otros no .
independientemente de lo que ese buen articulo quiso decir (
todavía lo encuentran
si se busca
quick kill project) Se trata de un proyecto:
1-recargado
2-mal planificado
Siempre la excusa es la urgencia , y la urgencia es eso: una excusa . El articulo de la revista
plantea una
organizacion alrededor de tres "documentos"
1-
vision and socpe document que no es mas que la
formulación de los objetivos del proyecto
2-
estructuración de las actividades en red
jerárquica3-revisiones de
códigoUn proyecto recargado es (traducido a
algún concepto conocido ) un proyecto donde todos los caminos se han vuelto
críticos. es decir no hay
ningún camino con holguras , si se atrasa cualquier actividad todo el proyecto se atrasara por lo menos en esa cantidad de atraso (
mínimo)
Entendamos: los recursos
están saturados todo el tiempo , es decir el contenido de las actividades es solo el
básico (
core) cualquier aspecto de
coordinación o
plantificación u
entumezcan es inaplicable porque no hay tiempo!. Y los jefes consideran que
deberían estar terminados ayer !
En el
ámbito del software dicen que son proyectos sin
gerenciacion , es decir llevado adelante por
programadores (es que no queda otra no hay tiempo para trabajos de
managment)
Estos proyectos son una verdadera calamidad , no puede salir nada bueno al final de ellos.
Los escritores
confían en que con la ayuda
espiritual de los objetivos, con la
concentración en actividades esenciales y con la disciplina de las revisiones estructuradas ,
quizás puedan completarse
exitosamente.
Exitosamente porque
conseguirán los resultados (nada mas), es decir se
hará código que ejecuta lo requerido , pero
segurisimo no es el mejor programa posible . Porque todo es incertidumbre.
Dice: que en
estos proyectos un miembro no sabe ni por donde empezar.
Mi
interpretación es simple: aunque nada tiene sentido , porque los objetivos no son claros , las actividades no las podemos completar y tampoco podemos dar una
mínima garantía de calidad de lo que estamos haciendo . En ese
desorden hay un sentido: seguramente los
objetivos están confusos entonces busquemos los resultados y/o metas para adivinar los objetivos . Solo encaremos actividades posibles o sea que tienen un principio , un fin , un
esfuerzo posible y un producto tangible (en nuestro mundo intangible). Y ya que los plazos no dan para control de
calidad , hagamos lo
mínimo : revisiones de
código.
Todo esta mal porque los elementos esenciales de un proyectos son los resultados esperados , una red de actividades factibles que aseguran el producto o resultado y un
método que sea verificable. En medio de todo esto hablan de las estimaciones
Recodemos que las actividades humanas
están enmarcadas en un contexto social y de necesidades personales.
Oralmente el que no conoce tiende a tomar como
buena una
estimación del
trabajo de robot o maquina . Ese es el contenido e
sencial o
básico o
mecánico de la actividad (si
hiciéramos solo eso durante las 24
hs habría que tener en cuenta por ejemplo que vamos al baño , que necesitamos
hidratarnos , que hay que
desentumeserse y
así .....) Y como sabremos entonces cuales son las restantes ? aparte de
estudiar , hay que basarse en
observaciones por lo menos de actividades parecidas y ejecutadas por un
tiempo considerable . Caso contrario
históricamente la
subestimacion es de un 50% , en el caso de gente con experiencia alrededor del 30%
Tenga en cuenta
también que el paso de una actividad a otra requiere (para software ) entre 11 a 30 minutos (tiempo de
preparación)