Artigo halan t14_seminário21102006

PPÓÓSS--GGRRAADDUUAAÇÇÃÃOO EEMM GGEERREENNCCIIAAMMEENNTTOO DDEE PPRROOJJEETTOOSS -- UUFFRRJJ SSEEGGRRAACC –– NNÚÚCCLLEEOO DDEE PPEESSQQUUIISSAA EEMM CCIIÊÊNNCCIIAASS DDAA EENNGGEENNHHAARRIIAA

SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 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 – [email protected]

1

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

Halan Ridolphi (Icatu Hartford SA) [email protected] de Software, Pós-Graduação em Gerenciamento de Projetos (SEGRAC/POLI/UFRJ)

Orientador Lysio Séllos (SEGRAC/POLI/UFRJ) [email protected]

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).

mailto:[email protected]

mailto:[email protected]


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


2



3

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



4

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:



5

− 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



6

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

http://edocs.{nome-corporação}.com.br/sites/projetos/{nome-projeto}/Documentos/Protegidos

http://edocs.{nome-corporação}.com.br/sites/projetos/{nome-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.



7

− 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.

Eventualmente pode haver uma quantidade excessiva de documentos nesta pasta. Neste caso,



8

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.

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.



9

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.



10

− 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. 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 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



11

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;



12

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 distribua-a previamente

Defina as etapas da reunião. Priorize os assuntos com foco no 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.



13

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;



14

− 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.

http://www.timaster.com.br/revista/artigos/main_artigo.asp?codigo=779

http://www.cenadem.com.br/

http://www.lumis.com.br/data/Pages/LUMISE23AA7F9PTBRIE.htm

http://www.microsoft.com/brasil/office/sharepoint/default.asp

Artigo halan t14_seminário21102006

Documents

Transcript of Artigo halan t14_seminário21102006