¿Qué hacer con una solicitud estúpida del cliente?

Question

Gané la licitación de un proyecto y ahora el cliente (que es del Departamento de TI) quiere que diseñe / implemente la solución de una manera muy particular. Estoy seguro de que la aplicación fallará de esa manera por problemas de rendimiento. Y no será fácilmente escalable.

Este cliente / usuario en particular no sabe NADA sobre la plataforma y el lenguaje que usaré (ASP.NET / SQL Server). Su único conocimiento está en Cobol y tratar de hacerle entender mi punto de vista lo está haciendo enojar.

Me contactó. Él fue la persona que me seleccionó como ganador en la oferta. Él es quien aprobará mis cheques. Él es mi único contacto con esta empresa.

No me siento cómodo proporcionando una solución que sé que fallará y no quiero ser conocido como el estúpido programador que lo hace fallar. Conozco sus necesidades reales y patrones de uso para esta aplicación porque he realizado proyectos para ellos en el pasado.

Por otro lado, hacer esto a su manera solo extenderá mi contrato más tiempo (por lo tanto, más ganancias financieras) para resolver los problemas modificando el código.

¿Debo renunciar al proyecto sabiendo que probablemente perderé a este cliente para siempre?

O & # 8230;

¿Debo tomar la píldora y aprovechar las ventajas financieras de un proyecto extendido y asumir la mala fama como un costo?

Answer 1

Estás viendo esto desde una perspectiva completamente equivocada. Esta no es una solicitud estúpida de un cliente que no sabe nada sobre tecnología. Es una restricción de diseño que cree que introduce riesgos en el proyecto.

Así que haces lo que haces cuando te encuentras con un riesgo en un proyecto: definirlo, evaluarlo y recomendar una estrategia de mitigación.

• Defina el riesgo. decir que causará " problemas de rendimiento " y "no será fácilmente escalable" No está definiendo el riesgo. Debe especificar exactamente lo que quiere decir. ¿Qué no se va a realizar y por qué? ¿Qué cambios de escala enfrentarán estos problemas?
• Evalúe el riesgo. Bien, entonces cree que hay un problema. ¿Qué tan malo es? ¿Qué tan seguro puede estar de que estos problemas de rendimiento realmente sucederán? ¿Cuál será el impacto en los usuarios si lo hacen? Usted dice que el programa no puede escalar: ¿es el crecimiento en escala lo que expondrá el defecto de diseño incluso en las tarjetas? Lo más importante, ¿cómo sabe esto? Aquí es donde tomarse el tiempo para construir y comparar un prototipo puede ahorrarle mucho argumento sin sentido.
• Recomiende una estrategia de mitigación. ¿Cuál es la forma correcta de implementar esto? ¿Por qué es el camino correcto? Nuevamente, ¿cómo sabes esto? Nuevamente, la creación de prototipos es tu amiga.

Un par de cosas saldrán de hacer este ejercicio.

Primero, puede descubrir que si bien tiene razón acerca de cada particular, cuando los combina todos no importa. Sí, este programa no funcionará bien o escalará bien, pero si ninguno de sus casos de uso proyectados se topará con esos problemas, fácilmente no valdría la pena resolverlos.

Segundo, hay un mundo de diferencia entre decirle a alguien '' Esto no va a funcionar, solo lo sé '' y diciéndole "comparé los casos de uso que esperamos, y parece que este enfoque dará como resultado un tiempo de respuesta de cuatro o cinco segundos por transacción de usuario".

Tercero, si sabe qué condiciones harán que el software falle, y expresa estas inquietudes al cliente, y el cliente dice "Realmente queremos que funcione de esta manera". has cumplido tu responsabilidad. Si esto falla porque el cliente elige no mitigar el riesgo que ha identificado, nadie puede señalarlo y decir que fue culpa del programador.

Sobre todo, la evidencia triunfa sobre la opinión . Has enmarcado toda esta pregunta como un caso de tu opinión frente a la del cliente. Esa es una propuesta perdedora. Lo que debe hacer es enmarcarlo como "aquí hay un problema que debemos resolver". Y para formular la pregunta de esa manera, debe demostrar la existencia del problema y, para eso, necesita evidencia.

Finalmente, es el cliente quien decide si un riesgo debe ser mitigado, no usted. Depende de usted darle la mejor información posible para respaldar su decisión. Y debes dejar en claro, sin ser un imbécil al respecto, que es su decisión.

He descubierto, en más de una ocasión, que un simple correo electrónico enfoca la atención perfectamente:

  

He estado revisando el diseño, y creo que hay un riesgo aquí que tenemos que discutir. [Enfoque A] es realmente sensible al volumen de transacciones, y me preocupa que tengamos suficientes usuarios para tener problemas con él.

     

Realicé una pequeña prueba usando [Enfoque B], y es mucho menos sensible; En mi prototipo simple, pude obtener X transacciones por segundo. Esto tiene sentido, porque [comparación técnica de cómo los dos enfoques manejan las cosas].

     

Estoy especialmente preocupado por esto porque [describe cómo fallará el programa si funciona mal].

     

Esto me parece un problema importante. Si fuera yo, usaría [Enfoque B], porque [describa cómo este enfoque mitigará el riesgo].

     

Pero usted está mucho más familiarizado con el [Enfoque A] que yo, y felizmente diferiré su orientación sobre este asunto. ¿Qué crees que deberíamos hacer?

Este mensaje dice muy claramente "Si ignoras lo que te estoy diciendo, así es como va a fallar el proyecto, y tendré documentación que demuestre que me dijiste que lo hiciera de esa manera". Tampoco dice eso en realidad.

Answer 2

Creo que tendrá que sentarse con él y hacerle algunas preguntas aclaratorias.

Deberá saber POR QUÉ quiere que se implemente de esa manera en particular. Debe demostrar que desea ofrecer una solución de trabajo que satisfaga las necesidades comerciales.

Es posible que haya algunas inquietudes subyacentes, problemas que deben abordarse, ya que usted dijo que es posible que no esté familiarizado con sus tecnologías propuestas y necesite cierta tranquilidad.

Fallas que aseguran que las cosas estén completamente documentadas y aprobadas.

Answer 3

Opción 1: Aléjese, ya tiene una mala relación y es poco probable que mejore.

Sin embargo, no lo haga porque desea prolongar un contrato, eso es, en el mejor de los casos, astuto y en el peor deshonesto, pero si necesita el contrato ...

Opción 2: pídale que documente sus opciones y razones de arquitectura y que las firme como una especificación. Agregue una cláusula al contrato que indique que no garantiza el rendimiento y / o la escalabilidad utilizando la especificación que ha producido y luego impleméntelo a su manera. Envíele una presentación de su enfoque y razonamiento favorito.

Si el proyecto falla (él podría estar en lo cierto), entonces siempre puede señalar que se lo dijo y le ofreció una alternativa.

Asegúrese de implementar su arquitectura de buena fe, es decir, no haga que falle deliberadamente. Haga pruebas tempranas que prueben su punto y asegúrese de que sepa que están fallando. Déle advertencias por escrito claras a lo largo del ciclo de vida del proyecto de que se está desviando.

La mejor de las suertes. Considere seriamente la opción 1. Vale la pena intentar un sincero corazón a corazón con el chico.

Answer 4

¿Es posible crear un pequeño prototipo como una aplicación para demostrar que él está equivocado y usted tiene razón? Hablar es mucho más fácil si tienes pruebas sólidas.

Answer 5

Odio ser la policía de servicio al cliente, pero hablar de esto como una "estúpida solicitud del cliente" es probablemente una mala idea a menos que realmente lo sea (en cuyo caso, debe retirarse sin dudar) Creo que un término mejor sería "solicitud de cliente mal informada".

Teniendo esto en cuenta, recuerde que su cliente probablemente tenga una necesidad genuina y usted debe reconocerlo (verbalmente). Simplemente está disfrazado por su idea (mal informada) de una solución. Pruebe un poco e intente llegar a lo que realmente está buscando, luego proponga una solución que considere mejor y explique por qué sería mejor. Y hágalo de tal manera que no cuestione la competencia del cliente. Nadie quiere trabajar con nadie que los haga sentir estúpidos.

Answer 6

Es difícil sugerir pasos específicos a seguir ya que no conozco los detalles aquí, pero aquí están mis pensamientos:

Si construyes lo que él quiere (y no lo que él necesita ) y sabes que la solución es la incorrecta, entonces eres cómplice en el fracaso de el proyecto. Si sabe que no va a funcionar y no escalará y lo construye de todos modos, entonces no se sorprenda si termina siendo el "tipo de caída". por el fracaso del proyecto y no obtener más dinero para hacerlo bien la próxima vez.

Si el tipo se está enojando, podría ser por muchas razones, una de las cuales podría ser que no entiende la tecnología y eso le molesta. Pero, no sé la situación, ¿quién sabe? Personalmente, preferiría enojar al tipo y proponer la solución correcta e insistir en la solución correcta que dejar que sus emociones conduzcan el barco.

Puede ser el cliente y puede retener el cheque, pero eso no lo hace inteligente o correcto. Los clientes se equivocan todo el tiempo, a pesar del viejo adagio. Ahora, puedes acercarte a él de la manera incorrecta o correcta y él podría reaccionar igual a ambos. Pero usted quiere acercarse a él de la manera correcta independientemente.

Si, al final, él insiste en que lo hagas a su manera y no pueda apoyar su camino con nada más que afirmaciones y emociones, cortésmente me alejaría del trabajo. El dinero no vale la pena, sinceramente. Puede estar enojado contigo, pero puedes dormir bien sabiendo que tú no desperdiciaste el dinero de su compañía en una mala solución al problema.

• Sé honesto.
• Escucha lo que tiene que decir.
• No dejes que sus emociones nublen tu juicio.
• Al final, haz lo correcto.

Al menos, eso es lo que haría.

¡Mucha suerte!

Answer 7

Escuchar y aprender . Estar realmente interesado en los pros y los contras del enfoque de sus clientes.

Declare su propio enfoque del problema de una manera que el cliente pueda entender asegúrese de documentar los pros y los contras de su enfoque también.

Luego, discuta las dos formas de hacer cosas con el cliente, pero no de una manera 'su enfoque es estúpido y estoy en lo correcto', sino que esté realmente interesado en los beneficios que podría aportar su enfoque. .
Si ve un problema en su enfoque, pregúntele . Pero no de una manera 'esto no funcionará', sino que sea curioso 'cómo funcionará esta escala'. No se limite a adivinar su idea , sino conozca los hechos y las cifras "hecho de esta manera, ¿no habrá problemas con demasiado tráfico en estos y estos casos?

Incluso podrías aprender algo. ¡Esfuérzate! Al final, es posible que tengas que codificarlo a su manera, ¡y será mejor si realmente entiendes las trampas !

Answer 8

Básicamente, solo usted puede responder esta pregunta. Conoces mejor a tu cliente y tu situación y si puedes encontrar la manera de hacer que esto funcione, es tu decisión.

Personalmente, rechazaría el proyecto. Si quieren quedarse con usted, explique por qué no puede llevar el proyecto a los requisitos establecidos.

Dígales que si quieren que usted implemente el proyecto, entonces contrataron a su experiencia, no la experiencia de su persona en el departamento de TI .

Answer 9

Si no se siente cómodo, aléjese. Hemos sido calzados para ofrecer una solución específica para los clientes antes a pesar de nuestros mejores deseos y las mejores recomendaciones y nos ha causado un sinfín de penas en el futuro.

Si es un problema financiero y usted "necesita" el negocio, entonces definitivamente abordaría el proyecto desde un punto de vista de boxeo temporal.

Dígales qué se puede lograr en qué tipo de líneas de tiempo. Asegúrate de que te paguen de forma modular a medida que alcances diferentes hitos. Al menos de esa manera, le brinda la oportunidad de alejarse en el futuro si se convierte en un no ganador para usted.

Otra opción podría ser mostrarles cuánto más costoso sería hacerlo a su manera que la suya.

Answer 10

Si necesita al cliente, él también lo necesita a usted (probablemente más). Después de todo, él fue quien te seleccionó. Él es quien necesita resolver un problema.

Tome una posición de que sus instrucciones sobre "cómo" hacer el trabajo no le dictarán: lo que debe hacer es su decisión. Es probable que veas algo de hielo derritiéndose.

Answer 11

Recomendaría probar algunas tácticas de dirección errónea con él. Hágale saber cuáles son sus preocupaciones con sus métodos y ofrézcale alguna otra solución que se adapte tanto a sus necesidades como a las suyas. Trate de evitar ser agresivo (no diga que está equivocado), pero diga que cree que hay una mejor solución que integra ambas opciones.

Intenta practicar " Judo verbal " ;. Ser confrontativo no te dará ningún punto con él, y solo hará que esté más seguro de que solo estás siendo difícil. Acuerde con él, establezca una relación sobre ideas comunes y luego guíelo suavemente por el camino hacia su solución.

Answer 12

Dibuje un contrato que contenga sus inquietudes y que les haga pagar el dinero incluso en caso de falla debido a la mala decisión del cliente. Luego haz que lo firmen.

Sin embargo, asegúrese de ejecutar ese contrato con un abogado experimentado, porque es fácil equivocarse un poco para que un tribunal lo desanime, si las cosas empeoran y necesita demandar por el dinero.

Informe al cliente de esa parte del contrato antes de firmar, tal vez lo reconsiderarán.

O, en lugar de pasar por todos estos problemas, como otros han sugerido: pagar la fianza, alejarse o mejor: correr. Tan rapido como puedas. A menos que sea realmente mucho dinero, entonces no valdrá la pena venderlo.

(Editar: maldita sea, Simon me ganó por unos segundos)

Answer 13

Simplemente proponga su solución y explique (con la ayuda de presentaciones / documentación ) por qué es la mejor. O incluso hacer un prototipo con él.

Su cliente debe comprender, si lo demuestra, que tiene liderazgo técnico en ese campo y confiar en usted.

Answer 14

Me saldría del proyecto a menos que me estuviera muriendo de hambre. Como consultor, creo que el único valor que aporto al cliente es el conocimiento que poseo (y que no tienen, o de lo contrario no me contratarían). Para trabajar en algo que '' sé '' va a fallar violaría el Código de ética del consultor (si hubiera uno).

Haría todo lo posible para convencer al cliente de que es probable que su camino fracase, y luego haría todo lo posible para localizar a otra persona que haga el trabajo por él.