Habíamos desarrollado una solución personalizada desde cero para nuestro cliente. Recientemente, el cliente solicitó una cotización para integrarlo con un software de terceros.
Desafortunadamente, simplemente recibimos una demostración guiada apresuradamente de ese software de su proveedor, un punto final de API de demostración y alguna 'documentación' insignificante que contiene ejemplos sobre cómo llamar a la API sin ninguna explicación de los datos devueltos. Hemos pedido más documentación o al menos acceso de demostración a ese software para que podamos "ingeniería inversa" de la API (supongo que es un poco tonto), pero desafortunadamente el proveedor se niega a dar nada de eso a menos que nuestro cliente firme un contrato de un año. con ellos.
Dada la enorme falta de visibilidad sobre esto, dudo en proporcionar cualquier tipo de cita. Sin embargo, me presionaron para que diera uno, así que puse un precio alto para cubrir los riesgos involucrados.
Por supuesto, el cliente no está contento con esto y afirma que no puede pagarlo. Además, de alguna manera parece que el proveedor le ha dicho al cliente que puede hacer la integración por sí mismo a un precio mucho más bajo modificando nuestro software.
Si bien el código que hemos escrito ahora pertenece al cliente y puede hacer lo que quiera con él, ¿cómo les digo que es una muy mala idea y que lo más probable es que falle? Además, el cliente todavía nos está pagando por el mantenimiento del software, por lo que nos gustaría mantener el código en buen estado y, por supuesto, no nos gustaría ser culpados (o arreglados) por cualquier problema que pueda surgir de los cambios del proveedor. .
Presumiblemente, su cliente le ha mostrado su código al tercero y está en posesión de toda la información que tiene menos riesgo de cubrir que usted al hacer su oferta.
Sin embargo, su cliente corre el riesgo de que simplemente esté haciendo una oferta baja para que su cliente compre su software principal y es posible que nunca entregue el trabajo de integración.
En lugar de tratar de explicar su riesgo al cliente. Resalte su riesgo con la opción de terceros diciendo:
1- Cualquier cambio en el código corre el riesgo de romper la funcionalidad existente
2- No puede continuar brindando soporte al producto si se realizan cambios en el código. ¿El tercero se hará cargo de este soporte para TODO el producto?
3- Si el tercero no cumple con la entrega, o si se encuentran errores después de que se completa el trabajo y su cliente vuelve a usted para solucionar los problemas. Es probable que los costos sean de una cantidad similar a la de usted haciendo el trabajo en primer lugar.
4- Sugiera que el tercero simplemente quiere vender su producto estándar y no tiene interés ni participación en el trabajo de integración. Donde usted está comprometido con el soporte continuo y la calidad.
Considera que el proveedor es un gran riesgo, lo que en una situación de precio fijo significa que debe cubrirlo. Su cotización es una evaluación honesta y sería una tontería reducirla. Espero que haya explicado su razonamiento a su cliente.
Un contrato de tiempo y materiales sería mejor para ambos. Usted no asume ese riesgo (específicamente, no corre el riesgo de que el proveedor irrazonable de su cliente o su ex competidor desairado le cuelguen hasta secarse). Como el cliente no tiene que cubrir sus riesgos, obtiene un precio justo. El cliente parece confiar más en el proveedor que en usted, y dada su relación directa con él, probablemente esté en una mejor posición para fomentar su cooperación. No creo que sea difícil convencerlos de que T&M es la ruta más barata aquí.
Si bien los contratos de soporte son una gran fuente de ingresos recurrentes, es de esperar que impliquen poco trabajo real. Apoyar su código después de la modificación por parte de un tercero no es algo en lo que me gustaría entrar. Si bien la ruta T&M debería presentarse como el cielo probablemente más barato si lo hacen , usted vende este lío de soporte de software (con suerte para el cliente, con suerte) como el infierno si no lo hacen .
Mucha de mi experiencia viene del mundo de la arquitectura/construcción y creo que hay un modelo de facturación que puedes tomar prestado. Por lo general, el arquitecto factura la fase inicial de "diseño esquemático" por hora/tiempo y materiales y solo después de que se completa se firma el contrato de "documentos de construcción" y se fija el precio.
Podría valer la pena probar un enfoque de dos fases: una fase de desarrollo inicial (llámese "estudio de idoneidad", "desarrollo preliminar" o algo así) en el contrato de tiempo y materiales y un contrato más normal que se determinará al final de la fase inicial.
Durante la fase inicial, es necesario tener reuniones y conversaciones con el cliente. Usted no quiere gastar más de lo que el cliente está dispuesto a pagar.
Muchos clientes no pueden soportar T&M, por lo que se ven obligados a hacer una cotización de precio fijo; esto es bastante común.
¿Pueden hacer una cotización de precio fijo para una prueba de concepto o una solución mínima viable? ¿Qué API de terceros, integrada con su solución, brinda el mayor beneficio con la menor cantidad de riesgo?
Cotizar el trabajo de MVS/PoC con alguna contingencia y establecer la expectativa de que el resto del trabajo se pueda cotizar una vez que se haya realizado el PoC.
Al completar la prueba de concepto, debe quedar bastante claro cuáles son sus capacidades, qué puede manejar el equipo de terceros y el cliente debe tener una buena idea sobre quién puede realmente entregar a tiempo y dentro del presupuesto.
Si todo va bien y el equipo de terceros es excelente, entonces su riesgo y precio bajarán.
Si no sale bien, entonces su cliente debe entender la fuente del problema y su precio tendrá sentido.
Es crucial que su cliente sepa que la solución completa será un proceso iterativo y que volverá al pozo por más dinero. El cliente debería apreciar este enfoque porque los proyectos pequeños tienen éxito con mucha más frecuencia que los proyectos grandes: Encuesta de Gartner
MCW
Barry A.