¡Nuestro equipo terminó nuestro proyecto antes de la fecha límite! ¿Ahora que?

Tengo 1 proyecto debajo de mí y parece que estamos adelantados en esto. Le dijimos al cliente que el proyecto se completará en un mes y el desarrollador lo completó en 2 semanas. ¿Qué debes hacer en esta situación?

Respuestas (5)

¡Empieza con un máximo de 5! :)

Reúnase con su cliente. Hágales saber que cree que ha completado la función y ofrézcales una demostración. Pregúnteles si cumple con sus criterios de aceptación. Mi apuesta es que el cliente tendrá algunos ajustes o cambios ahora que lo ha visto. Al regresar a ellos de inmediato, tiene la posibilidad de que estos cambios se puedan realizar sin afectar la fecha de entrega final del cliente.

La comunicación frecuente con el cliente asegurará que va en la dirección correcta y permitirá cambios a medida que interceda la realidad.

Y si realmente has terminado, entonces celebra. El éxito es algo que hay que reconocer.

+1 por devolvérselo al cliente. Es raro que construyas exactamente lo que querían. Solo porque creas que lo tienes resuelto, no significa que lo tengas. Y si realmente ha terminado antes, una demostración como esta les da la oportunidad de comenzar a usarla antes, solicitar funciones adicionales o simplemente pagar menos de lo esperado (si están pagando una tarifa por hora).
El cliente no está en la ciudad. Están ubicados lejos...
WebEx! Por lo menos, dígales "Hemos terminado" y vea qué quieren hacer a continuación.
@Joel, dejaría que el cliente decida si ha terminado. Es posible que vean la demostración y decidan que no cumple con sus requisitos. +1, sin embargo, por sugerir reunirse con el cliente para pedirle su opinión. Si están contentos con el alcance y con la entrega anticipada, esto podría generar "puntos brownie" adicionales.
@John: Joel prácticamente lo señaló como una de las razones para hacer un seguimiento con el cliente. "Mi apuesta es que el cliente tendrá algunos ajustes o cambios ahora que lo ha visto". y "La comunicación frecuente con el cliente le asegurará que va en la dirección correcta..." +1
@ jmort253 Sí, de acuerdo. Mi comentario se refería al comentario de Joel, deberían decirles "Hemos terminado". En mi opinión, si alguien está listo o no, es al final la decisión del cliente, no la decisión del desarrollador. Pero, de nuevo, puede haber otros factores.
@john - Buen punto. Creo que Joel lo entiende, y creo que tú lo entiendes, pero tal vez ese sea un buen punto para que Joel lo aclare en la respuesta para que nadie lo malinterprete. :) Por supuesto... Joel no usó específicamente las palabras "Terminaste". Esas son tus palabras ;)
@ John- Muy buen punto. Las palabras son muy poderosas y debemos tener cuidado con ellas, no sea que nos lleven por un camino oscuro. Decir "Terminamos" es probablemente un poco brusco y podría dar lugar a malos resultados si no es así. Algo más como "Según nuestro entendimiento, hemos completado la funcionalidad, ¿cumple con sus requisitos?" Por supuesto, si tienes criterios de aceptación sólidos, lo sabrás.

Me haría eco de la respuesta de Joel sobre consultar con el cliente y también sobre el pulido.

Sin embargo, algunos otros pensamientos, en las líneas de "¿estás seguro de que has terminado?":

Tienes un proyecto de un mes, desarrollado en 2 semanas. ¿Existe algún plan para probar el software que se ha desarrollado? Ya sea desde el punto de vista de la funcionalidad u otros aspectos menos visibles, por ejemplo, rendimiento bajo carga, seguridad, usabilidad, accesibilidad, etc.

¿Se comprende y se prueba el método de implementación? Si es un software que se ejecutará en la PC del cliente, ¿ha sido instalado y probado en PC que no sean las de los desarrolladores para demostrar que no hay dependencias desconocidas?

¿Están planificadas las pruebas de aceptación del usuario o las pruebas de usabilidad? Esto puede eliminar necesidades o problemas inesperados.

Creo que, dependiendo de los elementos del cliente, como los anteriores, puede ser un mayor esfuerzo que el desarrollo real.

Sin ofender, ¡pero parece algo demasiado bueno para ser verdad! ¿Entendiste claramente lo que preguntaron tus clientes? ¿Te perdiste una parte? Siento ser un escéptico, pero normalmente tienes mucho más trabajo del que puedes manejar. A menos que lo hayas planeado mal al principio. Llamaría a tus clientes lo antes posible para validar con ellos si lo que hiciste se corresponde con lo que te pidieron. Si es así, ¡enhorabuena! Pero no esperes dejar algo así cada vez.

Creo que este es un gran punto. Es muy posible que el proyecto aparentemente se completó temprano simplemente porque el equipo no entendió el requisito. +1
Es muy posible que se trate de un error de planificación; después de todo, la variación va en ambos sentidos. Solo porque la industria de TI generalmente subestima, a veces también puede sobreestimar. A veces piensas que algo podría ser difícil y permitir la contingencia, pero resulta que el desarrollador ha hecho algo similar antes, o encuentra componentes reutilizables que aceleran las cosas y todo se hace antes de tiempo.
@Kris: de cualquier manera, el equipo no debe sacar el champán hasta que hable con el cliente y esté de acuerdo en que se completó. Sin embargo, estoy contigo, a veces sucede que algo realmente se hace.
acordado :) los criterios de aceptación y aprobación son importantes. Mencioné las pruebas de aceptación del usuario en mi respuesta: ¡espero que las pruebas y la aprobación del usuario se realicen antes de que el software se entregue formalmente y el pago final importante cambie de manos!

Pulir, refinar y entregar algo más allá de sus propias expectativas y estándares de calidad. Fácilmente podría pasar otra semana o dos probando y mejorando (sin agregar funciones no solicitadas) cada pequeño detalle y aún así entregarlo antes de tiempo. Por ejemplo, probar en plataformas/navegadores adicionales, corregir errores que pueden haber sido aceptables antes, ejecutar herramientas de validación adicionales, etc.

¿Qué pasa si la funcionalidad no es lo que el cliente realmente quería? ¿Qué pasa si el cliente se ha dado cuenta de que no explicó todas sus funciones? Tiene la oportunidad de ponerse en contacto con su cliente, tómela. Mi opinión.
Creo que es una buena idea Joel. Gracias, lo tendre en cuenta.
@simpixelated: aquí es de donde proviene el término 'chapado en oro'; agregar cosas que no se pidieron, y es la otra cara de la fluencia del alcance. Si completó el proyecto de acuerdo con las especificaciones y los requisitos de los clientes, continuar trabajando en él más allá de eso es simplemente gastar su dinero sin una buena razón. Lo que está defendiendo también trae consigo un problema de riesgo: ha terminado y está listo. Pero ahora agrega o cambia algo (sin autorización) y lo rompe y tiene que dedicar más tiempo para arreglarlo, y posiblemente poner en peligro la fecha de finalización.
"Fácilmente podría pasar otra semana o dos probando y mejorando (mi énfasis) cada pequeño detalle y aun así entregar a tiempo". Parece que @simpixelated solo sugiere que el equipo se asegure de que la calidad esté ahí, que no haya defectos importantes y que se solucionen los errores menores. Entiendo que "bañado en oro" implica agregar funciones que no se solicitaron, mientras que esto me parece que solo está sugiriendo que se tome el tiempo para asegurarse de que todas las i estén punteadas y las t cruzadas, algo así como volver a leer una propuesta + corregir errores antes de enviarlo. +1
@JMort - podría ser. Fue su uso de "más allá de las expectativas" lo que me llevó a un baño de oro. Pero es posible que tu lectura haya sido mejor que la mía. Gracias por la perspectiva diferente. +1
@Trevor: aún así, tal vez uno de nosotros debería editar esta respuesta solo para dejar en claro que "más allá de las expectativas" no significa volverse loco y comenzar a agregar funciones aleatorias. Creo que vale la pena señalar específicamente que este tiempo solo debe usarse para una revisión cuidadosa y corrección de defectos. Si usted y Joel no entendieron bien, es muy posible que muchos otros también lo hagan :)
Definitivamente no estaba insinuando nuevas funciones, así que me alegro de que se haya aclarado. Estaba más pensando más allá de las expectativas de sus propios estándares. También me gusta mucho la idea de Joel de contactar al cliente para asegurarte de que lo que has hecho es lo que esperaban.
@ jmort253 Niza respondió.
@simpixelated: ¿puede actualizar su respuesta para que quede más claro que no quiere decir comenzar a agregar funciones aleatorias? Gracias por el seguimiento.
Creo que esta respuesta es un buen ejemplo de la Ley de Parkinson.

¡Felicidades! Y pásalo al equipo. Específicamente, lleve al equipo a una celebración; alimentación y/o actividad. si es posible, considere darles un bono.

No pretenda que el proyecto no ha terminado; esa es una forma segura de desmoralizar al equipo.

A menos que haya una buena razón para no hacerlo, informe al cliente que está listo para entregar, y haga un gran problema con la entrega anticipada. Después de todo, quieres que el equipo repita esta hazaña.

No empieces a añadir funciones, por triviales que sean. Si está probado y aprobado, envíelo. Agregar incluso la característica más pequeña podría causar grandes retrasos; si no está roto, no lo arregles.

No aprietes el próximo calendario suponiendo que tienes un Súper Equipo . Eso es equivalente a castigarlos por hacer un gran trabajo.

¡Nuestro equipo terminó nuestro proyecto antes de la fecha límite! ¿Ahora que?
RespuestasAquíPolítica de privacidad1y, 0v