Hackaton

Hackaton ajuda a moldar o comportamento da TI!

Pilares do hackaton

  1. A pressão do prazo alimenta a inovação
  2. Auto-Organização é escalável
  3. Confiança e empatia criam velocidade
  4. Arrisquem tudo!
  5. Código vence argumentos

Como funciona?

  1. Abre um board Trello para que todos possam colocar suas idéias. Eu disse todos…. qualquer um da empresa pode dar idéia! =) Importante também descrever a idéia!
  2. Um dia antes do hackaton, todos se encontram para apresentar suas idéias
  3. Participantes dão join nas idéias que curtiram.
  4. Hackaton deve durar de 24 a 48hr, escolher o modelo.
  5. Sem PPT! Só pode mostrar o sistema no dia, nada de PPT. Este deve ser desqualificado na hora.
  6. Apresentar os projetos e público vota nos vencedores
  7. Importante liberar comida e ambiente propício para virar a noite. =)

Regras

  • Uma pessoa não pode participar em mais de um time;
  • Times devem ser formados com >= 2 && <= 5 pessoas;
  • Não necessariamente você precisa se associar a um projeto sugerido por você. Se interessou por algum projeto e quer trabalhar nele, basta se associar ao projeto, respeitando o limite máximo de pessoas permitidas;
  • Caso > 5 pessoas, as últimas cadastradas não farão parte do projeto 😦
  • Código só pode ser escrito durante o hackaton

Critérios de Avaliação

  • Viabilidade: O projeto tem uma chance de ser continuado pela empresa? A idéia é escalável e aplicável ao nosso contexto? É realista a chance de desenvolver o projeto?
  • Originalidade: Seu projeto é criativo, novo e inovador? É algo que nós já conhecemos, ou é uma idéia disruptiva?
  • Impacto para empresa: A idéia tem potencial de criar novos negócios? O projeto tem chance de reduzir custos e evitar desperdícios? A idéia resolve um problema real que vivemos no nosso dia-a-dia?

PesquisaScreen Shot 2018-05-02 at 14.49.41.png

[3]

Referências

  1. https://www.fastcompany.com/3002845/secrets-facebooks-legendary-hackathons-revealed
  2. http://vidadestartup.org/como-realizar-hackathons-em-sua-empresa-pode-mudar-completamente-o-ambiente-de-trabalho/
  3. https://insights.stackoverflow.com/survey/2018

Inovação

Desafios

  • Mexer no produto que é vaca leiteira
  • Risco alto por errar
  • Time não consegue sair da operação

Como resolver

  • Crie ambiente seguro para ter e validar a idéia
    • hackaton
    • 20% rule
    • incubadora – após lançar o produto, dispersar o time
  • Uma vez validada a ideia
    • Inicie um time independente
    • Funding separado
    • Reportando temporariamente para o CEO (pelo menos no começo)

Referências

 

Planejamento Estratégico

Estratégia é sobre saber o que não fazer

Base

  • Sonho grande
  • Propósito
  • Valores

Estruturar

Sugestão metas

  • Crescimento Faturamento
  • Lucro (meta vermelha)
  • Satisfação Cliente
  • Satisfação Pessoas
  • Engajamento do Produto

Crescimento deve ser top-down, o restante bottom-up, com ajustes pra bater faturamento.

 

[1] amazon-4-638

Agile / SCRUM

Manifesto Ágil

0.jpeg

[2]

Fluxo

  • Release planning (previsibilidade)
  • Gestão Backlog (planejamento)
  • Planning (alinhamento)
  • Daily (comunicação)
  • Review (responsabilidade)
  • Retrospectiva (melhoria contínua)

Release Planning / Roadmapping

Gestão do Backlog

  • Responsabilidade do Gerente de Produto, especificar e manter sempre priorizado
  • Time faz backlog grooming
    • Todo planning, time entende um pouco das estórias seguintes, estima, tira dúvidas e etc

Planning

  • Pega as hipóteses que estão priorizadas no backlog
  • Quebra em atividades menores (ideal 1 ticket/postit por dia por pessoa)
  • Tira dúvidas com Gerente de Produto/stakeholders
  • Estima tudo

Especificação / Requisitos

  • Deve focar na experiência completa, não apenas nos requisitos
  • Representa o comportamento da aplicação
  • Deve ser legível por: QA, DEV, MKT, SAC, Operação
  • Especificação muda logo após começar!
  • É importante ter requisitos priorizados, wireframes e mocks

Sprint

  • Separe uma parte para refatorações. Qualidade de código é lei.
  • Composição do sprint
    • Bugs reportados pelo cliente
    • Features
    • Bugs internos
    • Refactors
    • Performance (reportado por ferramenta como new relic)
    • Erros de log (tipo sentry)
    • Discoverys
    • Melhorias
    • Otimizações

Daily

  • Todos de pé, em frente ao quadro, mesmo horário, todo dia
  • Cada um fala: o que fez, o que está fazendo e impedimentos
  • Passar pelos pontos “a melhorar”, que veio da retrospectiva
  • Cabe ao SM/PO remover impedimentos toda reunião

Review?

  • Se fizer deploy grande
    • Hora de apresentar tudo em homologação
    • Sempre um dev apresenta (importante alternar, pois ninguém quer apresentar algo com bug. Dessa forma todos ficam com “skin in the game”)
    • PO pode abortar uma tarefa e pedir pra não subir se julgar não estar bom o suficiente (importante levar este ponto pra retrospectiva pra aprender pq desenvolveu e não subiu, onde erramos?)
  • Se for microdeploy (minha preferência)
    • A medida que o sprint anda, no daily o dev ja informa ter acabado
    • PO/QA valida a micro tarefa e libera
    • No final do sprint, está tudo em produção

Retrospectiva

Definição: “Uma reunião especial que o time se reune após completar um incremento do trabalho para inspecionar e adaptar seus métodos e forma de trabalhar” Daiana Larsen & Esther Derby

  • Time avalia como foi o sprint. Etapa crucial para melhorar sempre.
  • Quebrar em: continuar, começar, melhorar e parar
  • Ao final, todos votam nos top 3 postits (cada um tem 3 pontos pra votar)
  • Pegam-se os mais votados, atribuem-se donos (Importante ter as pessoas fazendo parte da solução e não só do problema) e coloca no quadro do time. A idéia é acompanhar diariamente os pontos a se melhorar.
  • Deve-se colocar as pessoas certas na reunião. Stakeholders ou envolvidos no sprint
    • No entanto, a lavação de roupa suja é somente com o time. Ou seja, primeiro os stakeholders passam a visão deles do que melhorar, depois o time segue. [1]
  • O que não deve acontecer
    • esta tudo ótimo e não temos nada pra melhorar
    • debater backlog
    • não ter hora pra acabar
  • https://labs.spotify.com/2017/12/15/spotify-retro-kit/
  • https://www.infoq.com/br/presentations/o-invisivel-das-retrospectivas-ageis

Design Sprint

 

[1] http://www.romanpichler.com/blog/sprint-review-tips-for-product-owners/?doing_wp_cron=1511890677.9049379825592041015625

[2] https://www.linkedin.com/pulse/5-organisational-agility-messages-land-1-hour-executive-chris-webb/

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

Time

Definição: Time é um conjunto de pessoas unidas com um mesmo objetivo e que depende um do outro para alcançar o objetivo através da colaboração.

Times devem ter missão

  • Short and memorable
  • Formula: We [reduce pain/improve life] in [market] by [value proposition]. Then refine it
  • Busque missões que durem uns 5 anos (ou pode ser o Objective do OKR, mas de médio prazo)
  • Exemplos:
    • Zynga: Connecting the world through games
    • Coffee Philz: Better people’s day

Combinados

  • Definition of ready – quando uma estória/ticket está pronto pra entrar no sprint? o que a deixa aceitável?
  • Definition of done – o que significa pronto? pronto na máquina? validado? em produção?

Team Building

https://www.huddle.com/blog/team-building-activities/

https://www.wrike.com/blog/ultimate-guide-team-building-activities/

http://www.ventureteambuilding.co.uk/team-building-activities/

https://www.thebalance.com/team-building-workplace-activities-1919238

http://vorkspace.com/blog/index.php/13-top-team-building-activities/

Referências

https://productcoalition.com/why-teams-matter-b893e5c223c1

http://livingbusiness.coloniallife.com/blog/why-empowering-employees-is-the-best-move-your-company-can-make

https://www.forbes.com/sites/drewhendricks/2014/01/27/6-ways-to-empower-your-employees-with-transformational-leadership/#2a968e9a1ada

Avaliação

Avaliação Geral

  • Comportamento – Alinhado com valores
  • Entrega

Avaliação da Entrega

  • Impacto Gerado – Ex: reduziu tempo de resposta da API de 200 para 100ms
  • Impacto Gerado usando serviço de terceiros – Ex: aumentou em 5% conversão usando API pronta (de dentro ou fora da empresa)
  • Impacto Gerado por terceiros usando seus serviços – Ex: time X aumentou em 5% conversão usando API do meu time
  • Ativos – Ex: Wireframe, código, documentação
  • Comportamentos – Ex: organizado, palestrante, líder
  • Conquistas – Ex: Contratou 5 pessoas

Frequência

  • Avaliação é feita realtime ou 1on1 semanal (máximo quinzenal)
  • Trimestralmente tem um mais formal, com calibração (A, B e C, by Jack Welch ou 1 a 5, by Google)

Geral

  • Não existe meritocracia sem transparência
  • Peer pressure é fundamental
  • Não se recompensa esforço e sim resultado

Aumento, Bonus, PL

  • Metas da empresa – Sempre quantitativas – Resultado é bonus em multiplo salário ou algo similar. Comportamento não entra aqui. Resultado gera dinheiro/salario.
  • Feedbacks sempre voltados pra comportamento – Bons profissionais crescem salário, responsabilidade, projetos. Alinhamento com os valores determina carreira.
  • Exceção é tratada como exceção. Se a pessoa foi espetacular, entregou baita resultado, tem um ótimo feedback… vai virar sócio, receber PLR agressivo e etc.

Gestão do Tempo

Organize-se!

  • Calendario – é perfeito para registrar reuniões, compromissos com data/hora marcada!
  • Todoist – coloque teus to-dos, suas atividades, não esqueça de fazer/entregar nada
  • Evernote/Notes – registre tudo que precisa ficar guardado lá. É como uma documentação para você
  • Wiki – O que tiver que ser documentado e público, deve ficar na wiki

Canais de Comunicação

  • Email – Registro de conversas, dúvidas adhoc. Após 5 trocas de e-mail, se não resolveu o assunto, recorra a chat, ligação ou pessoalmente.
  • Chat – Dúvidas, troca de idéias, adhoc.
  • Pessoalmente – Mellhor para feedbacks ou assuntos complicados.
  • Ligação – Para assuntos urgentes (afinal, vc vai interromper a pessoa) e perfeito para resolver quando por chat/email ficaram confusos.
  • Dicas Básicas
    • Mande emails/reporte com titulo descritivo. nada de “bug, erro, dev…! erro cliente”. Experimente algo tipo “Cliente X – Problema Y”
    • Evite emails longos

Reuniões

  • Vá para reunião com TEMPO definido e PROPÓSITO. Qual o entregável da reunião?
  • Evite reuniões com muitas pessoas (máximo 6 é o ideal)
  • Proíba celulares
  • Ideal são reuniões de 40m
  • Reunião não é feita para trabalhar e sim para propor/validar/decidir
  • No final, defina próximos passos, o responsável por cada atividade e prazo de conclusão.

Etapas para organização, priorização e execução

  1. Mapeie: grande lista de atividades! quanto mais coisa, melhor! \o/
  2. Agrupe: agrupe as atividades por temas. Cada tema pode ter tarefas e cada tarefa, sub-tarefas. Potanto: tema > tarefa > sub-tarefa.
  3. Classifique: cada atividade como importante/urgente. Pode usar coisas extras como esforço, impacto, dependência… classificações que auxiliem tomada de decisão.
  4. Estime: qual o esforço de cada atividade? Sugestão estimar com fibonacci, 1,2,3,5,8,13,20,40.
  5. Priorize: primeiro dentro de um tema, depois no geral. Analise comparativamente os itens que devem ser feito. Mais importante em cima, menos importante embaixo.
  6. Escolha: o que será feito em 1 semana?
  7. Planeje: agora que tenho MUITA atividade PRIORIZADA, tenho atividade para 1, 2, 3 meses de trabalho que tenho CERTEZA que precisamos neste periodo? Release Planning!
  8. Faça: esta é sem dúvida a etapa mais importante, faça, faça, faça. Não adianta planejar tudo lindo se não fizer.

Dicas

  • Quinzenalmente faça retrospectiva. Continuar, Melhorar, Começar e Parar
  • Está no meio da semana e chegou um pedido urgente. Diga não, fale que está com a semana cheia e que fará semana que vem. (claro, bom senso sempre manda).
    • Neste momento, se a atividade for REALMENTE importante, jogue ela para o topo do backlog (atividades a fazer). Se não for, coloca la embaixo. (não perca tempo vendo exatamente em que ordem deve entrar pois vc será mt interrompido).
  • Comece uma atividade e acabe ela. Não adianta ficar fazendo 10 atividades e não terminar nenhuma. Faça uma por vez, faça bem feito.
  • Quem estima o tempo é o executor, não o gestor.
  • Faça um release planning trimestralmente, ou seja, um plaanejamento do trimestre envolvendo stakeholders e o time.
  • Aprenda a dizer NÃO, quando pedem algo pra ontem. Se vc tem sua lista organizada, fica mais fácil dizer não. 😉
  • Lendo rapidamente: http://fourhourworkweek.com/2015/06/09/speed-reading/

Produtividade

  • Shallow work – is everything about email, endless meetings, conversations without goals;
    • Shallow work prevents you from being fired but deep work is what gets you promoted
  • Deep work – is everything about planinning the next step, managing your people, assuring customer satisfaction
    • Desligue todas as interferências, não cheque email, não olhe o celular; idealmente tenha um ritual que diga para o seu cérebro que é hora de focar. Esse ritual pode ser pegar um café, colocar determinada música, sentar em outra mesa etc.
  • Se auto-conheça – veja em quais horários vc é mais produtivo/criativo e bloqueie a agenda nesses horários para focar em depp work; nos horários mais morosos faça shallow work
  • Sua última atividade do dia – tem que ser priorizar as atividades do dia seguinte; chegar em casa sem precisar se preocupar com o dia seguinte te ajuda a relaxar, evita ansiedade e permite que vc se desconecte
  • Agende “batches” no seu dia para checar o email e não fique olhando ele o tempo todo; quando for olhar tenha em mente quatro ações: do it now, delegate it (e agendar o follow up), defer it (colocar na todo list) or drop it
  • Saia de todos os grupos de email que vc não precisa receber e olhar todos os emails; alinhe com a equipe para te copiar sempre que acharem necessário a sua participação no assunto, assim vc foca só no que realmente importa e dá autonomia para a equipe
  • Não confie na sua memória, isso só faz vc se sentir mais ansioso por achar que está esquecendo algo; anote tudo, organize uma todo list e tenha disciplina na execução dela

Gestão do Email

  1. Use os grupos de email para criar filtros e colocar os emails em pastas
  2. Se nao tem grupo (ou filtro. Tenho filtro from @jira manda pra pasta jira. Nao eh grupo, é regra from), cai na inbox
  3. Inbox deve ser lida TODO dia.
  4. Crie uma pasta “later” ou “menos importante”. Coloque nesta pasta todos os grupos que não precisam que vc leia o tempo todo o email.
  5. Esta em alguma pasta e vc precisa fazer? Mova pra inbox. Inbox pode ser vista como todo
  6. Leu a inbox e resolveu? Arquive!
  7. Quer acompanhar prazos e acompanhar mt bem tudo? ActiveInbox!

Use o lastpass para senhas, vai te poupar mt tempo!

Benchmarks