No processo tradicional o cliente exige que sejam fornecidos um prazo e um preço, a partir uma lista de requisitos que definem o escopo do projeto. Nesse modelo é comum o fornecedor fornecer a proposta baseada em premissas que ele mesmo definiu a partir do seu próprio entendimento do que foi escrito no escopo.
a partir do escopo, Premissas sobre o escopo, Gordura no projeto ou prejuizo. É comum que algumas dessas premissas estejam erradas, já que existem diversas formas de se implementar uma mesma funcionalidade. O fornecedor então adiciona ao seu preço um valor adicional de margem de risco para tentar cobrir eventuais erros de estimativa que tenha tido. E aí duas coisas podem acontecer: 1) O cliente paga mais do que deveria pelo serviço, pois pagou pela gordura que não foi utilizada; 2) O fornecedor leva prejuízo, pois a gordura colocada no preço do projeto não foi suficiente para cobrir as discrepâncias.
parte dos casos o prazo e preço são subestimados. No momento da execução dos serviços o cliente detalha o escopo e solicita mais funções, que do ponto de vista dele era uma interpretação do que estava escrito, mas do ponto de vista do fornecedor são mudanças no escopo.
fornecedores de software precisam entender de uma vez por todas que se tem alguma coisa que é sempre comum em todos os projetos é que o escopo irá mudar. Vai mudar por que é software, é digital, é flexível, é maleável. Ele tem que mudar, o cliente precisa ter a flexibilidade para mudar, e a mudança não pode ser um problema.
Nenhum ser humano é capaz de prever de antemão e com exatidão, o que será necessário desenvolver num software que demandará mais de 3 meses de desenvolvimento. Qualquer tentativa de elencar tudo que é necessário desenvolver é em vão. É como pedir para uma criança de 6 anos de idade escrever em uma folha de papel em branco tudo que ela vai precisar para a vida dela inteira. Ela não tem essa noção, pois ainda não explorou a vida.
um processo de descoberta, então a melhor coisa que se pode ter é a possibilidade de fazer escolhas sobre o que será desenvolvido após usar uma parte do sistema. Somente depois de experimentar na prática uma parte do sistema, é que as pessoas têm condição de definir o que é mais importante desenvolver naquele momento e dessa forma iterativa, reduzir o desperdício.
exemplo, não sofre os limites da física, como numa construção tradicional, ele pode ser qualquer coisa. Por ter essa característica é comum que as pessoas sempre desejem que seus aplicativos tenham mais e mais e mais funcionalidades. Estatísticas do Standish Group. A melhor forma de administrar um projeto de software é rever permanentemente as prioridades do projeto e assegurar que apenas funcionalidades essenciais, isto é, que serão usadas de verdade, sejam colocadas no sistema. Só é possível saber quais são estas funcionalidades ao longo do desenvolvimento, enquanto o cliente aprende com o software que está sendo construído, especialmente quando o desenvolvimento é iterativo.
uma solução necessariamente seja a mesma imaginada originalmente é pouco produtivo, porque raramente acontece. A possibilidade de aprender e aprimorar a solução não é algo ruim. Pelo contrário, é extremamente positivo, podendo significar economia de dinheiro e tempo tanto para o cliente, quanto para a empresa que faz o desenvolvimento.
um prazo, mas não um escopo! Assim, permite-se que o escopo absorva as incertezas do projeto. Neste caso, o cliente continua sabendo o quanto irá gastar, bem como quanto tempo o projeto irá durar. O que ele não sabe com exatidão é o que irá receber. Mas, na verdade, ele não sabia disso no caso do contrato de escopo fixo, ele apenas tinha a ilusão de saber, a ilusão da previsibilidade do escopo. Portanto, ele não perdeu absolutamente nada, apenas assumimos uma relação contratual mais honesta e realista.
investimento, provisione o retorno que ele irá gerar a você no longo prazo. Se o seu core-business é uma plataforma de software - ou seja: se seu produto É um software - se prepare, pois você precisará investir nele constantemente ao longo do tempo. Não espere que um dia ele “estará pronto”. Você sempre irá precisar evoluir ou simplesmente estará fora do mercado.
mergulhao
ryder472
sudoakiy
fumiyasac0921
takumiogawa
emiki
blueb
ysknsid25
tenshoku_draft
oracle4engineer
sonatard
kamina_zzz
4su_para
danielanewman
maggiecrowley
marktimemedia
honnibal
dougneiner
hatefulcrawdad
addyosmani
eileencodes
maltzj
garrettdimon
