1. Introdução
Software se tornou um elemento indispensável para organizações dos mais diversos ramos de atuação. É também considerado um fator estratégico, pois possibilita uma série de diferenciais em termos de serviços e de produtos. Empresas e organizações voltadas para o desenvolvimento de Software investem cada vez mais em tecnologia e processos para obter um produto competitivo e de qualidade. Por esse motivo estas empresas estão adotando o conceito de Fábrica de Software que leva em conta os atributos de uma fábrica industrial no processo de desenvolvimento de Software. Assim como na fábrica industrial, o objetivo de uma Fábrica de Software é a geração de produtos requeridos pelos usuários ou clientes, com o mínimo de defeitos e com um preço competitivo, que forneça a margem necessária para os investimentos em manutenção e melhoria da fábrica (Fernandes E Teixeira, 2004).
Outro fator que identifica uma Fábrica de Software é a existência de conjuntos de processos e métodos bem desenvolvidos, que proporcionam maior produtividade. Desta forma os processos operacionais acabam ganhando mais autonomia em relação ao fator humano, evitando falhas de qualidade. Estes métodos são identificados no processo de desenvolvimento de software e podem estar presentes tanto em um produto novo como na alteração ou melhoria de um já existente.
Além do conceito de Fábrica de Software, com o aumento da escala e da complexidade dos sistemas de informação, a abordagem do ciclo de vida foi levada em conta no desenvolvimento de software. Essa abordagem gerou maior ênfase no desenvolvimento de sistemas de informações gerencias, ou seja, sistemas mais simples e que funcionavam de forma isolada foram descontinuados dando lugar a sistemas integrados aptos a atender toda a organização com capacidade de gerar informações de níveis gerencias e estratégicas. Muitos são os modelos de ciclo de vida de um software: cascata, espiral, prototipação evolutiva, prototipação incremental, desenvolvimento incremental, etc. Embora uns com mais ou menos capacidade, com vantagens e desvantagens, todos tem como característica descrever as etapas do processo de desenvolvimento de sistemas e as atividades a serem realizadas em cada etapa. Entre os modelos existem divergências no enfoque e na estratégia, pois cada modelo representa um processo a partir de uma perspectiva particular (Sommerville, 1995). Porém, segundo Sanches (2001), para se alcançar um diferencial competitivo muitos países inclusive o Brasil utilizam a norma internacional NBR ISO/IEC 12207 –Tecnologia da Informação - Processos de Ciclo de Vida de Software (ISO, 1995a) como referência. Ela estabelece uma estrutura comum para os processos de ciclo de vida e desenvolvimento, proporcionando às empresas um melhor entendimento dos componentes existentes na aquisição e fornecimento de software.
Segundo Pfleeger (2004) é possível dizer que processo de desenvolvimento de software também pode ser chamado de ciclo de vida do software, pois ele descreve a “vida” do produto desde a concepção até a implementação, entrega, utilização e manutenção. Ele determina as fases e o relacionamento entre elas com processos fundamentais que atendem a operação e manutenção dos produtos de software. Tanto as fases como o relacionamento representam diversas medições, detalhamento de como os processos devem ser executados, qual método deverá ser utilizado, descrição das atividades e seus relacionamentos, artefatos consumidos, ferramentas utilizadas entre outros. Assim, para Rocha et al (2001) independente de paradigma, área de aplicação, do tamanho do projeto e da complexidade, o processo de desenvolvimento de software possui três fases genéricas: a definição, o desenvolvimento e a manutenção. Neste trabalho será abordada a fase de definição que objetiva a montagem do escopo através dos requisitos formando a base de todo o processo de desenvolvimento de software. Essa fase é tão importante que se for mal executada pode comprometer todo o projeto. Na fase de definição ocorre a explicitação e estruturação dos requisitos. “Requisito é uma característica ou a descrição de algo que o sistema será capaz de realizar” (Pfleeger, 2004 p.111). Estes requisitos devem passar por algumas fases onde são reescritos, verificados e validados para que se garanta que a descrição corresponde ao que o cliente espera.
Os requisitos especificam o conjunto de funcionalidades que um software deve prover para satisfazer as necessidades de todos os envolvidos no projeto, as características de qualidade e as restrições a que devem estar sujeitas às funcionalidades (Sampaio, 2005). Assim, a engenharia de requisitos pode ser definida como a ciência e disciplina preocupada com a análise e documentação dos requisitos citados anteriormente, além de fornecer mecanismos apropriados para facilitar as atividades de análise, documentação e validação.
Tanto na criação quanto na implementação de melhorias em software, uma das tarefas mais importantes a ser executada é a extração dos requisitos principalmente porque em diversos momentos as necessidades dos clientes não são claras. Por isso é necessário habilidade e experiência de analistas e gerentes de projetos, para tratar e identificar a incompletude, ambiguidade ou em alguns casos até a contradição dos requisitos, possibilitando dessa forma uma compreensão completa do problema. Nesse sentido Leite (2001) diz que o processo de definição dos requisitos deve lidar com diferentes pontos de vista e usar uma combinação de métodos, ferramentas e equipes. Se a análise for feita de forma incorreta o resultado final será desastroso podendo levar ao desenvolvimento de um produto que não atenda aos objetivos para o qual foi planejado, gerando a necessidade de um novo ciclo de especificação, projeto, e codificação. A análise de requisitos é tão importante que em casos mais graves o código criado pode ser até desperdiçado, afetando diretamente os prazos envolvidos, trazendo prejuízos financeiros elevados, além de comprometer a credibilidade da empresa.
Como se trata de um processo que ocorre a partir da relação cliente/analista é importante considerar os elementos relativos à interpretação da dinâmica informacional presente nesta interação. Muito mais do que uma simples troca de informações, trata-se de um ato cognitivo que diz respeito ao processo de conhecer, intimamente ligado à atenção, memória, pensamento, raciocínio, entre outras ações do ser humano. Assim, parece evidente que o processo cognitivo pode influenciar de forma direta a compreensão e a interpretação dos analistas.
Nesta interação cognitiva cliente/analista tão essencial à análise de requisitos, a troca de conhecimentos e sua interpretação é fundamental para que as necessidades do cliente se traduzam em produtos adequados à sua demanda. O trabalho do analista nesse caso refere-se às dimensões do conhecimento do cliente que podem não estar ainda declarados, ou seja, se encontram numa dimensão tácita. Acessar essa dimensão pode representar melhores níveis de adequação do produto final.
2. Fundamentação teórica
2.1. Fábrica de software
Conforme Fernandes e Teixeira (2004), antes da década de 80 não havia processo disciplinado para desenvolvimento de software no Brasil. Esse processo que antes era artesanal passou a ser mais industrializado com o surgimento do conceito de Fábrica de Software, mas que só pode ser aplicado em escala comercial a partir de 1993 no mercado de São Paulo.
O conceito de Fábrica de Software ilustra a mudança do paradigma da produção de software centrada no trabalho intensivo para um modelo mais centrado no capital, onde investimentos são praticáveis e os riscos são de certa forma calculados. Apesar de existirem vínculos entre o desenvolvimento de software e a manufatura industrial, existem algumas diferenças fundamentais em relação à produção da manufatura industrial, tais como, a não produção em série e o vínculo da realização das atividades de desenvolvimento de software à criatividade e ao conhecimento prático e teórico das pessoas.
Apesar dos vínculos com a manufatura industrial, ressalta-se que na essência de uma Fábrica de Software está o objetivo técnico e de gerenciamento, com ênfase na qualidade. O foco técnico se refere à infra-estrutura de suporte e comunicação, a qual possibilita interação entre as pessoas. Já o gerenciamento pretende extrapolar modelos fixos de projetos de software através da especialização de modelos de processos, do reuso de conhecimento e de artefatos e da aplicação de qualidade e controle aos processos e aos produtos.
Castor (2004) reitera que a característica principal do modelo de Fábrica de Software é objetivar a criação de um ambiente de desenvolvimento produtivo de software com qualidade e baixo custo. Para que isso ocorra, são utilizadas técnicas da engenharia de produção em série, buscando a solução de problemas encontrados neste ambiente como a baixa produtividade e alto custo na produção de sistemas. Em síntese, as fábricas de software buscam a melhoria dos seus processos com o objetivo de otimizar a utilização dos recursos e diminuir os seus custos operacionais.
2.1.1 Processo de Desenvolvimento de Software
Lonchamp(1993) e Pessoa (2003), afirmam que para um bom funcionamento, o processo de desenvolvimento de software deve ser formado por passos ordenados com o objetivo de produzir e garantir que o produto acabado seja realmente o que foi solicitado. “Um processo de software descreve uma abordagem para a construção, implantação e, possivelmente, a manutenção de software.” (Larman, 2004, P.37). Assim, muitos engenheiros de software afirmam que garantindo qualidade do processo de desenvolvimento de software consequentemente se assegurará a qualidade do produto final. Por isso Pressman (2006), afirma que existem algumas atividades que são fundamentais no processo de construção de um software, ou seja, o ciclo de vida de todo processo de desenvolvimento deve cumprir um conjunto mínimo de atividades para se alcançar um produto: comunicação, planejamento, modelagem, construção, implantação. Realizar todas as etapas acima no decorrer do desenvolvimento de software principalmente as de comunicação, garantem que atividades básicas sejam realizadas evitando assim que se entregue um produto com baixa qualidade. A comunicação está na base da dinâmica informacional que por sua vez gera a interação cognitiva entre o cliente e o analista no momento da definição de requisitos. O conteúdo de tal interação é com frequência de natureza tácita e portanto de difícil captura e explicitação. Estabelecer um significado que seja comum tanto ao analista como ao cliente é portanto o maior desafio e tem uma influência direta no resultado da definição dos requisitos.
2.1.2 Requisitos de Software
Um fator preponderante de sucesso para um software é o grau em que atende aos requisitos para os quais foi construído. A fase de análise de requisitos é extremamente importante no desenvolvimento de um sistema, pois é o alicerce para o desenvolvimento do software.
Segundo o IEEE Standard Glossary of Software Engineering Terminology requisito é uma condição ou capacidade necessária para o usuário resolver um problema ou alcançar um objetivo; uma condição ou capacidade que deve ser encontrada ou possuída por um sistema ou componente do sistema para satisfazer um contrato, padrão, especificação ou outro documento imposto formalmente ou uma representação documentada de uma condição ou capacidade.
Por isso os requisitos de software determinam o que o sistema deve fazer e sob quais circunstâncias deve operar. Outra definição para requisitos é dada por Leite (2001) que explica que requisitos são uma condição fundamental para a aquisição ou para o preenchimento de certo objetivo. Como os requisitos formam a base para o desenvolvimento de software, é possível dizer que requisitos de má qualidade poderiam gerar um software de baixa qualidade. Isso pode ser consequência da falta de processos definidos para o levantamento destes requisitos o que levará a um documento que não expressa a verdadeira necessidade do cliente.
Isso pode acontecer em dois cenários distintos. Um ocorre pela falta de conhecimento das técnicas por parte de analistas e gerentes de projetos e o outro ocorre pelo excesso de intimidade com o cliente o que faz com que os profissionais responsáveis por esse levantamento suponham conhecer tão bem o processo e os problemas a ponto de deixarem de lado considerações importantes dos clientes. É possível diminuir tais falhas documentando e compartilhando estes requisitos, produzindo uma rica e completa definição dos mesmos.
Pfleeger (2004) em seu livro questiona porque os requisitos são importantes. Ele mesmo responde com uma pesquisa feita pelo Standish Group em 1994 que pesquisou mais de 350 empresas sobre seus mais de 8000 projetos de software. 31% dos projetos foram cancelados antes da sua conclusão e apenas 9% foram entregues dentro do prazo e valor estimado nas grandes empresas.
O mais esclarecedor e que também responde muito bem o questionamento feito pela autora é que requisitos incompletos representam a maior causa dos projetos terem sido falhos segundo os entrevistados, com 13,1%. Outras partes de definição, identificação e gerenciamento de requisitos também aparecem em outras respostas, como expectativas não realistas com 9,9% e modificações nos requisitos e nas especificações com 8,7%.
Outros estudos como o de Boehm (1984) indicam que o custo de correção de um erro encontrado depois do software implementado é muito maior, erros em requisitos de software são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.
Leffingwell (1997) afirma que em torno de 40% a 60% dos problemas detectados em um projeto são cometidos na fase de análise, ou seja, no levantamento dos requisitos, e que estes podem ser facilmente detectados. As consequências de não se detectar os erros nesta fase impactam diretamente na não satisfação do usuário, em um possível desentendimento entre os envolvidos, e na perda de tempo e dinheiro das partes. Assim, percebe-se que a identificação dos requisitos é parte extremamente importante no processo de desenvolvimento de software. Segundo Pfleeger (2004) é necessário a utilização de várias técnicas para determinar o que os usuários e clientes realmente querem.
Segundo Pressman (2006) todos nós lutamos quando tentamos levantar requisitos com nossos clientes, pois temos dificuldade de entender a própria informação conseguida. Poucos são os registros destes requisitos levantados e pouco tempo é gasto para se verificar o que realmente foi registrado. Para o autor ao invés de criarmos mecanismos de controle e gerenciamento destes requisitos, permitimos que as modificações nos controlem, falhando ao tentar estabelecer uma base consistente para o software que será construído. Quando estes problemas se combinam o futuro é incerto, porém existem soluções para contornar estas dificuldades.
Uma solução é a engenharia de requisitos (ER) que de forma geral, é o processo de identificação de todos os envolvidos, de localizar os objetivos e necessidades e documentá-los de forma correta para análise, comunicação e subsequente implementação. (Sommerville, 2003; Pressman, 2006). Segundo Thayer (2000) a engenharia de requisitos pode ser definida como a ciência e disciplina preocupada com a análise e documentação dos requisitos, incluindo análise das necessidades e análise e especificação dos próprios requisitos. Além disso, a engenharia de requisitos fornece mecanismos apropriados para facilitar as atividades de análise, documentação e verificação.
Ainda de acordo com Pressman (2006), engenharia de requisitos auxilia os engenheiros de software a compreenderem melhor o problema que precisam resolver, se utilizando para isso de tarefas que ajudam a chegar a um entendimento da dimensão que o sistema dará ao negócio, além de levantar o que os usuários querem e como interagirão com o sistema.
Um processo de engenharia de requisitos é um conjunto estruturado de atividades que são obedecidas para derivar, validar e manter um documento de requisitos de um sistema. Uma descrição completa desse processo inclui as atividades que devem ser guiadas, o mecanismo de execução destas atividades, as entradas e saídas de cada atividade e as ferramentas utilizadas para suportar a engenharia de requisitos (Sommerville; Sawyer, 1997).
O sucesso no processo de transformação dos pré requisitos do usuário em requisitos de produto torna-se claro, portanto, passa a ser um elemento crítico na realização global de um produto de sucesso (Daugulis, 2000) e ocorre em quatro etapas.
O que veremos a seguir é o que os autores falam sobre estas quatro etapas:
- Elicitação: É o levantamento dos requisitos, seja por meio de entrevistas com os usuários, clientes e especialistas, consulta a documentação do sistema, ou conhecimento tácito e explicito sobre o domínio de conhecimento em questão;
- Análise e negociação: Avaliar e revisar o escopo do software, envolvendo negociação com diferentes interessados, estabelecendo em conjunto um acordo dos requisitos, os quais devem estar consistentes e sem ambiguidades, para que possam ser utilizados como base para o desenvolvimento do software.
- Documentação: É a documentação dos requisitos acordados, que serve como meio de comunicação entre gerente de projeto/analista e cliente, formalizando-os em um nível de detalhe que todos os interessados consigam entender, geralmente por meio de linguagem natural e diagramas;
- Validação: Trata da verificação dos requisitos em termos de consistência e completude, verificando se os requisitos e modelos documentados atendem às reais necessidades dos usuários antes que sejam utilizados no desenvolvimento do sistema.
Analistas experientes possuem maior facilidade na atividade de construção de software por possuírem conhecimento de soluções recorrentes que podem ser aplicadas em diversas situações similares. Tais soluções podem ser documentadas adequadamente no formato de padrões para facilitar a sua utilização diversas vezes, sem, no entanto implementar a solução da mesma forma duas vezes (Sommerville; Sawyer, 1997).
Para que a definição de requisitos seja realizada com sucesso segundo Ratchev et al (2003) é fundamental uma correspondência exata entre os requisitos do cliente, capacidade do produto e conhecimento do processo por parte do analista. Para os autores apesar dos recentes desenvolvimentos na área ainda existe falta de transparência e definição coerente na integração das atividades de engenharia de requisitos.
Ainda segundo o trabalho dos autores que é parte do projeto ESPRIT colaborativo KARE (Knowledge acquisition and sharing for requirement engineering) financiado pela Comissão Européia, há falta de métodos estruturados para a captura do conhecimento empresarial relevante para posterior implementação em suporte de tomada de decisão no processo de especificação de requisitos.
Kudikyala e Vaughn (2005) abordam a definição de requisitos sob outra ótica onde aplicam uma técnica já utilizada na engenharia de software, mas desta vez na engenharia de requisitos. O trabalho dos autores é utilizar modelos mentais para reduzir os problemas de verificação e validação no processo de definição de requisitos. Para os autores a evidência empírica obtida no estudo indica que tais modelos podem também ser úteis na identificação de mal entendidos, requisitos duplicados e ambíguos. A técnica utilizada é conhecida como redes pathfinder (PFNETs). Nesse caso um software que aplica a técnica PFNET é utilizado para analisar documentos de requisitos de cliente e desenvolvedor separadamente.
No estudo feito pelos autores o principal benefício é a capacidade de gerar um modelo com aspectos de memória semântica humana. Ele fornece a capacidade de avaliar matematicamente e comparar estas redes de semelhanças e diferenças para revelar
possíveis mal entendidos.
Já Shaw e Gaines (1992) afirmam que os clientes geralmente codificam o conhecimento relacionado às suas necessidades, em textos, desenhos ou mensagens verbais, ou seja, em informação. A conversão desse conhecimento em informação explícita depende muito do uso do conhecimento tácito, o conhecimento pessoal que está implícito e é dificilmente transmitido.
2.2 O Conhecimento Tácito e a Gerência de Requisitos
Conforme Damm (2002), o conhecimento produzido em projetos pode ser categorizado como conhecimento em projetos, conhecimento sobre projetos e conhecimento proveniente de projetos. O conhecimento em projetos abrange dados e informações detalhadas que são produzidas ao longo do mesmo e é fundamental para que as pessoas envolvidas saibam como e quais projetos estão sendo encaminhados em algum momento. Isso contribui para a promoção de uma coordenação eficiente e efetiva das atividades, além do controle dos recursos utilizados nos projetos.
Já o conhecimento pertinente ao projeto corresponde às informações importantes geradas com a execução deste. Este conhecimento é definitivo para a busca do sucesso no projeto e contribui para o aprendizado organizacional.
Durante a execução de um projeto, particularmente na etapa de levantamento de requisitos são necessárias várias informações detalhadas sobre eles e as requisições dos clientes. No processo de gestão de requisitos podemos identificar os quatro modos de conversão de conhecimento propostos por Nonaka e Takeuchi (1998) os quais abrangem informações de origens e objetivos distintos.
O compartilhamento de experiências entre os integrantes do projeto, principalmente sob a forma da linguagem e observação, é segundo Nonaka e Takeuchi (1998), o modo de socialização onde ocorre a conversão do conhecimento tácito em conhecimento tácito. Na busca do entendimento dos desejos e objetivos do projeto de software analistas de sistemas adquirem com usuários e gerentes uma expertise no contexto do projeto a ser desenvolvido através do compartilhamento de experiências. Isso vem ao encontro do que dizem Nonaka e Takeuchi (1998) sobre a relação entre aquisição do conhecimento tácito e envolvimento, acentuado pelas emoções associadas nos contextos particulares nos quais as experiências partilhadas são embutidas.
A conversão do conhecimento tácito em conhecimento explícito, caracterizado como modo de externalização segundo Nonaka e Takeuchi (2008) ocorre na medida em que os participantes do projeto criam suas representações em forma de metáforas, pareceres, hipóteses ou modelos. Documentos que são fundamentais no processo de especificação e levantamento de requisitos e são normalmente a forma adquirida dessas representações. De acordo com Nonaka e Takeuchi (1998) a externalização é o principal modo para a criação do conhecimento, pois cria conceitos novos e explícitos a partir do conhecimento tácito.
Outro modo de conversão percebido na engenharia de requisitos é a combinação, que segundo Nonaka e Takeuchi (1998) ocorre quando existe conversão do conhecimento explícito em conhecimento explícito. É possível notá-la quando da sistematização de documentos e conceitos criados por analistas no momento em que se estuda toda a documentação inerente ao projeto e a sua respectiva transformação em documentos de especificação de requisitos com um nível de detalhamento elevado a fim de permitir que a fase seguinte do processo de desenvolvimento de software ocorra sem problemas. Na etapa seguinte a combinação das tecnologias selecionadas possibilita que protótipos sejam construídos e utilizados para auxiliar no processo de construção do software.
Por fim a documentação sistematizada passa pela homologação e análise de viabilidade dos indivíduos envolvidos no projeto os quais utilizam a verbalização e esquematização do conhecimento sob diversas formas como, por exemplo, manuais e histórias orais. Esse processo também é conhecido como incorporação do conhecimento, onde existe a conversão de conhecimento explícito em conhecimento tácito, ou seja, o modo de internalização segundo Nonaka e Takeuchi (1998). Os autores declaram ainda que para que ocorra a criação do conhecimento organizacional, é fundamental que o conhecimento tácito capitalizado seja difundido para o restante dos membros da organização, para que se inicie uma nova espiral de criação do conhecimento.
A criação do conhecimento organizacional é uma interação contínua e dinâmica entre o conhecimento tácito e o conhecimento explícito. (Nonaka E Takeuchi, 1998). Esse tipo de interação é percebida entre usuários e gerentes antes do desenvolvimento do produto e após sua implantação. Dessa forma a internalização produz conhecimento sobre o gerenciamento de requisitos o qual é socializado iniciando assim um novo ciclo, de acabamento do produto existente ou desenvolvimento de uma inovação.
Alguns trabalhos recentes como o de Scott (2008) confirmam a importância do conhecimento tácito existente no capital intelectual das empresas. O estudo de Scott (2008) examinou a criação e partilha de conhecimentos e percebeu que grande parte do conhecimento que as pessoas mais experientes possuem é tácito e aprendido com a experiência pessoal e com a interação com outros empregados. A maioria do conhecimento tomado como certo não é registrado em qualquer banco de dados, manual de procedimentos, ou programa. Nessa mesma linha, alguns autores indicam que criar e compartilhar conhecimento de forma mais eficaz do que os concorrentes possibilita ganho de vantagem competitiva (Boisot, 1998; Grant, 1996; Kogut E Zander, 1992; Teece, 1998). Nesse sentido, Cecez-Kecmanovic e Jerram (2002) trabalham com o modelo de gestão do conhecimento baseado em sensemaking. O modelo dos autores permitiu compreender os processos de criação e partilha de conhecimento em um momento de mudança organizacional. Segundo os autores no estudo se distinguiu diferentes tipos de conhecimento em diferentes níveis: individual, coletivo, organizacional e incorporado na cultura. Com base nesse entendimento, o trabalho dos autores possibilitou ter a compreensão das necessidades dos stakeholders em vários momentos dos processos de gestão aumentando a compreensão das mudanças nos processos e os seus problemas essenciais.
Outros estudos feitos na área dão conta que a partilha de conhecimento tácito,
está sujeita a interação social (Käser & Miles, 2002; Nonaka, 1994; Osterloh & Frey, 2000). Yang e Farn (2009) examinaram o compartilhamento do conhecimento tácito entre os membros de grupos de trabalho a partir da perspectiva do capital social e controle comportamental. Eles afirmam que a intenção do empregado em compartilhar conhecimento tácito é afetada pela confiança entre as pessoas. Também asseguram que a intenção de um funcionário em partilhar conhecimento não necessariamente levará a um comportamento tácito de partilhar conhecimentos. Como exemplos eles citam boa parte dos funcionários de Taiwan que não partilham experiências e conhecimento a menos que tenham um relacionamento de confiança com outros colegas.
A partir desses trabalhos é possível se perceber avanços quanto aos estudos relativos à motivação e às condições para o compartilhamento do conhecimento tácito. Poucos estudos, no entanto aprofundam a questão relativa ao sentido coletivo atribuído ao conhecimento tácito depois de seu compartilhamento. Os estudos relativos à essa questão se situam no campo do sensemaking e levam em conta a problemática em torno de processos coletivos de atribuição de sentido à informação e ao conhecimento.
2.2.2 Sensemaking e Resgate da Dimensão Tácita Do Conhecimento
Vários estudos ajudaram a compor o conceito de sensemaking e por isso muitas são as formas de grafia, porém optaremos neste trabalho por utilizar a palavra sensemaking escrita desta forma, visto que, também é utilizado pelo grupo de Psicologia Social e Administração Norte-Americano, dos quais se distinguem autores como Daft (1984), Thomas (1993), Gioia (1996) e Weick (1995), por exemplo.
Na visão de Karl Weick (1995) quando se fala de sensemaking estamos falando de algo em andamento, pois a definição do conceito ainda não é consenso no meio acadêmico. Segundo ele o conceito de Sensemaking foi definido como o significado literal de construção de sentido. É a formação acertada e significativa de eventos vividos por agentes sociais, ou também a estruturação do desconhecido (Weick, 1995).
Entretanto Weick (1995) mostra que o conceito pode ser baseado em muitas perspectivas, iniciando nas definições, que partem de uma revisão do sensemaking como atividade simplesmente individual até as análises que o colocam como fenômeno grupal.
Já para Evans & Chi (2008) um modelo de sensemaking inclui características sociais. A sugestão dos autores é que este comportamento social seja suportado por ferramentas de tecnologia da informação, utilizando, por exemplo, um método que torne acessível o conhecimento de comunidades e indivíduos de uma determinada rede, auxiliando desta forma os usuários no estágio de preparação de determinada tarefa. Para os autores é interessante que tais ferramentas estejam disponíveis também em uma fase posterior à busca.
Neste sentido Dervin (1992) interpreta a teoria de sensemaking a partir de ontologias e epistemologias relacionadas as atividades humanas de interpretar, discernir e reparar os acontecimentos ao seu redor, seguindo para o processo de inferência de sentido lógico ao fato observado. É possível verificar que a autora analisa a atividade de sensemaking como sendo um comportamento interno no sentido cognitivo, e também externo relacionado a postura, reações, entre outros comportamentos relacionados com o meio social. É preciso trazer a tona o conceito do sentido cognitivo por se tratar de algo fundamental na ideia de sensemaking. Assim, Manis (1973), afirma que existem varias abordagens teóricas dentro do campo das ciências cognitivas. Porém a maioria delas inclina-se para o conceito de que a cognição representa a aquisição de um determinado conhecimento por meio da percepção, reconhecimento, classificação, memória e compreensão envolvendo para isso operações cognitivas como atenção, memória, raciocínio, pensamento, percepção, etc.
Entretanto a cognição vai além da simples aquisição de conhecimento. Para obter uma melhor adaptação ao meio, a cognição pode ser considerada um mecanismo dentro de nossa mente que capta dados do exterior através dos sentidos e converte para o nosso modo de ser interno através da percepção. Ou seja, utiliza a informação do meio em que vivemos e o que já está registrado na nossa memória.
A memória é segundo Leiderman (2002), um sistema que permite a manutenção provisória e o processamento da informação para elaborar e dirigir nossa conduta. Por isso, Cardoso (2006), afirma que a memória é uma faculdade cognitiva de alta importância, porque forma a base para a aprendizagem, característica que pode ser considerada a habilidade de mudarmos o nosso comportamento através das experiências que estão armazenadas.
Furnas & Russell (2005) dizem que a prática de sensemaking é comum e constante nas atividades do dia-a-dia, quando tentamos entender o que acontece à nossa volta. O processo tem seu início quando nos deparamos com novos problemas e não temos conhecimento suficiente para superá-los. Esta carência de entendimento dispara uma sequência de atividades de busca de informação, indicando que sensemaking pode ser considerado um processo de relações cognitivas e sociais.
Dervin (1992), afirma que a informação é um minimizador de incertezas, pois ao se confrontar com um obstáculo, o indivíduo busca diversas soluções e formas de conhecimento para suprir a sua necessidade. Assim, são analisadas individualmente as situações, características e ações cognitivas e construtivistas de cada pessoa, na tentativa de se chegar a padrões comuns para a maioria.
Dessa forma é possível analisar com mais clareza a importância do sensemaking nas organizações, mais precisamente em empresas de software, as quais tratam o levantamento dos requisitos como um momento fundamental na vida de um projeto. Cabe aos analistas superar os obstáculos citados anteriormente por Dervin (1992), utilizando aspectos cognitivos como, interpretação, discernimento e análise de outros acontecimentos que estão ao seu redor e se inter-relacionam com a busca de conhecimentos, muitas vezes em relações sociais na tentativa de desenvolver representações mais aprimoradas para que auxiliem na execução desta tarefa. Essa ação de sensemaking juntamente com a prática de troca de experiências entre analista e cliente, faz com que o processo de inferência feito pelo analista ajude a visualizar mais detalhes relevantes do projeto inclusive novas necessidades de negocio.
Por isso, a partilha de experiências e conhecimentos também conhecida como socialização (Nonaka e Takeuchi 1998), se torna fator chave para que se suceda o correto entendimento dos requisitos no contexto do projeto que será desenvolvido.
Nessa linha, merece destaque o estudo de Qiu, Chui e Helander (2007) que teve como foco principal analisar como abordagens cognitivas auxiliam na utilização e gestão do conhecimento para tomada de decisões por equipes virtuais de desenvolvimento de produtos. Os autores indicam que para se obter sucesso na resolução de problemas juntamente com sucesso no desenvolvimento assertivo de produtos que atendam aos requisitos, é fundamental a compreensão dos processos cognitivos das pessoas envolvidas.
Outro estudo, com uma abordagem mais “hibrida” também aporta processos cognitivos, porém com maior ênfase na construção de sentido. Este estudo realizado por Kjærgaard, Kautz,e Nielsen (2007) também foi realizado na área de desenvolvimento de software, que pode ser considerada intensiva em conhecimento.
O estudo de Kjærgaard, Kautz, Nielsen (2007) teve como foco principal a criação de um manual de gerenciamento de projetos em desenvolvimento de software, utilizando como lente analítica o sensemaking. Os autores construíram o modelo a partir do mapeamento de processos e desdobramentos de sensemaking e cognição, coletivos e individuais dos envolvidos na pesquisa, a fim de melhorar as práticas de gestão de projetos buscando estimular a partilha de conhecimentos entre os envolvidos.
O modelo de Kjærgaard, Kautz, Nielsen (2007) considera a criação,a negociação e os os processos cognitivos construídos na forma organizacional, como estruturantes do sensemaking. A interpretação da realidade, no sentido dos processos cognitivos, mostram que os processos individuais são influenciados pelos entendimentos mantidos coletivamente na organização. Os processos cognitivos no primeiro período de criação são baseados no entendimento das pessoas nas partes específicas do fluxo de informações a que estão expostos continuamente. Na fase da negociação existe uma espécie de colisão entre as expectativas e experiências. Elas são as percepções e discordâncias dos membros em relação às expectativas e às experiências que geram insegurança e fazem com que essas pessoas encontrem a estabilidade através da criação de um novo quadro em que suas experiências se encaixam.
No estudo de Kjærgaard, Kautz, Nielsen (2007) a gestão do conhecimento foi inicialmente limitada a focar o processo de externalização do conhecimento dos participantes em procedimentos escritos e, portanto, trouxe uma visão um tanto reduzida de como as formas de conhecimento são importantes no gerenciamento de projetos. Segundo os autores, isso também levou a um processo completamente ineficaz de criação do conhecimento. No entanto, segundo os autores, quando ocorre a colisão desta abordagem com as experiências em gestão de projetos, os processos de negociação podem revelar uma realidade complexa. No caso do presente estudo, buscamos verificar se estes processos de negociação também ocorrem entre analista e cliente sob a ótica de ajustar divergências existentes na etapa de levantamento de requisitos e qual a o seu papel na socialização do conhecimento tácito.
3. A pesquisa
Para classificar a presente pesquisa, consideramos Vergara (2003), que qualifica a pesquisa quanto aos fins e quanto aos meios. No que se refere aos fins, este estudo é uma pesquisa exploratória, do tipo qualitativa e quanto aos meios, a pesquisa é bibliográfica, de campo com um estudo de caso único.
O campo de estudo desta pesquisa é a empresa Totvs, mais especificamente a franquia de desenvolvimento de soluções para a governança de saúde sediada em Caxias do Sul. Nesta franquia são percebidos conceitos e características que dialogam com as características de uma Fábrica de Software. Na unidade de Caxias do Sul é possível perceber aspectos como a existência de processos definidos e estruturados, que buscam o atendimento a múltiplas demandas de natureza e escopo distintas possibilitando flexibilidade aos projetos.
Também é possível evidenciar a não produção em série, dando mais liberdade a criatividade e ao conhecimento prático e teórico das pessoas o que ocorre na produção de bens intensivos em conhecimento. Isso proporciona a produção de software com a reutilização de código proporcionando maior qualidade e menor custo.
O inicio da empresa se dá quando a DZset começa suas atividades em 26 de abril de 1993, quando da terceirização da área de informática de uma grande empresa caxiense do setor metal-mecânico. Seus 17 sócios buscaram reunir esforços técnicos e recursos financeiros para alavancar o surgimento da empresa.
Ao mesmo tempo em que prestava assessoria para a empresa mencionada, a DZset conquistou um grande cliente do setor da saúde, para o qual desenvolveu software para a gestão de planos de saúde. A partir da consolidação do produto junto à empresa do setor de saúde, a DZset expandiu seus serviços para outras empresas na área, firmando parcerias para a criação de um sistema integrado para a gestão de cooperativas médicas, o SERIOUS – Gestão de Planos de Saúde.
Em 1º de junho de 2005, os ativos da DZset S/A e Datamedical Ltda, foram adquiridos pela Datasul S/A empresa pioneira no desenvolvimento e comercialização de softwares de gestão empresarial no Brasil. Após a aquisição, a Dzset passou a chamar-se Seventeen, tornando-se então uma franquia de desenvolvimento responsável pela produção de sistemas de gestão para o setor de saúde denominada Datasul Medical. Após uma fusão em novembro de 2007 com a subsidiária Informange de Sorocaba o nome é alterado novamente, desta vez para Datasul Saúde. Em agosto de 2008, a ultima mudança: a Datasul S/A é adquirida pela Totvs, e passa a fazer parte da maior empresa brasileira de softwares de gestão (ERP), tornando agora a Datasul Saúde uma franquia de desenvolvimento de software Totvs- Franquia de desenvolvimento de Soluções para a Governança de Saúde.O nome Totvs vem do latim e significatudo,todos, apropriado para uma companhia que fornece soluções em 10 segmentos para todos os portes e tipos de empresa. Os produtos são destinados para as áreas: administrativas, sistêmicas, de processos, de desempenho e de infra-estrutura. Toda essa gama de produtos e serviços garantem para a Totvs maior competitividade e, permite cada cliente focar em sua atividade fim e terceirizar parcialmente sua operação administrativa/sistêmica.
Com 26 anos de atuação, a TOTVS foi a primeira do setor em toda a América Latina a abrir capital. Tem mais de 25,2 mil clientes ativos, conta com o apoio de 9 mil participantes e está presente em 23 países.
O estudo será realizado na Franquia de desenvolvimento de Soluções para a Governança de Saúde – Totvs localizada na cidade de Caxias do Sul no estado do Rio Grande do Sul a qual possui atualmente 139 funcionários divididos entre matriz e filial e uma carteira composta por aproximadamente 110 clientes responsáveis por um faturamento anual de 12 milhões.
O desenvolvimento de novas implementações em produtos existentes é responsável por 44% do faturamento da franquia. Essas demandas sempre partem dos clientes e atualmente chegam aos analistas de sistemas por meio de FO – Ficha de ocorrência, documento onde ficam descritas as necessidades sob a ótica do cliente. Após análise do profissional de software, os requisitos voltam ao cliente para esclarecimentos ou para sua aprovação sob a forma de orçamento. Assim, estudar a franquia de desenvolvimento de software para a governança de saúde – Totvs proporcionará dados pertinentes e relevantes para alcance do objetivo desta pesquisa.
No que diz respeito à coleta de dados foi utilizado o modelo do sensemaking para a estruturação das entrevistas. O modelo está centrado no triângulo situação-lacuna-uso que representa o estado cognitivo do ser humano como um movimento contínuo, num determinado momento e num determinado espaço n. Os momentos do modelo são: a situação, momento inicial onde existe a busca e uso da informação. A lacuna, momento em que ocorre a problemática da busca e o do uso, momento em que se faz necessário uma estratégia para se alcançar o resultado esperado formando um triangulo Situação-Lacuna-Uso.
Esforços de pesquisas de sensemaking têm criado várias técnicas de coleta de dados. Dervin (1983) desenvolveu quatro técnicas de entrevistas: Micro-moment Time-Line Interview, Helps/Hunts Interview, Close-Ended Sense-Making e Message Questioning Interview (MQI).
O instrumento para a coleta de dados utilizado nesse trabalho foi a entrevista de Micro-Moment Time-Line (entrevista da linha do tempo em micro-momento). Esta técnica de coleta de dados foi desenvolvida ao longo do tempo e é descrita em diferentes níveis de detalhe, com exemplos, em várias publicações (Dervin, 1983, 1992, 1999). O micro-momento é uma das principais técnicas do Sensemaking e a sequencia da entrevista é o ponto central da técnica da abordagem, onde o entrevistador tenta organizar a fala em triângulos (situação/lacuna/uso).
O processo básico da entrevista Micro-Momento Time-Line significa levantar ao máximo, fatos que aconteceram em uma situação, com a ideia de linha do tempo. Para cada etapa chamadaTime-Line, o entrevistado é questionado sobre o que aconteceu em determinada situação que se queira estudar, seguindo com perguntas sobre os questionamentos que ele possuía, as coisas que ele precisava descobrir, aprender, se ficou mais confuso ou mais elucidado e se o sensemaking foi necessário (Dervin, 1983).
Então, para cada uma destas perguntas ou lacunas, o entrevistado é questionado de forma que suas respostas mostrem algo sobre seu mundo, possibilitando fazer conexões entre experiências passadas e presentes (Dervin, 2001), permitindo a compreensão dos três vértices do triângulo do Sensemaking: situação-lacuna-uso.
As entrevistas foram realizadas com 12 pessoas que ocupam cargos de analistas de sistemas, os quais estão divididos em analistas júnior, pleno e sênior responsáveis por fazer o levantamento de requisitos de software normalmente sob a forma de orçamentos. Estas 12 pessoas representam 100% da amostra, ou seja, todos os analistas responsáveis pelo levantamento de requisitos na área de desenvolvimento de novas implementações em produtos existentes.
Por mais que existam diversas técnicas, todos os métodos de coleta de dados têm algumas características em comum como, por exemplo, uso de estruturas livres de roteiro de entrevistas, estrutura de audiência baseada na compreensão do outro e a construção (ou não) de sentido (DERVIN, 1983).
Dervin (1999) escreve que o método de pesquisa como Sensemaking oferece uma teoria da entrevista e não um script. A aplicação pode ter inúmeras formas, dependendo da finalidade do estudo.A técnica de entrevista Micro-Momento Time-Line entra em detalhes sobre um passo da linha do tempo (Dervin, 1992), normalmente escolhido pelo pesquisado com base em vários critérios, por exemplo, mais importante, mais recente, mais problemático, mais lembrado.Dessa forma a entrevista Time-Line permite obter dados sobre situações memoráveis ??ou mais significativas. Uma vez realizadas as entrevistas, os diálogos serão registrados para a análise.
Este estudo é qualitativo e tem seu foco nos analistas de uma Fábrica de Software, porém entende-se que destinar um olhar para o cliente é extremamente importante, por isso, por meio de uma enquete foi realizada uma verificação da percepção do cliente quanto à qualidade dos produtos finais cujos requisitos foram definidos junto aos analistas entrevistados. Para tanto foi construído um questionário a partir da norma NBR ISO/IEC 9126-1:2003 deste trabalho, onde a mesma foi adaptada para que contivesse apenas questões fechadas.
Em geral o questionário refere-se a uma forma de alcançar respostas às questões por uma fórmula que o próprio informante preenche. Assim, os questionários foram enviados a 12 respondentes que representam 100% da amostra e que ocupam a função de analistas de negócios dos clientes para que respondessem a cerca da qualidade do projeto entregue pelo analista da Totvs previamente entrevistado. Os analistas e projetos foram identificados nos questionários apenas para fins comparativos recebendo nomes fictícios ao longo do trabalho.
Este instrumento foi aplicado através da internet onde um link encaminhado por email aos respondentes remetia a uma pagina web a qual gravava as informações.
Uma vez coletados os dados, estes foram analisados segundo as categorias derivadas do estudo de Kjærgaard, Kautz, Nielsen (2007) que referem-se à Criação, Colisão e Negociação.
A criação é a fase inicial, onde existe a busca pela informação, por algo que não está condizente com a realidade das organizações ou simplesmente melhore os processos operacionais das mesmas. É nesse momento em que a necessidade do cliente é levada até a empresa de software para que o processo de desenvolvimento da demanda seja realizado, iniciando pelo levantamento de requisitos feito por um analista.
A colisão é o passo seguinte, momento em que pode existir algum tipo de confusão, ou seja, algum tipo de problema na elicitação dos requisitos, com a possibilidade de ocorrência de colisão entre expectativas criadas pelo cliente e experiências de projetos anteriores dos analistas.
Por fim, verificou-se se ocorreu a negociação, processo que pode acontecer entre cliente e analista na transformação do conhecimento tácito através da socialização, afim de, deixar os requisitos mais claros para que se alcance um produto aderente a necessidade do cliente gerando dessa forma um novo quadro.
Para viabilizar a análise, as respostas foram organizadas com o uso do Mapa de Associação de Ideias associado ao software Atlas Ti. Mapas de associação de ideias são instrumentos de visualização cujo objetivo é subsidiar o processo de análise e interpretação dos dados da pesquisa, a fim de facilitar a comunicação de seus resultados (Vergara, 2005). Segundo a autora o mapa de associação de ideias confere visibilidade ao processo de análise por meio da organização de dados em estado bruto, em colunas que correspondem a categorias definidas pelo pesquisador. Outra característica é que ele permite a apresentação dos dados na sequência em que foram coletados, sem fragmentá-los, evidenciando o todo ao se percorrerem as colunas do mapa (Vergara, 2005).
Para a utilização do mapa de associação de ideias utilizamos inicialmente o software Atlas Ti para organizar as respostas segundo as categorias propostas. Foram realizadas 12 entrevistas que representaram 7 horas de conversas, algo que ao ser transcrito gerou aproximadamente 96 páginas de texto.
O Atlas/Ti consiste em um software de análise de dados qualitativos (Computer-Assisted Qualitative Data Analysis Software – CAQDAS). O objetivo do software não é automatizar o processo de análise, mas desenvolver uma ferramenta que apoie e facilite a interpretação humana.
O Atlas/Ti apresenta quatro princípios básicos: Visualização que gerencia a complexidade do processo de análise, a Integração que reúne todos os dados relevantes em um único projeto, a Casualidade que analisa de forma intuitiva os dados, encontrando respostas, achados inovadores e por fim a Exploração que examina o percurso de interpretação através dos elementos constitutivos do programa.
Conforme mencionado, tanto o Atlas/Ti como o mapa de associação de ideias foram estruturados a partir das três categorias provenientes do estudo de Kjærgaard, Kautz, Nielsen (2007) que referem-se à criação, colisão e negociação, tornando-se nosso filtro interpretativo além de determinar a quantidade de colunas do mapa. Colunas essas que receberam o conteúdo das entrevistas identificadas pelo Atlas/Ti de acordo com as categorias que se relacionam. Em seguida ocorreu a interpretação dos dados, resgatando-se o problema que provocou a investigação possibilitando identificar, por exemplo, quais categorias predominam.
4. Análise dos dados
Utilizando-se da técnica de sensemaking Micro-Momento Time-Line proposta por Dervin (1983), buscou-se saber nas entrevistas o que aconteceu no evento lembrado pelos respondentes e o que os levou a proceder de determinada forma, principalmente nas dificuldades encontradas no dia-a-dia onde somos instigados a ter novas ideias para transpor as barreiras criando assim uma nova realidade. (Furnas e Russell, 2005; Ferreira 1997).
Baseado nesta perspectiva, o sistema de análise dos dados decorreu por meio de três passos. O primeiro passo foi a escuta e transcrição exata de todas as entrevistas realizadas. O segundo passo consistiu em utilizar o software Atlas/Ti para organizar o conteúdo das entrevistas num projeto único (Unidade Hermenêutica), estruturado a partir das categorias, também chamadas de famílias, de acordo com o modelo de Kjærgaard, Kautz e Nielsen (2007). A partir de então iniciou-se a codificação, processo que identifica nas falas, uma representação do conteúdo capaz de evidenciar para o pesquisador características presentes no material analisado.
Assim, foi possível viabilizar a utilização dos mapas de associação de ideias, pois com as entrevistas devidamente classificadas e os filtros criados a fase seguinte foi a transferência das falas para o mapa, de forma sequencial separados em categorias. O conteúdo das transcrições foi organizado com o caráter dialógico e o sentido das entrevistas preservado. Ao final de cada resposta dos entrevistados foi incluída uma abreviação como, por exemplo, “p01” onde “p” significa a pergunta e “01” significa o número da mesma.
Ao analisar os resultados identificamos as diversas formas de implementações feitas pelos analistas: novos projetos, melhorias em funcionalidades existentes, continuações de projetos que já estavam em andamento e correções no produto existente.
Nessa realidade identificamos que analistas com menos tempo de empresa encontraram dificuldades na definição dos requisitos em virtude da falta de conhecimento da regra de negócio do sistema, fato esse que não se observa nos discursos de analistas mais experientes. Essa dificuldade acaba se refletindo no projeto, pois segundo os próprios analistas pode acabar trazendo certo constrangimento e com isso dificultando o contato com o cliente na busca de refinar os requisitos.
Verifica-se que o cliente facilita o trabalho dos analistas por diversas vezes quando cria documentos e fluxos tornando o processo mais visual sempre no intuito de auxiliar a fase de definição dos requisitos para que ele mesmo receba um produto com maior qualidade. Esse processo faz parte da construção da realidade inicial quando o cliente utiliza inclusive operações cognitivas transformando suas percepções do dia-a-dia, nesse caso as suas dificuldades, em uma nova demanda indo de encontro ao que diz Isabella (1990). Essa etapa também é conhecida dentro da perspectiva do sensemaking como o primeiro vértice do triangulo, a situação.
É possível observar que em praticamente todas as entrevistas os analistas se utilizam de experiências e de suas próprias interpretações da realidade para tornar um requisito de software ou até o desenvolvimento do projeto o mais eficiente possível. Essa interpretação da realidade seria uma espécie de quebra-cabeça o qual precisa ser montado pelas percepções coletivas de como se comportar na organização (Kjærgaard, Kautz E Nielsen, 2007) utilizando normas, técnicas e processos juntamente com informações e crenças do seu dia-a-dia (Isabella, 1990).
Através destas percepções do próprio cliente são criadas as expectativas em torno do projeto, visto que, em parte das entrevistas é possível identificar que os analistas percebem esse sentimento quando da existência de integração entre eles. O cliente passa de uma forma tácita tudo aquilo que não conseguiu expressar no papel, principalmente detalhes da usabilidade possibilitando ao analista recolher mais informações sobre a solicitação.
Dando sequencia nesse raciocínio, analistas que provocam a colisão segundo o modelo de Kjærgaard, Kautz e Nielsen (2007) na tentativa de definir da melhor forma os requisitos acabam encontrando alguns problemas. Problemas estes que muitas vezes são criados pelos próprios clientes como no trecho abaixo, onde o cliente se esquece de mencionar um processo interno seu. Essa identificação só foi possível através da interação existente entre cliente e analista e devido a proximidade entre os dois também pode ser sanada de forma mais rápida.
“[...]na hora que eles colocaram para nós o projeto eles não lembravam que tinham aqueles três ou quatro casos lá que era uma outra situação.[...]”
“[...]Todas as dúvidas eram sanadas de imediato.”
Pode-se perceber que os processos de negociação são desencadeados em sua grande maioria pela colisão das expectativas normalmente dos clientes com as experiências dos analistas. Isso é decorrência da busca incessante em sempre melhorar ao máximo um requisito.
Porém, existem aquelas situações onde a interpretação também pode gerar a negociação. Nesses casos isso ocorre pela forma com que foram escritos os requisitos, tanto pelo cliente como pelo analista ocasionando discussões devido a sua dupla interpretação.
A fase da construção da realidade secundária ocorre após a negociação entre cliente e analista. É possível identificar essa fase na compilação de trechos das falas abaixo onde os analistas procuram passar para o cliente como o sistema deve atuar mesmo que em alguns casos se necessite de outros caminhos para chegar ao mesmo resultado. Isso deixa claro a existência da preocupação por parte dos analistas em não fugir da solicitação inicial. As situações em que se obriga a execução de um processo de determinada forma são menos comuns, mas também fica claro que elas existem.
“[...]e aí se buscou caminhos alternativos que alguns contentaram o cliente e outros foi meio que empurrado, ó é assim ou não tem outro jeito e aí começou um pouco de desgaste em alguns momentos.”
“[...]Se tentou, se dialogou no início, mas nós acabamos meio que impondo uma solução porque foi o que tecnicamente era viável ...”
“Neste caso a negociação foi tranquila. Sempre me preocupo em deixar claro para o cliente que se o que o ele quer é viável para o sistema, é aceito exatamente como ele coloca. Caso não seja viável, é exposto para o cliente e oferecido outra forma pra atendê-lo. Tudo é negociável para que fique bom para ambos.”
Outras fases do modelo de Kjærgaard, Kautz e Nielsen (2007) também são identificadas nas entrevistas. A interpretação e percepção da análise secundária são processos cognitivos presentes no dia-a-dia destes profissionais e que auxiliam nas suas tomadas de decisão. Quando se recorre às experiências para solucionar um problema ou indefinição no processo de definição dos requisitos ocorre a adesão dessa nova realidade criada. Entretanto uma fase pouco presente nas falas é o abandono da realidade secundária, exatamente o oposto da adesão, quando as experiências são ignoradas e o processo sugerido pelo cliente é aceito.
Além do que foi associado às categorias de análise, outros aspectos relevantes foram identificados na fala dos entrevistados. Analistas com mais de 1 ano de empresa buscam o diálogo com o cliente como uma forma de entender melhor a sua solicitação criando um requisito mais adequado e tornando seu trabalho mais eficiente e assertivo. Isso acontece devido à experiência adquirida nesse período a qual perpassa maior segurança ao trabalho desempenhado.
Quando perguntado para estes respondentes que pensassem em um projeto que os marcou, observamos que analistas com mais tempo de empresa falaram de projetos onde ocorreu essa interação. Identificamos também que a maioria desses projetos na visão dos analistas ficaram de acordo com a especificação do requisito atendendo a necessidade do cliente.
Alguns problemas na fase de definição dos requisitos citados por Brooks (1987), foram visualizados nas entrevistas no decorrer deste trabalho. O mais evidente de todos é o fato de não existir nenhum tipo de metodologia ou padrão para realizar tal processo. Independentemente de cliente, módulo e tamanho do projeto cada analista experiente ou não utiliza apenas seu conhecimento para realizar essa etapa tão critica em um projeto de software, o que confirma a importância da dimensão técita do conhecimento no processo de definição de requisitos
Outro fato que devemos considerar é a pratica do levantamento de requisitos por pessoas pouco experientes e com pouco tempo de empresa. Apesar de todos os analistas deixarem claro que sempre foi necessário aprender algo no decorrer do projeto foi possível identificar que essa necessidade estava mais acentuada nos analistas classificados como novatos.
Uma forma de contornar tal dificuldade que pode ser ampliada com uma rotatividade elevada seria a utilização de tutoria entre pares de funcionários como propõem Scott (2008) em seu estudo. A ideia de criar e compartilhar conhecimento de forma mais eficaz realizada por funcionários com mais experiência repassando o conhecimento tácito e explícito sobre os processos, sistemas, regras de negócio, etc., seria um mecanismo para evitar requisitos incompletos. Nos trechos abaixo podemos identificar tal dificuldade.
“[...]eu não tenho muito conhecimento do negócio, para estar questionando assim.... não cheguei a questionar, ah tem que fazer de outra forma. Mudar mesmo o que ele(cliente) pediu assim nunca cheguei a mudar.”
Pesquisador: “Entendi, e se o requisito tivesse alguma coisa diferente do que o cliente solicitou? você fez baseado naquele requisito, então se por acaso tiver alguma coisa que não estava ali o cliente não iria receber?”
Entrevistado: “Não vai receber.”
Pontos positivos também são notados nas entrevistas deste estudo. É o caso da internalização de conhecimento que segundo Nonaka e Tekeuchi (1998) que ocorre quando da incorporação do conhecimento explicito em tácito. O exemplo mais claro e também comum em um Fábrica de Software é a observação do código fonte de um programa para aprender o que o mesmo faz.
Exceto o código fonte que também é o produto de uma empresa de software e por isso da sua existência, as demais documentações deixam a desejar segundo os próprios analistas. Segundo eles a maioria do aprendizado vem da socialização do conhecimento. Os motivos principais para a utilização dessa forma de transmissão de conhecimento vai de encontro com que Nonaka e Tekeuchi (1998) dizem, afirmando ser uma forma mais eficaz de adquirir conhecimento. Essa socialização também auxiliou muito na definição do requisito sendo o fator mais importante na opinião dos analistas para que o projeto ficasse de acordo com a solicitação do cliente. Esse processo traz inclusive benefícios para a organização, pois dentro do projeto a socialização do conhecimento de analistas com suas equipes sempre ocorreram.
Tal integração e socialização de conhecimento entre analistas e clientes se refletem na qualidade do software. Esse contato completa lacunas no momento da definição de um requisito tornando o mesmo rico em detalhes eliminando ambiguidades e incompletude. Assim como consideram Chiu (2011) e Barney (2012) essa interação na elicitação dos requisitos proporcionam grandes ganhos na qualidade final do software resultando em um produto aderente as necessidades do cliente.
Como dito anteriormente a maior parte dos analistas afirmaram existir em seus projetos mais relevantes, citados nas entrevistas, interação com o cliente e socialização do conhecimento. Nestes projetos todos entrevistados mencionaramque atenderam as necessidades dos clientes com um requisito adequado a sua solicitação, mas com alguns ajustes a serem realizados no decorrer destes projetos.
Na enquete realizada com os clientes, mais precisamente com pessoas que exercem função de analista no cliente e são responsáveis pelos projetos solicitados junto à fábrica, foi possível perceber que com exceção de um caso, as características de qualidade de software são maioria nos projetos. Esta enquete teve como finalidade verificar se a expectativa que o analista tinha se comprovava a partir das respostas dadas pelo cliente.
Figura 1 Características da qualidade de software
Fonte: Desenvolvido pelo autor.
Um último fato observado, mas não menos importante, são as lições aprendidas pelos analistas. Todos, sem exceção, afirmam que aprenderam algo durante a execução dos projetos Para eles o fato de aprender possibilita um crescimento dentro da organização e como consequência o desenvolvimento de produtos com maior qualidade de software.
Assim, os resultados obtidos com a presente pesquisa indicam que devido ao fato de uma fábrica de software estar contextualizada em uma área intensiva em conhecimento, a utilização e transferência do mesmo é fundamental para os processos do cotidiano. Fazer emergir o conhecimento tácito e transformá-lo em explicito é uma tarefa essencial como já diriam Nonaka e Takeuchi (1998) e pode ser facilitada com o processo de interação direta entre os polos cliente e analista. Porém, absorver essa gama de dados e informações afloradas nesse momento e relacionar com as técnicas de engenharia de requisitos passa a ser uma atividade dura a ser desempenhada por um analista. Descobrir ou instigar essa habilidade nestas pessoas significa entregar projetos com mais qualidade e consequentemente potencializar a vantagem competitiva da organização.
6. Considerações finais
O objetivo desta pesquisa foi analisar a dimensão tácita do conhecimento no processo de definição de requisitos e a qualidade em uma fábrica de Software da Serra Gaúcha. Identificamos ao longo da pesquisa que os processos cognitivos dos analistas como experiência, interpretação, memória, aprendizagem, etc. foram fundamentais para que projetos fossem entregues com a qualidade esperada.
Estes processos que possuem relação direta com o conhecimento tácito foram amplamente identificados na categoria colisão segundo o modelo dos autores Kjærgaard, Kautz e Nielsen (2007) onde percebemos que a mesma existiu devido às experiências e conhecimento por parte de analistas com mais tempo de empresa. O reflexo dessa colisão na fase de levantamento de requisitos foi extremamente positivo, pois a interação das pontas cliente e analista possibilitou que as necessidades do cliente estivessem contempladas de forma mais clara e objetiva minimizando o risco de se iniciar o desenvolvimento de um produto fadado ao fracasso.
Essa é uma das principais funções de um levantamento de requisitos e que também é percebida pelos analistas, pois nas suas entrevistas, sem exceção, todos deixaram claro que essa interação na elicitação dos requisitos é fundamental apesar de nem todos adotarem tal prática. Também fica claro que se por um lado analistas com mais tempo de atuação e consequentemente mais experiência buscavam sempre essa interação, por outro, analistas considerados novatos tinham certo receio de criar esse contato, justamente pela falta de experiência e conhecimento da regra de negócio.
O problema que um requisito mal elaborado pode causar também é de conhecimento de grande parte dos entrevistados, pois muitos já sofreram com isso. Requisitos mal estimados e com poucos detalhes exigem maior esforço, principalmente de pessoas com menos experiência, o que acaba impactando diretamente na quantidade de horas diminuindo a qualidade final do software, gerando maior retrabalho e tendo como resultado menor lucro para a empresa.
Baseado nos fatos evidenciados na pesquisa e relacionando com a visão de Nonaka e Takeuchi (1998) onde afirmam que para inovar é necessário processar informações de fora para dentro criando novos conhecimentos e informações de dentro para fora recriando seu meio chegamos ao modelo abaixo, o qual poderá ser utilizado como guia em processos de definição de requisitos.
Fonte: Desenvolvido pelo autor.
Diferentemente do modelo utilizado como base no referencial deste trabalho a ideia aqui é que o modelo proposto tenha o formato circular dando ideia de continuidade, onde o processo permaneça evoluindo até que fique ajustado.
Tudo começa na construção da realidade inicial, ou seja, na necessidade vista pelo cliente, fato este que o faz procurar a fábrica solicitando a demanda. A partir daí é fundamental que ocorra a integração entre cliente e analista, momento em que os processos cognitivos como experiência e conhecimento fazem toda a diferença na elaboração de um requisito de software, visto que, funcionam como uma espécie de engrenagem que ajusta e refina o documento a partir da dinâmica do conhecimento tácito. Como consequência uma nova realidade é criada o mais próximo da exatidão, mas que se ainda assim não for a ideal dispara novamente o processo fazendo com que este se repita até que se chegue a um requisito 100% aderente. O efeito do modelo é ter um requisto que atenda o que o cliente necessita, tornando-se a chave para diminuição de um problema existente em praticamente todas as fábricas de software que é o retrabalho.
Espera-se que este modelo possa servir como referência para fábricas de software, pois na busca do entendimento dos objetivos e ambições de um projeto analistas alcançam uma expertise ímpar desenvolvida a partir do compartilhamento de experiências com seus clientes. Essa experiência adquirida precisa ser repassada para o resto da equipe algo que já acontece atualmente dentro da fábrica estudada, porém, de uma forma um tanto limitada, alcançando apenas as pessoas envolvidas com o projeto. Esse repasse de conhecimento para as demais equipes pode ser a maneira que uma empresa tem de preparar seus colaboradores sem que eles precisem sofrer na prática para adquirir tal conhecimento evitando, sobretudo, problemas com qualidade e desgaste do cliente.
Como todos analistas deixaram claro que aprenderam com seus projetos, identificar uma maneira eficiente e que seja adequada a uma Fábrica de Software de transferir esse conhecimento após o termino dos projetos pode ser tratado como um trabalho futuro. Além disso, propor novos fluxos assim como a reestruturação dos processos de definição dos requisitos de modo que permaneçam alinhados com as descobertas deste estudo podem ser alvo de pesquisas futuras.
Referências bibliograficas
Barney S., Petersen K., Svahnberg M., Aurum A., Barney H. (2012); Software Quality Trade-Offs: A Systematic Map, Information And Software Technology. In Press, Accepted Manuscript February.
Boehm, B. W. (1994);Verifying And Validating Software Requirements And Design Specification. Ieee Software, V.1.
Boisot, M. (1998); Knowledge Assets: Securing Competitive Advantage In The Information Economy. New York, Ny: Oxford University Press.
Brooks, F. (1987); No Silver Bullet: Essence And Accidents Of Software Engineering. Ieee Computer.
Cardoso, S.H. (2006); Memória: O Que É E Como Melhorá-La. Disponível Em: <http://www.cerebromente.org.br> Acesso Em 01 Abr. 2011.
Castor, E. M. (2004); Fábrica De Software: Passado, Presente E Futuro. (Pós-Graduação Lato Sensu Em Tecnologia Da Informação) Unibratec - União Dos Institutos Brasileiros De Tecnologia.
Cecez-Kecmanovic D. & Jerram, C. (2002); “A Sensemaking Model Of Knowledge Management In Organisations.” The European Conference On Information Systems Ecis 2002, 6-8 June 2002, Gdansk, Poland, Pp. 894-904.
Chiu, N.H. (2011); Combining Techniques For Software Quality Classification: An Integrated Decision Network Approach. Journal Expert Systems With Applications: An International Journal, Volume 38 (4), P. 4618–4625.
Cusumano, M. A. (2005); “The Puzzle Of Japanese Software.” Communications Of The Acm, V. 48.
Cusumano, M. A. (2001); Japan’s Software Factories: A Challenge To Us Management. Oxford University Press: New York.
Daft, R. L.; Weick, K. E. (1984); “Toward A Model Of Organizations As Interpretations Systems.” Academy Of Management Review, V. 9.
Damm, D., Schindler, M. (2002); Security Issues Of A Knowledge Médium For Distributed Projects Work. Intern. J. Of Project Management 20.
Daugulis, A. (2000); “Time Aspects In Requirements Engineering: Or Every Cloud Has A Silver Lining.” Requirements Engineering. V.5 P.137- 143.
Dervin, B. (1983); “An Overview Of Sense-Making Research: Concepts, Methods And Results To Date.” International Communications Association Annual Meeting. Dallas.
Dervin, B. (1999); “On Studying Information Seeking Methodologically: The Implications Of Connecting Metatheory To Method.” Information Processing And Management. V. 35.(6).
Dervin, B. (1992); From The Mind’s Eye Of The User: The Sense-Making Qualitative- Quantitative Methodology. In: Glazier, J.; Powell, R. “Qualitative Research In Information Management. Englewood: Libraries Unlimited, 1992. Disponível Em: <http://communication.sbs.ohio-state.edu/sensemaking/art/artabsdervin92powell.html> Acesso Em: 05 Jan. 2011.
Dervin, B. What We Know About Information Seeking And Use And How Research Discourse Community Makes A Difference In Our Knowing. 2001. Disponível Em <http://communication.sbs.ohio-state.edu/sense-making/art/artabsdervin01nlm.html> Acesso Em 13 Mai 2011
Evans, B.M.; Chi, E.H. (2008); Towards A Model Of Understanding Social Search. San Diego, California, Usa.
Fabri, J. A. Et Al. (2004); Desenvolvimento E Replicação De Uma Fábrica De Software. 2004 In: Vi Simpósio Internacional De Melhoria De Processos De Software,
Fernandes, A. A.; Teixeira, D. S. Fábrica De Software: Implantação e Gestão De Operações. (2004); São Paulo: Atlas.
Furnas, G. W.; Russell, D.M. (2005); Making Sense Of Sensemaking. Portland, Oregon, Usa.
Gioia, D. A. Mehra, A. (1996); “Sensemaking In Organizations.” In Weick, Karl E. Thousand Oaks (CA): Sage. Academy Of Management. The Academy Of Management Review, v. 21, Issue 4, P. 1226-1240.
Grant, R. (1996); Toward A Knowledge-Based Theory Of The Firm. Strategic Management Journal 17: 109-122.
Harvey, D. (1994); Condição Pós Moderna. São Paulo: Edições Loyola.
Humprhey, W. S. (1989); Managing The Software Process. Canada: Addison-Wesley.
Isabella, L. A. (1990); “Evolving Interpretations As A Change Unfolds: How Managers Construe Key Organizational Events.” Academy Of Management Journal. 33 (1), 7-41.
Iso (1995); - International Organization For Standardization. information Technology—Guideline For The Evaluation And Selection Of Case Tools [Iso/Iec 14102:1995(E)]. Geneva, switzerland: International Organization For Standardization
Käser, P. A. W., E Miles, R. E. (2002); “Understanding Knowledge Activists’ Successes And Failures.” Long Range Planning, 35, 9–28.
Kjærgaard A.; Kautz K.; Nielsen P. A. (2007); Making Sense Of Project Management - A Case Of Knowledge Management In Software Development. In: Proceedings Of The Fifteenth European Conference On Information Systems (ÖSTERLE H, Schelp J, Winter R Eds.), 565-575, University Of St. Gallen, St. Gallen.
Kogut, B. E Zander, U., (1992); “Knowledge Of The Firm, Combinative Capabilities, And The Replication Of Technology.” Organization Science 3: 383-397.
Kudikyala, U.K E Vaughn, R.B. (2005); “Software Requirement Understanding Using Pathfinder Networks: Discovering And Evaluating Mental Models.” In: Journal Of Systems And Software - Special Issue: Automated Component-Based Software Engineering Archive. v 74 (1), Elsevier Science Inc.
Larman, Craig. (2004); Utilizando uml e padrões: uma introdução à análise e ao projeto orientados a objetos e ao processo unificado. São Paulo: Bookman.
Leffingwell, D. (1997); “Calculating The Return On Investment From More Effective Requirements Management.” American Programmer. v. 10(4).
Leiderman, S.M. (2002); The World Problem Of Environmental Emigration From Polluted Regions. The Nato Advanced Research.
Leite J. (2001); “Documentação De Software”.In: Qualidade De Software: Teoria E Prática, Eds. A.R.C. Rocha, J.C. Maldonado, K. Weber, Prentice Hall.
Lonchamp, J. (1993); A Structured Conceptual And Terminological Framework For The Software Process Engineering. In: International Conference On The Software Process Berlin. Proceedings.
Manis, M. (1973); Processos Cognitivos. São Paulo: Ed. Herder.
Nonaka, I.; Takeuchi, H. (1997); Criação De Conhecimento Na Empresa. 16ª Ed. Rio De Janeiro: Campus.
Nonaka, I.; Toyama, R.; Konno, N. S. (2000); Ba And Leadership: A Unified Model Of Dynamic Knowledge Creation, Long Range Planning. V. 33.
Nonaka, I.; Takeuchi, H. (2008); Gestão Do Conhecimento. Tradução Ana Thorell. Porto Alegre: Bookman.
Osterloh, M., E Frey, B. S. (2001); Motivation, Knowledge Transfer, And Organizational Forms. Organization Science, 11(5), 538–550.
Pessoa, M. S. P. (2003); Introdução Ao Cmm - Modelo De Maturidade Da Capacidade De Processo De Software. Lavras: Curso De Pós-Graduação Ufla/Faepe
Pfleeger, S.L. (1998); Software Engineering: Theory And Practice. New Jersey: Prentice – Hall.
Pfleeger, S. L. (2004); Engenharia De Software: Teoria E Prática. 2.Ed. Rio De Janeiro: Pearson.
Plant R.T. (1991); “Factors In Software Quality For Knowledge-Based Systems”. Journal Information And Software Technology. v. 33(7).
Pressman, R. S. (2006); Engenharia De Software. 6.Ed. São Paulo: Mcgraw-Hill.
Qiu, Y.F.; Chui, Y.P And Helander, M.G. (2007); A Cognitive Approach To Understanding Knowledge-Based Virtual Team Decision Making In: Product Design, Int. J. Intelligent Enterprise, v. 1(1).
Ratchev, S.M., Urwin, E., Muller, D., Pawar, K.S., Moulek, I.. (2003); “Knowledge Based Requirement Engineering For One-Of-A-Kind Complex Systems.” Journal Of Knowledge Based Systems. Knowledge-Based Systems .Vol 16(1) P.1-5.
Rocha, A.R.C; Maldonado, J.C; Weber, K. (2001); Qualidade De Software: Teoria e Prática. São Paulo: Prentice Hall.
Sampaio, A.L.S.; Primo F.; Francisco; M.; Wagner R. (2005); Método Para Definição De Requisitos De Software De Um Sistema A Partir Das Necessidades Dos Seus Stakeholders In: Vii Simpósio Internacional De Melhoria De Processos De Software, São Paulo, Brazil.
Sampaio, S. E. K. (2006); O Desenvolvimento Da Aglomeração Produtiva De Software De Curitiba. Dissertação (mestrado). Curitiba – Ufpr.
Scott, E.B. (2001); “Impact Of Peer Mentor Training On Creating And Sharing Organizational Knowledge”, Journal Of Managerial. Vol. 20(1).
Shaw, M.L.G., Gains, B.R.(1992); “Integrated Knowledge Acquisition Architectures”, Journal Of Intelligent Information Systems. v.1.
Sommerville, I. (2003); Engenharia de Software. 6.Ed. São Paulo: Addison-Wesley.
Sommerville, I. (1995); Software Engineering International Computer Science Series. 5ª Edição. Reading: Addison-Wesley.
Sommerville, I.; Sawyer, P. Requirements Engineering A Good Practice Guide. 1ªed. England : John Wiley & Sons Ltd, 1997
Souza, A. D. Estudo E Avaliação Da Área De Processo De Planejamento De Projeto De Acordo Com O Modelo Cmmi-Sw Nível 2 Na Empresa Sw Quality Situada Em Lavras-Mg. 2004. Monografia (Graduação Em Ciência Da Computação) – Universidade Federal De Lavras, Lavras. Disponível Em, <http://www.comp.ufla.br/monografias/ano2004/ano2004.htm>. Acesso Em: 06 Out. 2010.
Teece, D. J., (1998); “Capturing Value From Knowledge Assets: The New Economy, Markets For Know-How, And Intangible Assets”. California Management Review. v. 40 pp. 55-79.
Thayer, R; Dorfman, M. (2000); System And Software Requirements Engineering. Ieee Computer Society Press Tutorial.
Thomas, J. B.; Clark, S. M.; Gioia, D. A. (1993); “Strategic Sensemaking And Organizational Performance: Linkages Among Scanning, Interpretation, Action, And Outcomes.” Academy Of Management Journal, v. 36, Issue 2, P. 239-270.
Vergara, S. C. (2005); Métodos De Pesquisa Em Administração. São Paulo: Atlas.
Weick, K. E. (1995); Sensemaking In Organizations. Thousand Oaks: Sage.
Yang, S.C. E. Farn, C.K. (2009); “Social Capital, Behavioural Control, And Tacit Knowledge Sharing—A Multi-Informant Design.” International Journal Of Information Management. v. 29 (3).