¿Es una buena idea estimar un proyecto sin requisitos básicos o historias de usuario para una propuesta de costo fijo?

Comencemos con la observación obvia: el momento en que menos sabemos sobre un proyecto es en su comienzo . Desafortunadamente, para proyectos de precio fijo también es un momento en el que generalmente solicitamos decir cuánto va a costar, por lo tanto, estimar.

En tal situación, me centraría más en mejorar la calidad de la estimación que en elegir esta o aquella técnica de estimación. En otras palabras, no veo por qué no debería estimar el estilo BDD (si eso funcionó para usted).

Hablando de mejorar la calidad de la estimación:

• Utilice estimaciones de puntos múltiples (como puntos Zbigniew; +1). Este enfoque se utiliza en muchos métodos, por ejemplo, PERT , incluso si al final obtenemos una estimación de un solo punto. Hay una trampa relacionada con la estimación de múltiples puntos. Si trabaja con un contrato de precio fijo, no tiene precios de puntos múltiples, por lo que eventualmente necesitará traducir la estimación de puntos múltiples en un precio de punto único. De cualquier manera, es mejor conocer el rango de estimaciones posibles que solo una.

• Probabilidad. Alternativamente, en lugar de elegir un rango, por ejemplo, de 80 a 120 días-hombre, puede usar la probabilidad, por ejemplo, estamos 60% seguros de que tomará 100 días-hombre. Vea cómo se usa el análisis de Monte Carlo en la Programación basada en evidencia para obtener más información sobre cómo puede aplicar esta técnica.

• Usa datos históricos. Probablemente el mayor cambio de juego en términos de estimación. Lo mejor que podemos hacer para mejorar nuestras estimaciones es verificar cómo lo hicimos con respecto a nuestras estimaciones en el pasado. Lo que necesita para aplicar esta técnica es recopilar datos sobre cómo estimó y cómo resultó finalmente. Luego, puede saber qué tan equivocado está normalmente y usar este conocimiento para ajustar sus estimaciones actuales. Después de todo, si constantemente subestimas tus tareas a la mitad, ¿por qué de repente esperas estar exactamente en el objetivo esta vez?

• Evite la estimación en absoluto. Esto es radical, lo sé, pero no está tan lejos de lo que propuse anteriormente. Si puede dividir su proyecto en piezas de tamaño aproximadamente similar (por ejemplo, consulte: Funciones de tamaño estándar ) y tiene datos históricos confiables que puede usar para conocer su tasa de entrega, es decir, con qué frecuencia puede entregar dicha función, puede basarse en estos valores para estimar la cantidad de trabajo necesario para completar el proyecto. Vea este ejemplo para aprender cómo puede hacerlo.

Y, sobre todo, lea el libro Estimación de software de Steve McConnell .

En términos de estimación, no existe una bala de plata, por lo que, básicamente, al conocer diferentes técnicas, puede mejorar la calidad de las estimaciones de una manera que sea factible en su caso. Por ejemplo, su equipo puede organizarse ad-hoc para un proyecto y es posible que no pueda tener datos históricos confiables, etc. El truco, como siempre, es usar la herramienta adecuada para el problema correcto.

Los contratos de precio fijo y el alcance ambiguo no van juntos... nunca. No puedes seguir el camino de ni siquiera decir claramente lo que harás porque nadie sabe lo que hay que hacer. No puede planear manejarlo con solicitudes de cambio porque un CR es un cambio en el alcance... y no tiene ningún alcance.

Este es un contrato de tiempo y materiales. Esto no es discutible. Un contrato de FP en estas circunstancias es injusto tanto para el vendedor como para el comprador de servicios. Para el vendedor, usted está asumiendo un grado de riesgo que es inaceptable e insuperable. No tendría más remedio que cargar el precio con un montón de contingencias, lo que a su vez lo hace injusto para el comprador al hacer que el precio sea dos, tres o cuatro veces lo que podría haber sido bajo otro acuerdo.

Si tiene que cotizar sin requisitos, debe ser muy claro al indicar con precisión qué hará por el pago de costo fijo que solicitará. Por lo tanto, en lugar de aceptar "el trabajo" (que es una especie de especificación de manos sueltas), enumerará los resultados específicos que puede lograr. Deje muy claro que los entregables solo incluirán lo que está escrito, y el trabajo adicional tendrá un costo adicional.

¡Bienvenido a PMSE!

Dividamos su pregunta en subpreguntas...

¿Es una buena idea estimar un proyecto sin requisitos básicos o historias de usuario?

No, no es una buena idea en absoluto, pero a veces tenemos que bailar con la música.

Mi instinto me dice que no tener todos los requisitos por adelantado crea demasiado riesgo. Personalmente, quiero saber cómo se ve "hecho".

Tus agallas son correctas, me temo. El riesgo del proyecto es directamente proporcional a la falta de requisitos claros... lo que significa que en su caso el riesgo es enorme.

¿Entonces Que puedo hacer?

Como no hay requisitos claros, pero sí un presupuesto claro (y plazos, supongo), creo que necesitará discutir mucho con el cliente para desglosar el proyecto tanto como pueda. Tener un primer PBS, definir estimaciones aproximadas para cada pieza de trabajo a realizar, sus dependencias y también definir claramente las prioridades entre cada pieza.

Las estimaciones se actualizarán a medida que avanza el proyecto, sus dependencias lo ayudarán a definir la ruta del proyecto en el futuro y las prioridades se usarán en caso de que las cosas se desvíen y necesite cortarlas. Lo sentimos, cuando se trata de proyectos, siempre debemos estar preparados para los peores escenarios.

Entonces, en resumen:

• Sea honesto con su cliente y explíquele que cuanto más claro se vuelve el proyecto, menos riesgo tendrán ambos (aquí sugiero evitar decir "cuanto más confuso se pone el proyecto, más riesgo tendremos", ya que puede dejar una mala impresión);
• Redactar con el cliente un PBS aproximado ;
• Acuerde las prioridades de las piezas con el cliente antes de proporcionar sus estimaciones (solo para evitar sesgos en la decisión del cliente);
• Acordar formalmente (por correo, contrato, lo que sea) todo lo anterior, teniendo especial cuidado en los detalles sobre lo que se va a entregar y lo que no.

¡Éxito!

Por favor, no intente especificar todo usando BDD. Terminarás con un backlog terriblemente detallado que lleva años mantener y que aún no se parecerá al proyecto real que surja.

Algo que he hecho, y que funciona muy bien con BDD más adelante, es observar las capacidades de alto nivel que el sistema debe proporcionar. Una capacidad es algo que un usuario podrá hacer o que el sistema puede hacer. Obviamente, esto significa capacidades comerciales, pero puede incluir capacidades técnicas, como rendimiento, integración con sistemas de terceros, etc. Como guía, teníamos alrededor de 30 tarjetas para un proyecto empresarial de 2 años.

A continuación, coloque un gran punto rojo en todo lo que sea nuevo o desconocido. Estas son sus áreas de mayor riesgo.

Si lo desea, puede estimar aproximadamente el tamaño relativo de las capacidades en puntos, de la misma manera que estimaría historias, pero más grande (use múltiplos de 10 como mínimo). Empecé con el más pequeño en 20, luego el más grande en 400, luego encontré uno en el medio y fui desde allí.

Cuando termine, duplique todo lo que tenga un punto rojo a menos que pueda pensar por qué el riesgo no es tan malo.

Esto le dará una muy buena idea de cuán complejo y arriesgado es el proyecto en comparación con proyectos similares que haya realizado, y podrá estimar el costo aproximado mucho más fácilmente. También le permitirá gastar su dinero y el del cliente en la producción de software en lugar de discutir sobre el alcance. Si tiene problemas para calcularlo, busque a algunas personas que hayan realizado proyectos similares. También puede usar las capacidades para definir un lanzamiento mínimo, que será más fácil de estimar y también representará menos riesgo y un retorno más rápido para el cliente.

Mi último consejo es trabajar con clientes razonables que prefieran producir cosas útiles y abordar juntos el riesgo real que discutir sobre quién es responsable de definir el futuro nebuloso.

Para leer más, este es un artículo que escribí hace un tiempo sobre esta técnica (entonces nos referíamos a las capacidades como temas o conjuntos de funciones ). Lea también las publicaciones de Dan North sobre los peligros de la estimación y el descubrimiento deliberado .

Si desea estimar los proyectos en función de lo que tiene hasta ahora, puede hacerlo proporcionando un rango de fechas en lugar de una fecha fija. Esto se llama " El Cono de la Incertidumbre ". La idea básica es que cuanto menos sepa, menos precisas serán sus estimaciones, por lo que debe incluir ese error en sus fechas. Sin embargo, entiendo que el cliente siempre quiera tener la fecha fija, por lo que debes explicarle de dónde salieron los rangos.

Además, agregue un búfer para incluir cambios y otro búfer para incluir riesgos.

Estoy de acuerdo con las otras respuestas en que es imposible estimar sin saber cuáles son los requisitos.

Lo que podría hacer, según la información que tiene ahora, es ofrecer un contrato de precio fijo solo para un estudio de análisis de requisitos . Podría incluir una especificación funcional e incluso técnica aproximada o detallada si está familiarizado con este tipo de proyecto. Agregue algunos prototipos de pantalla importantes para que el cliente pueda tener una idea de lo que obtendrá.

Cuando haya terminado, y no tiene que tomar tanto tiempo, también puede agregar su mejor precio para el resto del proyecto.

Asegúrese de tener un representante de atención al cliente calificado que trabaje con usted todo el tiempo. No solo para asegurarse de que su análisis sea preciso, sino también para construir una relación con este cliente.

Los requisitos cambian con el tiempo, así que asegúrese de que esto también esté claro para su cliente y agregue el proceso apropiado para los cambios en el resto del proyecto.

Puede vender esto al cliente con la idea de que el aspecto de TERMINADO es claro para ambas partes, pero que pueden usarlo para ir de compras a otro lado. Aquí es donde la cosa de la relación es importante.

Puede ser una decisión arriesgada aceptar un proyecto. es recomendable pasar por los requisitos del cliente, y la parte más riesgosa es si el cliente explica el proyecto en una sola línea.

El proyecto de costo fijo puede ser aceptable en las siguientes condiciones: si la solución/proyecto está claramente definido desde el lado del desarrollador, si tiene la fuerte sensación de que el cliente definitivamente satisfará su solución/trabajo, si el cliente lo conoce bien, tiene experiencia laboral previa con él.

Supongo que esto es durante una fase de licitación, donde el cliente determina con qué socio trabajar. Tienen un problema y quieren que se solucione lo mejor posible por una cantidad fija de dinero.

Asumes erróneamente que debes estimar lo que cuesta proporcionar un determinado alcance. A menudo es al revés: tienen un presupuesto disponible y quieren al proveedor que ofrezca el mayor valor.

• Sugiera una fase de análisis (facturada), donde trabajará con el cliente para definir mejor el alcance. Argumentos de venta:
  • Sin esto, agregaremos una gran cantidad de contingencias a nuestro contrato. Todos los vendedores (serios) lo harán.
  • Al pagarnos para hacer esto, terminará con un documento de requisitos de alta calidad. Esto permitirá que todos los proveedores reduzcan su contingencia, permitiéndole obtener mejores precios.
  • Los proveedores (como mínimo) realizarán este análisis de forma gratuita para reducir su propio punto de riesgo/precio. Sin embargo, tendrá que hablar con 5 proveedores en lugar de solo 1.
• Componga el alcance, definido con la mayor precisión posible. Estarán felices de que hayas hecho el esfuerzo proactivo y verán claramente que conoces su negocio.
  • Desventaja: simplemente podrían usar su análisis e incorporarlo en la próxima RFP. Asegúrese de que no puedan, haciendo que su oferta sea confidencial.
• Sugiera un proyecto de alcance a presupuesto. Proporcione una prueba de concepto muy claramente definida para mostrarles lo que vale. Una vez que se establezca la confianza, se darán cuenta de que vale la pena y ya no les importará el presupuesto.
• Simplemente haga su alcance para ellos, basado en una simple conversación sobre objetivos comerciales + presupuesto disponible. Por supuesto, esto requiere más esfuerzo de ventas, mientras que es posible que aún no ganes el proyecto.

Estamos muy a menudo en esta situación en nuestra empresa. Pero así es como trabajamos.

Nuestra fortaleza no es exigir detalles de los clientes, sino crear una propuesta nosotros mismos: lo que proporcionaremos al cliente con su dinero. Uso de un enfoque ágil, incluso en contratos de precio fijo.

Lo que hacemos esencialmente es lo siguiente:

1. Averiguar los principales problemas de los objetivos comerciales del cliente.
2. Cree una estimación PERT para todos los objetivos del proyecto (divididos en entregables de alto nivel).
3. Asegúrese de que haya alguna solución que se ajuste al presupuesto del cliente. Simplifique cualquier entrega que necesite para cumplir con el presupuesto, por ejemplo, descargando CSV en lugar de informes completos. Asegúrese de que aún pueda satisfacer a su cliente, si aún resuelve su problema comercial.
4. Proporcione la mayor cantidad de suposiciones junto con los entregables que pueda, es decir, describa lo que va a entregar. Le ayudará a negociar el cambio de alcance durante el transcurso del proyecto.
5. Crear cronograma que tendrá fechas aproximadas para la entrega de los entregables. Especifique los requisitos detallados solo para un par de los primeros.
6. Algo importante: cuando se acerque al inicio del próximo entregable, comience a especificar sus detalles y negocíelos con el cliente. Si descubre que el cliente quiere algo más grande de lo que presupuestó, dígale: consideró menos presupuesto para ello, por lo que ahora hay dos opciones:
   1. Para apegarse a la versión original del entregable, o
   2. Hacerlo más grande, pero para simplificar aún más los entregables, para cumplir con el mismo costo total al final del proyecto.

Hay algunos otros trucos que puede utilizar, pero estos son esenciales tanto para evitar hacer una costosa planificación inicial, como para poder resolver el problema del cliente a precio fijo.