5 fatores de sucesso para enfrentar os problemas de integrações na automação de processos

Tendo participado de vários de projetos de automação de processos, se tem algo que podemos afirmar como sendo um denominador comum a projetos de automação em empresas das mais diferentes áreas, é dos problemas que surgem quando existe necessidade de integração do processo automatizado com outros sistemas/organizações.

O fato é que problemas relacionados a integrações invariavelmente vão ocorrer, apenas variando de acordo com o grau de complexidade do processo e das integrações em si. Por outro lado, existem sim alguns fatores e cuidados que podem evitar problemas ou facilitar a sua resolução.

Ter conhecimento destes fatores no projeto vai prepará-lo melhor para o que vem pela frente.

Vamos a eles?

1. Ter uma boa governança dos serviços/integrações/funcionalidades disponíveis

Durante a automação do processo, é comum detectar uma ou mais necessidades de integração (ex: salvar alguma informação digitada durante a execução do processo num banco de dados).

Em nossa experiência, boa parte dos problemas que ocorrem nestes casos se devem a falta de governança da organização em relação aos serviços, integrações e sistemas existentes, ou seja, não se sabe se aquela necessidade de integração do processo já se encontra disponível (ex: através de um webservice).

A consequência disso é a necessidade de se discutir do zero esta integração, fazer orçamento e incluí-la no escopo, o que leva a aumento do prazo e custo do projeto. Um fator que minimiza bastante estes problemas é se a organização já trabalha numa Arquitetura Orientada a Serviços, ou simplesmente SOA (mais informações aqui, aqui e aqui), bem como dispor de ferramentas de governança/pesquisa de serviços.

2. Prever o modelo de dados do processo adequado as necessidades de integração

Quando um processo será automatizado, deve-se previamente fazer uma análise para definir o “modelo de dados” do processo, ou seja, as informações que serão visualizadas e manipuladas ao longo da execução do processo (veja aqui para mais informações).

A definição deste modelo de dados costuma ser mais transparente quando estamos falando de informações que ficam visíveis no formulário eletrônico do processo, ou seja, as informações que os usuários vão visualizar/editar ao acessar as tarefas. Mas infelizmente não é tão óbvio quando falamos de integrações.

Por exemplo, se é necessário chamar uma integração para atualizar uma informação no ERP a partir do processo automatizado, pode se descobrir que uma das informações obrigatórias para se chamar esta integração é específica daquele sistema (ex: um determinado identificador), e esta informação não foi prevista inicialmente no modelo de dados.

Com frequência, inclusive, ocorre a situação de que para obter a informação que você precisa para chamar uma integração, é necessário chamar outra integração!

Este fator costuma gerar muitas dores de cabeça, em muitos casos não é fácil prever todas as possibilidades.

3. Ter conhecimento das funcionalidades e limitações do framework de integração do BPMS

Mesmo que inicialmente a empresa tenha adquirido uma solução de BPMS para um processo pontual ou para apenas gerenciar fluxo de trabalho sem integrações com outros sistemas, o fato é que as necessidades da organização mudam. Quando chegar o momento em que as iniciativas de automação de processos passarem a demandar mais inteligência, com integração de dados existentes em outros sistemas, é importante conhecer as funcionalidades e limitações de integração do BPMS.

Por exemplo, alguns questionamentos comuns nestes casos:

  • Posso chamar webservices através do BPMS?
  • Consigo conectar diretamente num banco de dados através do BPMS?
  • Existem adaptadores nativos que permitem conexões com sistemas conhecidos no mercado?
  • O BPMS me permite realizar transformações complexas de dados ao chamar ou obter o retorno de um webservice?
  • Existe algum formato específico de assinatura do serviço para poder ser acionado?
  • Com que tecnologias o BPMS permite fazer integração? Soap? Rest? Corba? EJB? .net? Controle de arquivos no filesystem? Outros?

Este conhecimento é importante para detectar eventuais restrições da ferramenta, identificar a necessidade de utilizar outras ferramentas em conjunto ao BPMS, ou no pior dos cenários até a troca do próprio BPMS. Por exemplo: se o BPMS não é capaz de fazer transformações de dados complexas ao chamar um webservice, então possivelmente será necessária outra ferramenta (ex: uma ferramenta de barramento de serviços) que fará esta transformação no lugar do BPMS, expondo para o BPMS uma versão simplificada do serviço. Neste mesmo exemplo, pode ser que esta ferramenta adicional não exista na organização, e precisa ser previsto a sua contratação e implantação, dentro do escopo do projeto de automação.

Entenda a importância de uma avaliação detalhada sobre recursos ​dos produtos ao adquirir uma plataforma ​BPMS com ​esta coleção de artigos sobre Seleção de Plataformas de BPM.

4. Equipes dos sistemas disponíveis para apoiar o projeto

Parece chover no molhado, afinal se um processo automatizado precisa se comunicar com o sistema X, então a equipe de apoio deste sistema tem que estar envolvida, certo? Bem, temos algumas histórias de iniciativas de automação de processos aprovadas em nível executivo, mas que durante o andamento do projeto as equipes dos sistemas estavam em uma das seguintes condições:

  • Não estavam sabendo do projeto – o popular “cair de paraquedas”  (sim, é comum);
  • Sabiam do projeto e que em algum momento iriam se envolver, mas não tinham nenhum contexto dos objetivos do projeto e o seu papel (tem na prática os mesmos efeitos nocivos da situação anterior);
  • Sabiam do projeto e tinham o contexto, mas não tiveram a alocação reservada para apoiar o projeto (“Eu conheço o projeto e entendo o que devo fazer, mas não sei se vou conseguir ajudá-los ainda neste mês…”).

Quando as equipes dos sistemas começam a se envolver no projeto, é comum surgirem problemas e limitações que não se tinha noção, o que pode ocasionar necessidade de se rediscutir a solução. Aqui o apoio da liderança executiva e da gestão de projetos é fundamental para minimizar os problemas, reforçando a alocação das equipes dos sistemas envolvidos, para se envolverem no projeto de automação o quanto antes, preferencialmente ainda durante as fases de análise e projeto.

5. Atenção à  etapa de testes

Se existem integrações no processo, obviamente as mesmas precisam ser bem testadas, envolvendo as equipes responsáveis pelos sistemas de origem/destino das informações.

Ocorre que na automação de processos, assim como no desenvolvimento tradicional de sistemas, pode ocorrer a tendência de dar ênfase maior apenas a “interface” do processo, que no caso do BPMS são os formulários das atividades enviadas para os usuários. Mas obviamente as integrações que são feitas automaticamente pelo processo devem ser testadas com o mesmo cuidado, verificando se estão retornando ou gravando as informações corretamente.

Isto comumente é realizado utilizando os recursos de rastreamento/auditoria presentes das próprias ferramentas de BPMS (verificando o que está recebendo ou enviando de informações), bem como acessando diretamente o sistema com o qual se tem a integração (para verificar se os dados sendo obtidos/atualizados pelo BPMS estão corretos).

Estas verificações normalmente exigem um conhecimento técnico maior (ex: visualizar payloads em XML, acessar as informações diretamente em tabelas do banco de dados do sistema em questão, etc).

 

Sem dúvida existem outros fatores envolvidos, mas acreditamos que os fatores citados acima dão um bom norte para a equipe do projeto se preparar e enfrentar os problemas que podem ocorrer nas integrações durante a automação de processos.

 

A parceria entre os processos automatizados e os sistemas já existentes em uma organização

Podemos dizer, a partir da experiência da equipe iProcess em automação de processos, que os processos automatizados e os sistemas informatizados das organizações não competem entre si, eles formam uma parceria, se complementam. Dizemos isto porque são nos sistemas já existentes nas organizações que os processos obtém as informações necessárias para a execução dos fluxos de trabalho, utilizando-se para isto de uma camada de integração. Daí o motivo de acreditarmos que ambos se complementam.

Os sistemas já existentes, que também chamamos de legado, não são descontinuados ao serem integrados ao processo automatizado. O processo será responsável pela conexão entre estes sistemas e os usuários do processo. Através do BPMS (Business Process Management Suite ou System), uma organização automatiza processos para aumentar seu nível de controle e monitoramento na execução dos processos. Assim, um BPMS atua como orquestrador da execução dos processos entre pessoas e sistemas, definindo o fluxo do trabalho e da informação entre estes participantes.

Desta forma, os sistemas se preocupam com o cadastro, atualização e consulta das informações armazenadas em base de dados e os processos com a sua distribuição, tendo o foco na sequência de etapas, prazos, distribuição das atividades, integridade do processo e em fornecer o melhor ambiente possível para que as atividades sejam executadas. Em alguns casos, se faz necessário o armazenamento das informações ao longo do processo, mas são informações específicas para o contexto das instâncias do processo, que servem para controle de estado do fluxo e logs de atividades, por exemplo.

Quando se automatiza um processo, na etapa de levantamento das informações, é que verificamos como a parceria entre os sistemas já existentes na empresa e o processo utilizando BPMS se dará. Algumas das informações levantadas nesta etapa são:

  • Informações consumidas e informações geradas pelo processo, isto é, quais as informações que deverão ser recebidas pelo processo oriundas de sistemas e quais as informações que eventualmente deverão ser enviadas para gravação em sistemas existentes da organização, como, por exemplo, ERP, sistemas contábeis ou cadastros corporativos.
  • Pontos de integração, isto é, em quais atividades do processo deverão ser obtidas/geradas informações que alimentam os sistemas legados.
  • Como que o processo e os sistemas legados conversarão entre si, que normalmente ocorre através da camada de integração, utilizando serviços especialmente construídos para isto.

A implementação de BPMS nas organizações não deve ser orientada a substituir total ou parcialmente os sistemas atuais esperando-se que passe eventualmente a ser o repositório central das informações da organização. O BPMS não é a fonte principal das informações que estão sendo manipuladas, mas atua principalmente como integrador delas, buscando e enviando informações para outros sistemas durante a execução dos processos.

A iProcess disponibiliza em sua plataforma EAD mais informações sobre este assunto, através do Curso TDP – Transformação Digital Orientada a Processos.

Na hora de escolher a plataforma de BPM…

"Mas o que é mesmo que nós precisamos?"

O fato da iProcess ser uma consultoria com longa história, construída no estudo e implementação de soluções para processos através de tecnologias como workflow e BPMS, nos coloca em uma posição bastante interessante em relação ao mercado: entendemos como as soluções de automação funcionam, como é a sua arquitetura, o que as faz iguais e diferentes.

Isso possibilita dizermos então que nossa ferramenta favorita é, na verdade, a solução que mais se encaixa nas necessidades organizacionais, financeiras, culturais e tecnológicas dos nossos clientes.

É por isso que, quando as pessoas nos comentam que estão testando as soluções X, Y e Z e nos perguntam qual indicaríamos, ou qual é o melhor, a nossa resposta é “depende”. Depende porque, em nossos anos de experiência automatizando processos, chegamos à seguinte conclusão: não é uma questão de qual software é melhor comparado a outro software, mas qual é o software que melhor se encaixa às reais necessidades da organização.

Descobrir a solução que apresenta a melhor relação de custo e benefício em BPM requer uma análise que vai além de verificar funcionalidades que uma tenha e a outra não. Ela passa por questões como:

      • “Qual o tamanho da organização em termos de usuários e sistemas que integram os processos de negócio, e qual a perspectiva de crescimento para os próximos anos?”
      • “Como a companhia está estruturada – ela existe em um local centralizado ou se espalha por diferentes locais e regiões? Qual o impacto disso nos usuários dos processos automatizados? Precisamos de um software que suporte multi-línguas e multi-moedas?”
      • “A infraestrutura de TI da organização já tem um direcionador de plataforma tecnológica que pode impactar nesta decisão?”
      • “O que mais a organização precisa deste software além da simples automação dos passos a serem executados no processo automatizado? Monitoramento e ação em tempo real? Arquitetura dos processos de negócio? Ferramentas e metodologias de análise de processos? Posso ter isto em apenas um software ou precisarei de múltiplas ferramentas para cobrir meu ciclo de melhoria contínua de processos?”
      • “Que tipo de processos planejamos automatizar? Quantos? Com que frequência eles são executados, e o software está preparado para gerenciar a quantidade de instâncias?”
      • “O processo que modelamos é o processo que será executado, ou precisa ser transformado em outras linguagens antes de rodar, como do EPC para BPMN, ou do BPMN para BPEL, ou ainda de uma notação gráfica para algo que só o BPMS entende? Consideramos isto aceitável?“
      • “Que outras soluções de software precisarão ser integradas: ERP, BRM, BAM, ECM, etc?”
      • “Que tipo de suporte o fornecedor da solução está preparado para oferecer enquanto desenvolvemos a automatização do processo e após a implantação?”
      • “Onde encontramos profissionais que conheçam o software com a profundidade suficiente para implementar as complexidades naturais dos processos, que vão além do simples workflow de sequência de atividades?”
      • “O quão sólida é a empresa por trás do software – quais os riscos do mesmo ser adquirido por outra empresa gerando mudanças e mais mudanças na plataforma?”

Você percebe que dependendo da organização, o peso e a resposta a essas perguntas podem gerar avaliações bem diferentes?

São tantas questões que precisam ser consideradas neste processo de escolha – e que vão além da simples comparação de funcionalidades, que já consolidamos uma planilha de avaliação com centenas de critérios a avaliar (e que inclusive faz parte do nosso treinamento e pacote de consultoria em Seleção de Plataformas de BPM).

É claro que boas opiniões de quem já usa a ferramenta são essencialmente importantes. É parte do processo de escolha de uma plataforma, mas pode não ser a resposta para a organização.

Há tanto software de BPM sendo oferecido no mercado, que recomendamos sempre que antes de escolher uma ou outra solução para “testar”, por sorte ou porque alguém disse que era boa, considere as reais necessidades da organização – e então escolha aquelas sobre as quais realmente vale a pena investir tempo na avaliação.

Nossa equipe já atuou em projetos utilizando diferentes soluções de BPM. Todas elas são muito boas. É apenas uma questão de entender quais as verdadeiras necessidades da empresa.

Veja mais artigos sobre o tema da escolha de plataforma de BPM publicados aqui mesmo no blog da iProcess:

 


O que BPM tem a ver com requisitos de software? Tudo!

Muitas organizações estão buscando adotar BPM (Gestão por Processos de Negócio) como disciplina gerencial. Isto quer dizer que a empresa começa a se organizar e ter seus negócios gerenciados com base em processos de negócio bem estabelecidos, que definem o quê a organização realiza para transformar matéria prima (ou informações) em produtos e serviços.

Conhecer os processos leva a uma série de benefícios para a gestão da organização, mas de forma especial:

  • Possibilita ter uma visão mais clara de como os clientes participam do negócio da empresa
  • Possibilita que a empresa se organize ajustando seus processos para atender os objetivos do planejamento estratégico
  • Possibilita olhar para o quê e como as áreas da empresa interagem para entregar produtos e serviços, de ponta a ponta (do recebimento de materiais/informações, passando por todas as etapas de transformação e agregação de valor até que o produto/serviço seja entregue).

Com isso, torna possível também à organização identificar situações onde pode gerar grande inovação, destacando-se no seu mercado por um produto de muito mais qualidade, ou muito menor custo – tendo como meta atender à expectativa dos clientes.

Então o processo de negócio bem definido nos ajuda a entender o quê a organização faz, não apenas dentro das áreas, mas também como o processo passa de uma área para a outra.

E o que isto tem a ver com requisitos de software?

Sabendo o quê é preciso fazer (e eliminando aquilo que é feito sem necessidade), a organização pode definir melhor como faz. E o como passa pelos recursos utilizados, inclusive, de software. Como uma pessoa realiza uma determinada atividade de um processo? Usando o sistema X. E o que é necessário para ela interagir com os sistemas nesta etapa do processo? Isso é que determina, da forma mais assertiva, os reais requisitos de software que o sistema precisa ter para que as pessoas façam o que precisa ser feito e como deve ser feito!

As integrações entre sistemas, as interfaces e casos de uso para a interação do usuário com o sistema, quais informações o usuário precisa obter, gerar, editar para poder concluir aquela atividade – tudo isso pode ser identificado e definido com maior clareza se temos a visão do processo.

Pense só: com a visão de processo, é possível identificar claramente que informações um participante de processo precisa gerar, para que os participantes das próximas etapas (que estejam por exemplo em outras áreas) possam fazer a sua parte. E com isso, conseguimos definir de forma assertiva tudo o que (e nada mais que) o usuário precisa fornecer em termos de dados no sistema para que o trabalho continue sendo realizado nas áreas seguintes com o menor risco de falta de informações e de erros possível.

Nós da iProcess (junto com muitos profissionais de processos que atuam na frente de tecnologia) acreditamos que o processo de negócio deve guiar a identificação dos requisitos de software. Esta abordagem se reflete na qualidade e aderência do software às necessidades do negócio quando a solução é implantada.

Veja resultados efetivos dessa abordagem nos cases implementados da iProcess.


Arquitetura típica de BPMS

Os BPMS (Business Process Management Suite, ou System) são uma categoria de software com a capacidade de coordenar a execução de processos de negócio.

Apesar de apresentarem variações, podendo conter ou não alguns componentes, os BPMS essencialmente apresentam uma arquitetura básica comum:

Arquitetura típica de um BPMS (iProcess, 2009/2013)

 

Modelagem

O componente de modelagem é a ferramenta que auxilia o analista a documentar o processo de negócio.

Podem ser utilizadas diferentes notações pela ferramenta de modelagem, embora a mais comum seja BPMN, pela sua facilidade de transformação no modelo que poderá ser implementado tecnicamente para a automação.

Muitas ferramentas dispõem na ferramenta de modelagem recursos como documentação detalhada, integração com a estrutura hierárquica organizacional, funcionalidades de apoio à análise e simulação dos processos.

Desenho Técnico

O componente de desenho técnico é a área de trabalho do desenvolvedor, que irá implementar o processo modelado.

Em alguns BPMS, a ferramenta de desenho técnico pode ser a mesma ou estar integrada à de modelagem. Em outros casos, as ferramentas podem ser distintas.

A ferramenta de desenho técnico pode implementar o processo na mesma notação do processo modelado (em geral BPMN) ou eventualmente poderá requerer uma transformação para outra notação ou linguagem, como BPEL por exemplo.

Motor de Processos (Process engine)

O motor de processos é o componente onde a mágica do controle e execução do processo automatizado acontece.

Quando o modelo do processo implementado está pronto, ele é disponibilizado para o motor de processos. As informações do modelo são armazenadas na base de dados da ferramenta, que passa a usá-las como base para controlar cada etapa da execução.

O motor de processos é responsável por:
  • interpretar o modelo do processo,
  • controlar a execução de acordo com o modelo do processo,
  • interagir com os participantes humanos do processo,
  • invocar e integrar-se com aplicações externas,
  • manter automaticamente atualizada a base de dados de execução do processo.
Quando uma nova instância do processo é disparada, o motor de processos interpreta a próxima etapa, identificando quem deve executar, que dados devem ser fornecidos como entrada, que dados são esperados como saída da sua execução.

O framework de tarefas humanas é o responsável por gerenciar as atividades executadas por usuários, disponibilizando as informações configuradas para a tarefa ao ator responsável através de mecanismos como a lista de trabalho (ou lista de tarefas). Quando um usuário finaliza sua atividade, o framework de tarefas humanas repassa o resultado ao motor de processos, que dá seguimento à execução do processo.

O framework de integração é o responsável por gerenciar o acionamento de mecanismos automáticos, executando serviços, APIs ou scripts de busca ou envio de dados para sistemas de informação como sistemas legados, ERPs ou serviços de agentes externos. Em geral apresenta melhor desempenho quando estas integrações são gerenciadas através de uma arquitetura SOA (para saber mais, leia os artigos “SOA – Arquitetura Orientada a Serviços” e “SOA – A relação com BPM no sucesso da automação de processos“).

Alguns produtos dispõem também de um framework de regras, que gerencia a invocação de regras de negócio. Neste caso, as regras de negócio são mantidas em uma solução denominada BRMS (Business Rules Manager System), viabilizando que gestores do negócio tenham controle sobre os parâmetros que definem a regra, cabendo ao processo apenas executá-la para obter o resultado.
(Leia mais sobre BRMS no artigo Business Rules e a Dinâmica do Negócio)

Repositório de documentos

É natural que em muitos processos de negócio haja o envolvimento de documentos.
Documentos podem ser o gatilho de um processo de negócio, bem como atividades no decorrer da execução do processo podem requerer que documentos sejam associados a ele.

Assim, a maior parte das soluções de BPM disponibilizam mecanismos para vincular documentos a processos em execução, mas elas podem se diferenciar basicamente de duas formas. Muitas soluções viabilizam mecanismos simples de vínculo de documentos, em que os arquivos são armazenados no sistema de diretórios do servidor e oferecem formas de interação simples (anexar, abrir, remover).
Outras soluções mais robustas incorporam ferramentas mais completas de gerenciamento de conteúdo – ECM (Enterprise Content Management), contemplando uma gestão plena sobre o documento, com funcionalidades como versionamento, busca por metadados ou por conteúdo, gerenciamento de validade e expiração, controle de acesso ao conteúdo, entre outros.

Dados de Desempenho e Monitoramento

Sem monitoramento não há gerenciamento. Assim, todo BPMS mantém uma base de informações da execução de cada instância de processo que pode ser usada na geração de dados de desempenho do processo.

Os dados de desempenho são utilizados por ferramentas que possibilitam o monitoramento através de indicadores reportados em relatórios ou painéis gráficos.

A forma como estes dados são disponibilizados para o monitoramento também pode apresentar variações entre as soluções disponíveis no mercado.

Enquanto algumas soluções disponibilizam relatórios tabulares e gráficos para acompanhamento dos indicadores (muitas vezes inclusive com alto grau de customização e personalização), outras ferramentas apresentam componentes mais robustos de Monitoramento Ativo – BAM (Business Activity Monitoring), que possibilitam não apenas visualizar indicadores mas interagir com processos problemáticos.

 

Com tantas variações, como escolher o BPMS certo para minha organização?

Selecionar um BPMS para uso em uma organização passa por compreender a robustez dos componentes disponibilizados pelas soluções de cada fornecedor e avaliá-las frente às necessidades atuais e futuras da organização, levando também em conta aspectos econômicos e culturais. Leia o artigo “A difícil tarefa de escolher uma plataforma BPM para uma organização” para compreender as complexidades envolvidas nesta escolha e estruturar um projeto de seleção.

 

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á!