Instantly share code, notes, and snippets.

Embed
What would you like to do?
O Ciclo Vicioso Do Software Retranqueiro
We couldn’t find any files to show.
@klauswuestefeld

This comment has been minimized.

Owner

klauswuestefeld commented Jan 11, 2012

O Círculo Vicioso do Software Retranqueiro
por Klaus Wuestefeld

Projetos de desenvolvimento de software fracassam. Fracassam notoriamente e fracassam feio. De acordo com o Gartner Group, 80% a 90% dos projetos de TI fracassam, sendo cancelados ou entregues com prazo ou com o orçamento estourados.

Mas qual é a importância disso, afinal? Por que as organizações dependem tanto do desenvolvimento de software próprio? Por que não podem simplesmente comprar todo seu software pronto?

É claro que não estamos falando de commodities como sistemas operacionais ou software para automação de escritório. Assim como a escolha da marca de clips, cada vez menos importa qual editor de textos ou qual ambiente gráfico vai-se usar.

A maioria das empresas depende também dos famosos "pacotões": folha de pagamento, controle de estoque, contas a pagar, etc. Embora eles ainda tragam muitos problemas de implantação e integração, principalmente em grandes organizações, também não é a escolha do "pacotão" que vai GARANTIR vantagem competitiva a essa ou aquela empresa.

Onde é que a coisa pega, então? Qual é o tipo de software que realmente faz a diferença?

Organizações como restaurantes, grupos de teatro, clínicas médicas e bandas musicais não ligam muito para software. No caso delas, o que importa mesmo é a experiência, o conhecimento tácito de seus integrantes.

Para grande maioria das empresas, porém, informação e conhecimento explícito estão, cada vez mais, definindo o resultado do jogo. É justamente nos sistemas centrais dessas organizações, portanto, que agilidade e qualidade no desenvolvimento de software fazem a diferença entre o sucesso e a morte.

Software é a única coisa que consegue representar conhecimento explícito e, ao mesmo tempo, botá-lo para trabalhar em favor da empresa, em vez de ficar fazendo volume numa prateleira ou num lindo repositório de documentos.

Software é conhecimento explícito por excelência.

Jamais conseguirá uma empresa superar a outra, se comprar exatamente o mesmo software de prateleira para seu sistema central. O máximo que conseguirá atingir com isso é a mediocridade e, não sendo capaz de alterar esse mesmo software para capturar seus conhecimentos adquiridos frente ao dinamismo do mercado, ficar estagnada é o que lhe resta.

Mas por que isso acontece? Por que, mesmo sendo cada vez mais importantes para as organizações, os projetos de software continuam fracassando? Quais são as causas dessa situação vergonhosa para a minha profissão, como desenvolvedor de software?

Não existe causa única. Existe um círculo vicioso de causas que se exacerbam mutuamente.

  1. O fracasso da grande maioria dos projetos de desenvolvimento de software causa grandes prejuízos aos clientes.

  2. Os repetidos prejuízos alimentam a desconfiança dos clientes em relação ao desenvolvimento e aos desenvolvedores de software.

  3. A desconfiança faz com que os clientes peçam orçamentos de preço fechado e, em muitos casos, com pesadas multas.

  4. Para fazer orçamentos de preço fechado, os desenvolvedores têm que fazer estimativas precisas.

  5. Para fazer estimativas precisas, os desenvolvedores necessitam de requisitos muito bem definidos.

  6. Para obter requisitos muito bem definidos, cliente e desenvolvedores passam boa parte do tempo de um projeto, mesmo antes de seu início, levantando e detalhando requisitos. Trata-se de um investimento pesado para um projeto que nem se sabe ao certo se vai ser implementado.

  7. Para minimizar esse investimento, que muitas vezes não é pago pelo cliente, os desenvolvedores comprometem a qualidade e abrangência do levantamento de requisitos (ver 10).

  8. Depois de trabalhar tanto na produção de um lindo documento de requisitos, o cliente não quer mais saber de falar com o desenvolvedor até a entrega do sistema final.

  9. O desenvolvedor, por sua vez, dá graças por não ter que aturar o cliente que só serve para atrapalhar, mudar de idéia e perguntar como anda o projeto.

  10. Evitando o contato com o cliente e com pressa, o desenvolvedor passa a supor uma série de coisas a respeito de como o sistema deveria funcionar. Por mais pesado que tenha sido o investimento na fase de requisitos, eles sempre apresentam inconsistências, ambigüidades e omissões. Se não fosse assim, bastaria compilar o documento de requisitos e o sistema estaria pronto.

  11. A maioria das suposições dos desenvolvedores está correta. A minoria, porém, está errada e causa surpresas desagradáveis para o cliente (ver 25).

  12. As surpresas desagradáveis causam retrabalho (ver 24) para o desenvolvedor quando da entrega do produto.

  13. Com pressa, a cada funcionalidade implementada, o desenvolvedor faz apenas alguns testezinhos manuais básicos. Ele não tem tempo para escrever código de teste automatizado para testar seu sistema. A qualidade do software fica prejudicada (ver 23).

  14. O desenvolvedor é proibido de melhorar código que já está funcionando para eliminar as duplicações com novas funcionalidades. "Se tá funcionando, então não mexe!". A complexidade do sistema passa a crescer como uma colcha de retalhos com duplicações, dependências a torto e direito e acoplamento forte entre os módulos do sistema.

  15. A complexidade faz as modificações no sistema serem cada vez mais demoradas e propensas a erro (ver 23).

  16. A demora e o alto custo de modificações atrasam o projeto (ver 10, 13, 21, 25).

  17. Os atrasos causam os ciclos de desenvolvimento a serem cada vez maiores.

  18. Quanto maior o tempo de cada ciclo de desenvolvimento, piores as surpresas, menos freqüente a chance do cliente requisitar novas funcionalidades e maior o tempo de espera.

  19. Quanto maior o tempo de espera, mais funcionalidades o cliente tem que requisitar nas raras chances que consegue: "Quero tudo, o mais configurável, flexível e genérico possível."

  20. Exagero de requisitos torna o software mais complexo (ver 15) e aumenta o tempo de desenvolvimento (ver 16).

  21. Projetos atrasados aceleram ou simplesmente ignoram a fase de testes.

  22. Sem a fase de testes a qualidade que já estava ruim vai pro buraco.

  23. Os defeitos causam retrabalho.

  24. O retrabalho causa atraso (ver 10, 13, 21, 17) e ainda mais defeitos (ver 23).

  25. As surpresas desagradáveis, os defeitos e os atrasos determinam o fracasso do projeto (ver 1).

Desenvolvedores experientes podem facilmente duplicar o tamanho dessa lista de sintomas do círculo vicioso. Todas essas coisas são tão corriqueiras na vida dos desenvolvedores que a grande maioria encara essa situação lastimável como sendo normal, inevitável.

A única forma de um projeto complexo nessas condições ser entregue dentro do prazo e dentro do orçamento é com pessoas excepcionalmente talentosas, experientes e motivadas, ou simplesmente com um prazo e com orçamento absurdamente altos.

Quando não estão preocupados com diagramas mais imponentes, cronogramas mais vistosos e coisas do gênero, os processos de desenvolvimento tradicionais trabalham alguns dos sintomas do círculo vicioso, buscando técnicas melhores para conseguir: levantamento de requisitos mais completos, estimativas mais precisas, modelos mais rastreáveis, etc.

Infelizmente, como em qualquer círculo vicioso, atacar os sintomas é perda de tempo, paliativo no melhor caso. Ainda por cima, para a maioria dos projetos doentes, o mero peso burocrático dos processos tradicionais, por si só, já representa uma quimioterapia por demais brutal. Não é à toa, portanto, que cansamos de ver até desenvolvedores sérios e responsáveis largando o processo, a quimioterapia, e preferindo encarar na raça a doença.

Esses desenvolvedores, cujo talento, como já vimos, é a única chance de sucesso desses projetos, ainda são condenados pelos feitores nas "fábricas de software" (triste metáfora), por não estarem atuando como deveriam: como "máquinas" burras seguindo o processo pseudo-definido.

A influência mais perniciosa nesse contexto todo, porém, ainda são as empresas fornecedoras de ferramentas para desenvolvimento de software e organizações certificadoras de processos. Para vender seu peixe, elas têm interesse em que o processo de desenvolvimento adotado pelo mercado seja o mais complexo e burocrático possível.

Mas será que esse círculo vicioso é realmente inevitável? Será ele um fenômeno da natureza? Ou será que podemos acabar com isso?

Os sucessos alcançados por equipes ágeis vem causando comoção justamente neste mercado cansado das metodologias retranqueiras tradicionais e do notório fracasso de seus projetos. O maior evento nacional de engenharia de software, até 2010, foi o Agile Brasil, onde tive a oportunidade de fazer a palestra de encerramento.

XP e as demais metodologias ágeis simplesmente elevam a um novo patamar o significado de "qualidade" e "agilidade" em desenvolvimento de software.


Sobre o autor:
Pioneiro de Extreme Programming (XP) no Brasil, Klaus Wuestefeld é autor do manifesto da computação soberana e do Prevayler, a camada de prevalência de objetos original. Klaus é sócio-fundador da Objective Solutions e já atuou como desenvolvedor, líder de projeto, gerente e até como cliente em projetos usando XP.

Copyright 2002-2012 Klaus Wuestefeld. Todos os direitos reservados.
Autorizo a publicação deste artigo na íntegra em qualquer meio, incluindo este aviso de copyright.

Twitter: @klauswuestefeld

@yanaga

This comment has been minimized.

yanaga commented Jan 11, 2012

Quanto disso poderia ser evitado sabendo que "Software is cheaper to build than design"?

@klauswuestefeld

This comment has been minimized.

Owner

klauswuestefeld commented Jan 11, 2012

Entendo o intuito da frase mas as palavras tem q ser revistas. Software n tem mais build. Desde o advento dos compiladores, software é só design.

@yanaga

This comment has been minimized.

yanaga commented Jan 11, 2012

É só pra gerar polêmica. "build" e "design" podem ter muitos significados diferentes, mas esse é o espírito da coisa mesmo. O ponto era "big upfront design" vs "iterative design".

@rpepato

This comment has been minimized.

rpepato commented Jan 11, 2012

Numa tentativa de eliminar o sintoma 19, boa parte dos desenvolvedores de software parte para a estratégia de otimização prematura, o que na maioria das vezes, também acaba levando à analysis paralysis, aumentando assim a retro-alimentação do círculo vicioso

@bkmeneguello

This comment has been minimized.

bkmeneguello commented Jan 11, 2012

Infelizmente, não existem tantas "pessoas excepcionalmente talentosas, experientes e motivadas" muito menos projetos com "prazo e com orçamento absurdamente altos" disponíveis por ai. Atualmente vejo um mercado onde as empresas contam com times cheios de programadores braçais, que escrevem código razoávelmente bom, e alguns poucos com talento suficiente para sair da caixa e ver o cenário como um todo, com conhecimento de boas práticas, arquiteturas, etc. Sou desenvolvedor e já vi vários projetos facassarem "funcionalmente" (projetos que são aceitos pelo cliente apesar do desempenho e confiabilidade estarem abaixo do nível realmente aceitável) e sempre acabo frustrado com isso, pois me considero do grupo de apaixonados por código bem feito e organizado. Gostaria muito de saber, como funciona o mercado de software dos grandes centros, pois na minha região (Maringá) o mercado não aceita muito bem as condições necessárias para o desenvolvimento de um projeto ágil (escopo aberto e pagamentos vinculados às entregas), pelo menos foi o que eu já ouvi de um ex-empregador meu. As empresas querem saber quanto elas vão gastar, quanto tempo o projeto vai levar (mesmo sabendo que nada disso vai ser cumprido), enfim, acho que a maioria dos clientes não está preparada para trabalhar com projetos ágeis, sendo essa caracteristica potencializada nos projetos de grande porte.

@felipecruz

This comment has been minimized.

felipecruz commented Jan 11, 2012

A cultura comercial de venda de software esta cheia de vícios de outras áreas comerciais(venda de outros tipos de produtos) e infestada de pessoas que não entendem nada de software..

@rpepato

This comment has been minimized.

rpepato commented Jan 11, 2012

Esse é um outro motivo desse caos todo... Boa parte das pessoas que estão em posições de liderança (gerente, diretor, bla bla bla) de empresas de desenvolvimento de software nunca escreveram uma linha de código na vida e não entendem o que signfica desenvolver software. Aí realmente vira pastelaria.

@bkmeneguello

This comment has been minimized.

bkmeneguello commented Jan 11, 2012

Muitas vezes, os gestores já trabalharam com desenvolvimento, mas mudaram seu foco para a gestão (ou administração) e passam a ficar mais focados em modelos de gestão do que de produção. É nesse momento que começam a usar processos que permitam controlar a produção e são menosprezados os integradores, resultados dos testes, complexidade ciclomática, legibilidade de código, intencionalidade explícita no código, e muito mais ferramentas e práticas que dão segurança ao time de desenvolvimento.

@klauswuestefeld

This comment has been minimized.

Owner

klauswuestefeld commented Jan 11, 2012

Certeza. Eu só acho q o q vc chama de otimização prematura (na minha cabeça está mais relacionado com performance de execução) eu chamaria de Big Design Up Front (BDUF).

@rpepato

This comment has been minimized.

rpepato commented Jan 11, 2012

Sim, é essa idéia mesmo, BDUF.

@nicolasiensen

This comment has been minimized.

nicolasiensen commented Jan 11, 2012

Alguém já participou de um projeto sem cliente? Um projeto pessoal ou opensource?

Quando se trata de uma equipe experiente desenvolvendo um software para uso próprio é impossível entrar neste ciclo vicioso que o Klaus descreveu.

Mas então o problema é o cliente? Claro que não podemos simplesmente dizer "o problema é o cliente", isso é de extrema imaturidade.

A maioria dos projetos no mundo PRECISAM de um cliente, afinal nós (desenvolvedores) não podemos ficar resolvendo apenas os nossos problemas, precisamos resolver os problemas dos outros.

Mas então qual é a solução se o cliente gera problemas, mas ao mesmo tempo não podemos viver sem ele?

A minha resposta é a comunicação.

Saber dizer não ao cliente, compreender a necessidade dele, não tirar os olhos dele para os objetivos de negócio que o software visa alcançar, fazer com que o cliente faça parte da equipe e jogue a favor e não contra.

@agnaldo4j

This comment has been minimized.

agnaldo4j commented Jan 11, 2012

Um modelo de negócio que estamos tentando praticar é a sociedade no produto que o cliente nos pede.
O que isso proporciona?

  1. Voz ativa no projeto.
  2. Tem que fazer direito pois seremos nós que daremos manutnção.
  3. Maior confiança do cliente, pois não robaremos horas de desenvolvimento, já que isso seria um tiro no próprio pé.
  4. Cliente mais seguro ao final do projeto, pois sabe que terá continuidade.
  5. Clientes de projeto para uso interno somente se o software for replicavel fora.

Mas isso implica em rejeitar projetos fora desse modelo.

@klauswuestefeld

This comment has been minimized.

Owner

klauswuestefeld commented Jan 11, 2012

Eh uma questão de confiança apenas. Um projeto de escopo fechado (q chamo de "Escopo Especulado" e sugiro q vcs façam o mesmo) apresenta um risco 10 a 20x maior que o mesmo projeto com escopo aberto (q chamo de "Escopo Priorizado" e sugiro q vcs façam o mesmo). Acontece q com o escopo especulado, o cliente tem a ilusão de estar repassando o risco ao fornecedor de software, mas, na verdade, ele nao ganha nada falindo o fornecedor do software crítico da empresa dele. Muito pelo contrário.

Praticamente todo cliente onde já trabalhei começou assim, com escopo especulado. Inclusive, muitos projetos internos de empresas são feitos assim! Mas, no projeto de missão crítica do Telecine, por exemplo, fomos ganhando confiança até chegar num ponto, lá pelo quarto ou quinto pacote de manutenção, onde eles simplesmente nos ligavam e diziam: "Temos X aqui p investir. Vem aqui fazer o q for melhor pra nós."

Não tenho dificuldade de vender contratos de escopo priorizado pros donos do dinheiro, pras áreas fim, que vão efetivamente usar o software, dentro de empresas grandes. São as áreas de TI q normalmente expressam seu medo através de contratos de escopo especulado.

@klauswuestefeld

This comment has been minimized.

Owner

klauswuestefeld commented Jan 11, 2012

Curti o modelo do Agnaldo.

@reinaldob

This comment has been minimized.

reinaldob commented Jan 12, 2012

Será que o problema do ciclo vicioso não está em nós entregarmos algo que sabemos que não está do jeito que deve ser, e simplesmente "lavarmos as mãos", dizendo que o cliente nos obrigou a correr pra entregar, vender com escopo fechado, não fazer testes, etc ??
Pq imaginem se cada profissional de TI se comportasse como médicos por exemplo, onde é feito um diagnóstico e um remédio é receitado, não há espaço para discussões entre médico e paciente, dizendo que o diagnóstico está errado ou que deveria ser o remédio X ou o remédio Y. O que acontece é que o paciente tem a opção de fazer o que o médico disse ou procurar outro médico.
Agora na área de TI tenho a impressão que não somos especialistas o suficiente para dizer(exigir??) que um projeto só está pronto se existem testes ou a funcionalidade só estará entregue após o refactoring.
Claro que eu sep o motive para isso não acontecer, dinheiro é claro.
Agora e se todos nós nos comportassemos da mesma maneira, impondo qualidade, será que conseguiríamos eliminar esse ciclo vicioso ?
Fiz a pergunta, mas eu mesmo não sei a resposta….

ps: Tb gostei do modelo do Agnaldo, pois como o risco é compartilhado, imagino que todo mundo vai exigir qualidade, o cliente do ponto de vista do negócio, e o desenvolvedor do ponto de vista técnico.

@agnaldo4j

This comment has been minimized.

agnaldo4j commented Jan 12, 2012

Comecei a usar este modelo, justamente quando me vi como médico do SUS dando soluções paleativas e mandando o paciênte pra casa sem saber se solucionei o seu problema.
Nesse momente resolvi ser um médico de família onde tenho um acompanhamento maior com o problema, podendo ir melhorando o tratamento.
Isso é mais caro inicialmente para a startup já que somos obrigados a recusar a maioria dos "paciêntes", mas os que dão certo são relacionamentos que acretido serão de longo prazo.

@rpepato

This comment has been minimized.

rpepato commented Jan 12, 2012

Klaus, acho que o grande problema é esse aí mesmo que você levantou. O grande atravancador de resultados hoje (principalmente em grandes corporações) é a área de TI (que provavelmente segue esse modelo por também ser pressionada e adotar uma saída 'cover your ass'). Concordo contigo quando você coloca a simplicidade de vender projetos de escopo priorizado para os donos da grana (normalmente esses caras não estão nem aí pra que tipo de método ou processo utilizamos, desde que entreguemos resultados tangíveis), quase nunca temos problemas nessa esfera, já que é fácil demonstrar que o modelo de entregas em produção a curtos intervalos de tempo oferece uma vantagem competitiva e um benefício financeiro óbvio (considerando a premissa básica da matemática financeira de que o dinheiro, no caso o ROI, tem valor no tempo, logo um sistema que me retorne x hoje vale mais do que um sistema que me retorne x daqui 2 anos). A dificuldade gerada pelas áreas de TI de grandes corporações (eu mesmo já fiz parte desse tipo de estrutura, desisti e hoje toco meu barco sozinho) é uma barreira de difícil transposição que vai exigir muita dedicação e coragem para que o jogo algum dia vire, mas o caminho é por aí: conscientizar a alta administração de que existe algo (ou tudo) errado na forma em como a TI encara seu papel e como é encarada nos dias atuais. Quem sabe assim um dia, consigamos finalmente trazer o merecido reconhecimento à nossa profissão.

PS: +1 que gostou do modelo do Agnaldo. Agnaldo, como tem sido a aceitação desse tipo de proposta para o seu mercado ? Você trabalha em alguma vertical ?

@agnaldo4j

This comment has been minimized.

agnaldo4j commented Jan 12, 2012

Bom estamos trabalhando com esse modelo a 6 meses, nesse período fechamos dois projetos e estamos com quatro em negociação e pretendemos ter dez até o final desse ano.
Nos projetos fechados já estamos avaliando novos projetos nessas empresas seguindo o mesmo modelo.
Os projetos são pequenos e médios.
Os clientes desse modelo são pequenos, startups e uma média.
O que percebemos em todos eles é que estamos em um período de testes(relacionamento, qualidade, validação do modelo) antes de começar a trabalhar em projetos críticos.
Não temos uma vertical ainda, só sabemos que softwares de contabilidade, frente de loja e afins estamos fora.

Gestores que aceitam o modelo:

  1. Jovens
  2. Outros gestores de startups
  3. Entendem que o negócio deles não é TI, mas sabem que esse é o meio para alcançarem o objetivo que querem.

Gestores que não aceitam

  1. Gestores de empresas que tem a cultura de não perder uma virgula no campo de batalha
  2. Acreditam que qualquer empresa vai fazer o mesmo trabalho é só uma questão de preço
  3. Realmente tem projetos sigilosos e o modelo não encaixa.

OBS: Empresas grandes ainda não nos arriscamos

Impactos sentidos no modelo:

  1. Ainda mantemos uma prestação de serviço no modelo SUS para sustentar o negócio parcialmente.
  2. Demora no fechamento do projeto
  3. Pagamento dos sócios comprometido (temos que trabalhar meio período)

O que tenho percebido esse é o modelo mais difícil. este acredito ser o modelo TDD, lento no início mas depois de tomar corpo manterá um ritmo constante já que teremos projetos de manutenção e possibilidades de venda dos produtos criados durante.

@flavih

This comment has been minimized.

flavih commented Jan 12, 2012

Perfeito os comentários de Klaus e do Agnaldo. Como desenvolvedor e autônomo sinto na pele todas as dificuldades elencadas pelo Klaus. Tenho que especular pq não dá para fazer levantamentos precisos, demorar um tempo enorme e depois nem ser pago para isto. O ideal seria com que o cliente pagasse as horas de levantamento do projeto. O qual geraria um documento que seria o produto final. Depois disso o desenvolvedor entregaria um orçamento baseado no documento. Este documento disponível pelo cliente poderia ser entregue a outros desenvolvedores para gerar outros orçamentos. Desta forma não se faria um trabalho em vão.

A forma de trabalho com que Agnaldo propõe me é revolucionária. Adorei. É difícil mas "sai da caixa". Contudo não adianta reter um produto que pode ser comercializado a terceiros, é preciso montar uma equipe de vendas e suporte técnico para tal, criando assim uma outra estrutura.

@rpepato

This comment has been minimized.

rpepato commented Jan 12, 2012

Bacana Agnaldo, bem legal seu relato, parece um modelo promissor!

Eu imagino que uma das dificuldades enfrentadas esteja no momento da negociação da distribuição percentual da propriedade (e dos resultados, claro) do produto, afinal, o dono da idéia muitas vezes tende a assumir uma hipótese de que sua idéia vale muita grana, mesmo quando não existe qualquer tipo de evidência séria que sustente esse tipo de argumentação. O Eric Ries fala bastante deste conceito (vanity metrics x actionable metrics) no "The Lean Startup" mas obviamente essa não é uma idéia aceita por todos (ok, Lean Startup tá fazendo barulho, mas é um conceito relativamente novo). Você já chegou a enfrentar esse tipo de situação ? Ex.: Acredito que meu esforço justifique 50% de participação no share do produto mas o cliente acha que você merece 5%. Caso positivo, conseguiu sair do enrosco ?

@luizlaydner

This comment has been minimized.

luizlaydner commented Jan 12, 2012

Klaus,
Muito bom o artigo!
Tem uma apresentação excelente do Glenn Vanderburg relacionado a esse tema... já assistiu?
http://confreaks.net/videos/282-lsrc2010-real-software-engineering

"Software engineering as it’s taught in universities simply doesn’t work. It doesn’t produce software systems of high quality, and it doesn’t produce them for low cost. Sometimes, even when practiced rigorously, it doesn’t produce systems at all.

That’s odd, because in every other field, the term “engineering” is reserved for methods that work.

What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we’ll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being “anti-engineering” (as they are often described), actually represent the best of engineering principles applied to the task of software development."

@agnaldo4j

This comment has been minimized.

agnaldo4j commented Jan 12, 2012

Bom sobre como funciona é mais ou menos como o rpepato relatou.
Funciona assim:
1- Com startups
O cara chega querendo fazer todo o produto que vai deixa-lo milionário somente com a ideia, a execução e a venda é só um mero detalhe, pois na cabeça dele todos estão esperando para deixa-lo rico.
Nós levamos o conceito de "Mínimo produto viável" para testar o mercado e ter o produto pronto o mais rápido possível.
Explicamos que nesse modelo queremos ser sócios do produto em um percentual que varia de 5% a 20%, pois estaremos comprometidos com a vida do produto.
Nesse cenário ao fecharmos o projeto temos todas as possibilidades de fazer o melhor trabalho que podemos para se ter um MVP e evoluirmos o cara.

2- Empresas que pedem software
Nesse caso pedimos o produto para nós e concedemos de 5% a 20% para eles.
Nesse cenário eles estão mais interessados em resolver seu problema interno, quando mostramos a proposta ele vê a possibilidade de fazer isso e ainda ter um retorno extra.

Conceitos como LEAN devem ser aplicados em todas as áreas, tanto LEAN Startup como no uso de LEAN no processo de desenvolvimento usando SCRUM e XP como modelo base.

Só lembrando esse conceito ainda esta em estudos só executamos dois projetos até agora, mas estamos felizes com os dois e acinosos pelos outros que podem vir.

Ainda existe muita politica na venda de software, chegar em grana grande vai levar muito tempo nesse modelo isso já é uma coisa a ser resolvida.

@alexandreaquiles

This comment has been minimized.

alexandreaquiles commented Jan 18, 2012

Acho importante ressaltar que o uso de uma abordagem iterativa/incremental, com Escopo Priorizado e evolução das funcionalidades, não é suficiente para o sucesso de um projeto de desenvolvimento de software.

Mesmo com metologias/práticas ágeis, muitos projetos que começam simples e bacaninhas vão se transformando em monstros. E os sintomas 10, 13, 14, 15, 16, 21, 22, 23 e 25 tornam-se claramente visíveis.

O lado positivo é que quem não conseguia entregar quase nada seguindo processos tradicionais passa a entregar. Mas o software vai ficando cada vez mais difícil de manter e evoluir.

O ponto chave para acabar com os sintomas mencionados, e com o fracasso, é aliar a evolução das funcionalidades a um cuidado com qualidade: design, refatoração, testes automatizados, testes manuais exploratórios, arquitetura, performance e também requisitos.


Dito isso, há um tipo de projeto que precisa de validação de hipóteses (lean startup/pretotyping). Pra esses, manter um nível de qualidade alto pode custar muito e tornar o MVP inviável.

Mas cuidado tem que ser tomado pra não virar um Netscape Communicator, um software de sucesso validado mas condenado.

@nicolasiensen

This comment has been minimized.

nicolasiensen commented Jan 20, 2012

@klauswuestefeld

This comment has been minimized.

Owner

klauswuestefeld commented Jan 20, 2012

Nicolas, gosto bastante do uso de personnas, como vc descreve.

Vc concorda que, melhor ou pior, esse design de projeto continua sendo especulação?

@nicolasiensen

This comment has been minimized.

nicolasiensen commented Jan 20, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment