Exemplos e recursos para escrever uma proposta de desenvolvimento para um cliente [fechado]

Estamos analisando nossos processos e relacionamentos com os clientes no trabalho e parte disso é a criação de um modelo padronizado para nossas propostas de desenvolvimento que enviamos aos clientes.

As áreas de desenvolvimento que cobrimos são principalmente desenvolvimento e design da Web e desenvolvimento de aplicativos móveis. Além disso, também oferecemos desenvolvimentos de software nativos para pequenas e grandes empresas.

O que estamos buscando é um modelo para cada área de desenvolvimento, algo em que possamos basear futuras propostas.

Como você escreve algo assim? Os recursos para ajudar na internet?

Mais importante, talvez, o que vocês diriam que é importante incluir em uma proposta? Normalmente, essa é uma especificação técnica anterior à "profundidade", mas eu sugiro (por exemplo) que inclua uma estrutura de arame ou maquete do produto acabado. Quão detalhado você deve estar para retratar o projeto para o cliente e entender as necessidades do projeto para cobrar adequadamente?

Como você escreve algo assim? Os recursos para ajudar na internet?

Normalmente, os modelos que eu olho são os modelos ReadySET .

Eu começaria examinando os modelos Proposta de projeto , Plano de projeto , Necessidades de recursos , Mercado-alvo e benefícios e Necessidades do usuário para ver o tipo de informação que normalmente é usada durante o início do projeto. Você provavelmente terá uma boa idéia do tipo de informação que precisa capturar no início de um projeto a partir desses modelos.

Uma palavra de cautela que sempre forneço ao falar sobre modelos - certifique-se de adaptá-los às necessidades de sua equipe, projeto, organização e cliente.

Mais importante, talvez, o que vocês diriam que é importante incluir em uma proposta?

Depende de quem está usando o documento e o que os requisitos dizem para produzir. Normalmente, isso precisa ser tratado caso a caso. Sou um defensor da documentação ágil / enxuta , especialmente princípios como viajar com pouca bagagem (produzindo apenas o que você precisa produzir para capturar decisões e o estado atual do sistema, e não mais) e documentação "apenas mal o suficiente" .

Este é o padrão que acredito ser adequado:

1. Sempre comece se apresentando, o que sua empresa faz e o que você pode fazer pelo seu possível cliente.

2. Definir um problema, os clientes precisam estar satisfeitos.

3. Propor uma solução.

4. Determinar custos.

5. Defina TERMOS: pagamento, entregas, o que está incluído, o que não está (suporte, etc ...) e seja claro.

6. Informações de contato.

Uma proposta precisa ser genérica, mas dirigida ao cliente e fazê-lo sentir como se a proposta fosse apenas para ele. Não é tão diferente quanto na programação de genéricos:

class Proposal<E>

private Proposal proposal<ClientX>

(Esta parte é minha opinião pessoal, sei que outras pessoas discordariam) - Ah, e use um PDF personalizado com um bom design de plano de fundo (agradável, mas elegante, sério). Eu estive no final de envio e recebimento de uma proposta e, quando você é uma empresa de web envolvida no design, como você se apresenta em todos os aspectos conta. Um PDF branco simples (ou pior, .doc ou qualquer outro formato) não é uma boa apresentação.

Faça uma pequena lista do que você acha que deve ser incluído. Você pode procurar por exemplos que tenham mais sobreposições. O Google Docs possui vários modelos.

Revise suas propostas anteriores e faça uma pequena análise sobre como elas foram aceitas pelos clientes. Além de apenas ser inconsistente, pode haver outros problemas, especialmente se os clientes solicitarem que você refaça pelo mesmo motivo.

Não tenha um modelo que tente incluir tudo sem a capacidade de remover itens desnecessários. Ninguém deseja ler uma página de itens com "NA". Evite a tentação de obter uma proposta anterior para um cliente semelhante e editá-la para um novo. É como copiar e colar grandes blocos de código.

Pergunte ao cliente qual formato ele prefere, mas dê uma lista de opções. Você nunca sabe o que é exigido pelos usuários finais. Você não deseja que eles façam uma apresentação da sua proposta depois de impressa e digitalizada no PowerPoint. As planilhas são boas se eles querem fazer um pouco de matemática. Nunca se sabe; eles podem realmente querer adicionar algo ao projeto.