Melhoria das Comunicações em Projetos de Software

PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ
SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA

Mecanismos Propostos Visando Melhoria das Comunicações
em Projetos de Desenvolvimento de Software

Halan Ridolphi (Icatu Hartford SA) hridolphi@icatuhartford.com.br
Engenheiro de Software, Pós-Graduação em Gerenciamento de Projetos (SEGRAC/POLI/UFRJ)

Orientador Lysio Séllos (SEGRAC/POLI/UFRJ) lysio@poli.ufrj.br
Engenheiro Civil, D.Sc.

Resumo
Este artigo tem como objetivo discorrer sobre boas práticas visando melhorar o
gerenciamento das comunicações em um cenário específico de projeto de desenvolvimento de
software, onde o esforço de equipes de trabalho está distribuído em distintas fábricas de
software, com artefatos sendo construídos em paralelo e com dependências entre si,
compartilhamento de baseline comum de código fonte e especificação, ou seja, um contexto
propício à geração de conflitos entre equipes por conta de problemas na compreensão da
informação intercambiada. O artigo expressa a proposta do autor na utilização de
mecanismos para efetivamente promover o gerenciamento da documentação e o
planejamento de reuniões do projeto, contribuindo para o bom gerenciamento das
comunicações em projetos de construção de sistemas de software, contemplando o tratamento
adequado para os problemas na comunicação de equipes geograficamente distribuídas, de
modo a assegurar melhor confiabilidade da comunicação e compreensão da informação
distribuída aos envolvidos neste cenário de projeto.

Palavras chave: Comunicações, Projetos, Software.

1. Introdução
Pretendemos comentar sobre tópicos relacionados a gerenciamento das comunicações do
projeto, considerando os problemas atuais enfrentados pelo autor em seu ambiente de
trabalho. Participando atualmente de um projeto de engenharia de software cujo produto
principal é viabilizar um sistema de informação único para automatizar os processos de gestão
e operacionalização integrada de negócios de uma corporação do ramo financeiro, o autor tem
a função de líder de equipe de engenharia de aplicação, essencialmente, coordenando pessoal
técnico para suporte a demandas de equipes de desenvolvimento de software distribuídas em
fábricas de software, perfacendo um total de 4 fábricas com até 25 pessoas em cada equipe,
com módulos de programa sendo construídos em paralelo e com dependências entre si. A
Figura 1 demonstra sucintamente o cenário de projeto mencionado.
Na experiência do autor, alguns dos grandes problemas neste contexto de projeto são prover
uma comunicação eficaz e efetiva, bem como, integração de muitas pessoas. O sistema de
informação em construção é enorme, bem como, as regras de negócio a serem automatizadas
são complexas. Há muitas pessoas cooperando em distintas frentes de trabalho (construção,
garantia de qualidade, homologação, implantação, suporte, gerenciamento) e compartilhando
artefatos do projeto (especificação, código fonte, planos, relatórios, cronogramas).

SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 1
Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJ
http://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br


Atualmente, a equipe de engenharia de aplicação deste cenário de projeto, atua basicamente
na forma de "apagar incêndio" quase que na maioria do tempo, ou seja, uma visão do
"inferno", quase não se respira, havendo boa carga de trabalho sendo realizado na forma de
improvisação e, onde a criatividade e inovação são fortemente minadas pelos incidentes e
suas recorrências.

Figura 1 – Cenário de desenvolvimento de software
Fonte: do autor
O desafio do autor neste contexto de projeto é coordenar e servir a equipe de engenharia de
aplicação, manter visão sistêmica dos objetivos da equipe, facilitando com que providências
necessárias aconteçam e, como também, antecipação de problemas. Além disso, manter a
preocupação em viabilizar, formalizar melhor organização do ambiente de trabalho, visando
minimizar a improvisão da equipe, para que se possam alcançar resultados mais efetivos e
eficazes dentro do projeto de software. Neste sentido, mecanismos para promover o
gerenciamento da documentação e planejamento de reuniões do projeto foram especificados
visando aperfeiçoar o relacionamento dos participantes neste cenário de projeto e, portanto,
serão objeto de apresentação neste estudo.
2. Problemas e Desafios
Como boa prática de gerência das comunicações do projeto recomenda-se fortemente ao
gerente de projeto propor, especificar, formalizar e documentar mecanismos formais sob a



forma de procedimentos, ferramentas, processos, técnicas ou métodos visando tratar
adequadamente as necessidades de coordenação do projeto, a saber:
− Organizar, manter, distribuir, proteger, atualizar e recuperar os artefatos de documentação
gerados nas atividades de execução do projeto;
− Preparar, planejar, conduzir e avaliar reuniões da equipe do projeto.
A ausência de tais mecanismos formais podem contribuir decidamente para o descontrole das
informações circulantes e compartilhadas no projeto, bem como, corroborar para instabilidade
das decisões, responsáveis e prazos definidos no transcorrer do projeto.
A seguir, enumeramos alguns problemas e desafios relacionados ao gerenciamento da
documentação e planejamento de reuniões do projeto:
a. Problemas
− Falta de abordagens sistemáticas e organizadas para troca de informações do projeto
contribui fortemente para ineficácia do processo produtivo e, consequentemente, queda da
qualidade do produto de software construído;
− Ausência de ferramental e repositório central para manipulação e armazenagem da
documentação do projeto contribui para disseminação de informação não-estruturada,
incompleta ou desatualizada para equipe do projeto;
− Falta de agendamento formal de reuniões ou uso de comunicação somente via mensagens
de e-mail para discussão de problemas da equipe, certamente contribui para degradar a
produtividade do trabalho, é desagradável porque desvia o foco da equipe e, as idéias
originadas tendem a cair no esquecimento, vulgo “limbo”, sem haver convergência para
definição formal de soluções, escalonamento de tarefas, responsabilidades e prazos.
b. Desafios
− Especificar, formalizar e padronizar procedimentos de publicação, atualização,
recuperação e disseminação de informações do projeto;
− Tornar reuniões da equipe do projeto mais produtivas e efetivas na resolução de problemas
do projeto;
− Possibilitar disponibilidade de acesso a documentação atualizada pela equipe do projeto, de
qualquer lugar e a qualquer hora do dia, com uso de ferramentas com interface do usuário
de navegação na Internet;
− Auxiliar os membros da equipe do projeto a se comunicarem de forma padronizada,
transmitirem idéias claras e objetivas entre si, e compreenderem com maior precisão o
significado da informação compartilhada;
− Ampliar a eficiência na comunicação geral entre os membros da equipe do projeto.
3. Organizando a Documentação
A abordagem apresentada nesta seção visa facilitar o bom gerenciamento da documentação do
projeto baseando-se na utilização de ferramentas que combinam funcionalidades para
gerenciamento de portais corporativos de relacionamento e gerenciamento eletrônico de
documentos (GED). Tais ferramentas possibilitam recursos para publicação,
compartilhamento, colaboração e recuperação de conteúdo via Internet, onde usuários
devidamente autenticados no portal corporativo podem acessar documentos e informações



com segurança, a qualquer hora e de qualquer lugar com uso de interface do usuário provida
por navegadores web. Essas ferramentas agregam funcionalidades para criação e manutenção
de bibliotecas de documentos, listas de discussão, listas de questões, listas de tarefas e, dentre
outras facilidades visando possibilitar o trabalho cooperativo e troca de informações entre os
participantes do projeto. Como exemplos de tais ferramentas citamos o Microsoft SharePoint
Portal Server e o Lumis Portal Suite.
Descreveremos uma abordagem de organização de documentos de projeto com propósito
geral, ou seja, independente de ferramentas específicas, entretanto, baseando nos conceitos
embutidos nas categorias de ferramentas supra-citadas. Para fins práticos, os exemplos
apresentados se utilizam da sintaxe disponível no Microsoft SharePoint 2003 e, focalizam o
conceito de bibliotecas de documentos.
Os termos “diretório” e “pasta” são utilizados como sinônimos. O termo “sub-pasta” é usado
para referir-se a uma pasta que existe dentro de outra pasta.
a. Projetos
Cada projeto deve possuir um web site específico contemplando lista de tarefas, lista de
discussão, lista de questões, bibliotecas de documentos, etc. A área de engenharia de
aplicação da corporação também deve possuir um web site próprio, contendo informações
gerais acerca de padrões e diretrizes orientando a construção de aplicações de software.
Cada projeto da corporação possui um web site específico, cuja localização proposta,
utilizando-se sintaxe do Microsoft SharePoint 2003, obedeceria ao seguinte padrão:
http://edocs.{nome-corporação}.com.br/sites/projetos/{nome-projeto}
{nome-projeto} especifica o nome do projeto.
{nome-corporação} especifica o nome da corporação a qual o projeto se destina.
b. Bibliotecas de Documentos
As bibliotecas de documentos do Microsoft SharePoint 2003 são repositórios de arquivos
similares ao sistema de arquivos do Windows, residem nos sites do SharePoint 2003 e podem
ser acessadas pelo Windows Explorer (necessita instalação do Cliente do Microsoft Office
SharePoint Portal Server 2003) ou pelo Internet Explorer.
O acesso via Windows Explorer está disponível se o computador cliente estiver hospedado no
ambiente interno da rede de computadores da corporação. O acesso via Internet Explorer está
disponível a partir de qualquer ponto da Internet. As duas formas de acesso requerem que o
usuário seja autenticado junto ao domínio de rede da corporação e faça parte dos grupos com
permissão de acesso aos recursos desejados.
c. Site de Engenharia de Aplicação
O site da área de engenharia de aplicação deverá conter, entre outros elementos, uma
biblioteca de documentos destinada a armazenar documentação normativa com padrões e
diretrizes orientando a construção de aplicações de software. Este web site poderá obedecer
ao seguinte de endereço de localização:
http://edocs.{nome-corporação}.com.br/sites/engapl
Este web site deverá conter as seguintes bibliotecas de documentos:



− Legado : Esta biblioteca armazena documentos antigos, que foram construídos antes da
nova padronização dos documentos. Esta biblioteca não é acessível por equipes externas a
corporação, como fábricas de software e, deve ser acessada com privilégio para somente
leitura.
− Diretrizes : Esta biblioteca armazena documentos com normas para desenvolvimento de
aplicações de software, em conformidade com padrões, arquitetura, requisitos de qualidade
estabelecidos pela corporação, os quais devem ser observados atentamente por todos os
fornecedores de software. Esta biblioteca deve ser acessível por equipes externas a
corporação, por exemplo, equipes de desenvolvedores distribuídos em fábricas de
software.
As bibliotecas de documentos acima podem ser endereçadas a partir da web como a seguir:
http://edocs.{nome-corporação}.com.br/sites/engapl/legado
http://edocs.{nome-corporação}.com.br/sites/engapl/diretrizes
Para a biblioteca de documentos Diretrizes sugere-se a seguinte hierarquia de pastas:
− Revisão de Código
− Framework
− Interface do Usuário
− Arquitetura
− IDE & CASE
− Programação
− Modelagem de Dados
− Segurança da Informação
d. Site de Projeto
Um site de projeto é criado para compor documentos específicos para determinado projeto
sendo gerenciado e realizado pela corporação. Conforme já mencionado, este web site poderá
obedecer ao seguinte de endereço de localização:
http://edocs.{nome-corporação}.com.br/sites/projetos/{nome-projeto}
Este web site deverá conter as seguintes bibliotecas de documentos:
− Documentos Privados : Esta biblioteca é usada para armazenar os documentos privados
da corporação. Esta biblioteca não é acessível por equipes externas a corporação, nem
mesmo para fins de leitura.
− Documentos Protegidos : Esta biblioteca é usada para publicação da documentação oficial
do projeto. Além dos documentos produzidos pela equipe da corporação, esta biblioteca
também armazena os documentos formalmente recebidos e enviados para equipes externas
a corporação, por exemplo, equipes distribuídas em fábricas de software. As equipes
externas possuem acesso somente de leitura nesta biblioteca.
− Documentos Públicos : Esta biblioteca é usada para troca de arquivos de trabalho entre os
participantes do projeto. Equipes externas a corporação possuem acesso de leitura e escrita



nesta biblioteca.

As bibliotecas de documentos acima podem ser endereçadas a partir da web como a seguir:
http://edocs.{nome-corporação}.com.br/sites/projetos/{nome-
projeto}/Documentos/Privados
projeto}/Documentos/Protegidos
projeto}/Documentos/Publicos
Documentos Privados
Esta biblioteca é usada para armazenar os documentos de escopo privativo da corporação.
Esta biblioteca não é acessível por equipes externas, nem mesmo para leitura.
Esta biblioteca deve possuir as seguintes pastas:
− Proposta
− Projeto
Proposta
Propostas são documentos que especificam, entre outras coisas, o escopo, o prazo e o custo
dos projetos. As propostas formalizam o entendimento entre a corporação e os fornecedores
externos com relação ao projeto, visando alcançar um acordo de aprovação para sua
realização.
A confecção da proposta depende de um ante-projeto, que especifica as características da
solução defendida pela corporação para realização do projeto em si. Os documentos que
formam este ante-projeto devem ser armazenados criteriosamente, com cuidados e padrões
similares aos documentos oficiais de projetos.
Eventualmente pode haver uma quantidade excessiva de documentos nesta pasta. Neste caso,
uma estrutura de sub-pastas deve ser utilizada para melhorar a organização dos documentos.
A estrutura a seguir deve ser adotada por padrão, podendo ser expandida em caso de
necessidade.
Pasta Propósito
Gestão Documentos de planejamento do projeto.
Especificação Documentos que compõem a especificação preliminar ou detalham mudanças no projeto.
Tabela 1 – Estrutura de sub-pastas de Documentos Privados/Proposta
Fonte: do autor
Exemplos de documentos na pasta Gestão:
− Apresentações genéricas sobre o projeto.
− Atas de reunião.
− Cronogramas.
− Contagem de ponto de função.
− Plano de projeto.



− Plano de release.
Caso haja necessidade, a pasta Gestão pode ser organizada da seguinte forma:
Pasta Propósito
Apresentação Apresentações genéricas sobre o projeto.
Atas Atas de reunião.
Planejamento Planejamentos em geral (cronograma, contagem de PF, plano de projeto, organograma).
Tabela 2 – Estrutura de sub-pastas de Documentos Privados/Proposta/Gestão
Fonte: do autor
Exemplos de documentos na pasta Especificação:
− Informações genéricas de levantamento do projeto: documentos de levantamento;
documentos recebidos; etc.
− Especificações de requisitos.
− Diagramas e especificações de casos de uso.
− Protótipos de telas.
− Protótipos de relatórios.
− Mapas de navegação.
− Diagramas de classe, seqüência e estado.
− Especificação de interfaces.
− Modelo de dados e documentos relacionados.
− Outros documentos de especificação funcional e técnica.
Caso haja necessidade, a pasta Especificação pode ser organizada da seguinte forma:
Pasta Propósito
Levantamento Informações genéricas de levantamento do projeto.
Funcional Requisitos, casos de uso, protótipos e outros documentos funcionais.
Técnica Diagramas de projeto, interfaces e outros documentos técnicos.
Modelo de Dados Modelo de dados e documentos relacionados.
Tabela 3 – Estrutura de sub-pastas de Documentos Privados/Proposta/Especificação
Fonte: do autor
A utilização das estruturas de sub-pastas acima é opcional, devendo ser considerada apenas
quando o trabalho estiver sendo prejudicado pela quantidade excessiva de documentos. No
caso, aplica-se o bom senso para determinar o que é “quantidade excessiva”, pois não existe
um valor pré-determinado.
Quando o projeto é formalmente iniciado, alguns destes documentos geralmente são copiados
para as pastas da biblioteca Documentos Protegidos.
Projeto
Documentos preliminares, rascunhos e esboços de trabalho privados da corporação,
produzidos após o início formal do projeto. Documentos que a ser publicados para equipes
externas devem ser movidos para pasta adequada da biblioteca Documentos Protegidos.



uma estrutura de sub-pastas deve ser utilizada para melhorar a organização dos documentos,
resumida a seguir:
Pasta Propósito
Gestão Documentos de planejamento do projeto.
Especificação Documentos que compõem a especificação preliminar ou detalham mudanças no projeto.
Implantação Evidências de homologação e implantação.
Tabela 4 – Estrutura de sub-pastas de Documentos Privados/Projeto
Fonte: do autor
Documentos Protegidos
Esta biblioteca é usada para publicação da documentação oficial do projeto. Além dos
documentos produzidos pela equipe da corporação, esta biblioteca também armazena os
documentos formalmente recebidos e enviados para equipes externas. Equipes externas
possuem acesso somente de leitura nesta biblioteca.
− Gestão
− Recebidos
− Enviados
− Especificação
− Implantação
Gestão
Documentos de planejamento e acompanhamento do projeto, tais como:
− Apresentações genéricas sobre o projeto.
− Atas de reunião.
− Cronogramas.
− Contagem de ponto de função.
− Relatórios de progresso.
− Plano de projeto.
− Plano de release.
Documentos que contenham orçamento devem ser armazenados na biblioteca Documentos
Privados.
necessidade.



Pasta Propósito
Apresentação Apresentações genéricas sobre o projeto.
Atas Atas de reunião.
Acompanhamento Relatórios de progresso.
Planejamento Planejamentos em geral (cronograma, contagem de PF, plano de projeto, organograma).
Tabela 5 – Estrutura de sub-pastas de Documentos Protegidos/Gestão
Fonte: do autor
Recebidos
Documentos recebidos das equipes externas a corporação. Alguns destes documentos
poderam ser copiados para a pasta Especificação. Na maioria dos casos, a quantidade de
documentos recebidos das equipes externas é baixa, não justificando a criação de sub-pastas
dentro da pasta Recebidos. Caso as equipes externas enviem uma grande quantidade de
documentos, é recomendável que se crie sub-pastas para organizar os documentos recebidos.
Neste caso, sugere-se acrescentar-se a data ao nome da sub-pasta que contém o pacote
recebido. No caso, o sufixo _aaaammdd poderá ser utilizado para nomear as sub-pastas.
Enviados
Documentos enviados formalmente para as equipes externas a corporação. Neste local devem
ser criadas sub-pastas, contendo os pacotes de arquivos que foram enviados como parte de
alguma entrega de artefato de projeto. Estes pacotes (war, jar, zip, rar) podem incluir artefatos
de módulos de programa, arquivos de configuração, arquivos de dados, evidências de teste,
evidências de implantação, etc.
Sugere-se acrescentar-se a data ao nome da sub-pasta que contém o pacote enviado. Neste
caso, o sufixo _aaaammdd poderá ser utilizado para nomear as sub-pastas.
Esta pasta deve conter uma cópia dos documentos e/ou programas que foram enviados a
equipes externas a corporação. Os documentos e/ou programas originais devem permanecer
em seus locais de origem.
Especificação
Documentos que compõem a especificação formal do projeto (funcional e técnica), tais como:
− Informações genéricas de levantamento do projeto: documentos de levantamento;
documentos recebidos; etc.
− Especificações de requisitos.
− Diagramas e especificações de casos de uso.
− Protótipos de telas.
− Protótipos de relatórios.
− Mapas de navegação.
− Diagramas de classe, seqüência e estado.



− Especificação de interfaces.
− Modelo de dados e documentos relacionados.
− Planos de implantação.
− Planos de teste.
− Solicitações e especificações de mudanças no projeto.
− Informações de versionamento de componentes (controle de mudanças).
− Outros documentos de especificação funcional e técnica.
necessidade.
Pasta Propósito
Controle de Mudança Informações de versionamento de componentes.
Levantamento Informações genéricas de levantamento do projeto.
Funcional Requisitos, casos de uso, protótipos e outros documentos funcionais.
Técnica Diagramas, interfaces e outros documentos técnicos.
Modelo de Dados Modelo de dados e documentos relacionados.
Plano de Implantação Planos de implantação.
Plano de Teste Planos de teste.
Tabela 6 – Estrutura de sub-pastas de Documentos Protegidos/Especificação
Fonte: do autor
Implantação
Evidências de instalação de componentes de software em distintos ambientes operacionais. É
recomendável a criação de sub-pastas para organizar os documentos em função dos ambientes
utilizados no projeto. A lista a seguir é um exemplo de ambientes possíveis:
Pasta Propósito
Desenvolvimento Ambiente de desenvolvimento.
Teste Integrado Ambiente de teste integrado.
Homologação Ambiente de homologação.
Piloto Ambiente de piloto.
Produção Ambiente de produção.
Tabela 7 – Estrutura de sub-pastas de Documentos Protegidos/Implantação
Fonte: do autor
Caso aconteçam várias implantações no mesmo ambiente, é recomendável que se crie sub-
pastas para organizar as evidências. Neste caso, é importante acrescentar-se a data ao nome da
sub-pasta que contém o pacote de evidências de uma determinada implantação. Neste caso, o
sufixo _aaaammdd poderá ser utilizado para nomear as sub-pastas.
Documentos Públicos



Esta biblioteca é usada para troca de arquivos de trabalho entre os participantes do projeto.
Equipes externas a corporação possuem acesso de leitura e escrita nesta biblioteca.
− Projeto
− Temp
Projeto
Documentos preliminares, rascunhos e esboços de trabalho compartilhados entre equipes da
corporação e equipes externas, em caráter temporário. As versões finais destes documentos
devem ser movidas para a pasta adequada da biblioteca Documentos Protegidos.
Temp
Área de trabalho genérica. O ideal é que seja usada como área de transferência para
armazenar documentos voláteis.
4. Otimizando as Reuniões
Parte da comunicação em um projeto de software acontece via realização de reuniões, as quais
podem ser presenciais, por meio de teleconferência ou por comunicação eletrônica.
As reuniões são fundamentais no mundo dos negócios. Todo encontro entre pessoas com
objetivo de resolver um problema ou tomar uma decisão pode ser considerado uma reunião –
mesmo que seja uma conversa informal entre colegas no corredor. No entanto, as reuniões
podem consumir muito tempo, sem apresentar bons resultados. Muitas pessoas ficam
arrepiadas quando são convocadas para uma reunião, pois certamente não perceberam que
reuniões são ações de comunicação, que demandam preparação e envolvimento de todos os
participantes.
De acordo com Pfleeger (2001), as reclamações mais divulgadas sobre as reuniões de equipe
incluem:
− O objetivo da reunião não está claramente definido;
− Os participantes não estão preparados;
− Pessoas essenciais não comparecem ou se atrasam;
− A conversação se desvia do objetivo;
− Alguns dos participantes não tratam de questões importantes, ou seja, discutem, dominam
a conversação ou não participam;
− As decisões tomadas na reunião nunca são implementadas, posteriormente.
Conforme defende Pfleeger (2001), há algumas ações para se assegurar que uma reunião seja
produtiva, citadas a seguir, em ordem de relevância:
1. O gerente de projeto deve deixar claro para equipe de projeto sobre quem deve participar
da reunião, quando ela começará e terminará, e qual será a finalidade da reunião;
2. Toda reunião deve ter uma pauta formal, escrita, distribuída, se possível, antecipadamente
a realização da reunião;
3. Alguém deve ficar responsável por manter a discussão sob controle e por ressolver
possíveis conflitos;



4. Alguém deve ser responsável por assegurar que cada item decidido na reunião seja
realmente colocado em prática;
5. Minimizar o número de reuniões, assim como o de participantes.
A boa prática de gerenciamento de projetos envolve o planejamento de todas as atividades do
desenvolvimento de software, incluindo a agenda de realização de reuniões. O Quadro 1, em
ordem de precedência, apresenta ações úteis para auxiliar o gerente de projetos no
planejamento de reuniões, no sentido de transformá-las em efetivos instrumentos de gestão
das comunicações do projeto.
Ordem Ação Descrição
1 Prepare sua reunião Quanto mais preparado você estiver para a sua ação de
comunicação, mais seguro você se sentirá. A improvisação coloca
em risco a efetividade da reuniõa e desperdiça o tempo dos
participantes.
2 Determine o resultado Defina o que você quer obter dessa ação de comunicação.
Estabeleça com precisão e clareza o objetivo da sua reunião.
3 Selecione os participantes Convide somente os profissionais que podem contribuir para atingir
os objetivos desejados. Reúna o maior número de informações
sobre essas pessoas.
4 Duração da reunião Calcule o tempo necessário para atingir os resultados esperados.
Essa estimativa balizará a abrangência e a profundidade das
discussões. Determine horário de início e término. No caso de
reuniões longas, marque com antecedência o horário dos intervalos.
5 Estruture a pauta e Defina as etapas da reunião. Priorize os assuntos com foco no
distribua-a previamente resultado final. Envolva outros participantes na construção da pauta.
O desenvolvimento da pauta deve ser lógico e ter relaçõa direta com
o objetivo.
6 Prepare materiais de apoio Use apoios visuais para melhorar a assimilação das informações. A
capacidade de retenção aumenta quando vemos e ouvimos
simultaneamente. Providencie o material que será entregue aos
participantes e os recursos necessários para a realização da reunião.
7 Organize o cenário Certifique-se de que o local escolhido oferece conforto e
privacidade adequados. Ele deve facilitar a interação dos
participantes.

Quadro 1 – Ações para planejamento de reuniões
Fonte: Adaptado de W2 Comunicação, 2001
O Quadro 2 menciona algumas medidas relativamente simples, as quais o gerente de projetos
poderá se valer visando evitar que reuniões se transformem em um falatório improdutivo,
onde as idéias tendem a cair no esquecimento sem haver convergência para decisões,
responsabilidades e prazos.
Medida Descrição
Estabelecer propósito da reunião Escreva o próposito da reunião, de preferência em uma única
frase. Cada um dos participantes deve receber uma cópia com
antecedência.



Esclarecer motivo da convocação Certifique-se de que cada um saiba por que foi convocado.
Isso pode fazer com que as pessoas se sintam valorizadas e
estimuladas a trazer idéias.
Convocar pessoal essencial Convoque apenas quem tem conhecimento direto do assunto e
responsabilidade por implementar decisões do grupo. Gente
demais torna o encontro improdutivo.
Evitar interrupções Use uma sala sem telefone para evitar interrupções.
Manter o foco Não deixe o foco se desviar dos problemas da empresa e cair
em interesses pessoais. Nesses casos, alguns podem se opor
as idéias que, de outro modo, apoiariam. Tente consultas
informais ou sessões um a um.
Definir metas claras Saia da reunião com metas claras e com responsáveis
designados para cada uma delas. Reuniões são caras. Imagine
que enquanto seus melhores executivos confabulam, a
concorrência age.
Reunir-se quando estritamente necessário A solução pode ser não se reunir. Especialmente, quando a
meta é compartilhar informações. Veja se você pode atingir
os objetivos de outras maneiras, como uma mensagem por e-
mail.

Quadro 2 – Medidas para evitar que reuniões se transformem em falatório improdutivo
Fonte: Adaptado de revista EXAME, 24/01/2001
5. Conclusões
Se o gerente de projetos vai ser o facilitador de uma reunião ou se vai encarregar uma outra
pessoa para esse papel, recomendamos fortemente a observação atenta das instruções
mencionadas anteriormente, para que se possa valer de mecanismos que visam assegurar um
bom resultado quando for planejar e dirigir uma reunião para solução de problemas,
consequentemente, tornando suas reuniões em efetivos instrumentos de gerenciamento de
projetos.
Acreditamos que a utilização de ferramentas que combinam funcionalidades de portais
corporativos e GED incrementam sobremaneira a produtividade da equipe do projeto, bem
como, contribuem para garantia da qualidade do produto final gerado pelo projeto. Além
disso, mencionamos outros benefícios tangíveis pela corporação quanto ao uso de tais
tecnologias, a saber:
− Redução do tempo de processamento e manuseio de documentos;
− Aumento de satisfação das equipes de projeto;
− Acesso imediato e multiusuário a qualquer informação;
− Alta velocidade e precisão na localização de documentos;
− Melhor controle dos documentos;
− Minimização de perda e extravio de documentos;
− Disponibilidade instantânea de documentos sem limites físicos;
− Possibilidade da empresa virtual sem limites físicos;
− Maior agilidade nas transações entre empresas;



− Redução de custos com novos escritórios/depósitos/equipamentos;
− Proteção contra catástrofes que poderiam danificar seu acervo.
6. Referências
PFLEEGER, Shari Lawrence Engenharia de Software: Teoria e Prática. São Paulo: Prentice Hall, 2003. Cap. 3,
p. 80 – 110.
Revista TI – Portal corporativo: você ainda vai ter um (I):
http://www.timaster.com.br/revista/artigos/main_artigo.asp?codigo=779 – acessado em 13/10/2006.
CENADEM – O Portal do GED no Brasil: http://www.cenadem.com.br/ – acessado em 13/10/2006.
Lumis – Produtos: http://www.lumis.com.br/data/Pages/LUMISE23AA7F9PTBRIE.htm – acessado em
13/10/2006.
Microsoft SharePoint Portal Server 2003: http://www.microsoft.com/brasil/office/sharepoint/default.asp –
acessado em 13/10/2006.


Melhoria das Comunicações em Projetos de Software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (8)

Destaque

Destaque (8)

Semelhante a Melhoria das Comunicações em Projetos de Software

Semelhante a Melhoria das Comunicações em Projetos de Software (20)

Mais de Halan Ridolphi

Mais de Halan Ridolphi (9)

Melhoria das Comunicações em Projetos de Software