como você lida com uma proposta de software vaga?

Eu faço o máximo que posso com o que é não vago (que em alguns casos não tem sido nada, se você não incluir a configuração do espaço de trabalho e nomear o projeto), e então enviar Um e-mail para os supervisores dizem "Preciso obter detalhes sobre os requisitos X, Y e Z ou não posso prosseguir". Se o supervisor disser "faça assim mesmo!" Eu então os pressiono para explicar o que devo fazer, e peço uma alocação de tempo para desfazer e corrigir quando meu código inevitavelmente não atende aos requisitos atrasados. Mesmo que o supervisor / chefe de equipe não goste disso, garante que eles sabem que o progresso está sendo bloqueado pela falta de requisitos.

Se eu estou lidando diretamente com um cliente, digo-lhes claramente o que preciso. Se eles não puderem me responder imediatamente, digo que o trabalho só começará depois que nós concordarmos com os requisitos. Novamente, isso nem sempre é popular, mas economizou uma quantidade significativa de esforço desperdiçado com clientes que, em alguns casos, nunca receberam os requisitos de volta para mim.

Você não esperaria que alguém construísse um edifício de escritórios com requisitos vague , por que alguém esperaria que você criasse software com requisitos igualmente vague ?

Sem requisitos concretos de recursos, você tem a garantia de falhar! Como você nunca conseguirá atender o que o cliente tem ou não tem em mente como expectativas.

Desenvolvimento de software Metodologias Ágeis como o SCRUM existem para forçar esta questão, você só trabalha no que é mais importante, se eles não podem dizer o que é importante do ponto de vista de um valor de negócios, por que você deve saber o que fazer ?

Além de

• Concentre-se nas coisas que são concretas e construídas em torno dessas
• Envolva o autor da proposta (cliente?) o mais rápido possível o quanto antes
• Planeje várias iterações como parte do plano de desenvolvimento (escolha sua metodologia iterativa favorita ...)
• Construa portões de aceitação / revisão no projeto (ou seja, se tudo mais falhar, talvez seja necessário propor uma solução, que o cliente deve aceitar, ou fornecer comentários sobre por que não é aceitável)
• Certifique-se de que o Gerente de projetos tenha calculado vários tempos de buffer & dinheiro: -)

Considere também

• Ir para uma especificação arquitetônica (com base em produtos / tecnologias existentes / o que for) - propor e discutir algo concreto pode ser útil para extrair as funções / comportamentos mais abstratos do cliente
• Tente entender o problema do ponto de vista do cliente e veja os problemas que eles estão tentando resolver e veja como outras soluções resolvem problemas semelhantes (por exemplo, uma proposta que diz "Adicionar segurança" pode ser expandida razoavelmente bem com base em um entendimento do domínio do problema (formulário web bancário vs marketing)
• Construa um protótipo - ele resolverá o problema da "experiência só vai até aí" ou fornecerá um ponto de discussão para o cliente, ou deixará claro o que pode ser alcançado no orçamento e o que é impossível.
• Escreva para o "Espaço negativo" na especificação funcional ... liste o que o produto não fará para que você tenha algum controle de escopo. As peças que você simplesmente não consegue fazer no tempo / orçamento são listadas como "fora" e você pode negociar / discutir / fazer um passe nas outras áreas que são fáceis de implementar / mudar à medida que o projeto avança

Assumi que você está fazendo isso como parte da redação da proposta e, eventualmente, o cliente poderá responder às suas perguntas, se não, pergunte seriamente à gerência se vale a pena assumir o risco do projeto / cliente (quem sabe, talvez o cliente simplesmente não se importa?)

Seja criativo, trabalhe pelo exemplo. Preencha alguns espaços em branco e tente apresentá-los para eles mais cedo. Ouça e (re) trabalhe sua descrição / código funcional com o feedback deles.

Desenvolva pelo exemplo. Bill por hora.