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.