Artigo halan t14_seminário21102006
Upcoming SlideShare
Loading in...5
×
 

Artigo halan t14_seminário21102006

on

  • 657 views

Project Management

Project Management

Statistics

Views

Total Views
657
Views on SlideShare
656
Embed Views
1

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Artigo halan t14_seminário21102006 Artigo halan t14_seminário21102006 Document Transcript

    • 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 ogerenciamento das comunicações em um cenário específico de projeto de desenvolvimento desoftware, onde o esforço de equipes de trabalho está distribuído em distintas fábricas desoftware, 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 contextopropício à geração de conflitos entre equipes por conta de problemas na compreensão dainformação intercambiada. O artigo expressa a proposta do autor na utilização demecanismos para efetivamente promover o gerenciamento da documentação e oplanejamento de reuniões do projeto, contribuindo para o bom gerenciamento dascomunicações em projetos de construção de sistemas de software, contemplando o tratamentoadequado para os problemas na comunicação de equipes geograficamente distribuídas, demodo a assegurar melhor confiabilidade da comunicação e compreensão da informaçãodistribuída aos envolvidos neste cenário de projeto.Palavras chave: Comunicações, Projetos, Software.1. IntroduçãoPretendemos comentar sobre tópicos relacionados a gerenciamento das comunicações doprojeto, considerando os problemas atuais enfrentados pelo autor em seu ambiente detrabalho. Participando atualmente de um projeto de engenharia de software cujo produtoprincipal é viabilizar um sistema de informação único para automatizar os processos de gestãoe operacionalização integrada de negócios de uma corporação do ramo financeiro, o autor tema função de líder de equipe de engenharia de aplicação, essencialmente, coordenando pessoaltécnico para suporte a demandas de equipes de desenvolvimento de software distribuídas emfá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. AFigura 1 demonstra sucintamente o cenário de projeto mencionado.Na experiência do autor, alguns dos grandes problemas neste contexto de projeto são proveruma comunicação eficaz e efetiva, bem como, integração de muitas pessoas. O sistema deinformação em construção é enorme, bem como, as regras de negócio a serem automatizadassão complexas. Há muitas pessoas cooperando em distintas frentes de trabalho (construção,garantia de qualidade, homologação, implantação, suporte, gerenciamento) e compartilhandoartefatos do projeto (especificação, código fonte, planos, relatórios, cronogramas).SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 1Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIAAtualmente, a equipe de engenharia de aplicação deste cenário de projeto, atua basicamentena 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 deimprovisação e, onde a criatividade e inovação são fortemente minadas pelos incidentes esuas recorrências. Figura 1 – Cenário de desenvolvimento de software Fonte: do autorO desafio do autor neste contexto de projeto é coordenar e servir a equipe de engenharia deaplicação, manter visão sistêmica dos objetivos da equipe, facilitando com que providênciasnecessárias aconteçam e, como também, antecipação de problemas. Além disso, manter apreocupação em viabilizar, formalizar melhor organização do ambiente de trabalho, visandominimizar a improvisão da equipe, para que se possam alcançar resultados mais efetivos eeficazes dentro do projeto de software. Neste sentido, mecanismos para promover ogerenciamento da documentação e planejamento de reuniões do projeto foram especificadosvisando aperfeiçoar o relacionamento dos participantes neste cenário de projeto e, portanto,serão objeto de apresentação neste estudo.2. Problemas e DesafiosComo boa prática de gerência das comunicações do projeto recomenda-se fortemente aogerente de projeto propor, especificar, formalizar e documentar mecanismos formais sob aSEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 2Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIAforma de procedimentos, ferramentas, processos, técnicas ou métodos visando trataradequadamente 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 dasinformações circulantes e compartilhadas no projeto, bem como, corroborar para instabilidadedas decisões, responsáveis e prazos definidos no transcorrer do projeto.A seguir, enumeramos alguns problemas e desafios relacionados ao gerenciamento dadocumentaçã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çãoA abordagem apresentada nesta seção visa facilitar o bom gerenciamento da documentação doprojeto baseando-se na utilização de ferramentas que combinam funcionalidades paragerenciamento de portais corporativos de relacionamento e gerenciamento eletrônico dedocumentos (GED). Tais ferramentas possibilitam recursos para publicação,compartilhamento, colaboração e recuperação de conteúdo via Internet, onde usuáriosdevidamente autenticados no portal corporativo podem acessar documentos e informaçõesSEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 3Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIAcom segurança, a qualquer hora e de qualquer lugar com uso de interface do usuário providapor navegadores web. Essas ferramentas agregam funcionalidades para criação e manutençãode bibliotecas de documentos, listas de discussão, listas de questões, listas de tarefas e, dentreoutras facilidades visando possibilitar o trabalho cooperativo e troca de informações entre osparticipantes do projeto. Como exemplos de tais ferramentas citamos o Microsoft SharePointPortal Server e o Lumis Portal Suite.Descreveremos uma abordagem de organização de documentos de projeto com propósitogeral, ou seja, independente de ferramentas específicas, entretanto, baseando nos conceitosembutidos nas categorias de ferramentas supra-citadas. Para fins práticos, os exemplosapresentados se utilizam da sintaxe disponível no Microsoft SharePoint 2003 e, focalizam oconceito de bibliotecas de documentos.Os termos “diretório” e “pasta” são utilizados como sinônimos. O termo “sub-pasta” é usadopara referir-se a uma pasta que existe dentro de outra pasta.a. ProjetosCada projeto deve possuir um web site específico contemplando lista de tarefas, lista dediscussão, lista de questões, bibliotecas de documentos, etc. A área de engenharia deaplicação da corporação também deve possuir um web site próprio, contendo informaçõesgerais 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 DocumentosAs bibliotecas de documentos do Microsoft SharePoint 2003 são repositórios de arquivossimilares ao sistema de arquivos do Windows, residem nos sites do SharePoint 2003 e podemser acessadas pelo Windows Explorer (necessita instalação do Cliente do Microsoft OfficeSharePoint Portal Server 2003) ou pelo Internet Explorer.O acesso via Windows Explorer está disponível se o computador cliente estiver hospedado noambiente 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 ousuário seja autenticado junto ao domínio de rede da corporação e faça parte dos grupos compermissão de acesso aos recursos desejados.c. Site de Engenharia de AplicaçãoO site da área de engenharia de aplicação deverá conter, entre outros elementos, umabiblioteca de documentos destinada a armazenar documentação normativa com padrões ediretrizes orientando a construção de aplicações de software. Este web site poderá obedecerao seguinte de endereço de localização:http://edocs.{nome-corporação}.com.br/sites/engaplEste web site deverá conter as seguintes bibliotecas de documentos:SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 4Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA− 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/legadohttp://edocs.{nome-corporação}.com.br/sites/engapl/diretrizesPara 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çãod. Site de ProjetoUm site de projeto é criado para compor documentos específicos para determinado projetosendo 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 escritaSEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 5Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA 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/Privadoshttp://edocs.{nome-corporação}.com.br/sites/projetos/{nome-projeto}/Documentos/Protegidoshttp://edocs.{nome-corporação}.com.br/sites/projetos/{nome-projeto}/Documentos/PublicosDocumentos PrivadosEsta 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− ProjetoPropostaPropostas são documentos que especificam, entre outras coisas, o escopo, o prazo e o custodos projetos. As propostas formalizam o entendimento entre a corporação e os fornecedoresexternos com relação ao projeto, visando alcançar um acordo de aprovação para suarealização.A confecção da proposta depende de um ante-projeto, que especifica as características dasolução defendida pela corporação para realização do projeto em si. Os documentos queformam este ante-projeto devem ser armazenados criteriosamente, com cuidados e padrõessimilares 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 denecessidade. 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 autorExemplos 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.SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 6Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA− 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 autorExemplos 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 autorA utilização das estruturas de sub-pastas acima é opcional, devendo ser considerada apenasquando o trabalho estiver sendo prejudicado pela quantidade excessiva de documentos. Nocaso, aplica-se o bom senso para determinar o que é “quantidade excessiva”, pois não existeum valor pré-determinado.Quando o projeto é formalmente iniciado, alguns destes documentos geralmente são copiadospara as pastas da biblioteca Documentos Protegidos.ProjetoDocumentos 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 equipesexternas devem ser movidos para pasta adequada da biblioteca Documentos Protegidos.Eventualmente pode haver uma quantidade excessiva de documentos nesta pasta. Neste caso,SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 7Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIAuma 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 autorA utilização das estruturas de sub-pastas acima é opcional, devendo ser considerada apenasquando o trabalho estiver sendo prejudicado pela quantidade excessiva de documentos. Nocaso, aplica-se o bom senso para determinar o que é “quantidade excessiva”, pois não existeum valor pré-determinado.Documentos ProtegidosEsta biblioteca é usada para publicação da documentação oficial do projeto. Além dosdocumentos produzidos pela equipe da corporação, esta biblioteca também armazena osdocumentos formalmente recebidos e enviados para equipes externas. Equipes externaspossuem acesso somente de leitura nesta biblioteca.Esta biblioteca deve possuir as seguintes pastas:− Gestão− Recebidos− Enviados− Especificação− ImplantaçãoGestãoDocumentos 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 DocumentosPrivados.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 denecessidade.SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 8Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA 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 autorA utilização das estruturas de sub-pastas acima é opcional, devendo ser considerada apenasquando o trabalho estiver sendo prejudicado pela quantidade excessiva de documentos. Nocaso, aplica-se o bom senso para determinar o que é “quantidade excessiva”, pois não existeum valor pré-determinado.RecebidosDocumentos recebidos das equipes externas a corporação. Alguns destes documentospoderam ser copiados para a pasta Especificação. Na maioria dos casos, a quantidade dedocumentos recebidos das equipes externas é baixa, não justificando a criação de sub-pastasdentro da pasta Recebidos. Caso as equipes externas enviem uma grande quantidade dedocumentos, é 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 pacoterecebido. No caso, o sufixo _aaaammdd poderá ser utilizado para nomear as sub-pastas.EnviadosDocumentos enviados formalmente para as equipes externas a corporação. Neste local devemser criadas sub-pastas, contendo os pacotes de arquivos que foram enviados como parte dealguma entrega de artefato de projeto. Estes pacotes (war, jar, zip, rar) podem incluir artefatosde 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. Nestecaso, 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 aequipes externas a corporação. Os documentos e/ou programas originais devem permanecerem seus locais de origem.EspecificaçãoDocumentos 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.SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 9Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA− 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 denecessidade. 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 autorA utilização das estruturas de sub-pastas acima é opcional, devendo ser considerada apenasquando o trabalho estiver sendo prejudicado pela quantidade excessiva de documentos. Nocaso, aplica-se o bom senso para determinar o que é “quantidade excessiva”, pois não existeum valor pré-determinado.ImplantaçãoEvidê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 ambientesutilizados 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 autorCaso 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 dasub-pasta que contém o pacote de evidências de uma determinada implantação. Neste caso, osufixo _aaaammdd poderá ser utilizado para nomear as sub-pastas.Documentos PúblicosSEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 10Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIAEsta 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.Esta biblioteca deve possuir as seguintes pastas:− Projeto− TempProjetoDocumentos preliminares, rascunhos e esboços de trabalho compartilhados entre equipes dacorporação e equipes externas, em caráter temporário. As versões finais destes documentosdevem 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 paraarmazenar documentos voláteis.4. Otimizando as ReuniõesParte da comunicação em um projeto de software acontece via realização de reuniões, as quaispodem 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 comobjetivo 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õespodem consumir muito tempo, sem apresentar bons resultados. Muitas pessoas ficamarrepiadas quando são convocadas para uma reunião, pois certamente não perceberam quereuniões são ações de comunicação, que demandam preparação e envolvimento de todos osparticipantes.De acordo com Pfleeger (2001), as reclamações mais divulgadas sobre as reuniões de equipeincluem:− 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 sejaprodutiva, 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;SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 11Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA4. 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 dodesenvolvimento de software, incluindo a agenda de realização de reuniões. O Quadro 1, emordem de precedência, apresenta ações úteis para auxiliar o gerente de projetos noplanejamento de reuniões, no sentido de transformá-las em efetivos instrumentos de gestãodas 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, 2001O Quadro 2 menciona algumas medidas relativamente simples, as quais o gerente de projetospoderá 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.SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 12Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA 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/20015. ConclusõesSe o gerente de projetos vai ser o facilitador de uma reunião ou se vai encarregar uma outrapessoa para esse papel, recomendamos fortemente a observação atenta das instruçõesmencionadas anteriormente, para que se possa valer de mecanismos que visam assegurar umbom resultado quando for planejar e dirigir uma reunião para solução de problemas,consequentemente, tornando suas reuniões em efetivos instrumentos de gerenciamento deprojetos.Acreditamos que a utilização de ferramentas que combinam funcionalidades de portaiscorporativos e GED incrementam sobremaneira a produtividade da equipe do projeto, bemcomo, contribuem para garantia da qualidade do produto final gerado pelo projeto. Alémdisso, mencionamos outros benefícios tangíveis pela corporação quanto ao uso de taistecnologias, 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;SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 13Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br
    • PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS - UFRJ SEGRAC – NÚCLEO DE PESQUISA EM CIÊNCIAS DA ENGENHARIA− Redução de custos com novos escritórios/depósitos/equipamentos;− Proteção contra catástrofes que poderiam danificar seu acervo.6. ReferênciasPFLEEGER, 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 em13/10/2006.Microsoft SharePoint Portal Server 2003: http://www.microsoft.com/brasil/office/sharepoint/default.asp –acessado em 13/10/2006.SEGRAC – Núcleo de Pesquisa em Ciências da Engenharia 14Escola Politécnica da Universidade Federal do Rio de Janeiro -CT– Bloco A – 2º andar - Cidade Universitária – Rio de Janeiro – RJhttp://www.segrac.poli.ufrj.br – segrac@poli.ufrj.br