Dois em uma caixa (se puder) e todos na documentação (sempre).
Em um contexto de TI, “dois em uma caixa” refere-se a dois servidores ou componentes projetados para trabalhar juntos para fornecer redundância e maior confiabilidade. Essa configuração pode garantir que, em caso de falha de um componente, o outro assuma suas operações, mantendo assim a continuidade do serviço. O objetivo de ter “dois em uma caixa” é fornecer alta disponibilidade e recuperação de desastres. Isso também se aplica às funções humanas em uma organização; no entanto, raramente é implementado.
Vejamos um exemplo relevante do Analytics. Todos nós provavelmente conhecemos uma pessoa em nossa empresa ou organização pelo nome que é a pessoa “válida” para o Analytics. São eles que têm relatórios ou painéis com seus nomes – Relatório do Mike ou Painel da Jane. Claro, existem outras pessoas que conhecem análises, mas esses são os verdadeiros campeões que parecem saber como fazer as coisas mais difíceis e superar os prazos. A questão é que essas pessoas estão sozinhas. Em muitos casos sob pressão, eles não trabalham com ninguém, pois isso pode atrasá-los e é aí que o problema começa. Nunca pensamos que vamos perder essa pessoa. Vou me abster do típico “digamos que eles foram atropelados por um ônibus” ou usar um exemplo aproveitando as oportunidades atuais do mercado de trabalho e dizer algo positivo como “eles ganharam na loteria!”, porque todos devemos fazer nossa parte para sermos positivos nos dias de hoje.
The Story
A manhã de segunda-feira chega e nosso especialista em análise e campeão MJ apresentou sua renúncia. MJ ganhou na loteria e já saiu do país sem se importar com o mundo. A equipe e as pessoas que conhecem MJ estão emocionadas e com ciúmes, mas o trabalho deve continuar. Agora é quando o valor e a realidade do que MJ estava fazendo estão prestes a ser compreendidos. MJ foi responsável pela publicação final e validação das análises. Eles sempre pareciam ser capazes de melhorar a eficiência ou fazer aquela mudança difícil antes de fornecer a análise para todos. Ninguém realmente se importava em como isso foi feito e estava seguro no fato de que simplesmente aconteceu, e MJ era uma estrela do rock individual do Analytics, então um nível de autonomia foi concedido. Agora, quando a equipe começa a juntar as peças, os pedidos, os problemas diários, os pedidos de modificação, eles ficam perdidos e começam a lutar. Relatórios/Painéis são encontrados em estados desconhecidos; alguns recursos não foram atualizados no fim de semana e não sabemos o motivo; as pessoas estão perguntando o que está acontecendo e quando as coisas serão consertadas, as edições que MJ disse que foram feitas não estão aparecendo e não temos ideia do porquê. A equipe parece ruim. É um desastre e agora todos nós odiamos MJ.
As lições
Existem alguns tópicos fáceis e óbvios.
- Nunca permita que um indivíduo trabalhe sozinho. Parece bom, mas em equipes ágeis menores, não temos tempo ou pessoas para fazer isso acontecer. As pessoas vêm e vão, as tarefas são muitas, então é dividir e conquistar em nome da produtividade.
- Todos devem compartilhar seus conhecimentos. Também soa bem, mas estamos compartilhando com a pessoa ou pessoas certas? Tenha em mente que muitos ganhadores de loteria são colegas de trabalho. Fazer sessões de compartilhamento de conhecimento também tira tempo das tarefas e a maioria das pessoas só investe em habilidades e conhecimento na hora em que é necessário.
Então, quais são algumas soluções reais que todos podem implementar e apoiar?
Vamos começar com o Gerenciamento de Configuração. Usaremos isso como um termo abrangente para vários tópicos semelhantes.
- Mudar a gestão: O processo de planejamento, implementação e controle de mudanças em sistemas de software de forma estruturada e sistemática. Este processo visa garantir que as alterações sejam feitas de forma controlada e eficiente (com capacidade de reversão), com o mínimo de interrupção do sistema existente e o máximo benefício para a organização.
- Gerenciamento de Projetos: O planejamento, organização e controle de projetos de desenvolvimento de software para garantir que sejam concluídos no prazo, dentro do orçamento e com os padrões de qualidade desejados. Envolve a coordenação de recursos, atividades e tarefas ao longo do ciclo de vida de desenvolvimento de software para atingir os objetivos do projeto e entregar o produto de software dentro do cronograma.
- Integração Contínua e Entrega Contínua (CI/CD): O processo de automatizar a construção, teste e implantação de software. A Integração Contínua requer a fusão regular de alterações de código em um repositório compartilhado e a execução de testes automatizados para detectar erros no início do processo de desenvolvimento. A entrega/implantação contínua envolve a liberação automática de alterações de código testadas e validadas na produção, permitindo lançamentos rápidos e frequentes de novos recursos e melhorias.
- Controle de versão: O processo de gerenciamento de alterações no código-fonte e outros artefatos de software ao longo do tempo usando ferramentas de software especializadas. Ele permite que os desenvolvedores colaborem em uma base de código, mantenham um histórico completo de alterações e experimentem novos recursos sem afetar a base de código principal.
Todos os itens acima se referem a boas práticas de desenvolvimento de software. As análises que impulsionam e administram os negócios não merecem menos, pois são essenciais para a tomada de decisões. Todos os recursos analíticos (trabalhos ETL, definições semânticas, definições de métricas, relatórios, painéis, histórias etc.) são apenas trechos de código com uma interface visual para design e alterações aparentemente menores podem causar estragos nas operações.
Usar o Gerenciamento de Configuração nos cobre para continuar funcionando em um bom estado. Os ativos são versionados para que possamos ver o que aconteceu em sua vida útil, sabemos quem está trabalhando em quê, juntamente com o progresso feito e os cronogramas, e sabemos que a produção continuará. O que não está coberto por nenhum processo puro é a transferência de conhecimento e a compreensão de por que as coisas são como são.
Cada sistema, banco de dados e ferramenta de análise tem suas próprias peculiaridades. Coisas que os fazem ir rápido ou devagar, itens que os fazem se comportar de uma certa maneira ou produzir um resultado desejado. Podem ser configurações em um nível de sistema ou global ou itens dentro do design do ativo que os fazem funcionar exatamente como deveriam. O problema é que a maioria dessas coisas são aprendidas com o tempo e nem sempre há um lugar para documentá-las. Mesmo quando mudamos para sistemas em nuvem, onde não controlamos mais como o aplicativo é executado e contamos com o fornecedor para torná-lo o mais rápido possível, o ajuste de definições continua em nossos ativos para revelar exatamente o que estamos procurando. Esse conhecimento é o que precisa ser capturado e compartilhado, tornando-o disponível para outras pessoas. Esse conhecimento deve ser exigido como parte da documentação de ativos e parte integrante do controle de versão e verificação de CI/CD e processo de aprovação e, em alguns casos, até mesmo como parte de uma lista de verificação antes da publicação de coisas a fazer e não fazer.
Não há respostas mágicas ou IA para encobrir atalhos em nossos processos analíticos ou a falta deles. Independentemente do tamanho da equipe que mantém os dados e análises fluindo, um investimento em um sistema para rastrear mudanças, versão de todos os ativos e ajudar a documentar o processo de desenvolvimento e capturar conhecimento é obrigatório. O investimento em processos e tempo antecipadamente economizará uma tonelada de tempo perdido depois, descobrindo as coisas para manter um estado saudável de nossas análises. As coisas acontecem e é melhor ter uma apólice de seguro para MJs e outros ganhadores de loteria.
