Um tema que constantemente vem à tona em minhas andanças pelos nossos clientes é a necessidade de melhoria da produtividade, em geral, no processo do ciclo de vida de desenvolvimento de um software, sustentação de sistemas, suporte à infraestrutura, entre outras áreas. É comum ouvir que os projetos de software são superdimensionados, caros e demorados.

Levando o assunto diretamente para desenvolvimento de sistemas, é comum encontrarmos etapas de concepção, análise e requisitos, nas quais existem algumas práticas de estimativas de esforço, mais maduras em algumas organizações, porém nem tanto em outras.

Sobre essa maturidade, posso afirmar que em algumas dessas organizações, estimativas é algo praticamente inexistente ou desestruturado de forma a não existir um padrão aparente ou que seja consenso ao de todos os envolvidos. Pior é estimar que um software é um tabu passado à frente na tradição oral da organização (“ninguém sabe o porquê, mas, estimar é algo que não funciona aqui…”). Então o que predomina é o método Cálculo Hipotético Universal da Teoria Especulativa (C.H.U.T.E.), utilizado para fechar orçamentos e propostas.

Quanto aos processos maduros de estimativas, sim eles existem, apesar de relativamente raros. Em geral são muito bem estruturados, com padrões muito bem concebidos, tornando-se um excelente mecanismo para contratação de serviços de desenvolvimento de terceiros e para dar segurança nas estimativas financeiras, comuns no setor governamental e grandes instituições financeiras. Mas param por aí. Minha provocação: estimar é o suficiente? Não! A estimativa de software é parte de algo maior.

Você com certeza vai me questionar, “se você faz a estimativa bem feita você tem maior assertividade no custo, esforço e prazo do seu projeto”. Sim concordo, mas isso não é o suficiente! O mundo corporativo moderno e as suas respectivas pressões por resultados (mais agilidade, mais velocidade, mais qualidade, menos desperdício, menor custo), nos fazem apontar os nossos esforços à melhoria da produtividade. Sendo mais objetivo, temos que fazer mais com no mínimo o mesmo; mas o foco real é fazer mais com menos, e da melhor forma possível, no menor tempo possível.

Existem ações pontuais de melhoria da produtividade, mas sempre dependem da boa vontade de alguns indivíduos e a captura do retorno, na maioria das vezes, é difícil, além de não ter sustentação a longo prazo. Dificilmente vemos ações estruturadas e objetivas ligadas à melhoria contínua de produtividade, o que é um desperdício enorme e têm o potencial de gerar ganhos substanciais de tempo e dinheiro.

Na prática, temos que equilibrar três dimensões no processo desenvolvimento de software: custo (dinheiro investido na entrega), qualidade (efetividade da entrega dentro dos requisitos e/ou expectativas do cliente) e produtividade (quanto é produzido com o esforço/tempo disponível). O prazo do projeto e a satisfação do cliente são consequências do equilíbrio entre essas três coisas. É muito comum existir nas áreas de suprimentos das organizações grande foco no custo, que são ações relacionadas a redução do valor da hora homem e custos de fábrica de software.

Ações desse tipo tendem a reduzir significativamente o custo por hora, porém não garantem que a entrega será produtiva e assertiva. Quanto à qualidade, as empresas investem grandes esforços e dinheiro nos processos que tem por objetivo entregar os requisitos definidos da forma mais assertiva possível. Essas ações são efetivas, porém também não garantem que o ciclo de desenvolvimento seja produtivo (temos que convir que em alguns casos o torna improdutivo).

É raro encontrar unidades organizacionais com foco em produtividade, o que pode trazer equilíbrio das três dimensões citadas. Em geral, o investimento em iniciativas desse tipo parece alto, mas gera um retorno significativo, o que financia a adoção de um modelo de gestão da produtividade.

A gestão da produtividade permite que sejam analisados os resultados (sempre baseados em fatos e dados) de forma sistemática e com a utilização de métodos estatísticos, permitindo a identificação de ofensores e a adoção de ações que permitam a eliminação dos geradores de improdutividade.

Os requisitos principais para que exista a gestão da produtividade são:

• Unidade de medida definida e reconhecida (seja qual for: use case points, pontos de função, pontos de complexidade, métricas ágeis, funcionais e não funcionais).

• Documentação mínima para que seja possível dimensionar o software, adequada à métrica escolhida.

• Informações sobre o ciclo de desenvolvimento (mesmo que desestruturadas).

• Utilização de ferramentas de estatísticas para estruturação da informação.

• Um conjunto adequado de indicadores de desempenho da produtividade.

• Atuação concreta em ações de melhoria de forma holística (processos – internos e externos, pessoas, tecnologia, ferramentas e parceiros).

• Profissionais com capacitação e conhecimento adequados.

Tenho participado de projetos onde a combinação da gestão da produtividade com práticas Lean tem dado resultados significativos (temos vários artigos sobre Lean no nosso blog, vale a pena ler!).

Esse assunto é de certa forma polêmico e extenso, então gostaria de propor aqui uma reflexão. Aqui vão alguns sintomas que direcionam a necessidade de você atuar na melhoria da produtividade:

• Você não tem uma medida de software que é entendida por você, por suas equipes de análise e desenvolvimento de sistemas e, principalmente, por seu cliente final. Isso, em geral, gera conflitos que parecem insolúveis ou são bem desagradáveis.

• Há dúvidas quanto ao esforço estimado e realizado no desenvolvimento de um software.

• Você tem a sensação de que está gastando demais no desenvolvimento de software, mas não consegue argumentar com sua equipe de desenvolvimento ou com o seu fornecedor.

• Você tem a sensação de que controlou o seu custo por hora, mas não houve impacto perceptível nos custos totais dos projetos.

• Você percebe que o seu desenvolvimento de software é improdutivo, mas isso é visto somente de forma subjetiva, sem fatos e dados que comprovem sua percepção.

• As melhorias necessárias no ciclo de desenvolvimento de software aparecem o tempo todo, mas todas parecem ser prioritárias e você acaba perdendo o foco.

• Você tem a necessidade de conhecer a produtividade não apenas das equipes de desenvolvimento em si, mas também por outras perspectivas, como por exemplo: por fornecedor, por tecnologia, por senioridade, entre outras.

*Clovis Hitos Gonçalves é especialista de TI da Inmetrics.

Too Human was a flagship title for the Xbox 360, billed as the first entry of a massive planned RPG trilogy and often spoken of in the same breath as Mass Effect. The final product left a lot to be desired and the other two entries never appeared. This week we’re examining why.

The game was in development as early as 1999 for release on PlayStation. It moved over to GameCube after developer Silicon Knights struck a deal with Nintendo, but finally landed on the Xbox 360 in 2008. It debuted to mostly negative reviews, including Game Informer’s, which garnered a surprising amount of heat towards our magazine from readers.

Andrew Reiner and Joe Juba, who talk about the strange circumstance of reviewing the game, join myself and Jeff Cork to chat about the ultimately failed attempt to launch a new gaming franchise. For our second segment, we go in blind on a game that came out way before Too Human.

For more episodes of Replay, check out our Replay hub, or click on the banner below to watch episodes on YouTube.

A brasileira Solvian empregou técnicas de machine learning e algoritmos de análise de espectro para desenvolver uma plataforma de industrial de Internet das Coisas. O MachineFlow é baseado em arquitetura IoT e coleta dados por meio de sensores microprocessados de baixo custo, distribuídos em um barramento imune a ruídos.

Estes dispositivos realizam leituras de diversas variáveis e se comunicam com um gateway que envia os dados para um servidor em nuvem. Com isso, o sistema possibilita a manutenção por monitoramento de condição (Condition Monitoring), identificando qualquer comportamento que fuja da condição normal de operação em tempo real.

Três variáveis são monitoradas: vibração triaxial, que permite detectar antecipadamente falhas por meio de características do sinal vibratório; térmica, que acompanha a degradação e lubrificação das máquinas a partir do controle de aquecimento; e elétrica, que possibilita a identificação de irregularidades elétricas que podem sinalizar falhas.

“É a própria máquina que avisa quando precisa de manutenção”, detalha a provedora, afirmando que a tecnologia aumenta os índices de disponibilidade e de vida útil dos equipamentos e diminui significativamente os custos de manutenção preventiva das instalações industriais.

O desenvolvimento do sistema levou cerca de 18 meses entre concepção e testes finais e contou com a participação de especialistas em IoT, analytics e computação em nuvem.

De acordo com a Solvian, o sistema é não intrusivo e possibilita a gestão e manutenção preditiva de máquinas elétricas rotativas (equipamentos destinados a converter energia mecânica em energia elétrica e vice-versa) e também sensoriza e controla outras variáveis relevantes para indústrias e grandes instalações em geral, tais como consumo de água e gás, temperatura, umidade, etc.

A fabricante enxerga potencial para aplicação da tecnologia, especialmente, em equipamentos como bombas, compressores, turbinas e geradores, elevadores, esteiras, acionadores, atuadores, válvulas e outros. A plataforma também pode ser utilizada em qualquer infraestrutura empresarial para o gerenciamento de utilities (água, eletricidade e gás).

Um estudo conduzido pela McKinsey Global Institute aponta que a IoT terá um valor econômico entre US$ 4 trilhões e US$ 11 trilhões em 2025, equivalendo a cerca de 11% da economia mundial. Segundo o instituto, os fornecedores e empresas usuárias que se adaptarem mais rapidamente às novas tecnologias serão as que obterão os maiores ganhos. O estudo analisou 150 casos de uso da Internet das Coisas.