Introdução
No início da década de 1980, com a adoção do Paperwork Reduction (PRA/1980) nos EUA pelo Federal Paperwork Comission, surgiu o conceito de Gestão de Recursos Informacionais (GRI), cuja evolução resultou na atual teoria da Gestão da Informação e do Conhecimento. Paralelamente, para lidar com a complexidade de projetos de software cada vez mais complexos tornou-se imprescindível a existência de um processo de desenvolvimento de software (PDS), juntamente com modelos de maturidade, como por exemplo o Capability Maturity Model Integration (CMMI), que conferem certificações de vários níveis de acordo com os seus requisitos que são atendidos por determinado processo. Esse tem sido o foco da Engenharia de Software desde então.
Recentemente começaram a surgir estudos relacionando estas duas áreas, tendo
como foco principal as contribuições que a gestão da informação e do
conhecimento podem dar aos processos de desenvolvimento de software. Este
artigo insere-se nesse contexto, tendo como objetivo principal identificar
práticas de Gestão da Informação (GI) relacionadas
especificamente com a certificação de processos de desenvolvimento de
software em um modelo de maturidade (no caso o Capability Maturity Model
Integration), bem como determinar a importância da gestão da informação
para uma organização nesta situação. Faz-se isso à luz do modelo
“Ecologia
da Informação".
Para tanto o artigo se estrutura apresentando inicialmente alguns conceitos
importantes e trabalhos relacionados, além de uma breve descrição do
Capability Maturity Model Integration e do modelo Ecologia da
Informação. Em seguida, na Seção 3, têm-se detalhes da metodologia utilizada
na pesquisa. Na Seção 4 apresenta-se a discussão dos resultados da pesquisa
e na Seção 5 são feitas algu-mas considerações finais.
Conceitos e trabalhos relacionados
O Processo de Desenvolvimento de Software e os Modelos de Maturidade
Segundo Borges (2001) um Processo de Desenvolvimento de Software pode ser
visto como um conjunto de atividades, métodos, ferramentas e práticas que
são utilizadas para construir um produto de software. Humphrey apud
Borges(2001) define Processo de Desenvolvimento de Software como o conjunto de
tarefas de engenharia de software necessárias para transformar os requisitos
dos usuários em software.
Um processo é definido quando pode ser repetido. Deve ser documentado de
forma a detalhar: o produto (o que é feito), os passos (quando), os agentes
(quem faz), os insumos (o que usa) e os resultados (o que produz). Os
processos podem ser definidos por seu maior ou menor detalhamento e os seus
passos podem ter ordenação apenas parcial, o que permite a concomitância
entre alguns passos. Um conjunto de passos pode ser definido como um
sub-processo (Paula, 2001).
Com a crescente disseminação das práticas da
Gestão da Qualidade Total
nos
EUA na década de 1980, iniciou-se um movimento por parte do governo
americano, notadamente do departamento de defesa, para introduzir esses
conceitos na gestão de software. Foi quando surgiram alguns modelos, já
citados na introdução, para a melhoria do PDS. Destacam-se o Capability
Maturity Model Integration for software (SW-CMM) e o CMMI
- Capability Maturity Model Integration.
O CMMI -
Capability Maturity Model
Integration
É importante ressaltar que o Capability Maturity Model Integration
não estabelece normas e ações específicas a serem implantadas no PDS, apenas
determina as boas práticas que devem ser adotadas para se alcançar um
determinado nível de maturidade. Cabe à organização desenvolver a sua
sistemática de implantação e uso das práticas prescritas no Capability
Maturity Model Integration de acordo com as suas características e conforme
o tipo de software que desenvolve. Ou seja, a maneira como as atividades são
realizadas no PDS da organização pode ser única e específica, desde que
contemple as práticas do Capability Maturity Model Integration.
Segundo o documento de especificação do modelo Capability Maturity Model
Integration, uma área de processo (PA) é “um grupo de
práticas relacionadas em uma área que, quando implementadas coletivamente,
satisfazem um conjunto de objetivos considerados importantes para
aperfeiçoar essa área”. No total são 22 áreas de processos no modelo
Capability Maturity Model Integration. Uma área de processo é formada pelos
componentes da Figura 1:
Área de processo e seus componentes
Fonte: CMMI-DEV Version 1.2 (2006)
Como pode-se ver na Figura 1, o modelo Capability Maturity Model Integration
é formado por componentes de três categorias:
Requeridos: descrevem o que uma organização tem que realizar para satisfazer uma área de processo. Esta realização tem que ser visivelmente implementada nos processos da organização.
Esperados: descrevem o que uma organização pode implementar para realizar um componente requerido. Eles guiam aqueles que implementam melhorias ou fazem avaliações.
Informativos: provêem detalhes que ajudam as organizações a começarem a pensar sobre como abordar os componentes requeridos e esperados.
Abaixo são definidos os componentes principais do modelo, vistos também na Figura 1:
Objetivos Específicos: um objetivo específico descreve as características únicas que têm que estar presentes para satisfazer a área de processo (PA). É um componente requerido do modelo e é usado em avaliações para ajudar a determinar se uma PA está satisfeita.
Objetivos Genéricos: são chamados “genéricos” porque a mesma declaração de objetivo se aplica a múltiplas áreas de processos. Um objetivo genérico descreve as características que têm que estar presentes para institucionalizar os processos que implementam a área de processo (PA). É um componente requerido no modelo e é também usado em avaliações para determinar se uma PA está satisfeita.
Práticas Específicas: descrevem as atividades que são esperadas para resultar no cumprimento de objetivos específicos de uma área de processo (PA). É um componente esperado do modelo.
Práticas Genéricas: são chamadas “genéricas” porque as mesmas práticas são aplicáveis a múltiplas áreas de processos. Uma prática genérica é a descrição de uma atividade que é considerada importante para alcançar o objetivo genérico associado e é um componente esperado do modelo.
O Capability Maturity Model Integration possui níveis, que têm o objetivo de
descrever um caminho evolutivo recomendado para uma organização que queira
aperfeiçoar os processos que utiliza para desenvolver e manter seus produtos
e serviços. Há duas representações do modelo, sendo que cada uma delas
aborda os níveis de uma maneira particular: representação contínua e
representação por estágio.
No caso da representação por estágio é utilizado o termo “nível de
maturidade”. Este nível é a melhoria dos processos da organização como um
todo, visto que cada nível depende obrigatoriamente da melhoria em
determinadas áreas de processos. São 5 níveis: inicial, gerenciado,
definido, quantitativamente gerenciado, otimizado.
Neste artigo o interesse está especificamente no nível 2, o nível
“gerenciado”, onde os projetos da organização têm processos planejados e
executados de acordo com uma política; os projetos contratam pessoas
habilitadas e que tem recursos adequados para produzir artefatos
controlados; envolvem as pessoas relevantes; são monitorados, controlados e
revisados; e são avaliados pela aderência com as descrições de seus
processos. Para se atingir este nível de maturidade, as
PAs REQM, PP, PMC, SAM, MA, PPQA e CM devem estar satisfeitas, o
que significa que todos os objetivos específicos de cada uma delas foram
cumpridos, a partir das práticas específicas de cada uma delas ou de
práticas alternativas aceitáveis. Além disso, os objetivos genéricos do
nível 2 devem ter sido cumpridos através das práticas genéricas do nível 2
ou de práticas alternativas aceitáveis, quando aplicáveis a cada uma das
áreas de processos.
Gestão da Informação e do Conhecimento (GIC)
A partir da década de 1980, com a adoção do PRA/1980
nos EUA pelo Federal Paperwork Comission, marco reconhecido por vários
autores como origem do conceito de gestão de recursos informacionais,
o estudo da informação como um recurso cujo ciclo de vida pode ser
gerenciado de forma integrada às decisões estratégicas das organizações vem
despertando o interesse.
A terminologia utilizada para gestão de recursos informacionais varia entre
os autores da área. Enquanto alguns utilizam o termo gestão da informação
como sinônimo de gestão de recursos informacionais, outros distinguem os
dois termos e alguns ainda utilizam-nos alternadamente se referindo ao mesmo
conceito. De acordo com Bergeron (1996), contudo, tesauros como o
ABI Controlled Vocabulary e
EIIC Descriptors
usam o termo gestão da informação
para se referirem a gestão de recursos informacionais, sugerindo não haver
diferenças entre os dois termos.
gestão de recursos informacionais ou gestão da informação, e mais
recentemente a Gestão do Conhecimento (GC), são consideradas decisivas para
as organizações em resposta às tendências econômicas e sociais, orientadas
pela transição de uma sociedade industrial para uma sociedade de informação
que, segundo Barbosa (2003), resulta em mudança de foco dos recursos
econômicos convencionais (terra, trabalho e capital), para a ênfase na
informação.
A gestão da informação é importante para a sobrevivência das organizações,
as quais deparam-se com ambientes cada vez mais complexos. McGee & Prusak
(1994) destacam que em uma economia onde a informação tem papel importante,
a concorrência entre as organizações é fortemente influenciada por sua
capacidade de adquirir, tratar, interpretar e utilizar a informação de forma
eficaz. Nesse cenário, informações históricas e atuais, internas ou
externas, com qualidade, precisão e relevância tornam-se um diferencial para
o sucesso de organizações frente a clientes cada vez mais exigentes.
A gestão da informação no contexto do Processo de Desenvolvimento de
Software
Existem inúmeras razões para se relacionar a Gestão da Informação e do
Conhecimento (GIC) e Processo de Desenvolvimento de Software PDS, de forma a
favorecer o compartilhamento do conhecimento. Natali (2003) diz que a Gestão
do Conhecimento é reconhecida como uma fonte de vantagem competitiva
para organizações de desenvolvimento de software. A Gestão do Conhecimento
apresenta-se como uma forma de apoiar os desenvolvedores, de modo que esses
realizem suas atividades melhor e mais rapidamente, aproveitando
experiências anteriores.
Lindvall (2001) apresenta alguns benefícios da institucionalização de
programas de Gestão do Conhecimento nesse contexto:
(1) reutilização eficiente de experiências documentadas;
(2) facilidade de encontrar soluções para problemas dentro da organização;
(3) identificação e armazenamento de experiências de valor; e
(4) facilidade de propor medidas para melhorar a execução de processos e aumentar a qualidade de produtos de software.
Segundo Borges (2001) a Gestão da Informação e do Conhecimento pode oferecer
meios de apoiar a melhoria contínua do Processo de Desenvolvimento de
Software, assim como permitir o aprendizado da organização como um todo.
Parreiras (2004) vai além, dizendo que o Processo de Desenvolvimento de
Software está intimamente ligado à Gestão da Informação e do Conhecimento,
uma vez que por meio desta pode-se mapear, organizar, tratar e disseminar
adequadamente o conhecimento. São processos inter-dependentes, isto é,
necessitam um do outro para gerar melhores resultados. Através de processos
adequados de desenvolvimento de softwares, é possível proporcionar a
melhoria na Gestão do Conhecimento e esta realimentar a melhoria nos
processos.
Segundo Basili (2001), através da estruturação e representação explícita de
conhecimento sobre processos de software, é possível definir programas de
treinamento eficientes que podem aumentar a produtividade dos membros da
organização. Já Landes (1999) salienta que soluções de Gestão do
Conhecimento apóiam de forma eficiente atividades de membros da
organização com pouca experiência em uma área ou domínio específico.
O modelo Ecologia da Informação
O modelo de gestão da informação escolhido para ser usado neste trabalho foi
aquele descrito no livro “Ecologia da Informação”, de
Davenport (2002). Este
é um dos modelos mais referenciados na literatura de Ciência da Informação,
além de ser um modelo bastante genérico, podendo ser aplicado a quase que
qualquer organização ou contexto. Isso porque a informação está presente em
tudo, nos mais variados contextos, atividades e processos. O modelo tem a
missão de propor uma visão de gestão da informação que possa ser útil de alguma forma em todas essas situações.
As relações entre a certificação de processos de desenvolvimento de
software e a gestão da informação serão estabelecidas à luz desse modelo.
No primeiro capítulo do livro, Informação e seus dissabores: uma introdução,
Davenport comenta sobre como o gerenciamento da informação tem sido
abordado nas organizações. As pessoas em quase a totalidade dos casos
colocam a tecnologia em primeiro plano, ao invés da informação: “Nosso
fascínio pela tecnologia nos fez esquecer o objetivo principal da
informação: informar.”
A maioria das pessoas de Tecnologia da Informação (TI)
não tem paciência com os usuários finais e procuram resolver com tecnologia
problemas informacionais que muitas vezes têm origem na ignorância de como
as pessoas e a informação se relacionam e não de falhas de software.
A base do modelo de Davenport, a Ecologia da Informação, é justamente o
oposto à essa “engenharia de máquina”: “Em vez de se concentrar na
tecnologia, a ecologia da informação baseia-se na maneira como as pessoas
criam, distribuem, compreendem e usam a informação”.
É importante ainda reescrever aqui a justificativa do nome Ecologia da
Informação:
“Considero a ecologia, a ciência de compreender e administrar todos os ambientes, apenas uma metáfora. (...) Em vez de modelar um ambiente informacional em máquinas e edifícios, proponho uma abordagem mais harmoniosa com as coisas vivas. Quando começamos a pensar nas muitas relações entrecruzadas de pessoas, processos, estruturas de apoio e outros elementos do ambiente informacional de uma empresa, obtemos um padrão melhor para administrar a complexidade e a variedade do uso atual da informação. Também poderíamos descrever a ecologia da informação como administração holística da informação ou administração informacional centrada no ser humano.” Davenport (2002) pág.21
Mas é a figura 2 que resume o modelo ecológico para gerenciamento da
informação de Davenport:
Modelo ecológico para o gerenciamento da informação
Fonte: Ecologia da Informação, pág. 51
Nessa figura vemos os três ambientes envolvidos: informacional,
organizacional e ex-terno, sendo o informacional o núcleo da abordagem
ecológica, com seis componentes: estratégia, processo, arquitetura,
política, cultura/comportamento e equipe. Os outros dois componentes são os
outros dois ambientes. As relações entre a certificação de processos de
desenvolvimento de software e o modelo Ecologia da Informação serão
estabelecidas para cada um desses componentes.
Procedimentos metodológicos
Este trabalho contempla aspectos de pesquisa descritiva, visto que objetiva
descrever detalhes dos processos de desenvolvimento de software e
estabelecer relações entre eles e a gestão da informação. Do ponto de vista
dos meios, a pesquisa se caracteriza como sendo de natureza qualitativa e
quantitativa.
A maioria das análises e relações que foram estabelecidas foram qualitativas, mas também houve análises quantitativas. Foi adotada uma abordagem de estudo de caso, conforme orientação de Yin (2005). A escolha pelo estudo de caso se deu em função da necessidade de conhecer, de forma mais detalhada, a maneira que cada uma das práticas do nível 2 do Capability Maturity Model Integration são realizadas, e como podem estar relacionadas com a gestão da informação.
De acordo com Gil (1994), um estudo de caso é um “estudo profundo e exaustivo de um ou poucos objetos, de maneira a permitir conhecimento amplo e detalhado sobre o mesmo”. Chizzotti (2005) complementa dizendo que tais estudos correspondem a pesquisas que coletam e registram dados de um caso particular ou de vários casos a fim de organizar um relatório ordenado e crítico de uma experiência. Para Yin (2005), um caso pode ser uma organização, pessoa, processos ou um projeto específico. Nesta pesquisa, o caso é uma organização que tem processos de desenvolvimento de software no nível de maturidade 3 do Capability Maturity Model Integration.
A empresa escolhida para o estudo de caso foi a
MSA Infor , por possuir a certificação Capability Maturity
Model Integration, ter sede em Belo Horizonte, e pelo fato do
pesquisador ter conseguido permissão para fazer a pesquisa nesta empresa.
Esta empresa possui atualmente Capability Maturity Model Integration
nível 3, mas foi estudado apenas o nível 2, porque acredita-se que se a
gestão da in-formação realmente ajuda e é necessária na certificação do
nível 2, certamente ajudará nos níveis superiores, e o tempo para se estudar
todo o nível 3 seria bem maior.
Nesta organização foram realizadas entrevistas, questionários foram
aplicados e uma análise documental foi feita. Os questionários foram
justamente os testes propostos por Davenport para se ter a percepção das
pessoas sobre o quão presente está a gestão da informação nesse contexto, à
luz de seu modelo. As quatro entrevistas que foram realizadas ( roteiro
é apresentado no anexo A [1] ) e a análise
documental serviram para se conseguir estabelecer relações existentes entre
a gestão da informação e o contexto da certificação de processos de
desenvolvimento de software, também à luz do modelo Ecologia da Informação.
Avaliação dos Resultados - Estrutura organizacional
A empresa MSA possui em sua estrutura uma equipe conhecida como Gestão da Qualidade
(GDQ). Esta equipe é responsável por criar, divulgar, atualizar e monitorar
todas as questões relativas ao processo de desenvolvimento e manutenção de
software da empresa, chamado “Processo do Ciclo de Vida do Produto de
Software”. Ou seja, a responsabilidade da eficiência do processo, da
qualidade dos produtos e da aderência do processo ao Capability Maturity
Model Integration é desta equipe de Gestão da Qualidade.
Há ainda a equipe de Coordenação de Informática Interna, responsável por
toda a infra-estrutura da empresa: computadores, rede, servidores e backup.
Já os serviços específicos de gestão de configuração, testes e controle de
distribuição dos produtos são realizados pela equipe de Suporte Técnico.
Finalmente, tem-se as equipes de cada projeto ou produto, compostas por um
gerente de projeto, analistas de sistemas, programadores, analistas de
testes etc.
Mas é claro que a estrutura organizacional da empresa MSA é bem maior do que isso e
com inúmeras áreas não ligadas diretamente ao desenvolvimento de software. É
por esta razão que estas outras áreas não estão descritas aqui. Mas não
existe uma equipe de informação na empresa, apesar de que no contexto de
desenvolvimento de software a equipe de Gestão da Qualidade parece cumprir
este papel.
O interessante nesta estrutura é que ela já existia na empresa MSA antes da
certificação do Capability Maturity Model Integration - CMMI . O que foi
feito foi adaptar o que cada uma dessas equipes faz e a maneira como faz,
quais documentos gera e com quais informações. Ou seja, cada área de
processo do CMMI não foi
implementada separadamente, cada uma com uma equipe. Ao ler o modelo
CMMI , muitas vezes as pessoas podem ser
levadas a pensar que é dessa forma que deve ser feito, mas esse caso mostrou
que não. Muito pelo contrário: o Capability Maturity Model Integration
apenas exige o cumprimento das práticas de cada área de processo,
independente da estrutura organizacional utilizada.
Além disso, faz sentido não separar totalmente as equipes. Algumas
atividades podem ser realizadas por uma única pessoa, com determinada função
na empresa, e isso pode representar várias práticas do Capability Maturity
Model Integration. Vendo o modelo dessa forma, percebemos que não é tão
complicado implementá-lo quanto pode parecer à primeira vista. Um exemplo
claro disso é que várias práticas das áreas de processo, PP, PMC e REQM
ficam sob a responsabilidade do gerente de projeto.
Outro fato que chamou a atenção nesta estrutura é que apenas a equipe de
Gestão da Qualidade conhece a fundo todo o modelo Capability Maturity Model
Integration CMMI : suas áreas de processos, objetivos genéricos e específicos,
práticas genéricas e específicas etc. Ela então encaixa no seu processo as
atividades necessárias para se realizar as práticas do CMMI , e as demais equipes normalmente apenas realizam essas
atividades conforme especificado no processo. Portanto há uma certa
abstração, de tal forma que somente a equipe de Gestão da Qualidade
realmente tem a preocupação em como atender ao modelo.
As demais equipes, apesar de terem alguns membros que definem as atividades
do processo juntamente com a Gestão da Qualidade, têm a preocupação apenas
de realizar essas atividades do processo da maneira que foram especificadas,
mas não necessariamente precisam saber qual ou quais práticas do Capability
Maturity Model Integration estão realizando. Mesmo esses membros que
auxiliam na definição das atividades não precisam ter o conhecimento
profundo do CMMI , visto que essa adequação
ao CMMI fica sob a responsabilidade da equipe de Gestão da Qualidade. A
idéia da participação desses membros na definição das atividades é
justamente a de que irão seguir mais facilmente um processo que ajudaram a
construir. Mas nem sempre isso é verdade. Em alguns casos pessoas de fora da
equipe de Gestão da Qualidade também precisam ter estas informações, visto
que são feitas entrevistas com elas durante a avaliação do Capability
Maturity Model Integration. Isso demanda treinamento.
Um último detalhe importante a ser observado com relação à empresa empresa MSA é que ela não implementou a área de processo
SAM do Capability Maturity Model Integration.
Como a empresa empresa MSA não faz sub-contratações em seus projetos, ela de fato não é
obrigada a implementar esta área de processo, mesmo porque nem faria
sentido.
Análise Documental
A partir da análise documental (e também das ferramentas utilizadas pela
organização), tem-se os seguintes resultados:
A equipe de Gestão da Qualidade é a única que realmente conhece a fundo todo o modelo Capability Maturity Model Integration. O que é feito é que são definidas as atividades do Processo de Desenvolvimento de Software de tal forma a atender às práticas do CMMI, e as demais pessoas apenas executam essas atividades, inclusive tendo conhecimento profundo apenas de suas próprias atividades.
Cada área de processo do modelo Capability Maturity Model Integration não foi implementada separadamente. A estrutura de equipes da empresa MSA já existia e foi apenas adaptada, de tal forma que um único cargo ou função possa executar atividades de mais de uma área de processo.
Cada cargo ou função participa de práticas de pelo menos 3 áreas de processos. Daí a importância de se estar tudo muito bem definido e gerenciado.
A maioria dos documentos padronizados do Processo de Desenvolvimento de Software também estão relacionados com práticas de pelo menos 3 áreas de processos. Ou seja, mais uma vez a gerência desses documentos é fundamental, dado o número de pessoas que os acessam e modificam.
A grande maioria das evidências utilizadas na avaliação do Capability Maturity Model Integration estão em documentos padronizados do Processo de Desenvolvimento de Software, sendo 86 no total. As demais ou estão em sistemas da empresa (50 no total) ou são tipos específicos de evidências (15 no total). Ou seja, a gestão de documentos é também fundamental nesse contexto.
Backup e controle de versão são amplamente utilizados.
Modernas ferramentas são usadas de tal forma a atualizar e disseminar o Processo de Desenvolvimento de Software na organização, como o Rational Method Composer (RMC), por exemplo, uma ferramenta que foi utilizada para se publicar o processo de forma dinâmica na intranet, facilitando o acesso e as atualizações e manutenções no processo.
Para gerenciar as informações dos projetos são utilizadas várias ferramentas específicas como o Microsoft® Project Server, o Scarab e o Sistema de Administração de Projetos (SIAP), além do Docman que é um sistema de Gestão Eletrônica de Documentos (GED) desenvolvido pela própria empresa MSA.
Percepção das pessoas da gestão da informação nesse contexto
Ao serem questionados se durante essa adequação do processo e conseqüente
certificação Capability Maturity Model Integration eles ouviram alguém usar
especificamente o termo “Gestão da Informação”, os 4 entrevistados foram
unânimes em dizer que não: ou simplesmente disseram que não, ou não
lembravam ou tinham quase certeza que não.
No entanto, logo na seqüência foram questionados se mesmo sem utilizar o
termo, houve iniciativas claras de gestão da informação durante a adequação
do processo, de tal forma a organizar as informações e facilitar o seu
acesso. Todos responderam que sim, citando as fer-ramentas que são
utilizadas para isso e enfatizando a importância disso.
A entrevistada 1 disse que “mesmo não tendo usado esse termo, sem dúvida é
uma preocupação da nossa área de Gestão da Qualidade gerir todas essas
informações relacionadas ao processo e às auditorias”. O entrevistado 3
comentou que “particularmente por conhecer um pouco de gestão da informação,
eu podia perceber que as coisas estavam sendo feitas para se ter também a
gestão da informação. (...) Informações cruciais para a empresa como missão,
objetivos, etc são inclusive espalhadas em quadros pelos corredores”.
Um outro detalhe importante nestas respostas foi o que colocou a
entrevistada 4: “muitas vezes fazemos as coisas sem saber o nome”. Isso
realmente é o que mais parece fazer sentido. A organização parece se
preocupar tanto em estudar o Capability Maturity Model Integration, gerência
de projetos e seus processos que não dá a devida atenção à gestão da
informação, mas ela acaba acontecen-do por ser importantíssima nesse
contexto. Só que acontece de uma maneira informal, ou seja, sem ter todas as
definições em um só local, sem ter um documento com definições da gestão da
informação especificamente. Mas se todos os detalhes forem coletados pode-se
identificar várias características, por exemplo, do modelo Ecologia da
Informação nesse contexto; o que foi feito na acima.
Mas para coletar a percepção das pessoas em relação à gestão da informação,
à luz do modelo Ecologia da Informação, avaliamos as respostas dadas pelos 4
respondentes aos questionários retirados do próprio modelo Ecologia da
Informação. Estes questionários são compostos de vários conjuntos de
afirmativas, cada um deles relativo a determinado componente do modelo. Cada
um dos quatro respondentes respondeu a todas as afirmativas, mas foram
consideradas como respostas positivas (resposta “sim” à afirmativa) apenas
as afirmativas em que pelo menos três dos respondentes responderam desta
forma. A partir desse número de afirmativas com respostas positivas e do
número total de afirmativas por componente, foi obtido um percentual de
aderência a cada um dos componentes do modelo. Foi obtido também um
percentual para o modelo como um todo, calculado através da média aritmética
dos percentuais de todos os componentes. Estes resultados são apresentados
na tabela 1.
Tabela 1 - Percentuais de aderência da organização aos componentes do modelo
Ecologia da Informação
Pode-se perceber que o resultado do modelo como um todo foi de 81,67% de
aderência com o modelo Ecologia da Informação. Um resultado alto, que mostra
que a organização tem gestão da informação, mas não de forma explícita. É
interessante observar ainda que os respondentes foram orientados a responder
“não” caso não entendessem a afirmativa. Ou seja, foi um teste rigoroso,
visto que só responderam “sim” se entenderam o que está na afirmativa e se
conseguiram fazer uma correspondência entre o conteúdo da afirmativa e algo
que é feito na empresa MSA.
Relações entre cada componente do modelo Ecologia da Informação e a
certificação de processos de software neste estudo de caso
Estratégia da Informação
Apesar de não possuir um documento, por exemplo, que defina exclusivamente a
estratégia da informação da empresa, a MSA nitidamente possui uma
estratégia, com pelo menos 3 dos enfoques citados no modelo Ecologia da
Informação:
Conteúdo da informação: há a seleção de informações que estarão disponíveis na intranet e no Docman, ou seja, as informações que são vitais para a empresa, na maioria informações ligadas ao desenvolvimento de software;
Processos de informação: pode-se considerar que dentro do processo de desenvolvimento de software também estão definidos os processos informacionais desse contexto: quem faz cada atividade, quem produz cada documento padronizado, quem recebe cada um desses documentos como entrada para outras atividades etc;
Novos mercados de informação: é claro que a empresa MSA investiu na certificação de seus processos de desenvolvimento de software principalmente para que seus projetos fossem mais bem gerenciados, seus produtos tivessem maior qualidade e ganhassem mais mercado na comercialização desses produtos e serviços relacionados, ou mesmo porque através de uma análise do setor de negócios tenha mostrado que seus concorrentes já eram certificados. No entanto, um outro mercado se abre: a consultoria em Processo de Desenvolvimento de Software e Capability Maturity Model Integration. Nada impede que a empresa MSA comece a explorar este mercado.
Política da Informação
Segundo o modelo Ecologia da Informação qualquer política de informação que
seja implantada irá gerar conflitos internos, ciúme pela divisão de
recursos, etc. No contexto da certificação de processos de desenvolvimento
de software (CPDS) isso não é diferente. As adaptações ao Processo de
Desenvolvimento de Software podem influenciar no trabalho de todos os
envolvidos, mudando inclusive sua rotina diária. Colaboradores podem perder
o controle e até mesmo o acesso a determinadas informações devido ao
processo.
Pode haver inclusive resistência a essas mudanças no Processo de
Desenvolvimento de Software, sendo que isso foi citado nas entrevistas. O
entrevistado 3 disse que foram necessárias várias reuniões e apresentações
para convencer as pessoas da importância disso. Ou seja, foram sim travadas
batalhas políticas dentro da organização, que envolviam mudanças
informacionais dentro das mudanças no Processo de Desenvolvimento de
Software. Várias informações do projeto que antes poderiam não estar
totalmente padronizadas e estar da forma que o gerente bem quisesse agora
teriam que estar seguindo o padrão.
Com relação ao modelo adotado para se “governar a informação” pode-se dizer
que o que mais se enquadra ao caso é o federalismo, visto que o controle das
informações acaba sendo por projeto, cada um com uma equipe diferente, etc.
Cultura e Comportamento em Relação à Informação
Sem dúvida que a cultura e o comportamento informacional são alterados com
Certificação de processos de desenvolvimento de software, visto que para se atender às práticas do
Capability Maturity Model
Integration, por exemplo, é necessário alterar como as pessoas realizam suas
atividades, os sistemas que utilizam, as informações com as quais lidam, e
até a maneira como lidam com estas informações. Na empresa MSA, o entrevistado 3
disse inclusive que “foi um trabalho de convencer as pessoas a mudarem a
maneira como trabalhavam e lidavam com as informações”.
O maior exemplo disso é o processo que passou a ser consultado pela intranet ao invés de estar impresso. Algumas pessoas lutaram contra essa mudança, e provavelmente contra muitas outras. Foi possível identificar neste contexto na empresa MSA as três espécies fundamentais de comportamento informacional que devem ser estimuladas para melhorar o ambiente informacional, segundo o modelo Ecologia da Informação:
Compartilhamento de informações: no modelo há uma diferenciação clara entre relatar e compartilhar informações. O relato de informações acontece devido ao próprio Capability Maturity Model Integration, que define quais informações devem ser passadas para a alta gerência, por exemplo. Mas o compartilhamento de informações foi identificado na empresa MSA no contexto da Certificação de processos de desenvolvimento de software. Durante a certificação as pessoas tinham tempo para estudar e faziam juntas estudos dirigidos para aprender de forma mais rápida e interativa. Além disso, mesmo após a certificação, há um banco de lições aprendidas, que todos colaboram para que erros que já foram cometidos por algum colaborador não se repitam na organização.
Administração da sobrecarga de informações: se o modelo Capability Maturity Model Integration fosse inteiramente apresentado, ou mesmo parcialmente, a todas as pessoas envolvidas com o desenvolvimento de software na empresa MSA, seria um caos informacional, visto que o modelo é muito extenso e complexo. A empresa MSA teve essa preocupação com essa sobrecarga de informações, deixando a adequação ao modelo sob a responsabilidade da equipe de Gestão da Qualidade, especializada em definir e manter o processo para atender ao Capability Maturity Model Integration, com a participação de apenas alguns membros das outras equipes.
Redução de significados múltiplos: existe esta preocupação na definição do processo da empresa MSA. Atualmente é mais fácil fazer qualquer manutenção, visto que ele está em formato eletrônico, gerenciado pela ferramenta RMC. Ao mudar o nome de um documento ou de um cargo ou função, por exemplo, ele já é atualizado automaticamente em todo o processo.
Equipe Especializada em Informação
A empresa MSA é uma grande organização e possivelmente possui várias equipes,
inclusive fora do contexto de desenvolvimento de software, que podem ser
consideradas equipes especializadas em informação. Mas especificamente
nesse contexto, na empresa MSA, podemos considerar a equipe de Gestão da Qualidade
seja a equipe especializada em informação, especializada nas informações
relativas ao Processo de Desenvolvimento de Software e à Certificação de
processos de desenvolvimento de software.
Apesar de ser composta por pessoas com formação em ciência da computação e
sistemas de informação, esta equipe tem cumprido muito bem o seu papel na
organização. Abaixo uma breve análise de como realizam cada uma das quatro
tarefas básicas sugeridas no modelo Ecologia da Informação para se
contemplar os atributos que determinam o valor da informação na organização:
Condensação: a informação é transmitida de forma curta e eficaz. Apesar do Processo de Desenvolvimento de Software todo ser enorme, o colaborador consegue achar rapidamente a atividade de seu interesse, que já resume tudo o que ele precisa saber a respeito, incluindo referências diretas e indiretas a cargos ou funções, documentos, sistemas e outras atividades.
Contextualização: foi fundamental no período de adaptação do processo. Além de apresentar o novo processo, foi necessário mostrar como aquilo se relacionava com o que era feito antes, fazendo-se uma comparação e mostrando os benefícios.
Apresentação: foi uma preocupação da equipe de Gestão da Qualidade, que deu vários treinamentos para vários públicos diferentes: gerentes de projeto, analistas de sistemas, programadores, etc. E a maneira de apresentar estas informações muda de acordo com o público.
Meio: a equipe de Gestão da Qualidade usa vários meios diferentes para comunicar as informações desse contexto. Vários sistemas e ferramentas são utilizados na organização, além de e-mails e reuniões presenciais. Cada um desses meios é utilizado para um propósito específico, adequado a cada tipo situação.
Processos de Gerenciamento da Informação
Na empresa MSA não houve a preocupação em definir explicitamente um processo de
gerencia-mento da informação, mas ao examinar tudo o que foi feito pode-se
identificar os quatro passos do processo genérico de gerenciamento da
informação proposto no modelo Ecologia da Informação.
O primeiro passo, determinação das exigências da informação, foi executado
ao examinarem o que já tinham em seu Processo de Desenvolvimento de Software
e o que precisavam ter para atender a todas as práticas do Capability
Maturity Model Integration.
O segundo passo, obtenção de informações, foi feito através da busca de
informações do próprio Capability Maturity Model Integration e de outras
fontes, como por exemplo informações a respeito de gerência de projetos,
gerência de configuração, auditorias, de tal forma a se construir o Processo
de Desenvolvimento de Software da empresa MSA, estruturá-lo e formatá-lo de acordo
também com os interesses da organização.
O terceiro passo, a distribuição, realmente combinou as duas estratégias
para isso definidas no modelo Ecologia da Informação, como já era esperado.
Em um primeiro momento a distribuição das informações foi feita de forma
ativa pela equipe de Gestão da Qualidade, inclusive treinando cada equipe de
acordo com suas atividades na organização. Em um segundo momento, já com as
equipes treinadas nas novas atividades, os colaboradores já eram capazes de
buscar, na maioria dos casos, as informações das quais necessitavam, nos
vários documentos e sistemas de informação da empresa. Inclusive os quatro
entrevistados responderam que eles e suas equipes dificilmente precisam
perguntar onde está determinada informação pra alguém, ou seja, são
realmente capazes de encontrá-las sozinhos.
O quarto e último passo, o uso da informação, certamente não é ignorado na
empresa MSA. Mesmo porque se as pessoas não usarem estas informações elas não
estarão seguindo o Processo de Desenvolvimento de Software da empresa MSA, e
conseqüentemente não estarão aderentes ao modelo Capability Maturity Model
Integration. Para verificar esta aderência, a equipe de Gestão da Qualidade
faz auditorias de qualidade periodicamente em todos os projetos. Isso
garante o uso das informações atualizadas do Processo de Desenvolvimento de
Software, tais como: últimas versões dos templates dos documentos
padronizados, como realizar as atividades envolvidas, como realizá-las, quem
é o responsável, etc.
Arquitetura da Informação
O principal ponto defendido por Davenport no modelo Ecologia da Informação é
que o objetivo de uma arquitetura da informação é mudar a maneira que os
funcionários lidam com as informações. Isso certamente aconteceu na empresa MSA, o
que já explicado anteriormente.
Além disso, toda esta adequação do Processo de Desenvolvimento de Software
ao Capability Maturity Model Integration não foi feita apenas pela equipe de
Gestão da Qualidade e imposta às demais equipes. Durante as adequações todas
as pessoas puderam opinar em como adequar suas atividades. E mesmo após a
certificação, as pessoas podem dar sugestões de alterações no processo, e
inclusive discutir estas alterações com a equipe de Gestão da Qualidade até
que um consenso seja alcançado. Esse consenso atende ao Capability Maturity
Model Integration, aos conhecimentos específicos e ao modo de trabalhar das
pessoas que executam as atividades.
Outro fato interessante é que se considerarmos a empresa MSA como um todo, e não
apenas as equipes ligadas diretamente ao desenvolvimento de software,
veremos que há uma arquitetura de informações geral, de informações comuns.
Mas a parte relativa ao Processo de Desenvolvimento de Software ficou a
cargo da equipe de Gestão da Qualidade, com uma atenção maior e uma
preocupação de estar tudo muito bem definido. Ou seja, não foi tudo pensado
de uma vez só, como também é sugerido no modelo Ecologia da Informação.
Conectando a Empresa: A Informação e a Organização
Situação dos Negócios
De fato uma melhora na situação informacional da empresa leva a uma melhora
na situação administrativa como um todo. No caso, o Capability Maturity
Model Integration foca principalmente em uma das estra-tégias de negócios
propostas no modelo Ecologia da Informação, a excelência operacional, na
qual há a redução dos custos e o aumento da qualidade dos produtos.
Investimento em tecnologia
Como a empresa MSA é uma empresa de tecnologia como atividade fim, é óbvio que
investe bastante em tecnologia também em sua infra-estrutura. Mas é
importante observar que todas as ferramentas utilizadas têm um propósito bem
claro e definido, tendo informações e processos por trás de cada uma delas.
Apesar de que algumas coisas ainda podem ser melhoradas, como uma melhor
integração das ferramentas, detalhe este citado pelo entrevistado número
dois.
Outra característica que está de acordo com o modelo Ecologia da Informação
é a do foco estar na informação e não na tecnologia. Um exemplo disso é o
que o entrevistado três disse a respeito de uma nova ferramenta que estão
procurando para analisar as métricas da organização automaticamente e já
exibir os resultados de uma forma palpável. Ou seja, eles já definiram todos
os procedimentos para isso e inclusive já o fazem, de forma manual. E querem
agora apenas automatizá-lo, ao invés de achar que a tecnologia pode resolver
tudo.
Disposição do espaço físico
A disposição do espaço físico na empresa MSA pareceu bastante adequada, onde os
membros de uma mesma equipe ficam próximos. Isto facilita bastante a
comunicação entre eles, sendo que certamente esta é a comunicação mais comum
dentro da organização.
Informação e o Ambiente Externo
Mercados de negócios
É fundamental que os responsáveis por implantar um modelo como o Capability
Maturity Model Integration numa or-ganização como a empresa MSA, por exemplo,
estejam certos de que estão no mercado correto, e que essa implantação
realmente tenha impactos positivos nos negócios da empresa, mesmo que seja a
longo prazo, como redução de custos e aumento da qualidade dos produtos.
Mercados de tecnologias
A empresa MSA está sempre avaliando novas tecnologias externas que possam melhorar
seus processos internos, incluindo o Processo de Desenvolvimento de
Software. Um exemplo disso foi o já citado uso da ferramenta
RMC - Rational Method Composer para a
publicação na web do Processo de Desenvolvimento de Software da empresa MSA, que se
mostrou extremamente eficiente e com certeza colaborou e muito para a
certificação do Capability Maturity Model Integration ser conseguida em
menos tempo.
Mas isso só foi possível porque a equipe de Gestão da Qualidade estava
atenta às essas novas tecnologias externas que estavam disponíveis, e
conseguiu enxergar nelas uma oportunidade. Foi feita uma avaliação e com o
resultado positivo a ferramenta foi implantada na organização. Esse
procedimento é exatamente o que recomenda o modelo Ecologia da Informação a
respeito desta questão.
Mercados de informação
Além de melhorar a situação da empresa MSA no mercado de negócios, o Capability
Maturity Model Integration também fez com que esta organização pudesse
explorar mais os mercados de informação. Como adquiriu uma vasta experiência
na implantação de um Processo de Desenvolvimento de Software que atende às
práticas do Capability Maturity Model Integration, pode passar a prestar
consultorias neste contexto para outras empresas, de tal forma a colaborar
no processo de adaptação ao CMMI nestas organizações.
Considerações Finais
Como resultado geral da pesquisa tem-se a comprovação de que a gestão da
informação se apresenta como peça chave no contexto da Certificação de
processos de desenvolvimento de software. Ou seja,
analisando-se todos os resultados alcançados pela pesquisa, tem-se que a
gestão da informação, considerando-se o modelo Ecologia da Informação, está
fortemente presente neste contexto, tanto na percepção das pessoas quanto no
que foi levantado e analisado pelos autores.
Assim é interessante notar que, embora não se tenha pensado explicitamente sobre gestão da informação para se alcançar a Certificação de processos de desenvolvimento de software no modelo Capability Maturity Model Integration na empresa empresa MSA, ela esteve presente o tempo todo. Tal fato sugere que o período de adequação do Processo de Desenvolvimento de Software para a certificação no modelo Capability Maturity Model Integration poderia ter sido menor, se a gestão da informação tivesse sido explicitada, estudada e planejada desde o início do processo.
Espera-se que os resultados alcançados pela pesquisa descrita neste artigo
possam servir de ponto de partida para novos estudos interdisciplinares
envolvendo engenharia de software e gestão da informação: duas áreas que
ainda podem ser muito exploradas em conjunto. Espera-se também que esses
resultados possam ser utilizados como instrumentos operacionais de
orientação para as empresas brasileiras de software, a fim de que essas
ampliem a sua competitividade, conseguindo uma sólida certificação de seus
processos de desenvolvimento de software com o auxílio da gestão da
informação.
Notas:
[1] Anexo A – Roteiro das Entrevistas
1. Qual o seu cargo na organização?
2. Sobre qual ou quais área de processos do Capability Maturity Model
Integration você tem mais conhecimento?
3. Quais foram as principais mudanças nesta área de processo com a adequação
do processo ao modelo Capability Maturity Model Integration?
4. Em algum momento foi utilizado o termo "Gestão da Informação"?
5. Independentemente se foi usado o termo ou não, na sua opinião houve
iniciativas claras de gestão da informação durante a adequação do processo,
de tal forma a organizar as informações e facilitar o seu acesso? Quais?
6. Essas iniciativas foram idealizadas por você ou pela organização? E foram
úteis? Ou algumas foram descartadas depois de algum tempo?
7. Quais foram as principais dificuldades informacionais encontradas para
viabilizar essas mudanças? Ou seja, com as mudanças as pessoas passaram a
precisar de mais informações, e essas informações eram ou são difíceis de se
obter? Por quê?
8. Onde você consulta e/ou guarda as informações relevantes ao seu trabalho
na organização? (Ex.: intranet, repositórios de documentos com arquivos de
texto e planilhas, e-mails, arquivos na sua máquina, algum outro sistema
corporativo, algum sistema na sua máquina, etc).
9. Atualmente você e sua equipe conseguem encontrar na organização todas as
informações necessárias para a realização de suas atividades, ou às vezes é
necessário consultar alguém ou alguma equipe? Quem?
10. Tudo o que foi feito na adequação ao Capability Maturity Model
Integration foi documentado e guardado? Ou alguns conhecimentos e
aprendizados ficaram apenas na cabeça de algumas pessoas?