Evidenciar que o usuário já tem acesso ao plano

[laura-l-amaral]

Expectativas

• Que no fim de 2 semanas o usuário tenha elementos o suficiente para saber que já tem acesso ao plano
• Que as featuras passem por testes de qualidade
• Que a gente bloqueie outras atividades que cheguem, o objetivo é que vcs poderem focar 100% nessa atividade, se alguem pedir alguma coisa, pode falar comigo antes, a não ser que seja um bug que vai derrubar o site ou que esteja cobrando clientes indevidamente não é pra entrar até o final das 2 semanas
• Que a gente tenha claro que esse é um exercício para a capacidade de cortar(serrar/hammering) atividades para conseguir fazer lançamentos em tempos fechados ao inves de ir estendendo uma atividade por muito tempo
• Que a gente consiga ao final levantar pontos do que é necessário para que essa dinâmica funcione melhor

Obs: Dentro desse framework a proposta é que a gestão não participe do trabalho com dailys, mas no final dessa conversa quero saber se vcs preferem essa liberdade ou se preferem que eu acompanhe para apoiar no procesos de direcionamento e vamos escrever aqui também

O que acontece se não der certo

• Vamos pausar essa atividade, voltamos para as atividades de backlog e Dahis, eu e Nay vamos avaliar se colcamos mais 1 ou 2 semanas para esse pitch

Elementos do pitch

• Mudar o entorno do nome do usuário para que ele visualize que está com o usuário BD Pro/Empresas
• Quando a pessoa assina, não aparecer mais mensagens/condições de “para assinantes”.
  • Trocar a cor da cobertura temporal para que ela apareça toda de uma única cor (sem separar pago de não pago por cor)
  • Na página de preços, exibir “bases de baixa frequência atualizadas” dentro do “plano grátis”.
  • Não exibir o filtro de conjuntos “com recursos grátis vs pagos”
• Área de usuário ter a espera de resposta do backend para não aparecer “BD Grátis” após a pessoa assinar, antes de um refresh de página.
• Antes de finalizar a compra incluir mensagem que avisa que o acesso aos dados será liberado para o email: [email protected]
• Ao final do processo já incluir mensagem que o acesso ao email [email protected] foi liberado no BQ e pacotes
• Permitir que o usuário possa trocar o e-mail de acesso a GCP via área de usuário

OBS: Sobre esse último elemento, nay e jhony, vamos sentar pra conversar antes sobre qual caminho seguir para atingí-lo, se não conseguirmos hoje, podemos fazer amanha e começamos o ciclo de 2 semanas na quarta

Como vai ser o acompanhamento

• Esse board
• Uma issue para cada escopo
• Uma lista de afazeres para cada escopo
• Movimentar os cards de escopo pelo board de shape up
  

Passos

• Mapear escopos
  • partes que indicam uma grande tarefa, quase independentes
  • permitem a gente atingir pequenas vitórias no caminho e integrar posteriormente
  • não separadas por área ou pessoa responsável
• Começar com aquilo que ajudar a reduzir as incertezas:
  • o que for central pro projeto
  • algo que seja possível de completar e testar, para que possamos avançar e criar "momentum"
  • o que for mais novidade pro time, coisas novas tem mais incertezas
• Como saber onde cortar:
  • sempre marcar o que não for essencial com um ~ na frente
  • comparar sempre com o que o usuário tem agora e não com o que ele poderia ter
    
  • perguntas que podem ajudar:
    • Isso é um "must-have" (essencial) para o novo recurso?
    • Podemos lançar sem isso?
    • O que acontece se não fizermos isso?
    • Este é um problema novo ou um problema pré-existente com o qual os clientes já convivem?
    • Qual é a probabilidade desse caso ou condição ocorrer?
    • Quando esse caso ocorre, quais clientes o veem? É algo central — usado por todos — ou mais um caso extremo?
    • Qual é o impacto real desse caso ou condição, se ele ocorrer?
    • Quando algo não funciona bem para um determinado caso de uso, quão alinhado está esse caso de uso com o nosso público-alvo pretendido?

[rdahis]

Comentário: é ótimo ter esse resumo do pitch aqui no GitHub, mas no futuro eu botaria como um "milestone". Me parece ser o mais apropriado. Tem recursos de markdown também.

[laura-l-amaral]

Comentário: é ótimo ter esse resumo do pitch aqui no GitHub, mas no futuro eu botaria como um "milestone". Me parece ser o mais apropriado. Tem recursos de markdown também.

@rdahis aaa boa! não tinha pensado nessa alternativa!