4 votos

Cómo tratar con un cliente con malas prioridades

Tengo un cliente -quizás socio comercial sea un término más adecuado, él generalmente lleva la voz cantante y se encarga de la parte comercial de las cosas, pero yo también soy un miembro de la empresa y apoyaré el software y obtendré parte de los ingresos- que tiene, bueno, "mucha visión". Empezó con una idea de lo que quería terminar para este sitio web y no es un mal diseño ni mucho menos, pero el producto ha evolucionado y todavía parece atrapado en sus expectativas originales de perfección. No considero que lo que hemos cambiado sea un compromiso en absoluto, hemos hecho algunas mejoras enormes y hemos automatizado algunos procesos mucho más de lo que se imaginaba en los días de la V1. Pero ahora está tratando de aplicar el mismo grado de entrada de los usuarios y las mismas expectativas a un sistema completamente diferente. Está haciendo sugerencias que no tienen sentido y que no son necesarias con el nuevo flujo de trabajo.

De todos modos, todavía estamos en las primeras etapas de nuestra beta -no hemos pasado un día completo sin que algo vaya mal en algún momento- y él ha empezado a centrarse en una característica particular que sólo se aplica el 2% de las veces. Lo llama nuestra máxima prioridad cuando, de nuevo, ni siquiera hemos pasado un día sin que aparezcan otros problemas más graves. Pero insiste en que este caso del 2% es gran parte de lo que está retrasando su trabajo, a pesar de que todavía se las arregla para hacer lo que supuestamente está bloqueado.

No entiende los aspectos técnicos, así que intento explicarle las cosas en términos sencillos, pero hoy me ha enviado un correo electrónico para decirme que ha llevado nuestro problema a otro desarrollador para pedirle consejo. Aparte de la frustración que supone que sus prioridades sean claramente erróneas, esto también me resulta algo embarazoso: ha acudido a un desarrollador para plantear una pregunta tonta y decir que yo no sabía cómo solucionarlo.

¿Cómo le explico todo esto, pero de una manera que no tensione la relación ni provoque que empiece a mandarme más y más mensajes sobre cosas irrelevantes mientras yo intento trabajar?

  1. Sé lo que hago y puede confiar en que diseñaré el software de forma que aprenda a preferirlo después de un par de semanas. Por no mencionar que puede confiar en que resolveré los problemas o pediré ayuda por mi cuenta, y que no le contaré (ni podría hacerlo) todos los detalles técnicos de cada problema al que me enfrento en el día, ya que enfrentarme a los problemas es más o menos la descripción de mi trabajo.
  2. Que debemos construir un producto que funcione antes de empezar a preocuparnos por las pequeñas complejidades de cómo funciona. La imagen grande es importante, la pequeña es lo suficientemente fácil como para lanzarla y no hacer un escándalo, pero pedir cambios importantes en la interfaz de usuario después de que tenemos algo que funciona en su mayoría no es mi prioridad en este momento.

2voto

Adam V Puntos 2774

En mi opinión, veo problemas aquí. Y sí, fue algo malo no porque dirigiera los problemas a otro desarrollador, sino porque te dijo eso.

¿Se trata de un socio local o remoto?

¿Hay que hacer otro proyecto como socio? ¿Se puede ser socio en el proyecto 1 y hacer otros como contratista remunerado?

Desde el punto de vista técnico, es evidente que necesita un buen software de gestión de proyectos en el que pueda clasificar las tareas por prioridades. De este modo, puedes marcar sus peticiones tontas como de baja prioridad.

Sin embargo, el aspecto más importante es la división de funciones. Tienes que dejarlo un 150% claro: él se encarga de la parte comercial y tú de la parte técnica. Tú no interfieres en su papel, él no interfiere en el tuyo. Cualquiera de vosotros puede sugerir cosas a un líder de rol, pero el líder de rol tiene el trabajo final. Si dice que es de baja prioridad, entonces lo es. Si se queja, entonces que se busque otro compañero. Tan claro como esto.

Dígale qué mal ha hecho hablando con otro promotor. Quizá no lo entienda.

Por lo que veo, tenéis problemas de comunicación interpersonal y una persona no respeta el papel y los límites de la otra. A menos que resolváis esto lo antes posible, tendréis dificultades para terminar este proyecto.

PS. Cuando leo esto, me alegro de no hacer sociedad con nadie :)

1voto

Kevin Berridge Puntos 3313

Tome su versión simplificada del problema que tiene ahora y llévela a otro gerente/comercializador/persona de desarrollo de negocios y pídale su opinión sobre el problema. Devuélveselo a tu "compañero" para que pueda entender la situación...

En serio, sin embargo, parece que podría ser el momento de, 1) seguir adelante, o 2) como dice la otra respuesta, hablar de sus funciones dentro de la organización, y posiblemente pensar en establecer un acuerdo contractual entre los dos para que sus funciones en el futuro sean más claras.

No me gustaría seguir trabajando con alguien que no respeta mi opinión profesional cuando no tiene experiencia ni conocimientos técnicos del ámbito.

0voto

trouble Puntos 28

Algunos puntos:

  1. No creo que tengas bien definida tu asociación. Desde luego, no parece que tengas nada por escrito que acredite lo que es y lo que no es la asociación.
  2. No tengo la sensación de que ningún dinero haya cambiado de manos todavía. Es importante que reconozca que su producto de trabajo está en su código existente. Su * tos * socio ya está buscando soluciones con otro desarrollador. ¿Tiene la capacidad de compartir, o incluso dar, su código a alguien más? El hecho de que haya involucrado a un segundo desarrollador, probablemente sin consultar contigo primero, sería una enorme bandera roja para mí.
  3. Como han escrito los demás, SÍ hay que definir los roles y ambos deben respetarlos. Pero teniendo en cuenta lo que ya ha sucedido, podrías considerar una estrategia de salida, así como la forma de definir esos roles.

0voto

rsapru Puntos 153

Siempre que sea posible, debe tener un completo y minucioso especificación de lo que se está construyendo, incluyendo cada detalle de la interfaz de usuario y cualquier tecnología de backend. Muchas especificaciones incluyen incluso detalles a nivel de método sobre lo que hará cada método en la implementación.

Un pliego de condiciones exhaustivo ayuda a eliminar el riesgo, porque documenta exactamente lo que se va a construir y cómo se va a construir. En un contrato a tanto alzado, los contratistas absorben todo el riesgo, incluido el introducido por los requisitos ambiguos, porque se paga al contratista una tarifa fija por completar el proyecto, a pesar de la ambigua definición del mismo.

En una situación como la suya, es particularmente vital escribir un completo y minucioso especificación, porque el cliente no tiene claro lo que quiere que se construya. Esa es una gran señal de advertencia de que podría ser un gran fracaso del proyecto, a menos que se obligue a definir claramente el proyecto desde el principio. Es necesario tener todos los detalles por escrito.

La alternativa -que puedes explicar al cliente- es que si no estás seguro de lo que hay que construir, tienes que empezar a multiplicar la estimación del coste del proyecto por un factor de 2 o 3 con la hipótesis de que tendrás que reconstruirlo varias veces, hasta que el cliente esté contento. O cobrar una tarifa por hora.

Finanhelp.com

FinanHelp es una comunidad para personas con conocimientos de economía y finanzas, o quiere aprender. Puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X