Conectores de sucesso: Melhores Práticas e Estratégias de Implementação

A melhor prática com conectores é sempre forçar uma abordagem baseada em regras e lidar com quaisquer exceções posteriormente ou após o esgotamento baseado em regras, em vez de começar com uma abordagem baseada em exceções.

A abordagem baseada em exceções é tentadora e atraente porque valoriza a escolha humana e a preservação da estrutura atual do processo. Mas traça um vetor para um lugar que não oferecerá boas alternativas para dimensionar e sustentar processos saudáveis a longo prazo. Nesse sentido, começar pensando nas exceções em vez das regras é um erro que evitamos a todo custo.

Ganho a curto prazo para dor a longo prazo em poucas palavras. A maioria das organizações com as quais trabalhamos compartilha isso em comum: elas buscam a preservação do processo atual. Quando a tecnologia é buscada, ela é destinada a abraçar o processo atual, em vez de encontrar um meio-termo entre as limitações do processo e a eficiência.

Nossos conectores são uma forma de conectar o fluxo de conteúdo de um repositório para o BWX e depois de volta. Embora entendamos a necessidade ocasional de selecionar um arquivo ou outro para um trabalho baseado em conectores, a melhor prática para os conectores é seguir uma abordagem baseada em regras em vez de uma abordagem manual.

‍A tentação da abordagem manual explicada

‍As abordagens manuais são tentadoras porque não exigem nenhuma mudança no processo. As pessoas podem explorar o arquivo exato que desejam traduzir e iniciar um projeto de tradução usando o conector. O problema com a abordagem manual é que ela não é escalável, não é sustentável e previsível (difícil de melhorar).

É por isso que exploramos a abordagem manual apenas depois de esgotarmos todas as possibilidades de ajustar o comportamento do conector ao comportamento baseado em regras. É necessário lidar com exceções, mas você não pode projetar com base em exceções.

Um produto bem-sucedido e sua respectiva implementação são baseados em regras que abrangem a maior porcentagem possível de casos de uso. Casos de uso que não são abordados precisam ser cuidadosamente avaliados para explorar as soluções alternativas e instrumentá-los dentro dos paradigmas propostos.

Aqui está um exemplo: o cliente A possui um conector que funciona com base em um cronograma, mas ocasionalmente eles têm projetos que exigem uma execução fora do cronograma. Aqui estão algumas opções diferentes de como abordar isso:

1. Solicite manualmente uma execução fora do cronograma para nossa equipe de suporte
2. Use our CLI para solicitar uma execução fora do cronograma
3. Crie um ramo/diretório fora do ciclo que seja verificado com mais frequência do que o cronograma típico, a fim de pegar trabalhos urgentes.

Aqui está mais um exemplo: o cliente B é usado para selecionar arquivos para iniciar o processo de localização. Em vez de perpetuar a abordagem manual, a maioria dos processos de seleção criteriosa segue um comportamento que pode ser engenharia reversa.

Sempre vale a pena se esforçar para levar essa engenharia reversa ao seu limite. Se você começar com uma abordagem manual ou focar em cobrir as exceções logo de cara através da interface do usuário, isso se tornará um obstáculo debilitante em vez de um acelerador de programa. Quando pensamos em um conector, sempre pensamos em automação.

Essa é a verdadeira eficiência do processo impulsionada por um conector. Exportar e importar projetos é um pequeno ganho quando se trata de conectores. O verdadeiro ganho gira em torno das regras de negócio e da previsibilidade e governança que elas geram.

O problema é que se você projetar e implementar por exceção, a automação nunca se torna realmente uma opção. A automação, por definição, requer algum grau de mudança de processo e se não buscarmos essa adequação entre processo e software, acabamos não superando as expectativas e nos tornamos vendedores da digitalização do caos.

Isso não é o que defendemos e não iremos adotar isso. Os conectores de pequena escala devem seguir o mesmo design e princípios dos conectores de grande escala para que possam escalar e crescer de forma eficiente. A maioria dos programas de localização solicita soluções baseadas em casos de uso atuais (que na verdade são do passado), em oposição a casos de uso voltados para o futuro que projetam mais arquivos, mais cadência, mais localidades, menos tempo de lançamento, menos custo e mais pessoas trabalhando juntas.

Se você não iniciar no curso correto, a correção posterior será cara e muito desafiadora, pois você perderá a janela de mudança introduzida por uma nova implementação. Todos os nossos conectores, grandes ou pequenos, são baseados em regras e parâmetros.

Eles são regidos pelos mesmos princípios de design e nenhum deles requer uma interface de usuário para funcionar corretamente. A interface do usuário pode ser um complemento interessante para um conector maduro, mas principalmente para alterar facilmente as configurações do conector, ao invés de ser uma forma de iniciar projetos manualmente.

Não podemos promover o sucesso a longo prazo se formos cúmplices da aceleração dos processos analógicos existentes.  

Pelo contrário, nosso objetivo é traduzir os processos analógicos em pensamento digital para que se tornem verdadeiramente compatíveis com o software, permitindo automação orientada por dados. Estamos acostumados a gerenciar conectores que processam milhares de arquivos por dia em quase cem localidades diferentes.

Ao longo dos anos, aprendemos que os mesmos ingredientes que tornam um conector em grande escala bem-sucedido também devem ser respeitados para conectores em pequena escala, a fim de aderir aos princípios básicos de design de escalabilidade e sustentabilidade.