Guilherme Sesterheim, head de transformação digital na Ilegra. Foto: Divulgação.
A falta de entendimento entre TI e negócios talvez seja um dos principais problemas da criação de software. Os pensamentos mais comuns quando alguém começa a pensar em criar um software é que será algo similar a qualquer outro produto que compramos. Quanto irá custar? E quanto tempo levará para ficar pronto?
Neste artigo tento desfazer a má comparação, que comumente acontece, entre construir uma casa e um software.
Software é um bebê
Tendemos a pensar que construir um software é similar a construir uma casa ou uma torre. Mas esta 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 duas ou dez plantas, e tudo que o comprador quiser estará lá 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 do 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 e-mail será enviado para um usuário? Ou desencadeia um processo interno envolvendo Inteligência Artificial, que busca todos os usuários que correspondem o dado atual, enviando a eles uma notificação pelo celular?
O PMI (Project Management Institute) aborda este cenário, escrevendo documentos enormes, com muitas informações, e seguindo o PMBOK (Project Management Body of Knowledge). Mas somente alguns softwares possuem este nível de detalhe; a enorme maioria das empresas/desenvolvedores não investem para ter este nível de detalhamento.
Complexidades diferentes
De volta à analogia das casas. Ao construir uma casa, o nível que se atinge ao desenhar a arquitetura (similar ao documento de requisitos no software) será a inserção de paredes, encanamento, eletricidade, rede etc. Porém, neste nível, não é descrito como a casa será decorada (a UI - Interface - no software). Quantas quadros estarão lá? Qual será o sofá? Quantas polegadas terá a TV? O quarto do filho será do Batman ou Superman?
Obviamente, isso não é descrito porque pessoas têm opiniões diferentes em como decorar uma casa. E essas opiniões mudam com o tempo. Quando falamos em 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, e após sérios problemas ao desenvolver o software, eventualmente, empresas começaram a migrar para o agile, que é a abordagem mais rápida para resolver os problemas que ocorrem quando um escopo não está claro/detalhado o suficiente. O 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 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 das pessoas
Esteja preparado para enfrentar desafios relacionados ao comportamento das pessoas ao migrar para o agile. É uma nova forma de trabalhar, e tudo o 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 estão nesta 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 o 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. Um 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. Então o cliente poderá ir ao mercado solicitar que fornecedores produzam o software. A produção do software será feita sprint por sprint. E todo começo de uma nova sprint gera um novo acordo.
Características de um projeto por sprint:
Data de início e fim (2, 3 ou 4 semanas são boas sugestões para começar);
Preço total da sprint;
Lista de stories que serão entregues;
Toda story deve ter um claro DoD (Definition of Done);
Toda story deve ser detalhada ao máximo, sempre chegando em um ponto que o time consiga trabalhar nelas sem nenhum bloqueio.
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:
Ele pode parar com o trabalho quando quiser, sem amarras contratuais de longo prazo;
Poderá aplicar novas decisões de negócio, assim que desejar;
Poderá responder rapidamente a mudanças de mercado e de competidores, sem precisar esperar para que o projeto atual seja finalizado para começar uma nova negociação;
Se algo estiver atrasado de uma sprint, o fornecedor terá a responsabilidade de resolver a questão 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 pensam que ele quer;
O produto será flexível para responder rapidamente a decisões de negócio e s 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 executadas sem afetar a continuação do projeto.
Para o fornecedor:
Terá informações claras para trabalhar. Menos entendimento duplo de requisitos irá acontecer;
Terá mais flexibilidade para se transformar em uma consultoria, trazendo conhecimento de diversos projetos. Isso beneficiará tanto práticas técnicas quanto decisões de negócio.
Mas atenção, para que este modelo funcione, o product owner deve ter autonomia para os acordos em cada início de sprint. Isso não pode envolver um novo ciclo do departamento de compras.
*Por Guilherme Sesterheim, head de transformação digital na Ilegra, empresa global de design, inovação e software.