Funcionalidades do Sistema
A razão de ser de qualquer sistema são suas funcionalidades. Obviamente.
Os desejos dos usuários são expressados em Requisitos Funcionais, que compõe as Funcionalidades. Mas, infelizmente, não há uma priorização adequada dos Requisitos, logo, as funcionalidades do sistema também não sofrem uma priorização adequada.
E o que isso gera?
Sistemas inchados, com muito mais escopo do que o necessário “de fato”, funcionalidades do sistema que não são usadas, ou quase nunca são utilizadas.
Sucesso nos Projetos de Software
Projetos de software dificilmente são bem sucedidos. Quem trabalha na área sabe que, na maioria dos casos, é muito improvável que um projeto vá terminar no prazo, esforço e custo planejados no início do projeto.
O simples fato de não terminar conforme o planejado já é um provável fator de insucesso no projeto (provável pois em alguns pouquíssimos casos os motivos são pertinentes e aceitáveis).
E só quem vive esta realidade sabe o quão frustrante é trabalhar com uma expectativa que é pouco provável de se realizar.
Todo profissional quer ver seu trabalho se materializando, gerando valor para alguém. Isso traz satisfação, sentimento de dever cumprido, de realização. E no dia a dia, projeto após projeto, os atrasos continuam, e a frustração só tende a aumentar. Mas não deve ser assim, não precisa ser assim.
/* infelizmente a maioria dos desenvolvedores jamais viu um projeto de software executado com sucesso. Eu já tenho 15 anos na área de TI, e não vi mais que cinco projetos bem sucedidos (e já trabalhei em mais de trinta, além de acompanhar com colegas o dia a dia de dezenas de projetos) */
Mas porque isso quase sempre acontece?
As causas são várias. E várias destas causas são complicadas de resolver, outras nem tanto. Uma das causas mais simples de resolver é o desperdício de escopo. Este desperdício refere-se à, basicamente, funcionalidades que não precisariam ser feitas, mas que são produzidas e inutilizadas logo que o software vai para produção.
Vamos entender melhor este contexto.
O padrão “desperdício”
De um modo geral, por padrão, o ser humano tem mania de excesso. Raramente se encontra alguém que, por opção, realmente tem somente aquilo que precisa.
A maioria de nós nivela o patrimônio material, por exemplo, aos recursos disponíveis; como o padrão de vida, onde quem ganha R$ 1.000,00 gasta R$ 1.000,00 (ou mais), mesmo que precise de R$ 800,00 para viver; quem ganha R$ 10.000,00 gasta R$ 10.000,00, mesmo que precise de R$ 8.000,00 para viver etc.
Sempre encontramos alguém que acredita que problemas como a fome e falta de água potável, por exemplo, tem como causa a escassez de recursos (naturais ou materiais). Mas isso precisa ser repensado.
Quaisquer recursos necessários para uma sobrevivência equilibrada existem, estão disponíveis. A causa não é a ausência do recursos, mas o mal uso que fazemos dos recursos disponíveis.
Um exemplo claro disso é o desperdício de alimento em nível mundial, que se erradicado, seria bem mais que o suficiente para suprir a necessidade de comida dos sete bilhões de humanos encarnados na terra.
Com as empresas não é diferente. Em tempos de crise no Brasil (2014/2015/2016) muitas empresas estão demitindo.
As demissões, na maioria das vezes, são justificadas pela necessidade de “corte de custos”. Neste contexto, entende-se que demitir diminuirá os custos, tornando a operação da empresa mais competitiva, otimizando a eficiência e a eficácia e logo, o lucro.
Mas essa linearidade também precisa ser repensada. Nos momentos de demissão, que funcionário nunca pensou algo como “puxa, tanto funcionário menos produtivo que o fulano, e logo ele foi mandado embora…” ou “essa empresa burocrática, com tantos processos desnecessários, jogando dinheiro fora, e agora vem demitir gente ao invés de mexer na sua cultura, na sua estrutura organizacional, nos seus processos…”.
O desperdício no software
Quando há a contratação de um serviço para desenvolvimento de sistemas por parte de clientes internos ou externos o pensamento muito (muito mesmo) raramente é “do que realmente precisamos” e quase sempre é “o que conseguimos fazer com o que temos de orçamento”.
No segundo caso, não há como não haver desperdício de recursos com relação ao escopo, pois não se orienta primariamente pela necessidade e sim pela capacidade financeira.
/* com “desperdício de recursos com relação ao escopo” eu quis referir-me a coisas tipo funcionalidades inúteis, funcionalidades úteis que foram ignoradas, funcionalidades “anabolizadas” – com muito mais recursos do que o necessário, e outras anomalias de escopo */
É como o primeiro parágrafo deste post, onde quem ganha R$ 10.000,00 não pensa sobre o que precisa realmente, mas pensa sobre o que se consegue consumir tendo R$ 10.000,00.
O que citei não é a única causa de desperdício de recursos em projetos de software. Existem diversos outros fatores, mas como estamos falando sobre funcionalidades, não vou estender muito neste raciocínio. Em outra oportunidade vamos falar disso, o problema é sério e vasto, mas simples de entender.
A realidade do desperdício no escopo de sistemas
Há uns dois anos fiz um curso de Scrum onde o instrutor apresentou um gráfico um tanto assustador, que apresentava em percentual o uso das funcionalidades de um sistema, segundo o Standish Group em seu relatório Chaos Report de 2002 (o hiperlink é para uma referência ao relatório de 2014 no blog da entidade). Abaixo segue o gráfico citado.
Os números acima são assustadores, mas eu enquanto usuário e fabricante de software não vejo exagero algum neles. 45% das funcionalidades nunca são utilizadas e 19% raramente são utilizadas. Vamos generalizar e considerar que a soma dos números acima – 64% – é escopo inútil, não gera valor, não é necessário existir.
Teoricamente podemos concluir que 64% do que é gasto com funcionalidades num software vai para o lixo, é desperdício de recursos.
Quer uma prova disso?
Se faça a seguinte pergunta: “de todas as vezes que utilizei o Microsoft Word, quantas funcionalidades eu realmente utilizei?”, ou “toda vez que utilizo meu Windows, quantos recursos do sistema operacional eu utilizo?”. No caso do Word, a maioria esmagadora dos usuários utiliza para textos simples, utilizando recursos de formatação, tabelas etc. Alguns outros fazem trabalhos, então utiliza-se índices/sumários, referências etc. Mas quantos itens de menu (comandos, ações, funcionalidades) o Word possui? Não sei, mas tenho certeza que passa fácil das centenas. E o Windows? Passa das milhares.
E o Outlook? Qual seria a parcela de usuários que, no mar de funcionalidades que tem no programa, fazem algo além de apenas enviar e receber e-mails?
Com softwares corporativos, produzidos por departamentos internos de desenvolvimento de sistemas, ou fábricas de software, não é muito diferente. Na minha opinião, para cada relatório existente num ERP, outros três inúteis também existem. Para cada tela de cadastro, outras duas inúteis também existem.
O princípio de Pareto explica um pouco disso. De um modo geral, podemos entender que 20% das funcionalidades de um sistema são necessárias, viabilizam o objetivo do sistema, e realmente geram valor para o negócio do cliente. Os outro 80% é o inverso disso.
E como resolver isso?
A priorização de requisitos é um excelente recurso, pois leva a equipe a pensar primeiramente no que é essencial a se fazer, refletindo sobre a utilidade dos requisitos solicitados; o uso adequado dos recursos, buscando conscientizar as pessoas do uso adequado do dinheiro e tempo também é fundamental; uma gestão adequada de escopo faz muita diferença, pois evita-se que clientes/usuários atropelem o planejamento e solicitem coisas diferentes das originais, alterem toda hora o que pediram inicialmente etc.
Mas acima de tudo é necessário refletir sobre isso. Conheço empresas que demitiram muito nestes dois anos, mas que gastaram milhões em software. Se destes milhões fosse subtraído ao menos 30% do escopo inútil dos sistemas construídos para estas empresas ou construído por elas mesmas, com certeza dezenas (ou centenas) de empregos teriam sido salvos, e menos famílias estariam passando necessidade neste momento…
E para fechar, viva o KISS! Não a banda, este KISS! A moda sempre será ser simples, simplicidade remete à eficiência, é o estado da arte em tudo na vida. E prova disso é o Google, que devido à simplicidade de seu buscador, tornou-se a gigante que é.
E para otimizar o escopo, diminuindo o escopo inútil, o segredo está todo nos Requisitos!
Abraços!