Todo es acerca de proceso y gestión de las expectativas y muy poco que ver con la técnica. El error (imho) que la mayoría de los clientes cometen -particularmente con consultorías más pequeñas- es que optan por un contrato de precio fijo (posiblemente con el soporte facturado T & M: tiempo y materiales). Lo hacen como un ejercicio de gestión de riesgos, por lo que es comprensible.
El problema es que están pagando por ese riesgo menor de tres maneras:
- Usted paga una prima por riesgo menor. Este es un principio fundamental que es tan cierto en el desarrollo de software como lo es en los mercados financieros;
- Tanto riesgo se puede poner en el desarrollador (es) que el costo aumenta astronómicamente, lo que beneficia precisamente a nadie (bueno, beneficia al desarrollador hasta que las cosas va mal catastróficamente, que casi siempre lo hacen con el tiempo); y
- Pasas tanto tiempo desarrollando una especificación y formalizando los entregables y los criterios de aceptación que te olvidas al hacerlo, así que acabas de gastar $ 300k escribiendo un documento Word de 300 páginas en lugar de, ya sabes, codificando algo.
Todo esto sirve para que el resultado final más caro para el cliente, desmotivación para el desarrollador (que quiere escribir 300 documentos de página de Word? En serio!) Y se retrasa el cliente realmente conseguir cualquier cosa (lo que aumenta la riesgo de fluencia del alcance, que es directamente proporcional a la duración del proyecto).
Ambas partes a menudo serían mejor atendidas tomando el enfoque T & M combinado con alguna forma de metodología de prototipado rápido con entregables regulares o demostraciones al cliente con no más de 4-6 semanas de diferencia. Esto va hacia la gestión de las expectativas.Si el cliente puede ver que algo está sucediendo, lo tranquiliza y le permite continuar con el trabajo (en lugar del tiempo pendiente en las reuniones que pasan por las tablas GANTT).
Entonces, lo que debe hacer es tratar de convencer a su cliente para que adopte un enfoque gradual (pasos de bebé) donde puedan ver lo que están obteniendo, cómo está evolucionando y participar en el proceso. Obtiene resultados más rápidos y, en última instancia, es más económico (ambas partes comparten la carga del riesgo).
Una cosa que muchos desarrolladores también parecen olvidar es que son como súbditos reales en el siglo XV en Francia. Pueden tener privilegios, incluso riquezas, y muchos perqs, pero sirven al placer del rey (o reina), que puede decapitarlos por capricho. Con esto quiero decir que el cliente finalmente ejerce el poder y usted, como desarrollador, existe para hacer su vida más fácil y no al revés.
Si el cliente quiere un sitio web rosa y verde desarrollado en Cobol on Rails que se ejecuta en un servidor Vax/VMS virtual en el iPhone del jefe, eso es lo que obtiene. Ahora puede usar su experiencia y experiencia para tratar de convencerlos de que no es una buena idea pero, en última instancia, si eso es lo que quieren, tiene dos opciones: dárselas o caminar.
Demasiados desarrolladores caen en la trampa de dar a las personas lo que creen que deberían tener, no lo que piden. GRAN ERROR. Parte del proceso consiste en mantener abiertos los canales de comunicación con el cliente, de modo que no se desplace en una tangente pensando que quiere algo (o que decida que debería tener algo) cuando esperan algo completamente diferente.
Incluso un pequeño proyecto de desarrollo de software puede ejecutarse fácilmente en 6 figuras. Esto es típicamente una gran inversión para quien lo está pagando. Tienen derecho a estar nerviosos y usted tiene la responsabilidad de hacerlos felices.
almohada hablar ... me gustaría tener clientes como ese – inspite
jajaja - mi fuente para esto es (creo que es la página 200) de refactorizar tu wetware de la estantería pragmática –