Estimación del proyecto con requisitos crecientes

Hacer una estimación del proyecto con un conjunto de requisitos dado es una cosa.

Pero, ¿qué sucede cuando el usuario de repente comienza a cambiarlos sobre la marcha y comienza a agregar nuevos requisitos al conjunto ya definido? E incluso llega a enojarse por qué el proyecto no está terminado en el plazo planificado originalmente.

¿Cómo debo lidiar con estas situaciones? Proponer algunas metodologías y lecturas podría ser útil.

Debe dejar claro al cliente que los cambios en los requisitos también son cambios en el alcance y proporcionar actualizaciones a las estimaciones. cada vez que haya un cambio en los requisitos.

Las estimaciones del proyecto se llaman estimaciones por una razón. No son promesas. Si el cliente quiere hacerles promesas, es un trato diferente; ahora tiene que proporcionar estimaciones mucho más grandes que tienen una mayor probabilidad de éxito, utilizando congelados requisitos .

La mayoría de las estimaciones de proyectos proporcionan un cierto nivel de relleno, en cualquier lugar desde el 20% al 100% de prima de tiempo (o más) sobre una estimación ideal. Asegúrese de que sus estimaciones incluyan este relleno.

Existen metodologías ágiles que proporcionan una mejor visibilidad para el cliente, de modo que puedan tener una mejor idea del esfuerzo involucrado y de cómo sus cambios están afectando los plazos.

Debe actualizar las estimaciones cuando actualizan los requisitos y tener una especificación definida de lo que el cliente aceptará como "hecho". "Mi estimación anterior era para el conjunto de funciones X, Y. Si desea que agregue Z, calculo que extenderá la fecha de entrega en ...", etc.

Debe comunicar formalmente el impacto en el cronograma y el costo al cliente y a la administración al cambiar los requisitos o agregar nuevos. Haga su mejor esfuerzo para imponer un mecanismo de aprobación formal para que piensen profundamente antes de pedir algo nuevo o cualquier cambio. De lo contrario, seguirá escuchando "Quiero que agregue XYZ" y luego "¿Dije XYZ que quise decir ABC".

Piense en su proyecto como un triángulo (un amigo mío de PM realmente hizo un triángulo físico que usó para un efecto adicional). Los bordes se llaman tiempo , costo y alcance . Le dice a su cliente que puede tener el control de 2 lados, pero usted (responsable de la entrega) debe tener el control de al menos uno.

Por lo tanto, puede hacerlo rápido y barato, pero luego debe tener el poder de reducir el alcance.

O bien, puede obtener más funciones, pero eso requerirá más tiempo o más dinero.

Lea más en http://en.wikipedia.org/wiki/Project_triangle

Puede intentar implementar Scrum , una metodología ágil que, según su situación, podría ser muy útil.

De Wikipedia:

Scrum es un esqueleto de proceso que contiene conjuntos de prácticas y roles predefinidos. Los roles principales en Scrum son:

1. el "ScrumMaster", que mantiene los procesos (generalmente en lugar de un gerente de proyecto)
2. el "Propietario del producto", que representa a las partes interesadas y al negocio
3. el "Equipo", un grupo interfuncional de aproximadamente 7 personas que realizan el análisis, diseño, implementación, prueba, etc.

Durante cada "sprint", típicamente un período de dos a cuatro semanas (con la duración decidida por el equipo), el equipo crea un incremento de producto potencialmente enviable (por ejemplo, software de trabajo y probado). El conjunto de características que se incluyen en un sprint proviene del "trabajo atrasado" del producto, que es un conjunto priorizado de requisitos de alto nivel de trabajo a realizar. Los elementos atrasados ​​que van al sprint se determinan durante la reunión de planificación del sprint.

No se trata de metodologías, sino de comunicación con un cliente.

Tuve muchas situaciones en las que los clientes querían agregar constantemente nuevas características a un proyecto no terminado, y me sorprendió por qué aumentaría el costo general y las demoras. El contexto y la personalidad de esos clientes eran diferentes, requería diferentes enfoques, pero puedo tratar de aislar algunas pautas y consejos:

• Asegúrese de que un cliente tenga acceso a la información general requerida para comprender por qué un cambio en un requisito puede afectar tanto el costo como la demora . En otras palabras, publique algunos artículos sobre esas cosas, explicando lo que una persona no técnica puede no saber en absoluto.

Por ejemplo, para la mayoría de las personas, es totalmente extraño que un cambio que consideran pequeño pueda tener un gran impacto en el proyecto y ser muy costoso (ver ejemplo en mi pregunta ). Si solicitan hacer algunos cambios, y cada vez que les dices, sin explicarles nada, que tendrían que pagar miles de dólares cuando lo esperaban gratis o por unas pocas docenas de dólares, probablemente pensarían que eres solo robando su dinero. Esto es especialmente cierto ya que algunos programadores poco éticos y compañías de software desarrollan productos que no se pueden mantener (por lo que no puede pedir que un desarrollador normal lo cambie más tarde), luego le piden que pague demasiado por cada modificación.

• Asegúrese de que un cliente haya entendido por qué el cambio específico que desea tiene un impacto en un costo . Para eso, puede darle los enlaces a sus artículos (ver el punto anterior), o simplemente resumir, de manera no técnica, lo que se requiere para realizar un cambio solicitado.

Dichas explicaciones también son una buena idea, ya que permiten que su cliente comprenda mejor el producto y el cambio. En algunos casos, algunos de mis clientes terminaron diciendo que el cambio que querían no era demasiado inteligente y que lo harían de otra manera. También puedes sugerir cosas. Algunos clientes lo aprecian mucho (advertencia: otros lo odian) y muestra que sabes de qué estás hablando (en comparación con el mono de código que solo traduce los requisitos en código, sin pensar demasiado en los posibles enfoques) .

• Asegúrese de que un cliente no pueda hacer lo que quiera, a menos que esté realmente segura. Para algunas personas, la única forma es bloquear los requisitos definitivamente antes de comenzar a codificar . De lo contrario, es un desastre y el proyecto nunca terminará . Para otros, es una buena idea nunca ver un proyecto sin terminar (en general, mis clientes tienen acceso en vivo al producto sin terminar muy temprano, para que puedan hacer comentarios / ajustes también temprano).

Por ejemplo, tuve un cliente que, después de enviar requisitos "finales", envió, en promedio, diez correos por día con diez cambios de requisitos, pasando por modificaciones menores ("¿Puede cambiar el ancho del borde de la zona central en la página de inicio? ¿de tres a seis píxeles? ") a los cambios que afectaron todo el proyecto (después de dos meses de desarrollo, una semana antes del lanzamiento:" Finalmente, creo que ASP.NET es una mala idea. ¿Podría cambiar a PHP por favor? " )

Entonces, para ese cliente , nos vimos obligados a bloquear todos los requisitos antes de escribir el código. Fue escrito en el contrato. No se aceptaron cambios antes del lanzamiento final.

Finalmente, no fue tan malo, ya que curiosamente nos permitió ser muy organizados: el proyecto se lanzó de acuerdo con los requisitos anteriores, y luego, unos días después, comenzamos la próxima versión desde cero con un conjunto completamente diferente de requisitos.