Es molesto pero no muy raro. Situaciones similares me ocurrieron alrededor de 5 o 6 veces en mi carrera. Trabajé en TI más de 30 años, de ahora en adelante no es tanto, pero conozco a otras personas que se encuentran con estos casos con mucha más frecuencia.
Si tiene una buena relación con su cliente y tiene la intención de mantenerla así, lo mejor es ser sincero y hacer que ese problema no solo sea suyo sino también suyo. Y no debe esperar, darle el comentario tan pronto como esté limpio con los problemas suele ser el mejor curso.
¿Dices que no has realizado un análisis lo suficientemente profundo? Eso simplemente demuestra que te sientes culpable. Pero si su equipo necesitó dos semanas para darse cuenta de que había un problema, es probable que este problema no fuera obvio. El tiempo invertido podría verse como un tiempo de estudio del proyecto, y en proyectos de software complejos que a veces se venden. No te sientas culpable. Es parte del trabajo.
- ¿Hacer que las aplicaciones IOS en javascript sean algo común? ¿O es algo que se puede lograr, pero que no es ideal para las aplicaciones IOS?
- Cómo escribir un código de calidad
- ¿Qué quiere decir Alan Kay con 'negociar significado' entre 2 servidores de comunicación? (oponiéndose explícitamente al concepto de API)
- ¿Cuáles son algunos de los principales desafíos al diseñar sistemas distribuidos y cuáles son las soluciones más populares?
- ¿Cómo utiliza DevOps los bucles de retroalimentación?
¿Su cliente espera algún software que no pueda entregar? Probablemente quiera ese software para algún propósito. El propósito es lo que probablemente sea importante para él, no el software real. El software descrito es simplemente una posible solución a un problema específico, pero generalmente no es el único.
El modo de seguir depende de los detalles de la imposibilidad técnica que haya visto.
Si lo que pretende lograr simplemente no es posible sea cual sea el software (es decir, implicaría enviar alguna señal más rápido que la luz o restricciones similares). Tienes que decirle y definir con él otro objetivo más accesible. O incluso simplemente detenerse allí para este proyecto y comenzar con algo completamente diferente.
– si el objetivo es alcanzable, pero no en la forma en que se definió inicialmente (o implica una cantidad prohibitiva de trabajo), también debe informarle y redefinir un objetivo más accesible.
En realidad, es un flujo de trabajo bastante normal en metodologías ágiles. Define una imagen grande con su cliente y algún hito (iteración) cuando se sincronizará con él. Cuando se alcanza el hito, le da retroalimentación sobre cómo va el proyecto, redefine el panorama general, incluyendo lo que aprendió en la iteración anterior y lo que se hará en la próxima iteración, y así sucesivamente hasta que se pueda entregar el proyecto.
Descubrir después de un tiempo que alguna tarea no se puede hacer es un poco extremo, pero sigue siendo un conocimiento valioso (hubiera sido peor descubrirlo tres meses después). Y aún puedes seguir trabajando con él.
Si logras involucrarlo en el diseño del proyecto, incluso puede que le guste, y es probable que confíe más en ti en los próximos proyectos si no ocultas los problemas. Porque eso es lo que hacen las personas de confianza y los clientes quieren trabajar con personas de confianza.