Espacios. Vol. 37 (Nº 34) Año 2016. Pág. 2

Aprendizagem nas Organizações: uma análise processual de indivíduos inseridos em grupos de desenvolvimento de software

Learning in organizations: a procedural analysis of individuals entered into software development groups

Letícia Rodrigues da FONSECA 1; Marcelo Ribeiro SILVA 2; Roger Antonio RODRIGUES 3; Guilherme Augusto Dionisío VIVALDI 4; Armando Belato PEREIRA 5; Guilherme Marques PEREIRA 6

Recibido: 16/06/16 • Aprobado: 23/07/2016


Conteúdo

1. Introdução

2. Aprendizagem coletiva

3. Metodologia

4. Apresentação e Discussão dos Resultados

5. Considerações Finais

Referências


RESUMO:

O objetivo deste artigo é compreender como a aprendizagem ocorre no nível coletivo em organizações de desenvolvimento de software (ODS). Para isso, foi realizado um estudo qualitativo do tipo multicaso em quatro ODSs. Como uma estratégia de coleta de dados, foi utilizado o método de entrevista semi-estruturada aplicada em indivíduos envolvidos no processo de desenvolvimento de software. As análises foram realizadas utilizando o software para Weft_QDA análise qualitativa, o qual permitiu o estabelecimento de categorias analíticas. No final, foi possível identificar e compreender as situações de aprendizagem coletiva que ocorrem nessas organizações.
Palavras-chave: Organizações de Desenvolvimento de Software, Weft_QDA; aprendizagem

ABSTRACT:

The objective of this article is to understand how learning occurs at the collective level in software development organizations (SDO). For this, we carried out a qualitative study of Multicase type in four OSDs. As a data collection strategy, we used the semi-structured interview method applied in individuals involved in the software development process. Analyses were performed using the software for qualitative analysis Weft_QDA that allowed the establishment of analytical categories. In the end, it was possible to identify and understand the learning situations and collectively that occur in these organizations.
Keywords: Software Development Organizations, Weft_QDA; learning

1. Introdução

De acordo com Albertin (2000), a atual economia denominada ‘economia do conhecimento’ baseia-se na aplicação do conhecimento humano a tudo que produz e como se produz. O conhecimento é considerado o elemento mais importante dos processos relativos a produtos e serviços, desde o seu desenvolvimento até a entrega e apoio na utilização.

O valor agregado é adquirido por meio da inteligência humana, em vez do esforço físico de trabalhadores. A inovação, mais do que o acesso a recursos ou capital, torna-se crítica, porque na nova economia, conseguir adentrar e manter-se no mercado é difícil quando os produtos têm uma vida competitiva de um ano, um mês, uma semana, ou algumas horas, como no caso de produtos financeiros.

Logo, os ativos-chave das organizações serão os ativos inteligentes ou os trabalhadores do conhecimento, capazes de desenvolver novos produtos e serviços conforme as atuais expectativas do mercado e atender a proposta da nova economia: torne os seus próprios produtos obsoletos, antes dos seus concorrentes.

Acredita-se que seja fundamental para as Organizações de Desenvolvimento de Softwares (ODS) instituírem um ambiente de trabalho que apoie o aprendizado, inclusive no nível coletivo, para lidar com os desafios da nova economia e manterem-se competitivas no mercado. O desenvolvimento de software é uma atividade individual, pois seu resultado depende da maneira particular com que o desenvolvedor aprende a aplicar os seus conhecimentos tecnológicos para transformar o requisito do usuário em um artefato computacional. No entanto, ao mesmo tempo também depende dos esforços coletivos de uma equipe, pois os softwares são construídos conforme métodos da Engenharia de Software utilizados por grupos de desenvolvimento (Tonini e outros, 2008). Portanto, o presente estudo propõe-se a entender como ocorre o aprendizado no nível coletivo, nessas organizações.

2. Aprendizagem coletiva

De acordo com Dixon (1997; 1999), a aprendizagem coletiva ocorre em um espaço projetado para facilitar conversas profundas entre os membros da organização sobre assuntos que lhes interessam. Nesses espaços, os indivíduos interagem por meio da troca de dados, por meio do compartilhamento de conclusões e raciocínios. As pessoas dialogam entre si em vez de apenas expor ideias umas para as outras.

Portanto, são nos corredores que as pessoas conversam entre si como iguais, sem pressões provenientes de uma estrutura hierárquica. Em algumas organizações, é difícil para aqueles que estão em posições de menor autoridade desafiar as ideias ou apresentar as suas perspectivas, para aqueles que ocupam posições de maior autoridade. A hierarquia pode inibir a aprendizagem coletiva, pois os subordinados podem suprimir ou negar suas próprias ideias e os superiores podem impor as suas, fazendo com que os subordinados distanciem-se a fim de se protegerem. Os ‘corredores’ precisam ser concebidos como lugares onde os gestores abdicam de suas posições, atuando apenas como participantes no processo de discussão para a construção do significado coletivo. Sem o livre fluxo de ideias, o aprendizado é severamente limitado (Dixon, 1997; 1999).

Nos corredores diversas pessoas expõem os seus pontos de vista, e são as diferenças entre essas perspectivas individuais que promovem a aprendizagem coletiva. Ao analisar as perspectivas individuais dos seus membros, o grupo poderá construir um significado coletivo a partir das ideias mais viáveis. Logo, é necessário convidar várias perspectivas para o ‘corredor’, além de tolerar a tensão que resulta das diferenças entre elas, para que um novo conhecimento seja construído (Dixon, 1997; 1999). Para essa autora, a principal vantagem em se promover a apresentação de múltiplas perspectivas é oferecer ao coletivo a possibilidade de explicitar suas suposições tácitas que eram, até o momento, desconhecidas. Uma vez explicitadas, essas suposições são discutidas publicamente e sua acurácia debatida. As suposições que se tornaram ultrapassadas ou desvantajosas para a organização são descartadas e aquelas que ainda servem ao interesse comum são mantidas.

Segundo Dixon (1997; 1999), os corredores operam por dois pressupostos fundamentais: (1) pessoas comuns pensando juntas têm a capacidade de gerar respostas funcionais para os problemas da organização; (2) não há apenas uma solução para a maioria dos problemas organizacionais, ao contrário, existem muitas soluções potenciais que podem ser eficazes.

Os corredores são ricos em dados, pois os participantes trazem consigo a compreensão acerca de seus próprios processos, sobre como eles interagem com outros departamentos e sobre o que é importante para eles em seu trabalho, o que eles valorizam. Os participantes trazem ainda dados sobre a qualidade dos produtos e serviços da empresa e dados que coletaram com os clientes. Portanto, os corredores reúnem dados de fontes primárias que permitem que o processo de ‘fazer sentido’ seja menos inferencial e mais baseado em dados concretos. Os dados tornam-se públicos nos corredores pelos mapas de processos, listas, planos e diagramas. O significado coletivo é construído por meio da discussão pública que faz referência a esses dados (Dixon, 1997; 1999).

3. Metodologia

Considerando o problema e os objetivos propostos neste artigo, optou-se por realizar uma pesquisa de abordagem qualitativa. Tal abordagem apresentou-se como a mais adequada, devido à ausência de explicações confiáveis para o problema de pesquisa proposto, sendo necessário adotar um enfoque exploratório e descritivo (Godoy, 1995). Para Berg (2001), a pesquisa qualitativa responde perguntas pela investigação de ambientes sociais. Ela possibilita ao pesquisador compartilhar das compreensões e percepções dos indivíduos que habitam esses ambientes, como interpretar o comportamento das pessoas e os significados que elas atribuem às situações vivenciadas.

Este trabalho pode ser considerado um estudo do tipo multicaso, quando o pesquisador identifica a necessidade de estudar vários casos individuais que guardam uma correlação importante para entender um fenômeno como um todo.

Pesquisaram-se quatro ODSs - Organizações de Desenvolvimento de Software que adotaram o modelo para a Melhoria do Processo Software Brasileiro – MPSBR.Acredita-se que esse modelo incentiva a aprendizagem, pois prescreve um conjunto de ‘áreas de processo’ que formam uma plataforma sob a qual, são operacionalizadas tarefas individuais e coletivas realizadas em projetos de software. Uma ‘área de processo’ pode ser definida como um conjunto de práticas de uma determinada área do desenvolvimento de software, que, quando implementadas, satisfazem um grupo de metas importantes para se obter uma melhoria significativa nessa área (Couto, 2008). Os modelos incentivam a aprendizagem, pois os desenvolvedores precisam compreender as orientações propostas pelas práticas para estabelecer métodos que possam atendê-las(Ramasubbu e outros, 2008). Nesse momento, a ODS necessita possuir um ambiente de trabalho que subsidie o desenvolvimento, a execução e a avaliação desses métodos.

A seguir, uma breve descrição das empresas que participaram desse estudo e que optaram por não divulgar a sua razão social:

Organização A: Emprega cerca de 250 funcionários e, em 2010, conquistou o nível C do MPSBR; Organização B: Emprega cerca de 150 funcionários e, em 2010, conquistou o nível F de maturidade do MPSBR; Organização C: Emprega cerca de 1.500 funcionários, sendo que 70 atuam na fábrica de software. Em 2010, conquistou o nível C de maturidade do MPSBR; Organização D: Emprega cerca de 200 funcionários, e, em 2010, conquistou o nível C de maturidade do MPSBR.

Com o intuito de obter informações de pessoas que apresentassem uma percepção consolidada sobre o ambiente de trabalho dessas empresas foram entrevistados profissionais envolvidos no processo de desenvolvimento dos sistemas das ODSs participantes, contratados há pelo menos um ano. O empregado pesquisado que atuou menos tempo em uma das ODSs foi contratado há 3 anos. As entrevistas aconteceram entre os meses de novembro e dezembro de 2012, entretanto, vale ressaltar que, em meados de 2014, os autores deste trabalho retornaram às organizações pesquisadas para convalidar os dados da pesquisa anterior.

Quadro 1 - Caracterização dos Entrevistados

Organizações pesquisas

Funcionários entrevistados

Função

Tempo de contratação  (em anos)

A

Desenvolvedor 1A

Diretor de Operações

4

Desenvolvedor 2A

Gerente de Projetos

3

Desenvolvedor 3A

Analista de Requisitos

3

B

Desenvolvedor 1B

Líder da Equipe de Atendimento

7

Desenvolvedor 2B

Especialista de Negócios

8

Desenvolvedor 3B

Analista e Desenvolvedor

6

C

Desenvolvedor 1C

Gerente do SEPG

12

Desenvolvedor 2C

Líder de Projetos

13

Desenvolvedor 3C

Analista e Projetista

8

D

Desenvolvedor 1D

Gerente de Tecnologia

7

Desenvolvedor 2D

Analista e Desenvolvedor

5

Desenvolvedor 3D

Analista e Desenvolvedor

12

Fonte: Elaborado pelos autores.

Entrevistaram-se apenas três desenvolvedores em cada ODS devido à saturação dos dados, ou seja, ao comparar as respostas da segunda entrevista com a primeira, verificou-se que ambas eram muito semelhantes, com poucas especificidades. Portanto, três entrevistas foram suficientes em cada organização para atender aos objetivos deste trabalho.

Adotou-se como método de coleta de dados a entrevista semiestruturada. Acrescenta-se que esse estudo utilizou apenas esse método, pois as organizações participantes não autorizaram a observação participante e não participante, bem como a análise documental.

As entrevistas foram transcritas por um especialista que utilizou para isso um editor de texto. Posteriormente, os arquivos txt foram importados para o software Weft_QDA, que trabalha com dados qualitativospor meio de quatro funções básicas: armazenamento de dados de forma organizada – em categorias analíticas ou demográficas criadas pelo investigador –; busca e classificação de dados por meio de categorias – entrevistas, notas de campo, documentos, reflexões ou observações –; estabelecimento de relações com os dados por meio de diversas buscas; visualização dos resultados das buscas em forma de textos ou quadros.

Realizou-se uma leitura cuidadosa das transcrições com o intuito de identificar trechos dos textos que apresentavam relação, para se estabelecer códigos ou categorias, em que define sobre o que se trata os dados em análise, envolve a identificação e o registro de uma ou mais passagens de texto ou outros itens dos dados, como partes do quadro geral que, em algum sentido, exemplificam a mesma ideia teórica e descritiva. (Gibbs, 2009, p. 61).

As categorias que guardam semelhança ou referem-se ao mesmo assunto são reunidas em um mesmo ramo dessa hierarquia. A categoria geral é denominada “código pai” e a categoria associada à geral, denominada “código filho”. No Weft Qda, a categorização dos dados foi realizada conforme as orientações de Gibbs (2009).

4. Apresentação e Discussão dos Resultados

Buscou-se compreender como os desenvolvedoresaprendem coletivamente. Os resultados são apresentados na Figura 1 e comentados posteriormente.

Figura 1 - Como ocorre o aprendizado coletivo nas equipes de desenvolvimento
Fonte: Elaborada pelos autores

Nas ODSs o aprendizado coletivo acontece quando os membros da equipe compartilham os seus conhecimentos e experiências uns com os outros. De acordo com os desenvolvedores, essa atitude é fundamental para que todos os membros da equipe possam apresentar o mesmo nível de conhecimento, principalmente aqueles com pouca experiência. “Essa troca de conhecimento é para aperfeiçoar as outras pessoas [...] Até mesmo porque, aí, nesse caso, quem tem mais conhecimento, pode auxiliar, pode dar sugestões. E isso nivela o conhecimento da equipe toda” (DESENVOLVEDOR 2B).

Além disso, o compartilhamento de conhecimento é fundamental para que a empresa não dependa apenas de determinados funcionários para desenvolver o seu produto. “Quando você compartilha conhecimento com o grupo, todo mundo passa a ter aquele conhecimento e não fica na mão de uma pessoa. A empresa não fica refém de uma pessoa com aquele conhecimento” (DESENVOLVEDOR 1B).

Quando a equipe identifica que um de seus desenvolvedores adquiriu um conhecimento importante, solicita-se a sua exposição para os demais membros. “Quando alguém dá alguma sugestão de melhoria ou viu, achou alguma coisa, por exemplo na Internet, a gente pede para montar uma apresentação e discutir com o pessoal da equipe” (DESENVOLVEDOR 1A).

A estratégia utilizada para identificar se há no grupo de funcionários alguém apto para ministrar um treinamento, consiste em avaliar os dados obtidos pela ‘Matriz de Especializações por Pessoa’ ou ‘Quadro de Habilidades’, que mensura o nível de conhecimento dos funcionários em relação às competências e habilidades requeridas pelos projetos. ”Na atribuição de cada assunto, você tem cinco níveis de conhecimento. Vamos dizer, você é nível cinco em Java e você tem uma certificação. Então você se torna apta a dar um curso quando isso for necessário. Quer dizer, você já tem dentro da empresa pessoas que podem dar treinamento, em uma necessidade” (DESENVOLVEDOR 2D).

O aprendizado coletivo acontece durante as discussões que ocorrem nas reuniões formais agendadas para tratar sobre questões relacionadas aos projetos. O objetivo dessas reuniões é apresentar as atividades que deverão ser realizadas e colocar a equipe a par do andamento dos trabalhos de cada membro. Nesse momento, os desenvolvedores expõem os métodos utilizados para realizar as suas tarefas e os problemas enfrentados, além de possuírem total liberdade para avaliar o trabalho realizado por seus pares e oferecer opiniões.

Constatou-se que o modelo scrum adotada pelas Organizações B, C e D, incentiva as discussões entre os membros da equipe de desenvolvimento ao propor certas reuniões formais durante o projeto. Trata-se de uma metodologia trata-se de uma metodologia que foi criada por Jeff Sutherland em 1993 e surgiu a partir de um estudo de Nonaka e Takeuchi (1986), no qual os autores afirmam que projetos pequenos apresentam melhores resultados quando são executados por equipes menores e multifuncionais.

A Daily Scrum, é uma rápida reunião diária que ocorre entre os membros do time para definir quais serão as tarefas do dia e saber os resultados das tarefas do dia anterior. Esta reunião é também chamada de Stand Up Meeting(reunião em pé) (CARVALHO;MELLO, 2009), modelo de reunião, frequentemente adotado pelas ODSs. “Como a gente tem que ter a maioria dessas reuniões de Daily Scrum, serve até para isso, para um saber o que o outro está fazendo e ver se pode ajudar e contribuir de alguma maneira. Então, rola um compartilhamento de ideias geral”. (DESENVOLVEDOR 1D).”Tem aquelas reuniões em pé, onde a gente discute com a equipe. Então, isso é interessante porque as pessoas colocam os seus problemas ali, os problemas que estão tendo, ali, no decorrer do seu trabalho, então você acaba conseguindo trocar ideia. Um já dá uma sugestão, o outro consegue complementar aquela informação” (DESENVOLVEDOR 2C).

Para atender as orientações do MpsBr quanto à disseminação das ‘Lições Aprendidas’, os problemas encontrados ao realizar uma tarefa e as soluções estabelecidas precisam ser compartilhados em uma reunião formal com a presença de todos os membros da equipe. “E, ao final do projeto, tem uma reunião final de encerramento onde são discutidos os problemas, os benefícios obtidos e lições aprendidas com os próprios projetos” (DESENVOLVEDOR 1C). O modelo Scrum também incentiva a discussão e o registro das ‘Lições Aprendidas’ durante o projeto. “Pelo MpsBr a gente tem uma reunião de lições aprendidas. E agora no Scrum, ao final da Sprint de desenvolvimento, a gente lista todas as lições aprendidas. O que a gente fez, o que a gente deixou de fazer e o que a gente pode melhorar na próxima” (DESENVOLVEDOR 2B).

Aprende-se também coletivamente, durante as discussões que ocorrem em reuniões informais. “Você tem as reuniões formais e tem essas discussões informais, também. Que eu acho até mais produtivas do que as formais. É, porque ali você está mais descontraído. Porque a reunião formal parece uma coisa  meio imposta. Aí, senta todo mundo lá, fica lendo documento, coisa e tal” (DESENVOLVEDOR 2C).

As ODSs utilizam tecnologias de informação e comunicação para favorecer a interação e o compartilhamento de conhecimentos e experiências entre os desenvolvedores.Os desenvolvedores aprendem coletivamente ao utilizar fóruns de discussão, ao utilizar Wikis que são sites totalmente editáveis, os quais os usuários podem ler conteúdos ou adicioná-los, ao interagir por meio de ferramentas de bate-papo, por texto ou voz e ao interagir por e-mail. “Então, nós temos uma wiki e fóruns de discussões. Os analistas alimentam esses fóruns de discussão” (DESENVOLVEDOR 1C). “A gente tem um e-mail interno da equipe, onde todo mundo manda as novidades para lá, a gente compartilha bem disso” (DESENVOLVEDOR 1D).

Identificou-se que as ODSs investigadas adotam o layout aberto, livre de divisórias e portas, onde os desenvolvedores sentam-se um ao lado do outro. Para os especialistas em software, esse layout facilita as discussões e consequentemente, contribui para a ocorrência do aprendizado coletivo: “É porque a equipe fica sentada bem junto. Como o espaço é aberto a gente costuma sentar um do lado do outro. Aí, fica fácil. Aí, é só levantar a cabeça e conversa com outro, conversa com o outro do lado. Então, isso incentiva mesmo a você estar conversando, trocando ideia” (DESENVOLVEDOR 2C).

Os desenvolvedores aprendem coletivamente ao compartilhar conhecimentos, uns com os outros, por meio de repositórios que armazenam o conhecimento gerado na ODS. Como exemplo, podemos citar o Subversion, que é um sistema de código livre e aberto para controle de versões e que gerencia arquivos e diretórios e as suas mudanças realizadas ao longo do tempo. O seu núcleo é reconhecido como ‘repositório’, onde são armazenados dados para serem compartilhados. Os indivíduos que possuem acesso a esse repositório podem ler, escrever nesses arquivos e compartilhar as informações cadastradas uns com os outros, por meio da intranet da empresa (Collins-Sussman e outros, 2007).

O Quadro 2 apresenta de forma sucinta as situações de aprendizagem coletiva identificadas em cada ODS:

Quadro 2 - Situações de aprendizagem coletiva identificadas nas ODS investigadas

Como os desenvolvedores de ODSs que implantaram o MPSBR aprendem coletivamente

Organização A

Organização B

Organização C

Organização D

 

- A predisposição para compartilhar conhecimento favorece o aprendizado coletivo

- Aprende-se durante as discussões que ocorrem nas reuniões

- Aprendizado entre equipes

- Compartilhamento de conhecimento por meio de tecnologias de informação e comunicação

- A estrutura física da organização facilita o compartilhamento de conhecimento

- Compartilhamento de conhecimento por meio de repositório de ativos

- A predisposição para compartilhar conhecimento favorece o aprendizado coletivo

- Aprende-se durante as discussões que ocorrem nas reuniões

- A estrutura física da organização facilita o compartilhamento de conhecimento

- Compartilhamento de conhecimento por meio de repositório de ativos

- A predisposição para compartilhar conhecimento favorece o aprendizado coletivo

- Aprende-se durante as discussões que ocorrem nas reuniões

- Aprendizado entre equipes

- Compartilhamento de conhecimento por meio de tecnologias de informação e comunicação

- A estrutura física da organização facilita o compartilhamento de conhecimento

- Compartilhamento de conhecimento por meio de repositório de ativos

- A predisposição para compartilhar conhecimento favorece o aprendizado coletivo

- Aprende-se durante as discussões que ocorrem nas reuniões

- Compartilhamento de conhecimento por meio de tecnologias de informação e comunicação

- A estrutura física da organização facilita o compartilhamento de conhecimento

- Compartilhamento de conhecimento por meio de repositório de ativos

Fonte: Elaborada pelos autores

5. Considerações Finais

Nas ODSs, o aprendizado coletivo ocorre quando os desenvolvedores apresentam predisposição para compartilhar os seus conhecimentos particulares. Essa predisposição existe, primeiramente, devido à necessidade de igualar o conhecimento da equipe, já que a atividade de desenvolvimento de software é um trabalho que precisa ser realizado em grupo, devido à interdependência de tarefas. Logo, o compartilhamento de conhecimento é fundamental para que a equipe possa apresentar um desempenho satisfatório nos projetos.

De acordo com Dixon (1997; 1999), os indivíduos constroem significados particulares que se tornam acessíveis quando são compartilhados com os demais membros do grupo. Nesse momento, a equipe avalia o raciocínio e a lógica desses significados aceitando-os como válidos ou não. Quando o significado particular não é aceito, ele é reconstruído pela equipe com o intuito de gerar melhores ideias e ações mais eficazes. Após essa reflexão em conjunto, desenvolve-se um significado coletivo, comum para todos. Na organização, o significado coletivo refere-se ao conhecimento que determina como o trabalho deve ser realizado.

Portanto, para que a aprendizagem coletiva possa ocorrer, é necessário que os significados particulares dos membros da equipe tornem-se acessíveis para que um significado coletivo seja construído.

Li e outros (2010) afirma que o aprendizado coletivo torna as equipes proativas e reativas para lidar com as mudanças ambientais. Quando se aprende coletivamente, o grupo desenvolve uma inteligência coletiva, que possibilita aos seus membros compreender a dinâmica das mudanças do ambiente organizacional, articular uma visão única e clara sobre os projetos e descobrir processos mais eficazes para o desenvolvimento de produtos/serviços (Akgun e outros, 2004)

Quando a equipe identifica que um de seus desenvolvedores adquiriu um conhecimento importante, solicita-se a sua exposição para os demais. Verificou-se, ainda, que a equipe faz uso do compartilhamento de conhecimento para capacitar o grupo. Ao constatar que é preciso desenvolver uma habilidade, primeiramente investiga-se, por meio dos dados da ‘Matriz de Especializações por Pessoas’, se há na empresa um funcionário apto para ministrar um treinamento, caso contrário, um dos seus membros busca por esse conhecimento em uma fonte externa para, posteriormente, compartilhá-lo com os demais.

Aprende-se durante as discussões que ocorrem nas reuniões formais e informais. De acordo com Edmondson (2002), o aprendizado em equipe é interrompido quando os grupos não conseguem refletir sobre as suas próprias ações, ou quando refletem, mas não conseguem implementar as alterações provenientes da reflexão.

Tal situação pode ocorrer devido a três motivos. Primeiro, porque a reflexão no nível do grupo é um processo de discussão e, se as equipes estiverem atarefadas ou acostumadas à rotina, a discussão reflexiva pode não ocorrer. Em segundo, a discussão no grupo pode se mostrar ineficaz quando ignora-se informações relevantes, quando a discussão não envolve todos os membros, ou quando a discussão é considerada inadequada pelos líderes da equipe. Em terceiro, as equipes podem refletir – bem ou mal –, mas não implementar as mudanças necessárias em suas atividades devido a certas limitações, como: incapacidade de romper com as rotinas, falta de motivação; ausência de recursos necessários (Edmondson, 2002).

Dixon (1997; 1999) apresenta as discussões como facilitadoras do aprendizado coletivo. De acordo com a autora, a aprendizagem coletiva ocorre em um espaço projetado para facilitar conversas profundas entre os membros da organização, sobre assuntos que lhes interessam. Nesses espaços, os indivíduos interagem por meio da troca de dados, por meio do compartilhamento de conclusões e raciocínios. As pessoas dialogam entre si em vez de apenas expor ideias, umas para as outras.

Constatou-se que nas reuniões formais os desenvolvedores apresentam os métodos utilizados para realizar as tarefas, os problemas enfrentados, além de possuírem total liberdade para avaliar o trabalho realizado pelos seus pares e apresentarem sugestões. Geralmente, o conhecimento gerado nessas reuniões é explicitado em um documento para ser compartilhado com os membros da equipe e com outros grupos de desenvolvimento. Por isso, na percepção de alguns desenvolvedores, o aprendizado coletivo ocorre nesse tipo de reunião, pois, nas informais, pode-se não perceber e registrar o conhecimento gerado para ser compartilhado e institucionalizado.

Entretanto, Dixon (1997; 1999) discorda desse cenário ao alegar que a aprendizagem coletiva ocorre em um espaço onde os membros conversam entre si como iguais, sem pressões provenientes de uma estrutura hierárquica. A autora refere-se a esses espaços como ‘corredores’, termo análogo aos ‘corredores de uma organização’, justamente para ressaltar que o aprendizado coletivo acontece, principalmente, durante as discussões informais.

Confirmando essa proposição, outros desenvolvedores afirmam que o aprendizado coletivo também ocorre nas reuniões informais. Além disso, segundo esses especialistas, os projetos exigem conversas informais frequentes, devido à interdependência das tarefas. As discussões informais são importantes para que os problemas sejam resolvidos imediatamente, não comprometendo o cronograma do projeto e para que os detalhes referentes a eles não sejam esquecidos com o passar do tempo.

Acrescenta-se que o modelo Scrum também incentiva as discussões formais e informais entre os membros da equipe de desenvolvimento. O modelo determina que certas reuniões formais precisam acontecer durante o projeto, como a Product backlog, a Daily Scrum e a Sprint Planning Meeting. Além disso, no Scrum as equipes precisam se autogerenciar, ou seja, serem capazes de resolver problemas e implementar requisitos sozinhas, situação que requer conversas informais frequentes (Carvalho; Mello, 2009).

As discussões informais podem ocorrer dentro ou fora do ambiente de trabalho. Nas ODSs que adotam o modelo Scrum, muitas dessas discussões acontecem no local onde se encontra o quadro de tarefas que fornece uma visão geral do andamento do projeto. É importante destacar que todas as empresas investigadas possuem salas de reuniões que podem ser utilizadas para esse tipo de discussão.

Segundo Dixon (1997; 1999), o aprendizado coletivo é extremamente favorecido quando os membros da equipe apresentam os seus pontos de vista, possibilitando ao grupo avaliar múltiplas perspectivas. São as diferenças que promovem o aprendizado, pois somente se aprende quando há uma discrepância entre o pensamento do indivíduo com um evento ou dado que o questiona. Quanto maior for o número de perspectivas apresentadas durante as discussões, maior será a probabilidade de desenvolver uma solução eficaz.

Dixon (1997; 1999) complementa que, ao promover a apresentação de múltiplas perspectivas, oferece-se ao coletivo a possibilidade de explicitar suposições tácitas que eram, até o momento, desconhecidas. Uma vez explicitadas, essas suposições são discutidas publicamente e sua acurácia debatida. As suposições que se tornaram ultrapassadas ou desvantajosas são descartadas e aquelas que ainda servem ao interesse comum, mantidas.

Aprende-se ao utilizar tecnologias de informação e comunicação que permitem a interação e o compartilhamento de conhecimento entre os desenvolvedores como: fóruns de discussão; wikis; ferramentas de bate-papo por texto ou por voz, e-mail; telefone. Ao utilizarem, essas tecnologias os especialistas em software podem compartilhar as suas ideias e experiências, uns com os outros, o que contribui para a instituição de um significado coletivo (Dixon, 1997; 1999).

A estrutura física das ODSs facilita o compartilhamento de conhecimento.  O layout aberto, livre de divisórias e portas, onde os desenvolvedores sentam um ao lado do outro, facilita as discussões durante o trabalho.Em algumas empresas, existe ainda um quadro branco na sala de trabalho para que os desenvolvedores possam desenvolver e apresentar esquemas que representem as suas ideias, para a equipe. Na Organização B, há uma sala denominada ‘Sala da Criatividade’. Esse local é destinado para momentos de descanso, recreação e reuniões informais. A Organização D também possui uma sala que apresenta um ambiente semelhante. Acredita-se que o clima de descontração e informalidade presente nesses locais facilita as discussões e a exposição de ideias (Dixon, 1997; 1999).

Aprende-se ao compartilhar conhecimento por meio de repositórios de ativos. Esses repositórios podem ser comparados a um Sistema de Memória Transacional (SMT), que se desenvolve em equipes que executam tarefas interdependentes, quando os seus membros interagem e discutem entre si, para abstrair e reter o conhecimento sobre as habilidades uns dos outros. Por meio dessa interação, cria-se um conhecimento coletivo que será armazenado no SMT o qual estará interconectado com todos os membros do grupo para que os indivíduos saibam, exatamente, ‘quem sabe o que’ e ‘quem pode fazer o que’. Assim, o grupo saberá quais indivíduos deverão agir em determinadas situações, além de melhor coordenar a realização das tarefas (Edmondson e outros, 2007; Kozlowski; Bell, 2008).

O SMT possibilita também, aos desenvolvedores, fornecerem feedback uns aos outros. Ao conhecer os comportamentos eficazes e ineficazes, podem-se enviar alertas quando uma tarefa não está sendo executada da maneira correta (Ellis e outros, 2008).

Day (1994) acrescenta, que o SMT possibilita selecionar ou rejeitar informações que não são válidas para o trabalho e estabelecer suposições sobre como o ambiente responderá a certas ações com base no conhecimento armazenado.

Identificou-se que o MPSBR contribui para o desenvolvimento dos SMTs ao determinar que o conhecimento adquirido durante os projetos e o conhecimento relacionado ao processo padrão seja armazenado em um repositório para que todos os desenvolvedores possam ter acesso a eles.

Os principais documentos que contribuem para o entendimento das equipes sobre ‘quem sabe o que’ e ‘quem pode fazer o que’ são os descritos do processo padrão e o mapeamento das atribuições de cada função. Os repositórios de ativos contribuem para o compartilhamento de conhecimento relacionado às funções dos desenvolvedores, o que permite à equipe estabelecer soluções eficazes em um curto espaço de tempo. Além disso, o armazenamento e compartilhamento do conhecimento gerado em projetos anteriores evita a recorrência de erros bem como possibilita o reaproveitamento dos melhores métodos, utilizados no passado.

Quanto às limitações deste estudo, não se pode generalizar os dados adquiridos para outras ODSs, pois este trabalho utilizou como método de coleta de dados apenas a entrevista semi-estruturada, pois as empresas investigadas não autorizaram a observação e a analise documental.

Segundo Yin (2006), a coleta de dados em múltiplas fontes – triangulação – possibilita o estabelecimento de conclusões convincentes e acuradas. A triangulação utilizada com frequência nos estudos de caso inclui: (1) entrevistas; (2) observação, (3) análise documental.

Portanto, é preciso fazer uso de outros métodos de coleta de dados com o intuito de realizar uma triangulação. De acordo com Kelle (2001), a triangulação de dados é a validação mútua dos métodos e resultados obtidos na investigação, a fim de identificar riscos de validade. É utilizada para produzir a imagem mais completa sobre o fenômeno investigado por meio da convergência de resultados utilizando diferentes métodos.

Referências

AKGUN, A; LYNN, G.; YILMAZ, C. Learning process in new product development teams and effects on product success: A socio-cognitive perspective. Industrial Marketing Management, v. 35, n. 2, p. 210-224, 2006.

ALBERTIN, A. L. Comércio Eletrônico Modelo, Aspectos e Contribuições de sua Aplicação. São Paulo: Atlas, 2000.

BERG, B.L. Qualitative Research Methods for the social sciences. California: Allyn & Bacon, 2001.

CARVALHO, B. V.; MELLO, C. H. P. Revisão, análise e classificação da literatura sobre o método de desenvolvimento de produtos ágil scrum. Anais. XII Simpósio de Administração da Produção, Logística e Operações Internacionais - SIMPOI, São Paulo, 2009.

COLLINS-SUSSMAN, B.; FITZPATRICK, B. W.; PILATO, C. M.. Version Control with Subversion. For Subversion 1.4. Califórnia, EUA: O'Reilly Media, 2007.

COUTO, A. B. CMMI: integração dos modelos de capacitação e maturidade de sistemas. Rio de Janeiro: Ciência Moderna, 2007.

DAY, G. S. Continuous Learning About Markets. California Management Review. v. 36, n.4, p. 9-31, 1994.

DIXON, N. The hallways of learning. Organizational Dynamics, v. 25, n. 4, p. 23-34, 1997.

_________. The organizational learning cycle. How can we learn collectively. 2. ed. London: McGraw-Hill Book Company, 1999.

EDMONDSON, A. C. The Local and Variegated Nature of Learning in Organizations: A Group-Level Perspective. Learning, v. 13, n. 2, p. 128-146, 2002.

ELLIS, A.P.J.; PORTER, C.O.L.H.; WOLVERTON, S.A. Learning to Work Together: An Examination of Transactive Memory System Development in Teams. In SESSA, V. I.; LONDON, M (org). Work group learning: understanding improving & assessing how groups learn in organizations. New York: Taylor & Francis Group, 2008.

GIBBS, G. Análise de Dados Qualitativos. Porto Alegre: Artmed, 2009.

GODOY, A. S. A pesquisa qualitativa: tipos fundamentais. Revista de Administração de Empresas. São Paulo, v. 35, n. 3, p. 20-29, maio/jun.1995.

KELLE, U. Forum: Qualitative Social Research Sozialforschung Sociological Explanations between Micro and Macro and the Integration of Qualitative and Quantitative Methods. Forum Qualitative Sozialforschung, v. 2, n. 1, 2001.

KOZLOWSKI; S.W.J.; BELL,B.S. Team Learning, Development, and Adaptation. In SESSA, V. I.; LONDON, M (org). Work group learning: understanding improving & assessing how groups learn in organizations. New York: Lawrence Erlbaum Associates. New York: Taylor & Francis Group, 2008.

LI, Y.; CHANG, K.-C.; CHEN, H.-G.; JIANG, J. J. Software development team flexibility antecedents. Journal of Systems and Software, v. 83, n. 10, p. 1726-1734, 2010.

NONAKA, I; TAKEUCHI, H. The New New Product Development Game. Harvard Business Review, 1986.

RAMASUBBU, N.; MITHAS, S.; KEMERER, C.F. Work dispersion, Process-based learning, and offshore software development performance. MIS Quarterly, v. 32, n, 2, p. 437-458, 2008.

TONINI, A. C.; CARVALHO, M. M.; SPINOLA, M. M. Contribuição dos modelos de qualidade e maturidade na melhoria dos processos de software. Produção, v. 18, n. 2, p. 275-286, 2008.

YIN, Robert K. Estudo de caso, planejamento e métodos. São Paulo: Bookman, 2006.

 


1. Letícia Rodrigues da FONSECA (Unidade de Educação a Distância/Centro Universitário do Sul de Minas - EaD/UNIS) - leticia@unis.edu.br
2. Marcelo Ribeiro SILVA (Programa de Pós-Graduação/Mestrado em Administração/Universidade Federal de Mato Grosso do Sul - UFMS) - profmarceloufms@hotmail.com
3. Roger Antonio RODRIGUES (Unidade de Educação a Distância/Centro Universitário do Sul de Minas - EaD/UNIS) - roger.rodrigues@unis.edu.br

4. Guilherme Augusto Dionisío VIVALDI (Unidade de Educação a Distância/Centro Universitário do Sul de Minas - EaD/UNIS) - guilherme.vivaldi@unis.edu.br

5. Armando Belato PEREIRA (Unidade de Educação a Distância/Centro Universitário do Sul de Minas - EaD/UNIS) - armando.pereira@unis.edu.br

6. Guilherme Marques PEREIRA (Universidade Vale do Sapucaí- UNIVAS) - guilherme.marques@bol.com.br


Revista Espacios. ISSN 0798 1015
Vol. 37 (Nº 34) Año 2016

[Índice]
[En caso de encontrar algún error en este website favor enviar email a webmaster]