Lei do BEM: Um incentivo à Inovação Tecnológica

Lei do BEM: Um incentivo à Inovação Tecnológica

(Por Reginaldo Lazarini)

.

A Lei do BEM, Lei de número 11.196 de 21 de Novembro de 2005, sob a responsabilidade e gestão da Secretaria de Desenvolvimento Tecnológico e Inovação (SETEC), do Ministério da Ciência, Tecnologia e Inovação (MCTI),  dispõe, dentre outros, no seu Capítulo III, sobre os Incentivos à Inovação Tecnológica. E no corpo do seu Decreto Regulamentador, número 5.798 de 7 de Junho de 2006, que regulamenta os incentivos fiscais às atividades de pesquisa tecnológica e desenvolvimento de inovação tecnológica, está definido claramente o que é considerado como Inovação Tecnológica.

.

Essa ampla definição de Inovação Tecnológica abrange desde a concepção de novo produto ou processo de fabricação bem como a agregação de novas funcionalidade ou características ao produto ou processo. A abrangência da definição de Inovação Tecnológica é o que torna a Lei convidativa às Empresas que investem em P&D&I no país.

.

Lembrando apenas que, esse incremento de novas funcionalidades em produto ou processo já existente deve implicar em melhorias incrementais e efetivo ganho de qualidade ou produtividade aos produtos (bens ou serviços) resultando uma maior competitividade no mercado.

.

Para efeitos da referida Lei, são consideradas atividades de Pesquisa Tecnológica e Desenvolvimento de Inovação Tecnológica:

• a pesquisa básica, realizada com o objetivo de adquirir conhecimento quanto à compreensão de novos fenômenos;
• a pesquisa aplicada, com o objetivo de adquirir novos conhecimentos, com vistas ao desenvolvimento ou aprimoramento de produtos, processos e sistemas;
• o desenvolvimento experimental, para os trabalhos sistemáticos, visando a viabilidade técnica ou funcional de novos produtos, processos, sistemas e serviços,
• a tecnologia industrial básica, aquelas tais como aferição e calibração de máquinas e equipamentos; e
• os serviços de apoio técnico, indispensáveis à implantação e à manutenção das instalações e equipamentos destinados à execução de projetos de pesquisa, desenvolvimento ou inovação tecnológica.

.

As Empresas que investem em projetos de P&D&I e em Inovação Tecnológica, conforme definido na Lei do BEM, poderão usufruir de incentivos fiscais, dentre eles: dedução, para efeito de apuração do lucro líquido, de valor correspondente à soma dos dispêndios com pesquisa e desenvolvimento de inovação tecnológica; adicionalmente, poderá excluir do lucro líquido, na determinação do lucro real e da base de cálculo da CSLL (Contribuição Social sobre o Lucro Líquido), o valor correspondente a até 60% da soma dos dispêndios realizados no período de apuração; esse valor poderá chegar a 100% adicionais caso a Empresa contrate empregados pesquisadores para os projetos de P&D&I e caso obtenha patente concedida ou cultivar registrado vinculados à pesquisa tecnológica e desenvolvimento de inovação tecnológica; redução do IPI incidente sobre equipamento, máquinas, aparelhos e instrumentos destinados à pesquisa e ao desenvolvimento de inovação tecnológica; depreciação acelerada (2x) na aquisição de máquinas, aparelhos e instrumentos novos, destinados EXCLUSIVAMENTE à P&D de Inovação Tecnológica (Projeto de P&D&I) – chamados tangíveis; amortização acelerada na aquisição de bens intangíveis (licenças, etc), vinculados EXCLUSIVAMENTE às atividades de P&D de Inovação Tecnológica; crédito de IR retido na fonte de remessas para o exterior de royalties, assistência técnica ou científica e de serviços especializados, de contratos de transferência de tecnologia; e, redução a zero da alíquota do IR na fonte nas remessas efetuadas para o exterior destinadas ao registro e manutenção de marcas, patentes e cultivares.

.

Importante ressaltar que todos os dispêndios e pagamentos de que tratam a referida Lei, deverão ser controlados contabilmente em contas ESPECÍFICAS do projeto (ou programa).

.

A Empresa beneficiária dos incentivos fiscais de que trata esta Lei do BEM e seu Decreto Regulamentador, fica obrigada a prestar ao Ministério da Ciência, Tecnologia e Inovação, em meio eletrônico, conforme instruções específicas disponibilizadas anualmente no site do MCTI, informações sobre seus programas de pesquisa e desenvolvimento de inovação tecnológica, até 31 de Julho de cada ano. Tais informações, incluem descritivos dos projetos de P&D&I, com os respectivos resultados alcançados e contendo dados econômico-financeiros de cada programa/projeto apresentado, dentre outras informações obrigatórias sobre a Empresa e suas atividades.

.

Todo o trabalho relacionado ao cumprimento das obrigações da Lei do BEM demanda um acompanhamento particular e detalhado de cada programa ou projeto ao longo de cada ano, com controle de despesas por projeto e por centro de custo, acompanhados de informações de todas as áreas da Empresa, para inserção e preenchimento da ferramenta (FORM P&D) que alimenta o banco de dados na SETEC. Isso tudo demanda o trabalho de uma equipe de profissionais experientes e qualificados que atuam em consonância com as diversas áreas correlatas da Empresa (financeira, jurídica, contratos, RH, P&D, impostos, etc). Atualmente, muitas consultorias e profissionais prestam esse tipo de trabalho para as Empresa em geral, garantindo a qualidade dos relatórios a serem enviados ao Ministério da Ciência e Tecnologia e a conformidade com os Manuais e Procedimentos exigidos pelo MCT/SETEC.

.

Maiores informações sobre a Lei do BEM e sobre Inovação Tecnológica poderão ser obtidas no próprio sítio do MCT/SETEC.

.

Autor: Eng. Reginaldo Lazarini (MsC).

Profissional da área de P&D nas Empresas Ericsson, CPqD Telecom & IT Solutions e Telebrás.

Consultor para assuntos de Lei de Informática, Lei do BEM, Projetos, Incentivos Fiscais e Gestão de P&D.

Contatos: (19) 3287-0446 e (19) 9742-0504

.

Links relacionados:

Lei do Bem – Link1

Lei do Bem – Link2

Gestão da Inovação (Ulbra)

Lei de Informática: Incentivos e Obrigações

Lei de Informática: Incentivos e Obrigações

(Por Reginaldo Lazarini)

.

.

A Lei de Informática, baseada no tripé produção incentivada-comercialização de produtos com Portaria PPB (Processo Produtivo Básico)-investimentos em P&D, beneficia as Empresas que investem em atividades de pesquisa e desenvolvimento (P&D) com o pleito da isenção ou redução do Imposto sobre Produtos Industrializados (IPI) para bens de informática e automação.

.

Para efeitos da referida Lei, são consideradas atividades de P&D: o trabalho teórico ou experimental, realizado de forma sistemática, sem prévia definição para o aproveitamento prático dos resultados; o trabalho sistemático, utilizando conhecimento adquirido na pesquisa ou experiência prática; os serviços científicos e tecnológicos, de assessoria, consultoria, estudos, ensaios, metrologia, normalização, etc, desde que associadas a quaisquer das atividades relacionadas ao trabalho teórico ou experimental e trabalho sistemático; e a formação ou capacitação profissional, de níveis superior e médio.

.

O benefício da redução do IPI varia em função do produto fabricado pela Empresa, em função da localização da fábrica e de acordo com o ano vigente de fabricação. Atualmente, essa redução é de 80% para produtos produzidos em qualquer ponto do território nacional, fora da Região Centro-Oeste, das regiões de influência da Agência de Desenvolvimento da Amazônia (ADA) e da Agência de Desenvolvimento do Nordeste (ADENE), sendo tal percentual válido até Dezembro de 2014.

.

Como contrapartida, as Empresas de desenvolvimento ou produção de bens e serviços de informática e automação que se beneficiarem de tal redução no IPI, deverão investir anualmente, em atividades de pesquisa e desenvolvimento em tecnologias da informação a serem realizadas no País, 4% (índice válido até Dezembro de 2014) do seu faturamento bruto no mercado interno, decorrente da comercialização dos produtos contemplados com a isenção ou redução do imposto (os chamados produtos com PPP). O “breakdown” de tal investimento em P&D por parte da Empresa consta do texto do Decreto Regulamentador 5.906 de 26 de Setembro de 2006, que poderá ser encontrado no sítio do Ministério da Ciência e Tecnologia, sendo que parte do investimento em projetos de P&D poderá ser realizado internamente a Empresa (os chamados investimentos extra-convênio) ou externamente em parcerias com Universidades e Instituições de Ciência e Tecnologia, os ICTs públicos e privados com certificação CATI (em convênio pelo termo usual).

.

Como decorrência da obrigação legal da contrapartida, ou seja do investimento em atividades de Pesquisa e Desenvolvimento, as Empresas deverão encaminhar ao Ministério da Ciência e Tecnologia (Secretaria de Política de Informática – SEPIN), até o dia 31 de Julho de cada ano, os relatórios demonstrativos do cumprimento das obrigações estabelecidas no Decreto 5.906, relativas ao ano-calendário anterior, incluindo informações descritivas das atividades de pesquisa e desenvolvimento previstas no projeto, ou nos projetos elaborados, com os respectivos resultados alcançados. Tais relatórios demonstrativos deverão ser elaborados em conformidade com as instruções baixadas pelo MCT, contendo toda a descrição econômica-financeira de cada projeto apresentado, dentre outras informações obrigatórias.

.

Todo o trabalho relacionado ao cumprimento das obrigações da Lei de Informática demanda um acompanhamento particular e detalhado de cada projeto ao longo de cada ano, com controle de despesas por projeto e por centro de custo, acompanhados de informações de todas as áreas da Empresa, para inserção e preenchimento da ferramenta que alimenta o banco de dados na SEPIN. Isso tudo demanda o trabalho de um equipe de profissionais experientes e qualificados que atuam em consonância com as diversas áreas correlatas da Empresa (fábrica, financeira, jurídica, contratos, RH, P&D, vendas, etc). Atualmente, muitas consultorias prestam esse tipo de trabalho para as Empresa de TI, garantindo a qualidade dos relatórios a serem enviados ao Ministério da Ciência e Tecnologia e a conformidade com os Manuais e Procedimentos exigidos pelo MCT/SEPIN.

.

Maiores informações sobre a Lei de Informática poderão ser obtidas no próprio sítio do MCT/SEPIN.

.

Autor: Eng. Reginaldo Lazarini (MsC).

Profissional da área de P&D nas Empresas Ericsson, CPqD Telecom & IT Solutions e Telebrás.

Consultor para assuntos de Lei de Informática, Lei do BEM, Projetos, Incentivos Fiscais e Gestão de P&D.

Contatos: (19) 3287-0446 e (19) 9742-0504

Links relacionados:

Sepin vai ser mais rigorosa na análise de projetos incentivados

Consultoria em Gestão de Projetos

Ótimo post sobre como avaliar e escolher uma consultoria em Gestão de Projetos:

Perguntas e respostas sobre Consultoria em Gestão de Projetos

Gerenciamento Estrategico

Metodologia ágil ou tradicional: porque não as duas?

Os modelos ágeis de gestão vem ganhando cada vez mais espaço nas organizações, mas nem sempre são bem aceitas ou entendidas por gerentes/executivos acostumados com o gerenciamento de projetos no modelo tradicional (em cascata, ou waterfall). As discussões sobre vantagens e desvantagens de cada modelo são, muitas vezes, inflamadas e polarizadas, onde cada um dos lados tenta doutrinar o outro.

Por mais que cada modelo ofereça uma série de vantagens e desvantagens (que devem ser avaliadas por cada organização e, mais especificamente, cada tipo de projeto) o que eu tenho visto é que a implementação “pura” de um modelo ou de outro é muito rara. Poucos são os lugares onde o gerenciamento do projeto segue dogmaticamente os preceitos (“boas práticas”) listadas no PMBoK ou que executem todos os seus projetos usando Scrum, por exemplo. Se olharmos criticamente um conjunto de projetos de determinada empresa é muito provável que vejamos a utilização de práticas de ambos modelos.

O objetivo desse post é compartilhar uma experiência onde tive a oportunidade de trabalhar com os dois modelos simultaneamente no mesmo projeto, e discutir sobre os ganhos percebidos, dificuldades encontradas e adaptações (tailoring) necessárias.

Histórico do projeto

O projeto tratava do desenvolvimento de uma inovação em um produto do cliente, cuja janela de inserção no mercado era bem definida (e restrita). Os requisitos do sistema, por sua vez, eram bastante complexos, e ainda não totalmente especificados (o que ocorreu ao longo do projeto).

Devido à importância estratégica do projeto o cliente necessitava validar entregas parciais e ter algumas funcionalidades implementadas em versões de demonstração do produto para ser utilizado em “Road Shows”. Assim, uma das ações para garantir a execução desse trabalho foi o estabelecimento de um contrato para a alocação de um time de tamanho fixo durante um período determinado.

Considerando as características do projeto o modelo de desenvolvimento escolhido foi o Scrum, uma vez que este permitiria tratar o desenvolvimento do produto de forma incremental e ainda assim garantir a qualidade do produto e do processo (outro requisito importante para o cliente).

No entanto, apesar de entender o funcionamento do modelo “puro” do Scrum o cliente demandou um acompanhamento nos moldes tradicionais, considerando um projeto “waterfall” e artefatos previstos no modelo de maturidade CMMi. Com isso, por exemplo, foram criados o cronograma macro de entregas descrito em um gráfico de Gantt, algumas métricas de acompanhamento de valor agregado e relatórios de status semanais.

Desafios

Em virtude dessa gestão “mista” foi necessário avaliar processos e práticas das duas correntes de pensamento e avaliar criticamente o uso das mesmas no projeto, tendo em mente a não duplicação do trabalho e a otimização do tempo e esforço para a gestão do projeto, com a garantia do atendimento das expectativas dos stakeholders.

Como resultado dessa análise alguns processos tiveram de ser adaptados. Já alguns outros continuaram a ser executados da mesma maneira, uma vez que o resultado produzido era o mesmo ou não apresentava diferenças significativas usando um dos métodos.

Os ajustes no processo foram sendo feitos e validados com o cliente ao longo do projeto, com o consequente mapeamento das práticas e grupos de processos de modo a gerenciar o projeto de forma eficiente.

A prática 

As principais disciplinas exercidas durante o projeto estão listadas a seguir, juntamente com uma explanação de como elas foram executadas.

Gestão do escopo

O escopo do projeto foi dividido em pacotes de trabalho, sendo que cada requisito foi detalhado pelo analista de requisitos para a criação do product backlog do projeto. No entanto, diferentemente de um projeto ágil puro, toda a quebra dos requisitos em estórias e atividades foi feita durante o planejamento do projeto e o backlog resultante foi usado como guia para o planejamento das iterações (sprints).

Quaisquer mudanças nos requisitos do projeto, seja por entendimento dos mesmos ou por alteração do escopo original, foram tratadas através de um procedimento de “Solicitações de Mudança” (Change Requests), onde as mudanças eram analisadas, detalhadas e incluídas no product backlog.

Gestão do cronograma

Apesar do projeto ter sido executado usando Scrum o conteúdo de cada iteração foi definido com base na priorização do backlog feita pelo Product Owner ainda durante a fase de planejamento. Como o conteúdo de cada iteração estava, em grande parte, definido de antemão a reunião de planejamento de cada sprint focava no balanceamento de volume de trabalho (esforço) e força produtiva disponível (capacidade), além de fazer adaptações necessárias na velocidade do time e incorporação de atividades remanejadas de outros sprints.

Como o Gerente de Projetos do cliente precisava ter visibilidade do projeto como um todo, foi criado um cronograma no MS-Project para acompanhar a execução de cada requisito, sendo que os milestones definidos continham um subconjunto de requisitos que seriam implementados. O cronograma era acompanhado com base no progresso dos sprints, e servia como referência para coleta de métricas do projeto.

O acompanhamento do projeto se dava tanto pelo cronograma de funcionalidades quanto pelo gráfico de burndown de cada sprint. Os dados do cronograma eram usados para informar o progresso do projeto como um todo, enquanto o burndown indicava o progresso de cada sprint.

Gestão do custo

Como o time de projeto era fixo a gestão dos custos do projeto limitou-se ao controle de despesas, o que simplificou a tarefa. Os índices de valor agregado derivavam diretamente dos dados inseridos no MS-Project.

Gestão da comunicação

O plano de comunicação foi criado no início do projeto após a identificação de todos os stakeholders. Para cada tipo de informação a ser divulgada foi definida a periodicidade e sua audiência, bem como o propósito e o responsável pela coleta e divulgação de cada informação. O time de projeto era informado regularmente através das reuniões diárias e demais cerimônias (planning, review) do sprint. Já a alta gerência e o cliente eram informados através de relatórios semanais de progresso.

Um mapa com papéis e responsabilidades de cada stakeholder foi criado e divulgado, de modo a tornar público todos os canais de informação do projeto.

Gestão de riscos

O processo de identificação e análise qualitativa dos riscos, bem como o planejamento de resposta aos mesmos, seguiu o processo tradicional, com o uso de uma planilha de acompanhamento atualizada semanalmente, sendo que o time e demais stakeholders eram envolvidos no processo através das reuniões diárias, reuniões periódicas de status e cerimônias do Scrum.

Gestão da qualidade

O projeto seguiu um processo de desenvolvimento aderente ao CMMi e foi acompanhado por um analista da área de Qualidade, que auditava periodicamente (a cada final de sprint) as entregas (artefatos) do mesmo. A qualidade era garantida através da criação e acompanhamento de itens de “Não Conformidade” em ferramenta específica, que eram enviados ao cliente mensalmente.

Gestão de RH:

A alocação de pessoas foi facilitada pelo fato do time ter um tamanho fixo ao longo de todo o projeto. Como a estrutura da empresa é do tipo matricial o gerente funcional era responsável pela alocação das pessoas, mas uma vez definido o time com as habilidades necessárias (com base no escopo definido) o esforço de gestão foi reduzido, limitando-se ao planejamento e controle de ausências ocasionais e períodos de férias, bem como, obviamente, ao acompanhamento do desempenho dos membros da equipe.

Gestão de aquisições:

Não foi necessário durante o projeto.

Conclusão

A amostra de projetos executados com essa metodologia é pequena e limitada aos projetos que eu gerenciei para esse cliente específico mas, apesar do trabalho inicial de análise ter tomado algum tempo, os resultados foram bastante satisfatórios.

O gerente de projetos do cliente ficou satisfeito por ter a visibilidade que precisava, e os produtos dos projetos foram entregues no prazo e com qualidade necessária. Um resultado adicional, que comprova a eficiência do modelo, é que ele tem sido adotado inclusive por outros parceiros com quem esse cliente executa projetos.

E você, tem alguma experiência desse tipo?

Eamon Sousa

Posts relacionados:

• Gerenciando projetos ágeis
• Análise de processos
• Projeto de adoção do Scrum
• Gestão de Projetos: Operacional x Estratégico
• PMBOK x SCRUM: como gerenciar um projeto de software?

Análise de Processos

Quando falamos em processos, muitas vezes, estamos procurando maneiras (métodos) de dar maior eficiência e eficácia ao trabalho nas organizações, onde termos como redução de custos, incremento da competitividade, melhoria da qualidade, entre outros, são bastante comuns.

Uma ferramenta que pode auxiliar neste sentido é a Gestão por Processos, que procura mapear e implementar os procedimentos organizacionais através de ferramentas de gestão (como os ERPs).

Entretanto, durante este processo – de criação e implantação de procedimentos e metodologias padronizadas (ou de sua revisão, já que processo ‘tem’ prazo de validade) – é preciso avaliar adequadamente o produto deste trabalho.

Alguns questionamentos pertinentes para aumentar as chances de sucesso no uso dos processos estabelecidos são:

• O processo (e cada uma de suas atividades) é realmente necessário?
• Este processo ou atividade agrega valor para a organização?
• Qual sua função desse processo/atividade na empresa?
• Este processo/atividade atende aos objetivos previamente definidos?
• Este processo/atividade pode (ou deve) ser melhorado?
• Todas as atividades definidas no processo precisam (e efetivamente, são) executadas?
• Este processo está adequado às demandas do mercado?

No Gerenciamento de Projetos (assim como apresentado no PMBoK) temos estabelecidos alguns Grupos de Processos de gestão que procuram estabelecer um fluxo de trabalho adequado para cada uma das fases do projeto. Estes grupos de processos foram apresentados nos posts seguintes:

• Série: Gestão de Projetos – Iniciação #1
• Série: Gestão de Projetos – Planejamento #2
• Série: Gestão de Projetos – Execução #3
• Série: Gestão de Projetos – Monitoramento e Controle #4
• Série: Gestão de Projetos – Encerramento #5

Giovani Faria

Meus posts

Implantação de PMO – Os ‘Sim’ e os ‘Não’

Decidir pela implantação de um Escritório de Projetos (PMO) é uma tarefa que exige reflexão, objetivo e planejamento.

Para ajudar neste momento de reflexão e análise, algumas perguntas:

• Existe uma metodologia padronizada para a gestão de projetos?
• Existe um padrão para reportar desempenho de projetos na sua organização?
• A análise de dados e tomada de decisão é feita de maneira estruturada e uniforme?
• As lições aprendidas são documentadas? E utilizadas em novos projetos?
• O desenvolvimento de competências para gerir projetos é feito de maneira adequada e consistente?
• A maturidade gerencial da empresa pode ser considerada adequada às suas necessidades?

Se até agora sua resposta à todas (ou maioria) as perguntas foi sempre ‘Não’, você já tem bastante munição para discutir esta implantação com a alta direção (o “Sponsor”).

Mais algumas perguntas:

• A gerência de projetos é (ou deveria ser) considerada uma competência crítica para a organização?
• A otimização dos recursos (humanos, financeiros, infra) é fator crítico de sucesso para a organização?
• Os riscos precisam ser avaliados de maneira efetiva levando em consideração projetos anteriores (lições aprendidas) e aspectos organizacionais (eg. demais projetos em execução)?
• É necessária a implantação de métricas que auxiliem na visibilidade do desempenho dos projetos e na tomada de decisões?
• A organização possui diferentes projetos de alta criticidade que requerem atenção?

Se agora, a resposta predominante foi ‘Sim’, o que é que você está esperando para formatar uma apresentação e ‘vender’ esta ideia internamente na organização, procurando por parceiros em posições estratégicas no organograma da empresa?

O Projeto de implantação de um PMO é um desafio interessante e que, se executado com sucesso, pode se tornar fator de diferenciação competitiva para sua empresa.

Giovani Faria

Meus posts

O que é projeto?

Consultando qualquer referência bibliográfica, dentre elas o PMBoK, pode-se obter uma definição de projeto como sendo “um esforço temporário empreendido para criar um produto, serviço ou resultado único”.

Até aí, nenhuma novidade. Agora, colocando de forma ‘visual’ a estruturação inicial de um projeto, através de seu Termo de Abertura, temos:

Esta forma de apresentação é semelhante à utilizada nos chamados mapas mentais (link) para a estruturação de ideias, informações, etc.

Giovani Faria

Meus posts

Análise – Ferramentas ‘Ágeis’ de gerenciamento

Neste post, vamos avaliar algumas ferramentas para controle de projetos Ágeis.

Para explicar o contexto dessa avaliação de ferramentas para metodologias ágeis, a motivação inicial foi a de identificar ferramentas aderentes a essas metodologias de trabalho para utilização por equipes situadas em diferentes localidades.

Ferramenta 1: Sprintometer

Esta é uma ferramenta (link) que pretende “ser uma ferramenta ágil, simples e poderosa para o gerenciamento de projetos SCRUM e XP (Extreme Programming)”. Nota: para mais informações, acesse o site ou o Guia da ferramenta.

Em sua versão freeware, o Sprintometer é uma ferramenta de fácil uso. Possui uma interface agradável e bastante completa. Entretanto, é mais adequado para o uso em projetos pequenos onde a equipe de projeto é reduzida e, preferenciamente, esteja localizada no mesmo site.

Além disso, uma única pessoa (o scrum master, por exemplo) deve ficar responsável pela atualização de todos os dados na ferramenta. Esta restrição pode sobrecarregar o responsável (que muitas vezes pode ser um dos membros da equipe de desenvolvimento) o que causaria impactos no projeto.

Outro ponto importante é que seu uso é adequado para o controle de sprints de forma isolada. Ou seja, para o controle do Product Backlog a ferramenta não está preparada. Neste caso, a ferramenta requer que o controle dos itens do product backlog que já foram alocados em algum sprint seja feita pelo responsável pelas atualizações (ex. scrum master).

Ferramenta 2: Agilo/Trac

O Agilo é uma ferramenta Open Source para controle de projetos Scrum, construída sobre a ferramenta de rastreamento de falhas (bug tracking) Trac. Essa ferramenta deve ser instalada em um servidor interno e dá acesso aos membros do time à todas as informações do projeto.

Por ser baseada no Trac a interface da ferramenta se dá através da criação de tickets; a cada ação é criado um ticket na ferramenta, da criação do backlog e atividades ao report de falhas encontradas (a ferramenta também possibilita o controle de bug tracking). Quando o usuário acessa a ferramenta ele tem acesso direto aos tickets pertencentes a ele,e econsegue ver o status geral do projeto. Cada membro do time consegue também apropriar-se determinada atividade durante o projeto,e deve reportar o status na própria ferramenta.

Outra característica interessante é a facilidade de adicionar informações complementares na própria ferramenta, uma vez que ela usa a estrutura Wiki. Com isso é possível acrescentar, no corpo do projeto, informações gerais do projeto, resultados de reuniões de review, etc.

A ferramenta também gera o burndown chart e dá uma visão macro dos milestones do projeto (também cadastrados como tickets).

Ferramenta 3: RTC (Rational Team Concert)

De acordo com a própria IBM (link): “O Rational Team Concert integra o rastreamento de itens de trabalho, controle de gerenciamento de código fonte, builds contínuos, planejamento iterativo, e suporte a processos altamente configuráveis, que permite a adaptação à maneira que você quiser trabalhar. Possibilitando que desenvolvedores, arquitetos, gerentes de projetos e ‘owners’ de projeto trabalhar juntos eficientemente”.

Em uma análise preliminar, embora a proposta da empresa seja bastante ambiciosa, a ferramenta parece ser bastante completa, podendo atender à todas (ou a grande maioria) as necessidades do projeto.

Vamos analisar as primeiras impressões, dificuldades e sucessos na sua utilização. Vale mencionar que neste momento estamos implementando seu uso em projetos piloto para posteriormente colocá-la em ‘produção’ na organização.

Depois de algumas reuniões onde a ferramenta foi apresentada e as expectativas foram discutidas, veio a fase de configuração. Como a ferramenta possui muitas possibilidades, definimos o setup mínimo necessário para utilização nos projetos. Aqui, procuramos estabelecer quais funcionalidades e configurações seriam mais intensivamente utilizadas.

A intenção de restringir o uso das funcionalidades foi a de provocar o mínimo de impacto possível no projeto. Isso porque, entendemos que a introdução das funcionalidades (e potencialidades) da ferramenta deveria ser feita de maneira gradual e incremental. Com isso, além de evitar problemas no andamento das atividades da equipe, procuramos reduzir as dificuldades da equipe quanto a aplicação da nova ferramenta e a resistência em aceitar as mudanças propostas.

O projeto piloto ainda está em andamento, entretanto já dá para notar que a ferramenta possui muitas funcionalidades e, ainda é preciso deixar a equipe se acostumar a ela.

Links:

Aplicativos para Gerentes de Projetos

Giovani Faria / Eamon Sousa

Trabalho em Equipe e o Paradoxo de Abilene

Não é novidade dizer que problemas de comunicação nas empresas e nas equipes de trabalho causam interferências nas organizações e, em especial, nos projetos.

Tornar a comunicação eficaz é um desafio diário. A interação entre os interlocutores através dos canais e ferramentas de comunicação disponíveis (reuniões, conferências telefônicas, workshops, etc.) e, principalmente, os problemas causados pelas barreiras da comunicação (tais como ruídos, bloqueios, filtros pessoais, interferências, pressupostos, preconceitos, etc.), tornam este desafio ainda mais complexo.

Neste contexto, quando falamos do trabalho de equipe nos projetos, um dos problemas que pode acarretar em falhas na comunicação é conhecido como Paradoxo de Abilene, descrito por Jerry B. Harvey. Em seu enunciado, Harvey diz que “o consenso que é formado por um grupo de indivíduos é oposto à vontade de cada um individualmente”.  Por exemplo, você pode não querer participar de um evento qualquer, ou não concordar com as decisões tomadas em grupo, mas, por acreditar que existe um concenso entre os demais, acaba por ceder e dar sua anuência no assunto (sem no entanto, realmente se comprometer devidament). Entretanto, quando as pessoas começam a interagir e a manifestar suas ideias e opiniões, é que se nota que todos (ou a grande maioria) não queria estar ali ou discorda das determinações estabelecidas.

Então, vamos tratar especificamente do ambiente de execução projetos e tomando como base uma reunião de início de projeto. Neste momento, onde temos maior liberdade para delimitar os objetivos mais adequados para o projeto (quando os impactos das mudanças no projeto são menores) de modo a atingir as expectativas dos stakeholders envolvidos, é extremamente importante que a comunicação entre as partes seja fluida e efetiva. Ou seja, é importante garantir que todos estejam ‘sintonizados’ e comprometidos com os planos que estão sendo desenvolvidos/estabelecidos.

Nesta hora de definições, onde é importante garantir que as demandas das partes interessadas sejam devidamente ententidas, e também que todos se comprometam com os objetivos do projeto, é que as habilidades de comunicação, negociação e integração do gerente tornam-se essenciais para garantir o sucesso do projeto.

Para isso, o gerente do projeto deve analisar todos os aspectos da comunicação que envolvem a transmissão e recepção da informação (mensagem). Entre estes:

• O código utilizado: cuidar para que o idioma, jargão e gírias sejam devidamente entendidos por todos.
• As culturas envolvidas: evitar que diferentes modo de pensar e interpretar a informação, causem desvios de entendimento;
• A mensagem: garantir para que as informações (reports, acordos, etc.) sejam claros e objetivos. Além disso, pode lançar mão da utilização de diferentes recursos (textos, gráficos, tabelas) para tornar a mensagem bastante clara;
• O método: a fala, a escrita, as apresentações, as reuniões, enfim, é preciso avaliar a complexidade e quantidade de informações e utilizar de diferentes métodos para transmiti-las;
• A técnica: gestos, posturas, recursos (visuais, áudio). Quando o projeto conta com equipes dispersas geograficamente, a comunicação verbal requer especial cuidado;
• Feedback: observar as reações ( fisionomias) e interesse da plateia é importante recurso de avaliação da efetividade da comunicação. Além disso, pode-se também solicitar que determinadas pessoas  manifestem seu entendimento (o que é bastante interessante quando existem equipes ‘virtuais’ envolvidas).

E como se prevenir ou evitar que situações parecidas com o Paradoxo de Abilene ocorram no seu projeto?

• Proporcione um ambiente que incentive todos a expor suas idéias, garantindo que existe um correto entendimento da informação.
• Garanta que todos sejam ouvidos. Solicite feedback de cada um.
• Questione os “por quês” de cada opinião. O objetivo não é por em dúvida os argumentos, mas sim, fazer com que tudo seja devidamente apresentado e entendido.
• Instigue e envolva os participantes de modo a garantir que o projeto tem efetivamente seu comprometimento com os objetivos.
• Promova o debate. As discussões podem levar a um melhor entendimento dos aspectos do projeto sob diferentes pontos de vista.
• Integre as idéias. Faça com que todas as opiniões se juntem para os objetivos comum do projeto.

Enfim, é preciso fazer da comunicação uma importante aliada para o sucesso do projeto, e não uma fonte de geração de problemas potenciais.

Livro: The Abilene Paradox and other Meditation on Management

Concurso: O Paradoxo de Abilene foi tema de um concurso do BNDES em Março/2011.

Giovani Faria

Meus posts

Processo tem prazo de validade?

É possível ver que práticas, processos e procedimentos são adotados por longos períodos de tempo sofrendo apenas pequenas alterações.

Pensando nisso pode ocorrer o seguinte questionamento: O processo utilizado continua sendo válido?

Organizações e pessoas mudam a todo instante. As empresas são quase que obrigadas a se reinventar ciclicamente para atender aos novos mercados consumidores que demandam novos produtos, num ambiente onde as barreiras para a concorrência ficam cada vez menores.

Então, como se reinventar de maneira estruturada usando processos antigos que receberam somente ‘roupas novas’ com o passar do tempo?

Além disso, como fazer com que as pessoas – acostumadas a seguir determinados procedimentos e a utilizar ferramentas específicas – adotem novas metodologias de trabalho?

Os mais fervorosos podem dizer que não se pode fugir aos ‘mandamentos’ estabelecidos por processos e certificações consagradas no mercado. Embora seja inegável a sua contribuição na estruturação do trabalho e criação de uma linguagem comum (milestones, análise crítica, estimativas, etc.).

Já outros, menos adeptos dos padrões e ansiosos por novidades e ambientes ‘livres’ querem a abolição total das regras. O que, em certa extensão, pode levar ao caos e descontrole total.

Então, para onde deve (ou pode) pender esta balança? Entre os Processos Consagrados (mas antigos)  e os Processos Inovadores (mas inexplorados).

Quem vence esta batalha? Se é que precisamos ter algum vencedor.

Normalmente, a escolha pelo tipo de padrão (processo) a ser seguido é determinada pela própria corporação em função do seu histórico e resultados (“Em time que está ganhando não se mexe!” Será?). Entretanto, seu direcionamento estratégico também deve ser parte influente deste processo, uma vez que este deve estabelecer o caminho (o futuro) da empresa.

Empresas inovadoras se inventam (ou reinventam) constantemente. Entretanto, será que conseguem simplesmente ‘jogar fora’ seus processos e começar ‘do zero’, tudo de novo? Mesmo sendo esta uma alternativa interessante (e necessária), é também dispensiosa e requer grande esforço por parte da corporação.

Empresas ‘antiquadas’ trocam as roupas dos processos, mudam as ferramentas, mas, a essência continua sendo a mesma. Os problemas ou ‘defeitos’ do processo continuam por lá, escondidos. Entretanto, os resultados obtidos e a agressividade do mercado expõem algumas fragilidades que precisam ser atacadas.

Resumindo:

• Um visionário pode querer virar tudo de pernas para o ar, mas, talvez não encontre suporte na organização (recursos financeiros, humanos, etc.), ou seja, um sponsor para esta empreitada.
• Um conservador, bem, este é retranqueiro de carteirinha e não vai querer mudar, afinal, ‘já era assim antes de chegar aqui’.
• No meio termo, a avaliação de um ‘conservador moderno’ pode levar a conclusão de que, sim, é preciso reinventar (inovar), quebrar paradigmas, causar desconforto, enfim, mudar. Todavia, tudo isso com pé no chão e uma avaliação crítica do que serve e do que não serve mais.

Qual a melhor opção? Ou melhor, qual a sua posição nisso tudo?

Giovani Faria

Meus posts