¿Cómo gestiona a los clientes con respecto a los requisitos cambiantes?[cerrado]

Question

La sabiduría de Steve Yegge No obstante, la mayoría de los desarrolladores se enfrentan a requisitos que se obtuvieron de clientes no técnicos.A veces hay jefes de proyecto que tratan con los clientes y traducen sus necesidades, otras veces no.En cualquier caso, el hecho de que los requisitos cambien es inevitable.

La mayor parte de lo que constituye una "buena práctica de programación" tiene que ver con desarrollar sistemas que sean adaptables para que puedan soportar los cambios de requisitos.Principios como YAGNI, DRY, acoplamiento flojo, etc.contribuir a esto.Los procesos de desarrollo iterativos como Agile también intentan abordar la preocupación de intentar alcanzar un objetivo en movimiento y, por supuesto, tener un sistema bajo prueba hace que sea infinitamente más factible realizar cambios.

Sin embargo, parece que para muchos de nosotros los cambios en las necesidades no sólo pueden dañar la calidad de nuestro software, pero también puede agotar nuestra motivación y hacernos querer apuñalar a alguien.

Esta pregunta es sobre cómo gestionar el cliente para permitirles cambiar sus requisitos en la forma que necesiten, desalentando al mismo tiempo los cambios arbitrarios o frívolos.¿Cómo lo haces?

• ¿Tiene gerentes de proyecto para aislar a los desarrolladores del cliente?
• ¿Tiene un proceso formal de gestión de cambios?¿Cambiar de gerentes?
• ¿Qué tan difícil es para el cliente conseguir un cambio cuando realmente lo necesita?
• Por el contrario, ¿qué tan fácil es para un cliente conseguir un cambio cuando es "frívolo"?
• ¿Cuánto detalle le das al cliente al explicar el costo de un cambio?
• ¿Qué tan rápido puede brindarle al cliente esta información después de recibir una solicitud de cambio?
• ¿Qué factores pueden torpedear el proceso (p. ej. ¿PM's que no pueden decirle que no al cliente?)
• ¿Qué funciona para ti?

Answer 1

Si está buscando el mundo ideal donde el cliente nunca cambia de opinión o obtiene la especificación ideal: está en el negocio equivocado . Dicho esto, el mecanismo más eficaz que he encontrado para gestionar las expectativas de los clientes y las solicitudes de cambio es instituir un sistema preciso de medición.

Así es como dirijo mi equipo:

1) Comenzamos con historias de usuarios. El cliente participa en su redacción y el equipo de desarrollo calcula cuánto tiempo llevará cada historia de usuario de manera relativa.

2) Utilizando la experiencia previa, tomo estas estimaciones relativas (puntos de la historia) y creo un cronograma aproximado de cuándo se completarán los hitos principales del proyecto.

3) Dentro de estos hitos ejecutamos iteraciones de 2 semanas. El cliente está involucrado en establecer los criterios de aprobación y si la historia ha sido aprobada o no. Un simple cuadro de quemado muestra al cliente lo cerca que estamos de alcanzar el objetivo de lanzamiento.

4) A menudo, durante las sesiones de aprobación, el cliente solicitará un cambio porque la función no resultó como la esperaba (aunque cumplió con los criterios de aprobación originales). En este momento generas una nueva historia con una nueva estimación. También puede ajustar sus fechas de hitos de manera adecuada. Esto vuelve a colocar la pelota en la cancha de los clientes:

• Muchas veces se dan cuenta de que su solicitud de cambio no vale la pena (tendrían que obtener la aprobación de su jefe) y eliminamos la nueva función
• A veces es importante, por lo que retrasamos la fecha de vencimiento para que la función aparezca
• Y, por último, siempre existe la opción de eliminar otra característica no tan importante que llevará una cantidad de tiempo equivalente.

La clave no es escapar de las solicitudes de cambio, sino establecer que cada solicitud de cambio tiene consecuencias en el producto. No existe el almuerzo gratis.

Answer 2

Trabajo como desarrollador independiente y, por lo tanto, me contacto directamente con los clientes. Es normal que la mayoría de las veces no tengan idea de lo que realmente quieren. Entonces comenzamos lentamente y les doy un prototipo desde el principio para que jueguen y luego los cambios se realizarán gradualmente. Si creo que los clientes quieren & Quot; frívolo & Quot; cambio, entonces le digo que este cambio no funciona o no es necesario. Si son 5 minutos de trabajo, incluso podría hacerlo de todos modos.

Ayuda agregar más adelante al contrato alguna cláusula de mantenimiento para obtener dinero para esos pequeños cambios que surgirán más adelante. Para cambios más grandes, solo cobra por hora.

Answer 3

Administrar al cliente es difícil, y es algo que muy fácilmente puede salir mal.

Creo que lo antes posible necesita ganarse la confianza del cliente. Para mí, creo que puedes hacer esto:

• Pídale al cliente que designe un gerente de producto , que sea lo suficientemente claro para comunicar los requisitos que desea y busque construir una relación de trabajo sólida con él / ella.
• Realmente intente comprender su negocio : no necesita ser un experto en dominios, pero necesita saber de dónde viene el cliente.
• Haga preguntas pertinentes sobre lo que quieren: no asuma que lo que piden (al principio) es lo que realmente quieren .
• Al principio da la bienvenida a todos los cambios . Este no es el cliente molesto y voluble, es una oportunidad para comprender mejor lo que el cliente realmente quiere. Si esto le cuesta tiempo / dinero, es posible que deba aceptarlo como líder de pérdidas .
• Entregue un prototipo temprano e incorpore tantos comentarios de los clientes como sea posible.
• Ofrezca al cliente un producto increíble .

Una vez que haya hecho esto, y el cliente confíe en usted, podrá comenzar a rechazar los cambios irrazonables o solicitar pagos / tiempo adicionales para cosas que anteriormente se consideraban fuera de alcance.

Por supuesto, no podrá construir este tipo de relación con cada cliente, algunos son idiotas (en este caso, verifique si puede designar un gerente de producto diferente), pero debe siempre haga todo lo que usted pueda para construir una relación de trabajo efectiva.

Answer 4

No puede & # 8217; no puede esperar que los clientes sepan lo que quieren al principio, por lo que debe ser adaptable. Pero también debe detener el cambio por el bien de los cambios.

Esto es para & # 8216; interno & # 8217; clientes.

He descubierto que negociar con el cliente es una forma efectiva de hacerlo. Pueden tener cualquier característica que deseen si la esperan, o si sacrifican otras características (aún por implementar). Esto los obliga a pensar sobre el valor del cambio que solicitan en relación con el sistema en su conjunto.

A veces esto funciona bien y se alcanza un buen compromiso. Otras veces, el cliente tira sus juguetes del cochecito y sube lo alto que tiene que implementar la función y se reduce la calidad.

Si el cliente está pagando, es un juego de pelota diferente. Deben ser conscientes de que los costos de cambio y que el costo aumenta a medida que el producto se acerca a su finalización. Esto significa que tiene que hacer muchos análisis por adelantado sobre lo que entregará y asegurarse de que se acuerde la especificación. Entonces puedes medir lo que ha cambiado. Puede que esta no sea la solución más efectiva para ninguna de las partes, pero mantiene las cosas secas. Por lo tanto, no están insatisfechos y usted no & # 8217; t termina haciendo un montón de trabajo de forma gratuita.

Answer 5

En ingeniería de software, el cambio es solo un hecho. Pasará. Para nosotros, todo tiene un precio. Haremos casi cualquier cambio que los clientes quieran, pero siempre hay una estimación de tiempo y un costo asociado. ¿Alguna vez le decimos al cliente que no? Normalmente no, pero a veces la solicitud de cambios tiene un costo muy alto. Trazamos la línea de las posibles amenazas de seguridad, etc. en cuyo caso les explicamos con calma que no podemos atender la solicitud.

Cuánto le explicamos al cliente, le explicamos dónde se asignará el dinero, tanto para el desarrollo, tanto para el análisis, etc. No les explicamos explícitamente por qué algo cuesta la forma en que lo hace. Ahora admito que esto varía un poco con algunos de nuestros clientes. Algunos de ellos obtienen una facturación muy detallada sobre exactamente cuántas horas se gastan dónde. Para obtener el contrato tuvimos que aceptarlo, aunque esto es muy raro para nosotros.

Tenemos vendedores que no pueden decir que no a veces, y eso puede causar problemas. Hemos pasado mucho tiempo trabajando en eso, pero desafortunadamente todavía surge. Lo combatimos explicando cuánto dinero nos cuesta citando algo sin investigar lo que costará. La transparencia es clave en todos los niveles. Todos deben saber cómo sus decisiones afectan el resultado final.

¿Hacemos cambios frívolos? Sí. Lo que debe recordar es que cuando factura por hora la mayor parte del tiempo, un cambio de 5 minutos se factura a una hora completa, por lo que es bastante lucrativo. Explicamos todo esto antes como lo hacemos con cualquier solicitud de cambio para que lo sepan, pero tiende a ayudar a desalentar tal comportamiento a menos que sea realmente importante. El hecho es que tratamos todos los cambios de la misma manera. No asumimos que sabemos lo que se considera frívolo para ellos, no importa cuán absurdo pensemos que podría ser. Tenemos un proceso de cambio formal en el que el cliente solicita algo, lo escribimos y lo firmamos, eso es lo que evaluamos y presentamos un Costo de trabajo estimado. O bien acuerdan en qué caso firman formalmente un documento para informarnos que está bien comenzar, o rescinden la solicitud. Intentamos ser diligentes, pero les hacemos saber que nos llevará unos días obtener una respuesta a su solicitud.

Un compañero de trabajo mío me dio el mejor consejo que he escuchado sobre la gestión de las relaciones con los clientes. Es un toma y daca. Para hacer feliz al cliente, debe estar dispuesto a ayudarlo cuando necesite algo, pero al mismo tiempo, debe poder decir que no. Cuando tratan con personas, quieren que les ayudes, pero también quieren que tengas una columna vertebral y te defiendas. Se convierte en una situación de ganar-ganar de esa manera.

Answer 6

Preferiría un término de requisitos en evolución a "requisitos cambiantes".Profesor MMLehman (http://www.doc.ic.ac.uk/~mml/ y http://en.wikipedia.org/wiki/Meir_Manny_Lehman) ha hecho una contribución considerable a la investigación sobre la evolución del software;sus trabajos también sugieren que no todos los tipos de requisitos evolucionan.Uno podría considerarse afortunado si trabaja en uno de estos sistemas, donde los requisitos siguen siendo los mismos (es decir,bibliotecas de matemáticas, etc.).

Para el resto de nosotros, la experiencia sugiere que los desarrolladores prefieren la mayor cantidad de información posible sobre los requisitos desde el principio, mientras que los clientes o usuarios finales valoran la capacidad de especificar o ajustar los requisitos lo más tarde posible en el proceso de desarrollo.Los primeros necesitan información detallada para ayudar a planificar y diseñar la solución, los segundos pueden obtener una ventaja estratégica al cambiar un requisito tarde, porque le da al cliente cierto margen de maniobra para responder al entorno cambiante o a la información obtenida como resultado de la solución. etapas / iteraciones anteriores del proyecto.Un equilibrio entre la capacidad de tener un plan detallado y cambiar las cosas determina en gran medida el proceso de desarrollo en sí (en cascada, ágil, en espiral, etc.).

Algunos consejos prácticos para gestionar la evolución de los requisitos:

• Cree algo de espacio en el plan inicial para tener en cuenta la evolución de los requisitos, los múltiples puntos de control o las iteraciones.

• Coloque requisitos volátiles al comienzo del proyecto para que algún tipo de prototipo o estudio de factibilidad pueda aclararlos o planifique el cambio en una etapa avanzada del proyecto.

• Supervisar que los requisitos sigan siendo relevantes.

• Tenga a mano una lista actualizada y priorizada de los requisitos actuales.Nada más ayuda a mantener la evolución bajo control que una buena visibilidad para todas las partes interesadas de los “imprescindibles” actuales, incluidas su prioridad y costo relativos.

• Siga gestionando las expectativas de los clientes sobre cuánto tiempo llevarán las cosas;esto también ayuda a mantener la concentración.

• Introduzca un proceso formal para cambiar o agregar requisitos si es necesario.La descripción del proceso debe especificar las funciones de los involucrados, la frecuencia de las revisiones, etc.Podría servir como una buena salvaguardia contra algunos requisitos políticos y muy oportunistas pero no esenciales.

• Dedica algo de tiempo para refactorizar incluso la primera versión.Es muy probable que descartes toda o parte de la solución como resultado de la adquisición de conocimientos adicionales durante el desarrollo.

Answer 7

El cliente acude a usted para hacer algo porque no tiene tiempo para hacerlo o no sabe qué hacer (y quiere pagarle para que lo haga por ellos) . Si tiene requisitos cambiantes, es por esto último. En otras palabras, ¡te están pagando para que descubras los detalles! Y saben lo que les gusta y no les gusta, pero no sabrán cómo funciona.

Reconozca esto y cualquier cosa que necesite ser la solución se encuentra en su lugar.