Mesmo em empresas muito grandes, eles costumam tratar os desenvolvedores como cogumelos: são mantidos no escuro e alimentados com esterco. Escreva o código, família e não fique de fora. Essa abordagem pode ser conveniente para muitos (incluindo algumas vezes para os próprios desenvolvedores no caso de gerenciamento não muito adequado), mas do ponto de vista dos negócios não é o ideal. Minha posição: os desenvolvedores devem ser capazes de aprender tudo o que acontece na empresa e no mercado, mas sem pressão. Queria - ele cavou e descobriu, não queria - não.
É raro que um desenvolvedor não queira entender o porquê e o que está fazendo. Poucos que não querem ver o impacto dos recursos implementados no mundo todo. Vamos ser sinceros: estamos todos aqui por causa do dinheiro ou por causa da capacidade de fazer algo significativo. Há dinheiro em todo lugar. Mas projetos interessantes são menos comuns.
Quero compartilhar o processo de como organizamos essas informações na equipe do Tutu.ru. Talvez para alguns pareça um programa educacional, mas para alguém será útil. Bem, ou você me diz como fazer melhor.
Posição geral
- A equipe de desenvolvimento, na medida do possível, deve dizer o que está acontecendo no mercado, que tipo de relacionamento com os concorrentes, o que e como isso acontece.
- É importante que a alta gerência da empresa saiba exatamente o que foi feito no projeto e como isso leva ao objetivo estratégico. Normalmente, estamos falando sobre o nível dos grupos de projetos, mas se você quiser, pode deixar de relatar um trabalho específico.
- Outras equipes estão interessadas em ver o que os colegas estão fazendo. Usamos diferentes tipos de transporte (ferroviário, aéreo, de ônibus) para resolver problemas semelhantes, e muitas vezes você pode reutilizar o código, espionar uma idéia ou ver como diferentes ferramentas são usadas. E pergunte.
O que isso afeta?
Pode parecer que, se um desenvolvedor reprimir uma tarefa de cima, o máximo que ele é capaz com uma imagem completa do conhecimento é escolher uma solução arquitetural um pouco mais correta. Acredita-se que isso reduza a taxa de crescimento da dívida técnica, à medida que a correção da arquitetura aumenta. Sim, isso é verdade, mas, na prática, organizar e apoiar o processo de informações fora do almoço é tão difícil quanto lidar com dívidas técnicas.
Mas então a segunda coisa importante aparece. Ou seja, aqueles que querem participar de sessões de brainstorming junto com os negócios. Ou seja, se antes o próprio negócio planejou, definiu tarefas e prioridades e disse a si mesmo o que e como fazer, agora o desenvolvimento o afeta.
E aqui temos muitas vezes um fenômeno muito interessante. O pensamento de um engenheiro é diferente do de uma pessoa comum. Em algum lugar mais estrutural, em algum lugar inesperadamente boas decisões, em algum lugar distorções cognitivas. Há uma aparência sem nuvens. Há uma negação das práticas "aconteceu" porque, para algumas, elas são um dado, e para o engenheiro elas são um legado sombrio. E não se importa quantos anos ele tem.
Inicialmente, as discussões diminuíram. Os desenvolvedores obviamente tinham grandes dificuldades com a análise financeira, e era necessário carregá-los com muita frequência para justificar a possibilidade ou impossibilidade (mais frequentemente) de uma solução.
Então, algumas vezes, consegui encontrar lugares onde os negócios nem pensavam que algo pudesse ser feito com quase um movimento. Assim, por exemplo, usando um modelo matemático de movimento de ônibus, fomos capazes de fazer paradas em rotas e restaurar a programação em ambas as direções.
Aqui está a história .
A próxima coisa importante é que um único sistema deverá aparecer no mercado nos próximos 1-2 anos. Um ano atrás, parecia fantástico, e cada transportadora, incluindo pequenas SPs com ônibus enferrujados dos anos 80, tinha seus próprios padrões. Agora tudo isso acaba em um único sistema de informação. Já construímos parte de sua funcionalidade, mas agora será possível remover essa camada e obter imediatamente dados limpos. É claro que, com essa mudança no mercado, precisamos de toda a equipe para discutir. No mínimo, isso remove as perguntas do nível "por que não terminamos meu código legal de um recurso interessante" e, no máximo, torna possível preparar as alterações com mais eficiência. O marketing consulta a equipe técnica, perguntando como eles criariam o novo sistema e quais limitações ele teria. Descrevemos a arquitetura de como será implementada no nível federal e percebemos que nosso sistema se tornará um complemento para gerenciar a marca, campanhas de marketing e outras ferramentas para promover e se comunicar com os usuários. Não será duplicado, mas integrado.
Ou aqui está um exemplo do que fazer se precisarmos conectar muitos pequenos parceiros ao sistema. Os negócios conheciam a todos de vista e entendiam como eles pensam. O desenvolvedor não conhecia ninguém, não conhecia as restrições do mercado, então calculou o modelo e propôs uma solução racional fria. Em uma tentativa de justificar por que não era possível, os negócios perceberam que, de fato, a restrição de mercado é bastante ilusória. E aqui temos outra inovação, mas não mais em desenvolvimento. A equipe para trabalhar com parceiros mudou o foco para outros parceiros, o que nos deu muito mais dados para o sistema.
O exemplo a seguir. O desenvolvedor fala na conferência, fala sobre a solução técnica. Ele falou sobre seu próprio sistema para reservar voos - a conta pessoal da transportadora. Ele recebe uma pergunta totalmente personalizada da platéia no nível do "que acontecerá se eu sentar na próxima parada". Em 98% dos casos, o desenvolvedor responderia em termos de integração e troca de dados. Aqui ele falou sobre como o negócio funciona, que tipo de relacionamento entre a transportadora e a estação. E discutiu todos os detalhes.
Ok, como informar alguma coisa?
Quando a empresa tinha cinco proprietários de produtos, reuníamos e trocávamos uma vez por semana sobre o que era útil no produto e o que poderia ser diferente. Então nos tornamos oito. Então - 13 pessoas. E 13 pessoas já são mais difíceis de montar. Eles sugeriram a troca dos resultados da análise em cartas. Eles começaram a falar sobre o que haviam sido úteis no produto e a dar recomendações sobre como aplicá-lo em outros produtos. Foi uma vez por mês e meio, então - uma vez por mês.
Assim, uma regra de tradição com relatórios mensais foi formada. De acordo com os resultados do trabalho da equipe, uma carta robusta é enviada em um mês (a última vez em ônibus foi de 27 páginas A4). Você pode ler apenas o topo, mas pode fazer tudo em uma linha ou em pedaços. Ajuda a obter feedback, novas idéias.
O relatório é duplicado pelo desempenho de uma reunião: não é necessário comparecer, mas geralmente pessoas de equipes vizinhas vêm. O importante na reunião é curto, você pode fazer perguntas rapidamente. Em seguida, leia a carta e entenda os detalhes, se desejar. Em uma dessas reuniões, um funcionário da ferrovia contou como o usuário partiu para Sverdlovsk (Ucrânia), em vez de Ecaterimburgo (Rússia, antigo Sverdlovsk na região de Sverdlovsk). Também existem colisões em ônibus. Juntos, eles pensaram em uma análise probabilística (aonde você provavelmente deveria ir) e um sistema de alerta sobre rotas atípicas. Alterou a ordem das dicas para as primeiras letras das cidades, para que as direções improváveis fossem classificadas mais tarde que as mais importantes.
Eu coletei o resumo sobre a abordagem alimentar. Ou seja, ele primeiro enviou o que achava ser dos valores dos usuários finais (desenvolvedores de equipes, proprietários de projetos, empresários se comunicando com parceiros) e depois começou a coletar feedback. Em algum lugar, alguém começou a fazer perguntas que não existiam antes. Em algum lugar eles pediram mais detalhes. Então enviei uma pesquisa para todos sobre o que é útil e o que não é.
Como resultado, a seguinte estrutura apareceu:- As principais tarefas que estavam no produto: para quê, por que, por que, como. É muito importante observar que cada tarefa afeta de alguma forma o mercado. Grupos de recursos se reúnem em pontos estratégicos como "faça um pedido o mais rápido" ou "tenha a programação mais precisa",
- Depois, retiramos os resultados dos estudos analíticos. Assim, por exemplo, graças à nossa pesquisa, aprendemos que muitas vezes uma viagem de ônibus é apenas o primeiro passo de uma jornada e, em seguida, uma pessoa viaja de trem. Ou do trem muda para o ônibus (se estiver viajando para o interior). E isso é muito importante, porque em uma primeira aproximação isso afeta o marketing e na segunda - em geral em todas as interfaces. Porque a tarefa já não é comprar uma passagem de ônibus, mas acoplá-la com um trem para chegar a algum lugar conveniente. O próximo analista - comparou a rede de rotas de trens, trens, ônibus para duplicação ou expansão. Para que, na página de horários do trem Moscou-Dmitrov e além, os ônibus em todo o distrito de Dmitrovsky estivessem no widget. Agora - em implementação.
- Pode haver notícias do mercado. Tudo é banal: apenas para que todos saibam o que esperar e o que foi feito em grande escala.
- Pesquisas - perguntas se alguém precisa ser atraído. Coletamos informações sobre quem dirige e quais problemas eles encontraram. Eles perguntaram à equipe como seria mais conveniente implementar um ticket eletrônico. De acordo com a variedade de ônibus - quem dirigia onde, como estava, como tudo está enferrujado. Às vezes, pedimos que você tire fotos de horários nas paradas em determinadas direções.
De acordo com os resultados do primeiro resumo, eles começaram um estudo sobre se as passagens de trem são mais baratas ou mais caras que as passagens de ônibus para os mesmos segmentos. E eles chegaram a muitos resultados não muito óbvios. Talvez eu escreva sobre isso um pouco mais tarde.
Muitos de nossos estudos são úteis para os colegas. E nós pegamos alguma coisa. Seguindo o exemplo de outro produto - tours - feito por usuários do CJM. Estamos acostumados a pensar que a abordagem para comprar um ingresso é do tipo funil linear. De fato, as pessoas vagam entre as páginas, abrem dezenas de guias, pressionam com confiança "voltar" no navegador de diferentes formas e geralmente navegam simultaneamente a partir de dispositivos diferentes (eles transferem de um telefone celular para um desktop quando você precisa comprar). O rastreamento de todas essas estranhas trajetórias tornou possível decidir que algumas etapas extras, em algum lugar as pessoas estão fechadas. Um problema típico da Rússia: ao escolher um ônibus, muitos não conseguiram derrotar a interface de seleção de assentos. Deixe-me lembrá-lo, estamos falando sobre as pessoas que vivem em aldeias e não sabem as diferenças entre a consulta de pesquisa e o endereço do site. São apenas aqueles que não sabem usar o pergaminho na balança do supermercado, se houver. Em geral, nasceu uma hipótese: você precisa escolher um local automaticamente e, em seguida, precisa concordá-lo ou alterá-lo. E eis que eis! - moradores de vilarejos russos distantes, migrantes que trabalham e várias categorias de usuários deixaram de ser confundidos na interface.
Um call center chegou a uma das reuniões para dizer que estava pasmo com perguntas estúpidas na primeira linha e, há um mês - as mesmas. Uma enorme camada de perguntas foi removida assinando dicas para os campos, adicionando mais detalhes à carta após a compra de um ingresso e assim por diante. Da coisa mais estranha: no cartão de ônibus, o link para a rota estava em um dado iluminado em azul, mas as pessoas não cutucavam lá, mas telefonavam. Ou seja, alguém não entendeu simplesmente que este é um link.
Outra descoberta interessante - ouvimos colegas do ar em uma reunião e descobrimos como os preços das passagens aéreas funcionam. E então eles ofereceram nossas transportadoras para carregar ônibus. Quando o voo sai com uma cobertura de 40% ou menos, descontamos o preço por um curto período de tempo, para que possamos pegar menos trens na mesma direção. 1 300 bilhetes custam, 400 rublos se tornam: não é lucrativo para uma transportadora de 400 colocar um ônibus inteiro, mas levar 10 pessoas por 400 e melhorá-las é melhor do que não levar mais ninguém.
Como é formado o relatório?
Tarefas e seu progresso. Exemplos:
Novas regras de decisão para o CC
- O que você decidiu? Em alguns casos, especialistas em contact center devem tomar decisões independentemente em favor do cliente, sem aguardar a análise da situação com o parceiro (rodoviária, transportadora), o que pode levar semanas ou a análise do suporte. Portanto, eles avaliaram onde o limiar de perdas está localizado, abaixo do qual os especialistas do CC podem tomar decisões instantaneamente.
- O resultado e o que faremos a seguir? O preço é determinado, continuaremos trabalhando em outros cenários. Nesse caso, todos os dados são coletados e controlaremos essa métrica (perda de ticket). Os especialistas da KC começam a resolver independentemente alguns casos dos clientes.
- Como isso pode ser útil em outros produtos? Às vezes, é mais eficaz e afeta melhor a marca se você ajudar imediatamente o cliente do que mergulhar em processos profundos. Avalie, talvez aqui você também tenha algo para trabalhar.
Sobre questões vazias, todos os CTIS (ferroviário, aéreo, ferroviário)
- O que você decidiu? Em questões vazias, quando não podemos oferecer ônibus ao cliente, eles começaram a mostrar todos os CTISs, devolveram o trem. Era importante ver como isso afeta o comportamento, se a alternativa é interessante e se vale a pena desenvolver mais.
- O resultado e o que faremos a seguir? Em 36% dos casos, foi oferecida ao cliente uma alternativa. Supõe-se que os clientes ainda estejam procurando ônibus reais (para onde realmente vão), portanto, na verdade, há uma grande quantidade de clientes insatisfeitos. Esse é o potencial para ônibus e PTTs, onde estamos expandindo nossa linha de produtos. Há interesse nisso, eles estão observando, mas não planejamos desenvolver ativamente questões vazias, mas pensaremos ainda mais em como integrá-las corretamente à questão atual.
- Como isso pode ser útil em outros produtos? Para o nosso grande país, um ônibus pode ser uma parte indispensável de uma viagem a algum lugar. Portanto, a combinação de modos de transporte (multimodalidade) pode fazer sentido estrategicamente se você acostumar os clientes a pensar em termos de categorias de A a B.
Pesquisa e hipótese, exemplo:
O que faz as pessoas voltarem?
- O que você decidiu? Descreva os usuários que retornaram para nós e como eles diferem em seu comportamento daqueles que não retornaram.
- Resultados e o que faremos a seguir? Compilamos um conjunto de características comportamentais que descrevem o usuário e que podem afetar sua retornabilidade. É importante que este não seja um modelo preditivo, mas descritivo. Além disso, conduziremos experimentos, imporemos as características e assistiremos ao retorno. Por fim, queremos criar um modelo preditivo para entender como envolver os usuários no produto, o que envolver para aumentar a probabilidade de retorno. Óbvio, mas verdadeiro: as pessoas que já compraram em outras seções provavelmente retornarão para re-compras em ônibus.
- Como isso pode ser útil em outros produtos? Se você estiver interessado em cavar nessa direção, faça uma análise semelhante e compare as interseções.
Então - as respostas para a pergunta: "O que está acontecendo?", Um exemplo da agenda:
- Por que comprar menos? Sim, está tudo bem, apenas uma temporada que não sabíamos.
- Tráfego direto. Por que um aumento tão acentuado? Você prometeu corretamente? E você não analisa? E também responde a várias perguntas (spoiler: sim, somos analisados).
- Plataforma. Estamos engajando usuários. Os primeiros resultados do envolvimento real de pessoas no gerenciamento de conteúdo no site. As pessoas estão ajudando ativamente.
- Compras entre plataformas. Um ingresso eletrônico ao parar pessoas em um PC sem impressora. O que vem a seguir? 83% daqueles que fizeram sua primeira compra em um PC continuam comprando em um PC.
- Análise de coorte. Os gráficos não são para os fracos de coração.
- Como é a venda no ar. Entendemos muito sobre a passagem de bagagem e não apenas ... (431 pedidos em ônibus por usuários que fizeram um pedido no avião durante o mesmo período, 42% deles - um ônibus para complementar a aeronave (ou seja, o ônibus é para o ponto de partida ou para ponto de chegada), 12% - na direção oposta.)
Experimentos desumanos (isso é interessante para todas as equipes), um exemplo:O que afeta a demanda por um voo?
- Classificação da operadora. A diferença de um ponto na classificação, de acordo com o feedback de nossos usuários (por exemplo, 9,4 versus 8,4), aumenta a probabilidade de comprar um voo em 23%. Este pode ser um argumento realmente significativo para as transportadoras, a fim de aumentar o nível de serviço dos passageiros.
- A probabilidade de comprar um voo promocional (marcado com Tutu.ru Emblemas da oferta com um preço cruzado) aumenta em XX%.
- A adição da primeira oferta promocional em XX% aumenta, ceteris paribus, a probabilidade de conversão a partir da emissão. E isso significa que você precisa expandir o intervalo de direções com os estoques.
- Se no teste A / B em cada voo de emissão, o número de assentos disponíveis for reduzido em um, a probabilidade de conversão da emissão aumentará em média X%.
- Se você jogar fora (ocultar) um voo em emissões com mais de 10 vôos, a probabilidade de compra aumentará 0,6%.
Devo dizer imediatamente que não planejamos substituir dados nos resultados de acordo com os métodos 3 e 4, mas examinaremos os fatores reais de escolha. Os testes A / B dizem respeito a cerca de 1% do público-alvo do site e são estritamente limitados no tempo. Todos os experimentos são éticos, no sentido de permitir que uma pessoa resolva um problema e não ocultar dados importantes dele, e o benefício deles às vezes deve superar os possíveis inconvenientes.
Feedback do mercado, exemplos:- Trabalhamos com a validação dos dados de programação de entrada. Agora o inimigo não passará (ou seja, a transportadora não poderá inserir inadvertidamente os dados de uma rota irreal).
- Eles deram às transportadoras a oportunidade de editar seus horários e voos. Os caras estão felizes e temos menos trabalho :)
Em seguida - descarregando de Jira (de fato) em linguagem simples para quem gosta de detalhes. Quaisquer adições e notas. Só isso.
Sumário
- Os negócios começaram a entender o potencial do produto, o que possibilitou substanciar muito claramente os orçamentos de soluções técnicas.
- Os desenvolvedores começaram a dar novas idéias e a ver como termina a implementação dos recursos e como isso muda o mundo.
- A equipe próxima foi capaz de transmitir aos desenvolvedores a importância de alguns problemas, e eles foram rapidamente resolvidos.
- Outras equipes recebem nossa experiência e compartilham sua experiência e o código que reutilizamos.
- Os usuários estão satisfeitos (exceto pelo 1% do tráfego que as experiências desumanas dizem respeito).
Por isso, digo a todos sobre o que está acontecendo dentro do produto. Separadamente, surge a questão dos segredos comerciais: o relatório é muito fácil de encaminhar ou remexer, mas confiamos em nosso pessoal. Da mesma forma, os dados fluem entre diferentes players do mercado e, se você realmente precisa ocultar algo completamente, o relatório cria links para recursos internos, que já possuem uma camada adicional de autenticação.