Seleção dos problemas que serão tratados

Finalizada a etapa de identificação e priorização dos problemas, foram determinados alguns que serão objeto de proposta de solução durante o período de execução deste projeto.

4.1.5.1 Dificuldade na priorização das atividades de desenvolvimento

O grande volume de chamados enviados ao desenvolvimento e o número considerável de desenvolvedores, faz com que a distribuição de tarefas entre eles se torne uma tarefa demorada, consumindo duas ou mais horas por dia e ainda assim com alta possibilidade de erro humano.

Para delegar uma tarefa a um desenvolvedor, o gerente deve considerar muitas características como complexidade da tarefa, necessidade de análise técnica mais apurada, perfil e experiência do desenvolvedor para a tarefa, nível de pressão do cliente, prazo necessário, entre outros. Após tomar a decisão, a tarefa é enviada ao desenvolvedor pelo software CO e fica em sua lista de tarefas aguardando o início de sua execução. E assim é feito com cada nova tarefa, o que contabiliza uma média de quinze novas tarefas por dia.

Com o passar dos dias, cada desenvolvedor fica com dezenas de tarefas esperando o início da produção, e é extremamente comum o gerente ficar olhando a lista de tarefas de cada um, alterando a prioridade, trocando de desenvolvedor, devido a constante reavaliação das prioridades, vinda da comunicação com as demais gerências, pressões de clientes, estimativas iniciais imprecisas, e assim por diante. Ocorre que para esta administração, o gerente de desenvolvimento deve saber constantemente de tudo o que ocorre com os desenvolvedores, os clientes e principalmente, o software, pois além de todo o fluxo de trabalho, ainda é necessário decidir sobre todas as implementações de software mantendo assim conhecimento sobre o escopo do produto de software.

Para que as demais gerências da empresa saibam do andamento das tarefas, estas tem que consultar a lista de tarefas de cada um dos 10 desenvolvedores, ou então questionar diretamente a gerência que por sua vez tem que obter conhecimento sobre a situação atual das tarefas para disponibilizar a resposta.

O resultado deste fluxo de trabalho adotado é a sobrecarga na gerência de desenvolvimento, que acaba muitas vezes falhando nesta tarefa. As informações imprecisas e não disponíveis de forma rápida, dificultam decisões estratégicas de outros setores, principalmente no que diz respeito ao contato com o cliente, pois por regra geral, a equipe de desenvolvimento não se relaciona com o usuário final, apesar de ocorrerem

exceções. Respostas a solicitações de clientes não são dadas de forma rápida, gerando descontentamentos.

Este fluxo de trabalho também faz com que a gerência não possa se ausentar por muito tempo, pois outros gerentes terão dificuldade de administrar o andamento destes trabalhos.

4.1.5.2 Incompatibilidade entre ambientes de desenvolvimento

Os executáveis do Procel G3 para serem compilados com sucesso e ter todas as suas características pré-determinadas, dependem de uma série de configurações de ambiente de sistema operacional e do Delphi. A equipe conta com 10 programadores com seus 10 computadores, onde os executáveis são gerados conforme cada programador conclui sua tarefa. As não conformidades ou incompatibilidades são ocasionadas por configurações inadequadas de ambiente. São situações como tamanho do executável que varia em quase 100%, mensagens de caixa de diálogo que em inglês ao invés de português, configuração de localização de código-fonte de projeto que faz um executável ser compilado com uma versão errada de código-fonte, entre outros problemas.

4.1.5.3 Dificuldade na administração das versões

Ao se concluir um trabalho de desenvolvimento de qualquer natureza, faz-se necessária a distribuição do novo executável gerado para os respectivos destinos. Exemplo: um cliente relata um bug no sistema, o desenvolvedor corrige o bug, e o novo executável deve ser gerado e entregue ao cliente.

Existem situações onde as configurações de ambiente dos desenvolvedores não estão totalmente compatíveis. Alterações que são realizadas com o tempo, possibilitam um código fonte idêntico em duas máquinas, gerando executáveis com características diferentes.

Também ocorre a possibilidade do desenvolvedor prover uma solução, liberar o executável ao cliente, e por alguma razão, não armazenar os fontes alterados no repositório, fazendo com que as demais máquinas da equipe compilem o executável sem

aquelas alterações, ou até mesmo ocorrer uma perda do código fonte por um problema na máquina local.

Mesmo com o código fonte seguro e com o executável gerado, começa a maratona de armazenar este executável no servidor de arquivos, publicar as informações sobre as alterações realizadas, relatar no CO que para solucionar o problema relatado é necessário atualizar o executável por este de versão x.y.z compilado na data “tal”. Como são muitas versões diferentes e a cópia deve ser feita para vários destinos, é comum o desenvolvedor esquecer de alguma cópia ou até mesmo copiar para uma pasta errada. A conseqüência deste erro, é muito custosa, pois só será percebido muito tempo depois quando um executável errado for instalado em outro cliente podendo gerar dados incorretos.

4.1.5.4 Performance do Software Insatisfatória.

Ao operar o sistema Procel G3, observa-se em vários pontos, sérios problemas de performance. Ao abrir alguns formulários, ou executar determinados procedimentos, o sistema demora muitos segundos, passando muitas vezes do aceitável.

Durante a navegação entre os formulários, um tempo aproximado de 1 a 3 segundos para carregar, o suficiente para irritar o usuário. Também foi observado que alguns procedimentos específicos demoram muito tempo, além do aceitável. Exemplo: observou-se que em uma base de dados de um cliente, com cerca de cinco mil produtos cadastrados, que ao realizar um orçamento, o sistema fica lento ao lançar mais de cinqüenta itens de orçamento.

4.1.5.5 Padronização de código inadequada

Para o principal produto da empresa, o Procel G3, estão alocados sete desenvolvedores dedicando-se em tempo exclusivo ao projeto, isso sem considerar gerentes e outros envolvidos, Esse código é compartilhado entre os desenvolvedores que utilizam o software Jedi para gerenciar este compartilhamento.

A rotatividade de desenvolvedores na Procel é considerada razoável e muitos deles vem de outras empresas, trazendo padrões e culturas muito diferentes, ao juntar estas culturas em uma grande equipe focada em um único projeto, o resultado é partes de códigos escritos de formas diferentes, o que dificulta muito a manutenção. Por se tratar de um projeto grande e de ciclo de vida longo, a maioria das implementações são de alterações de características para melhoramento ou edição de regras, e normalmente são realizadas por desenvolvedores diferentes.

Comentários são hora ausentes e hora excessivos, e muitas vezes não é identificado o autor da alteração, o que pode ser necessário para uma consulta posterior. É comum ocorrer de um desenvolvedor olhar uma linha de código e questionar “Quem escreveu esta porcaria?” ou “Quem foi que desabilitou esta linha que fazia tudo funcionar?”, e assim por diante.

Observa-se que sem muito controle, vários desenvolvedores editam o mesmo código, de forma que todos se envolvam, mas ninguém fica efetivamente responsável.

4.1.5.6 Desconhecimento das regras de negócio do software

Os sistemas da Procel são desenvolvidos para controlar regras de negócios empresariais que conduzem processos como financeiro, faturamento, estoque, compras, vendas e assim por diante. O conhecimento necessário para implementar nos sistemas estas regras vem do conhecimento dos gerentes e programadores que vão aprendendo ao longo dos anos o funcionamento das empresas e assim vão implementando as soluções.

Este conhecimento não está escrito de forma explícita, e cada novo colaborador da equipe precisa aprender essas regras utilizando o próprio software sem entender diretamente as regras. É fato que existe um conhecimento muito valioso de posse dos principais colaboradores e sócios da empresa, mas este conhecimento precisa sempre ser consultado diretamente com eles.

4.1.5.7 Solicitações mal definidas

As solicitações de ajustes, implementações ou relatos de bug´s nem sempre são bem definidas, sendo comum os textos serem escritos de forma muito resumida e sem a preocupação de transmitir a informação de forma completa.

Em caso de bug´s, normalmente seus relatos não explicam bem como eles ocorrem, e qual é a situação e ambiente em que é possível simular o bug, para então corrigi-lo.

Em caso de solicitações de ajustes ou novas implementações, é comum que a descrição venha de forma incompleta ou se valendo das conversas informais, em casos extremos, “Conforme conversamos, segue a solicitação sobre o assunto X”. Assim se um técnico que não participou da discussão se envolver no problema, a documentação existente não será suficiente para que ele colabore sendo necessário conversar novamente com quem originou o chamado.

Também é comum que sejam solicitadas algumas soluções para determinados problemas do cliente, porém a “solução” é estudada por pessoas sem o conhecimento técnico necessário para propor uma análise, ou que não entendem o problema de fato. É necessário que um analista experiente entenda realmente o problema para então propor uma solução.

4.1.5.8 Ausência de processo de teste de software

Atualmente quando uma nova versão é liberada pelo desenvolvimento, esta é testada apenas pelo próprio desenvolvedor, e as vezes superficialmente pelo técnico que solicitou o ajuste junto ao cliente. E esta situação facilmente permite que a versão seja entregue ao cliente com bug´s ou que o entregue não seja exatamente o que foi solicitado.

4.1.5.9 Dificuldade na análise sobre o rendimento dos desenvolvedores

Com uma equipe de dez desenvolvedores onde muitos processos produtivos ainda não são totalmente definidos e organizados, fica difícil determinar quando um programador não está tendo o rendimento adequado. Pela falta de controle e medição pode-se apenas observar de uma forma geral que o rendimento global da equipe está fraco, ou então analisar o rendimento individual de forma muito subjetiva, sem dados estatísticos.

4.1.5.10 Dificuldade no controle das tarefas em andamento

Após as tarefas já terem sido iniciadas pelos desenvolvedores, o gerente precisa constantemente avaliar se elas estão ocorrendo no tempo certo, se o tempo não está excedendo, se o desenvolvedor precisa de auxílio técnico. Atualmente, o gerente precisa estar analisando constantemente a lista de chamados de cada um ou mesmo questionar a cada um como está o andamento do trabalho. Este tempo de análise de toda a equipe costuma durar cerca de quinze minutos e ocorre várias vezes ao dia. É necessário uma alternativa para facilitar esta administração.