¿Cómo educas a tus clientes?

Los clientes necesitan algo de educación porque piensan diferente. Los clientes piensan:

• los cambios no son un problema en ningún momento del proyecto

• los detalles no son importantes (excepciones aún menos)

• el tiempo no cuesta dinero (tienen un precio fijo acordado)

• una oración en la especificación se puede ampliar / leer libremente para satisfacer las necesidades reales, y esto no afecta el contrato. (Aquí vemos a menudo la discusión del "sentido común" - ejemplo: "Por supuesto que necesitamos una pantalla de gestión de facturas cuando hablamos de gestión contable, ¡esto es sentido común!")

• la lista continua...

El principal problema es que el cliente (no importa si es externo o interno / departamento) no quiere o no puede entender. Me llevó muchos años entender el proceso de creación de software y todavía estoy aprendiendo, entonces, ¿cómo pueden hacerlo en solo unos meses?

¿Cuál es su experiencia, cuál es el mejor enfoque para educar a los clientes?

Este verano pasado, tuve una conversación muy similar con un cliente.

El cliente quería que yo proporcionara un precio competitivo para el trabajo definido, y luego, cuando sus necesidades cambian, o su comprensión de sus necesidades cambian, querían cambiar las especificaciones sin permitirme cambiar el costo para reflejar el cambio en el trabajo.

Le pregunté a mi cliente si tenían alguna sugerencia sobre cómo podría costar cambios desconocidos como parte de la cotización. La solución que resolvimos fue que yo cotizara, incluyendo una asignación de contingencia detallada del 15%, que luego trabajaríamos con el cliente para priorizar sus cambios para utilizar esa asignación. Al final, la contingencia no se utilizó por completo, solo facture por el trabajo realizado.

El resultado final fue que estaba contento de que me pagaran por el trabajo realizado, que el cliente cumpliera internamente por debajo del presupuesto, y porque había planteado el problema de manera profesional con ellos por adelantado, me eligieron a mí en lugar de un competidor para hacer la obra.

Solo deseo que todos los clientes potenciales que existen sean profesionales y realmente valoren la calidad de la mano de obra.

Educar al cliente . Desearía no ser uno de tus clientes;)

En serio, entiendo que estás en problemas, y crees que el problema es el cliente. Tal vez lo sea, pero no importa. Cambiar a sus clientes es realmente difícil, mientras que cambiar la forma en que trabaja con ellos es mucho más fácil.

El problema es que la mayoría de los clientes no son conscientes de todas las implicaciones del desarrollo de software y usted no es consciente de sus negocios en detalle.

Solo una pequeña cosa:

los cambios no son un problema en ningún momento del proyecto

"No importa lo lejos que hayas llegado por un camino equivocado, regresa". Proverbio turco

Me encanta ese proverbio, así que cuando puedo usarlo, estoy feliz. Gracias por la oportunidad ;)

Aquí hay un par de soluciones:

Debe proporcionar al cliente la posibilidad de cambiar de opinión, ya que esto lo ayudará a obtener el software adecuado que realmente se ajuste a sus necesidades. Eventualmente obtendrá más ideas mientras lo está desarrollando.

Usted tiene un contrato de precio fijo, así que supongo que tuvo que reunir los requisitos, estimarlos y poner un precio a cada uno.

Si tiene que construir algo nuevo, utilice el mismo proceso: modifica el contrato de precio fijo con los requisitos adicionales. Acepte eliminar los requisitos que serán inútiles (por supuesto, no los ha construido ya).

Otro enfoque sería terminar lo que se ha negociado (requisitos menos inútiles y no desarrollados) como versión 1, y negociar una versión 2 con sus nuevas ideas.

La segunda solución sería crear iteraciones en el desarrollo como en Scrum . Todavía no tengo experiencia con esto en proyectos de precio fijo (porque ya no hago proyectos fijos), así que no sé si funciona o no. En serio, tengo muchas dudas. Scrum (o Agile ) es la solución para todos los proyectos de desarrollo de software, pero tal vez algunas de las prácticas descritas lo ayuden.

Si tiene un contrato de precio fijo, debe dejar en claro que cada cambio de alcance costará dinero, y evaluarán el cambio y presentarán una cotización con costo para implementar el cambio.

Esta es una práctica ampliamente aceptada en la mayoría de las industrias, pero algunos clientes se molestarán mucho con esto.

Si suena como si tuvieras un problema mayor, si tienes "sentido común" discutido.

Un poco como un cliente hace muchos años en el que trabajé y leí las especificaciones y dije cosas como "Hay un REQUISITO IMPLÍCITO que haces XXX"). A lo que la respuesta fue: No hay requisitos implícitos. Los únicos requisitos son los de la especificación escrita. Si desea agregar o cambiar requisitos, envíe una solicitud de cambio de especificación y citaremos el cambio de alcance.

El mensaje finalmente llegó pero tardó mucho tiempo.

Una solución es poner más trabajo en definir lo que está de acuerdo en hacer antes de comenzar a trabajar. Como usted dijo, usted y los clientes pueden leer fácilmente una oración del contrato de manera diferente. Cuanto más detallado sea el plan del proyecto, más fácil será para usted decir que lo extra que quieren que haga no es parte del acuerdo original.

También es importante ser consistente. El cliente no sabe cuánto trabajo implica una nueva función. Si acepta agregar funciones implementables rápidamente de forma gratuita, es muy difícil explicarle al cliente por qué no puede hacer esta otra función de forma gratuita también cuando el sentido común del cliente dice que no debería ser más trabajo.

Un truco con los contratos de precio fijo es que, incluso si realiza el trabajo con un precio fijo, haga una estimación de cuántas horas lleva el trabajo. Aunque no factura por hora, esto elimina la ilusión de que el precio fijo equivale a horas de trabajo infinitas.