Escrito por Guilherme Sesterheim, VP of Operations, em 24/07/2019
9 minutos de leitura
Você já pensou em comprar desenvolvimento de software por sprint?
Confira no artigo do nosso Head de Transformação Digital, Guilherme Sesterheim, como o novo modelo de contratação de software por sprint tem viabilizado projetos ágeis e flexíveis, que geram soluções mais centradas no cliente.
Principais problemas em comprar escopo fechado/software precificado
Os pensamentos mais comuns quando alguém começa a pensar sobre criar um software é que será algo similar a qualquer outra coisa que compramos. Quanto irá custar? E quanto tempo até ficar pronto?
Estou tentando desmistificar a ruim comparação entre construir uma casa e construir um software, algo que geralmente acontece durante essas conversas.
Software é um bebê
Nós tendemos a pensar que construir software é similar a construir uma casa ou uma torre. Mas este paralelo/analogia é impossível de ser feita nos dias de hoje. Durante séculos, casas têm sido construídas e o processo alcançou uma maturidade que permite colocar toda a informação em 2 ou 10 plantas, e tudo que o comprador quer estará lá bem descrito.
Softwares têm sido criados há menos de 100 anos (desde 1950) e até hoje não há uma forma de colocar toda a informação em um documento que pode ser seguido desde o começo até o fim do processo. Invariavelmente, os documentos possuem uma visão macro do que é solicitado. Porém, como exemplo, o que deve acontecer quando eu aperto o botão “notifique o usuário”? Um email será enviado para um usuário? Ou desencadeia um processo interno envolvendo AI que busca todos os usuários que correspondem o dado atual e envia a eles uma notificação pelo celular?
PMI aborda este cenário escrevendo documentos enormes com plenos detalhes seguindo o PMBOK. Mas somente alguns softwares possuem este nível de detalhe. Para todo resto (a grande maioria que tenho visto durante 10 anos de TI) empresas não podem pagar o investimento para ter este nível de detalhe.
Complexidades diferentes
De volta a analogia das casas. Quando você está construindo uma casa, o nível que você atinge ao desenhar a arquitetura (similar ao documento de requisitos no software) será as paredes, encanamento, eletricidade, rede e etc. Porém, neste nível, você não descreve como a casa será decorada (a UI no software). Quantas pinturas estarão lá? Qual será o sofá? Quantas polegadas terá sua TV? O quarto do seu filho será do Batman ou Superman?
Obviamente, isso não é descrito porque pessoas terão opiniões diferentes em como decorar a casa. E estas opiniões mudam com o tempo. Quando falando de software, algumas vezes estes comportamentos de UI não são descritos no nível que deveriam ser.
A migração para agile
Dado este cenário acima e após sérios problemas ao desenvolver o software, eventualmente, empresas começaram a migrar para o agile. Atualmente o agile é a abordagem mais rápida para abordar os problemas que ocorrem quando um escopo não está claro/detalhado suficiente. Gartner (ID #G00325642) diz que as principais barreiras para a mudança de escopo fechado/preço fixo para o método agile são:
- Sourcing e finanças
- Sourcing: é difícil dizer quanto que o software irá custar. Em organizações onde o processo de sourcing é engessado, esse será o principal desafio.
- Finanças: as organizações possuem suas operações financeiras estruturadas como preço por projeto. Orçar para que o software seja tratado como um produto em vez de um projeto pode ser algo complexo em algumas empresas.
- Adaptabilidade da cultura/mindset da rotina da pessoa
- Esteja preparado para enfrentar desafios relacionados ao comportamento das pessoas ao migrar para o agile. É uma nova forma de trabalhar, e tudo que é novo cria resistência.
- Como uma das principais características do desenvolvimento ágil, a habilidade de adaptar seu software junto ao seu desenvolvimento é essencial. Quando aplicado a organizações que em mudança, alguns problemas surgirão.
- Já que o escopo pode ser modificado a qualquer momento, pessoas podem cair na armadilha de continuar tentando alcançar a perfeição em alguns requisitos e gastam muito tempo com isso, em vez de trabalhar nos próximos itens, o que torna todo o processo mais lento.
- Em alguns momentos, é fácil perder o padrão de UX, pois as features que já foram entregues podem ter diferenças funcionais ou de design das seguintes.
- O processo de gerenciar pessoas contará com diferentes KPI’s para medir performance e qualidade. Encontrar os índices corretos para seu projeto não será algo rápido.
Uma abordagem híbrida
Quanto mais flexível é o escopo, maior é o risco para o cliente. Quanto mais fixo é o escopo, maior é o risco para o fornecedor.
Uma bom modelo de abordagem híbrida entre escopo fixo e 100% agile pode ser a compra por sprint/fase (Gartner, 2017 – ID #G00325642). Você vai precisar analisar o projeto como um todo para utilizar este modelo. Começando por uma estimativa interna inicial de preço e tempo, o cliente poderá ir ao mercado solicitar que fornecedores produzam o software. A produção do software será feita sprint por sprint. Todo começo de nova sprint significa um novo acordo. O que estará neste acordo:
Anatomia de uma proposta por sprint:
- Data de início e fim (2, 3 ou 4 semanas são um bom começo);
- Preço por sprint;
- Stories que serão entregues;
- Toda story deve ter um claro DoD (Definition of Done);
- Toda story deve ser detalhada ao máximo para que o time trabalhe sem blocks.
Para que este modelo funcione, o product owner deve ter autonomia para assinar. Isso não pode envolver um ciclo de aquisição.
Os benefícios
Desenvolver projetos por sprint coloca a balança do risco em algum lugar perto do centro. E aqui eu listo alguns resultados importantes da mudança:
- Para o cliente:
- Eles podem parar com o trabalho quando quiserem sem alianças contratuais de longo prazo;
- O cliente poderá aplicar novas decisões de negócio quando o mesmo desejar;
- O cliente poderá responder rapidamente a mudanças de mercado e de competidores, sem precisar esperar para que o projeto atual esteja finalizado para começar uma nova negociação;
- Se algo está atrasado de uma sprint, será responsabilidade do fornecedor de resolver isso sem gerar novos custos.
- Para o produto (software):
- Um dos benefícios chave da flexibilidade é a possibilidade de envolver mais experts em processos específicos. Com isso, o produto atenderá melhor ao que o usuário quer, e não o que um grupo de pessoas (como o antigo gerente de projeto e o analista de sistema) pensam que querem;
- O produto será flexível para responder decisões de negócio rápidas e feedback de usuários;
- Práticas focadas em encontrar inovação podem se tornar rotineiras. Executar design sprints, inceptions, teste de usabilidade e entrevistas com usuários são algumas práticas que seriam finalizadas sem afetar a continuação do projeto;
- Para o fornecedor:
- O fornecedor terá informações mais claras para se trabalhar. Menos entendimento duplo de requisitos irá acontecer;
- O fornecedor terá mais flexibilidade de se transformar em uma consultoria, trazendo conhecimento de diversos projetos. Isso beneficiará tanto práticas técnicas quanto decisões de negócio.