Ejemplos y recursos para escribir una propuesta de desarrollo para un cliente [cerrado]

Estamos investigando nuestros procesos y relaciones con los clientes en el trabajo y parte de esto es crear una plantilla estandarizada para nuestras propuestas de desarrollo que enviamos a los clientes.

Las áreas de desarrollo que cubrimos son principalmente desarrollo web y diseño y desarrollo de aplicaciones móviles. Además de esto, también ofrecemos desarrollos de software nativos para pequeñas y grandes empresas.

Lo que buscamos es una plantilla para cada área de desarrollo, algo en lo que podamos basar futuras propuestas.

¿Cómo haces para escribir algo como esto? ¿Son los recursos para ayudar en internet?

Más importante aún, ¿qué dirían ustedes que es importante incluir en una propuesta? Esto normalmente es una "especificación técnica en profundidad" previa, pero sugeriría (por ejemplo) incluir una estructura alámbrica o una maqueta del producto terminado. ¿Qué tan detallado debe ser para retratar el proyecto al cliente y comprender las necesidades del proyecto usted mismo para poder cobrar en consecuencia?

¿Cómo haces para escribir algo como esto? ¿Son los recursos para ayudar en internet?

Por lo general, las plantillas que miro son las plantillas ReadySET .

Comenzaría mirando las plantillas de Propuesta de proyecto , Plan de proyecto , Necesidades de recursos , Mercado objetivo y beneficios , y Necesidades de usuario para ver el tipo de información que se usa típicamente durante el inicio del proyecto. Probablemente obtendrá una buena idea del tipo de información que necesita capturar al principio de un proyecto a partir de estas plantillas.

Una advertencia que siempre brindo cuando hablo de plantillas: asegúrese de adaptarlas a las necesidades de su equipo, proyecto, organización y cliente.

Más importante aún, ¿qué dirían ustedes que es importante incluir en una propuesta?

Depende de quién está usando el documento y qué dicen los requisitos para producir. Normalmente, esto debe abordarse caso por caso. Soy un defensor de la documentación ágil / esbelta , especialmente principios tales como viajar ligero (solo produciendo lo que necesita producir para capturar decisiones y el estado actual del sistema, y ​​nada más) y documentación "apenas lo suficientemente buena" .

Este es el patrón que creo que es apropiado:

1. Comience siempre presentándose, lo que hace su empresa y lo que puede hacer por su posible cliente.

2. Defina un problema, los clientes deben estar satisfechos.

3. Proponer una solución.

4. Determina los costos.

5. Defina los TÉRMINOS: pago, entregables, qué está incluido, qué no (soporte, etc.) y sea claro al respecto.

6. Datos de contacto.

Una propuesta debe ser genérica, pero dirigida al cliente y hacer que se sienta como si la propuesta fuera solo para él. No es tan diferente como en la programación de genéricos:

class Proposal<E>

private Proposal proposal<ClientX>

(Esta parte es mi opinión personal, sé que otros no estarían de acuerdo) - Ah, y use un PDF personalizado con un bonito diseño de fondo (bonito pero elegante, serio). He estado tanto en el envío como en la recepción de una propuesta, y cuando eres una empresa web, involucrada en el diseño, cómo te presentas en cada aspecto cuenta. Un PDF blanco (o peor, .doc o cualquier otro formato) no es una buena presentación.

Haga una breve lista de lo que cree que debería incluirse. Puede buscar ejemplos que tengan la mayor cantidad de vueltas. Google Docs tiene varias plantillas.

Revise sus propuestas anteriores y haga un pequeño informe sobre cómo fueron aceptadas por los clientes. Además de ser inconsistente, puede haber otros problemas, especialmente si los clientes le piden que lo vuelva a hacer por el mismo motivo.

No tenga una plantilla que intente incluir todo sin la capacidad de eliminar elementos innecesarios. Nadie quiere leer una página de elementos con "NA". Evite la tentación de tomar una propuesta previa para un cliente similar y editarla para una nueva. Es como copiar y pegar grandes bloques de código.

Pregúntele al cliente qué formato prefiere, pero proporcione una lista de opciones. Nunca se sabe lo que requieren sus usuarios finales. No desea que hagan una presentación de su propuesta después de que se haya impreso y escaneado en PowerPoint. Las hojas de cálculo son buenas si quieren hacer un poco de matemática. Nunca sabes; en realidad pueden querer agregar algo al proyecto.