¿Cuándo es menos importante el "control de un proyecto de software"?

En el artículo titulado Ingeniería de software: ¿una idea cuyo tiempo ha llegado y se ha ido? , Tom DeMarco dice que:

Para comprender el papel real del control, debe distinguir entre dos tipos de proyectos radicalmente diferentes:

■ El Proyecto A eventualmente costará alrededor de un millón de dólares y producirá un valor de alrededor de $1.1 millones.

■ El Proyecto B eventualmente costará alrededor de un millón de dólares y producirá un valor de más de $50 millones.

Lo que salta a la vista de inmediato es que el control es realmente importante para el Proyecto A, pero casi nada importante para el Proyecto B.

No es "inmediatamente aparente" para mí. ¿Alguien puede explicar?

+1 solo por el enlace a este artículo. Una buena lectura que no había encontrado antes.
El proyecto A nunca debe comprometerse con...
@aclear16: Sin embargo, a veces este tipo de productos/proyectos son absolutamente necesarios. He estado trabajando en un producto/proyecto durante los últimos años que no se espera que gane dinero, sino que solo alcance el punto de equilibrio (en el mejor de los casos). Pero se sorprendería de lo crucial e importante que es este producto para la empresa para respaldar y complementar nuestra plataforma y cartera de productos.
Si el Proyecto A es absolutamente necesario, entonces el beneficio puro no es una buena medida de su éxito/fracaso. Si ese es el caso, entonces el ejemplo proporcionado no refleja con precisión una comparación de valor entre los dos proyectos.

Respuestas (2)

TL; DR

La premisa principal del autor es que la contención de costos es más importante para el Proyecto A que para el Proyecto B. Esto es casi axiomático si hace los cálculos.

Propósito de los controles del proyecto

Los controles del proyecto son los procesos y procedimientos que se utilizan para mantener un proyecto dentro de una variación aceptable de los objetivos del proyecto, especialmente en el área de costo proyectado frente al retorno esperado de la inversión (ROI).

Controles de proyecto y el artículo

  • El Proyecto A eventualmente costará alrededor de un millón de dólares y producirá un valor de alrededor de $1.1 millones.
  • El Proyecto B eventualmente costará alrededor de un millón de dólares y producirá un valor de más de $50 millones.

Lo que esto le dice es que el Proyecto A tiene un rendimiento esperado de $ 0,1 millones después de contabilizar los gastos del proyecto. Por otro lado, el Proyecto B tiene un retorno esperado de $49 millones , ganando más de 50 veces su presupuesto total. Como diría una de las estrellas de Breaking Bad : "¡Eso es mucho queso cheddar!"

Lo que salta a la vista de inmediato es que el control es realmente importante para el Proyecto A, pero casi nada importante para el Proyecto B.

El proyecto A tiene un margen de utilidad de solo $100,000. El presupuesto planificado consumirá casi todas las ganancias, por lo que no tolerará muchos retrasos en el cronograma o sobrecostos antes de que el proyecto esté en números rojos.

El proyecto B, por otro lado, tiene un margen de beneficio mucho mayor y, por lo tanto, un margen de error mayor. De hecho, el costo del proyecto es solo el 2% de las ganancias esperadas, por lo que el proyecto teóricamente podría salirse de control (por ejemplo, podría tener estimaciones de mano de obra que superen en un 300% el presupuesto) y aún así ganar mucho para los chicos de Breaking Bad . de "pilas de grasa".

Creo que CodeGnome lo clavó como el pensamiento que tenía el autor cuando redactó ese lenguaje; sin embargo, también creo que este es un mensaje terrible. En cierto modo, doy permiso para una gestión descuidada si tiene un alto grado de probabilidad de un retorno obsceno. También da permiso para ejercer una mano dura en los controles si se prevé que su retorno sea pequeño. Si mis inferencias dan en el blanco aquí, entonces debería evitarse la insinuación del autor.

Desde la perspectiva de este último, donde el rendimiento es bajo, debe tener mucho cuidado con los controles implementados. Son costosos y, si estudia las organizaciones cuidadosamente, lo que probablemente encontrará es un conjunto de controles que se implementan para resolver un problema inmediato y discreto, pero que nunca desaparecerán a pesar de que el problema se extinguió hace mucho tiempo. En otras palabras, tenemos una tendencia a mantener controles costosos que ofrecen poco o ningún valor.

Creo que, sin importar el rendimiento esperado, el despliegue constante de los controles correctos es el camino a seguir.

¡Por "mensaje terrible" me refiero al autor, no a CodeGnome!
No creo que el autor estuviera promoviendo "permiso para una gestión descuidada". Simplemente creo que lo que está diciendo es que los gerentes podrían, por ejemplo, dedicar el 80 % de su tiempo/esfuerzo en proyectos como el Proyecto A y el 20 % de su tiempo/esfuerzo en el Proyecto B. O, por ejemplo, si los desarrolladores del Proyecto B necesitaran refactorice el código para que sea 'realmente genial' (pero no una prioridad) y luego permitirlo de todos modos. O si tiene gerentes de proyectos junior, permita que 'ellos' dirijan estos "grandes proyectos" que tienden a ser monopolizados por PM senior simplemente debido a su gran prestigio de retorno de la inversión.
Con respeto, los ejemplos que proporciona son, en mi opinión, evidencia de una gestión descuidada. El 80% del tiempo en A por parte de líderes costosos con eficacia cuestionable solo aumentará los costos, los devolverá y proporcionará poco o ningún valor. Apriete el código adicional simplemente porque tiene sonidos de pista como características de arrastre. ¿Permitir que su tercera cuerda se maneje simplemente porque tiene cojín? Mmm....
¿Especialmente en un proyecto en el que probablemente gastes el dinero de otra persona?
Según su comentario: "evidencia de una gestión descuidada", creo que la "gestión descuidada" es una consecuencia de los escenarios del mundo real para la gran mayoría de nosotros. Nos enfrentamos a muchos problemas; muy pocos recursos, demasiados proyectos, muy poco tiempo, demasiadas funciones, tiempo de comercialización, etc., etc., lo que significa que la 'gestión descuidada' es una realidad y debemos hacer todo lo posible para gestionarla lo mejor que podamos. Todavía tengo que ver la "ejecución perfecta" de cualquier empresa y gerente de proyecto. Nos esforzamos por la teoría académica, pero lamentablemente debemos enfrentar la realidad. Mi comentario se basa en la ejecución de tal realidad.
Si bien la perfección nunca se logra, nunca dejas de intentarlo. Decir que esta es nuestra realidad y que es académica/teoría es darse por vencido y aceptar el statu quo. No puedo decirle cuántas veces, como consultor de BPM, entro en un entorno, realizo un cambio elemental y académico y observo cómo se dispara el rendimiento.
Estoy de acuerdo en que todos deberíamos tratar de 'perfeccionarnos a nosotros mismos/procesar/etc' (lo cual hago), aunque a veces simplemente no es posible debido a la cultura corporativa. ¡Pero tampoco estoy hablando de rendirme aquí! El statu quo, por otro lado, es la realidad para muchas organizaciones... tipo de entorno de 'tómalo o déjalo' (desafortunadamente). Si ingresa como consultor a este tipo de lugares, tenerlo allí en primer lugar es una señal de que quieren mejorar. Pero creo que también nos estamos desviando un poco del tema :)
¿Cuándo es menos importante el "control de un proyecto de software"?
RespuestasAquíPolítica de privacidad1y, 0v