-
-
Save klauswuestefeld/1595701 to your computer and use it in GitHub Desktop.
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:
- Jovens
- Outros gestores de startups
- 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
- Gestores de empresas que tem a cultura de não perder uma virgula no campo de batalha
- Acreditam que qualquer empresa vai fazer o mesmo trabalho é só uma questão de preço
- Realmente tem projetos sigilosos e o modelo não encaixa.
OBS: Empresas grandes ainda não nos arriscamos
Impactos sentidos no modelo:
- Ainda mantemos uma prestação de serviço no modelo SUS para sustentar o negócio parcialmente.
- Demora no fechamento do projeto
- 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.
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.
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.
Nicolas, gosto bastante do uso de personnas, como vc descreve.
Vc concorda que, melhor ou pior, esse design de projeto continua sendo especulação?
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 ?