“Hazlo bien, en contra de los deseos del cliente”: ¿cómo se llama? [cerrado]

Conocemos la situación óptima de negociar correcciones de especificaciones con el cliente, obteniendo las especificaciones para hacer lo que el cliente quería, no lo que dijo o pensó que quería. Eso es negociar, explicar.

A veces, no podemos convencer al cliente. Nos vemos obligados a producir rotos según lo diseñado. Esto, llamado "demonología" por el mérito de que los magos convoquen demonios y demonios que cumplan sus deseos literalmente, causando la desaparición del mago como resultado, es otro enfoque que dejará al cliente muy insatisfecho una vez que se den cuenta de su error, y por supuesto, trate de fijar el La culpa es del desarrollador.

Ahora me enfrenté a un enfoque muy diferente: el cliente creó especificaciones simples que no tienen en cuenta algunas advertencias críticas, y no está dispuesto a solucionarlas, admitir los errores obvios y aceptar las correcciones sugeridas. El producto hecho con estas especificaciones se romperá críticamente y posiblemente podría costar vidas humanas. Aún así, es demasiado tarde para cancelar el contrato por completo. El contrato tiene cláusulas punitivas para eso, que no podemos aceptar realmente.

¿La decisión del jefe? Hacemos el trabajo correctamente y le mentimos al cliente que lo hicimos de acuerdo con las especificaciones. Los algoritmos en cuestión están ocultos lo suficientemente profundo debajo de la superficie, el producto hará el trabajo bien, no fallará en la situación de advertencia, y a menos que alguien cava demasiado profundo, nunca descubrirán que no lo rompimos como se solicitó.

¿Hay algún nombre común para esta táctica de ejecución de especificaciones?

¿Es el (los) requisito (s) en cuestión un requisito defectuoso, faltante o derivado? Importa. Si falta el requisito o puede derivarse de otro requisito, entonces es simple decir que es un requisito derivado y usted cumple con los términos del contrato. Y no hay razón para ocultarlo.

Si el requisito contradice un requisito, ¿cómo va a validar el sistema sin un cambio en los requisitos? La razón más probable para que el gobierno no quiera cambiar los requisitos es "les cobrará más". Si ya va a implementar sin costo adicional, entonces hay pocas razones para que se opongan.

Finalmente, debido a que este es un trabajo del gobierno, habrá un seguimiento en papel para todos estos tipos de decisiones, si lo desea. Si los empleados gubernamentales responsables de su proyecto no están de acuerdo verbalmente con el cambio de requisitos, entonces puede presentar formalmente una variación de requisitos. Estoy seguro de que cualquier solicitud de variación que utilice términos como "poner en peligro la vida" tendrá CERO posibilidad de ser rechazada. En cualquier caso, no hay razón para "ocultar" que no está cumpliendo con los requisitos, ya que eso podría ocasionar daños punitivos a su empresa, aunque esté tratando de hacer lo correcto. En este caso, lo correcto es escalar formalmente el problema y asegurarse de que su empresa esté protegida. No es ocultar lo que estás haciendo al cliente porque eso también está mal,

Yo no soy un abogado. No debe actuar ni abstenerse de actuar según las opiniones que proporcione.

El lanzamiento de un producto que podría poner en riesgo vidas debido a una falla de diseño (en lugar de ser una parte necesaria de su operación) de la que está al tanto es probable que lo ponga del lado equivocado de la legislación de salud y seguridad, así como exponga a su organización a reclamaciones legales y costos. En la mayoría de los territorios y situaciones, la ley de la tierra anula cualquier contrato que pueda tener, por lo que esa debería ser su prioridad.

En otras palabras: aclare su posición legal específica antes de continuar.