1
Solução para os problemas de comunicação em gerência de
projetos de software
Héber Renato Fadel de Morais, Luiz Henrique Taconi, Wellington Aparecido Della
Mura, Rodolfo Miranda de Barros
Departamento de Computação
Universidade Estadual de Londrina
E-mails: [email protected], {lhtaconi, della.mura, rodolfomdebarros}@gmail.com
Resumo: A solução proposta neste artigo visa compilar as melhores práticas no
gerenciamento de projetos em um processo de negócios. O resultado permite a aplicação em
equipes de desenvolvimento com o objetivo de sanar os vários problemas de comunicação
encontrados. Além disso, o processo desenvolvido busca avaliar a situação atual da equipe,
verificar seu nível de maturidade na comunicação e a melhoria contínua da gerência de
comunicação.
Abstract: The solution proposal in this article aims compile the best practicies in the project
management in a business process. The result permits the application in development teams
with an objective of solving the several communication problems found. In the same way, the
develop proccess pursuits evaluates the current situation of the team, verifying his maturity
level in the communication and the contiunuos improvement of the communication
management.
Palavras chaves: Comunicação, Gerência de Projetos, PMBOK.
2
1 INTRODUÇÃO
Frente à complexidade e grande oferta de metodologias de desenvolvimento
de softwares e seu gerenciamento, um dos maiores e mais recorrentes problemas é a
comunicação dentro da equipe e em relação aos clientes e patrocinadores.
Mesmo com toda a evolução em metodologias ágeis, infraestrutura e
gerência de projetos, a comunicação permanece sendo o elo que traduz a boa aceitação do
cliente, o constante crescimento da equipe e a concordância com os patrocinadores e escopos
definidos.
Por meio de um plano de comunicação eficaz, é possível atender todos os
objetivos da gerência de projetos de softwares.
1.1 MOTIVAÇÕES E JUSTIFICATIVAS
Diante dos problemas de comunicação encontrados, faz-se necessário uma
estruturação de quais ocorrem com maior frequência e suas respectivas soluções encontradas.
A gerência de um projeto, que parte desde orientações sobre seu desenho até sua
implementação e melhoria contínua, deve ser alcançada de forma que as comunicações entre
as diferentes partes interessadas e hierarquias possam interagir clara e concisamente, não
havendo ruídos e falhas nas trocas de informações.
O sucesso de um projeto de software depende não somente da qualidade e
eficiência do produto, mas também da forma com que as informações são repassadas e no
total entendimento de todos que o compõe.
1.2 OBJETIVOS
Este trabalho tem como objetivo apresentar soluções de problemas de
comunicação para o gerenciamento de projetos de software, utilizando-se de uma revisão de
frameworks de melhores práticas de desenvolvimento, tais como COBIT, SCRUM, RUP,
3
CMMI e ITIL, lidando com o fluxo de comunicação no desenvolvimento de software como
um projeto em concordância com o PMBOK.
1.3 ESTRUTURA DO ARTIGO
este artigo está dividido em quatro capítulos: introdução; fundamentação
teórica, onde serão apresentadas as soluções baseadas em frameworks de melhores práticas;
desenvolvimento, que apresentará a solução proposta pelo trabalho baseando-se no guia
PMBOK e nos frameworks pesquisados; onde será validada a metodologia definida; e por
fim a conclusão, que trará os resultados obtidos e os possível trabalhos futuros.
4
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo serão descritos os conceitos de Gerência de Projetos e
comunicação baseados na metodologia PMBOK e nos frameworks de melhores práticas
COBIT, RUP, ITIL, SCRUM e CMMI. Após, será apresentado um comparativo entre como
cada um destes soluciona ou auxilia nos problemas de comunicação no desenvolvimento de
softwares.
2.1 GERÊNCIA DE PROJETOS
Um projeto tem como objetivo a execução de certo serviço específico ou a
criação de um novo produto envolvendo os mais variados níveis da organização. Estes
projetos surgem de necessidades de uma empresa, organização ou grupo de pessoas. São
diversas as fontes, internas ou vindo de clientes, criação de novas leis, competidores, etc. Uma
vez reconhecida a necessidade, o projeto deverá ser criado com base nos requisitos técnicos e
funcionais colhidos (PMI, 2008).
Segundo Trindade (2008), p. 31,
“O gerenciamento de projeto tem a função de assegurar que o conjunto de pessoas
com diferentes interesses, culturas, valores, abordagens e prioridades, envolvidos em
um projeto consiga desenvolver o trabalho dentro do planejamento e cronograma
pré-estabelecidos”.
Antigamente a ideia de gerenciamento de projetos estava restrita apenas a
órgãos de defesa ou companhias de construção, ou seja, grandes projetos. Atualmente, esse
cenário foi modificado de modo que essa preocupação de gerência seja amplamente aplicada
em diversas áreas.
Segundo Kerzner (2003), as técnicas de gerenciamento de projetos são
relativamente modernas quando comparadas com os problemas que estas visam resolver,
como o aumento das necessidades de TI das empresas e a falta de mão de obra qualificada, o
que gera grandes dificuldades na conclusão de projetos. Os métodos utilizados na Gestão de
Projetos são caracterizados por uma reestruturação da gerência e utilização de técnicas
5
especiais com o propósito de obter um melhor controle e uma otimização no uso dos recursos
existentes.
2.2 PMBOK
O Project Management Institute (PMI), através do Guia do Conhecimento
em Gerenciamento de Projetos (Guia PMBOK), reúne um conjunto de boas práticas
reconhecidas para o gerenciamento de projetos, sendo este um documento formal que
descreve normas, métodos, processos e práticas estabelecidas, apresentando diretrizes e
descrevendo o ciclo de vida e os processos relacionados.
O Guia PMBOK é organizado em grupos de processos, estes, por vez, são
descritos através de áreas de conhecimentos que se referem aos aspectos a serem considerados
dentro da gerência de projetos.
Os processos de gerenciamento de projetos são agrupados em cinco fases:
Iniciação: definição um novo projeto ou nova etapa de um projeto existente,
definidos após uma necessidade ter sido identificada e transformada em um objetivo a ser
solucionado, a partir de suas premissas e restrições;
Planejamento: definição do escopo do projeto, identificação das melhores
estratégias, desmembramento dos objetivos e desenvolvimento do cronograma, incluindo
alocação de recursos, equipe, custos, etc.;
Execução: realização dos trabalhos definidos no planejamento;
Monitoramento e controle: acompanhamento, revisão e controle do progresso
de execução e o desempenho do projeto e, consequentemente, a identificação das áreas em
que serão necessárias mudanças;
Encerramento: auditoria e finalização das atividades de todos os grupos de
processos, encerrando formalmente o projeto.
Estes cinco grupos de processos são organizados em nove áreas de
conhecimento conforme segue:
Integração do projeto: reúne os processos e atividades de todas as áreas para
assegurar que sejam identificados, coordenados, unificados e integrados, avaliando de
maneira homogênea qualquer necessidade de replanejamento;
6
Escopo: descreve os processos necessários para a conclusão do projeto
utilizando a menor quantidade de trabalho possível com base nas premissas do objetivo do
projeto e autoriza o início do projeto ou uma nova fase do mesmo;
Tempo: estimam os prazos necessários para a conclusão dos processos do
projeto e asseguram que os mesmo sejam cumpridos, tornando-se uma das áreas mais visíveis
do gerenciamento do projeto;
Custos: estimam o orçamento dos processos e controla seus custos,
garantindo que o capital disponível será suficiente para sua conclusão;
Qualidade: acompanha os processos de modo que satisfaçam os objetivos
para os quais foram realizados e provém melhoria contínua;
Recursos Humanos: descreve os integrantes que participam, organizam e
gerenciam o projeto (stakeholders), proporcionando a melhor utilização dos envolvidos;
Comunicação: acompanha os processos relativos à geração, coleta,
disseminação e destinação das informações do projeto, garantindo que todas estejam sempre e
imediatamente disponíveis às partes interessadas;
Riscos: possibilita a identificação, análise e resposta do gerenciamento de
riscos do projeto, geralmente associados a tempo, qualidade e custos, possibilitando uma
melhor compreensão da natureza do projeto;
Aquisições: apresenta os processos que necessitam adquirir produtos ou
serviços de organizações externas, além dos processos de gerenciamento de acordos e
contratos.
Todos estes conceitos, compostos por práticas inovadoras e avançadas, visam
obter um equilíbrio entre as demandas concorrentes de escopo, tempo, custo, qualidade,
recursos e riscos, para gerar o produto, serviço ou o resultado especificado, padronizando os
termos utilizados em gerência de projetos. A partir desta abordagem definida é possível
atender aos requisitos do projeto, selecionando as etapas apropriadas para cumprir seus
objetivos a fim de atender às necessidades e expectativas das partes interessadas [PMBOK].
Segundo o Guia PMBOK, a comunicação da organização é definida por seus
requisitos, como por exemplo, a tecnologia de comunicação específica disponível, as mídias
de comunicação permitidas (e-mails, reuniões presenciais ou virtuais, etc.), a política de
retenção de registros e os requisitos de segurança.
O Guia PMBOK dispõe de um capítulo específico visando o gerenciamento
das comunicações do projeto, do qual define que este gerenciamento deve incluir os processos
7
necessários para assegurar que as informações sejam geradas, coletadas, distribuídas,
armazenadas, recuperadas e organizadas.
Uma comunicação eficaz estabelece uma conexão confiável entre as
diferentes partes interessadas do projeto, conectando os ambientes culturais e organizacionais
independentemente dos níveis de conhecimento, e tornando clara a visão das perspectivas e
dos resultados esperados.
Diante deste cenário são definidos os processos do gerenciamento de
comunicações:
Identificação das partes interessadas: todas as pessoas ou organizações que
podem ser afetadas pelo projeto devem estar definidas e documentadas a fim de receber a
comunicação para atender às suas expectativas e resolver as questões conforme ocorrem. As
partes interessadas vão interagir e influenciar no resultado geral do projeto, portanto é
imprescindível que sejam analisados os níveis de interesse, expectativas, importância e
influência de cada uma.
Planejamento das comunicações: determinação das necessidades de
informação das partes interessadas do projeto e definição de uma abordagem de comunicação.
Neste processo são definidas expectativas claras, como quem precisa de quais informações,
quando serão necessárias e como serão entregues. A comunicação gerada deve ser eficaz,
sendo fornecida no formato esperado e tempo adequado, e também íntegra, onde somente as
informações necessárias são entregues unicamente a quem são destinadas.
Distribuição de informações: este processo é executado durante todo o ciclo
de vida do projeto e em todos os processos de gerenciamento, definindo os meios de
disponibilizar as informações necessárias às partes interessadas. Fornece relatórios e registros,
de modo que haja o feedback entre os participantes.
Gerenciamento das expectativas das partes interessadas: este processo visa a
comunicação e interação com as partes interessadas para atender às suas necessidades e
solucionar as questões no decorrer do projeto. O acompanhamento das expectativas não
somente aumenta a aceitação dos interessados, como também aponta questões ainda não
solucionadas e esclarece as já resolvidas.
Relatório de desempenho: reúne e apresenta informações sobre o
desempenho do projeto, incluindo relatórios de andamento, medições do progresso e
previsões. Através deste processo os interessados podem avaliar as situações de riscos, os
trabalhos concluídos e os em andamento, o cronograma do projeto e as mudanças necessárias.
8
Estes processos interagem entre si e com os processos das outras áreas de
conhecimento, e suas atividades englobam muitas dimensões, podendo estar não somente
dentro do projeto, mas também se relacionar com outros projetos e o público (através de
questionários), com diversos meios formais (relatórios) e informais (discussões e e-mails) de
comunicação, independentemente da hierarquia.
Dentre as habilidades de comunicação que os integrantes do projeto devem
possuir é destacado ouvir ativamente e de modo eficaz, investigando ideias e situações para
garantir um melhor entendimento, fomentar o conhecimento da equipe com base em lições
aprendidas e também as habilidades de persuasão e bom relacionamento, a fim de negociar
acordos mutuamente aceitáveis e administrar as expectativas.
Estes processos condizem com uma comunicação clara, oportuna e eficaz
entre os membros da equipe ao longo da vida do projeto, administrando conflitos de forma
construtiva e estimulando soluções de problemas e tomadas de decisões de forma
colaborativa, desenvolvendo a confiança e estabelecendo bons relacionamentos de trabalho.
2.3 Problemas Gerais de Comunicação em Desenvolvimento de Software
Com base nos conceitos de Gerência de Projetos é possível classificar os
problemas comumente encontrados, como:
Planejamento ruim: impossibilidade dos desenvolvedores em estimar o
tempo e recursos necessários para a entrega do produto solicitado, resultando em sistemas
entregues fora do prazo estimado;
Falta de qualidade: sistemas que não atendem aos requisitos do cliente,
podendo resultar não somente do problema de planejamento já citado, mas também devido
aos requisitos mal especificados;
Manutenção sofrível e com custo elevado: tanto as alterações corretivas
quanto as evolutivas geram alto custo quando o sistema original é desenvolvido sem uma
arquitetura clara e visível;
Duplicação de esforços: dificuldades em reutilizar os códigos gerados devido
à má escolha da tecnologia adotada, falta de documentação, metodologia restrita e falta de
confiança dentro da equipe;
9
Comunicação: falhas nos processos de comunicação fazem com que não haja
união entre a equipe e que o conhecimento não seja repassado.
Para Machado, 2005, fica evidente que as práticas de gerência de projetos
devem ser melhoradas para que haja sucesso, uma vez que o desenvolvimento de software
tende a ser imprevisível, e que apenas uma pequena parte de projetos de software são
entregues com sucesso dentro das estimativas de orçamento e custo.
Diante deste cenário, é encontrada a necessidade de um estudo mais
profundo e uma definição de métodos e técnicas para gerência de projetos, como propõe o
Guia PMBOK, o qual visa apresentar soluções para problemas frequentemente encontrados,
dentre os quais podemos destacar:
Planejamento: segundo o Guia PMBOK, o planejamento fornece ao grupo de
processos em execução um plano de gerenciamento do projeto documentado desde o início,
facilitando as atualizações se mudanças ocorrerem durante o progresso do mesmo. A ausência
do planejamento de um projeto ocasiona, dentre inúmeros problemas, tempo e esforço
imprecisos, fazendo com que o resultado final seja obtido aquém do esperado, e muitas das
vezes gerando novos custos pela adição de recursos nas tentativas de acelerar o processo.
Estas ações fazem com que o produto final não seja exatamente o que foi estipulado de início
e possua custo superior ao previsto.
Comunicação: planejar as comunicações é o processo de determinação das
necessidades de informação das partes interessadas no projeto e definição de uma abordagem
de comunicação (Guia PMBOK, 2008). A ausência deste planejamento acarreta na difícil
comunicação entre os envolvidos no projeto, tornando-se impossível precisar os resultados
que serão obtidos e quando serão obtidos.
Atribuição de responsabilidades: consiste no detalhamento das soluções
esperadas e a atribuição de responsabilidades a cada um dos participantes e grupos, bem como
o acompanhamento das etapas fazem com que a tomada de decisão dentro de um projeto seja
mais precisa e embasada em informações reais.
Melhoria contínua: a dificuldade em detalhar um cronograma e acompanhálo faz com que não seja possível o planejamento de melhorias em um produto, dificultando
também a tomada de decisões nas correções e manutenções preventivas, podendo ocorrer de
estas ainda não terem sido plenamente concluídas. A melhoria contínua dos processos reduz o
desperdício e elimina as atividades que não agregam valor, permitindo que os sejam operados
com níveis mais altos de eficiência e eficácia (Guia PMBOK, 2008).
10
Controle gerencial: em um ambiente em que não existe hierarquia nas
competências não há como ser avaliado o desempenho e a capacitação dos envolvidos, fato
este que atrapalha o andamento do projeto como um todo e impossibilita a identificação de
problemas e possíveis soluções.
De acordo com as últimas pesquisas do PMI, as organizações apontam que o
principal problema no gerenciamento de projetos são os de comunicação, a qual é a habilidade
mais valorizada e a principal deficiência dos gerentes (Molena 2009).
2.3.1 Problemas Específicos de Comunicação
A comunicação é imprescindível em qualquer tipo de projeto, dos mais
simples aos mais complexos. Informar o andamento das atividades é crucial para o
gerenciamento, no entanto, se nos deparamos com projetos maiores, mais completos ou com
mais cobranças políticas, é necessário que se determine um plano de comunicação a fim de
estabelecê-la de uma forma mais sofisticada (MAXIMIANO, 1997).
Segundo Martins (2006), para o bom andamento e desenvolvimento de um
projeto, é de extrema importância que todas as informações obtidas durante sua realização
sejam registradas e armazenadas em um local acessível aos interessados.
A comunicação é um ponto fundamental para ao sucesso do projeto, pois
engloba, dentro de um ambiente de projetos, vários fatores indispensáveis, como o
levantamento de requisitos entre o gerente e os usuários, e a troca de informações entre a
equipe de desenvolvimento e as negociações com fornecedores e demais envolvidos
Mozzoquatro (2010).
O PMSOUVEY.ORG, uma pesquisa anual organizada pelo PMI que conta
com a participação de centenas de organizações no mundo, aponta que a comunicação está no
topo quando o assunto é:
 Principal habilidade necessária e valorizada ao gerenciar projetos nas
organizações;
 Principal deficiência dos gerentes de projeto nas organizações;
 Problema mais frequente em projetos.
Na gerência de projetos a comunicação deve assegurar que as informações
necessárias sejam coletadas e disseminadas no momento adequado, de forma completa e
11
correta, e garantindo que os membros envolvidos tenham acesso a essa informação atualizada
(Mozzoquatro, 2010).
A comunicação eficaz entre os membros da equipe do projeto acelera os
processos internos, facilita a solução de problemas e torna mais ágil a tomada de decisões.
Para assegurar este tipo de comunicação, é necessário um gerenciamento que trate a
distribuição das informações e o registro de problemas no desenvolvimento de software,
resultando na união da equipe e propiciando alto desempenho nas realizações das variadas
atividades. Entretanto, se por um lado a comunicação adequadamente implementada oferece
vários benefícios ao projeto; por outro, pode provocar efeitos indesejados se mal apresentada,
se utilizar o tipo errado de abordagem ou se oferecida em excesso (Costa, 2011).
Os quadros seguintes demonstrarão os problemas de comunicação mais
encontrados dentro da equipe, entre a equipe e o gerente, e também com o cliente e o
patrocinador.
Problema
Descrição
Falta de padronização da
linguagem
A informação circula adequadamente dentro da
equipe, pois a comunicação é dificultada pela falta
de padronização. A informação sem padrões de
localização, escrita e organização ocasiona a
desmotivação e desunião entre os membros da
equipe. A comunicação sem métodos estruturados
pode criar um uma grande quantidade de papeis ou
e-mails que contém informações ambíguas e
normalmente pulverizadas entre as pessoas
envolvidas no projeto. Isto torna o processo de
recuperação de informações difícil, se não
impossível.
Duplicação de esforços
Devido à falta de comunicação entre a equipe,
ocasionalmente um membro pode realizar uma
tarefa ao mesmo tempo em que o outro. Ou
também, acontecer a perda de tempo na resolução
de um problema já solucionado.
Desunião da equipe
Quando a informação não circula livremente dentro
da equipe de modo que todos os integrantes se
sintam parte do desenvolvimento como um todo,
pode ocorrer a perda do foco e comprometimento.
A disseminação da comunicação entre os
envolvidos faz com que esteja claro o andamento e
objetivos do projeto.
1
2
3
12
Omissão de informação
Manter as informações ocultas e entregá-las com
atrasos ou incompletas são as principais causas de
fracasso na comunicação.
Utilização de tecnologias
inadequadas
O excesso e a diversidade de meios em que a
comunicação é disseminada faz com que haja um
tempo desnecessário na absorvição das informações
pela equipe. Todas as formas de envio e
recebimento de informações devem ser claramente
definidas e estas, por vez, devem ser amplamente
utilizadas.
Falta de uma hierarquia na
recepção das informações
Indefinição de quais integrantes devem receber e ter
acesso às informações sobre um determinado
projeto, quais são os envolvidos e se há uma
política de controle de acesso.
4
5
6
Tabela 1 - Problemas dentro da equipe
Problema
Descrição
Rejeição entre a equipe
A falta de explicação dos objetivos e andamento do
projeto por parte dos gerentes em relação à equipe
faz com que esta não esteja amplamente
identificada com os processos e não detalhem as
reais dificuldades encontradas ao longo das tarefas.
Omissão do gerente ou da equipe
Problemas como informar um atraso no cronograma
próximo à data entrega esperada do resultado, e a
autonomia restrita de um integrante que necessita de
aprovações constantes de seu superior para realizar
as comunicações apropriadas ocasionam atrasos no
projeto como um todo.
Ruído nas informações
A falta de clareza e detalhamento na definição do
escopo e políticas ocasiona o surgimento de
suposições e atitudes equivocadas.
1
2
3
Tabela 2 - Falha na comunicação gerente - equipe
1
Problema
Descrição
Rejeição ao projeto
Para o cliente, a comunicação envolve o quanto o
projeto afeta sua rotina de trabalho, suas
habilidades, capacitação e estabilidade. A ausência
de uma comunicação positiva junto ao cliente
13
ocasiona a rejeição do usuário ao projeto.
Linguagem inadequada
2
O cliente do projeto valoriza as funcionalidades
resultantes da contratação do serviço e como estas
auxiliarão no seu trabalho. Linguagens técnicas,
tecnológicas, e outras que são de entendimento
unicamente da equipe de desenvolvimento não
fazem parte do convívio dos clientes do projeto,
sendo necessária uma desmembração no
vocabulário, de forma que a comunicação fique
clara e concisa ao cliente.
Tabela 3 - Problemas na comunicação com o cliente
Problema
Descrição
Metas e prazos inalcançáveis
Ao receber uma solicitação de alteração no escopo,
o gerente pode não ter argumentos suficientes para
tratar esta solicitação, como por exemplo, rejeitá-la
ou modificá-la de acordo com a realidade. Isto pode
ocorrer caso não haja comunicação entre os
gerentes e o patrocinador e não sejam claras as
implicações da modificação.
Funcionalidades desnecessárias
Por falta de entendimento do projeto na sua
totalidade,
o
patrocinador
pode
solicitar
funcionalidades que fogem do foco do
desenvolvimento
do
software
estipulado
inicialmente. O Gerente, por sua vez, devido a falta
de comunicação com a equipe, pode aceitar as
tarefas sem a verificação se estas são viáveis.
1
2
Tabela 4 - Problemas na comunicação com o patrocinador
2.4 SOLUÇÕES
Com o objetivo de evitar os problemas citados anteriormente, foram
encontradas soluções baseadas nos mais importantes frameworks de gestão de projetos. Desta
forma, o resultado foi uma compilação das melhores práticas para a solução dos problemas de
comunicação.
14
2.4.1 COBIT
O Control Objectives for Information and Related Technology (COBIT) é
aceito pelas empresas que atuam na área de TI como uma boa prática em segurança e controle
da TI para empresas de vários segmentos. Esta melhor prática de TI foi criada pelo
Information Systems Audit and Control Association (ISACA) e atualmente é editado pelo IT
Governance Institute (Lopes, 2010).
A missão do COBIT é pesquisar, desenvolver e promover um conjunto
internacional de objetivos de controle geralmente aceitos sobre tecnologia de informação,
para o uso cotidiano por administradores e auditores (Lopes, 2010).
Quanto à comunicação, o COBIT propõe:
Comunicação realizada durante o gerenciamento de mudanças: Todas as
mudanças, incluindo manutenções e correções de emergência, relacionadas com a
infraestrutura e as aplicações no ambiente de produção são formalmente gerenciadas de
maneira controlada. As mudanças (incluindo procedimentos, processos, parâmetros de
sistemas e de serviço) devem ser registradas, avaliadas e autorizadas antes da implementação
e revisadas em seguida, tendo como base os resultados efetivos e planejados. Isso assegura a
mitigação de riscos de impactos negativos na estabilidade ou na integridade do ambiente de
produção.
Comunicação na definição e gerenciamento de serviços: A comunicação
eficaz entre a Direção de TI e os clientes de negócio sobre os serviços necessários é
possibilitada por um acordo definido e documentado que aborda os serviços de TI e os níveis
de serviço esperados. Este processo também inclui monitoramento e relatório oportuno às
partes interessadas quanto ao atendimento dos níveis de serviço. Este processo permite o
alinhamento entre os serviços de TI e os respectivos requisitos do negócio.
Comunicação de Dados confidenciais: para garantir a segurança dos sistemas
o COBIT sugere assegurar que as transações de comunicação de dados confidenciais ocorram
somente por um caminho confiável ou controlado de modo a fornecer autenticação de
conteúdo, comprovante de envio, comprovante de recebimento e não rejeição de origem.
15
2.4.2 SCRUM
Scrum é uma metodologia que permite equipes trabalharem juntas para
desenvolver um produto, transformando este desenvolvimento em etapas menores, que por
vez são construídas pelas pequenas etapas criadas anteriormente. Esta divisão de trabalho
estimula a criatividade e permite que as equipes retornem o feedback e mudanças para
desenvolver apenas o necessário (Scrum.org, 2012).
A comunicação diária com a equipe de desenvolvimento do projeto sugere
reuniões de no máximo 15 minutos, sempre realizadas no mesmo local e horário. Estas
reuniões melhoram a comunicação, pois eliminam outras reuniões, identificam e removem
impedimentos para o desenvolvimento, ressaltando e promovendo a tomada rápida de
decisões e também, melhoram o nível de conhecimento de todos para com o projeto.
Cada membro da equipe de desenvolvimento esclarece o que foi realizado
desde a última reunião, o que será feito até a próxima reunião e quais os obstáculos presentes.
Aspectos significativos do processo devem estar visíveis aos responsáveis
pelos resultados. Esta transparência requer a definição de um padrão comum para que os
observadores compartilharem o mesmo entendimento, ou seja, uma linguagem comum
referindo-se ao processo deve ser compartilhada por todos os participantes.
Existe uma forte comunicação com o cliente, onde eles se tornam parte da
equipe de desenvolvimento, permitindo que o escopo possa ser clarificado e renegociado entre
o cliente e a equipe de desenvolvimento e os gerentes do projeto possam claramente
comunicar a visão, objetivo e itens dos requisitos do projeto para a equipe de
desenvolvimento.
2.4.3 RUP
Desenvolvido pela IBM, o Rational Unified Process é um framework
abrangente de processos que oferece melhores práticas para o desenvolvimento de softwares e
sistemas com efetiva gerência de projeto, permitindo facilmente a customização conforme as
necessidades únicas da organização e a entrega somente dos componentes necessários (IBM,
2012).
16
Um dos muitos benefícios de uma arquitetura robusta, conforme indica o
RUP, (KROLL; KRUCHTEN, 2003), é que ela pode ser divida em subsistemas bem
definidos, permitindo aos membros da equipe se especializarem em suas atribuições e apenas
entender superficialmente o todo. Além disso, organizando-se em volta desta arquitetura
temos um grande avanço na comunicação dentro da equipe.
Claramente, a comunicação presencial parece ainda ser a mais efetiva,
porém, em um grande projeto isso se torna inviável. Analisando a Figura 2.4.3 é possível
verificar a complexidade destacada. Simplificando, para um time de N integrantes, o número
de caminhos de comunicação é: C = N * (N-1)*2. Isso significa que um time de duas pessoas
tem um caminho apenas, no entanto, um time de três pessoas possui três caminhos de
comunicação e um time com seis pessoas a quantidade de caminhos salta para quinze.
Figura 1 – Comunicação Presencial e Comunicação Centralizada
Um aumento dessa magnitude destroi a eficiência do time, cabendo ao
gerente procurar uma melhor maneira de comunicação. Este cenário pode ser solucionado
com a criação de um time responsável pela arquitetura e vários outros times menores com um
17
responsável, proporcionando um caminho único entre este time mais específico e o restante da
equipe.
O RUP prega que o arquiteto não é um designer solitário operando a partir de
uma torre tecnológica, mas sim, desempenhando um papel importante na comunicação da
organização de desenvolvimento, sendo assim, necessária a preocupação com as formas de
comunicação entre as várias partes interessadas no projeto, como:
Comunicação entre Gerenciamento de Projetos e Desenvolvimento: Na
indústria do cinema, o diretor é responsável pelo conteúdo artístico do filme, a direção de
atores. É muito raro que o diretor também desempenhe o papel de produtor executivo, sendo
este último mais focado em planejamento, finanças, orçamento, equipes, suprimentos,
construção de cenários, e assim por diante. Mas, ao mesmo tempo, estas duas funções
precisam ser muito bem coordenadas. Eles precisam se comunicar constantemente,
especialmente em um ambiente em movimento e em constante mudança. Da mesma forma,
em um projeto de software, o arquiteto e o gerente de projeto necessitam estar em constante
comunicação (embora seja necessário muito cuidado para que não haja o conflito de
responsabilidades). O arquiteto vai desempenhar um papel importante no planejamento do
conteúdo de uma iteração, na identificação e tratamento de riscos técnicos, e em ajudar o
gerente de projeto com mudanças estratégicas e táticas.
Comunicação entre as partes internas e parceiros externos: O arquiteto é
também a interface do mundo exterior com o restante da equipe de arquitetura e equipe do
projeto. O Documento de Visão e os requisitos desenvolvidos pelos analistas fornecem a
entrada principal para o trabalho do arquiteto, da qual o este irá extrair os requisitos de
arquitetura significativos que irão contribuir para moldar o sistema. Quando várias partes
externas - clientes, fornecedores - estão envolvidas, este aspecto do trabalho pode tornar-se
bastante demorado.
Comunicação entre várias equipes de desenvolvimento: Especialmente em
uma grande organização, os arquitetos também irão desempenhar um papel de comunicação e
coordenação, no plano técnico, entre as equipes de desenvolvimento diferentes. Eles farão
com que as interfaces sejam definidas e respeitadas, explorarão o potencial de reutilização, e
participarão de revisões, esforçando-se para garantir um estilo consistente para o
desenvolvimento do sistema, preservando o que Frederick Brooks denominou de “a sua
integridade arquitetural”.
18
2.4.4 CMMI
Os modelos do CMMI são coleções das melhores práticas e processos de
melhoria que as organizações utilizam para avaliar e melhorar seus processos (CARNEGIE
MELLON UNIVERSITY, 2012). Estes objetivos e práticas são organizadas em um grupo
chamado Áreas de Processo, dividido em:
Aquisição: provê caminhos para as que organizações gerenciem a escolha de
seus processos de aquisição e integração de produtos e serviços que necessitam de
personalização.
Desenvolvimento: modelo usado pelas empresas que desenvolvem produtos
e serviços a fim de guiar seus processos para a efetividade, eficiência e qualidade no
desenvolvimento.
Serviços: modelo específico para a prestação de serviço onde visa
estabelecer, gerenciar e entregar serviços necessários aos clientes e usuários finais.
Atualmente existe ainda um modelo chamado People CMM que provê meios
para as organizações gerenciarem seus recursos humanos. Muitas empresas que utilizam o
CMMI descobrem naturalmente que a melhoria contínua também significa melhorar o
gerenciamento de pessoas.
Sobre a Comunicação dentro do projeto, o CMMI define que o plano do
projeto deve incluir o planejamento de comunicação, projeto este que cobre como a
comunicação terá lugar durante o projeto. A comunicação com os stakeholders incluem
relatórios de status e reuniões com os vários interessados. Durante todo o projeto, o gerente
irá realizar análises para determinar o progresso e irá comunicar o status regularmente. Todos
os problemas identificados serão geridos e ações corretivas acompanhados até o
encerramento.
Um plano de comunicação documenta a proposta e define caminhos e
mecanismos de comunicação por meio de um projeto. A comunicação sem planejamento é
uma grande sobrecarga e pode ser um grande empecilho na produtividade (IRIS PROCESS
CENTRAL, 2012).
O planejamento da comunicação envolve a definição dos caminhos
hierárquicos, meios de transmissão e sua publicação.
Definir os caminhos de comunicação é o processo que detalha quem é o
remetente e quem é o receptor de uma informação dentro do projeto, tendo como principal
19
objetivo eliminar o ruído no fluxo do projeto pelos membros do time. Nos grupos de trabalho,
os membros da equipe devem ser livres para se comunicar entre si. Entre os grupos de
trabalho e externas ao projeto a comunicação deve ser canalizada, processo geralmente
realizado pelos líderes e gerentes.
A definição de meios de comunicação consiste em estipular, para cada canal
de comunicação, os meios aceitáveis para realizá-la, como reuniões, mensagens instantâneas,
e-mail, vídeo conferência, documento escrito para revisão, etc. Meios de comunicação
diferentes dos estabelecidos devem ser classificados como risco ou problema.
Por fim, a publicação do plano de comunicação consiste em tornar acessível
aos interessados estas orientações.
2.4.5 ITIL
O Information Technology Infrastructure Library surgiu no final da década
de 1980 tendo como objetivo padronizar e comparar as diversas propostas de prestadores de
serviços de TI ao governo britânico (MAGALHÃES E BRITO, 2007).
As práticas do ITIL estão reunidas em cinco livros oficiais (versão 3)
publicados pelo IT Service Management Forum. Os livros são denominados:
Estratégia de Serviço: identificação das necessidades do negócio e tomada de
decisões relacionadas aos serviços oferecidos;
Desenho de Serviço: direcionamento na integração das necessidades do
negócio com os serviços da TI com base nas informações da estratégia de serviço;
Transição de Serviço: implantação dos serviços dispostos no desenho
viabilizando sua operação;
Operação de Serviço: acompanhamento do serviço durante todo seu
funcionamento e enquanto estiver em funcionamento;
Melhoria Contínua de Serviço: fornecimento de uma referência sobre a
avaliação e melhoria nos processos e serviços gerenciados mantendo seu alinhamento com as
necessidades do negócio.
Dentre estes livros os que melhor reúnem aspectos relativos à comunicação
são os de desenho, transição e operação de serviço.
20
No livro Transição de Serviço é definido que a comunicação é o centro de
qualquer mudança em um serviço, abordando também que as maiores alterações e
necessidades da organização tem a comunicação como maior requisito, pois o planejamento e
os benefícios esperados devem ser dispostos claramente através de audiências constantes.
Neste livro é levado em consideração um aspecto peculiar, no qual esclarece que as transições
de serviços são impactantes nos integrantes da organização e que estas podem alterar suas
rotinas de entrega de resultados. Durante a transição são estabelecidos conceitos de como a
informação deve ser entregue e quais ações devem ser feitas antes da sua entrega para que
esta seja de total entendimento e aceitação. Por fim, são tratadas orientações de como as
comunicações devem ser fornecidas, tendo como exemplo citados, palestras, boletins, sessões
de treinamento, reuniões, memorandos, dentre outros.
O livro Operação de Serviço apresenta que comunicação é necessária para as
equipes e departamentos, aos usuários e clientes, entre toda a equipe de operação do serviço e
que toda comunicação deve ter um propósito pretendido ou uma ação resultante. Estes
resultados são obtidos através de rotinas operacionais de comunicação, gerenciamento de
mudanças, reporte de performance, e também, comunicações relacionadas a estratégias,
exceções e emergências. Pela operação de serviço comumente ser realizada por integrantes
mais próximos ao projeto, são apresentados meios mais usuais de comunicação, como e-mail,
mensagens de texto, mensageiros de Internet e compartilhamento de documentos. Outro meio
com destaque maior neste livro são as reuniões, porém menos formais, utilizando de aspectos
encontrados particularmente em cada organização, nos quais já são resultante a entrega e o
recebimento de informações de uma forma efetiva e conhecida. Estas reuniões tendem a ser
de poucos minutos e é agendada conforme disponibilidade dos integrantes de uma maneira
menos burocrática, encorajando os integrantes a realizá-las, podendo ser compostas por
departamentos, grupos, equipes ou clientes.
Finalizando, o livro Melhoria Contínua de Serviço propõe uma estratégia e
planejamento da comunicação de forma pontual e efetiva como base de qualquer melhoria a
ser realizada. Neste livro em especial é levado em consideração uma forma de comunicação
motivadora e informativa, onde deve ser estabelecido que a conclusão dos processos
anteriores do projeto não definem a conclusão definitiva do mesmo, visando que sempre são
possíveis aperfeiçoamentos e resultados ainda melhores obtidos através do feedback das
comunicações e informações. Por fim, são definidas algumas considerações a respeito da
definição do planejamento, como quem está entregando a informação, qual a mensagem, qual
21
o objetivo da reunião, seu tempo e frequência e o método da comunicação, bem como prover
um mecanismo efetivo de feedback.
2.4.6 Tabela Comparativa
A Tabela 2.4.6 a seguir é o resultado da pesquisa dos frameworks para gestão
de projetos. Os valores informados são “S” para solução total, “P” para a solução parcial e
“N” quando não há solução para esse problema na abordagem. É fácil perceber que, em
alguns casos, quase todas as abordagens cobrem o problema, e com isso, a solução proposta
neste trabalho faz uma combinação dessas práticas com o objetivo de otimizar o processo.
Item
COBIT1
Problema
SCRUM 2
RUP3
CMMI4
ITIL5
Solução Proposta
Comunicação dentro da equipe
1
Propõe padronização da
linguagem
S
S
S
P
N
S (3)
2
Evita a duplicação de
esforços
S
P
P
P
P
S (1,3,5)
3
Estabelece a união da
equipe
S
S
S
P
S
S (2,3,5)
4
Mantém as informações
disponíveis aos interessados
S
S
S
S
S
S (1)
5
Propõe hierarquia na
recepção das informações
N
S
S
S
S
S (2,5)
6
Recepção da comunicação
em todos os níveis
S
S
P
S
S
S (1)
Comunicação entre a equipe e o gerente
7
Boa aceitação entre a
equipe
S
P
S
P
P
S (2,3)
8
Incentiva o
comprometimento e a
motivação da equipe
P
S
S
P
N
S (2)
9
Reduz o ruído das
informações
S
S
S
P
N
S (1,2)
P
N
S (2)
Comunicação com o cliente
Comunicação com o usuário final
10
Estabelece a aceitação do
projeto
S
S
S
22
11
Mantém uma linguagem
clara e objetiva
S
S
S
P
N
S (1,2,3)
Comunicação com o patrocinador
12
Propõe prazos e metas
cabíveis
S
S
S
S
N
S (3)
13
Reduz as funcionalidades
desnecessárias
P
S
S
P
S
S (2)
Tabela 5 – Relação entre Metodologias e Problemas de Comunicação
23
3 DESENVOLVIMENTO
Neste capítulo serão apresentados um modelo de Política Organizacional, as
soluções propostas com base no que há de mais completo nos frameworks demonstrados, os
níveis de maturidade em que a organização pode ser classificada por meio de um questionário
de conhecimento e os processos necessários para alcance dos níveis superiores.
3.1 POLÍTICA ORGANIZACIONAL
A ampliação da equipe, ocasional troca de pessoal, e também a certeza de
que as especificações necessárias para uma perfeita comunicação estão definidas, entregues e
cumpridas, necessita de um documento de política organizacional de comunicação no
desenvolvimento de software, visando equiparar o conhecimento de todos que fazem o projeto
atingir o objetivo esperado. Estes fatores fazem com que a equipe mantenha o
desenvolvimento em pleno funcionamento.
O documento de Política Organizacional descrito na Tabela 3.1, dispõe o
objetivo da comunicação no desenvolvimento de software, o organograma de posicionamento
do catálogo em relação às áreas da organização, os recursos necessários para que se torne
efetivo, a gerência de requisitos e projeto, e sua divulgação para as partes envolvidas no
processo.
Política Organizacional de Comunicação em Desenvolvimento de Software
Objetivo
Registrar a política dos processos de comunicação no desenvolvimento de software, e
também inteirar cada integrante com todas as normas e políticas estabelecidas no projeto.
Aplicação
Aplicar em todos os níveis hierárquicos do desenvolvimento de software da organização e
seus respetivos clientes e patrocinadores.
Referências
● Project Management Institute, Inc. Guia PMBOK. 4.ed.
● Lopes Sheron M. C. “Governança de TI – um estudo sobre ITIL e COBIT”
24
●
●
●
●
IT Governance Institute. “COBIT 4.1”
Scrum.org. “Um guia definitivo para o Scrum: As regras do jogo”,
KROLL, Per; KRUCHTEN, Philippe. The Rational Unified Process Made Easy.
CARNEGIE MELLON UNIVERSITY. CMMI.
Organograma
Recursos e informações necessárias
● Os executores são capacitados e conhecem os procedimentos
● Existem responsáveis para a alocação do processo
● As informações devem ser entregues aos integrantes em tempo e nível adequado
Treinamento
Os executores dos processos de comunicação devem ser treinados nas metodologias,
tecnologias e ferramentas necessárias.
Comunicação entre as partes envolvidas
● Estabelecer os responsáveis do projeto
● Os contatos serão realizados por e-mail, mensageiro eletrônico, compartilhamento
de documentos ou reuniões presenciais, sendo estas registradas em atas
● Manter um repositório de conhecimento com as informações das reuniões
Revisão do status do processo com a gerência de Alto Nível
Em períodos determinados pela gerência será feita a revisão dos processos, visando a
melhoria contínua com base nas lições aprendidas
Gerência de Requisitos
● Os clientes devem ser identificados a partir do primeiro contato após solicitação do
serviço
● Os requisitos identificados devem ser avaliados antes de serem apresentados ao
clientes
● Toda mudança de requisitos deve ser gerenciada, avaliando e registrando seu
impacto
25
Gerência de Projetos
● O Gerente de Projetos é o responsável pelo projeto a partir da assinatura de uma
proposta técnica
● Todo projeto deve ter suas estimativas de esforço e prazo calculados conforme o
escopo e requisitos do projeto
● O plano do projeto deve ser baseado nas estimativas, requisitos, restrições e plano
da organização
● Toda alteração no plano deverá ser comunicada aos envolvidos
● Problemas encontrados no decorrer do projeto devem gerar plano de ações
corretivas
● Ao final do projeto deve ser realizada uma reunião para discutir as lições
aprendidas e melhoria contínua, de forma que estes dados componham o banco
de dados de histórico da organização, usado em futuras estimativas
Sobre a divulgação e Institucionalização da Política
● A Política Organizacional para o processo de comunicação deverá ser mantida e
aprovada, tendo somente revisão quando houver a necessidade de inclusão de
novos processos e capacidades ou quando o organograma for alterado
● Todos os integrantes devem ter acesso a este documento, registrando-se o
recebimento de cada um
Tabela 6 – Política Organizacional em Desenvolvimento de Software
3.2 SOLUÇÃO PROPOSTA
Em concordância com o PMBOK, os frameworks avaliados cobrem, cada
um, diferentes aspectos na resolução dos problemas de comunicação. Com base nestes
estudos, serão apresentados suas respectivas soluções.
3.2.1 Comunicação dentro da equipe
Nesta subseção serão apresentadas as soluções de comunicação dentro da
equipe.
3.2.1.1 Padronização da linguagem
26
Segundo o RUP, é necessário um glossário formado por um conjunto
consistente de definições para evitar interpretações erradas, desta forma, os integrantes
utilizam este documento para compreender os termos que são inerentes ao projeto.
Para os desenvolvedores, por exemplo, um glossário com os termos irá
ajudar a projetar e implementar as classes, tabelas, interfaces, entre outras funcionalidades. Já
os analistas, o utilizam para capturar termos específicos do projeto e definir de forma clara as
regras de negócios e garantir que as especificações de requisitos utilizarão estes termos de
maneira correta e consistente. Além disso, este glossário será utilizado até o momento da
escrita da documentação e a criação dos arquivos de treinamento para os usuários.
O processo de desenvolvimento do glossário é realizado nas fases de
iniciação e elaboração do RUP, pois, logo no início já é de suma importância uma
terminologia comum. O responsável por manter a integridade desse documento é o analista de
sistema.
Em casos de projetos em que não seja executada a modelagem de negócios e
de domínio o glossário é o principal artefato utilizado para capturar informações sobre o
domínio de negócios do projeto. Se o contexto e o escopo do esforço de modelagem de
negócios forem muito mais amplos do que os do esforço da engenharia de software, talvez
seja necessário produzir um glossário separado, especialmente para a modelagem de negócios.
O responsável por esse glossário seria então o Analista do Processo de Negócios.
3.2.1.2 Ausência de duplicação de esforços
O modelo que melhor lida com este problema é o COBIT, através do
desenvolvimento de um dicionário de dados corporativo, contendo as regras de sintaxe de
dados, o esquema de classificação de dados e os níveis de segurança da organização.
Apesar de não reunir um conjunto de soluções definidas exclusivamente para
o problema de duplicação de esforços, o ITIL e o RUP também apresentam aspectos que
podem ser aplicados no auxílio desta solução. O ITIL, propõe que todos os recursos, tarefas e
responsáveis estejam determinados e documentados, fator este que torna a comunicação
consideravelmente mais clara, restringindo os ruídos que possam ocasionar o retrabalho. Já o
RUP, por sua vez, utiliza um modelo de implementação que representa um conjunto de
27
componentes e subsistemas que os contém. Estes, incluem componentes de produtos liberados
para produção, como programas finalizados, executáveis, etc., e componentes pelos quais os
produtos liberados foram criados, como os códigos-fonte.
Utilizando destes conceitos, deve-se focar no desenvolvimento de um
dicionário de dados e uma documentação de atribuição de tarefas bem definidas, em que cada
papel ou recurso esteja disponível, a fim de evitar qualquer trabalho duplicado.
3.2.1.3 União entre a equipe
A união entre a equipe é um fator considerável no sucesso do projeto. Seja
pelas definições do ITIL, que não se torna efetivo sem o empenho das diversas áreas que
compõe seus processos, ou pelo RUP, que visa a melhor divisão e consequentemente, grupos
menores, mais focados e melhor gerenciados, as equipes tendem a se tornar mais uniformes e
homogêneas.
A cooperação e as constantes reuniões auxiliam também para que a equipe
identifique-se com o projeto, tornando único o comprometimento com os objetivos e metas do
processo.
3.2.1.4 Informações disponíveis aos interessados
Assegurar que as informações cheguem ao seu destinatário é um fator muito
importante em um ambiente de trabalho. O COBIT propõe que se deve assegurar que as
transações de comunicação de dados confidenciais ocorram somente por um caminho
confiável ou controlado de modo a fornecer autenticação de conteúdo, comprovante de envio,
comprovante de recebimento e não rejeição de origem.
3.2.1.5 Hierarquia na recepção das informações
28
De forma a atender a hierarquia de um projeto, em que a informação deve
seguir um caminho para ser recebida, entregue, e ao mesmo tempo estar disponível a todos os
interessados em tempo hábil, é necessária a orientação que o ITIL determina em seus
processos, de forma que seja respeitada a posição de cada integrante.
Em auxílio, o SCRUM estabelece que as equipes sejam auto-organizáveis,
resultando na interna gerência de cada uma delas. Uma vez que estes grupos possuem as
atribuições e competências necessárias para completar o trabalho sem envolvimento externo,
estas equipes multifuncionais tendem a respeitar de forma mais efetiva a hierarquia do projeto
como um todo.
Nestes padrões, é possível concluir que cada equipe pode ser considerada um
projeto independente, com metas e objetivos específicos, e que estes colaboram para a
conclusão de um projeto final de maior dimensão.
3.2.1.6 Recepção da comunicação em todos os níveis
Os processos de desenvolvimento requerem que as partes interessadas
atendam as demandas de requisições de acordo com o cronograma do projeto, e para que este
seja seguido e tenha o andamento esperado é necessário que os integrantes recebam as
informações pertinentes sobre recursos e requisitos e também dos prazos e objetivos.
A forma mais efetiva proposta condiz com a solução apresentada pelo
COBIT. Este framework fornece, de uma maneira geral, um modelo de processo de referência
e uma linguagem comum para que todos na organização possam visualizar e gerenciar as
atividades de projeto.
Seguindo as orientações do COBIT, é possível assegurar que a informação
chegará no tempo adequado a cada respectiva parte interessada, contribuindo assim no
andamento do projeto em geral.
3.2.2 Comunicação entre a equipe e o gerente
29
Os itens conseguintes apresentam as soluções na comunicação entre a equipe
e o gerente.
3.2.2.1 Aceitação entre a equipe
Conforme indica o RUP, (KROLL; KRUCHTEN, 2003), quando se trata de
uma arquitetura robusta é possível que ela seja divida em subsistemas bem definidos, desta
forma, os membros da equipe podem especializar-se em suas responsabilidades e apenas
entender superficialmente o todo. Organizando-se em volta desta arquitetura há um grande
avanço na comunicação dentro da equipe, pois a partir de grupos menores é possível facilitar
a comunicação entre os membros e aplicar técnica do SCRUM para melhorar o processo.
O SCRUM sugere reuniões diárias de aproximadamente 15 minutos, que
sempre será feita no mesmo local e horário. Estas reuniões melhoram a comunicação e
identificam e removem impedimentos para o desenvolvimento, ressaltando e promovendo a
tomada rápida de decisões e também, melhoram o nível de conhecimento de todos para com o
projeto.
3.2.2.2 Comprometimento e motivação da equipe
Quanto maior a motivação melhor se alcançam os resultados esperados. O
alcance do sucesso neste torna-se possível a partir de conceitos do SCRUM, em que suas
reuniões informais são destinadas a motivar, obter comentários e promover a colaboração.
3.2.2.3 Redução no ruído das informações
De acordo com COBIT, uma organização de TI é definida considerando os
requisitos de pessoal, habilidades, funções, autoridade, papéis e responsabilidades,
rastreabilidade e supervisão. Esta organização deve fazer parte de uma estrutura de processos
30
de TI que assegure transparência e controle de suas informações, que se unidas com as várias
reuniões propostas pelo SCRUM, reduz o ruído das informações.
3.2.3 Comunicação com o cliente e o usuário final
Os próximos itens detalharão as soluções para a melhor comunicação da
equipe com o cliente e/ou o usuário final.
3.2.3.1 Aceitação do projeto
Para alcançar uma boa aceitação do projeto com o cliente o SCRUM define
passos importantes, os quais tornam o cliente parte da equipe de desenvolvimento.
Aumentando sua participação o escopo pode ser clarificado e renegociado quanto mais for
aprendido.
3.2.3.2 Linguagem clara e objetiva
Do mesmo modo que foi proposto na solução de comunicação dentro da
equipe, pode ser proposto um glossário com os termos mais comuns dentro do projeto e fora
dele. Deste modo é possível comunicar-se com o cliente de forma clara e muitas vezes
fornecendo a ele mais confiabilidade. Além disso, é possível utilizar conceitos do SCRUM e
de técnicas ágeis, por exemplo o DDD (Domain Driven Design) que consiste em criar código
e regras de negócio mais inteligíveis ao usuário final, deixando-o mais familiarizado com o
desenvolvimento.
3.2.4 Comunicação com o patrocinador
31
Os próximos itens consistem em apresentar soluções entre a comunicação da
equipe de projeto com o patrocinador.
3.2.4.1 Estabelecimento de prazos e metas aceitáveis
A partir do momento em que é definido um processo para a solicitação de
alterações no projeto é possível definir o tempo necessário para realizar a tarefa. Segundo o
RUP, a Solicitação de Mudança é um artefato formalmente submetido que é usado para
rastrear todas as requisições dos envolvidos, incluindo novas características, necessidades de
melhoria, reparos de defeitos, alteração nos requisitos, entre outros.
Todo o histórico de mudanças deverá ser mantido com a Solicitação de
Mudança, incluindo todas as mudanças de estado, datas e motivos para as mesmas. Estas
informações ficam disponíveis para revisões e para fechamento final. A vantagem desta
técnica é que é possível obter um registro das decisões e, devido a seu processo de avaliação,
garante que os impactos das mudanças sejam entendidos no projeto.
O Gerente de Controle de Mudança responde pela definição dos
procedimentos de gerenciamento de solicitações de mudança, isto as mantém controladas em
um sistema e permite que tudo possa ser previsto.
3.2.4.2 Redução de funcionalidades desnecessárias
Como mencionado anteriormente, por falta de entendimento no projeto pode
ocorrer de o cliente solicitar funcionalidades que fogem do escopo do projeto. Como solução
a este problema o SCRUM sugere que quando elementos do plano são considerados
desnecessários, são removidos, e somente a equipe de desenvolvimento pode alterar o escopo
do projeto e realizar as mudanças.
3.3 NÍVEIS DE MATURIDADE NA COMUNICAÇÃO
32
Para definir qual a metodologia deverá ser empregada em cada corporação,
objetivando a melhoria no processo de comunicação, primeiramente é necessário definir em
qual nível ela está no caminho da solução.
A melhor forma de alcançar este objetivo é classificar junto aos níveis de
maturidade o quanto o dia-a-dia da empresa está de acordo com as boas práticas descritas
nesse trabalho. Sendo assim, foi definido um conjunto de cinco níveis de maturidade na
comunicação conforme o Tabela a seguir.
Nível
Nível de Gerência
Descrição do nível
1
Nenhuma Gerência
Existe o conceito de hierarquia no recebimento da informação, entretanto
não são aplicadas técnicas para gerenciá-las.
2
Parcialmente
Gerenciado
A organização possui conhecimento sobre o processo de gestão de
comunicação, entretanto, não há processos de monitoramento e controle de
que a informação é recebida por todos os interessados e em tempo hábil.
3
Gerenciado
A empresa adota um padrão para os processos de gestão de comunicação,
ocorre o desenvolvimento de uma política de gestão de comunicação. São
definidos e executados os processos de monitoramento da informação,
porém não há atribuição de correções aos processos de entrega falhos.
4
Gerenciado e
Auditado
O processo de gestão da comunicação da empresa é auditado e sua
avaliação é utilizada para auxiliar na tomada de decisões, porém não há
um processo de melhoria contínua, o qual defina que os erros conhecidos
não voltem a acontecer.
5
Melhoria Contínua
A empresa atinge o nível de excelência, pois consegue estimar e entregar
de forma precisa os níveis de comunicação aos envolvidos no projeto, e
utiliza-se também da melhoria contínua com base nas lições aprendidas.
Tabela 7 – Níveis de Maturidade na Organização
O maior objetivo da solução é auxiliar a empresa a chegar ao nível de
Melhoria Contínua. Para que isso seja possível são definidas uma série de processos para que
um novo nível seja alcançado. O diagrama a seguir indica quais tarefas devem ser realizadas
para que a equipe amadureça mais um nível.
33
Figura 2 – Evolução dos Níveis de Maturidade
A definição do nível atual da equipe é obtido pela aplicação de um
questionário específico para cada grau. Este questionário consiste em três perguntas para cada
nível, sendo que caso o resultado seja positivo em todas as questões, o questionário do
próximo nível é aplicado, terminando apenas em dois casos: alguma questão não foi
34
respondida, então a empresa permanece naquele nível ou todas as questões de todos os níveis
estão respondidas, a empresa precisa apenas manter a melhoria contínua. A Figura 3.3b
exemplifica o processo.
Figura 3 – Fluxo de Trabalho nos Níveis de Maturidade
Por fim, a figura a seguir demonstra quais questões devem ser aplicadas em
cada nível. A formulação das questões tem como objetivo definir características inerentes de
cada nível de maturidade e evitar que a empresa esteja fora da sequência. Considera-se no
nível atual no caso de alguma resposta do nível aplicado seja negativa mesmo que nos níveis
superiores as respostas sejam positivas.
35
Nível
Análise de Maturidade
1
2
3
Existe o conceito de hierarquia no recebimento da informação?
Existe uma verificação do recebimento hierárquico da informação?
Existe uma linguagem objetiva que seja tanto compreensível para o cliente quanto
completa para os desenvolvedores?
2
1
2
3
É definida uma metodologia de controle na circulação da informação dentro da equipe?
As reuniões com a equipe são documentadas?
Existe uma padronização dos termos praticada dentro da equipe?
3
1
2
3
Existe uma política de gestão da comunicação dentro da empresa?
Existe uma verificação quanto ao cumprimento da política de gestão da comunicação?
As modificações solicitadas são documentas e avaliadas por meio de reuniões?
1
Existe um repositório de acesso comum com as informações coletadas ao longo de
desenvolvimento?
Existe uma documentação dos artefatos criados pela equipe de modo a evitar o
retrabalho?
Existe um processo de auditoria na gestão da comunicação?
1
4
2
3
5
1
2
3
Há revisões constantes dos processos existentes?
Existe um acompanhamento e avaliação das novas metodologias que surgem no
mercado?
Existem alterações nos processos conforme as novas metodologias avaliadas?
Tabela 8 – Questionário de Classificação nos Níveis de Maturidade
36
4 CONCLUSÕES
Finalizando as soluções propostas por este trabalho, serão apresentadas as
últimas considerações sobre como resolver os problemas de comunicação em gerência de
projetos de softwares e os possíveis trabalhos futuros que podem utilizar deste como
referência ou início.
4.1 CONSIDERAÇÕES FINAIS
Diante dos conceitos apresentados e com base nas melhores práticas
existentes em gerência de projetos de desenvolvimento de software e soluções dos possíveis
problemas em manter as informações neste ambiente circulando de forma com que seja exata
e de prontidão, é provado que a comunicação é o fator chave de sucesso em um bom projeto
de desenvolvimento.
Metodologias como o ITIL, CMMI, RUP e COBIT, geridos por um projeto
em concordância com o PMBOK, auxiliam o desenvolvimento de software, porém, nenhum
deles cobre de maneira satisfatória todos os problema de comunicação que podem ocorrer em
um projeto. Este trabalho demonstrou os melhores conceitos, individualmente em cada um
dos frameworks, que constroem um processo de comunicação bem definido, baseado em
planejamento em que seja possível de assegurar a hierarquia e a garantia de recebimento.
4.2 TRABALHOS FUTUROS
Utilizando dos métodos proposto neste trabalho, o gerenciamento de um
projeto de desenvolvimento pode alcançar a comunicação eficaz tanto almejada para o
sucesso em todos os processos e total aceitação dos clientes e patrocinadores.
Cada processo de um projeto de desenvolvimento pode aplicar
individualmente este artigo para resolver seus específicos problemas de comunicação, tendo
em mente que em muitos cenários a comunicação não necessariamente é um caos total, mas
sim podem acontecer fatores específicos como má aceitação, dificuldade na recepção, falha na
hierarquia, dentre outros. Lidando especificamente com determinados problemas de
comunicação, serão alcançados os níveis desejados de aceitação e a comunicação será parte
de um processo constante de um projeto de sucesso.
37
5 REFERÊNCIAS
KERZNER, Harold. Project Management: A Systems Approach to Planning Scheduling and
Controlling. 8ª edição Hoboken, New Jersey: John Wiley & Sons, Inc, 2003. 914 p.
PROJECT MANAGEMENT INSTITUTE. Um guia do Conhecimento em Gerenciamento de
Projetos: Guia PMBOK. 4ª edição Newton Square, Pennsylvania: Project Management
Institute, 2008. 337 p.
TRINDADE, Daniela De Freitas Guilhermino. Uma feramente para gerenciar a comunicação
em um ambiente distribuído de desenvolvimento de software. 2008. 123 f. Dissertação
(Mestrado) - Departamento de Programa de Pós-graduação em Ciência da Computação,
Universidade Estadual de Maringá, Maringá, 2008.
PROJECT MANAGEMENT INSTITUTE, Inc. Um guia do conhecimento em gerenciamento
de projetos. Guia PMBOK. 4.ed., 2008.
MACHADO, C, BURNETT, R. Gerência de Projetos na Engenharia de Software em Relação
as Práticas do PMBOK. PUC Curitiba, 2005.
MOLENA, Airton, A comunicação na gestão de projetos. Revista Eletrônica “PRODAM
Tecnologia”, 2009.
KERZNER, H. Project Management - A System Approach to Planning, Scheduling and
Controlling, 8º ed., New York, John Wiley & Sons Inc.,2003.
GIBBS W. Software's Chronic Crisis. Scientific American Magazine, setembro, 1994.
MARTINS, J.C.C. Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e
UML. 1. ed. Rio de Janeiro: BRASPORT, 2006.
MAXIMIANO, A.C.A. Administração de Projetos – Como transformar ideias em resultados.
São Paulo: Ed. Atlas S.A., 1997.
COSTA, Augustus X., et al. (2011), “Um Processo de Gerência de Comunicação Baseada no
PMBoK para o Desenvolvimento Distribuído de Software”, II Workshop de Desenvolvimento
distribuído de Software – WDDS.
MOZZOQUATRO, Patrícia M., SCHWADE, Darlan E. (2010), “Gerencia de Comunicação
como Garantia de Sucesso em Projetos de TI”, UNICRUZ
PMI (2008), “Um Guia do Conhecimento em Gerenciamento de Projetos”, 4ª Ed. PMI,
Newtown Square.
LOPES SHERON M. C, et al. (2010), “Governança de TI – um estudo sobre ITIL e COBIT”,
VII SEGeT – Simpósio de Excelência em Gestão e Tecnologia.
(2007) “COBIT 4.1” IT Governance Institute
38
(2011), “Um guia definitivo para o Scrum: As regras do jogo”, Scrum.org
KROLL, Per; KRUCHTEN, Philippe. The Rational Unified Process Made Easy: A
Practitioner. reimpressão. Addison-wesley Professional, 2003. 416 p.
CARNEGIE
MELLON
UNIVERSITY.
CMMI
Overview.
Disponível
em:
<http://www.sei.cmu.edu/cmmi/?location=secondary-nav&source=652373>. Acesso em: 27
set. 2012.
IRIS PROCESS CENTRAL. MSF for CMMI Process Improvement. Disponível em:
<http://process.osellus.com/sites/wiki/MSF for CMMI Process Improvement/>. Acesso em:
01 out. 2012.
IBM. Disponível em <http://www-01.ibm.com/software/awdtools/rup/>. Acesso em: 12 dez.
2012.
SCRUM.ORG. <http://scrum.org/Resources/What-is-Scrum>. Acesso em: 12 dez. 2012.