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.
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.
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.
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 – User 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.
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: é 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.
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.
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.
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:
Se algo estiver atrasado de uma sprint, o fornecedor terá a responsabilidade de resolver a questão sem gerar novos custos.
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.
Mas atenção, para que este modelo funcione, o product owner deve ter autonomia para assinar 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.
