Produtividade em times de tecnologia

Que coisas ou fatores podem tornar times de tecnologia mais produtivos? Essa palestra é para você que está na jornada de buscar mais produtividade dentro dos times de tecnologia da sua empresa.

Transcript

1. PRODUTIVIDADE em times de tecnologia
2. Eduardo Matos Pai da Duda e do João Líder em Tech há +8 anos Desenvolvedor há +17 JWT | R7.com | Creditas | GetNinjas | Nubank | Will Bank | iFood
3. Produtividade é o tema da moda
4. https://about.fb.com/br/news/2023/03/atualizacao-sobre-o-ano-de-eficiencia-da-meta/
5. McKinsey Em grandes empresas, problemas estruturais são o principal obstáculo para alcançar as metas digitais “As empresas esperam que grande parte de seu crescimento de curto prazo seja impulsionado pelo digital, mas o impacto continua elusivo. Além disso, faltam estruturas organizacionais eficazes, responsabilidade e métricas e incentivos significativos. À medida que os executivos se envolvem mais nos esforços digitais, eles devem trabalhar para garantir que suas estruturas e processos de negócios sejam configurados para aproveitar ao máximo as oportunidades que os esforços digitais oferecem”
6. "Arquitetura de software e estrutura organizacional fracamente acopladas é um pilar chave da performance de entrega contínua e da capacidade de dimensionar a organização e aumentar o desempenho linearmente”
7. um pouco de história Ainda nos amparamos no Taylorismo ou Fordismo para descobrir como otimizar o trabalho das pessoas O argumento de Taylor sobre e fi ciência passa pelo entendimento de que era necessário escolher as pessoas certas e treiná-las nas funções que iriam desenvolver. Já ouviu por aí esse argumento? Num trabalho que exige uma técnica repetitiva, isso pode até ter algum sentido, mas quando lidamos com criatividade pra resolver problemas, dos mais variados, essa perspectiva não cabe. Frederick Taylor
8. Tentar usar essas práticas de gestão que funcionam num ambiente de fábrica, num contexto onde é crucial pensar em como resolver problemas das maneiras mais criativas, causa uma perda de inovação e de surgimento de potenciais ideias que podem gerar mais benefícios para os clientes ou empresa. O trabalho do conhecimento envolve uma série de fatores que vão além de ter pessoas certas ou bem treinadas.
9. como resolver isso? Ainda há poucos estudos relacionados à produtividade em trabalhadores do conhecimento, mas algumas vertentes tem seguido o caminho de diminuir a quantidade de contextos e tornar a carga cognitiva de conhecimento mais simples.
10. mas então não dá pra medir o quanto estamos produtivos? Existem muito mais fatores humanos do que técnicos ou ferramentais, embora as ferramentas ajudem muito a diminuir a fricção no trabalho a ser feito.
11. o que temos hojee Nos últimos anos, algumas abordagens surgiram pra tentar nos ajudar a melhorar nossa e fi ciência ao entregar software. DORA Metrics, SPACE framework foram duas delas.
12. DORA Metrics DORA é um acrônimo (DevOps Research and Assessment) de um time de pesquisa que foi responsável por elencar 4 principais métricas que indicam a performance de um time: ⁃ Deployment Frequency - quantas vezes um time/organização consegue entregar em produção com sucesso; ⁃ Lead Time for Changes - quanto tempo leva desde o primeiro commit até estar em produção ⁃ Change Failure Rate - Porcentagem de falhas nos deployments em produção ⁃ Time to Restore Service - Quanto tempo se leva para recuperar de um incidente em produção. ⁃
13. Essas métricas nos ajudam a descobrir pontos de melhoria no fl uxo de entrega de código, desde ferramentas de CI/CD, até de observabilidade e resiliência. A grande questão por trás dessas métricas, é que elas servem para nortear ações, e não exatamente de fi nir se estamos produtivos ou não Veja que, deployment frequency alto pode signi fi car alta capacidade produtiva, mas nem sempre signi fi car entregas e fi cazes.
14. ser ou estar produtivo Eu tenho percebido nos últimos anos que não existe “ser” produtivo, mas “estar” produtivo. Isso signi fi ca que o meio em que as pessoas estão trabalhando in fl uenciam o “estar” produtivo. Precisamos entender que individualizar produtividade pode ser um erro gigante. Os aspectos sócio-técnicos do trabalho in fl uenciam 100% o quanto as pessoas podem “estar” produtivas.
15. sistemas sócio… o quê? Sistemas sócio-técnicos é uma teoria que estuda a relação entre aspectos sociais e tecnológicos, entre os sistemas (um grupo de partes interativas e interdependentes que forma um todo complexo). Esses fatores afetam diretamente a experiência das pessoas desenvolvedoras. Exemplos de fatores: interrupções, ferramentas de desenvolvimento que causam fricção no trabalho, código mal organizado, tarefas não claras.
16. aí que entra DevEx Um estudo recente trouxe 3 grandes pilares que afetam a produtividade de pessoas de tecnologia: Feedback Loops Cognitive Load Flow State https://queue.acm.org/detail.cfm?id=3595878
17. | feedback loops Esse pilar diz respeito à qualidade e velocidade de resposta para algumas ações serem feitas. Por exemplo, tempo de compilação, tempo pra rodar a suíte de testes, tempo pra code-review, entre outros assuntos. Quando esse tempo é muito grande, possivelmente as pessoas vão trocar de tarefas esperando essas fricções se resolverem, ou até mesmo fi car aguardando - gerando frustração e menos velocidade nas entregas. Diminuir esse loop é importantíssimo! https://queue.acm.org/detail.cfm?id=3595878
18. | carga cognitiva Carga cognitiva é a quantidade de processamento mental requerido para uma pessoa executar um trabalho. Exemplos de coisas que podemos observar quando há alta carga cognitiva, é a quantidade de serviços que um time precisa lidar, complexidade ou alto acoplamento de código, di fi culdade em descobrir causas de incidente, demora para novas pessoas no time estarem prontas para executar o trabalho. Times que tem muitos domínios sob sua responsabilidade provavelmente sofrem com alta carga cognitiva.
19. 🧠 Sobrecarga de Domínios Problemas resultantes da sobrecarga: • Conhecimento super fi cial do contexto de negócio; • Demora pra ganhar contexto novamente sobre o domínio, diminuindo a produtividade; • Baixo conhecimento sobre a arquitetura ou o ecossistema que o domínio abrange; • Aumento do tempo para corrigir e identi fi car problemas; • Alta demora na recuperação de incidentes (MTTR - mean time to recovery); • Sobrecarga de assuntos, o que pode levar à fadiga mental e stress; • Di fi culdade ao lembrar de detalhes importantes das jornadas; • Fadiga na tomada de decisão - tende-se a tomar decisões mais pobres por conta da quantidade de assuntos pra lidar; • Tempo de onboarding mais alto para novas pessoas no time;
20. Casos da vida real Já liderei times que tinham diversos domínios sob sua responsabilidade. Alguns desa fi os eram constantes, como a priorização de iniciativas, de fi nição dos objetivos, o entendimento do capacity dos times e o stress que o time tinha ao ter que buscar informações de fl uxos que nem sabiam que tinham responsabilidade.
21. Mihaly Csikszentmihalyi (Flow: The Psychology of Optimal Experience) | flow state “O estado mental altamente efetivo de uma pessoa completamente imersa em uma atividade”
22. quando você está “no fl ow”… • há a uma sensação de "ecstasy" e clareza; • você sabe exatamente o que você quer fazer de um momento para outro; • o senso de tempo desaparece; • você esquece de você mesmo; • você se sente parte de algo maior. Photo by Mulyadi on Unsplash
23. você já se sentiu assim alguma vez? Pra quem trabalha desenvolvendo software, essa sensação acontece quando estamos tão imersas ou imersos no código que esquecemos a hora e a realização ao ver a conclusão de uma entrega (por exemplo, um endpoint de uma API funcionando como deveria, ou um trecho de código executando algo de forma perfeita) gera um grande prazer e alegria. Ver as coisas funcionando depois que você fez aquele código é uma sensação realmente diferente.
24. flow em desenvolvimento de software cada história fl ui da "ideia" ao entregável, software funcionando diretamente sem fi las, sem um inventário (trabalho em processo), distração, interrupção ou multitasking
25. O que impede o flow? • Fadiga • Requisitos perdidos • Troca de contexto e falta dele • Interrupções no fl uxo de trabalho • Distrações • Espera por clareza do trabalho • Barreiras de comunicação • Falta de conhecimento/skills • Reuniões desnecessárias • Dependências externas ou de outros times • Expectativas irreais ou não claras;
26. Carga Cognitiva e Flow Flow tem uma relação próxima com carga cognitiva. Se as pessoas do time precisam parar pra ganhar contexto do trabalho, buscar informações para ter clareza do trabalho a ser feito, por conta da falta de contexto e das dependências não explícitas ou não declaradas, di fi cilmente vão conseguir encontrar o estado de Flow.
27. então como aumentar a produtividade do meu time/empresa? Dentro desses 3 pilares, existem métricas que você pode acompanhar
28. https://queue.acm.org/detail.cfm?id=3595878
29. como posso começar uma jornada de produtividade no meu time?
30. observe como o trabalho é feito Veja como as demandas chegam, como elas são escolhidas pelas pessoas, como elas tiram dúvidas (se tiram), como o trabalho fi ca visível, que passos normalmente acontecem durante essa jornada.
31. converse com as pessoas Medir é a última parte da jornada. Conversar com seu time vai te trazer mais ideias, repensar outras e con fi rmar hipóteses.
32. vá além do óbvio Nem sempre baixa produtividade é causada por falta de conhecimento do time. Muitas vezes as pessoas estão lidando com muita informação e contexto pra fazer o trabalho. A complexidade dos assuntos que um mesmo time cuida pode ser a causa de ine fi ciência. É importante entender o quê do trabalho em si parece gerar fricção e atrapalhar as pessoas de terem espaço pra pensar e criar boas soluções. Às vezes uma estrutura de time mais enxuta e com domínios claros pode ser mais efetiva do que um time grande e com muitas responsabilidades
33. entenda como o código é feito e finalizado Saber como seu time entrega o código, testa, roda localmente, pode abrir um leque de oportunidades de melhorar a produtividade das pessoas. Monolitos altamente acoplados tendem a diminuir a velocidade do time. O nível de complexidade e acoplamento afeta diretamente o poder de resolver problemas.
34. use métricas pra reflexão, e não para cobranças ou metas Usar métricas como metas é um erro clássico. Metas moldam comportamentos. Então se você colocar metas pra reduzir tempo de code-review, você pode gerar problemas de qualidade (as pessoas vão apenas aprovar rápido, pra bater a meta de diminuir time to review) Abra as métricas com seu time, e deixe claro o objetivo de visualiza-las, tirando o caráter de cobrança ou de meta.
35. não podemos individualizar problemas de eficiência, antes de prover um espaço e ambiente propício para que as pessoas estejam produtivas
36. mini-jabá :)
37. mini-jabá :) https://www.youtube.com/@people-tech
38. mentoria, treinamentos e consultoria Link para agendar mentoria ☝ contact@eduardomatos.me Se precisar de ajuda com assuntos relacionados a liderança, arquitetura de software, design organizacional e cultura de engenharia, me manda um email no:
39. Referências • Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi | Goodreads. • The Principles of Product Development Flow: Second Generation Lean Product Development (English Edition) - eBooks em Inglês na Amazon.com.br • DevEx: What Actually Drives Productivity • Mckinsey study: The digital tipping point
40. Obrigado :) @eduj.matos @eduardojmatos @people-tech Clube People Tech contact@eduardomatos.me