A filosofia do DevOps, quando o desenvolvimento se conecta à manutenção do software, não surpreende ninguém. Uma nova tendência está ganhando força - DevOps 2.0 ou BizDevOps. Nele, três componentes se fundem em um único todo: negócios, desenvolvimento e suporte. E, como nas práticas de engenharia do DevOps'e formam a base da conexão entre desenvolvimento e suporte, no ambiente de negócios, o analista assume o papel da “cola” que combina desenvolvimento com negócios.
Quero admitir imediatamente: que temos um bizdevops real, só aprendemos agora lendo livros inteligentes. De alguma forma, desenvolveu-se graças à iniciativa dos funcionários e a uma paixão incansável por melhorias. Agora, a análise faz parte do processo de desenvolvimento da produção, reduzindo significativamente os loops de feedback e fornecendo insights regularmente. Vou contar em detalhes como tudo está organizado conosco.
Desvantagens do DevOps clássico
Quando novos produtos para clientes são concebidos, uma empresa cria um modelo ideal de comportamento do cliente e espera uma boa conversão, com base na qual constrói suas metas e resultados de negócios. A equipe de desenvolvimento, por sua vez, está comprometida em criar um código muito bom e de alta qualidade. O suporte, no entanto, espera a automação completa dos processos, a facilidade e a conveniência de manter um novo produto.
A realidade geralmente se desenvolve de tal maneira que os clientes obtêm um processo bastante complicado, os negócios se baseiam em baixa conversão, as equipes de desenvolvimento emitem correção por correção e o suporte está se afogando no fluxo de solicitações dos clientes. Isso é familiar?
A raiz do mal aqui reside em um ciclo de feedback longo e de baixa qualidade incorporado no processo. Ao coletar requisitos e receber feedback durante os sprints, os negócios e os desenvolvedores se comunicam com um número limitado de clientes, o que afeta muito o destino do produto. Freqüentemente, o que é importante para alguém não é de todo característico de todo o público-alvo.
Entender se o produto está sendo desenvolvido na direção certa vem com relatórios financeiros e resultados de pesquisas de marketing meses após o lançamento. E eles, devido à amostragem limitada, não oferecem a possibilidade de testar hipóteses em um grande volume de clientes. Em geral, é longo, impreciso e ineficiente.
Instrumento troféu
Encontramos uma boa maneira de fugir disso. Uma ferramenta que costumava ajudar apenas os profissionais de marketing, caímos nas mãos de empresas e desenvolvedores. Começamos a usar ativamente a análise da web para analisar o processo em tempo real, aqui e agora para entender o que está acontecendo. Com base nisso, planeje o próprio produto, lançando-o para um grande volume de clientes.
Se você planeja algum tipo de melhoria do produto, pode ver imediatamente com quais métricas estão associadas e como essas métricas afetam as características de vendas e negócios. Assim, você pode eliminar imediatamente hipóteses com um efeito baixo. Ou, por exemplo, implante um novo recurso para um número estatisticamente significativo de usuários e siga as métricas em tempo real, para entender se tudo funciona como pretendido. Não espere pelo feedback na forma de recursos ou relatórios, mas monitore imediatamente e ajuste rapidamente o processo de criação do produto. Podemos lançar um novo recurso, em três dias já coletar dados estatisticamente corretos, fazer alterações em mais três dias - e agora em uma semana um excelente novo produto está pronto.
Você pode acompanhar o funil inteiro, todos os clientes que entraram em contato com um novo produto, encontrar os pontos nos quais o funil se estreitou bastante e descobrir os motivos. Agora, tanto os desenvolvedores quanto as empresas estão assistindo isso, isso faz parte do trabalho diário. Eles veem o mesmo caminho do cliente e, juntos, podem gerar idéias e hipóteses para melhoria.
Essa integração de negócios e desenvolvimento, juntamente com a análise, permite criar produtos continuamente, otimizar constantemente, procurar e ver gargalos, durante todo o processo.
É uma questão de complexidade
Quando criamos um novo produto, não começamos do zero, mas o incorporamos aos meandros dos serviços já existentes. Experimentando um novo produto, o cliente geralmente entra em contato com vários departamentos. Ele pode se comunicar com os funcionários do contact center, com os gerentes no escritório, pode entrar em contato com o suporte, em bate-papos online. Usando métricas, podemos ver, por exemplo, qual é a carga no contact center, a melhor forma de lidar com solicitações recebidas. Podemos entender quantas pessoas chegam ao escritório e sugerir como aconselhar ainda mais o cliente.
Com sistemas de informação, tudo é exatamente o mesmo. Nosso banco existe há mais de 20 anos. Durante esse período, uma grande camada de sistemas heterogêneos foi criada e ainda está funcionando. A interação entre sistemas de back-end é às vezes imprevisível. Por exemplo, em algum sistema antigo de um determinado campo, há restrições no número de caracteres e, às vezes, isso causa um novo serviço. O rastreamento de um bug por métodos padrão é bastante difícil, mas o uso da web analytics é fundamental.
Chegamos ao ponto em que começamos a receber e analisar os textos de erros que são mostrados ao cliente em todos os sistemas envolvidos. Aconteceu que muitos deles estavam desatualizados, e não podíamos nem imaginar que estivessem de alguma forma envolvidos em nosso processo.
Trabalhar com análises
Temos equipes de análise da web e desenvolvimento SCRUM na mesma sala. Eles constantemente interagem um com o outro. Quando necessário, os especialistas ajudam a configurar métricas ou fazer upload de dados, mas basicamente os próprios membros da equipe trabalham com o serviço de análise, não há nada complicado.
É necessária ajuda se, por exemplo, você precisar de algumas dependências, filtros adicionais para um tipo limitado de clientes ou fontes. Mas na arquitetura atual, raramente encontramos isso.
Curiosamente, a introdução da análise não exigiu a instalação de um novo sistema de TI. Usamos o mesmo software com o qual os profissionais de marketing trabalhavam anteriormente. Só era necessário coordenar seu uso e implementá-lo nos negócios e desenvolvimento. Obviamente, não podíamos apenas pegar o que o marketing tem, tivemos que reconfigurar tudo e dar acesso ao marketing para o novo ambiente, para que eles estivessem conosco no mesmo campo de informações.
No futuro, planejamos comprar uma versão aprimorada do software de análise da web que irá lidar com o crescente volume de sessões processadas.
Também estamos integrando ativamente análises da web e bancos de dados internos do CRM e sistemas de contabilidade. Ao combinar os dados, obtemos uma imagem completa do cliente em todas as seções necessárias: por fonte, tipo de cliente, produto. Os serviços de BI que ajudam a visualizar dados em breve estarão disponíveis para todos os departamentos.
Com o que acabamos? De fato, fizemos da análise e da tomada de decisão parte do processo de produção, o que deu um efeito visível.
Analytics: não pise em um ancinho
E, finalmente, quero compartilhar dicas que ajudarão a evitar cones no processo de criação de um plano de negócios.
- Se a análise não puder ser feita rapidamente, você estará fazendo a análise errada. Você precisa seguir um caminho simples de um produto e depois escalar.
- Você deve ter uma equipe ou pessoa que entenda bem a arquitetura de análise futura. Também é necessário decidir em terra como você escalará a análise, integrá-la a outros sistemas, reutilizar os dados.
- Não gere dados extras. As estatísticas da Web são, além de informações úteis, também um grande depósito de lixo com dados redundantes e de baixa qualidade. E esse lixo interferirá na tomada de decisões e na avaliação, se não houver objetivos claros.
- Não faça análises para análises. A princípio, os objetivos, a escolha de um instrumento e, somente então - a análise apenas onde produzirá um efeito.
Material preparado em conjunto com Chebotar Olga (
olga_cebotari ).