¿Qué criterios se deben considerar al decidir hacer un trabajo que va más allá del alcance del proyecto?

Tenga cuidado con superar las expectativas basadas en 'tener tiempo para hacerlo'. He estado del lado del cliente en este comportamiento y mi reacción no fue la que esperaba el equipo. Si me hubieran dado a elegir, habría pedido un uso completamente diferente del tiempo. El equipo no solo no superó mis expectativas al decidir lo que podía hacer, sino que no cumplió mis expectativas debido a sus acciones.

Mi sugerencia es darle al cliente las opciones. Recuerde, es posible que estén más contentos con la entrega anticipada, en lugar de tener lo que usted determina que es un valor 'extra'.

Tema complicado porque muchos proyectos giran en torno a las expectativas del cliente, que a menudo no coinciden con las especificaciones escritas.

Podrías entregar el producto central temprano y preguntarle al cliente qué áreas le gustaría mejorar.

Podrías adivinar y producir algo que se extiende en áreas que crees que son importantes.

¡Podrías entregar antes de tiempo!

Podría mostrarle al cliente lo que ha hecho y luego el cliente bien podría señalar que tenía expectativas diferentes de las secciones 2, 3, 6 y 7, y ¿podría volver a trabajarlas?

Recuerdo haber leído un estudio de caso sobre el proyecto de interfaz de usuario del iPhone, en el que decidieron superar las expectativas en áreas que harían que el teléfono pareciera especial, como la pantalla táctil y acercar/alejar el zoom, pero casi ignoraron elementos monótonos como cortar y pegar, y eso fue lo que condujo a los enormes índices de aprobación.

Entonces, si va a superar las expectativas, vale la pena considerar la ventaja del iPhone.

Diría que en cualquier escenario debería haber alguna ganancia para usted o para el cliente y posiblemente para ambas partes.

Algunas ideas a tener en cuenta que se me ocurren:

• Según el tipo de proyecto, puede agregar algo que agrade al cliente pero que también mejore su producto para implementaciones futuras. No solo debe considerar esta implementación específica, sino también las posibles futuras.

• Otro factor a considerar es pagar parte de la deuda técnica . La gran mayoría de los proyectos que conozco incurrieron en al menos alguna deuda técnica y tal situación es una buena ocasión para hacer algo al respecto. Por lo general, paga en términos de costo de mantenimiento.

• Esto me lleva a otra cosa: hay algunas características que reducen la carga y el costo de mantenimiento, siendo las actualizaciones automáticas el ejemplo más obvio aquí. Por lo general, son beneficiosos para todos, lo que los convierte en buenos candidatos para considerar en tal escenario.

Solo tenga en cuenta que todo lo que entregue que exceda las especificaciones y, por lo tanto, un contrato existente, no se puede vender y probablemente nunca obtendrá dinero por ello.

Voto no en esto en la mayoría de las circunstancias, si no en todas. Esto corre demasiado cerca de la línea de desplazamiento del alcance. Los proyectos terminan antes o después de los objetivos todo el tiempo, secundarios a nada más que eventos aleatorios. La mayoría de las veces, terminamos más tarde debido a nuestra extraña habilidad de estimar de manera demasiado optimista: falacia de planificación. Si termina temprano, capture la varianza favorable y continúe según lo planeado porque probablemente necesitará la holgura más adelante cuando comience a sobrepasar un paquete posterior.

Bueno, creo que es un caso perfecto para la gestión de proyectos de estilo Agile. Si está operando de manera ágil, entonces tiene algunas cosas.

1- Cuando el proyecto, tal como está definido, esté terminado, puedes enviarlo. 2- Te estás comunicando con el cliente regularmente. Esto les permite ajustar lo que quieren. No habrás terminado y preguntándote si deberías agregar más, el cliente te lo dirá. 3- Con una cartera de pedidos bien definida y ordenada, puede alcanzar fácilmente los siguientes elementos de la cartera de pedidos.

Para ser mi propio abogado del diablo, debe tener mucho cuidado con lo que envía, si será utilizado por un consumidor externo. Si agrega una docena de funciones nuevas a su base de datos y nadie le informa al servicio de atención al cliente al respecto, intentarán respaldar un producto que no conocen. Esto solo enfatiza la necesidad de una comunicación total del equipo. Incluso en un proceso de desarrollo Agile, puede tener grupos como atención al cliente listos para usar en el momento del envío.