Estimación del proyecto con requisitos crecientes

8

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.

TheBoyan
fuente
2
Esto se puede pedir mejor en pm.stackexchange.com
Bill the Lizard
66
Esto se conoce comúnmente como fluencia del alcance.
P.Brian.Mackey
2
Las metodologías son inútiles aquí. Es necesario aclarar que los cambios en los requisitos tienen un costo, y ese es un problema de relaciones con los clientes. Algunas metodologías son mejores que otras para manejar los cambios, pero ninguna manejará el desplazamiento del alcance sin costo adicional a tiempo.
David Thornley
tiempo * = requisitos ++;
Aditya P

Respuestas:

11

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.

Robert Harvey
fuente
No veo cuán ágil ayuda. De hecho, lo más probable es que obstaculice la visibilidad ya que la fecha de finalización del proyecto es más difusa. Mientras que un enfoque más en cascada dirá, seguro que si agregamos estos requisitos, agregará 3 meses al cronograma y X dólares al costo.
Dunk
1
@Dunk: Lo que quiero decir con visibilidad es la capacidad del cliente de "ver" cómo sus cambios están impactando el proyecto. La visibilidad no es una promesa; Es solo una política de puertas abiertas. Cascada no garantiza buenas estimaciones. En todo caso, cascada debe insistir en que el cliente no realice ningún cambio, si las estimaciones son útiles.
Robert Harvey
1
Agile le da al cliente la ilusión de estar al tanto, lo que a su vez le da una idea del impacto que sus requisitos cambiantes pueden tener en el ciclo de desarrollo. Como tal, puede ser una herramienta para enseñar a los clientes una lección sobre lo que su actitud puede hacer a un proyecto.
Jwent
6

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.

Daenyth
fuente
4

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".

M.Sameer
fuente
¿Algún recurso / lectura sugerido, experiencias compartidas sobre este enfoque formal?
TheBoyan
1
Lo que quiero decir es hacer lo siguiente: (1) Pida que una persona (puede ser por tema) actúe como proveedor de requisitos. (2) Aceptar solo solicitudes por escrito. Si recibe una solicitud por llamada telefónica o comunicación verbal o reunión, debe escribir las actas y los requisitos y decir claramente lo que va a hacer y enviarlo por correo electrónico o formato escrito e incluir el tiempo extra necesario. (3) al informar a su líder técnico, indique las áreas afectadas de la aplicación para que pueda aconsejarle sobre un mejor enfoque o apoyarlo en su decisión.
M.Sameer
1
(4) Si recibe solicitudes en formato escrito pero no están organizadas o no están claras, puede proponer plantillas para Solicitudes de cambio. (5) Lleve un registro de todas las solicitudes de cambio porque es muy importante que el gerente de proyecto sepa la inestabilidad de los requisitos. Si lo desea, puede leer sobre Definición y gestión de requisitos, Gestión del cambio y CMMI.
M.Sameer
3

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

papilla
fuente
2

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.

Harima555
fuente
1
Un proyecto más grande probablemente tomará más tiempo, scrum o no scrum. Es probable que Agile facilite el intercambio de funciones y facilite la entrega de algo útil si se impone una fecha límite repentinamente. No detendrá el arrastre de características.
David Thornley
2

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.

Arseni Mourzenko
fuente