DOI: 10.13037/gr.vol36n107.5385

Comunicação em Projetos de Desenvolvimento Global de Software: A Visão dos Praticantes

COMMUNICATION IN GLOBAL SOFTWARE DEVELOPMENT PROJECTS: THE VISION OF THE PRACTITIONERS

Voltar ao Sumário

Azriel Majdenbaum¹

ORCID: http://orcid.org/0000-0002-3171-4933 

Marcirio Chaves²

ORCID: http://orcid.org/0000-0002-3171-4933 

^{1, 2}(Pontifícia Universidade Católica do Rio Grande do Sul)

Resumo

A distribuição no desenvolvimento de software está se tornando cada vez mais comum para economizar o custo de produção e reduzir o tempo de lançamento no mercado. Distância geográfica, diferentes fusos horários e diferenças culturais no desenvolvimento global de software (DGS) levam a uma comunicação fraca que afeta negativamente o projeto. É crítico buscar por melhores práticas em gestão da comunicação para melhorar a efetividade desses empreendimentos. O artigo explora a visão de gestores de projetos seniores sobre a comunicação em DGS. Dentre os resultados destaca-se a popularidade de WhatsApp e Slack em DSG e os gestores de projetos demonstrando estarem voltados a processos utilizando frameworks de gestão da comunicação presentes na literatura. Este artigo apresenta duas contribuições: 1. um modelo conceitual para avaliar a utilização de comunicação passiva; 2.  um conjunto de boas práticas representadas por ações, comportamentos e ferramentas de tecnologia da informação e comunicação para contribuir com o sucesso desses projetos. 

Palavras-chave: Desenvolvimento global de software. Comunicação em projetos. Gestão de projetos. Equipes virtuais.

Abstract

Distribution in software development is becoming increasingly common to save on production costs and reduce time to market. Geographic distance, different time zones, and cultural differences in global software development (GSD) lead to poor communication that negatively affects the project. It is critical to seek best practices in communication management to improve the effectiveness of these endeavors. The article explores the vision of senior project managers on communication in GSD. Among the results, we highlight the popularity of WhatsApp and Slack in GSD and the project managers demonstrating that they are process-oriented using communication management frameworks available in the literature. This article presents two contributions: 1. a conceptual model to evaluate the use of passive communication; 2. a set of good practices represented by actions, behaviors and tools of information technology and communication to contribute to the success of these projects.

Keywords: Global software development. Communication in projects. Project management. Virtual teams.

O software se tornou um componente estratégico para diversas áreas de negócio, tornando clara a necessidade do uso da Tecnologia da Informação e Comunicação (TIC) como diferencial competitivo (Herbsleb et al., 2001). Às vezes, a busca de vantagem competitiva obriga as organizações a procurarem soluções em outros países, distribuindo seus processos de desenvolvimento de software ao redor do mundo, visando ganhos de produtividade, redução de custos e melhorias na qualidade. Essa abordagem é chamada de Desenvolvimento Global de Software (DGS) (Jan et al., 2016).

Para muitas empresas, gerenciar projetos de DGS é a chave para o sucesso no atual ambiente competitivo (Ebert; KUHRMANN; PRIKLADNICKI, 2016). O projeto é desenvolvido em um ambiente multi-site, multicultural e globalmente distribuído. Engenheiros, gerentes e executivos enfrentam mudanças em muitos níveis, desde o técnico até o social e cultural (HendersoN; STACKMAN; LINDEKILDE, 2016; Shrivastava, 2010), afetando a forma como o software é projetado, desenvolvido e entregue ao cliente. No entanto, tais projetos são notórios por falhas e a gestão de equipes globalmente distribuídas representa desafios adicionais únicos, principalmente em relação à comunicação.

A distância geográfica, os diferentes fusos horários e as diferenças culturais no DGS levam a desafios à comunicação que podem afetar negativamente o projeto. Muitas organizações realizam suas tarefas usando a abordagem baseada em projetos, que inclui uma série de áreas (Kerzner, 2013) onde se destaca o gerenciamento da comunicação, devido a seu impacto no sucesso do projeto (Papke-Shields; beise; quan, 2010). A comunicação inadequada ou deficiente historicamente está entre as principais causas de falha em projetos observadas na literatura (Dwivedi et al., 2015; Klaus; Blanton, 2010; Kappelman; mckeeman; zhang, 2006; May, 1998). 

Dada a importância do gerenciamento eficaz de projetos de DGS, esta pesquisa procura entender quais são suas melhores práticas para superar as dificuldades de comunicação nesse ambiente por meio da experiência de gerentes de projeto (GP) seniores. O artigo explora a visão dos GP em relação às práticas de comunicação direta, passiva e sobre o uso de ferramentas de comunicação. Além de um conjunto de boas práticas em termos de ações, comportamentos e ferramentas de comunicação utilizadas em eventos de desenvolvimento de software, esta pesquisa apresenta um modelo que permite avaliar a adoção da prática de comunicação passiva em projetos de DSG.

2.1  Distribuição em Projetos de Software

O DGS caracteriza-se pela distância física e/ou temporal entre alguns elementos como cliente, usuário e desenvolvedores envolvidos no processo de desenvolvimento (Audy; Prikladnicki, 2007). Um determinado cenário de dispersão global pode ser bem diferente de um cenário de dispersão local. O entendimento dos níveis de dispersão pode ajudar a identificar possíveis fontes de dificuldades na distribuição física de equipes envolvidas nos projetos. Quando a distância entre colaboradores distribuídos atinge 30 metros ou mais, a frequência de comunicação diminui para um nível idêntico ao de colaboradores que estão distribuídos a milhares de metros (Herbsleb et al., 2001).

Pode-se dizer que a caracterização de um ambiente de Desenvolvimento Distribuído de Software ocorre sempre que pelo menos um stakeholder genérico estiver fisicamente distante dos demais (Audy; Prikladnicki, 2007). Em um cenário ilustrativo para observar o grau de dispersão, a equipe de desenvolvimento poderia estar distribuída globalmente, tendo seus membros em países de diversos continentes como, por exemplo, parte da equipe no Brasil, parte na Índia e parte nos Estados Unidos. Os clientes e os usuários poderiam estar localizados no mesmo país, por exemplo, os Estados Unidos, porém distantes fisicamente entre si. Neste exemplo, a equipe de desenvolvimento também poderia estar globalmente distante dos usuários e dos clientes.

Podemos ampliar a visão de distribuição de um dos stakeholders, dividindo-os em mais de um grupo. Assim, podemos dividir a equipe de desenvolvimento entre equipe de especificação, localizada nos Estados Unidos e equipe de desenvolvimento, dispersa entre Brasil e Índia, por exemplo. Existem várias configurações possíveis de dispersão que podem trazer diferentes consequências para a complexidade da comunicação nos projetos.

2.2  Comunicação em Projetos DGS

Projetos globais podem usar diferenças de fuso horário para aumentar o número de horas de trabalho produtivo em um dia, e garantir recursos escassos, como especialistas em conhecimento e outros recursos especializados, independentemente de onde eles residam (Nidiffer; Dolan, 2005). Projetos globais também podem empregar mais pessoas, pois não há restrições de espaço. No entanto, Nidiffer e Dolan alertam que esses benefícios vêm com riscos aumentados devido à falta de interação face a face, o que pode resultar em falta de confiança e comunicação ineficaz, levando à dificuldade de cooperação.

O desenvolvimento de software é um processo colaborativo e intensivo em conhecimento que requer a mistura e o entrelaçamento de diversos conhecimentos dispersos por domínios de especialização (Robillard,1999). As características únicas e inerentes do desenvolvimento de software expressam a importância do compartilhamento efetivo do conhecimento, referindo-se à troca de informações relacionadas a tarefas, ideias, know-how e feedback sobre produtos e processos de software, explorando os recursos disponíveis, abordando desafios e explorando oportunidades emergentes no desenvolvimento e design de software (Ghobadi, 2015). 

Os desafios do desenvolvimento distribuído de software relacionados à comunicação são discutidos por Audy e Prikladnicki (2007). Um projeto desenvolvido nesse ambiente acaba ocultando informações que em projetos tradicionais estariam presentes no próprio ambiente de uma equipe de trabalho. Segundo o autor, no desenvolvimento de software é importante que se tenha consciência do que está acontecendo, quem está realizando determinada tarefa, onde ela está acontecendo e os participantes precisam saber os resultados uns dos outros para ampliar a colaboração. Quando uma informação nova surge e o responsável pela informação não sabe quem precisa ser informado a respeito, pode não informar ninguém ou enviar a informação para pessoas desnecessárias, podendo gerar conflitos. 

O compartilhamento de contexto também aparece como um desafio à comunicação conforme Audy e Prikladnicki (2007, p. 78) exemplificaram:

[...] para um cenário onde a equipe está distribuída, nem sempre sabemos, por exemplo, quando será feriado nos países onde estão os outros integrantes da equipe. Ou, ainda, nem sempre sabemos exatamente a diferença de fuso horário existente ou qual é o melhor horário para encontrar determinada pessoa.

Nesse contexto, a comunicação pode ser entendida como o grau em que os diferentes grupos de stakeholders criam e compartilham informações efetivamente durante o projeto de desenvolvimento.

2.3  Ferramentas de Comunicação

A aceleração da inovação em tecnologia da informação e as mudanças no mundo corporativo (Attaran; Attaran, 2002) tornaram o trabalho em conjunto, em equipes virtuais, uma mudança natural na forma como as organizações funcionam (Nystrom; Asproth, 2013), trazendo desafios ainda maiores à comunicação. Dessa forma, cada vez mais as Tecnologias de Informação e Comunicação (TIC) são necessárias para suportar as necessidades de comunicação e colaboração dos times de projeto.

As opções de mídia dos membros das equipes refletem sua abordagem de trabalho e influenciam a dinâmica e os resultados do grupo (Timmerman; Scott, 2006). Enquanto a Internet e o e-mail foram os principais meios de comunicação entre essas equipes, novas tecnologias e aplicações surgem constantemente e apresentam oportunidades para aperfeiçoar a gerência de projetos. Nos últimos anos surgiram ferramentas de comunicação mais interativas como as mídias sociais, que são largamente usadas para propósitos pessoais (Rimkuniene; Zinkeviciute, 2014), porém pouco estudadas em sua capacidade de promover maior colaboração entre os times de projeto (mAJDENBAUM; CHAVES, 2018).

Esta pesquisa qualitativa e exploratória utilizou a técnica de entrevista para melhor compreender o fenômeno de como gestores de projeto (GP) seniores percebem a comunicação em projetos de DGS. Para sua realização foi elaborado um roteiro de entrevistas, baseado na literatura de gestão de projetos, que serviu de guia para as entrevistas semiestruturadas. Vinte entrevistas foram realizadas durante seis meses (ver Quadro 1) totalizando treze horas e dezenove minutos de gravação e gerando 190 páginas de texto transcritas.

Quadro 1 - Caracterização dos entrevistados. GP significa Gestão de Projetos neste quadro.

Fonte: Dados do estudo

O estudo empírico foi uma investigação com 20 GPs que desenvolvem software para diferentes indústrias (agrícola, aviação, comunicação, consultoria, petróleo, serviço público e tecnologia). Os entrevistados têm mais de cinco anos de experiência em projetos dessa natureza e gerenciaram pelo menos um projeto com times geograficamente distribuídos. A maioria dos gestores já liderou projetos com orçamento acima de US$ 500,000.00 e possui treinamento sólido na área, apresentando assim um perfil aderente ao estudo.

A análise dos dados foi feita com base nas transcrições das entrevistas gravadas. Os autores selecionaram segmentos das transcrições que fornecem o exemplo mais claro da visão dos GP relacionado à comunicação direta, comunicação passiva e ferramentas utilizadas, ou o maior contraste nas diferentes visões. Esta abordagem tem sido usada por outros pesquisadores (Orlikowski, 1993; Wastell, 1999; Newell, 2006).

Nesta seção, trazemos exemplos de diferentes GPs para ilustrar as principais perspectivas que surgiram a partir da análise dos dados. 

4.1  Comunicação Direta

Quando questionados em relação aos eventos de comunicação utilizados nos projetos, os respondentes se referiram à realização de reuniões e emissão de relatórios de progresso do projeto. O R12 comenta sobre a relevância do relatório de progresso do projeto para a comunicação “quando a gente recebe comentários da equipe de projeto em relação ao status semanal do projeto, dizendo ‘olha, aquela afirmação lá não está bem correta’ ou ‘eu não tinha entendido que a gente estava prometendo isso para a semana que vem’ é uma forma de checar se o entendimento foi correto e propriamente documentado”.

O R1 salienta a importância do planejamento e do seu controle na gestão da comunicação: “as reuniões têm que estar sempre planejadas e o gerente de projetos não pode ficar desmarcando e marcando reunião... tu deixar marcado essas reuniões, tu comunicar teus stakeholders das reuniões”. Seguindo uma perspectiva distinta, o R7, que adota metodologia Ágil de desenvolvimento, não acredita em reuniões e prefere focar na informalidade da comunicação quando os times estão distribuídos em fusos horários semelhantes “Aqui nós odiamos reunião, então reunião nós não fazemos muito. Tem muita interação no Slack, o pessoal coloca uma dúvida ou um cara chama o outro no canal direto”. 

Ao perguntarmos sobre o principal objetivo da boa comunicação nos projetos o R1 explica “Boa comunicação é aquela em que ... todos os teus stakeholders estão claramente comunicados do que eles têm que fazer, quais são as responsabilidades, quais são os objetivos do projeto”. O R15 entende o objetivo da comunicação de maneira semelhante “que as pessoas estejam cientes, sabendo o que está acontecendo no projeto. Se você precisa também ter alguma ação com algum stakeholder... você saber levar essa informação”.

O R12, ao contrário, já tem um entendimento da comunicação como um diálogo construtivo “Não sei se enxergo a comunicação como um objetivo ou como um meio... a comunicação é uma questão de entendimento, em um sentido, do que precisa ser feito, no outro sentido, validando o que está sendo feito...”. O R8 entende de maneira semelhante “Fazer com que o time trabalhe de forma produtiva e com harmonia. O segredo é conseguir montar um time de projeto, ao invés de um grupo de profissionais alocados no projeto”.

Nós também perguntamos aos entrevistados quais eram suas boas práticas para a comunicação fluir bem ao longo do projeto. O Quadro2 resume as principais práticas mencionadas.

Quadro2 – Boas práticas de comunicação de acordo com os GPs seniores.

Fonte: Dados do estudo

As boas práticas mencionadas no Quadro2 referem-se tanto a características comportamentais dos GP em relação à comunicação, quanto a ações de comunicação relacionadas às fases de planejamento, execução e controle do projeto. As características comportamentais que emergiram foram transparência, assertividade e saber ouvir. Enquanto que o agendamento de eventos, a realização de reuniões de acompanhamento e a adaptação do plano de comunicação exemplificam algumas boas práticas de comunicação relacionadas às ações do GP.

4.2  Ferramentas de Comunicação

Quando perguntados sobre ferramentas utilizadas que auxiliam a gestão de projetos de DGS facilitando a comunicação, emergiram características destas como planejamento/rastreamento, comunicação, sincronização e gestão de configuração. Os rastreadores são usados para gerenciar problemas (ou "tickets"), como defeitos, mudanças ou pedidos de suporte. O R9 comenta sobre a utilização de Kanban “o Trello… organiza o dia a dia dos times... para dar visibilidade do que cada um está fazendo para o outro”. As funções de planejamento permitem criar histórias e problemas de usuários, planejar e distribuir tarefas. As ferramentas de gestão de projetos como Rally, Jira, TSVS e Access Soft emergiram das entrevistas. O R6 comenta sobre o Jira “... é usada todo o dia onde ficam registradas todas as user stories, todas as tarefas, a gente acompanha a estimativa de pontos das user stories, então essa é uma ferramenta que tem sido bastante usada ... mais para condução da execução do projeto mesmo”. 

Uma gama de tecnologias de comunicação, tanto síncronas quanto assíncronas, foram mencionadas nas entrevistas. Entre elas e-mail, agendamento, vídeo conferência, telefones, conference bridge, WebEx, Skype for business, wiki, Git, WhatsApp e Slack. 

O R1 comenta como utiliza essas ferramentas em conjunto para obter respostas mais rápidas “Mando e-mail ‘Olha, está acontecendo esse problema no objeto, e preciso de uma resposta rápida’. Eu dou em torno de 15 minutos e se ninguém respondeu eu mando WhatsApp para o grupo ‘Olha, estou com esse problema, o servidor caiu”. Se ninguém respondeu eu ligo para o líder técnico”. E o R9 elabora sobre a função atual do e-mail “eu acho que o e-mail é mais para uma formalidade, mais para deixar as outras pessoas informadas que aquilo foi realmente alinhado entre as partes. Ou para dar continuidade num trabalho em equipe distribuída...se tu não tem como fazer a comunicação síncrona funcionar, então tu acaba fazendo assíncrona para dar essa continuidade”. 

O R1 reforça a importância da disponibilidade de infraestrutura de comunicação em projetos com times distribuídos “Tu tens que ter aparelhos de videoconferência, tu tens que ter telefones em que tu possas se comunicar”. E o R3 comenta sobre a importância de videoconferência “uma coisa que tem muito benefício para a aproximação é a videoconferência. Não há dúvidas de que isso diminui a distância”. O R15 relata sobre a diminuição do uso de conference bridges “Outra ferramenta que eu uso também são aquelas conference bridge com o 0800 e manda um passcode e as pessoas podem entrar em conferência. A gente utiliza isso, mas com a chegada do Skype for Business a gente utiliza cada vez menos. Eu ainda tenho minha bridge para algumas situações, mas a gente utiliza muito pouco hoje em dia”. 

O uso de ferramentas de comunicação em grupo também foi mencionado. O R12 descreve o uso do WebEx “permite conferência de voz de todo mundo...compartilhar tela... eu posso estar falando com um grupo de pessoas de locais diferentes, compartilhando a minha tela para mostrar o que eu estou fazendo, passar o controle para outra pessoa, essa pessoa vai mostrar a tela dela... Permite que cada um tenha imagem... use sua câmera para mostrar seu rosto... É o que nós mais usamos...”. Enquanto que o R15 relata a utilização do Skype for Business “Diariamente eu faço ligações com pessoas distribuídas geograficamente e eu sempre brinco ‘eu vou ligar a câmera para você ver o escritório e matar a saudade’. E as pessoas fazem a mesma coisa no lugar em que elas estão”.

O R11 salienta a funcionalidade de colaboração da Wiki “é uma questão colaborativa. Qualquer um vai ali e edita, atualiza um documento, ou alguma questão específica de projeto do dia a dia”. A utilização do Git para a gestão de configuração foi descrita pelo R4 “a documentação técnica deixamos no próprio Git. Coisas relativas a componentes de desenvolvimento deixamos no Git”. 

O benefício em utilizar o WhatsApp para comunicações informais foi lembrado pelo R11 “para cliente informal, para aproximar as pessoas, tu poder ter liberdade de falar sobre diversos assuntos, não só o projeto”. O R4 enaltece sua interatividade “Tu pode saber se a pessoa leu a mensagem. Se ela não respondeu, tu podes insistir na pergunta”. Enquanto o R1 comenta sobre a rapidez no retorno das mensagens “eu acho que a comunicação que mais chega é a comunicação WhatsApp. Tu podes mandar um e-mail e se a pessoa não te responde tu podes chamá-la no Whats e dizer “Olha, está acontecendo isso e eu preciso resolver”. 

O Slack também tem sido largamente adotado. O R4 relata sua utilização “o canal oficial de comunicação era o Slack. Nós esquecemos o e-mail... Só olhávamos o Slack, no celular ou no computador. Se precisássemos subir um documento, usávamos o Slack... é possível linkar a ferramenta com um sistema de repositório tipo Git”. O R6 salienta sua importância para a comunicação ao mover códigos para o ambiente de produção “no dia do deploy...todos os times ficam conectados no Slack e compartilham informações durante o andamento do deploy”. O R7 defende sua validade para o compartilhamento de documentos “o Slack tem funcionado superbem para compartilhar documentos e esse tipo de coisa”. O R19 reflete sobre o gerenciamento das ferramentas de comunicação “O problema não é a disponibilidade de ferramentas, mas, como tu organiza a utilização...quem está no canal ou grupo”. O Quadro 3 resume as ferramentas de TIC destinadas a cada evento de comunicação pelos GP.

Quadro3 - Eventos x Ferramentas de Tecnologia da Informação e Comunicação

Fonte: Dados da pesquisa

Os GP consideram que boas práticas de comunicação passam por ações que levem a uma efetiva comunicação tanto nas fases de planejamento quanto de execução do projeto. O conjunto acima de ferramentas de TIC que suportam eventos chave no desenvolvimento de software (Quadro 3) emergiram como facilitadores para a boa comunicação.

4.3       Comunicação Passiva

Quando questionados sobre a utilização de comunicação passiva na equipe de projetos como materiais de treinamento, documentos de código fonte, documentos de teste, entre outros, os respondentes se referiram principalmente à criação, armazenamento e benefícios do uso do conhecimento. As palavras que aparecem sublinhadas originaram a composição do modelo.

O R12 comenta sobre a necessidade de educação constante para o uso do conhecimento armazenado: “Eu acho ela (a comunicação passiva) muito importante, só que ela por si só não resolve nada...todo mundo sabe para quem perguntar a questão, ao invés de abrir a documentação... uma boa parte do que eu faço é educar as pessoas em relação a como elas podem obter essa informação... quando eu recebo...uma pergunta... normalmente eu devolvo um link para o documento... e ponho uma interpretação minha para ajudar. Eu respondo à pergunta e digo ‘Para futuras questões, futuras dúvidas que se possa ter, tem essa documentação que pode ser consultada’”.

O R9 considera que o baixo uso do conhecimento armazenado se deve à cultura das empresas: “é pouco utilizado, tem muita oportunidade nisto, mas é algo cultural, que é muito mais fácil eu perguntar para alguém do que ir buscar a informação na comunicação passiva”.

O R1 referencia a Wiki como repositório para armazenamento das informações do projeto “treinamento, todas as atas de reunião... tinha tudo do projeto. Quem participava, qual era o objetivo, centralizado na Wiki”.

O R11 avalia a qualidade da documentação passiva em relação à curva de aprendizado de novos integrantes no time de desenvolvimento “eu avalio se a documentação passiva é boa... se uma pessoa... que vai se integrar ao time... vai conseguir identificar como o projeto é... como eu resolvo os problemas, como eu faço o setup de ambiente... onde estão os documentos de especificação... se eu preciso entender um pouco mais sobre uma determinada regra, se eu encontro isso dentro da documentação”.

O R16 não acredita na relevância do armazenamento de conhecimento do projeto para posterior utilização em relação ao seu custo-benefício. Ao contrário do R15, que acredita nos seus benefícios.

R16: “acho que o dia a dia das pessoas...é tão “puxado”, que deixar um material pronto, assim...as pessoas não usam. Sinceramente, acho que é dinheiro jogado fora”.

R15: “eu acho que é importante para comunicar o que foi feito no projeto, documentar o que foi treinado, quando tem treinamento, quem participou... é um respaldo do próprio projeto”.

O R14 estima que poucas pessoas realmente usem o conhecimento armazenado, porém considera o armazenamento relevante para a evolução do produto “é um percentual muito pequeno de pessoas que acessam... o uso é baixo, mas eu acho necessário ter esse conhecimento até para outros projetos quando tu evoluíres o produto tu teres essa base de conhecimento”.

O R6 justifica a falta de prioridade na geração de documentação em relação às entregas do projeto. Porém, reconhece o impacto da falta de documentação na curva de aprendizado do time e na evolução do produto “Têm situações onde o time desprioriza essa questão da comunicação passiva em detrimento de entregas... isso prejudica ao longo prazo o próprio time na medida em que a gente tem... entrada de novos membros no time, ou a gente precisa até resgatar definições que foram feitas no passado e poder discuti-las... eu acho que o maior impacto de não ter... documentos e material de treinamento é ao longo do tempo porque a gente vai acabar tendo que reduzir bastantes entregas futuras por não termos um suporte de comunicação documentada”.

O R3 mantém o conhecimento técnico distribuído nas ferramentas utilizadas durante a construção do software “temos na criação do produto diagramas de arquitetura... documentação do código-fonte muitas vezes está junto ao diagrama nas ferramentas. A documentação de teste está na própria ferramenta de teste que é utilizada. Então, usa-se um Jira com plug-in de teste, tudo já está documentado ali”.

O R4 também utiliza o conhecimento técnico distribuído nas ferramentas de desenvolvimento do software “para a documentação técnica deixamos no próprio Git. Coisas relativas a componentes de desenvolvimento deixamos no Git”.

O R7 reconhece a importância da documentação nas próprias ferramentas de desenvolvimento de software, não centralizadas em repositórios únicos do projeto “as ferramentas hoje já disponibilizam uma série de funcionalidades que fazem isso... códigos já fazem a documentação do código, teste é automatizado, então é o código também ... existem ferramentas onde histórias são construídas...tudo que está sendo feito tem trilha de acompanhamento...Nós temos ferramentas de acompanhamento de projetos para ver como os itens estão sendo desenvolvidos no backlog... Não é que não existe documentação, é só que ela não é tão estruturada como era antigamente, mas está lá na ferramenta, tem a informação, o pessoal tem que documentar”. A Figura 1 apresenta um modelo conceitual sobre a comunicação passiva em projetos DGS. 

Figura 1 – Modelo conceitual para comunicação passiva.

Fonte: os autores

O modelo conceitual para comunicação passiva apresentado na Figura 1 está dividido em criação, armazenamento, uso e benefícios da prática da comunicação passiva em projetos de DGS. Foram levantadas duas condições para que haja a criação de comunicação passiva nos projetos. A primeira condição é a priorização da alocação dos membros do time para a criação dos artefatos que serão armazenados. A existência de uma cultura organizacional que valorize a documentação é outra condição para a existência da prática.

O armazenamento das informações pode ser centralizado ou distribuído. As informações que costumam ficar centralizadas em ferramentas como uma Wiki ou pubshare, por exemplo, são relativas à descrição do projeto, suas regras de negócio, os treinamentos realizados e informações da configuração do ambiente. As informações relativas a artefatos técnicos que foram criados para a execução dos projetos, como userstories, diagramas, testes e códigos, costumam ficar documentadas de maneira distribuída, nas ferramentas em que os artefatos foram gerados.

O modelo mostra as condições para que haja um efetivo uso das informações comunicadas de maneira passiva. A qualidade da documentação e uma cultura organizacional voltada ao uso de artefatos disponíveis para acelerar a curva de aprendizado dos membros das equipes, aliada a uma educação contínua para a busca de informações documentadas do projeto são condições para a adoção da prática de comunicação passiva. De maneira geral, os benefícios da prática de compartilhamento de informações do projeto através da comunicação passiva é uma maior valorização do projeto por ter suas informações registradas, menor curva de aprendizado para novos integrantes nos times e facilitar a evolução do projeto.

A partir do modelo criamos as seguintes proposições: Proposição 1 - As condições necessárias para a criação de documentação associadas às condições para sua utilização possibilitam os benefícios da prática. Proposição 2 - O armazenamento de artefatos técnicos distribuídos nas ferramentas onde foram criados traz benefícios quando as condições de uso são atendidas. 

Projetos de DGS são considerados empreendimentos complexos do ponto de vista organizacional pela distribuição geográfica dos membros da equipe (Damasiotis; Fitsilis, 2015), levando seus gestores a buscarem soluções de comunicação e planejamento para sua coordenação. Nesse contexto, a busca por boas práticas de processos, ferramentas de TI e aspectos comportamentais dos membros da equipe, que facilitem a comunicação e a cooperação, contribuem para esse objetivo. 

A falta de uma utilização eficiente do relatório de desempenho do projeto e de planejamento da comunicação encontrada em estudos como o de Monteiro de Carvalho (2013) não foi expressiva nessa amostra. Os GP demonstraram ser voltados a processos estando alinhados tanto com frameworks de gerência da comunicação presentes na literatura como em Samáková et al. (2013) e o PMBoK, quanto com as cerimônias propostas por metodologias ágeis, principalmente o framework do Scrum. 

Zieke Dwight (2015) demonstraram que no geral, os gerentes de projeto não concordam com a crença de que a comunicação é parte de um diálogo construtivo. Os entrevistados, na amostra dos autores, ao discutirem suas visões gerais de comunicação, adotaram uma abordagem de transmissão para a ação, acreditando que o objetivo da comunicação é enviar informações claras, inequívocas e completas. Neste estudo encontramos ambas as perspectivas de comunicação sendo utilizadas, com a maioria das respostas reforçando o achado de Zieke Dwight (2015). Porém, além da escolha adequada das ferramentas e processos de comunicação para o sucesso do projeto, os GP manifestaram a importância de comportamentos e atitudes do líder do projeto relacionados à comunicação, como transparência na comunicação e a busca de um ambiente de harmonia na equipe, por exemplo.

O conhecimento dos líderes de projeto sobre as diferentes mídias de comunicação, assim como a consciência e habilidades básicas em gerenciar a adaptação dos times às tecnologias de maneira adequada, estão presentes em estudos anteriores (BEISE; NIEDERMAN; MATTORD, 2007; DEN Otter; Emmitt, 2007; Dominic; Bostrom, 2008) como fatores de sucesso para atingir os objetivos do projeto. Diferentes estudos mostraram que a proliferação de mídias na organização tende a ser prejudicial à comunicação (DEN Otter; Emmitt, 2007; Weimann et al., 2010), por criar uma divisão tecnológica e separar os usuários, que escolhem as ferramentas apegados às suas experiências de uso anteriores, mesmo que sejam menos eficientes. Porém, neste estudo, os GP deixam a escolha das ferramentas que serão usadas para a comunicação a critério dos times de desenvolvimento e consideram que o aprendizado dessas ferramentas é intuitivo, não sendo necessários treinamentos preparados para sua utilização. Em alguns casos específicos os GP manifestaram a importância de gerenciar o uso das mídias controlando quem deva estar em cada canal ou grupos criados nessas ferramentas.

O uso intenso do WhatsApp e do Slack nos projetos DGS, principalmente em eventos como desenvolvimento, elicitação de requisitos e na resolução de problemas de produção foi notável nesta pesquisa. O uso dessas ferramentas em comunicações síncronas se dá em paralelo com o uso de softwares de comunicação em grupos mais tradicionais, que permitem conferência por voz, visualização de imagens através das câmeras dos computadores e compartilhamento das telas dos monitores do computador como o Skype for Business e o WebEx, ou mesmo o uso de dispositivos de videoconferência e telefone.

Por vezes, ferramentas normalmente utilizadas para comunicação síncrona, como o caso do WhatsApp, são usadas de maneira assíncrona pelos times distribuídos. Notamos que as ferramentas de comunicação utilizadas em DSG são as mesmas que são utilizadas em times locais. Glória Jr., Oliveira e Chaves (2014) propõem o uso de tecnologias colaborativas específicas para projetos que usam Scrum. Porém, nós identificamos que o uso de ferramentas colaborativas de comunicação é independente do paradigma adotado para gestão de projetos de DGS. 

O WhatsApp inovou ao associar os mecanismos de troca de mensagens por texto ou voz a um número de telefone sem usar a rede de comunicação de celular tradicional, paga, e sim a Internet. Dessa forma conquistou um grande número de usuários que carregam seus telefones celulares consigo estando aptos para troca de informações instantâneas, independentemente do local onde se encontram. Não evidenciamos uma preocupação dos GPs em restringir as mensagens trocadas no WhatsApp por ser uma ferramenta externa à organização.

O Slack adota estratégia similar ao WhatsApp estando disponível tanto em plataforma Web quanto em plataforma móvel, além de possibilitar a integração com diversos aplicativos úteis ao gerenciamento de projetos, como Trello e Git. A adoção do WhatsApp e do Slack traz para o projeto uma proximidade com os hábitos de comunicação já arraigados na vida privada dos membros do time, de respostas a mensagens, independentemente de estarem em frente a um computador na sua mesa de trabalho. O e-mail, por sua vez, continua sendo amplamente utilizado, confirmando estudos anteriores como em Majdenbaum e Chaves (2018), porém com o foco principal de formalizar decisões tomadas ou dar continuidade a tarefas onde não foi possível a comunicação síncrona para sua finalização. 

Apesar de grande parte dos GP reconhecer o benefício da documentação do projeto para a curva de aprendizado dos novos membros da equipe e para a sua evolução, pouca ênfase se dá ao armazenamento centralizado dessas informações. A alocação dos membros do time para a criação dos artefatos é o principal empecilho, porque muitas vezes o tempo necessário para a realização dessas tarefas concorre com outras atividades de projeto, que assumem maior prioridade. 

O armazenamento da documentação do produto é feito de maneira descentralizada, nas ferramentas que suportam o desenvolvimento do software, como por exemplo, no próprio código fonte ou nos diagramas de arquitetura do sistema. Notamos que a utilização dessas informações pelas equipes também é um desafio. A preferência dos times é por tirar suas dúvidas com quem possa saber a resposta, ao invés de pesquisar por informações armazenadas.

6 Contribuições Teóricas e Práticas

O artigo contribui com um modelo conceitual proposto para a comunicação passiva. O modelo identifica quais os fatores que contribuem para as condições necessárias tanto para a criação quanto para o uso da comunicação passiva em projetos de DGS. O modelo também identifica as variáveis que contribuem para os benefícios percebidos pela prática de criação e utilização da comunicação passiva em projetos. Além disso, ajuda a distinguir os tipos de informações que devem ser armazenadas de maneira centralizada e as que devem ficar distribuídas nas ferramentas que auxiliam na criação do produto final. A criação do modelo permitiu a geração de duas proposições: 1) As condições necessárias para a criação de documentação associadas às condições para sua utilização possibilitam os benefícios da prática; 2) O armazenamento de artefatos técnicos distribuídos nas ferramentas onde foram criados traz benefícios quando as condições de uso são atendidas. 

Os resultados do artigo permitiram identificar as percepções dos GP seniores em relação à a comunicação em projetos de DSG e elencar um conjunto de boas práticas de comunicação que são de valor imediato para os profissionais da área. As boas práticas apresentam um conjunto de ações, comportamentos e ferramentas de TIC utilizadas para a gestão da comunicação nesses empreendimentos. As ações e comportamentos permitem aos profissionais uma seleção consciente das práticas de comunicação a fim de obter o melhor suporte para os objetivos dos projetos. A lista de ferramentas de TIC utilizada em diferentes eventos de comunicação em projetos de DSG pode ser recomendada aos profissionais pela sua contemporaneidade. O conjunto de contribuições permite a definição de soluções atenuantes aos problemas de comunicação no desenvolvimento de software global usando as melhores práticas e ferramentas que já foram testadas em ambientes experimentais e industriais. As proposições criadas referentes à comunicação passiva também podem ser avaliadas em futuros trabalhos de natureza quantitativa.

7 Considerações Finais

O presente trabalho contribui para a área de gestão da comunicação em projetos ao disponibilizar as experiências práticas de GPs seniores sobre o uso de comunicação direta e passiva em projetos de DGS. Além disso, esta pesquisa identifica as ferramentas de comunicação utilizadas em diferentes eventos e aspectos comportamentais relacionados à comunicação. O conjunto de boas práticas de comunicação representadas por ações, comportamentos e ferramentas de comunicação permite aumentar a probabilidade de sucesso de projetos de natureza global.

Os GP seniores valorizam e utilizam metodologias de gestão de projetos como o Scrum ou os processos do PMI para a gestão da comunicação. A comunicação passiva é pouco utilizada pelos times de projeto, sendo que as principais restrições para sua geração é a perda de prioridade em relação às tarefas de projeto e a cultura das empresas. A documentação relativa a artefatos técnicos é armazenada de maneira distribuída nos próprios softwares que auxiliam na geração desses artefatos como diagramas de arquitetura e código-fonte, por exemplo. O trabalho contribui com um modelo para entender melhor quando e como utilizar a comunicação passiva. Notamos ainda que o Whatsapp e o Slack se tornaram comuns em projetos de DSD, principalmente em eventos como desenvolvimento, elicitação de requisitos e na resolução de problemas de produção.

O trabalho apresenta limitação com o tamanho dos dados. Com apenas 20 entrevistas, perguntas sobre confiabilidade podem ser feitas. Porém, essa limitação é equilibrada pelo fato do estudo ser exploratório e consequentemente utilizado de maneira qualitativa. Os GP da amostra são brasileiros e seniores, o que limita os resultados à nacionalidade dos entrevistados, sendo que GPs com diferentes graus de experiência poderiam ter visões diferentes. Trabalhos futuros podem comparar as percepções de diferentes grupos de stakeholders, como o time de desenvolvimento do projeto ou os clientes com os resultados obtidos neste artigo sobre comunicação em projetos de DGS.

Referências

ATTARAN, Mohsen; ATTARAN, Sharmin. Collaborative computing technology: the hot new managing tool. Journal of Management Development, v. 21, n. 8, p. 598-609, 2002.

AUDY, Jorge Luis Nicolas; PRIKLADNICKI, Rafael. Desenvolvimento distribuído de software. Elsevier, 2007.

BEISE, Catherine M.; NIEDERMAN, F.; MATTORD, Herb. IT Project Managers' Perceptions and Use of Virtual Team Technologies. IEEE Engineering Management Review, v. 35, n. 4, 2007.

DEN OTTER, Ad; EMMITT, Stephen. Exploring effectiveness of team communication: Balancing synchronous and asynchronous communication in design teams. Engineering, Construction and Architectural Management, v. 14, n. 5, p. 408-419, 2007.

DWIVEDI, Yogesh K. et al. Research on information systems failures and successes: Status update and future directions. Information Systems Frontiers, v. 17, n. 1, p. 143-157, 2015.

EBERT, Christof; KUHRMANN, Marco; PRIKLADNICKI, Rafael. Global software engineering: Evolution and trends. In: Global Software Engineering (ICGSE), 2016 IEEE 11th International Conference on. IEEE, 2016. p. 144-153.

GHOBADI, Shahla. What drives knowledge sharing in software development teams: A literature review and classification framework. Information & Management, v. 52, n. 1, p. 82-97, 2015.

HENDERSON, Linda S.; STACKMAN, Richard W.; LINDEKILDE, Rikke. The centrality of communication norm alignment, role clarity, and trust in global project teams. International Journal of Project Management, v. 34, n. 8, p. 1717-1730, 2016.

HERBSLEB, James D. et al. An empirical study of global software development: distance and speed. In: Proceedings of the 23rd international conference on software engineering. IEEE Computer Society, 2001. p. 81-90.

KAPPELMAN, Leon A.; MCKEEMAN, Robert; ZHANG, Lixuan. Early warning signs of IT project failure: The dominant dozen. Information Systems Management, v. 23, n. 4, p. 31-36, 2006.

KERZNER, Harold; KERZNER, Harold R. Project management: a systems approach to planning, scheduling, and controlling. John Wiley & Sons, 2013.

KLAUS, Tim; BLANTON, J. Ellis. User resistance determinants and the psychological contract in enterprise system implementations. European Journal of Information Systems, v. 19, n. 6, p. 625-636, 2010.

JAN, Syed Roohullah et al. Issues in global software development (communication, coordination and trust)—a critical review. Training, v. 6, n. 7, p. 8, 2016.

majdenbaum, Azriel; CHAVES, Marcirio. Análise de Ferramentas de Comunicação em Gestão de Projetos sob Seis Perspectivas. Iberoamerican Journal of Project Management, v. 9, n. 1, p. 1-17, 2018.

MAY, Lorin J. Major causes of software project failures. CrossTalk: The Journal of Defense Software Engineering, v. 11, n. 6, p. 9-12, 1998.

MONTEIRO DE CARVALHO, Marly. An investigation of the role of communication in IT projects. International Journal of Operations & Production Management, v. 34, n. 1, p. 36-64, 2013.

NEWELL, Sue et al. Sharing knowledge across projects: limits to ICT-led project review practices. Management learning, v. 37, n. 2, p. 167-185, 2006.

NIDIFFER, Kenneth E.; DOLAN, Dana. Evolving distributed project management. IEEE Software, v. 22, n. 5, p. 63-72, 2005.

Nonaka, Ikujiro. A dynamic theory of organizational knowledge creation. Organization Science, 5(1), 14-37, 1994.

NYSTRÖM, Christina Amcoff; ASPROTH, Viveca. Virtual Teams—Support for Technical Communication?. Journal of Organisational Transformation & Social Change, v. 10, n. 1, p. 64-80, 2013.

ORLIKOWSKI, Wanda J. CASE tools as organizational change: Investigating incremental and radical changes in systems development. MIS Quarterly, p. 309-340, 1993.

PAPKE-SHIELDS, Karen E.; BEISE, Catherine; QUAN, Jing. Do project managers practice what they preach, and does it matter to project success?. International journal of project management, v. 28, n. 7, p. 650-662, 2010.

RIMKUNIENE, Dalia; ZINKEVICIUTE, Virgilija. Social media in communication of temporary organisations: role, needs, strategic perspective. Journal of Business Economics and Management, v. 15, n. 5, p. 899-914, 2014.

ROBILLARD, Pierre N. The role of knowledge in software development. Communications of the ACM, v. 42, n. 1, p. 87-92, 1999.

SAMÁKOVÁ, Jana; SUJANOVÁ, Jana; KOLTNEROVÁ, Kristína. Project communication management in industrial enterprises. In: European Conference on Information Management and Evaluation. Academic Conferences International Limited, 2013. p. 155.

SHRIVASTAVA, SuprikaVasudevaet al. Distributed agile software development: A review. arXiv preprint arXiv:1006.1955, 2010.

WASTELL, David G. Learning dysfunctions in information systems development: overcoming the social defenses with transitional objects. MIS Quarterly, p. 581-600, 1999.

WEIMANN, Peter et al. Changing the communication culture of distributed teams in a world where communication is neither perfect nor complete. Electronic Journal Information Systems Evaluation, v. 13, p. 187-196, 2010.

ZIEK, Paul; ANDERSON, J. Dwight. Communication, dialogue and project management. International Journal of Managing Projects in Business, v. 8, n. 4, p. 788-803, 2015.

____________________________

Azriel Majdenbaum¹

Doutorando em Administração pela PUCRS (http://pucrs.br/negocios); Mestrado em Administração pela Universidade Federal do Rio Grande do Sul, Brasil (2001); Especialização em Administração Hospitalar pela PUCRS; Bacharel em Informática pela PUCRS. Professor Assistente da Pontifícia Universidade Católica do Rio Grande do Sul, Brasil. PUCRS -Pontifícia Universidade Católica do Rio Grande do Sul, Escola de Negócios – Porto Alegre – RS – Brasil. E-mail: azrielmaj@gmail.com

Marcirio Chaves²

Doutorado em Informática pela Universidade de Lisboa, Portugal (2009). Professor Adjunto da Pontifícia Universidade Católica do Rio Grande do Sul, Brasil. PUCRS - Pontifícia Universidade Católica do Rio Grande do Sul, Escola de Negócios, Porto Alegre, RS, Brasil. E-mail: mschaves@gmail.com 

Recebido em: 12/06/2018

Aprovado em: 18/10/2018