Upload
leliem
View
212
Download
0
Embed Size (px)
Citation preview
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.
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?