Relatório da Pesquisa sobre o Processo de Software no

CERCOMP

Sumário1. Introdução..........................................................................................................................32. Conhecimento e Uso do Processo de Software Definido.................................................53. Processo Executado Atualmente.......................................................................................84. Satisfação com o Modo de Trabalho Atual......................................................................105. Pontos Fortes e Fracos do Processo Executado e o Processo Definido........................136. Distribuição de Papéis.....................................................................................................187. Distribuição de Tempo pelas Atividades..........................................................................218. Considerações Finais......................................................................................................27Referências..........................................................................................................................28Anexo A – Questionário da Pesquisa..................................................................................29Anexo B - Planilha de Coleta de Tempo gasto com Atividades...........................................32

1. IntroduçãoEntre os dias 25 de novembro de 2009 e 2 de dezembro de 2009 foi realizada uma

pesquisa com os funcionários da Divisão de sistemas do CERCOMP (Centro de Recursos Computacionais) da UFG (Universidade Federal de Goiás) com o intuito de avaliar a percepção deles. Além disso, foi objetivo da pesquisa, coletar opiniões sobre o Processo de Software e identificar os problemas e dificuldades associados a ele associados.

Para tanto, o Grupo de Processos de Software (GPS), aqui representado pelos funcionários Daiany de Castro, Caroline Mota, Fabiana Freitas Mendes, Kássio Borges Melo e Patrícia Gomes Fernandes, contatou todos os funcionários com o intuito de marcar um horário de entrevista com cada uma deles. Apesar de terem sido contatados todos os funcionários da Divisão de Sistemas, nem todos participaram da pesquisa. O questionário que foi utilizado para conduzir as entrevistas que foram feitas é apresentado no Anexo A deste documento.

Além de funcionários da Divisão de Sistemas, também foram consultados dois funcionários que estão diretamente a ela relacionados. A lista dos participantes da pesquisa é apresentada a seguir.

• Alexandre Ferreira de Melo• Brasmeire Freitas• Daiany de Castro Vieira• Dannyel Cardoso da Fonseca• Divino Edson Cesar Morais• Douglas Carvalho• Euler Robério Sena Santos• Fernando César Silva da Mota• Geraldo Ribeiro• Gilmar de Oliveira• Guilherme Alves• Hugo Alexandre Dantas do Nascimento• Jeová Almeida• João Marcos Borges e Azevedo• Kássio Borges de Melo• Larissa Santa Cruz• Leandro Bruno Pereira Queiroz• Lygia Reis• Murilo Adriano• Pablo Leonardo Mendes• Plínio Almeida de Oliveira• Rosa da Silva Nunes• Rosângela Sousa• Vinicius Pessoni• Wilane Carlos da Silva

Este documento tem como objetivo apresentar os resultados da pesquisa referida. Para tanto, a Seção 2 apresenta o quanto o processo definido no Manual de Produção de Software é conhecido e utilizado na Divisão de Sistemas. Na Seção 3 é apresentado o modo de trabalho atual quando se trata de uma manutenção e de um desenvolvimento novo. A próxima seção, Seção 4, apresenta o grau de satisfação da equipe com este modo de trabalho atual. Os pontos fortes e fracos do modo de trabalho atual e do processo definido no Manual de Produção de Software são apresentado na Seção 5.

O modo com os papéis estão distribuídos pelos funcionários da Divisão de Sistema é apresentado na Seção 6. Já o modo como as atividades executadas estão distribuídos pelo tempo dos funcionários é apresentado na Seção 7.

Finalmente, na Seção 8 são apresentadas as considerações finais relacionadas à pesquisa, destacando as principais conclusões que se pôde chegar.

2. Conhecimento e Uso do Processo de Software Definido

Os entrevistados também foram questionados sobre a familiaridade que têm com os subprocessos que compõem o Processo de Software, descrito no Manual de Produção de Software do CERCOMP. A familiaridade com um subprocesso diz respeito a saber quais atividades fazem parte dele, quais templates estão associados às suas saídas, quais papéis o executam. A Figura 2.1 mostra o quantitativo de respostas para cada subprocesso que compõe o processo atualmente.

Figura 2.1 – Familiaridade dos funcionários com subprocessos do Processo de Software

Como pode ser observado na Figura 2.1, os subprocessos técnicos (Análise e Solução Técnica) são os mais conhecidos pelos funcionários entrevistados. Os subprocessos gerenciais (Gerência de Projetos, Gerência de Requisitos e Gerência de Configuração) são os menos conhecidos. Além disso, quase 40% dos entrevistados afirmou não conhecer qualquer subprocesso do Processo de Software definido. Dois dos entrevistados afirmaram que ninguém lhes forneceu o Manual para que lessem. Mesmo assim um deles afirmou que deu uma olhada.

Aqueles que se consideram familiarizados com algum subprocesso afirmaram, em sua maioria, que obtiveram tal conhecimento por meio de discussões/conversas com membros do GPS, como ilustra a Figura 2.2.

Um dos funcionários afirmou que o próprio uso do processo o ajudou a compreendê-lo e conhecê-lo melhor. Segundo ele, este foi um dos meios mais eficazes de obter conhecimento sobre o processo. Um outro colaborador também apontou o método de tentativa e erro como um dos que utilizou no aprendizado do processo.

Outro entrevistado afirmou que também aprendeu o processo por meio dos próprios documentos, feitos seguindo os templates definidos, que ele tinha que ler e compreender. Esta foi, segundo ele, a forma mais eficaz de aprender sobre o processo.

Figura 2.2 – Meios de obtenção de conhecimento sobre o Processo de Software

Além disso, como mostra a Figura 2.3, outros meios eficazes para obter conhecimento sobre o processo, segundo os participantes da pesquisa, são as discussões/conversas com os membros do GPS e leituras e estudos individuais. Isto pode sugerir que uma estratégia de fornecer tempo para estudo individual para aqueles que irão utilizar o processo seguido de tempo para discutir com o GPS pode ser mais eficaz do que simplesmente fornecer treinamentos formais.

Figura 2.3 – Meios de obtenção de conhecimento sobre o Processo de Software mais eficazes

Um dos funcionários afirmou que não há forma mais eficaz de obter conhecimento sobre o processo, pois uma forma complementa outra.

Quando perguntados sobre o uso dos subprocessos do Processo de Software nas atividades rotineiras, as diferenças entre os subprocessos gerenciais e técnicos são ainda

maiores, como mostra a Figura 2.4.

Figura 2.4 – Uso dos subprocessos do Processo de Software

Menos de 5% dos funcionários afirmou fazer uso de algum dos subprocessos gerenciais. O subprocesso mais utilizado é o de Análise (quase 35% dos entrevistados).

Todavia, a maioria dos funcionários (quase 50% do total) afirmou que não está fazendo uso de qualquer subprocesso. Alguns comentários ressaltam os seguintes pontos sobre esta falta de uso dos subprocessos do Processo de Software:

• O Processo de Software está longe do que se está acostumado a fazer;• Gostaria de aprender o Processo de Software para se organizar melhor, mas a

sobrecarga e a pressa têm dificultado isto. Outro colaborador também comentou que tudo que tem feito tem sido emergencial.Um dos entrevistados, que começou a trabalhar no CERCOMP há menos de seis

meses, afirmou que tem utilizado o Processo de Software definido para suas atividades, mas que foi por iniciativa própria. Ninguém o aconselhou a utilizá-lo.

3. Processo Executado Atualmente

Durante a pesquisa conduzida no CERCOMP, foi requisitado que cada colaborador descrevesse como o processo de manutenção e desenvolvimento ocorrem na organização.

A manutenção, neste caso, é entendida como qualquer modificação realizada em um produto já existente. A Figura 3.1 mostra as atividades, com a sequência de execução, encontradas durante a pesquisa. A figura mostra todas as atividades observadas, ou seja, pode ser que, uma execução específica do processo não contenha uma ou mais atividades.

Figura 3.1 Processo de Manutenção atualmente executado

Em geral, todas as instâncias de execução do processo executam as atividades de “receber requisição”, “analisar requisição”, “implementar requisição” e “colocar em produção”. Estas atividades estão coloridas de cinza na Figura 3.1.

Foram encontrados sete meios de entrada de uma requisição para os funcionários da Divisão de Sistemas: RT, telefone, email, ocorrência de evento, necessidade de refatoração, reunião e via Gerente de Sistemas. Destes, os meios mais utilizados são RT, telefone e email.

A análise da requisição pode ser para verificar se o que foi relatado é de fato um problema, e/ou verificar se há tempo disponível para implementar a requisição, e/ou para priorização, e/ou para verificar o impacto no sistema como um todo. Além disso, ela pode ou não ser registrada, pode ser feita durante o próprio telefonema, e pode ter o prazo imposto pelo requisitante ou definido em conjunto com ele.

Sobre a atividade de “fazer o design da requisição”, apenas um dos funcionários relatou que a executou e apenas em uma situação específica de refatoração de um sistema.

A atividade “implementar requisição” na maioria das vezes é realizada sem qualquer design ou análise da requisição. Em apenas um caso o código foi verificado em relação ao design produzido para a requisição.

Cerca de metade dos funcionários declarou que a gerência de versões (colocar o código produzido no svn) é uma das preocupações durante a execução do processo de manutenção.

Já a atividade de “testar solução” foi declarada como parte do processo pela a maioria dos funcionários. O teste pode ser baseado na entrada e saída desejada, pode ser feito apenas se a requisição não for urgente e pode ser feito também em relação ao desempenho.

A atividade “colocar em produção” consiste em colocar o código produzido no servidor correto e avisar (por email, TR ou telefone) o requerente que a requisição foi finalizada.

Apenas dois funcionários disseram que realizam alguma atividade de gerência. Esta gerência consiste em colocar as atividades da manutenção do RedMine e fazer o acompanhamento dos tickets.

Em relação a desenvolvimento novo, a maioria dos funcionários que descreveu o processo utilizado afirmou ter tentando ou usado o processo. Todas as tentativas, entretanto, falharam, seja porque o processo foi abandonado no meio do projeto, ou pelo fato de ter se utilizado apenas uma parte do processo.

Dois dos funcionários entrevistados afirmou ter utilizado um processo de gerência semelhante àquele implementado pelo RedMine (cadastro, acompanhamento e finalização de tickets).

Os motivos de falha de uso do processo foram devido a um prazo pequeno para desenvolvimento do produto ou mudanças na equipe do projeto (um colaborador deixa a equipe ou a equipe prometida não é disponibilizada). Alguns outros motivos de falha podem ser derivados dos pontos fracos do processo definido, apresentados na Tabela 5.4 da Seção 6.

Quanto à gerência de configuração é mais executada a parte que trata da questão de armazenamento e da gerência de versões, principalmente por causa do uso do svn.

4. Satisfação com o Modo de Trabalho Atual

Durante a pesquisa, os funcionários foram questionados sobre a satisfação que têm com o modo de trabalho atual. O objetivo com tal questionamento foi averiguar a predisposição dos entrevistados a mudar seu modo de trabalho, pela eventual insatisfação com o mesmo. A Figura 4.1 apresenta o resultado das respostas para esta questão.

Figura 4.1 – Grau de satisfação pessoal com o modo de trabalho atual

Cerca de 44% afirmou estar medianamente satisfeito. Alguns comentários foram feitos sobre este grau de satisfação. Alguns pontos colocados nestes comentários foram:

• Poderiam se dedicar mais. A desaceleração no trabalho poderia aumentar a produtividade. Seria necessário, para melhorar, organizar melhor o tempo.

• Está há algum tempo no mesmo projeto, e isto o tem deixado desanimado, pois gosta de coisas novas.

• Cada um faz seu trabalho de forma diferente. Não estão uniformes, o que dificulta o gerenciamento. De acordo com o entrevistado, se todos fizessem de modo igual, ainda que sem usar o processo, seria mais fácil de gerenciar.

• Outro comentário, feito por dois dos funcionários entrevistados, é de que falta pessoal. São muitas responsabilidades e atribuições feitas para uma mesma pessoa, e acabam tendo que protelar algumas coisas devido às urgências. De acordo com um destes entrevistados, gostaria de poder focar em apenas uma coisa. Deveria ter alguém, por exemplo, para mexer apenas com a documentação.

• O que falta é tempo para realizar todas as tarefas que eles têm.• A documentação feita nem sempre é lida. Por exemplo, em vez de passar para o

desenvolvedor ler os documentos de análise, o analista prefere se reunir com ele e passar tudo que tem que ser feito oralmente, porque é mais rápido.

• O fato de estar medianamente satisfeito é simplesmente porque já cansou da área de informática.

• A insatisfação vem quando tem que abrir vários documentos ao mesmo tempo, para ler casos de uso.

• Em relação a outros lugares, trabalhar no CERCOMP é infinitamente melhor. De

acordo com este entrevistado, em relação ao processo, parece muito burocratizado (apesar de não conhecê-lo bem). Mesmo quem trabalha com ele não o domina completamente, o que causa dificuldades. Mas sem usá-lo, falta documentação para os sistemas. E os sistemas sem documentação são mais difíceis de serem mantidos. Em relação à estrutura física, ter duas salas dificulta a comunicação. Seria também interessante ter rodízios de papéis e de equipes.A maioria destes comentários, como poderá ser observado mais a frente no

presente relatório, foi citada como pontos a melhorar no Processo de Software atual (ver Tabela 5.2). Isto sugere que estes funcionários não estão completamente satisfeitos com seu modo de trabalho atual por conta destas dificuldades associadas ao Processo de Software atual.

Adicionalmente, cerca de 36% afirmou estar satisfeito ou muito satisfeito. Os comentários destes funcionários envolviam as seguintes questões:

• Há sempre a busca na melhoria do software produzido e trabalham com o que gostam.

• O Processo de Software não é utilizado porque que prefere trabalhar do jeito dele, fazendo e depois documentando.

• Por estar trabalhando sozinho tem se saído bem assim. Mas sem uma equipe as chances de aprendizado diminuem. Outro entrevistado afirmou que está muito satisfeito porque está aprendendo muito.

• Está mais satisfeito porque começaram a usar o processo mais fielmente, e isto o deixou mais confortável.Apenas 20% dos entrevistados declarou estar pouco satisfeito ou insatisfeito. Os

comentários destes funcionários abordaram os seguintes pontos:• As atividades estão muito centralizadas em um único colaborador. Este alto grau

de responsabilidade e de dependência dele não é bom para ninguém.• Nem tudo funciona como deveria. Por exemplo, a análise é muito complexa para o

desenvolvedor e muitas vezes o levantamento de requisitos não é realizado corretamente, gerando muitas dúvidas.

• O barulho e a falta de integração entre a equipe são pontos que contribuem para certa insatisfação.

• A pouca satisfação é deviso ao fato de não se seguir o que foi estabelecido para ser seguido.Os entrevistados também foram perguntados sobre a percepção que têm do grau

de satisfação de colegas de trabalho e de usuários de seus serviços com seu atual modo de trabalho. A Figura 4.2 mostra as respostas que foram obtidas.

Figura 4.2 – Grau de satisfação de colegas e usuários com o modo de trabalho atual

Pouco mais de 40% dos entrevistados afirmou que considera que colegas e usuários estejam satisfeitos ou muito satisfeitos com seu modo de trabalho atual.

Além disso, cerca de 33% dos entrevistados considera que colegas e usuários estejam medianamente satisfeitos, enquanto apenas 13% considera que estejam pouco satisfeitos. Nenhum entrevistado afirmou que considera que seus colegas e usuários estejam insatisfeitos com seu modo de trabalho atual. Um dos comentários feitos por estes funcionários é que para o usuário não interessa o modo de trabalho, e sim o prazo. Se o processo aumentar o tempo para entrega de um produto, para o usuário isto será pior.

Um dos comentários dos entrevistados que afirmaram que os colegas e usuários estão pouco satisfeitos com o modo de trabalho atual, é de que isto ocorre porque falta empenho dos funcionários em aumentar este grau de satisfação. As pessoas não estão abertas e disponíveis para isto. Outro comentário sobre esta questão afirmava que o pessoal pensa que estão enrolando, ao fazer a documentação. Outro colaborador acredita que seus colegas estão pouco satisfeitos porque ficam pouco tempo juntos.

Finalmente, cerca de 13% não soube responder ou fez outros comentários sobre esta questão. Um destes comentários, feitos por um dos funcionários que têm utilizado o processo, é de que as pessoas não têm interesse no processo e acham que é muita documentação.

5. Pontos Fortes e Fracos do Processo Executado e o Processo Definido

Os funcionários que participaram da pesquisa também foram questionados sobre os pontos fortes e fracos tanto do processo que têm executado atualmente (seja seguindo ou não o Processo de Software definido) e sobre os pontos fortes e fracos do Processo de Software do Manual de Produção de Software. As Tabelas 6.1 a 6.4 apresentam as respostas dadas, contabilizando a quantidade de vezes em que foram citadas nas entrevistas.

Pontos Fortes do Processo de Software Atual # Citações

Conhecimento que têm da instituição e dos sistemas 2

O desenvolvedor tem voz mais ativa sobre o que está sendo feito no produto 2

Uso de framework para ajudar no desenvolvimento 2

Geração de documentação para os sistemas 2

Agilidade na identificação e resolução de problemas 2

Os documentos facilitam a compreensão 1

Os documentos facilitam a comunicação 1

O SAU minimizou a quantidade de telefonemas que têm que atender para falar com o usuário

1

Forte contato com analistas, trazendo ganho de tempo para os desenvolvedores 1

ScriptCase permite desenvolvimento inicial rápido 1

Boa interação entre a equipe (interesse de todos, vontade de ajudar) 1

Template de abertura de OS fácil e simples 1

Agilidade no atendimento das urgências 1

Execução de procedimentos de controle de versão 1

Manutenção da documentação (de modo que esteja sempre atualizada) 1

A análise tem sido feita de forma adequada 1

Forte contato com o usuário 1

Análise feita considerando todas possibilidades 1

O Manual de Produção de Software tem sido seguido 1Tabela 5.1 – Visão dos pontos fortes do Processo de Software atual

Alguns dos pontos fortes colocados na Tabela 5.1 dizem respeito ao Processo de Software definido no Manual, pois partiram de funcionários que o estão utilizando.

Como pode ser notado, os funcionários têm visões diferentes dos benefícios do Processo de Software atual. Poucos apontaram os mesmos itens como pontos fortes. Isto pode ocorrer pelo fato de que, como discutido na Seção 4, as pessoas não executam o mesmo processo. Com isto, seus diferentes processos de software têm diferentes pontos fortes.

A Tabela 5.2 apresenta o que os funcionários consideram como pontos fracos do Processo de Software atual.

Pontos Fracos do Processo de Software Atual # Citações

Falta de documentação 5

Falta de organização 3

Falta de tempo, por conta de prazos de trabalho muito apertados 3

Falta de padronização 2

Falta de motivação 2

Falta de ferramentas 2

Falta de pessoas 2

Demora no cumprimento de tarefas, por falta de motivação 1

Alto grau de dependência do trabalho alheio, que aparenta gerar empecilhos no seu próprio trabalho

1

Dificuldade de acessar vários documentos ao mesmo tempo 1

Dificuldade no uso dos templates 1

Desorganização pela grande quantidade de tarefas 1

Dificuldade de avaliar, priorizar e estimar tarefas 1

Falta de capacitação para execução dos papéis 1

Constantes mudanças em pontos que já eram considerados definidos 1

Ter que atender telefones, mesmo com o SAU para fazer isto 1

Falta de disciplina 1

Falta de comprometimento com as fases e o padrão 1

Falta de resolução de tickets 1

Muito tempo gerando documentação 1

Tempo maior de resolução de problemas, pelo foco que têm na agilidade 1

Dificuldade de pegar sistemas já prontos para trabalhar 1

Não executar o processo 1

Falta de controle de mudanças 1

Não há divisão de papéis 1

Falta de tempo e priorização para completar tarefas antes de começar outras 1Tabela 5.2 – Visão dos pontos fracos do Processo de Software atual

Em relação aos pontos fracos do Processo de Software houve um maior número de pessoas identificando os mesmos itens. Isto pode indicar que os diferentes processos que têm sido executados falham em pontos semelhantes, do ponto de vista dos funcionários entrevistados.

O item que recebeu a maior quantidade de citações (pouco mais de 20%) foi a falta de documentação dos sistemas, decorrente da utilização do Processo de Software atual. A falta de organização na execução das tarefas e a falta de tempo por conta de prazos muito apertados (e que gera muita pressão sobre os funcionários, além de sobrecarga), também estão entre os itens mais citados.

Alguns dos pontos fracos citados na Tabela 5.2 também dizem respeito ao Processo de Software do Manual. A Tabela 5.3, por sua vez, apresenta as respostas dos funcionários para a pergunta específica sobre quais são os pontos fortes do Processo de Software do Manual.

Pontos Fortes do Processo de Software do Manual # Citações

A documentação e “materialização” dos sistemas 10

Padronização da documentação e do processo 6

Definição de papéis e responsabilidades 4

Facilita o entendimento do sistema em questão 3

Aumenta a troca de informações e a integração entre as equipes 3

Proporciona maior organização 2

Visibilidade do volume de trabalho e dos custos associados 2

Facilita o acompanhamento de tarefas 2

Templates ajudam no início da execução do processo 1

O subprocesso de Análise, como está, não é burocrático e satisfaz as necessidades 1

A busca de aceitação dos requisitos 1

Redução da centralização de responsabilidade e de conhecimento em uma única pessoa 1

Ajuda a saber por onde começar o trabalho 1

Segue um padrão nacional de desenvolvimento de software (o MPS.BR), facilitando a inserção de pessoas que já estão acostumadas com ele

1

Sistematização do processo 1

Desenvolvimento cada vez mais rápido 1

O subprocesso de Análise, que é importante tanto para desenvolvimento quanto para manutenção, e o subprocesso de Implementação

1

Documenta os requisitos 1

Tabela 5.3 – Visão dos pontos fortes do Processo de Software definido no Manual de Produção

Quando questionados sobre os benefícios do Processo de Software do Manual, a maioria dos funcionários apontou a documentação dos sistemas como ponto forte. É interessante notar que este é um benefício que supre uma deficiência do Processo de Software atual (que é justamente a falta de documentação, como mostra a Tabela 5.2).

A padronização da documentação e do próprio processo, assim como a definição clara de papéis e responsabilidades também foram apontados como pontos fortes do Processo de Software do Manual. Estas também são questões apontadas como pontos fracos do Processo de Software atual, na Tabela 5.2.

A Tabela 5.4, por sua vez, apresenta o ponto de vista dos funcionários do CERCOMP sobre os pontos fracos do Processo de Software definido no Manual.

Pontos Fracos do Processo de Software do Manual # Citações

Falta de ferramentas de apoio padronizadas 4

Quando uma pessoa trabalha sozinha em um produto (fazendo tudo), é difícil fazer tudo o que diz o processo

3

Muito tempo gasto com documentação (escrita e manutenção) 3

Falta de pessoal 2

Grande quantidade de documentos 2

Alguns documentos são redundantes 2

Falta de um roteiro mais resumido do processo 1

Dificuldade de identificar o que é relevante de ser documentado 1

Dificuldade de fazer o acompanhamento das tarefas 1

Demora e burocracia na aprovação de documentos 1

Muita burocracia 1

Alguns usuários não sabem o que querem e não ajudam 1

Equipes muito pequenas 1

Falta de cultura 1

Falta de agilidade 1

Falta de processo definido de Implementação 1

Processo imaturo 1

Documentos deveriam ser mais refinados e opcionais (para poderem variar de projeto para projeto)

1

Melhor definição do percentual de esforço a gastar com cada fase de um projeto (para não chegar no fim e ainda estar fazendo análise, por exemplo)

1

Nem todos estão inseridos no processo, nem mesmo os superiores 1

Falta de uso, dificultando a identificação de melhorias 1Tabela 5.4 – Visão dos pontos fracos do Processo de Software definido no Manual de Produção

A falta de ferramentas de apoio ao processo foi o ponto fraco mais citado pelos funcionários. Isto, segundo os funcionários, dificulta o uso do processo. Além disso, quando uma pessoa atua em todos os papéis em um determinado produto, o processo é burocrático e difícil de ser aplicado, segundo alguns dos funcionários entrevistados. Finalmente, um dos itens muito citados como ponto fraco também é a grande quantidade de tempo gasta com a documentação. Um dos entrevistados até mesmo sugeriu que houvesse um grupo dedicado a cuidar da documentação (tanto da sua criação, quanto da sua manutenção).

Os funcionários também foram questionados sobre o sentimento que têm quando são pedidos para utilizar o processo ou que teriam caso isto ocorresse. A Figura 5.1 mostra as respostas que foram obtidas. A maioria dos entrevistados declarou se sentir seguro no uso do Processo de Software.

Figura 5.1 – Segurança no uso do Processo de Software

Aqueles que declararam não se sentir seguros com o uso do Processo de Software, indicaram as razões apresentadas na Tabela 5.3.

Causas # Citações

Falta de conhecimento do Processo de Software/Necessidade de aprender o Processo de Software

6

Muita pressão que não tem sido controlada para permitir a adoção do processo 2

Alto índice de manutenções 1

Desmotivação pelas constantes mudanças de prioridade 1

Muitas requisições emergenciais 1

Falta de pessoal 1

Em requisições emergenciais, o Processo de Software emperraria o trabalho 1

Acúmulo de atividades 1

Processo imaturo 1Tabela 5.5 – Causas para o sentimento de insegurança no uso do Processo de Software

Desta forma, segundo os funcionários, ainda é preciso disponibilizar mais meios para que o processo seja aprendido e conhecido por todos que devem utilizá-lo. Além disso, é preciso minimizar as pressões sobre as tarefas que têm sido executadas atualmente, para tornar a adoção do processo possível.

6. Distribuição de Papéis

Outro ponto que foi investigado durante a pesquisa feita no CERCOMP diz respeito à distribuição de papéis entre os funcionários. Foram pesquisadas tanto a distribuição atual quanto a distribuição a partir dos papéis que os funcionários desejam exercer.

A Figura 6.1 mostra a quantidade de funcionários que desempenham determinados papéis no CERCOMP. Os papéis mais desempenhados são os de Analista e de Desenvolvedor, com um total de 18 pessoas trabalhando em algum sistema responsável por essa atividade dentro do projeto. Em seguida vem o papel de Testador, com 13 ocorrências. Há ainda uma grande quantidade de pessoas exercendo o papéis de Atendente, Gerente de Produto e Gerente de Projeto. Não houve ocorrências de pessoas desempenhando os papéis de Gerente de TI, Patrocinador e Solicitante.

Figura 6.1 – Quantidade de funcionários desempenhando cada papel

A Figura 6.2 mostra a quantidade de pessoas que não executam determinado papel, mas têm interesse em exercê-lo no CERCOMP. O mais citado na entrevista foi o de Gerente de Projetos, totalizando 4 pessoas. Em seguida vem o desejo de exercer a função de Analista, com 3 ocorrências.

An

alis

ta

Ate

nd

ent

e

Des

en

volv

ed

or

Fo

rn.

de

Re

qu

isito

s

Ge

r. d

e P

rod

uto

Ge

r. d

e P

roje

to

Ge

r. d

e C

on

figu

raç

ão

Ge

r. d

e R

eq

uis

it os

Ge

r. d

e S

iste

ma

s

Ge

r. d

e T

I

Pa

tro

cin

ad

or

Pro

jetis

ta

Te

sta

dor

So

licita

nte

0

2

4

6

8

10

12

14

16

18

20

Figura 6.2 – Quantidade de papéis que os funcionários não desempenham, mas gostariam de desempenhar

A Figura 6.3 mostra a quantidade de pessoas gostariam de continuar exercendo determinado papel. Das pessoas que responderam, a maioria já executa o papel de Desenvolvedor e de Analista e gostaria de continuar executando-o.

Figura 6.3 – Quantidade de papéis que os funcionários querem continuar exercendo

Como mostra a Figura 6.4, existe uma grande quantidade de “euquipes”, ou seja, equipes que possuem apenas uma pessoa que realiza tudo no projeto. Segundo informações coletadas dos participantes, existem atualmente 42 sistemas sendo desenvolvidos ou mantidos no CERCOMP. Destes, cerca de 75% é mantido ou desenvolvido por apenas uma pessoa.

An

alis

ta

Ate

nd

en

te

De

se

nv

olv

ed

or

Fo

rn.

de

Re

qu

isito

s

Ge

r. d

e P

rod

uto

Ge

r. d

e P

roje

to

Ge

r. d

e C

on

figu

raç

ão

Ge

r. d

e R

eq

uis

it os

Ge

r. d

e S

iste

ma

s

Ge

r. d

e T

I

Pa

tro

cin

ad

or

Pro

jetis

ta

Te

sta

do

r

So

licita

nte

01

23

4

An

alis

ta

Ate

nd

en

te

De

se

nv

olv

ed

or

Fo

rn.

de

Re

qu

isito

s

Ge

r. d

e P

rod

uto

Ge

r. d

e P

roje

to

Ge

r. d

e C

on

figu r

aç

ão

Ge

r. d

e R

eq

uis

it os

Ge

r. d

e S

iste

ma

s

Ge

r. d

e T

I

Pa

tro

cin

ad

or

Pro

jetis

ta

Te

sta

do

r

So

licita

nte

02

46

810

Figura 6.4 – Tamanho das equipes no CERCOMP

Um colaborador comentou que deveria existir o papel de documentador, que seria aquele que soubesse documentar qualquer coisa, revisasse os documentos e padronizasse tudo. Ele seria responsável por manter atualizada a documentação de todos os sistemas. Um outro colaborador informou que não tem um papel específico que gostaria de desempenhar, mas prefere ser projetista. Gosta de estudar coisas novas, seria bom em pesquisar novas tecnologias. Houve ainda um colaborador que disse que seria importante documentar pois as informações estão todas na cabeça dele, seria interessante passar pra frente.

75%

20%

4%2%

Pessoas X Sistemas

1 pessoa 2 pessoas3 pessoas4 pessoas

7. Distribuição de Tempo pelas Atividades

Os funcionários que participaram das entrevistas realizadas, também foram solicitados a informar o tempo que eles gastam por semana em cada uma das atividades que realizam. Os entrevistados foram orientados ou a preencher a planilha das atividades contabilizando 40 horas semanais (e 25 horas semanais para os que trabalham apenas meio período), ou contabilizando através de porcentagens. Tivemos, em alguns casos, entrevistados que preencheram a planilha contabilizando mais que 40 horas semanais ou mais que 100%. A Figura 7.1 mostra a distribuição geral do tempo dos entrevistados para cada um dos tipos de atividades.

Figura 7.1 – Distribuição Geral do Tempo dos Entrevistados para os Tipos de Atividades

As atividades de construção de software correspondem à maior parte dos tipos de atividades executadas na Divisão de Sistemas do CERCOMP. Segundo um dos entrevistados é um ponto positivo ter uma porcentagem maior na construção do software, visto que julga o desenvolvimento ágil mais eficaz para a instituição. Contudo, outros entrevistados julgaram isto como sendo um ponto negativo por não terem tempo de se dedicarem às atividades formais de documentação, o que representa a falta de padronização e o maior gasto de tempo com manutenção do produto.

Ainda nesta figura, percebe-se que a outra metade do tempo é utilizada para atividades que envolve a comunicação, o retrabalho e a gerência (incluindo as atividades informais de gerência). Além disso, percebe-se que não se investe muito tempo na análise inicial das requisições de desenvolvimento ou de manutenção de software, em atividades de gerenciamento de dados, no registro inicial de requisição e no comunicado verbal.

47%

20%

15%

12%

5%1%1%0%

Tipos de Atividades

ConstruçãoComunicaçãoGerênciaRetrabalhoAnálise InicialDBARegistro Inicial de RequisiçãoComunicado Verbal

Figura 7.2 – Porcentagem de tempo gasto com as atividade do tipo Comunicação

Conforme demonstrado na Figura 7.2, mais de 40% do tempo gasto para executar as atividades de comunicação é atribuída ao Atendimento, ou seja, a estatística demonstra que a criação do SAU não eliminou os atendimentos aos usuários. Um dos entrevistados apontou o SAU como sendo um dos pontos fracos do processo atual de trabalho, pois apesar dele existir não está poupando a Divisão de Sistemas de fazerem atendimentos aos usuários. Por outro lado, observa-se que a menor parte do tempo é gasto para realizar comunicados, isto significa que grande parte da comunicação não tem sido registrada e padronizada como define o Manual de Processo de Software.

43%

35%

22%

Comunicação

AtendimentoAjudaComunicado

Figura 7.3 - Porcentagem de tempo gasto com as atividade do tipo Análise Inicial

Na Figura 7.3 é possível notar que a maior parte das análises de requisição de usuário é realizada informalmente, isto é, 84% do tempo gasto com a análise inicial de uma solicitação corresponde a uma análise informal, sendo que apenas 9% do tempo é utilizado para o registro das requisições do usuário, e ainda, somente 7% das análise inciais são feitas formalmente. Isto demonstra que a análise de requisição de usuário ainda é feita sem padronização, sem registro e sem utilizar o que foi definido no Manual de Produção de Software.

84%

9%

7%

Análise Inicial

Análise informal de requisição de usuárioRegistro de requi-sição de usuárioAnálise formal de requisição de usuá-rio

31%

15%

12%

10%

7%

6%

6%

4%4%

4%2%

ConstruçãoCodificação para me-lhoria de produto existenteTeste ad hoc

Codificação de novo módulo/produtoDefinição formal de requisitos

Definição informal do design detalhado do softwareDefinição formal do design detalhado do software

Definição informal de requisitos

Definição formal da arquitetura do softwa-reTeste planejado

Definição informal da arquitetura do softwa-reCriação de material de ajuda

Figura 7.4 - Porcentagem de tempo gasto com as atividade do tipo Construção

Conforme demonstrado na Figura 6.4, quase um terço das atividades de construção do software corresponde a “Codificação para melhoria de produto existente”, ou seja, é gasto um esforço maior com a manutenção do software no desenvolvimento de novos módulos de sistemas já existentes. Além disto, nota-se que os testes realizados são predominantemente ad-hoc, isto é, sem documentação. Isto confirma o fato da falta de documentação como um ponto fraco do processo de software atual, afirmado por alguns entrevistados. Percebe-se ainda, que pouco do tempo é gasto com a criação de manuais de ajuda e com a documentação do design e arquitetura do software, o que significa que o Manual de Produção de Software não está sendo aplicado nestas fases.

Figura 7.5 - Porcentagem de tempo gasto com as atividade do tipo Retrabalho

Segundo os dados apresentados na Figura 7.5 nota-se que no processo atual de trabalho dos funcionários, gasta-se mais tempo na codificação para correção de erro de produtos já existentes que para atualizar artefatos, ou seja, existem modificações na codificação dos produtos que não são registradas. Para alguns dos entrevistados estes dados correspondem a um ponto positivo do processo atual, uma vez que julgam o atendimento de identificação e resolução de problemas ágil. Porém, por outro lado, alguns entrevistados julgam estes dados como sendo um ponto negativo da forma de trabalho atual, já que a falta de documentação gera o descontrole das mudanças codificadas.

53%

47%

Retrabalho

Codificação para correção de erro de produto existenteAtualização de arte-fatos

Figura 7.6 - Porcentagem de tempo gasto com as atividade do tipo Gerência

Segundo os dados apresentados na Figura 7.6 nota-se que a maior parte do tempo gasto em atividades gerenciais são “descrição e análise informal de requisição de mudança em requisito”, “obtenção de aprovação informal dos requisitos”, “planejamento de atividades” e “acompanhamento das atividades”. Menos de 30% do tempo dedicado às atividades de gerência corresponde a finalização do projeto e definição do escopo inicial do projeto.

25%

24%

14%

12%

8%

7%

6%4%1%0%0%

Gerência

Descrição e análise informal de uma re-quisição de uma mudança em requisi-toObtenção de apro-vação informal dos requisitos

Planejamento de atividadesAcompanhamento de atividades

Definição informal de escopo inicial de pro-jetoFinalização informal de projeto

Definição formal de escopo inicial de pro-jeto

Descrição e análise formal de uma requi-sição de uma mu-dança em requisitoPlanejamento de pro-jetoObtenção de apro-vação formal dos re-quisitosAcompanhamento de projeto

Finalização formal de projeto

89%

11%

Atividades de Gerência

InformalFormal

Figura 7.7 - Porcentagem do tipo de atividades de Gerência

Além disso, conforme mostrado na Figura 7.7 percebe-se que quase todas as atividades de gerência realizadas na Divisão de Sistemas do CERCOMP são feitas informalmente, isto significa que o gerenciamento dos projetos não estão sendo feitos seguindo o Manual de Produção de Software. É interessante notar que a falta de padronização, de organização e de documentação estiveram entre os itens mais citados como os principais pontos fracos do processo de software atual, e que a falta de um gerenciamento formal pode levar a estes problemas.

8. Considerações FinaisA execução da pesquisa foi importante, pois demonstrou a percepção dos

funcionários em relação ao processo que atualmente é executado na organização e aquele que foi definido no Manual de Produção de Software.

Como pôde ser percebido, metade dos funcionários dizem conhecer os processos que foram definidos, mas, em especial os processos gerenciais não são executados. Apesar disso, muitos funcionários afirmaram que desempenham o papel de gerente de projeto, ainda que as atividades por ele executadas sejam simplificadas e não gerem a documentação previstas no manual.

Um outro ponto interessante observado é que muitos desejam executar o papel de gerente de projeto, pois reconhecem os benefícios que a execução processo traz para a Divisão de Sistemas.

Outro papel que muitos funcionários também afirmam executar é o de atendente, apesar da existência do SAU (Sistema de Atendimento ao Usuário).

A maioria das pessoas também declararam-se seguras para utilizar o processo definido. Entretanto, não estão insatisfeitas com o modo de trabalho atual. De acordo com Schein, para que uma mudança cultural ocorra, é necessário que os envolvidos se sintam desconfortáveis com a situação atual, por não atender aos objetivos organizacionais [Schein 2004]. Dessa forma, é bem provável que os processos definidos não sejam de fato adotados pelos funcionários, caso permaneça a percepção de que o modo de trabalho atual satisfaz plenamente os objetivos organizacionais.

Muitos dos problemas no modo de trabalho atual apresentados na Tabela 4.2 poderiam ser solucionados com a adoção do processo, em especial os processos gerenciais que são os mais utilizados. Entretanto, quando olha-se para os pontos fortes do processo definido no manual, vê-se que o maior benefício visualizado é a documentação e não a solução de alguns do modo de trabalho atual. Isso significa que eles ainda não estão claros dos benefícios advindos do uso do processo definido.

Atualmente, o processo de manutenção executado pelos funcionários é uma simplificação do fluxograma geral proposto no Manual de Produção de Software. Apesar disso, não é gerada documentação auxiliar na manutenção posterior do software.

Sobre a continuidade dos sistemas do CERCOMP é interessante que alguns funcionários mais experientes da divisão atuem como fornecedor de requisitos a fim de gerar uma documentação para os sistemas que hoje eles são especialistas e para que a organização não sofra quando estes funcionários aposentarem.

Também foi observado que grande parte dos sistemas do CERCOMP são desenvolvidos/mantidos por uma equipe de apenas uma pessoa, conforme mostrado na Seção 6.

Referências

[Schein 2004] SCHEIN, E. Organizational Culture and Leadership. Jossey-Bass, 2004.

Anexo A – Questionário da Pesquisa

NOME DO PARTICIPANTE:_________________________________________________

1) Há quanto tempo você trabalha no Cercomp?

3) Preencha a Tabela 1 identificando os sistemas (produtos de software) nos quais você tem atuado e quais papéis/funções têm exercido em cada um deles.

Tabela 1 – Sistemas e funções/papéis exercidos

3) Preencha a Tabela 2 identificando os sistemas (produtos de software) nos quais você tem atuado e quais papéis/funções você desejaria exercer em cada um deles.

Tabela 2 – Sistemas e funções/papéis que deseja exercer.

4) Com quais subprocessos do processo de software você se considera familiarizado (ou seja, conhece as atividades e os templates dos produtos relacionados)?

( ) Pré-Projeto( ) Gerência de Projeto( ) Gerência de Requisitos( ) Gerência de Configuração( ) Análise( ) Solução Técnica( ) Não me considero familiarizado com qualquer dos subprocessos do processo de

Sistemas

An

alis

ta

Ate

nd

ente

Des

en

volv

edo

r

Pat

roci

nad

or

Pro

jeti

sta

Tes

tad

or

So

licit

ante

Fo

rn. d

e R

eq

uis

ito

s

Ge

r. d

e P

rod

uto

Ge

r. d

e P

roje

to

Ge

r. d

e C

on

fig

ura

ção

Ge

r. d

e R

eq

uis

ito

s

Ge

r. d

e S

iste

mas

Ge

r. d

e T

I

An

alis

ta

Ate

nd

en

te

De

sen

vo

lve

do

r

Pat

roci

nad

or

Pro

jeti

sta

Te

stad

or

So

licit

ante

Fo

rn. d

e R

eq

uis

ito

s

Ge

r. d

e P

rod

uto

Ge

r. d

e P

roje

to

Ge

r. d

e C

on

fig

ura

ção

Ge

r. d

e R

eq

uis

ito

s

Ge

r. d

e S

iste

mas

Ge

r. d

e T

I

software

5) Como você adquiriu conhecimento sobre o processo de software? ( ) Treinamentos ministrados pelo GPS( ) Leituras e estudos individuais( ) Treinamentos realizados externamente (com recursos próprios)( ) Treinamentos realizados externamente (com recursos da UFG)( ) Discussões/conversas com os membros do GPS( ) Discussões/conversas com outros funcionários do Cercomp( ) Outras formas. Quais?

6) Qual você considerou mais eficiente?

7) Quais subprocessos do processo de software você tem utilizado no seu dia-a-dia?( ) Pré-Projeto( ) Gerência de Projeto( ) Gerência de Requisitos( ) Gerência de Configuração( ) Análise( ) Solução Técnica( ) Não tenho utilizado qualquer subprocesso do processo de software no meu dia-

a-dia

8) Qual seu grau de satisfação pessoal com o seu modo de trabalho atual?a) Muito satisfeito.b) Satisfeito.c) Medianamente satisfeito.d) Pouco satisfeito.e) Não estou satisfeito.

9) Como é o seu processo de trabalho atual durante a manutenção de um produto (distinguir entre manutenções corretivas, adaptativas, preventivas)? Dê o máximo de detalhes possível, construindo um fluxograma e o descrevendo brevemente.

10) Como é o seu processo de trabalho atual durante o desenvolvimento de um produto? Dê o máximo de detalhes possível, construindo um fluxograma e o descrevendo brevemente.

11) Quais são, na sua opinião, os pontos fortes do seu modo de trabalho atual?

12) E quais são, na sua opinião, as oportunidades de melhoria (pontos fracos) do seu modo de trabalho atual?

13) Qual sua percepção do grau de satisfação dos usuários e colegas de trabalho com o seu modo de trabalho atual?

a) Muito satisfeitos.b) Satisfeitos.c) Medianamente satisfeitos.d) Pouco satisfeitos.e) Não estão satisfeitos.

14) Quando você pensa em utilizar o processo de software ou quando alguém pede que o

utilize você:( ) Se sente seguro( ) Se sente inseguro

Justificativa:

Exemplos de justificativas:• Se sente inseguro em relação ao seu conhecimento e habilidades com o processo

e, portanto, não o utiliza por medo de não atingir os objetivos do seu trabalho• Se sente inseguro em relação ao seu conhecimento e habilidades com o processo

e, portanto, não o utiliza por medo de que te chamem a atenção pela diminuição de produtividade decorrente do uso de uma metodologia com a qual não está acostumado a trabalhar

• Sente que não há necessidade de utilizar um processo tão detalhado para o seu trabalho e, portanto, não o utiliza porque acredita que o seu modo de trabalho atual é mais eficaz e eficiente

• Acredita que seria o único seguindo as definições do processo e, portanto, não o utiliza porque os demais funcionários também não o utilizam

• Sente confiança no processo de software e nos seus conhecimentos sobre ele e, portanto, o utiliza

15) Na sua opinião, quais são os pontos fortes do processo de software?

16) E quais são, na sua opinião, as oportunidades de melhoria (pontos fracos) do processo de software, que devem ser tratadas para que ele possa ser adotado de fato no Cercomp?

17) Há alguma outra questão que não foi feita, relacionada a como tornar o processo usável no Cercomp ou a dificuldades atuais no seu uso, e que você gostaria de comentar? Qual?

Anexo B - Planilha de Coleta de Tempo gasto com Atividades