Desmistificando tipos de tarefas em BPMN: Tarefas automáticas

No artigo anterior (Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual) iniciamos uma série de três artigos sobre os tipos de tarefas em BPMN. Para facilitar o entendimento, estamos discutindo os os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefas de execução de rotinas automáticas

Para representar situações em que rotinas que são executadas automaticamente no processo (em que seu acionamento é determinado pelo andamento do fluxo do processo, sem que haja uma pessoa para acioná-lo), BPMN sugere três tipos de tarefa: tarefa de serviço, tarefa de script e tarefa de regra de negócio:

Os tipos de tarefa automáticas: tarefa de serviço (service task), tarefa de script (script task) e tarefa de regra de negócio (business rule task)

De acordo com a especificação:

“Uma Service Task (tarefa de serviço) é uma tarefa que usa algum tipo de serviço, que pode ser um Web Service ou uma aplicação automatizada.” (pág 156)

“Uma Script Task (tarefa de script) é executada pelo motor de processos de negócio (business process engine). O modelador ou implementador define um script em uma linguagem que o motor de processos consegue interpretar. Quando a tarefa estiver pronta para iniciar, o motor de processos executará o script. Quando o script for concluído, a tarefa também será concluída.” (pag 162)

“Uma Business Rule Task (tarefa de regra de negócio) propicia um mecanismo para o processo para enviar informações a um Business Rules Engine (motor de regras de negócio) e obter o resultado do cálculo que o motor de regras pode prover. ” (pag 161)

 

Todas as três são utilizadas na modelagem quando temos um processo que está sendo automatizado (se o processo é executado manualmente, fora de um BPMS ou workflow, é necessário que haja uma atividade manual em que uma pessoa acione a execução de uma funcionalidade; portanto a tarefa em si é de uma pessoa).

 A diferença entre elas é que a tarefa de serviço (service task) aciona a operação de um sistema de informação externo com o qual o motor de processo se comunica (process engine) – que pode ser implementado através de tecnologias como webservices, RMI (Remote Method Invocation), EJB (Enterprise Java Beans), etc. Já a tarefa de script (script task) executa um trecho de código que a própria aplicação de motor de processos interpreta e executa (e cada fornecedor de produto pode definir sua linguagem de script própria). Por exemplo, a transformação de um tipo de dado em outro ou a realização de cálculos com os dados da instância do processo, são exemplos de tarefas de script.

A tarefa de regra de negócio (business rule task) comporta-se da mesma forma que a tarefa de serviço, porém possui o propósito específico de obter resultado da aplicação de uma determinada regra de negócio no processo (leia mais sobre regras de negócio e Business Rules Management no artigo Business Rules e a Dinâmica do Negócio).

Um exemplo de processo com tarefas automáticas de serviço, de tarefa e regra de negócio

No processo hipotético acima temos exemplos aplicados dos três tipos de tarefas automáticas.

  • A tarefa “Identificar prioridade do atendimento” é uma tarefa de regra de negócio, pois executa uma regra da organização (por exemplo: chamados de clientes com contas premium ou chamados que já tiveram uma visita técnica mas o problema não foi solucionado são tratadas como prioridade “emergência”, enquanto as demais são prioridade “normal”. Se a organização quiser mudar esta regra e incluir outros planos no atendimento de prioridade emergencial, pode modificar a regra de negócio sem impactar no processo).
  • Neste processo em que todos os chamados são originados com prioridade “normal”, a tarefa “Elevar prioridade do atendimento” é uma tarefa de script pois muda de “normal” para “emergência” uma informação do próprio processo, elevando a prioridade dos processos que passam por ela (sem precisar acessar outros sistemas).
  • A tarefa “Identificar técnico responsável” é uma tarefa de serviço pois acessa o sistema de localização da empresa identificando que técnico está mais próximo do endereço do cliente. Ela aciona um serviço deste sistema, e recebe como retorno a informação do técnico disponível.
  • A tarefa de serviço a seguir “Sinalizar sistema de chamados”, aciona um serviço do sistema usado pela empresa para enviar ao comunicador do técnico a nova chamada prioritária.
  • A tarefa de serviço “Agendar visita técnica” registra o chamado no sistema que libera a lista de clientes a serem visitados no dia pelos técnicos. Como é uma visita normal, ela é registrada de acordo com o agendamento realizado com o cliente na criação da ficha de atendimento.

Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Projetos de Modelagem de Processos – Parte 1: Objetivos e Motivadores

A modelagem de processos está sendo muito utilizada pelas organizações para conhecer, documentar e melhorar os seus processos. Porém, as necessidades que levam uma organização a iniciar a modelagem de processos acabam direcionando a tipos de projetos de modelagem com focos diferentes.
Trataremos, neste primeiro artigo da série, dos principais objetivos e motivadores relacionados aos mais comuns tipos de projetos de modelagem de processos.

 

Modelagem para Conhecer o Processo:

Objetivo
  • modelar o processo de modo que a forma como ele é realizado passe a ser de conhecimento dos participantes que executam o processo e da organização como um todo
Motivadores
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Documentação ou Treinamento:

Objetivos
  • documentar o processo para que dúvidas operacionais possam ser diluídas através da consulta ao processo
  • fornecer uma documentação completa para que os seus executores saibam como realizar suas atividades, evitando erros ou demoras devido a dúvidas
  • fornecer uma documentação que facilite o treinamento de novos colaboradores:
    • minimizando o efeito de perdas de colaboradores
    • auxiliando a organização que passe por um processo de expansão
Motivadores
  • processos em que os executores não tem experiência em executá-lo porque:
    • os papéis tem alta rotatividade ou
    • o processo não é executado com frequência por determinados papéis
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Implantação de Auditoria:

Objetivo
  • descrever os processos que serão objetos de auditoria para que exista uma referência comum sobre o que deve ou não ser feito no processo
Motivadores
  • padronização e documentação de processos que precisam ser auditados devido a exigências internas ou externas da organização
Mapeamento de Processos de Toda a Organização:

Objetivo
  • criar um repositório de processo com todos os processos da organização modelados e documentados
Motivadores
  • criar um ponto de partida para as iniciativas de gestão por processos
  • permitir que novas demandas de melhoria de processos possam ser atendidas rapidamente
Modelagem para Padronização dos Processos:

Objetivo
  • garantir que toda a organização executa o mesmo processo
Motivadores
  • demandada por processos executados em mais de um local. Ex.: Processo utilizado em várias unidades geográficas como no varejo ou no sistema financeiro.
  • processos que possuem diferente desempenhos de acordo com o local onde são executados ou das pessoas que os executam
  • aquisição de outras empresas → Necessidade de unificar a operação
  • abertura de novas unidades → Necessidade de replicar o modelo de gestão
Modelagem para o Redesenho de Processos:

Objetivos
  • a modelagem é focada no entendimento da situação atual do processo (AS IS)
  • objetivo não é a documentação do processo e sim o entendimento de
    • quais são suas atividades
    • quais os seus pontos fracos
    • quais os seus pontos fortes
    • quais suas oportunidades de melhoria
  • criar base para executar todo o ciclo BPM de melhorias: Mapeamento, Redesenho, Automação, Implantação e Melhoria Contínua.
Motivadores
  • redução de custos ou perdas do processo
  • processos críticos que, se não forem bem executados, podem gerar um grande impacto na organização
  • processos com metas cronológicas bem delimitadas
  • processos que possuem muitas perguntas a serem respondidas. Ex: Como é feito o processo? Porque acontecem tantos erros? Porque o processo é tão lento? Como posso melhorá-lo? Como meço os indicadores deste Processo?
  • processos com SLA bem definidos
  • melhorar o atendimento ao cliente final
  • expansão organizacional
  • processos inter-organizacionais (B2B)
  • empresa precisa se certificar ou aderir a uma legislação
Modelagem para Automação de Processos:

Objetivo
  • conhecer o processo o suficiente para propor uma versão automatizada que busque aumentar a sua eficiência operacional
Motivadores
  • ocorre quando a organização está satisfeita com o seu processo, mas acredita que ele poderia ser melhorado com o uso da tecnologia
  • organização entende que não precisa necessariamente discutir o processo a nível de negócio, e sim entregar com mais eficiência o processo da forma como atua hoje

Leia também o artigo Parte 2 – Características e Desafios, que trata da profundidade da modelagem, características, desafios e riscos relacionados a cada tipo de projeto de modelagem.

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.

Evitando as armadilhas mais comuns em projetos de otimização de processos

Projetos de otimização de processos consistem em realizar o trabalho de ajustar um processo buscando sua melhoria. De acordo com Reint Jan Holterman, autor do white paper “Five Common Pitfalls in Process Optimization, And how to avoid them“, os esforços de otimização devem “reforçar as atividades essenciais da empresa, produzindo melhores produtos e serviços, em um período mais curto de tempo, a um custo mais baixo e com mínimo de impacto ambiental”.

A otimização de processos requer, então, que se possa produzir uma visão de futuro melhor para a execução de um processo olhando para a forma como ele acontece atualmente e seu histórico (lições aprendidas). Envolve atividades de modelagem, análise e redesenho do processo, e apesar de este ciclo já se constituir em uma prática comum em organizações que buscam a melhoria de processos através das práticas de BPM, estima-se que 60 a 70% de todos os processos de otimização não produzam resultados satisfatórios (leia mais aqui: http://esopsfables.wordpress.com/2012/02/29/why-process-improvement-projects-fail/).

Em seu white paper, Holterman explora as cinco falhas mais comuns, responsáveis pelos problemas neste tipo de projeto:

1. Falta de clareza sobre onde começa e onde termina o trabalho

Muitos projetos são iniciados com uma declaração “vamos otimizar o processo tal”, mas não está claro para a equipe por onde começar e até onde se vai.

A falta de clareza sobre o início e fim do projeto leva a uma sequência de armadilhas que resultam em um processo desestruturado e interminável.

Em um projeto de otimização de processos é fundamental compreender a situação atual, o status quo do processo. Quem está envolvido, quais são as entradas e saídas, quais são os limites do escopo deste processo, qual é o tempo que o processo leva atualmente para ser executado, que exceções comumente levam a resultados diferentes e com que frequência acontecem, são questões iniciais que precisam ser feitas antes mesmo de se iniciar alguma ação de otimização.

Conhecer bem a situação atual do processo é tão importante quanto ter claro onde se quer chegar. É preciso que todos os participantes tenham uma visão clara de que melhoria deseja-se atingir com o projeto, se é um ganho de produtividade, de redução de tempo, de redução de custos, e que parâmetros definirão o atingimento do resultado esperado.

2. Usar indicadores (KPIs) inadequados

Os indicadores de performance (KPIs) são as referências que apontam a direção para a linha de chegada.

Indicadores mal definidos levarão a equipe a sair do curso, já que apontam para a direção errada.

Sintomas comuns de um KPIs mal definido:

  • não está relacionado ou é impactado muito levianamente pelo processo de negócio;
  • pode gerar interpretações diferentes;
  • não é impactado apenas pelo processo, mas também por  fatores externos;
  • não está relacionado de alguma forma aos objetivos estratégicos da organização, de forma que mesmo que o processo obtenha alguma otimização, não há garantia que produzirá algum resultado melhorado para a empresa.

3. Falta de apoio do dono do processo e da alta gestão

O Dono do Processo (Processo Owner) é o responsável pelo desempenho do processo de negócio, e espera-se que seja o maior interessado no sucesso de um projeto de otimização, já que afetará diretamente os resultados do produto ou serviço gerado pelas atividades do processo de negócio.

Consequentemente, sem um Dono do Processo que se importe em acompanhar o trabalho de otimização do seu processo (seja por falta de interesse ou de tempo para apoiar o trabalho), não se pode esperar grandes resultados do projeto.

Também o apoio da alta gestão da empresa ao projeto de otimização é essencial para o sucesso da iniciativa, de forma a garantir o envolvimento e a disponibilidade dos recursos necessários às ações de melhoria.

4. Não adotar as mudanças no processo

É da natureza humana apresentar resistência a mudanças – mudar envolve sair da zona de conforto, aquela em que conhecemos e controlamos como as coisas funcionam.

Por este motivo, comunicar bem e garantir que os envolvidos tenham tempo suficiente para compreender e aceitar as mudanças propostas é fundamental para o sucesso da implantação de otimizações no processo. As pessoas precisam entender por quê as mudanças estão sendo feitas para assimilar os benefícios a serem obtidos e efetivamente adotá-las.

5. Displicência na execução

Holterman aponta que em muitas organizações, os projetos de otimização acabam se perdendo em um perpétuo estudo e desgastante levantamento de informações, colecionando e analisando todo tipo de dado que se pode coletar acerca do processo na tentativa de representá-lo da forma mais apurada, às vezes envolvendo até mesmo coleta de informações de outros processos que nem estão diretamente relacionados ao escopo de otimização prevista no projeto. Mas dispender toda energia em gerar estatísticas complexas e painéis de monitoramento não trarão resultados práticos de otimização.
Controlar a execução, garantindo que as otimizações definidas sejam efetivamente executadas como planejadas, são um dos grandes desafios de um projeto de otimização e podem encontrar suporte na implementação do processo em um BPMS (Business Process Management Sustem).  Para mais informações do que esperar da implementação de um processo em um BPMS, leia nosso post “Benefícios da Automação de Processos“.

E veja no artigo “Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!” que avaliações recomendamos antes da decisão por automatizar um processo de negócio.

 

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