Falei com muitos colegas de análise que são adoradores de que eles querem que a sua equipa nunca toque na “produção”. Embora existam boas razões para ter cuidado sempre que você faz mudanças que possam impactar os clientes, acredito que, à medida que o software se torna mais orientado a dados, é fundamental encontrar maneiras seguras de capacitar as equipes de análise a construir e implantar aplicativos orientados a dados.
O que é Produção?
Primeiro, alguma definição de termo. “Produção” é um ambiente. Geralmente existem alguns ambientes onde o código pode ser executado (em ordem de progressão):
- Desenvolvimento local
- Desenvolvimento remoto
- Estaging / QA
- Produção
Cada “aplicação” terá vários ambientes, um dos quais será o que enfrentará usuários não-desenvolvedores. O que enfrenta usuários que não são desenvolvedores é normalmente chamado de “produção”.
Aqui está minha tese: É fundamental que as equipes de análise tenham impacto sobre os aplicativos que enfrentam os clientes1Há, é claro, exceções a isso e diferentes tipos de aplicativos terão diferentes “graus” de dados. Historicamente, algumas empresas têm hesitado em tornar suas aplicações mais orientadas a dados porque seus engenheiros de software não tinham as habilidades de dados e tinham medo de deixar a equipe Analytics impactar a aplicação. É claro que você deve tomar decisões sobre a adição de novos recursos com base no quanto eles serão valiosos, não simplesmente porque algum blogueiro lhe disse para… Se não for possível habilitar isso de forma segura, então você deve modificar seu aplicativo voltado para o cliente de forma a tornar isso possível.
Se você achou esse último parágrafo chocante, estou prestes a estourar suas meias: todos os seus analistas estão implantando para a produção todos os dias, já. Deixe-me acompanhá-lo através do meu favorito2 e mais detestável. As pessoas me adoram nas festas. linha de questionamento:
- A ferramenta de BI que você configura para fornecer relatórios aos usuários dentro da sua empresa – isso não é produção?
- O script R que montou os dados, limpa-os e fornece visualizações para um PPT que é enviado por e-mail para a equipe de execução, isso não é produção?
- O arquivo Excel (preenchido com código) que é usado para tomar uma decisão de inventário multi-milionário, isso não é produção?
Lembrar: só porque você não tem um ambiente de desenvolvimento não significa que seu ambiente voltado para o usuário não seja de produção!
Para muitas startups, as pessoas usam “produção” como abreviação para se referir ao seu aplicativo web voltado para o usuário (dependendo do estágio da empresa, pode ou não ainda ser um monólito de Rails). Além de dizer que você deve parar de usar termos tão pouco claros, eu quero advogar para pensar sobre o porquê de você querer permitir que analistas não engenheiros e cientistas de dados possam implantar uma aplicação voltada para o cliente. Vou terminar com algumas estratégias de como você pode operacionalizar isto.
Por que capacitar a equipe de análise a impactar os clientes?
Aplicativos orientados a dados de construção é um jogo de tabela para a engenharia moderna de software e desenvolvimento de produtos. Os aplicativos de amanhã terão dados integrados de haste a popa e se houver uma parede entre os seus especialistas em dados e os desenvolvedores de aplicativos, você vai passar um mau bocado.
Aqui estão alguns exemplos de produtos orientados a dados que você pode querer construir:
- Amostras de implementação Thompson para variantes de sites de teste de bandidos multi-armação
- Clientes de cluster para e-mails de marketing direcionados ou variantes de páginas de destino
- Prever clientes com probabilidade de agitar e dar apenas a esses clientes um código de cupom
- Introduzir algoritmos de recomendação de produtos / ranking de busca
Se você quiser construir esses produtos orientados por dados, você vai querer seus especialistas em dados trabalhando neles. Aqui estão algumas razões para pensar em embaçar a linha entre seus Analytics3 Como de costume, neste post eu uso o termo “Analytics” e “analistas” da maneira mais ampla possível, incluindo cientistas de dados, analistas de dados e outros especialistas em dados. equipe e o resto de sua equipe de engenharia de software:
- Cientistas de dados são seus especialistas em algoritmos, e a integração contínua é importante
- Você quer que sua aplicação seja alimentada por dados!!
- Analistas conhecem melhor os dados, por isso são menos propensos a cometer erros
- Produzir o trabalho de outra pessoa é um trabalho de merda
- Titeração analítica de bloqueio com priorização de eng torna todos mais lentos e leva à frustração
>
>
>
>
>
Não é controverso deixar os gerentes de produto ou designers implantar novos conteúdos no site através de um CMS. Se essa marcação suportada, deve ser trivial também. Você também poderia deixar os analistas ajustar os pesos dos algoritmos através de um CMS, então por que não deixá-los implantar um modelo desde que esse modelo esteja de acordo com a API que a aplicação espera? Claro, porque sua equipe de análise pode não ter todas as ferramentas ou habilidades para trabalhar em uma aplicação web complexa, você quer ter certeza de que eles podem fazer essas mudanças de uma maneira que seja segura e eficaz (ou seja, eles podem usar as ferramentas com as quais estão familiarizados e as outras partes são abstraídas).
Como capacitar a equipe de análise para impactar os clientes?
Agora que já discutimos o porquê disso ser uma boa idéia, podemos falar sobre algumas maneiras de fazer isso acontecer de forma segura e eficaz. Aqui estão alguns exemplos que eu vi no passado (e eu adoraria ouvir mais sobre isso se você conhecer algum bom padrão):
- Micro serviços
- O algoritmo de classificação de produtos pode viver atrás de uma API para que a equipe de análise possa implementar mudanças sem tocar no resto do aplicativo
- Perfis de usuário
- Você pode persistir em atributos-chave de usuário em uma tabela à qual seu aplicativo web tenha acesso (e.g., através de um cache redis) que é gerenciado pela equipe de análise (ETL, ML, o que for, desde que a API não mude)
- Pesosições / Pontuações
- Se você tiver um modelo que funcione sem pesos ou atributos para criar uma “pontuação” (por exemplo, uma pontuação de risco de fraude) então você pode manter esses pesos em uma tabela que a equipe de análise pode ter acesso de escrita para
Eu já escrevi sobre o padrão de design de código como configuração antes, e em geral este é um ótimo padrão para capacitar não-engenheiros a implementar o código em ambientes de produção de forma inteligente. Friend-of-the-blog Harlan Harris também escreveu sobre o uso de linguagens específicas de domínio para facilitar o teste, coordenação e implementação de modelos de aprendizagem de máquinas em produção.