O Ciclo Vicioso Do Software Retranqueiro

We couldn’t find any files to show.

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 ?

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."

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.

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.

@flavih, aqui na empresa todos os novos clientes passam por um design de projeto. O design de projeto consiste em duas dinmicas com o cliente: uma para elaborar um business model canvas (BMC) e um workshop de requisitos. No BMC abordamos o problema que o cliente deseja resolver, identificamos o pblico alvo, definimos algumas metas afim de explorarmos o problema. No workshop de requisitos partimos para a soluo, identificamos as personas envolvidas no processo, quais as atividades que precisam ser apoiadas por software e quebramos essas atividades em user stories. No fim temos um user story mapping com um big picture da soluo que imaginamos. As vezes, no BMC, percebemos que no precisamos de software para resolver o problema. Nesse caso nem fazemos o workshop de requisitos, e sugerimos para o cliente solucionar o problema de uma outra forma. O produto final do design de projeto o business model canvas, o user story mapping, e uma anlise feita por ns sobre tecnologias que recomendamos, tempo necessrio, equipe necessria e etc... Esse servio cobrado, e no final o cliente ainda pode levar o produto desse design de projeto para ser desenvolvido com outra empresa, nada segura ele com a gente. O resultado est sendo bem positivo, os clientes esto adorando as dinmicas e vendo muito valor nesse processo. []s 2012/1/18 Alexandre Aquiles < reply@reply.github.com

…

Acho importante ressaltar que o uso de uma abordagem iterativa/incremental, com Escopo Priorizado e evoluo das funcionalidades, no suficiente para o sucesso de um projeto de desenvolvimento de software. Mesmo com metologias/prticas geis, muitos projetos que comeam simples e bacaninhas vo se transformando em monstros. E os sintomas 10, 13, 14, 15, 16, 21, 22, 23 e 25 tornam-se claramente visveis. O lado positivo que quem no conseguia entregar quase nada seguindo processos tradicionais passa a entregar. Mas o software vai ficando cada vez mais difcil de manter e evoluir. O ponto chave para acabar com os sintomas mencionados, e com o fracasso, aliar a evoluo das funcionalidades a um cuidado com qualidade: design, refatorao, testes automatizados, testes manuais exploratrios, arquitetura, performance e tambm requisitos. --- Dito isso, h um tipo de projeto que precisa de validao de hipteses (lean startup/pretotyping). Pra esses, manter um nvel de qualidade alto pode custar muito e tornar o MVP invivel. Mas cuidado tem que ser tomado pra no virar um [Netscape Communicator](http://www.youtube.com/watch?v=u404SLJj7ig), um software de sucesso validado mas condenado. --- Reply to this email directly or view it on GitHub: https://gist.github.com/1595701

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

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

Com certeza! A estimativa do design de projeto, como qualquer outra estimativa, não é uma garantia. Estamos trabalhando no formato timebox, e damos o nome de "slot" para uma equipe de 3 pessoas trabalhando durante 1 mes. Quando um cliente decide nos contratar para o desenvolvimento, ele contrata slots. Portanto fica bastante claro que ele não contrata escopo, mas sim o nosso tempo. No fim o levantamento do escopo no design de projeto serve como um guia de como começar o desenvolvimento. Mas nada impede que no slot que o cliente contratou se faça outra coisa, ou que as estimativas se provem estarem erradas. Quando nos preocupamos em agregar valor, ao invés de simplesmente nos comprometermos com o escopo, o cliente adora a ideia dos slots.