Diferença entre o planejamento de um projeto e o planejamento de um produto

5

Li em vários lugares que, ao desenvolver um produto, é preciso adotar uma abordagem diferente para quando você está desenvolvendo um projeto (pense em "contrato").

Algumas diferenças são:

1) Não há usuário definitivo, mas uma "base de usuários".

2) Você precisa desenvolver o conjunto de recursos comercializáveis mínimo.

3) O agendamento precisa ser observado, pois muitas vezes não há um prazo fixo que é possível para o produto executar horas extras (ou para escalonamento de escopo).

Eu queria saber se há pessoas por aí com experiência em ambos, e se eles poderiam oferecer alguma contribuição para qualquer diferença que eles saibam. Além disso, se alguém puder fornecer algumas dicas / boas referências sobre como lidar com as diferenças, eu ficaria muito grato.

    
por Aidos 21.05.2012 / 12:45
fonte

5 respostas

4

Algumas diferenças significativas:

  • Um projeto geralmente é limitado por tempo . Um produto tem uma vida útil geralmente não é conhecida no momento do desenvolvimento - sua suposição deve ser que, se for bem-sucedido, você terá um negócio em andamento.
  • Um projeto precisa ser entregue em relação a entregáveis especificados . Um produto precisa oferecer um negócio contínuo viável . Adivinha qual é mais difícil: -)
  • É realmente fácil terceirizar um projeto. O desenvolvimento de produtos de terceirização geralmente é uma ideia muito ruim (dica: você não deve terceirizar sua competência principal!)
  • Como os produtos são (geralmente) focados externamente e planejados para dimensionar, a qualidade tende a se tornar mais importante como um fator de sucesso.

Acho que as diferenças listadas na pergunta não são diferenças intrínsecas entre produtos e projetos. Você pode imaginar o lançamento de um produto com um conjunto completo de recursos, por exemplo. Um projeto pode ter uma "base de usuários" ampla e vagamente definida. E ambos os produtos e projetos provavelmente terão problemas com escalonamento de planejamento / escopo: -)

    
por 21.05.2012 / 13:24
fonte
1

Isto é maçãs e laranjas. Não há comparação como se um fosse exclusivo do outro. Pode-se e deve-se trabalhar em projetos para o benefício do produto.

As qualidades de construir um produto definitivamente se concentram em 1 e 2, no entanto, 3 não é totalmente correto. Simplesmente porque é um produto não significa que o escorregamento do escopo seja mais aceitável ou menos perigoso. Ao determinar o trabalho do produto, deve-se ajustar o desenvolvimento de recursos viáveis em um ou mais projetos, pois é importante atender às necessidades do cronograma e manter os custos sob controle.

O fato é que o "produto de software" é parcialmente um termo de marketing. Se eu tenho um software funcional de qualidade razoável, então posso marcá-lo, anunciá-lo e tentar vendê-lo a vários clientes.

Quando o design de software entra em jogo, a combinação inteligente de conjuntos de recursos personalizáveis para uma variedade diversificada de clientes torna um produto de software tal que a necessidade de desenvolvimento personalizado para conquistar um único cliente é mantida a um mínimo, se possível. Isso pode ser extraordinariamente difícil de fazer.

Se a sua organização estiver usando a desculpa de que o trabalho com o produto torna o escopo do rastreamento e os prazos flutuantes aceitáveis, eles estão apenas inventando desculpas.

    
por 21.05.2012 / 13:25
fonte
1

Ao planejar um projeto, você precisa considerar o seguinte:

  1. Escopo
  2. Partes interessadas
  3. Recursos
  4. Restrições
  5. Nível de qualidade
  6. Custo

Considerando que, ao planejar um produto, é necessário considerar o seguinte:

1. Características genéricas: Componente essencial do produto, as características sem as quais o produto não existe.

2. Recursos esperados: Recursos geralmente assumidos ou esperados pelo cliente alvo

3. Recursos adicionais: Recursos que adicionam mais força e valor ao produto

4. Recursos potenciais: Recursos que visam tornar o produto único e distinto e, portanto, contribuem para a retenção de clientes.

    
por 21.05.2012 / 16:05
fonte
0

Todos os seus três pontos podem se aplicar a um projeto também. Isso pode ajudar a visualizar um exemplo real: desenvolver um sistema de faturamento interno para uma empresa grande (projeto) versus escrever um sistema de faturamento para ser vendido amplamente (produto).

Algumas diferenças:

1) Você pode se contentar com "apenas bom o suficiente" no projeto. O produto tem expectativas de qualidade mais altas.

2) Você tem que acompanhar muito mais configurações de hardware e software com um produto.

3) É mais provável que os usuários sejam remotos em um produto. É mais difícil, mas não impossível, obter dados de uso.

4) Com um produto, é mais provável que você deixe a integração para outra pessoa.

    
por 21.05.2012 / 13:46
fonte
0

Eu trabalhei para uma pequena empresa de software durante o tempo em que eles lançaram novas versões para lidar com o Y2K. Para mim, as maiores diferenças envolvem o controle e a consistência dos usuários e seus ambientes.

  1. As configurações do computador do usuário serão mais consistentes.
  2. Os usuários geralmente são mais bem treinados (exceto se seu mercado é profissional de TI) ou possuem um departamento de TI.
  3. Os contratos de trabalho dão a você mais acesso aos sistemas do usuário, caso precise ajustar uma instalação.
  4. O buy-in do usuário pode ser complicado em situações de contrato, se houver lutas internas e políticas em andamento. Muitos usuários não querem mudanças. Espero que um cliente que esteja comprando software comercial realmente queira usá-lo.

Eu não acho que as demandas de tempo sejam tão diferentes porque alguém ainda está pagando pelo seu tempo e pode estar perdendo negócios ou produtividade porque eles não têm o seu aplicativo (não é por isso que eles estão comprando primeiro lugar?). Se você está criando algum aplicativo social gratuito e usando dinheiro emprestado, os investidores querem ver um produto o quanto antes.

    
por 21.05.2012 / 18:40
fonte