Home > Gestão

25 perguntas que o CEO deve fazer sobre software – 1ª parte

As primeiras dez erguntas – e as respostas de líderes de tecnologia – sobre os temas do mundo do software corporativo que interessam aos executivos de negócios do C-level

Capers Jones*

24/09/2007 às 20h08

question5_int.jpg
Foto:

Manter os softwares sob controle não tem sido tarefa fácil. Apesar de sua importância cada vez maior para as operações corporativas, continua sendo uma tecnologia complexa, que traz quase tantos problemas quanto benefícios.
Considerando-se que um grande número de CEOs agora está na faixa dos 40 a 60 anos, é possível imaginar que eles não sabem muito bem como lidar com software. O mesmo vale para vice-presidentes de unidades operacionais como manufatura, vendas, marketing e recursos humanos. Entretanto, todas as grandes empresa automatizaram boa parte das atividades de relatório financeiro, billing, marketing e manufatura. Ou seja, software é vital para entrega de muitos produtos novos e pode ser incorporado ao próprio produto. A ignorância, portanto, é perigosa.
Este artigo discute 25 aspectos importantes que os CEOs (e outros executivos do C-level) devem entender para garantir que o software do qual suas empresas dependem seja um ativo e não um passivo para a corporação que eles controlam. As perguntas estão classificadas em cinco áreas relevantes e as respostas, em geral, são de CIOs, vice-presidentes de tecnologia da informação, vice-presidentes de engenharia de software ou outro cargo equivalente.
Os dados contidos neste relatório foram fornecidos por muitos dos meus clientes, que abrangem cerca de 150 empresas Fortune 500, centenas de empresas menores e várias agências do governo e setores das forças armadas. Um panorama mais completo dos problemas e das melhores práticas de software está descrito no meu livro Software Assessments, Benchmarks,and Best Practices (Addison Wesley, 2000).

Perguntas sobre o que está “na moda”
1. Quantos dos nossos sistemas têm mais de 10 anos de existência e estão se tornando obsoletos?
2. Até que ponto os métodos ágeis seriam úteis para nós?
3. Qual é o impacto de subir na escala de maturidade (Capability Maturity Model –CMM) do Software Engineering Institute (SEI)?
4. Em que nível da escala de CMM nos encontramos?
5. O que estamos fazendo em termos de ITIL e arquitetura orientada a serviços (service-oriented architecture – SOA)?

A maioria dos portfólios de software, além de estar envelhecendo, são instáveis e difíceis de modificar com segurança. A média de idade dos aplicativos é algo entre 10 e 15 anos. Uma solução imediata é dar a estes aplicativos um “tratamento geriátrico”, ou seja, renová-los e reestruturá-los. Remover módulos sujeitos a erros também é uma possibilidade. Outra é terceirizar operações de manutenção, liberando recursos internos para novo desenvolvimento.
Soluções de prazo mais longo envolvem SOA e ITIL (Information Technology Information Library). SOA ainda não está totalmente desenvolvida e disponível, mas promete. Compartilha alguns dos problemas dos ERP, no sentido de que a complexidade de implementação é maior do que a prevista. ITIL também é uma boa idéia, concentra-se em atingir altos níveis de confiabilidade e disponibilidade, além de rápida reação a problemas. Dentro de alguns anos, SOA e ITIL provavelmente vão apresentar resultados mais empíricos do que hoje.
Os métodos ágeis são baseados na premissa de que pequenas equipes de desenvolvedores em contato diário com usuários podem criar software funcional mais rápido e melhor do que com métodos mais antigos que partem de requisitos e fases de design longos e problemáticos. Os métodos ágeis apresentaram resultados de produtividade impressionantes para aplicativos menores e estão começando a ser usados para aplicativos maiores também.
Entretanto, ainda pairam dúvidas em relação aos níveis de qualidade dos aplicativos ágeis. Além disso, os métodos ágeis são novos e, portanto, existem poucos dados disponíveis sobre os custos de manutenção no longo prazo.
O “tópico quente” seguinte diz respeito ao renomado Software Engineering Institute (SEI), uma organização sem fins de lucrativos que desenvolveu uma escala de avaliação de cinco pontos muito interessante, chamada “modelo de maturidade de capacidade (“Capability Maturity model" -- CMM). O sistema de pontuação classifica as empresas com base em modelos de resposta para cerca de 150 perguntas. Há também uma versão mais nova, CMMI (“Capability Maturity Model Integration)".
No nível mais primitivo, as organizações que se encontram no Nível 1 de CMM (cerca de 75% das empresas atualmente) costumam ter problemas de estouro de orçamento e cronograma, má qualidade e cancelamentos de software. O nível máximo — alcançado por menos de 1% das organizações — classifica uma empresa como “estado da arte em todos os aspectos de software".  Em geral, passar de um nível a outro leva cerca de um ano. Galgar cada nível pode custar U$5.000 per capita para a população de software existente. Em uma organização, passar do Nível 1 ao Nível 5 pode consumir cinco anos e custar US$25.000 per capita em treinamento e reformulação. Não são cifras negligenciáveis.
Em termos de qualidade e produtividade, existe uma sobreposição entre os diversos níveis de CMM. Mas, à medida que os dados empíricos crescem, as empresas nos níveis mais altos -- 2, 3, 4 e 5 – parecem alcançar melhor qualidade e, às vezes, melhor produtividade do que as do Nível 1, principalmente para aplicativos grandes.

Perguntas sobre uso e valor do software e satisfação do usuário
1.
 Quais são as principais queixas das pessoas em relação ao nosso software?
2. Nossos clientes estão satisfeitos ou insatisfeitos com nosso serviço?
3. Quantos relatórios sobre problemas recebemos por ano dos clientes?
4. O que estamos fazendo para manter nosso software útil e valioso?
5. Quais são nossos piores sistemas de software atualmente?


Com base em pesquisas realizadas pela Software Productivity Research nos Estados Unidos, cerca de 70% dos usuários de aplicativos comerciais e 65% dos usuários de aplicativos MIS internos estão satisfeitos com a qualidade e com o serviço. Quanto aos aplicativos corporativos internos, cronogramas lentos de desenvolvimento encabeçam a lista de reclamações. Se levarmos em conta todas as formas software, má qualidade é a principal queixa. Estouros de orçamento e cronograma são freqüentes e problemáticos.
As equipes de desenvolvimento de software normalmente detectam e eliminam apenas 85% dos defeitos em aplicativos, o que significa que 15% chegam até os usuários. Este é um ponto fraco significativo da indústria. As melhores empresas estão atingindo a marca de 95% de remoção de defeitos e alguns projetos já se aproximaram dos 99%. A qualidade de software aquém da ideal leva ao tópico da manutenção de aplicativos que estão envelhecendo. A correção de defeitos latentes é a tarefa de manutenção básica nos vários anos após a implementação de um aplicativo.
Há mais de 20 anos surgiu uma nova sub-indústria de empresas e produtos que fornecem “cuidados geriátricos” para software em processo de envelhecimento. Agora é possível analisar a estrutura do software existente e reestruturá-lo automaticamente. Através de engenharia reversa e reengenharia, velhos aplicativos são analisados e transformados em versões modernas. Estas ferramentas de renovação ou “geriátricas” têm-se mostrado bastante eficazes.
Empresas em muitos setores começaram a reverter o crescimento alarmante dos custos de manutenção e aprimoramento de software com o uso destas técnicas. Algumas estão gastando menos de 20% de seus budgets anuais com manutenção de software. Os retardatários poderão gastar 70%. Se os custos de manutenção e aprimoramento em sua empresa ultrapassam 50% do seu budget total para software, alguma coisa pode estar muito errada.
A área de manutenção é uma das mais bem sucedidas da comunidade de outsourcing. Alguns outsourcers são duas vezes mais produtivos do que as empresas cujo software eles mantêm. Isso acontece porque eles têm pessoal treinado em manutenção e também porque desenvolveram conjuntos de ferramentas excelentes. Além disso, não costumam dividir seu tempo entre novos projetos de desenvolvimento e manutenção de aplicativos legados.

*Capers Jones é cientista-chefe emérito da Software Productivity Research

Junte-se a nós e receba nossas melhores histórias de tecnologia. Newsletter Newsletter por e-mail