Como competir em um escassos spec'd projeto para evitar team death-março [fechado]

https://stackoverflow.com/questions/1370425

21-09-2019
|

Pergunta

Eu sou do tempo+estimativa de custos de um semi-complexa solução de software, que não tem requisitos específicos em cerca de 75% dos recursos.Eu ainda gostaria de fazer, como boa estimativa possível, e para obter dados adicionais do cliente.Ainda haverá partes que podem acabar por não ser capaz de desenvolver, desde há muitos dependências com outros produtos/tecnologias e a falta de definição.Eu também tenho um cronograma muito apertado para produzir esta estimativa.

Também haverá outros candidatos neste projeto.Cliente espera de um preço+duração (e, provavelmente, também apresenta) e eu sei que todo mundo vai estar fora.Eu sei que é impossível, mas dizer que as pessoas de marketing.Outro problema é que eu estou a falar para o meio-homem e não diretamente para o cliente. Eu posso obter a confiança com o meio-homem só, mas não com a decisão do cliente. O que é um problema completamente diferente.

O que disclaimer/info posso colocar na minha lista de preços/contrato não matar equipe com este projeto, portanto, quando o projeto começa a escorregar (em termos de custo/tempo/recursos) vamos ser coberto com algum tipo de pagamento.Eu seria, claro, gostaria de ser pagos pelos sprints ou lançamentos com relação ao tempo, mas eu duvido cliente poderia ser convencidos a esta.Eu tenho certeza que nós podemos terminar este produto antes do prazo e também criar um ótimo produto, mas como posso convencê cliente acredita em mim?

Pergunta

O que posso fazer para obter esse projeto e evitar a morte de março situação ao mesmo tempo?

Qualquer sugestão bem-vindo!

EDITAR:Resultado

No final, nós (eu e meus colegas de trabalho) convenceu o cliente que precisa de pelo menos uma semana para avaliar o produto.E assim fizemos.Nós também empurrado (e tem) um slot para algumas horas de reunião com o cliente para esclarecer quaisquer requisitos pendentes' perguntas.E assim fizemos.A reunião foi feito depois que fez a primeira estimativa do projecto, assim, tínhamos certeza de que temos todas as perguntas para apontar as especificidades que foram completamente incompreendido ou demasiado vaga para estimativa.Eu espero que nós tenhamos o projeto, porque isso significaria 8 meses de trabalho em tempo integral para nós, além de um razoável pagar.Vamos saber em cerca de uma semana e meia.

É claro que eu também apontou que a maneira como vai ser a entrega deste produto será obtê-los exatamente onde querem estar com um produto que vai ser realmente o que eles queriam.E também que nós cometemos de preço e de hora, mas não funcionalidade, porque é e será sujeito a alteração.Eu acho que fizemos uma boa impressão.

Solução

Bem-vindo ao mundo de fixo a preços de serviços de desenvolvimento :-)

Técnicas para ganhar este projeto e evitar a morte de março de situação ao mesmo tempo:

Não underbid um projeto.Lance para o que você acha que o projeto vai tirar e adicionar alguns percentagem de coisas susceptíveis de dar errado.
Se você estiver faltando 75% de detalhe, as probabilidades são de que o projeto será significativamente diferente do que o que você espera.Documento algum detalhe razoável pressupostos dentro da hierarquia do trabalho definido.Quando o projeto começa de facto e os detalhes não coincidir com a suposição, você tem uma oportunidade para negociar os custos para as mudanças.Nesse momento, você também pode estar em uma posição melhor para saber o quanto você está por cima/por baixo e tentar compensar com esta citação.
Seu objetivo em um SOW (instrução de trabalho) deve ser o de definir detalhes suficientes de modo a que ele dá a você uma oportunidade para renegociar o custo de alterações quando você a saber mais sobre o projeto.Escreva como positivos, tanto quanto possível.Nota, é improvável que as pessoas que realmente entendem o projeto vai ler ou compreender a SEMEAR...essa base que eu o ponto em que você está dado poucos detalhes para citação.Isso significa que ele não é uma venda consultiva e nem o partido está realmente focado na construção de 'direito' solução.
Se você pode obter um contrato, como em T&M (tempo e material) grande.Eu duvido que você vai conseguir ou não conseguir obtê-lo sem algumas restrições que, essencialmente, derrota o propósito de um T&M.Seus clientes em potencial olhar para isso como eles aceitar todos os riscos em torno de suas habilidades.
Espero que, você não é o primeiro na sua empresa para fazer isso.Descubra, historicamente, como os projetos foram e o resultado típico taxas.Muitos de desenvolvimento de software grupos de cobrar uma taxa por hora que é significativamente maior do que o custo...mas suas cotações tendem a ser mais baixos e não real de horas.Muitas vezes os clientes irão argumentar mais sobre as horas/dias que a própria citação.As empresas tendem a ser utilizado para pagar altas taxas de hora em hora.
Descobrir o seu departamento esperado margem (de lucro que você precisa para ganhar do trabalho).Isso pode ajudar você a entender o quanto de uma "morte de março", pode enfrentar quando seu projeto de deslizamentos.
No SEMEAR especificar o nível de detalhe que será necessária uma especificação antes de começar o trabalho.Enquanto Ágil e outras ao cliente com foco em processos de assumir uma abordagem orientada a encontrar a melhor solução, eles não são projetados para manter os custos sob controle, em um lance fixo ambiente.Você vai precisar para tomar uma cachoeira abordagem requisitos e, em seguida, construir de forma ágil para que você possa ajustar ao longo do caminho.A especificação, como o SEMEAR, vai dar-lhe uma oportunidade de projeto de lei para alterações.Enquanto o cliente não vai gostar dessa, ele vai colocar o ônus e os riscos associados com os requisitos e não a sua equipe.

Nota: para ser bem-sucedido com essas negociações, você precisa de uma gestão de suporte, vendas e equipe de gerenciamento de projetos.Se você não tem essa, você está fadado a ser sempre a " morte de marchas.' Mesmo se você abrir mão de qualidade, processo de testes e outros itens, você vai encontrar nunca há tempo suficiente para um projeto.

Outras dicas

Nesse ambiente econômico, há muitas empresas competindo por um pouco de trabalho. Alguém deve dar a eles uma oferta muito doce que vai

Não ser capaz de cumprir,
Mate sua equipe com, ou
Ambos.

Quando não conseguem entregar pelo preço acordado, começarão a reduzir a qualidade para entregar algo e receber o pagamento.

Seu desafio é apresentar esse fato ao seu cliente em potencial de maneira profissional e convencê -los de que você trabalhará muito para entregar a um custo razoável, mas também para entregar exatamente o que eles precisam. O fato de você estar voltando para obter mais detalhes e o método com o qual você aborda o projeto (ágil ... mas tenha certeza e explique o benefício comercial para eles) ajuda a garantir que eles acabem com o que realmente precisam.

Lembre -se, eles querem entregar o software que eles precisam pelo preço mais baixo possível.

Convide -os de que você atenderá exatamente às suas necessidades e que seu preço é razoável.

EDITAR:

Abordando a situação dos médios. Eu acho que o melhor curso de ação seria enviar uma lista de riscos junto com sua oferta como cortesia para o cliente. É como dar a eles um aviso sobre quais são as limitações do projeto. Isso custará algum trabalho com antecedência, mas acho que poderia ajudá -lo a vencer o projeto.

você tem duas opções

Faça um melhor adivinho e dobrar ou triplicar sua estimativa (sua concorrência provavelmente está fazendo a mesma coisa.)

explique Para o cliente, você não pode fazer trabalho assim e diga a ele que todos os outros que lhe dão uma estimativa fixa provavelmente não estão sendo completamente verdadeiros.

No final do dia, se você não conseguir ganhar dinheiro com o trabalho, não há sentido em tentar.

Pessoalmente, prefiro a comunicação final, adiante e honesta com seus clientes, levará você a mais longe do que qualquer truques de lance jamais o fará.

Algumas coisas eu diria que você deve pensar:

Pressupostos: Não há um disclaimer você pode adicionar, mas você precisa para preencher as lacunas com as exigências da sensato pressupostos e documentá-los.Nada de maior ou assustadora, apenas uma seção em seu spec/lance com uma lista de pontos de bala dizendo o que você supõe ser verdade o que estava faltando (por exemplo,os detalhes do usuário será puxado usando LDAP e nenhum admin telas vai ser escrito para cobrir usuário admin).

Isso lhe dá clareza na estimativa de como você agora tem um escopo completo para trabalhar, mas isso também significa que, se o cliente voltar com coisas que são muito diferentes, você tem uma boa base para começar a falar sobre o aumento de pedidos de alteração e variando-se a custo.Como alternativa, eles podem voltar durante as negociações, dizendo: este pressuposto, ou que um não é verdade e você tem mais informações.

Fora do Âmbito de aplicação: Um caso específico de pressupostos - lista de coisas que você não incluindo (por exemplo,Não integração irá existir com o sistema X).Novamente, isso permite que você tenha um escopo completo e razoável, caso potencialmente variação de custos em um estágio posterior.

Pressupostos e fora do escopo são particularmente aplicável quando as coisas são mencionados na passagem, mas não é realmente seguido, ou para as coisas que eles dizem que pode esperar por uma segunda fase.Estes são, muitas vezes, as coisas que o cliente vai acreditar que estão sendo feitas como parte do projeto principal, mas a equipe do projeto não.

Espero que o rigor e a visão dos pressupostos e escopo definir irá ajudar a inspirar confiança com o seu cliente também.

Contingência: Complicado, mas você deve adicionar contingência de duas maneiras:

(1) para riscos específicos.Para coisas que podem significar alguma coisa leva mais tempo do que você já estimou, em seguida, depositar uma quantia para cobrir o que ponderadas pela chance de isso acontecer.Adicionar todos estes e que o seu risco de contingência.

(2) Merda acontece de contingência - imprevisível merda acontece em projetos de TI.Adicionar entre 10% e 20% para cobrir isso.

Se você ocultar contingência de seu comercial de pessoas e o cliente, ou não, depende do seu relacionamento, mas, se ele for removido eles precisam entender o que isso significa (essencialmente, você IRÁ executar).

Compreender a relação entre o esforço e o custo: Como tecnólogo seu papel é o de fornecer uma estimativa de esforço com base nas informações que você tem.Você precisa, em seguida, comunicar-se com suposições, nível de contingência e à sua equipa comercial que pode convertê-lo em um valor monetário.A única coisa a ser claros com eles é que se eles querem largar o custo que não altera o esforço.

Há muitas boas razões para escrever para baixo o custo para o cliente (para construir um relacionamento, porque você vai acabar com as coisas que você pode reutilizar mais tarde, e assim por diante), mas as pessoas precisam entender que, a menos que as mudanças de escopo do esforço permanece o mesmo - a redução sai do lucro.

Eu tenho um artigo do blog que pode ter algumas dicas para você:

http://pm4web.blogspot.com/2009/06/surviving-under-sourced-project.html

Um dos outros pôsteres aqui tem um bom ponto. Sempre haverá alguém que oferecerá um preço mais baixo para obter o trabalho. E o desenvolvedor sofrerá mais tarde (ou seja, ter que fazer muito trabalho gratuito para satisfazer o cliente).

Alguns clientes precisam ter essa experiência antes de clicar que você não pode fazer projetos baratos sem pagar algum tipo de preço.

Vá para o realismo. Evite prometer demais e faça questão disso.

Muitos clientes por aí foram queimados por ofertas irrealistas que não conseguem entregar conforme prometido.

Enfatize a necessidade de um sprint de especificações. Transmitir um foco na funcionalidade central e no compromisso de entregar, em vez de um recurso Bonanza. Ofereça uma fase de desenvolvimento primário para fornecer funcionalidade central.

Comunicar o poder e a segurança da abordagem ágil. Credite o cliente com a capacidade de ver o bom senso.

Em resumo: lute para parecer realista e sério (mais do que seus concorrentes). A coisa mais importante para qualquer cliente sério no final é não o preço, mas uma confiança de que o produto será entregue no prazo e no orçamento.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow