Estoy leyendo un libro de Steve McConnell que trata sobre estimaciones de proyectos de software y no entiendo la siguiente declaración (mi traducción, obtuve el libro en alemán):
Una organización eficaz pospone sus compromisos hasta que se haya hecho el trabajo de estrechar el cono. .. Se pueden dar compromisos razonables en la parte inicial de la fase intermedia (aprox. en el 30% del avance del proyecto).
¿Cómo se puede lograr esto en la realidad? Quiero decir, en la empresa, no podemos empezar a trabajar en el proyecto hasta que el contrato esté en vigor. El contrato se firma con un esfuerzo estimado y precio, por lo que ya estamos comprometidos con ello.
Entonces, ¿cómo se aplica esto en la práctica?
El cono de incertidumbre tiene algunos usos, pero es más útil cuando se usa junto con otras prácticas. Entonces, comencemos con los usos en las circunstancias que describe.
Cono de Incertidumbre cuando se Adquiere un Compromiso
Obviamente, no se puede retrasar un compromiso que ya está hecho, eso es una simple cuestión de física (tiempo). La mayoría de las organizaciones con las que he trabajado que trabajan en el modelo de alcance fijo y fecha límite que tienen éxito hacen dos cosas. En primer lugar, aumentan severamente sus estimaciones. Siempre prometen la cola del cono de incertidumbre. En segundo lugar, conservan cierto control sobre el esfuerzo que pueden aplicar, agregando equipos y personas al equipo. Es esta segunda parte donde el cono de incertidumbre les resulta útil. Es posible que haya escuchado el dicho "agregar personas a un proyecto tardío lo hace más tarde". Esto viene del tiempo de aceleración. Agregar personas a un equipo o equipos a un proyecto ralentiza el proyecto por un tiempo antes de acelerarlo, por lo que en la gestión de proyectos tradicional generalmente no se sabe que un proyecto está retrasado hasta que Está demasiado cerca de la fecha límite para superar esa desaceleración. Aprovechar de manera efectiva los gráficos de quemado y un cono de incertidumbre le permite ver que su proyecto está atrasado mucho antes, tal vez a tiempo para agregar personas o equipos de manera efectiva.
También vale la pena señalar que nunca he conocido a una organización exitosa que se dedique a un proyecto (y una estimación) en frío. O bien invierten una buena cantidad de tiempo en arquitectura y diseño (no sé si es el 30 %, pero suele ser considerable) o venden una solución lista para usar en la que aprovechan el trabajo anterior para este mismo propósito. En otras palabras, están invirtiendo tiempo y dinero que esperan recuperar más adelante.
Cono de Incertidumbre Sin Alcance Fijo / Plazo Fijo
Este es probablemente el enfoque más común que he visto con las empresas que realizan trabajos por contrato. En lugar de un gran compromiso, hay una serie de pequeños compromisos, como trabajar en 2 o 3 sprints o, si no usa Scrum, tal vez un mes a la vez. He trabajado con varias empresas reales que hacen esto. El plan puede ser para un proyecto de 8 meses, pero hay controles regulares y el cliente puede retirarse cuando lo desee porque los equipos están entregando un software de trabajo utilizable, por lo que nunca se trata de reducir las pérdidas. Aquí, el Cono de Incertidumbre ve un gran valor, ya que puede hacer pronósticos sobre cuándo se podría realizar cierto trabajo y también usar esos pronósticos para pivotar sobre qué trabajo es más importante.
Cono de Incertidumbre sin Compromisos
Este enfoque es mucho más común cuando el equipo que realiza el trabajo es interno de la organización, pero he trabajado con grupos en los que básicamente están al servicio del cliente y pueden usar este modelo. En este enfoque, los equipos tienen algunas medidas de éxito como tiempo de actividad, trabajo manual reducido, etc., que utilizan para priorizar el trabajo. Trabajan con el cliente para mover la aguja en esas medidas. Esto abandona por completo el modelo de proyecto y, por lo tanto, no se ven tanto gráficos de quemado ni conos de incertidumbre en las conversaciones. Sin embargo, aparecen de vez en cuando, especialmente en esfuerzos a largo plazo. Por ejemplo, podría pensar que una actualización de la plataforma impulsará mucho todas esas medidas, pero llevará algunos meses. Tres semanas en, Puedo usar este cono de incertidumbre para ver si esos tres meses están saliendo como pensaba. Tal vez tome mucho más tiempo porque la nueva versión de la plataforma es simplemente un desastre, y elegir posponerla mientras el proveedor soluciona los errores es una mejor decisión comercial.
Finalmente, su circunstancia
Por supuesto, no sé cuáles son tus circunstancias, el tipo de trabajo que haces o cómo redactas tus contratos. Estas son formas en que otras empresas han aprovechado este modelo, pero los diferentes mercados en diferentes países están más o menos abiertos. Además, incluso si el mercado funciona de cierta manera, diferentes clientes en ese mercado estarán por todas partes en su tolerancia al compromiso. Cuando las empresas intentan cambiar a este enfoque, veo el mayor éxito cuando encuentran un cliente que está abierto a probarlo en lugar de forzarlo a un cliente y buscan un equipo que se ofrezca como voluntario para trabajar de esta manera en lugar de obligar al equipo a hacerlo. .
Especulo que "compromiso" se está utilizando en un sentido indeterminado/ambiguo.
No podemos posponer el compromiso, pero podemos controlar los recursos comprometidos. La mayoría de las organizaciones tienen algunas puertas de enlace por las que deben pasar los proyectos, y esas puertas de enlace dependen en gran medida del "cono de incertidumbre". En mi organización hay una puerta de enlace al final del proceso de requisitos y una segunda puerta de enlace al final del proceso de diseño. Cada uno de estos sirve para controlar cuánta incertidumbre permanece en el proyecto. No comprometemos todos los recursos hasta la tercera puerta de enlace; hasta ese momento solo hemos hecho un compromiso tentativo. (Nuestros números sugieren que 2/3 del costo es después de esa tercera puerta de enlace).
Esto también tiene el efecto de "aplazar el trabajo" hasta que el cono de incertidumbre sea más estrecho. No comenzamos la producción hasta que hayamos completado el desarrollo.
Tomado bajo esa luz, la declaración es... un poco obvia...
Nuestros proyectos son internos; no estamos trabajando con un contrato, sino con una parte interesada/obligación interna. Dicho esto, creo que algunas organizaciones hacen cosas similares, por ejemplo, contrato para completar el diseño, con la expectativa de un contrato de desarrollo si el contrato de diseño tiene éxito, etc.
Línea inferior al frente
¿Cómo podríamos retrasar el compromiso con las estimaciones en la vida real?
Si se requiere una estimación de extremo a extremo por adelantado , entonces no se puede retrasar. Si el enfoque se puede cambiar a una forma de trabajo iterativa y colaborativa, entonces cada iteración es un retraso y más estimable.
Entonces, ¿cómo se aplica esto en la práctica?
Su valor está en comprender que cuanto menos se sabe, especialmente sobre el trabajo complejo, menos seguro se puede estar sobre el futuro; la certeza aumenta a medida que el trabajo se acerca a su finalización. Su aplicación varía según el enfoque.
La gestión de proyectos tradicional tiene sus raíces en los procedimientos de fabricación basados en Fredrick Taylor y su discípulo Gantt. La idea es que al trabajar en fases, donde un grupo de especialistas crea entregables para pasar al siguiente grupo de especialistas, varios aspectos del proyecto (especialmente costo, alcance, cronograma) pueden controlarse de manera más efectiva. Tiene mucho éxito en dominios simples y ha tenido éxito en dominios complicados. (Para ver las definiciones de dominio, consulte Cynefin ).
Estas ideas se han aplicado incorrectamente al desarrollo de software, lo que ha dado lugar a la llegada de la cascada debido a la mala lectura del artículo de Royce, Gestión del desarrollo de grandes sistemas de software . Muchos de los problemas se han documentado, incluido el sincero libro retrospectivo de Fred Brooks The Mythical Man-Month , la complejidad de una sola fase se destaca en Requisitos de software: ¿son realmente un problema de Bell & Thayer y el informe anual CHAOS .
En la década de 1990 se desarrollaron varios enfoques para tratar de abordar estos problemas: Scrum y eXtreme Prgramming son dos de los más reconocidos. Diecisiete personas detrás de estos enfoques se reunieron en 2001 para discutir lo que estaban aprendiendo y haciendo. El resultado fue la creación del Manifiesto para el Desarrollo Ágil de Software . Esa filosofía resultante de cuatro valores y doce principios es un resumen y una guía general para el éxito.
Cuando se aplica en el modelo de fabricación tradicional, el cono de incertidumbre reconoce la realidad: cualquier estimación inicial es muy inexacta. Esta es la razón por la cual el relleno de estimación se usa con tanta frecuencia; Las estimaciones de rango serían más honestas y estarían respaldadas por el cono, pero no se ven con frecuencia ya que no son lo suficientemente concretas para la mayoría de los sistemas de gestión de proyectos o contratos comerciales tradicionales. Una vez aceptado, se hace hincapié en tratar de documentar y diseñar todo completamente para intentar cumplir con la expectativa ahora contratada o validar las estimaciones iniciales. A medida que el proyecto se acerca a la fecha límite, las proyecciones suelen ser más precisas según lo descrito por el cono. Se puede agregar personal, se aplican procesos de cambio de requisitos (alcance) y se puede negociar un apéndice para tiempo adicional.
Cuando se utilizan enfoques modernos de desarrollo de productos de software, cada iteración se puede ver como un proyecto propio con más previsibilidad. Tener una visión y no un plan rígido, el cliente y el productor trabajando juntos diariamente, creando pequeños incrementos de software usable y de alta calidad, y reevaluando continuamente las necesidades del cliente y la efectividad de la solución son fundamentales. Estas prácticas dan como resultado que se reduzcan los riesgos y que la estimación se vuelva más exacta y precisa porque el cono de incertidumbre sigue siendo estrecho para cada iteración corta del esfuerzo. El cono de incertidumbre se convierte en una herramienta de pronóstico una vez que se ha establecido un ritmo relativamente constante. Cuanto más adelante se mira, menos exacta y precisa es la estimación.
Manejar bien los resultados probabilísticos en cualquier organización requiere un alto grado de madurez del proyecto dentro de esa organización. Creo que es muy difícil llegar a un alto grado de madurez y luego mantenerlo una vez que estás allí. En mi experiencia, e incluso con mi empresa que tiene un enfoque intenso en PM, he sido testigo de pocas capacidades de PM realmente maduras en una empresa.
Entonces, hay sesgos humanos normales en juego que nos llevan a descartar o minimizar el riesgo en nuestro mundo, donde terminamos siendo muy optimistas sobre nuestro futuro y donde creemos que tenemos mucho más control sobre el número infinito de variables laborales que afectan resultados de lo que realmente hacemos. Entonces, incluso con una organización de PM muy madura, estos sesgos nunca desaparecen.
Finalmente, en un acuerdo de comprador-vendedor, tenemos otros impulsores comerciales en juego que dictan que se acuerden compromisos firmes, aunque no concuerde con las buenas prácticas de PM. Después de todo, los retrasos en el cronograma y los excesos en los proyectos generalmente benefician los ingresos del vendedor, excepto cuando tiene el contrato adecuado para evitarlo. Eso generalmente significa compromisos mucho antes de que comience un proyecto.
Juan V
Daniel