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:

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