Modelos / requisitos da proposta de projeto [fechados]


11

Ao elaborar uma proposta de projeto, você usa algum modelo padrão?

Quais recursos / informações devem ser incluídos? O que é bom ter incluído? Que tipo de informação sobre a placa da caldeira devo colocar?

Você acha algum padrão ou conceito de design particularmente útil?


É uma proposta de projeto interno ou para um cliente?
VirtuosiMedia

Em geral, para um cliente.
Incognito

Respostas:


5

Você já olhou o Modelo de Requisitos Volere ?

Embora contenha detalhes demais para o meu gosto, principalmente para uma proposta (é mais adequado para especificações detalhadas de requisitos iniciais), os títulos das seções são uma ótima lista de verificação para garantir que você tenha pensado em todas as diferentes partes móveis antes fornecendo uma estimativa ou criando um documento de proposta.

Aqui estão eles:

CONTROLADORES DE PROJETO

  1. O objetivo do produto
  2. Cliente, Cliente e outras partes interessadas
  3. Usuários do produto

RESTRIÇÕES DO PROJETO

  1. Restrições obrigatórias
  2. Convenções e definições de nomenclatura
  3. Fatos e Premissas Relevantes

REQUISITOS FUNCIONAIS

  1. O escopo do trabalho
  2. O escopo do produto
  3. Requisitos funcionais e de dados

REQUISITOS NÃO FUNCIONAIS

  1. Requisitos de aparência
  2. Requisitos de usabilidade
  3. Requisitos de desempenho
  4. Requisitos operacionais
  5. Requisitos de manutenção e portabilidade
  6. Requisitos de segurança
  7. Requisitos culturais e políticos
  8. Requerimentos legais

QUESTÕES DO PROJETO

  1. Edições em aberto
  2. Soluções prontas para uso
  3. Novos problemas
  4. Tarefas
  5. Cutover
  6. Riscos
  7. Custos
  8. Documentação e treinamento do usuário
  9. Sala de espera
  10. Ideias para soluções

O link para o documento está quebrado
mclark1129 10/10

Parece que eles mudaram seu site. Vou atualizar a referência.
Paddyslacker

3

Eu uso um modelo padrão? sim

Quais recursos / informações estão incluídos, é bom ter:

  • Folha de capa
  • Meta Data: Informações de Contato do Cliente, Informações de Contato do Desenvolvedor, Nome do Projeto, Data
  • Perfil do cliente (opcional, mas bom): inclui informações, produtos ou serviços do concorrente vendidos pelo cliente, situação e objetivos atuais, mercado-alvo, posição no mercado. As pequenas empresas comuns não podem fornecer a maioria delas.
  • Visão geral do projeto: inclui detalhes em formato de estrutura de tópicos. É aqui que o trabalho do projeto é definido.
  • Não incluído: itens especificamente omitidos no projeto.
  • Materiais iniciais: Uma lista de itens necessários para o cliente começar, bem como as datas em que são necessários.
  • Mapa do site: opcional, mas bom se você estiver criando um site ou aplicativo complexo. Belo gráfico.
  • Dados demográficos: do usuário final, geralmente na forma de um bom gráfico.
  • Resumo criativo: opcional. Isso é para designers e inclui itens como histórico de comunicação, mensagem, personalidade e tom, público-alvo (mentalidade atual) e público-alvo (mentalidade resultante), sites de concorrentes, sites de exemplo ou produtos preferidos pelo cliente, cores da empresa, guia de estilo (geralmente externo). Ele documenta materiais existentes, como logotipos, brochuras etc.
  • Cronograma do projeto: Um detalhamento de quando as coisas devem ser feitas com a data final estimada de conclusão. Meu modelo tem um grande aviso de que as linhas do tempo dependem muito da participação do cliente.
  • Repartição dos custos: o custo das diferentes tarefas a serem executadas. Quando possível, esta seção também inclui uma análise de "retorno do investimento".
  • Contrato do projeto: condições de pagamento, dinheiro sério, garantia de devolução do dinheiro de 100%, ponto de contato único necessário, materiais e aprovações fornecidas pelo cliente precisam ser oportunos, cobrança ou tempo extras se o cliente alterar o escopo do trabalho, hospedando informações (para sites) , direito de usar o trabalho para autopromoção, leis aplicáveis, declaração de propriedade do código-fonte, disponibilidade de garantia do software, assinaturas.
  • Sobre nós: inclui informações da empresa com fotos, exemplos de nosso trabalho, depoimentos, outros serviços oferecidos, perfil da equipe com fotos.
  • Conclusão: Obrigado e informações de contato.

Placa da caldeira: Tanto quanto possível. Todas as opções acima têm algo mesmo que seja apenas texto de preenchimento. Este artigo foi influente para mim: http://articles.sitepoint.com/article/bulletproof-web-design-contract

Minhas propostas geralmente são de 14 a 20.


2

Existem muitas maneiras diferentes de fazer isso.

Aqui está um que eu achei que aprovaria - ele tem a abordagem de freelancer, mas realmente é isso que você quer fazer:

http://tutorialblog.org/writing-a-project-proposal/

Existem muitos guias online. O truque é saber qual deles atenderá às suas necessidades. Eu ensinei uma classe nessas coisas. Meu artigo endossado realmente parece ser a essência do que os clientes querem e o que deve levá-lo à porta.

Isso NÃO substitui um plano de projeto, que pode ser um animal mais elaborado.


você se importaria de explicar isso com mais detalhes - como e por que o "artigo aprovado" responde à pergunta? "Respostas apenas para links" não são bem-vindas no Stack Exchange
gnat

2

Quando se trata de modelos, acho os modelos ReadySET bastante sólidos. Esses modelos abrangem os principais pontos do ciclo de vida - planejamento, requisitos, design, implementação, teste, implantação / instalação, suporte e finalização do projeto.

Algo a ter em mente, porém, é que os modelos devem ser modificados para se ajustarem ao projeto e aos processos. Muito raramente, você pode simplesmente retirar um modelo de um livro ou da Internet e usá-lo. Acho os modelos mais úteis para determinar quais informações devo ter em algum lugar de cada fase e deixo o projeto determinar como e onde as informações são capturadas.


0

O Departamento de Defesa dos EUA trabalhou muito no desenvolvimento de um conjunto completo de descrições de itens de dados (modelos) para acompanhar o DOD-STD-2167A e, posteriormente, o MIL-STD-498 .

Há um velho ditado: "Os regulamentos da Marinha estão escritos em sangue". Se você ler os DIDs com atenção, é provável que perceba que cada linha deles está escrita no sangue de gerentes de programas cujos projetos sofreram uma morte horrível porque negligenciaram o item nessa linha.

Você poderia fazer coisas piores ao olhar para elas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.