3 dicas para se preparar para o exame CBPP – Certified Business Process Professional

CBPP – Certified Business Process Professional, concedida pela ABPMP Internacional, é certificação a mais valorizada atualmente no mercado brasileiro para os profissionais envolvidos em gestão por processos de negócio, e uma das mais importantes em caráter internacional.

É um grande investimento na carreira profissional de quem atua no mercado de BPM. Por isso, compartilhamos aqui algumas dicas interessantes para você que está se preparando para fazer o exame e se tornar um profissional de processos de negócio certificado.

1) Estude o BPM-CBOK

A base para esta certificação é o Corpo Comum de Conhecimento em Gerenciamento de Processos de Negócio (BPM CBOK), que atualmente encontra-se na sua terceira versão.
O BPM CBOK discute nove áreas de conhecimento sobre a Gestão por Processos distribuindo-as em duas perspectivas – a das atividades do ciclo de vida de processos  (gerenciamento de processos, modelagem, análise, desenho, gerenciamento de desempenho, e transformação de processos), e a da disciplina em nível organizacional (organização do gerenciamento de processos e gerenciamento corporativo). Além disso, também dedica uma área específica para tratar as diferentes tecnologias que suportam a prática de BPM nas organizações.

É importante conhecer bem os conceitos relacionados a cada uma dessas áreas de conhecimento.

Você pode iniciar seus estudos do BPM CBOK com a versão digital deste guia, que pode ser obtido através do próprio site da ABPMP Brasil:
http://www.abpmp-br.org/bpm-cbok-v3-0/

Se você precisar de uma ajuda para revisar a fixação dos conceitos, a iProcess Education tem um kit de Simulado para Exame CBPP, com cerca de 150 questões diferentes sobre todas as áreas de conhecimento do BPM CBOK e inspiradas no exame.
Saiba mais em: http://iprocesseducation.com.br/simulado_CBPP


2) Aproxime a prática do seu dia a dia às boas práticas recomendadas pelo BPM CBOK

O BPM CBOK não é um livro de instruções sobre como aplicar BPM, mas ele faz um alinhamento de questões relevantes e que devem se tornar práticas comuns entre os profissionais nesta disciplina de gestão de negócios.

Avalie o cenário atual da sua organização e trace paralelos com as práticas sugeridas pelo guia. É a melhor forma de fixar os conceitos e se alinhar com a visão de gestão por processos, além de uma excelente forma de avaliar o nível de maturidade da sua empresa no gerenciamento de processos de negócio.

Avalie também se você está preparado para se tornar um profissional CBPP. Como ela é uma certificação de proficiência em BPM, é preciso comprovar experiência para se submeter ao exame. Se precisar, invista em cursos que possam ajudar na sua preparação. 

A iProcess Education tem o compromisso de alinhar em seus treinamentos a teoria do BPM CBOK com a experiência prática dos diversos projetos pela nossa equipe.  Confira as próximas edições do programa de formação Ciclo BPM – Da Estratégia à Medição.


3) Participe do BPM Bootcamp e considere isto um valioso investimento

Com tantas oportunidades para se atuar no mercado de BPM, e tantos papéis diferentes em que uma pessoa pode se envolver, que é bastante natural que os profissionais acabem se especializando em algumas atividades ou conhecimentos específicos. Por exemplo:

  • Há profissionais de BPM que geralmente possuem uma formação em TI e quando entram no mercado de BPM, costumam ter um foco direcionado a projetos de automação de processos. Por isso sua visão da gestão por processos está mais associada à aplicação de soluções e plataformas tecnológicas para controle e monitoramento dos processos.
  • Há profissionais geralmente provenientes de formações relacionadas a O&M e qualidade, cuja especialidade está em modelar e padronizar processos organizacionais. Por isso sua visão de processos está mais relacionada à organização e documentação padronizada do conhecimento da execução de processos e a identificação e mitigação ou solução de potenciais riscos na variação da execução dos processos.
  • Há também os profissionais que atuam em projetos de análise, criando diagnóstico de processos e propondo redesenhos, muitas vezes com o objetivo de reduzir custos ou melhorar a qualidade.
  • Alguns possuem grande experiência em processos de um determinado nicho de negócio (como por exemplo os processos fiscais e tributários brasileiros, ou as particularidades dos processos na área de saúde), outros são mais generalistas, atuando com menos profundidade em uma variedade maior de processos.

As diferentes formas de atuar na disciplina de BPM faz com que a visão conceitual relacionada ao tema de processos tenha uma perspectiva diferente para cada um destes profissionais, e pode estar limitada ao seu conjunto de técnicas e práticas. O profissional CBPP precisa ampliar sua visão além da sua prática diária, devendo conhecer a disciplina BPM em todas as suas áreas de conhecimento, mesmo que sua atividade profissional esteja aprofundada em uma ou duas delas.

Por isso, considere a participação no BPM Bootcamp não como mais um custo para buscar a certificação, e sim como um investimento justamente na ampliação desta visão. O BPM Bootcamp oportuniza a discussão e troca de experiência com profissionais que atuam sob as mais variadas perspectivas da gestão por processos nas organizações e que estão, naquele momento, visando o mesmo alinhamento que você.

Geralmente, o BPM Bootcamp acontece nos dias que antecedem a data de exame para a certificação. Acompanhe a agenda de eventos da ABPMP Brasil e verifique qual o próximo BPM Bootcam e CBPP Exam mais próximo de você:

http://www.abpmp-br.org/

Outras dúvidas sobre o BPM Bootcamp podem ser obtidas diretamente com a equipe da ABPMP pelo email secretaria@abpmp-br.org.

 

Definindo a equipe nos projetos de BPM

Uma das primeiras dúvidas que costumam ocorrer quando uma empresa começa sua iniciativa de BPM é quais pessoas e perfis deveriam ser envolvidos nos trabalhos. Outro fator complicador é o fato de que podem existir variações na equipe envolvida, dependendo de etapa em que o projeto BPM se encontra.

Vamos começar revisitando, brevemente, as principais etapas do ciclo de melhoria de processos:

  • Modelagem de processos: neste momento o objetivo é modelar o processo atual em execução, gerando o modelo AS IS. Não se entra no mérito do quanto eficiente e efetivo o processo está sendo, ou quais são seus problemas/oportunidades de melhoria. As pessoas envolvidas nesta etapa, assim, devem ter conhecimento de como o processo é de fato executado na organização, mas não necessariamente precisam conhecer todos os seus problemas e ter uma visão mais abrangente
  • Análise de Processos: esta etapa tem o objetivo de coletar informações sobre o desempenho do processo, ou seja, fazer um julgamento de valor do quão adequado e eficiente um processo está sendo. Desta forma as pessoas escolhidas para atuar nesta etapa, além de conhecerem o processo, devem ser capazes também de identificar os problemas que ocorrem no processo e ter uma visão mais abrangente
  • Redesenho de Processos: esta etapa tem o objetivo de definir melhorias num processo para torná-lo mais eficiente e alinhado com os objetivos da organização, gerando o modelo TO BE. As pessoas escolhidas para atuar nesta etapa devem ser representativas dos papéis do processo, sendo importante estarem motivadas com a iniciativa BPM e carentes da mudança, de forma a auxiliar de maneira proativa a definição da visão futura do processo
  • Automação de processos: nesta etapa, o processo TO BE definido na etapa de Melhoria de Processos (TO BE) sofrerá melhorias do ponto de vista tecnológico, de forma a deixá-lo mais rápido, eficiente e automatizado onde for possível

Agora que relembramos as etapas, vamos listar os papéis comumente envolvidos em cada uma delas, descrevendo as suas típicas responsabilidades.

MODELAGEM DE PROCESSOS

Analista de Processos: atua como facilitador, coletando, reunindo e organizando informações do processo, criando o modelo do processo no nível de informação mais adequado
Representante Funcional: contribui com informações sobre as atividades que realiza durante a execução do processo
Analista de Sistemas/Negócios: apoia com informações sobre os sistemas de informação utilizados no processo
Especialista no Assunto: contribui com visão especializada sobre algum aspecto do negócio do processo (ex: um médico de alguma especialidade; num processo de venda online, seria um colaborador com profundo conhecimento da venda com cartões de crédito)

ANÁLISE DE PROCESSOS

Dono do Processo: avalia e aprova o resultado da análise, garante que a investigação dos problemas não será utilizada para achar culpados, mas sim como um meio de melhorar o processo e a organização
Analista de Sistemas/Negócios: apoia na identificação de problemas e limitações dos sistemas atuais
Representante/Líder Funcional: indica os pontos fortes, problemas e oportunidades de melhoria na execução das suas atividades do processo
Especialistas no Assunto: apoia no detalhamento de aspectos de uma determinada função do negócio
Analista de processos: facilitador que conduz o levantamento e documentação do diagnóstico atual do processo

REDESENHO DE PROCESSOS

Liderança Executiva: assegura que o processo irá atender as necessidades da organização, dando suporte e concordando com as mudanças
Dono do Processo: ajuda a garantir que o novo desenho se adéqua aos objetivos requeridos da organização
Representante Funcional/Participantes/Partes Interessadas: qualquer um que participe ou tenha atividades que afetem o processo. Em empresas maiores, pode ser a uma pessoa que represente uma classe. São fundamentais e trabalham com o Dono do Processo, para garantir que seus interesses no desempenho do novo processo sejam atendidos
Cliente: quando possível, envolvê-lo nesta fase aumenta as chances de sucesso
Analista de processos: atua como facilitador e lidera a equipe no desenvolvimento do desenho futuro do processo

AUTOMAÇÃO DE PROCESSOS

Dono do Processo: responsável pelos resultados do processo. Envolve-se na aprovação da proposição de melhorias e na apresentação da homologação, realizando a aprovação da solução automatizada
Gerente de Projetos: responsável por planejar e gerenciar as atividades do projeto de automação. Envolve-se na gestão da comunicação, tempo e custos do projeto em todas as etapas
Analista de Processos: apoia na revisão do processo, garantindo a integridade do negócio durante a avaliação das mudanças tecnológicas. Compartilha responsabilidade com o Analista de Sistemas na etapa de Proposição de Melhorias, envolve-se na validação do processo durante a homologação e implantação
Analista de Sistemas/Negócio: deve conhecer as funcionalidades disponíveis pela tecnologia a ser utilizada na automatização do processo. Compartilha responsabilidade com o Analista de Processos na etapa de Proposição de Melhorias. Responsável pelo detalhamento na implementação, apoia nas etapas de homologação e implantação
Arquiteto de Sistemas: profissional conhecedor da arquitetura de sistemas que suportará a automação de processos. Envolve-se na etapa de Implementação apoiando no projeto técnico com definições de infraestrutura de software
Desenvolvedor: profissionais que realizarão a implementação da automatização do processo, desenvolvendo os componentes de software conforme o detalhamento funcional do Analista de Sistemas/Negócio. Participam da etapa de implementação e de homologação através de correções e ajustes antes da implantação
Equipe de testes: profissionais responsáveis pela garantia da qualidade da solução. Verifica a aderência da solução à especificação funcional, sendo responsáveis pelo planejamento, elaboração e aplicação de roteiros de testes. Envolve-se nas etapas de implementação e homologação
Representante Funcional/Participantes do Processo: participam das etapas de Proposição de Melhorias para definir os requisitos e de Implementação para o detalhamento. Responsáveis pela homologação, validando a solução frente às expectativas e necessidades do negócio, através da verificação da aderência aos requisitos

OUTROS PAPÉIS IMPORTANTES NO GERENCIAMENTO POR PROCESSOS

Além disso, temos também papéis que costumam ser transversais, que dependendo do contexto e do papel podem se envolver em uma, algumas ou em todas as etapas:

Patrocinador e Dono do Processo: orientam sobre os objetivos da iniciativa e e asseguram que o resultado de cada uma das etapas estão adequados e alinhados aos objetivos da organização
Cliente: apoiando o levantamento e definições nas etapas
Designer de processos: atuando em conjunto com o Analista de Processos, focado na elaboração da representação gráfica dos processos
Arquiteto de Processos: responsável pela governança e manutenção do repositório de processos

Perceba que as definições acima refletem cenários comuns de ocorrer nas organizações, mas que não precisam ser seguidos à risca. Alguns exemplos em que é natural, e até esperado, existirem diferenças:

  • É muito frequente que algumas pessoas acumulem papéis/funções. Por exemplo:
    • O Dono do Processo também atua como Representante Funcional de alguma parte do processo
    • O Analista de Sistemas também é o responsável pelos testes
    • etc
  • Podemos ter projetos mais simples, em que não será necessária a participação de um ou mais papéis. Por exemplo, numa automação de processos com poucas integrações com sistemas externos, pode não ser necessária a participação de um Arquiteto de Sistemas
  • Se estamos falando de uma organização que está começando sua iniciativa de BPM, alguns papéis podem nem existir ainda, e precisarão ser definidos posteriormente, como costuma ser o caso do Dono do Processo

No final de contas, independente da quantidade de pessoas, nome dos papéis e quais papéis se deseja envolver formalmente na iniciativa, o importante é todas as pessoas chave estarem envolvidas, bem como todas as informações necessárias estarem disponíveis. Da nossa experiência, estes fatores aumentam consideravelmente as chances de um projeto de sucesso. :-)

 

Métodos para levantamento de informações na Modelagem e Análise de Processos – Parte 2

No primeiro artigo da série (veja aqui) falamos sobre os métodos Pesquisa, Entrevista e Observação Direta. Neste segundo e último artigo da série abordaremos o restante dos métodos utilizados para coleta de informações para o trabalho de modelagem.

WORKSHOP ESTRUTURADO

Workshop estruturado é um método utilizado para a coleta informações através de reuniões com os representantes dos papéis envolvidos no processo, reunindo diferentes pontos de vista, visando o detalhamento e a modelagem do processo de modo interativo.

photo credit: juhansonin via photopin (cc)

Agendamento do workshop

A escolha correta dos envolvidos é crucial para uma reunião produtiva, mas afinal como escolher as pessoas certas para a reunião?

  • Especialistas: Ninguém melhor para explicar um determinado processo do que as pessoas que trabalham nele. São os executores do processo, usuários do sistema ou membros de equipes operacionais com profundo conhecimento sobre certas funções ou operações de negócio. Quando em grande número são representados por usuários-chaves que se fazem presente no workshop. Representados normalmente pelos papéis de Representantes Funcionais ou Gestores Funcionais.
  • Liderança: Outro papel de importância na reunião é o do Dono do Processo, este é o responsável pelo processo ponta a ponta. Defende as prioridades e assegura que o processo atenda às expectativas de desempenho esperado pelo cliente. Não podemos esquecer também do Patrocinador, representado usualmente pela liderança executiva, gestores, diretor ou gerente da área responsável pelo processo. Apesar de não se envolver de forma integral, participa geralmente de reuniões estratégicas que determinam o caminho que o processo irá trilhar. Estes papéis possuem uma visão macro do processo.
  • Facilitador: Normalmente representado pelo Analista de Processos ou Designer de Processos. É o responsável pela condução adequada da reunião e por garantir que todos os participantes sejam ouvidos. Para isto deve ter a habilidade para lidar com pessoas, resolver conflitos e manter o foco no objetivo do workshop.

A divisão apresentada acima contendo especialistas, liderança e facilitador compreende uma abordagem mais estruturada e pode variar de empresa para empresa, levando em conta a sua maturidade em BPM. O mesmo vale para as convenções de nomenclaturas para os papéis descritos.

Outras questões que devem ser levadas em conta para escolha dos envolvidos:

  • O participante do workshop deve ter a competência e o conhecimento necessário para descrever suas atividades e se posicionar quanto suas divergências.
  • Os envolvidos devem ter bom relacionamento, para isto o facilitador deve se informar sobre conflitos de interesses e embates políticos entre gestores e equipes.
  • Disponibilizar uma agenda viável para todos os participantes.

Vantagens

  • Redução do tempo de desenvolvimento do modelo devido ao entendimento comum criado entre os participantes.
  • Resolução de conflitos no momento do workshop.
  • Redução do número de intermediadores evitando futuros problemas de comunicação.
  • Redução do tempo do acompanhamento das partes envolvidas na evolução do modelo final.
  • Facilitador com habilidades de técnicas de modelagem.
  • Facilitador com apoio de Designer de Processos (trabalho em dupla) na modelagem do processo; principais impactos na redução do tempo de execução e validação do modelo com processo aprovado na mesma reunião.

Desvantagens

  • Desgastes em deslocamentos / viagens – Participantes muitas vezes encontram-se em locais físicos distintos.
  • Altos custos de viagens.
  • Conciliar agenda dos participantes.
  • Custo com hora/homem  – 100% do tempo de todos ao mesmo tempo em reunião.
  • Evitar paralisia por análise – Seleção do escopo e escolha do processo e profundidade da análise devem ser definidos com muita clareza.

CONFERÊNCIA VIA WEB photo credit: JulianBleecker via photopin (cc)

A Conferência via web ou Videoconferência como também é conhecida, é um método semelhante ao Workshop Estruturado. Utilizado quando os participantes estão em locais físicos distintos e sem a disponibilidade para viagens.

Vantagens

  • Redução de custos de deslocamentos e viagens.
  • Redução no tempo de deslocamentos entre unidades.
  • Utilizado para se buscar um consenso sobre um mesmo processo desenvolvido em diferentes unidades.

Desvantagens

  • Não funcionam muito bem com grupos grandes.
  • Dificuldade de conduzir a participação individual dos participantes.
  • Baixa qualidade de áudio e vídeo.

Atenção para a infraestrutura tecnológica requerida que dependerá da necessidade de cada projeto/empresa. Alguns pontos devem ser observados:

  • Disponibilidades de equipamentos/periféricos de áudio e vídeo.
  • Qualidade de velocidade de banda da internet para transmissão, disponibilização de vídeo e eventuais imagens, acompanhamento em tempo real do processo que está sendo modelado.
  • Softwares apropriados para conferência.

FAZER EM VEZ DE OBSERVAR

photo credit: ColorTime via flickr (cc)

Método conhecido também como “aprendizado do aprendiz”, muito utilizado em tarefas repetitivas. Consiste em aprender o que é feito e então executar o processo.

Ao ensinar as atividades, podem surgir informações de tarefas e passos que ocorrem de forma inconsciente, isto permite que o observador tenha um conhecimento mais detalhado das tarefas realizadas.

A execução do processo pelo observador pode ajudar a coletar alguns detalhes das atividades que de outra forma não seriam observados. Sempre que possível, é interessante ter um segundo membro da equipe observando o processo de aprendizagem para auxiliar na identificação de detalhes das atividades.

ANÁLISE DE VÍDEO photo credit:  Flickmor via flickr (cc)

Similar à observação direta  (veja mais sobre o método Observação Direta no artigo anterior), a análise de vídeo auxilia na identificação de evidências à distância e permite que o executor realize suas atividades de forma mais natural.

A presença de um equipamento de gravação permite uma adaptação mais rápida do que a de um observador ao seu lado.

Outra vantagem é que os vídeos podem ser mais tarde assistidos pelo executor e este narrar suas atividades e ações executadas fora do campo da lente, isto auxilia na identificação de informações não vistas pelo observador.

SIMULAÇÃO DE ATIVIDADES

photo credit: Wonderlane via flickr (cc)

A simulação de atividades é utilizada para identificar possíveis falhas humanas e desvios na execução do processo. Uma forma de simulação seria, durante a entrevista ou workshop, a realização de uma análise apurada do comportamento de cada atividade do fluxo do processo. Esta análise consiste em avaliar o que dispara esta atividade (entradas), seu resultado (saídas) e regras estabelecidas para execução desta atividade.

 

Como falamos nos dois artigos, cada método tem suas vantagens, desvantagens e o esforço necessário para que possa ser realizado. Questões como tempo requerido, altos custos de viagens, conciliar agenda dos participantes, suporte à infraestrutura tecnológica e habilidades em técnicas de modelagem são apenas alguns pontos a serem observados antes de optar pelo método a ser utilizado no levantamento de informações.

Não há um método único que seja melhor, cada projeto de modelagem ou análise de processos deve considerar quais métodos de coleta de informações são mais apropriados e eficazes para o processo que está sendo estudado.


Conheça mais sobre estas e outras atividades relacionadas à modelagem de processos no curso de Modelagem de Processos de Negócio da iProcess Education.

A importância de avaliar a cultura e o medo da mudança na implementação de BPM

Neste artigo vamos abordar alguns dos aspectos mais críticos, e frequentemente ignorados, no que se refere a implementar BPM nas organizações: como a cultura organizacional e o medo da mudança são fatores que podem afetar consideravelmente o resultado desta iniciativa.

Durante a implementação de projetos de BPM, é muito frequente se deparar com obstáculos relacionados à cultura da organização, principalmente no que se refere à forma como as coisas costumam ser feitas. São procedimentos, padrões e ferramentas que se estabeleceram com o passar do tempo, e acabaram virando a única forma conhecida das pessoas de realizar o seu trabalho. Com a realização de um trabalho de análise e redesenho do processo através de uma iniciativa de BPM, então todos os gaps, ineficiências e problemas desta forma de trabalho podem vir à tona. Podemos citar como exemplo um caso clássico na automatização de processos: a substituição de formulários em papel que devem ser assinados manualmente pelos gestores, por formulários eletrônicos em que a aprovação é controlada por um processo automatizado e realizada através de uma lista de trabalho.

É do nosso conhecimento casos em que usuários de negócio ficaram receosos e resistentes pelo simples fato de que as aprovações necessárias não iriam mais ser em papel, ou seja, sem a assinatura “física” do seu gestor. São usuários que não foram suficientemente informados de todos os conceitos por trás de uma aprovação digital, e chegaram a exigir (já numa fase bem adiantada de uso do processo) que os participantes deveriam adicionalmente imprimir o histórico de aprovações e anexar junto a solicitação, para que fosse dado o encaminhamento para a próxima área envolvida. Temos aqui um caso em que um dos maiores benefícios da automatização de processos, que é a economia de papel, foi praticamente anulada simplesmente pelos receios de usuários mal informados.

Uma mudança na forma de como são feitas as coisas pode mexer ainda com questões comportamentais enraizadas na organização, e que podem passar despercebidas até para o mais experiente analista de processos. Podemos citar o exemplo de um solicitante que aproveitava o momento em que solicitava a aprovação do seu gestor (com o formulário em papel em mãos), para sentar com ele na sua sala, tomar um cafezinho e discutir com ele banalidades e o resultado do futebol no fim de semana. E que, de uma hora pra outra, teve esta rotina agradável e esperada (do ponto de vista dele) sendo substituída pela rápida, eficiente e distante aprovação eletrônica. O exemplo pode até parecer exagerado e cômico, mas é um tipo de percepção que de fato ocorre entre os usuários, e é preciso ficar atento.

A resistência a mudanças pode ser um grande impeditivo para o sucesso de projetos de BPM. Se os usuários não forem suficientemente informados e principalmente convencidos da necessidade da mudança, podem virar grandes opositores e chegar ao ponto de boicotar a iniciativa, levando muitas vezes o projeto ao fracasso. Em outro exemplo que ilustra esta situação, uma das pessoas envolvidas na execução de um processo chegou a temer pelo seu emprego, quando descobriu que a automação do processo iria realizar de forma automática muito dos procedimentos que esta pessoa executava de forma manual, procedimentos os quais tomavam boa parte do seu dia. Foi então necessário um trabalho de informação e conscientização com esta pessoa, informando que esta seria direcionada para atividades de maior valor agregado, para que a resistência e o medo da mudança fossem finalmente superados.

Se durante uma iniciativa de BPM as organizações optarem por ignorar a avaliação da cultura interna e não realizarem uma etapa de gerenciamento das mudanças com todos os envolvidos, certamente poderá se esperar como resultado uma resistência muito grande e, em casos extremos, até o cancelamento da iniciativa.

Particularidades na execução de projetos com integrações – Parte Final

Nos dois primeiros posts (disponíveis em 1 e 2), tratamos particularidades da gestão/execução e práticas metodológicas para bons resultados em projetos envolvendo integrações.

Para fechar esta série de artigos, hoje descreveremos alguns riscos importantes e fatores críticos de sucesso (FCS) nestes projetos, para que recebam a devida atenção e, se necessário, tratamento.

Em resumo, grande parte dos riscos e FCS se referem à comunicação e à integração das equipes do projeto, dado que muitas das informações e necessidades de trabalhos desta natureza envolvem algum tipo de compartilhamento.

Desta forma, listamos abaixo alguns itens que consideramos relevantes:

  • O primeiro ponto quem sabe até não seja o mais importante, mas certamente é um dos mais frequentes. Durante testes do sistema, quando ocorrem problemas, costumamos dizer: “até que se prove o contrário, a ‘culpa’ é da integração”. E pode-se dizer que até é um fato lógico. Quando uma das equipes realiza algum teste e não vê o resultado esperado acontecendo na outra “ponta”, naturalmente a primeira desconfiança é de algum defeito ou inconsistência na integração, que justamente faz a “ligação” entre os dois sistemas. Porém, esquece-se que a integração não é uma peça de software isolada, e sim um pequeno sistema formado pela origem, destino e o meio, que é a integração em si. E em qualquer um destes componentes pode ocorrer erro. Assim, é importante tanto alinhar as expectativas das equipes (inclusive para evitar desgastes) quanto definir um processo de teste e avaliação de problemas tecnicamente adequado para o cenário do projeto e dos sistemas envolvidos.
  • Boa parte das etapas de desenvolvimento e testes será realizado de maneira simbiótica por todas as equipes envolvidas (equipe do sistema que será integrado, de integrações e dos legados). Desta forma, uma prática bastante importante é a apresentação destas equipes, visando sua aproximação e integração. Com isto, espera-se que todos se conheçam, saibam os papéis de cada um e a quais responsabilidades respondem, quais os conhecimentos de cada integrante quando precisarem de apoio, etc. Além disso, a própria integração pessoal da equipe auxilia na pró-atividade e facilidade da comunicação.
  • Apesar da metodologia de desenvolvimento normalmente contemplar e se adequar a boa parte do escopo, como as integrações são o meio e dependem da forma como as “pontas” são desenvolvidas e entregues, é fundamental avaliar as eventuais modificações necessárias na metodologia, bem como apresentá-las às equipes. As responsabilidades também devem ficar muito claras. Além disso, é mandatório registrar estas mudanças em algum local, para consulta. Esta preocupação é essencialmente importante pois é muito comum (para não dizer que acontece sempre) que se confundam sobre o que cada equipe deve fazer e até onde sua autonomia vai. Isto pode gerar conflitos e desgastes desnecessários, perda de produtividade ou até problemas mais graves, que se refletem apenas quando o projeto já está em um estágio mais avançado.
  • É comum em um projeto com integrações existirem documentações compartilhadas, nas quais uma equipe preenche parte do documento, e outra(s) o completa(m). Assim, é importante esclarecer com todos quais tópicos cada um é responsável e definir uma política de armazenamento e versionamento adequadas.
  • A comunicação entre as equipes durante a análise e os testes é outro fator crítico. É fundamental definir um fluxo adequado e claro de comunicação entre os integrantes das equipes, de acordo com as responsabilidades no projeto. E, claro, esta definição depende de uma avaliação criteriosa dos estilos e da disposição física das equipes, do ambiente de trabalho e dos recursos de comunicação disponíveis.
  • Por fim, um ponto bastante simples, mas que pode facilitar muito a identificação de problemas. À medida que integrações forem codificadas e estejam razoavelmente estáveis, podem ser disponibilizadas para uso pelas demais equipes. Claro, dependendo do planejamento do projeto e da metodologia utilizada, elas nem serão acionadas antes dos testes integrados. Mas, caso as equipes das “pontas” já estejam prontas para realizar testes com o uso das integrações, isto pode antecipar alertas relevantes sobre inconsistências e defeitos.

Com este artigo, fechamos esta série dedicada especialmente a dicas, boas práticas e cuidados com projetos envolvendo integrações, que possuem particularidades que os tornam especialmente desafiadores.

Fiquem à vontade para opinar e sugerir outras práticas interessantes.

Esperamos que tenham gostado!

Nos falamos em futuros artigos. Até lá!

Particularidades na execução de projetos com integrações – Parte 2

No primeiro post (disponível aqui), iniciamos uma avaliação de particularidades da gestão e execução de projetos envolvendo integrações, com foco nas dependências técnicas e gerenciais.

Hoje, a ideia é “conversarmos” sobre algumas práticas metodológicas importantes para minimizar riscos e conduzir o trabalho de maneira organizada.

Apesar de podermos citar um grande número de práticas, algumas são especialmente relevantes para o sucesso deste tipo de projeto, a saber:

  • Definição de uma arquitetura do projeto. O básico do básico, mas por vezes esquecido. É fundamental definir uma arquitetura de comunicação, tecnologias a serem utilizadas e padrões de implementação no projeto, especialmente para as integrações. Outro ponto muitas vezes negligenciado – não adianta ter, tem que comunicar. Se for necessário, imprima a arquitetura e cole no monitor dos integrantes da equipe. Cada um precisa ter a arquitetura na cabeça, sem exceções. Criar uma página tipo wiki também pode ser simples e eficiente.
  • Implementação de mocks na etapa inicial de desenvolvimento ou arquitetura. Como citado no primeiro post, a definição e construção de mocks é uma prática que facilita a formalização da comunicação entre os componentes do sistema (principalmente quando estes estão divididos entre vários fornecedores) e auxilia o paralelismo de atividades. Uma outra avaliação é bastante importante – o comportamento interno do mock. Se por um lado um artefato que simplesmente devolve “vazio” é fácil e rápido de implementar, por outro ele não auxilia os testes unitários, por exemplo. Se implementarmos algumas regras, os testes unitários podem ser mais efetivos, mas é um trabalho que posteriormente será descartado. Assim, é fundamental avaliar qual a complexidade e conteúdo dos mocks a ser desenvolvido para cada caso e requisitos do projeto.
  • Testes unitários com componentes já desenvolvidos. Conforme o segundo item, a validação das regras de negócio das integrações não depende apenas das interfaces (assinaturas, contratos, etc) dos componentes chamados por estas, e sim principalmente de sua implementação interna. Desta forma, assim que possível é importante a substituição dos mocks pelos componentes definitivos, o que já ajuda, e muito, na avaliação de eventuais problemas de integração dos dados e até de análise. Porém, um alerta. Caso os componentes ainda estejam em uma fase incipiente de desenvolvimento, podem conter bugs que mais prejudicarão do que ajudarão durante a implementação das integrações. Assim, é necessário avaliar a qualidade dos componentes das “pontas” quando estes forem usados.
    • Revisão periódica de serviços ou componentes que vão ficando prontos. Item relacionado ao tópico anterior. Defina um meio de acompanhar e comunicar quais componentes das “pontas” da integração (serviços que serão chamados, por exemplo) estão prontos e disponíveis para uso no decorrer do projeto. É bastante comum esquecermos disto por vários dias e perdermos a oportunidade de aproveitar os ganhos do tópico acima.
  • Teste de arquitetura com “integração piloto”. Uma prática que resolve várias dores de cabeça e antecipa problemas do desenvolvimento é validar a arquitetura definida para o desenvolvimento das integrações com a implementação de uma “integração piloto”. Aproveite este momento para questionar e validar as diretrizes arquiteturais para o restante do projeto. Claro, nem sempre isto é simples, visto que muitos projetos incluem integrações com “n” formas de implementação e utilização de recursos. Mas, na medida do possível, é uma prática muito vantajosa.
  • Mapa de dependências entre componentes. Prática simples e muito útil. Organize um mapa com todos os componentes do projeto e quem depende de quem. Não use textos – faça o mapa de forma gráfica. Aí temos uma vasta gama de ferramentas que podem ser usadas – aplicativos de mind mapping, de desenho, de modelagem, etc. E use a criatividade. Pinte componentes de cada tecnologia com uma cor diferente, separe-os por equipe responsável, por desenvolvedor, e assim por diante.
  • Repositório único de contratos. É realmente muito importante definir um repositório que armazene a versão oficial de contratos de serviços e demais componentes que são dependência para outros no projeto. Assim, todas as equipes sabem onde consultar a versão a ser utilizada, evitando ruídos de comunicação. Claro, se alguma alteração é feita, deve ser comunicada a todos – e isto deve estar contemplado no Plano de Comunicação do projeto. Este repositório deve estar sempre atualizado.
  • Organizar a análise e desenvolvimento das integrações por assunto. É bastante comum em projetos envolvendo integrações que estas estejam separadas por assuntos de negócio tratados pelo sistema. Por exemplo: ao desenvolver integrações de um ERP com sistemas legados, organizar os profissionais que vão analisar e implementar as integrações por cada módulo do ERP. Nem sempre isto é possível – alguns processos são transversais e passam por vários módulos – mas claramente auxilia o entendimento das integrações pelo conhecimento de negócio que cada profissional adquire. Claro, isto incide em alguns riscos bastante relevantes. Se um profissional, seja analista ou desenvolvedor, sai da equipe, um grande conhecimento pode ir com ele. Uma forma de contornar isto é envolver o líder técnico e um analista líder em pontos-chave da análise e desenvolvimento de todas as integrações, a fim de que possa responder pelo conhecimento destas.
  • Definição de cenários de testes entre as equipes. Um ponto chave do projeto, difícil de gerenciar e que frequentemente enfrenta grandes problemas, é o teste integrado do sistema, principalmente quando existem diferentes equipes envolvidas. Uma sugestão muito interessante é a reunião dos responsáveis das equipes para elaboração de cenários de teste integrados. Veja, a ideia não é detalhar cada cenário neste momento, e sim definir quais são os cenários a serem executados para validar a integração dos sistemas de ponta a ponta. Após, cada equipe detalha seus cenários individualmente, que são validados ao final, novamente entre todos.

No próximo post, que encerra esta série, trataremos de riscos e pontos de atenção em projetos com integrações, visando auxiliar principalmente seu planejamento e gestão. Até lá!