Como encontramos uma maneira legal de conectar negócios e DevOps

A filosofia DevOps, quando o desenvolvimento é aliado à manutenção de software, não surpreenderá ninguém. Uma nova tendência está ganhando força – DevOps 2.0 ou BizDevOps. Combina três componentes em um único todo: negócios, desenvolvimento e suporte. E assim como no DevOps, as práticas de engenharia formam a base da conexão entre desenvolvimento e suporte, e no desenvolvimento de negócios, a análise assume o papel de “cola” que une o desenvolvimento ao negócio.

Quero admitir desde já: só descobrimos agora que temos um verdadeiro desenvolvimento de negócios, depois de ler livros inteligentes. De alguma forma, tudo se concretizou graças à iniciativa dos colaboradores e a uma paixão irreprimível pela melhoria. A análise agora faz parte do processo de produção de desenvolvimento, reduzindo significativamente os ciclos de feedback e fornecendo insights regularmente. Vou lhe contar em detalhes como tudo funciona para nós.

Como encontramos uma maneira legal de conectar negócios e DevOps

Desvantagens do DevOps clássico

Quando novos produtos para o cliente 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 seus objetivos e resultados de negócios. A equipe de desenvolvimento, por sua vez, se esforça para criar um código muito bom e de alta qualidade. O suporte espera automação completa dos processos, facilidade e comodidade na manutenção de um novo produto.

A realidade geralmente se desenvolve de tal forma que os clientes recebem um processo bastante complexo, o negócio fica preso a uma baixa conversão, as equipes de desenvolvimento lançam correção após correção e o suporte fica afogado no fluxo de solicitações dos clientes. Soa familiar?

A raiz do mal aqui reside no longo e deficiente ciclo de feedback incorporado ao processo. Empresas e desenvolvedores, ao coletar requisitos e receber feedback durante os sprints, comunicam-se com um número limitado de clientes que influenciam bastante o destino do produto. Freqüentemente, o que é importante para uma pessoa não é típico de todo o público-alvo.
Entender se um produto está caminhando na direção certa vem com relatórios financeiros e resultados de pesquisas de mercado meses após o lançamento. E devido ao tamanho limitado da amostra, não oferecem a oportunidade de testar hipóteses em um grande número de clientes. Em geral, revela-se longo, impreciso e ineficaz.

Ferramenta de troféu

Encontramos uma boa maneira de fugir disso. Uma ferramenta que antes só ajudava profissionais de marketing agora chegou às mãos de empresas e desenvolvedores. Começamos a usar ativamente a análise da web para observar o processo em tempo real, aqui e agora, para entender o que está acontecendo. Com base nisso, planeje o próprio produto e distribua-o para um grande número de clientes.
Se você estiver planejando algum tipo de melhoria de produto, poderá ver imediatamente a quais métricas ela está associada e como essas métricas afetam as vendas e características que são importantes para o negócio. Dessa forma, você pode eliminar imediatamente hipóteses com baixo efeito. Ou, por exemplo, implemente um novo recurso para um número estatisticamente significativo de usuários e monitore as métricas em tempo real para entender se tudo funciona conforme o esperado. Não espere por feedback na forma de solicitações ou relatórios, mas monitore imediatamente e ajuste você mesmo prontamente o processo de criação do produto. Podemos lançar um novo recurso, coletar dados estatisticamente corretos em três dias, fazer alterações em outros três dias – e em uma semana um excelente novo produto estará pronto.

Você pode acompanhar todo o funil, todos os clientes que tiveram contato com o novo produto, detectar pontos onde o funil se estreitou acentuadamente e entender os motivos. Tanto os desenvolvedores quanto as empresas agora monitoram isso como parte de seu trabalho diário. Eles veem a mesma jornada do cliente e juntos podem gerar ideias e hipóteses de melhoria.

Essa integração de negócios e desenvolvimento junto com análises permite criar produtos de forma contínua, otimizar constantemente, buscar e visualizar gargalos e todo o processo como um todo.

É tudo uma questão de complexidade

Quando criamos um novo produto, não começamos do zero, mas integramo-lo numa rede de serviços já existente. Ao experimentar 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 do escritório, pode entrar em contato com o suporte ou em chats online. Usando métricas, podemos ver, por exemplo, qual é a carga do contact center, qual a melhor forma de processar as solicitações recebidas. Podemos entender quantas pessoas chegam ao escritório e sugerir como orientar melhor o cliente.

É exatamente o mesmo com os sistemas de informação. Nosso banco existe há mais de 20 anos, durante os quais uma grande camada de sistemas heterogêneos foi criada e ainda funciona. A interação entre sistemas backend às vezes pode ser imprevisível. Por exemplo, em alguns sistemas antigos há restrições quanto ao número de caracteres para um determinado campo e, às vezes, isso trava o novo serviço. É muito difícil rastrear um bug usando métodos padrão, mas usando análise da web é fácil.

Chegamos ao ponto em que começamos a coletar e analisar textos de erros que são mostrados ao cliente de todos os sistemas envolvidos. Acontece que muitos deles estavam desatualizados e nem podíamos imaginar que estivessem de alguma forma envolvidos em nosso processo.

Trabalhando com análises

Nossos analistas web e equipes de desenvolvimento SCRUM estão localizados na mesma sala. Eles interagem constantemente entre si. Quando necessário, especialistas ajudam a configurar métricas ou fazer upload de dados, mas principalmente os próprios membros da equipe trabalham com o serviço de análise, não há nada complicado nisso.

A ajuda será necessária se, por exemplo, você precisar de algumas dependências ou filtros adicionais para um tipo limitado de clientes ou fontes. Mas na arquitetura atual raramente encontramos isso.

Curiosamente, a implementaçã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 trabalharam anteriormente. Foi necessário apenas concordar com sua utilização e implementá-la nos negócios e no desenvolvimento. Claro que não podíamos simplesmente pegar o que o marketing tinha, tínhamos que reconfigurar tudo de novo e dar acesso ao marketing ao novo ambiente para que eles estivessem no mesmo campo de informação que nós.

No futuro, planeamos adquirir uma versão melhorada do software de análise web que nos permitirá lidar com os volumes crescentes de sessões processadas.

Também estamos ativamente no processo de integração de análises da web e bancos de dados internos de CRM e sistemas de contabilidade. Ao combinar os dados, obtemos uma visão completa do cliente em todos os aspectos necessários: por fonte, tipo de cliente, produto. Os serviços de BI que ajudam a visualizar os dados estarão em breve disponíveis para todos os departamentos.

Com o que acabamos? Na verdade, tornamos a análise e a tomada de decisões parte do processo de produção, o que teve um efeito visível.

Analytics: não pise no rake

E, por fim, quero compartilhar algumas dicas que o ajudarão a evitar problemas no processo de construção de um negócio de desenvolvimento de negócios.

  1. Se você não consegue fazer análises rapidamente, então você está fazendo análises erradas. Você precisa seguir um caminho simples a partir de um produto e depois aumentar a escala.
  2. Você deve ter uma equipe ou pessoa que tenha um bom entendimento da futura arquitetura analítica. Você ainda precisa decidir como dimensionará a análise, integrá-la a outros sistemas e reutilizar os dados.
  3. Não gere dados desnecessários. As estatísticas da Web, além de informações úteis, também são um enorme depósito de lixo com dados desnecessários e de baixa qualidade. E esse lixo vai interferir na tomada de decisões e na avaliação se não houver objetivos claros.
  4. Não faça análises por analisar. Primeiro, objetivos, escolha da ferramenta e só então - análise apenas onde terá efeito.

O material foi elaborado em conjunto com Chebotar Olga (olga_cebotari).

Fonte: habr.com

Adicionar um comentário