¿Cómo escribir una propuesta de software?

La primera propuesta de software que escribí me tomó casi 2 semanas.

Fue en un caluroso verano del 2013, cuando por primera vez estaba vendiendo un proyecto de verdad. Entre las cosas que incluí en el documento:

• un listado de todas las funcionalidades…
• detalles técnicos de frameworks o librerías a usar…
• prototipos de la aplicación…
• plazos…
• alcance…

Se sentía muy bien entregar tantas cosas. Me lo tomé como si fuera una tarea de la Universidad, mientras más mejor. En realidad no tenía mucha idea de lo que estaba haciendo.

Tuvo que pasar 1 año con 8 propuestas rechazadas para darme cuenta que estaba haciendo las cosas mal. No es gracioso gastar días en una propuesta y recibir un NO como respuesta 😅

Lo peor de todo es que sé que no soy el único. Las veces que he enviado a cotizar proyectos de software, el proceso es similar a lo que hacía: una propuesta con miles de detalles técnicos con tiempos de entrega e incluso con estimaciones.

Buscando en Google, me encontré con varias fuentes confiables que explicaban cómo hacer bien estas propuestas, aunque la mayoría está escrita en inglés.

Luego de ensayo y error, encontré un template en particular que me gustó bastante ya que está optimizado para vender, es decir, para que te acepten la propuesta y para que no pierdas tanto tiempo elaborándola 🥰

Antes de decirte cuál es el formato, es importante que sepas cuáles son los problemas de escribir propuestas taaaan detalladas.

2 problemas de escribir propuestas muy técnicas

Problema #1: Estás regalando trabajo

Si quiero mandar a hacer una casa, no vas a esperar que los planos que te haga el arquitecto sean gratis… ¿cierto? 🤔

Bueno, cuando incluyes funcionalidades, mockups u otros artefactos de software estás regalando los planos. Estás trabajando gratis.

Estos planos son importantes, ya que con ellos el cliente pasa de tener una idea a tener algo concreto. Lo estás ayudando, y por lo mismo, puedes cobrar por este trabajo.

Hay empresas y profesionales que venden sesiones estratégicas donde el output es un “Roadmap”, una hoja de ruta que dice como llegar de “A” (situación actual del cliente) a “B” (situación deseada del cliente). Incluso hay un curso muy bueno donde te enseñan a hacerlo.

Una forma simple de ver esto es que tu posible cliente tiene una problemática y que con tu ayuda ya no la tendrá:

Si bien los “planos” no solucionan al 100% el problema, lo deja en un estado mejor.

Problema #2: La propuesta larga y técnica no vende

La propuesta es una herramienta de venta… pero pocos nos damos cuenta de esto 🤭

Nos centramos en “nosotros” más que en el cliente, en la tecnología más que en el por qué.

Una parte importante de vender es saber escuchar y transmitir que entiendes la problemática de la persona que tienes enfrente. Aunque tengas las mejores intenciones, una mala propuesta estropea todo.

Es como si en un folleto del nuevo iPhone coloquen las especificaciones técnicas junto a una imagen plana del producto (aburrido!)… esto no se hace porque no vende, y Apple sí sabe vender 😏

¿Qué elementos debería tener una propuesta?

Una propuesta debe ser escrita para convencer al cliente de que tú eres la mejor opción. Para lograr esto, una de las mejores estructuras la tiene la propuesta de Jonathan Stark que puedes descargar aquí.

Básicamente tiene 4 secciones, te voy a ir detallando cada una de ellas con tips adicionales:

Sección 1: “Por qué estás aquí” o “Descripción del proyecto”

Esta sección debe incluir las razones por las que el cliente te contactó. Es prácticamente una síntesis de las primeras reuniones, utilizando lenguaje no técnico y ojalá incluyendo frases o palabras que tu mismo cliente dijo durante las reuniones.

La situación actual y el problema debe ser especificado de forma clara y amena. Es importante también incluir el cómo se ve un futuro con el problema solucionado.

Sección 2: Opciones de proyecto

¿Cómo solucionar la problemática del cliente? Existen infinitas formas 😊 así que en esta sección debes colocar 2 o más opciones que ayudan a tu cliente.

¿Por qué más de 1 opción?

• Porque al cerebro le encanta tener opciones para elegir. De hecho, apunta siempre a ofrecer 3 opciones.
• La decisión del cliente ya no es un “Sí” o “No”, es un “¿Cuál opción me conviene más?”
• Te permiten jugar con la disposición a pagar ofreciendo alternativas “low cost” que solucione en parte la problemática y unas más caras (“premium”) que sean de más valor para el cliente.

Por ejemplo, una vez hice un proyecto que consistía sólo en cambiar proveedor de correo transaccional en una aplicación (esto toma a lo más una mañana). Las opciones que dí fueron 2:

• Opción 1: yo hago el cambio en el código, y tu has cambio en la configuración siguiendo este tutorial.
• Opción 2: yo hago todo por ti.

En el ejemplo, coloqué los precios de tal manera de que la primera opción fuese la más tentativa (ya que me daba pereza configurar 😂). El cliente eligió la opción barata pero con más trabajo para él. Gané el proyecto y de paso aprendí que a él le interesaban las cosas más baratas, así que no éramos buen fit para un proyecto más grande.

Otra alternativa es colocar opciones incrementales. Por ejemplo, para la creación de productos nuevos, puedes ofrecer algo así:

• Opción a) levantamiento de requisitos (casos de uso + mockups + planificación estratégica + definición de mockup).
• Opción b) opción 1 + desarrollo de MVP.
• Opción c) opción 2 + estrategia de lanzamiento.

Si bien la opción a) no soluciona el problema (implementar nuevo producto) te acerca a la solución y da posibilidad de que el cliente luego elija un proveedor a su elección o que continúe contigo. Cualquiera de los 2 casos es bueno, si continúa podrás vender el proyecto más caro (implementación) y si no, el trabajo que hiciste fue remunerado y que fue de ayuda (todos ganan).

La opción c) no es 100% necesaria (ya que con a y b tienes un producto funcional) con ésta puedes ofrecer una estrategia de lanzamiento que ayudaría a que el producto sea más exitoso.

Sección 3: Por qué yo

En esta sección respondes la pregunta a “¿por qué yo y no otra persona?”.

Aquí hay que usar elementos que apelan a cosas que el cliente valora y que realmente te sirvan para destacar entre otros profesionales.

Cosas como “me interesa mucho tu proyecto”, “tengo el mejor equipo”, “entiendo tus necesidades”, “utilizo las últimas tecnologías”, “escribo código limpio” NO SIRVEN. Son 💩 genérica, no te destaca, ya que todos lo dicen. Nadie va a decir “tengo al peor equipo del mundo”.

Lo siguiente funciona mucho mejor:

• He ayudado a cliente de similares características a obtener resultado.
• Ofrezco una garantía de 2 años para mi trabajo (suena una locura 🤪, pero es posible cobrar MUUUCHO por reducir tanto el riesgo de un proyecto de software).
• Tengo un blog que habla sobre problemática o tecnologías que ayudarán a obtener resultado.
• Tengo un diplomado en industria, con lo que aprendí logré resultado.

Son características que respaldan tu expertise en relación al proyecto.

Sección 4: Términos y condiciones

Aquí van los precios y condiciones de pago. Es decir, cuánto le saldrá a tu cliente y cuándo debe hacer los pagos.

Precios

Para colocar precio a cada opción, te recomiendo utilizar psicología de precios. Por ejemplo, ¿cuál de las siguientes 3 opciones eliges?

• Bebida chica (500ml): 10 usd
• Bebida grande (1L): 11 usd
• Bebida gigante (2L): 12 usd

Yo escogería la 2L ya que por sólo 2 USD adicionales obtengo 1.5L (comparado con la más barata). Me siento inteligente por seleccionar esa opción 🤓

Pero… 10 USD por 500ml es muy caro. La gracia de ésta técnica es incrementar los precios de todas las opciones, haciendo ver a la más cara como una ganga (“Decoy Effect”)

Otra técnica es usar la estructura x, 2x y 5x:

• Opción a) precio: x, beneficio para tu cliente: y
• Opción b) precio: 2x, beneficio para tu cliente: 5y
• Opción c) precio: 5x, beneficio para tu cliente: 10y

Aquí, la idea es que la opción obvia sea 2x, pues el beneficio incrementó mucho comparado con la opción anterior. La opción c) es comparativamente menos atractiva, pero tiene un gran beneficio.

Un ejemplo en software podría ser:

• Opción 1: definición del software con mockups, historias de usuario y planificación.
• Opción 2: implementación del software (versión básica, algunas cosas pueden quedar manuales).
• Opción 3: implementación del software (versión extendida, todo automatizado).

Si usas cualquiera de estas estructuras, siempre debes tener presente que la solución propuesta debe mejorar la situación actual y en lo posible ser una inversión inteligente para tu cliente. Algo como “invertir X y ganar 3X”.

Si le cobras una millonada por un proyecto que no beneficia a nadie… ya no eres un programador, eres un estafador 😂 (puedes ver más sobre pricing aquí)

Términos de pago

Un consejo: no uses lo que usan todos: “40 al comienzo, 30 en la mitad y 30 al final” (o alguna variación).

Un proyecto de software es un ser viviente, es difícil definir “cuándo va a aprender a caminar”, “cuándo van a salirle dientes” o “cuando va a enfermarse”.

Muchos cursos y libros que hablan sobre consultoría proponen lo siguiente:

• Si las relaciones de confianza están bien definidas, solicita el 100% al inicio del proyecto.
• Si piensas que puede haber problemas de confianza, puedes solicitar un porcentaje al inicio (digamos, 50%) y el resto en una fecha en particular (acordada por ambas partes). Esto te evitará situaciones en que el cliente te retiene pagos porque piensa que la funcionalidad no está lista.

Si tienes la duda de cuál usar, puedes dejar que tu cliente decida. Ofrécele lo siguiente:

• Opción 1: 10% de descuento por un pago de la totalidad del proyecto (valor total = 0.9X). Es decir, te depositarán el 90% del precio total pero ya estará en tu cuenta 🤑
• Opción 2: 50% al inicio, 50% en una fecha fija (o al final del proyecto 😑). Valor total = X.

Resumen y Conclusiones

En resumen, lo importante de una propuesta es:

• Describir el proyecto (recordar por qué estamos aquí, las motivaciones, ser empático, demostrar que escuchaste).
• Opciones (distintas formas en las que puedes ayudar a solucionar el problema).
• Por qué yo (indicar por qué tu y no otra persona, ¿qué ventajas tienes?).
• Términos y condiciones (indicar los precios y condiciones de pago, usar descuentos a tu favor).

Seguir una estructura similar ayudará a cerrar más proyectos e invertir muuuuuuuucho menos tiempo en la elaboración de la propuesta.

Recursos adicionales

• Template de Jonathan Stark, el que más me gustó y en el que me inspiro para escribir mis propuestas hoy en día. Tiene la misma estructura que te presenté en este post.
• Ejemplo en español, una propuesta que me aceptaron este año que tiene el mismo formato y en español. La información sensible fue eliminada 😏