Indicadores

Objetivo de indicadores

  • Auxiliar na tomada de decisão
  • Leitura rápida, fácil

Tipos de Dash

  • Tempo real – algo que mostre se o sistema está funcionando plenamente.
  • Green, good. Red, bad. – Fácil de ver onde tem problema
  • Dash zero – Meta é ter tudo zero, bom para identificar erros no sistema. Ex: usuários sem data de criação. Deveria ser zero, pois é básico ter a data de criação.

Indicadores

  • SaaS: Lifetime, LifetimeValue, CAC, Churn
  • Pessoas: PNPS, Turnover Voluntário (crítico), turnover involuntário, qtd pessoas sem promoção nos últimos X meses
  • Cliente: NPS, Contact Rate, Engajamento
  • Financeiro: Grown Rate, Posição Caixa, LucroLiquido
  • TI: Bugs, Disponibilidade, Incidentes, Deploys, Cobertura de teste, Total Testes
  • Suporte: Tempo 1a Resposta, Tickets não atribuidos, Tickets sem resposta, Tempo de Resolução do ticket, Média de interações por ticket, Tickets por cliente

Referências

Disseminação Conhecimento

Talks

  • Algum board (quadro, trello… qualquer coisa) onde as pessoas colocam temas de interesse
    • Caneta para a galera votar
  • Calendário com as datas disponíveis
    • Quem quiser falar dos temas com mais votos, coloca nome com tema palestra

Changelog

  • Com uma regularidade (semanal, quinzenal ou máximo mensal) comunicar as subidas mais relevantes dos times.
  • Sugestão é usar um grupo de email da empresa para enviar as novidades, ou se a empresa for muito grande, usar um “mailchimp” que permite vc criar uma lista e as pessoas se inscreverem para receber as novidades.

TGIF – All Hands [1]

  • Inspirado no google/facebook, semanalmente param a empresa para comunicar novidades e abrir para perguntas/respostas.
  • Aberto, honesto e transparente.
  • O que comunicar
    • Direção da empresa
    • Atg da meta (OKR)
    • Mudanças no organograma
    • Conquistas relevantes
    • Outros Fatos relevantes
    • De espaço para times compartilharem novidades
  • Momento de perguntas
    • Abrir com 1 dia de antecedência formulário com perguntas anônimas
    • Ler todas as perguntas
    • Ser o mais transparente/franco possível!
    • E se prepare…! =)

[1] http://futureofwork.nobl.io/future-of-work/how-googles-tgif-meetings-empower-employees

Protótipo

http://www.gv.com/sprint/

Faça protótipos! Ajuda no entendimento, validação e especificação.

Protótipos

  • É muito mais fácil, rápido e barato
  • O que não tem no protótipo
    • Lógica de negócio
    • Release requirements
    • Plataform delivery requirements
    • Instalation requirements
    • Browser suportado
  • Uma vez com o protótipo, ter um time de pesquisa com o cliente ajuda muito a validar as hipóteses antes de desenvolver.

Sempre busco manter o time de design/experiência 1 ou 2 passos a frente do time de desenvolvimento.

Priorização

Decisões de Negócio

Decisões técnicas

  • CAP Theorem – Consistency, Availability, Partition Tolerance

Como Priorizar?

  • Que problema quer resolver? (value proposition)
  • Para quem resolvemos o problema? (target Market)
  • Quão grande é a oportunidade? (Market size)
  • Como mediremos o sucesso? (metrics/revenue strategy)
  • Quais alternativas existem agora? (competitive landscape)
  • Por que somos os melhores ao fazer isso? (our differentiator)
  • Por que agora? (Market window)
  • Como levaremos este produto para o mercado? (go-to-Market strategy)
  • Quais os fatores são críticos para o sucesso? (solution requirements)
  • Impacto vs Esforço (matriz 2×2) – https://medium.com/@itamargilad/why-impact-effort-prioritization-doesnt-work-57d141fafc2c
  • Dado as perguntas acima, qual recomendação? (go or no-go)

Referências

Qualidade

21-triangulo-das-restricoes-2.png

Práticas pra melhorar Qualidade

  • bug bash – separar um tempo para todo o time usar o produto e encontrar bugs/melhorias.
  • retrospectiva
  • debrief após incidente
  • Quality Assurance ou Assistance?

Manifesto do teste ágil

Manifesto do Teste Ágil

manifesto-do-teste.jpg

Manifesto de Qualidade

  • atender expectativa MAIS QUE tudo
  • qa como disciplina MAIS QUE time de QA
  • automação MAIS QUE manual
  • experiência do cliente MAIS QUE esplanar responsabilidade
  • propósito/aceitação MAIS QUE especificar detalhadamente
  • causa raiz MAIS QUE conformidade com soluções temporárias
  • integração entre time, responsabilidade distribuída e aceitar erro como forma de aprendizado MAIS QUE apontar culpa

Qualidade (Kaizen)

  • bons processos levam a bons resultados;
  • observar os dados para gerenciar fatos;
  • para entender a situação atual é preciso olhar para si mesmo;
  • tomar medidas para conter e para corrigir a causa dos problemas em suas raízes; (5W)
  • trabalhar em equipe;
  • retrospectiva

Monitoramento

  • Evitar subir algo errado pode dar muito trabalho. Por isso é importante se cercar de indicadores

Pq Errou?

  • negligência?
  • arriscou algo novo?
  • ignorou o problema?
  • não pensou a respeito?
  • não estava nem ai?

Como melhorar

  • planning, communication methods
  • task estimation
  • code testing
  • code reviews
  • pairing up
  • technical debt
  • test coverage
  • code quality
  • branching

Referências