Pois é. Em três semanas esse projetinho cresceu de um jeito que merece um post só sobre o processo, porque ele virou um exemplo vivo de uma coisa que eu prego há tempos: software de verdade é cultivado, igual planta. Ninguém monta software bom peça por peça como quem monta um Lego. Vou te mostrar os números, e principalmente a história que eles contam.

Os números, hoje

O ai-memory tem hoje, em 24 dias de vida (do primeiro commit em 21 de maio até agora):

• 482 commits no main, uma média de 20 por dia.
• 26 pessoas commitaram no repositório.
• 10 crates Rust no workspace.
• ~62,7 mil linhas de Rust de produção, mais ~11 mil linhas de teste em tests/, mais de 1.000 funções de teste e 90 módulos #[cfg(test)] espalhados pelo código.
• ~19,7 mil linhas de documentação em markdown (docs/).
• 70 pull requests, dos quais 59 mergeados (84% de aceitação).
• 27 issues, 100% fechadas.
• Saímos do v1.0.0 em 12 de junho e já estamos no v1.0.6.

Vinte e quatro dias. Guarda esse número, porque a parte interessante não é o tamanho final, é a forma como ele chegou aqui.

Como começou: um só de tudo

O ai-memory nasceu pequeno e burro de propósito. Nos dois primeiros dias eu cravei o esqueleto inteiro: bootstrap do workspace, servidor MCP, captura por hooks, handoff entre agentes, versionamento da wiki em git, trait de provider de LLM, embeddings. Tudo isso rodando pra um usuário, uma máquina, um workspace, uma arquitetura (Linux, basicamente). Sem multi-usuário, sem permissão, sem escopo, sem suporte a Windows ou macOS. Era o meu cérebro de agente, na minha máquina, pra mim.

No dia 3, quando a primeira contribuição externa chegou (um fix do Lucas Oliveira pra URLs de provider OpenAI-compatível, o PR #6), o projeto tinha 102 commits e cerca de 22,9 mil linhas de código-fonte. Já eram os mesmos 10 crates de hoje, mas com uma fração da funcionalidade. Era um MVP de um-só-de-tudo que funcionava pra mim e mais ninguém.

E aqui é onde a maioria dos projetos morre, ou pior, onde a maioria dos programadores inexperientes erra a mão.

A falácia do Lego

Tem uma crença muito difundida, principalmente em quem está começando, de que dá pra desenhar tudo que um software vai ser antes de escrever a primeira linha. Você senta, planeja a arquitetura inteira, quebra em pedacinhos bem organizados, com as pastas e as camadas e as interfaces todas previstas, e aí constrói peça por peça. Quando a última peça de Lego se encaixa, o software está pronto. Lindo no papel.

Na prática, é o caminho mais rápido pra deteriorar código. Quanto mais cedo você cristaliza uma estrutura, mais cedo ela vira uma camisa de força. Você previu um sistema de permissões elaborado antes de ter usuários? Parabéns, agora você carrega o peso de manter abstração que ninguém usa, e que quase sempre está errada, porque você a desenhou adivinhando o futuro em vez de responder a uma necessidade real. O programador inexperiente faz engenharia em excesso no começo, e não importa o quanto ele planeje, o resultado começa a apodrecer rápido, porque ele está resolvendo problemas que ainda não existem e errando os que existem.

Eu não acredito em software que termina. Já escrevi sobre isso no “Software nunca está pronto”, e ele se conecta direto com as metodologias Agile originais, as de verdade, antes de virarem ritual corporativo de post-it. Software bom é uma escultura de barro: maleável, sempre úmida, que você fica ajustando, transformando, e que nunca fica pronta. É argila que você modela enquanto ela é usada. A torre de Lego que uma hora fica pronta e acabou é fantasia.

O que os contribuidores construíram

E é aí que entra a melhor parte de ter aberto o código. Aquele MVP de um-só-de-tudo virou um sistema multiplataforma e multiusuário porque muita gente colocou a mão. Eu quero agradecer nominalmente, porque sem essas pessoas o projeto seria uma fração do que é:

Djalma Júnior tocou boa parte da arquitetura pesada (multi-usuário, admin, recall cross-project), com 25 PRs mergeados. wlech com dezenas de commits. Pedro de Freitas Jr em embeddings e correções de web. Mauro Couto de Paiva e Gustavo Cateim tocaram boa parte do suporte a Windows. Pablo Winter, Lucas Oliveira (autor do primeiro PR externo) e Said Rodrigues, entre vários outros. Valeu demais, gente.

O que essas contribuições adicionaram, em destaque:

• Suporte real a Windows, macOS e Linux. O que era Linux-only ganhou compatibilidade com bash 3.2 do macOS, um índice de arquivos NTFS pra rastrear inode no Windows, e comandos de hook nativos por plataforma.
• Frontend API (/api/v1) e UI web customizável. Deixou de ser só MCP + CLI e ganhou uma superfície HTTP de verdade, com links de wiki clicáveis e busca por caminho de arquivo.
• Multi-usuário com atribuição. Tabela de users, comandos de writer/reader, e atribuição de autoria na mesma transação SQL da escrita (pages.author_id + frontmatter).
• Multi-workspace e recall cross-project. Busca global, links entre wikis de projetos diferentes, e isolamento de projeto ativo por sessão e por ator.
• Mais providers e mais agentes. Gemini, Copilot via OAuth, OpenAI-compat strict mode; e suporte a Antigravity, Grok e VS Code Copilot além dos originais.
• Robustez operacional. Recuperação por checkpoint, reindex-from-wiki pra reconstruir o índice a partir do markdown, manifestos _meta.md auto-descritivos.

Repara numa coisa: nada disso estava no plano original. Não existia plano original. Cada uma dessas features entrou porque alguém precisou dela, abriu uma issue ou um PR, e a estrutura foi cedendo espaço pra acomodar. O multi-usuário não foi previsto: ele emergiu.

E só agora a gente parou pra consolidar

Aqui está o ponto central do post. Durante essas três semanas, o código cresceu meio bagunçado de propósito. Quando o suporte a multi-usuário entrou, a lógica de “qual workspace e projeto esse pedido está mirando” foi parar embutida direto no meio de vários handlers do servidor MCP, da API web, do admin, espalhada e duplicada. Cada lugar resolvia escopo do seu jeito. Tinha duplicação. Tinha código que não era bonito. E está tudo bem, porque estava funcionando, e funcionando pra muita gente.

Só depois que o software já rodava na máquina de dezenas de pessoas, em três sistemas operacionais, com multi-usuário de verdade em produção, é que eu parei e falei: “ok, agora é uma boa hora pra refatorar e repensar a fiação interna”. O penúltimo commit grande, o refactor: centralize scope auth and wiki consistency, fez exatamente isso, com 1.239 linhas adicionadas e 249 removidas, criando um ScopeResolver central de 601 linhas e um ActorContext consolidado.

Veja o “antes”. Esse trecho de resolução de escopo vivia duplicado, com variações, em vários métodos:

// ANTES: lógica de escopo embutida, repetida em cada handler
let active = self.active_project.get_for(actor);
if let Some(name) = explicit_project.map(str::trim).filter(|s| !s.is_empty()) {
    if let Some((active_ws, _)) = active
        && let Ok(Some(pid)) = self.reader.find_project(active_ws, name.to_string()).await
    {
        return Ok((active_ws, pid));
    }
    if active.map(|(ws, _)| ws) != Some(self.workspace_id)
        && let Ok(Some(pid)) = self
            .reader
            .find_project(self.workspace_id, name.to_string())
            .await
    {
        return Ok((self.workspace_id, pid));
    }
    return Err(McpError::internal_error(
        format!("project '{name}' not found in the active or default workspace"),
        None,
    ));
}
Ok(active.unwrap_or((self.workspace_id, self.project_id)))

E o “depois”. A mesma resolução, agora delegada pra uma autoridade única no crate de store:

// DEPOIS: um resolvedor central, uma chamada
fn scope_resolver(&self) -> ScopeResolver<'_> {
    ScopeResolver::new(&self.reader, self.workspace_id, self.project_id)
        .with_writer(&self.writer)
        .with_active_project(&self.active_project)
}

// ... e cada handler vira isto:
self.scope_resolver()
    .resolve_current_or_project(explicit_project, actor)
    .await
    .map(ai_memory_store::ResolvedScope::as_tuple)
    .map_err(Self::scope_error)

Três métodos diferentes que antes carregavam 30 linhas de lógica embutida cada um, com lookup_ids, fallback de workspace e tratamento de erro próprio, colapsaram em uma chamada cada. Junto vieram os commits irmãos: harden multi-user admin auth boundaries e prevent scoped fallback bleed. Centralizar permissão, escopo de workspace e usuário, e consistência da wiki, tudo num lugar só, com regra clara.

O detalhe que importa: o ScopeResolver não foi inventado no começo do projeto adivinhando que um dia ia ter multi-usuário. Ele foi extraído de um código que já existia, já funcionava, e já tinha mostrado, na prática, quais eram os padrões que se repetiam. A abstração veio depois do uso, não antes. Eu deixei a estrutura emergir do código, e só quando ela ficou óbvia eu a consolidei.

A ordem certa: make it work, make it right, make it fast

Esse é o resumo de tudo. Tem um ditado antigo, atribuído ao Kent Beck, que eu carrego como mantra: “make it work, make it right, make it fast”. Faça funcionar, depois faça direito, depois faça rápido. Nessa ordem. A maioria dos programadores inexperientes quer fazer “direito” e “rápido” antes de fazer “funcionar”, e aí inventa regra sem ter código pra justificar a regra.

O ai-memory seguiu a ordem certa sem eu nem pensar muito nisso. Primeiro fiz funcionar pra uma pessoa, escopo simples. Depois fiz funcionar uma feature de cada vez, refatorando e endurecendo o código no caminho, mas sem nunca cair na engenharia em excesso e sem nunca reescrever do zero pra encaixar numa estrutura pré-concebida. Eu deixei as estruturas atuais emergirem do código que foi sendo adicionado. Isso significou conviver com alguma duplicação e algum código meia-boca por um tempo, até bater aquele momento de “agora sim é hora de refatorar e repensar a fiação”. E só agora, com o software maduro e em uso, é que eu estabeleci padrões e regras melhores pra código novo. Regras lastreadas em código de verdade, não em adivinhação.

KISS, “keep it simple”, é sobre não resolver problema que você ainda não tem. Não tem nada a ver com escrever pouco código. É deixar a arquitetura emergir do código, e não o contrário. Você não desenha a escultura e despeja o barro dentro do molde. Você pega o barro, começa a modelar, e a forma aparece conforme suas mãos trabalham. O molde, se um dia precisar de um, você constrói depois, em volta da forma que já existe.

Vinte e quatro dias, 482 commits, 26 pessoas, e nenhum deles seguiu um diagrama desenhado no dia 1. Porque não existia diagrama no dia 1. E é exatamente por isso que funcionou.

O ai-memory é open source e continua mudando toda semana: github.com/akitaonrails/ai-memory. Quer ajudar a modelar o próximo pedaço? Tem issue aberta esperando.

–

No dia 10 de fevereiro de 2026, eu postei o tweet acima, só jogando no ar uma coisa que estava na minha to-do list há anos, desde que eu publicava vídeos no YouTube. Nunca fiz porque eu odeio HTML/CSS e ter que fazer template de e-mail era suficiente pra não começar. Além disso, fazer mais uma newsletter, que é só uma lista de links chata, não me motivava.

Mas nesse dia eu já estava terminando meu segundo projeto com vibe coding, o FrankMD, e acho que entendi os principais truques e a metodologia pra fazer um produto completo da forma certa. Então, começaram a surgir várias ideias. Dei dump e escrevi este pequeno documento.

Pensei: e se eu fizesse não só o código do sistema de newsletter com vibe code, mas também tivesse parte do próprio conteúdo gerada por IA de forma inusitada, em forma de comentaristas: eu e um robô? E, claro, com Guia do Mochileiro na mente, tinha que ser o MARVIN, ou melhor, o “M.Arvin” (pra ninguém encher com copyright).

É claro, vai ter versão por e-mail semanal e um blog de arquivos. Mas já que vai ter tudo isso, por que não reescrever já toda a newsletter em script de podcast? E já que recentemente saiu o Qwen3 TTS, open source, por que não treinar um LoRa com minha voz (obviamente, tenho centenas de horas de minha voz no YouTube) e fazer um podcast totalmente automatizado?

Finalmente, um dos desmotivadores pra mim seria criar um Web Admin tradicional e ter que entrar manualmente lá pra cadastrar os links de notícias e meus comentários. Eu sei que ia me dar preguiça e, a uma hora, ia cansar. Só tinha uma solução: criar um bot mais inteligente com o qual eu pudesse conversar via DISCORD. Assim, eu posso rapidamente acessar, seja do meu PC, seja do meu smartphone, sem precisar logar num sistema separado nem nada. Eu já converso com pessoas no Discord, então a fricção seria zero.

Então:

• Marvin Bot pra gerenciar todo conteúdo (que eu mando e os automatizados, com comentários e tudo mais)
• Monitor de X.com pra checar o que eu postei e já pegar pra usar na newsletter. Incluindo as replies que eu dou, que vão virar Q&A!
• Newsletter website pra assinar, cancelar, etc
• Blog pra arquivos de newsletter e de transcripts dos podcasts (também com termos de serviço e de privacidade — sim, sou LGPD compliant!)
• Gerador automático de vozes e montador de podcast que vai subir automaticamente pra deixar disponível pro Spotify
• E ainda templates de blog e de e-mail, com versões de tema light e dark.

Você, que é um programador experiente, sem IA, quanto tempo levaria pra fazer tudo isso?

Pois bem, eu comecei no dia 10 de fevereiro. Terminei tudo no domingo, dia 15 de fevereiro. E hoje, dia 16, rodaram os jobs de produção pela primeira vez, o que gerou newsletter, blog posts, podcast, upload pro Spotify, envio de email.

E não foi do jeito podre que todo vibe coder amador faz:

Quem é de Rails deve ter ficado surpreso: projeto com taxa de 1 pra 1 de testes! 1 linha de testes pra cada 1 linha de código: 100% de cobertura. E isso, sem contar um projeto separado deles de integração completa, ponta a ponta (que usei pra garantir que a produção ficaria perfeita).

Todas as estratégias que eu aprendi ao longo dos anos colocando projeto em produção: segurança, escalabilidade, durabilidade, garantia de entrega sem spammar duplicatas de e-mails, etc. Depois vejo se faço mais posts específicos sobre alguns dos truques técnicos.

Este projeto não vou abrir como open source. Eu fiz 100% customizado pra mim, pro meu fluxo de trabalho e meus estilos. Não é difícil pra outro programador competente fazer a mesma coisa com vibe code: se eu consegui, qualquer um consegue. Então é só não ter preguiça de pensar e fazer. Aliás, não entendo como tech youtubers ainda não estão lançando 1 projeto completo em produção, por vídeo, pra todo mundo testar e ver.

No screenshot também não está o servidor de Qwen3-TTS, que produz áudio. Esse é bem mais simples, um servidor PyTorch. Aqui foi Python mesmo. O mais importante é o fine tuning do modelo pra gerar vozes exatamente do jeito que eu queria:

O blog é todo com Hugo/Hextra, como este também. E meu bot publica lá automaticamente.

M.Arvin Bot

O M.Arvin tem uma personalidade que eu detalhei como eu queria. E é um bot de Discord, então meu trabalho é assim:

Só preciso mandar um link com meu comentário (igual eu faria no X.com), ou posso postar direto no X, que ele vai pegar igual. Daí ele busca o conteúdo, faz um resuminho, faz um pequeno fact-check e o M.Arvin gera seu comentário em cima do meu.

Eu programei ele pra responder a um monte de comandos pra facilitar meu dia a dia. Isso é só uma pequena parte:

Eis um exemplo: eu tenho controle sobre quanto de IA ele está usando (é bem barato):

Deployment

Neste post não vou detalhar muito, mas uma coisa em que demorei bastante, passando por várias discussões e versões com o Claude Code, foi na arquitetura de infraestrutura. E no final ele conseguiu me dar um Deployment Guide, que consegui seguir até o fim e sabendo que minimamente está como eu mesmo faria se tivesse feito tudo sozinho:

Nenhum software tem garantia de ser 100% perfeito; este também não deve ser. Mesmo eu tendo revisado por dias, passando por cada etapa várias vezes, sempre vai ter algum bug que eu não previ. Eu “acho” que, pelo menos, tudo o que sei que costuma dar problema em produção, “acho” que consegui cobrir de forma satisfatória. Se fosse uma equipe humana, eu teria colocado em produção num estado pior do que o que atingi com o Claude.

Tudo o que dava pra proteger com Cloudflare, eu configurei. Todas as boas práticas pra e-mail/mailing, eu segui. Todas as precauções contra acidentes eu tomei (todo deploy automatizado com Kamal) e todos os e-mails dos assinantes foram encriptados com AES-256 no banco de dados (mesmo que vazem por acidente, não vazam os dados dos usuários). Não implementei profiling, cookies nem pixels de rastreamento, nada. Privacidade foi o foco.

Tudo o que dava pra reduzir custos, eu reduzi; afinal, vou pagar do meu bolso. Então, coisas como GPU na RunPod pra gerar os áudios são serverless. Eu subo só no momento de gerar; ele faz todo o processo e, depois, a máquina desliga. O servidor está todo organizado numa imagem Docker leve. Todos os modelos de IA estão num volume de rede separado.

Spoiler do Processo

Depois pretendo fazer um post maior falando da minha metodologia, mas é muito simples: trate o Claude Code/Codex como se fosse um programador humano esforçado — que vai cometer muitos erros, mas sabe obedecer ordens super explícitas, diretas, claras e sem ambiguidade. Meu papel é de gerente de produto, Tech Lead ou QA. Têm que ser os TRÊS papéis.

No total, o Claude Code fez 201 commits. Mas não são commits normais; considero que, num projeto normal com humanos, cada um teria feito aproximadamente 150 Pull Requests.

Pergunta a vocês que participam de sprints em projetos: quanto tempo leva pra ter 150 user stories/bug fixes aprovados e em produção no seu projeto real? Quantos user stories vocês conseguem fazer e aprovar (com QA e tudo) em UMA semana?

Eis um exemplo de um commit/“user story”:

Quando estava lá no commit, talvez 50, eu já pensava: “Já funciona!”* É o estágio que todo criador de conteúdo (que nunca colocou projetos de verdade em produção) já postaria, dizendo: “fiz vibe code em 2 dias”. De fato, em 2 dias eu já tinha o grosso das funcionalidades prontas.

Os outros 4 dias foram:

• 1 dia pra deploy em produção (quando tem tudo planejado com antecedência, todas as contingências já pensadas, é fácil).
• 3 dias só testando, criando testes automatizados/integração, gerando e regerando, exercitando todas as etapas de todas as partes, múltiplas vezes, e fazendo ajustes, refatorações ou até mesmo jogando fora um pedaço inteiro pra mudar, porque os testes indicaram que valia mais a pena.

Isso levou de 50 a 200 commits! E é a parte que todo vibe coder pula. Pra ser justo, é a parte que qualquer pessoa, com ou sem IA, pularia. E é por isso que sempre os projetos dão errado e vão pra produção cheios de erros e de buracos óbvios de segurança.

Mesmo depois de pedir ao Claude Code pra revisar boas práticas de segurança e de cobertura de testes, múltiplas vezes. Depois eu abri o Codex e pedi pra fazer a mesma coisa, e ele ainda achou mais buracos de segurança e mais testes faltando, múltiplas vezes. Mesmo depois dos dois fazerem essas checagens várias vezes, eu ainda encontrei sozinho mais buracos que mandei consertar. Em nenhum momento, nenhum dos dois conseguiu achar “TUDO”. Ninguém consegue, nem a IA.

Conclusão

Programar Vibe Coding da forma correta só tem um jeito: Extreme Programming!

Sim, todas as coisas “chatas” e “burocráticas” que todo desenvolvedor odeia fazer são o que garante que a IA vai devolver um resultado aceitável pra colocar em produção:

• Pair Programming: você precisa mandar a IA planejar primeiro e te dizer exatamente tudo o que vai fazer, ANTES de começar. Eu reviso, ajusto e, só quando estou satisfeito, deixo fazer. Fico olhando cada coisa que ele faz e, no final, mando ajustar o que acho que faltou.
• Test-Driven Development: toda funcionalidade deve vir acompanhada de testes unitários. Toda correção de bug precisa de testes de regressão.
• Continuous Integration: Toda vez que termina de implementar, precisa rodar script de CI pra ver se nada quebrou em outro lugar. Mais do que isso: no branch master, só há commits com testes que passam. Eu posso reverter em qualquer ponto e o projeto roda.
• Small Releases: isso eu achei ótimo no Claude, mesmo se eu acabar esquecendo de mandar ele comitar uma tarefa e mandar fazer outra, no fim, ele não faz aquela tosquice de git add . — não: ele separa em 2 commits e descreve cada um da forma correta. Além disso, eu subi produção na sexta-feira, e continuei sábado e domingo testando integração local e em ambiente de produção, pra garantir que não tem isso de “só na minha máquina funciona”
• Coding Standard: eu iniciei com o mínimo de requerimentos técnicos, mas, durante o desenvolvimento, mandei refatorar do meu jeito várias e várias vezes.

Essas são as principais tarefas a serem feitas. Já adianto: “Spec Driven Development” não é totalmente inútil, mas a estrutura não tem importância: é o seu texto que conta.

É a mesma coisa que User Stories. Grande bosta que você escreveu “Eu, como o usuário final, Quero que quando digitar X …, o sistema responda com Y”. O formato NUNCA é importante. O que é importante é COMO você escreveu o que vai no meio. Se você não sabe escrever, a IA não vai saber responder a você como deveria. Vou fazer outro artigo só pra demonstrar como todos vocês são péssimos em escrever.

O recado é simples: Vibe Code funciona, em partes.

O que funciona mesmo é “Senior Agile Vibe Coder”

Vou perguntar de novo: quanto tempo, sem IA, você levaria pra produzir 150 user stories/bug fixes, no escopo que resumi no começo? Até colocar em produção com tudo testado? Duvido que seja em 6 dias como eu fiz.

Finalmente vou discutir um pouco sobre Programação Orientada a Testes e o que isso tem a ver com gerenciamento de projetos, equipes, e um pouco sobre como todo mundo ainda encara estimativas da maneira errada.

Este video é pra você programador, gerente, cliente, empreendedor, que tem dificuldades de entregar projetos de qualidade. Vamos entender tudo que vocês estão fazendo de errado e porque dá errado.

== Conteúdo

• 00:00 - Intro
• 01:13 - CAP 01 - Suas Premissas estão Erradas - Esqueça Bullshit
• 05:33 - Programadores não são Pedreiros!
• 08:31 - CAP 02 - Provas de Conceito - Comecem a Fazer!
• 13:01 - CAP 03 - Programação Orientada a Testes - Comecem a Fazer!
• 17:53 - Demonstração de testes de Firefox
• 19:02 - Demonstração de testes de React
• 19:27 - Demonstração de testes de Tailwind
• 19:57 - Demonstração de testes de Django
• 20:28 - Demonstração de testes de Laravel
• 21:06 - Demonstração de testes de VSCode
• 22:14 - Demonstração de testes de Rust
• 24:02 - Demonstração de testes de Spring Boot
• 27:25 - Vocês não SABEM fazer testes!
• 28:45 - CAP 04 - Como a falta de Testes afeta Produtividade? A Raíz do Ágil
• 32:27 - Como é um fluxo de trabalho Ágil?
• 37:01 - CAP 05 - O que significa Estimar? Estimar não é Prever
• 47:27 - CAP 06 - Removendo Maus Elementos. Não acumule problemas.
• 50:07 - CAP 07 - Resumindo os Princípios: O Mínimo pra Começar
• 52:27 - Bloopers

SCRIPT

Olá pessoal, Fabio Akita

Vamos dar uma pausa na série de videos técnicos. Se não assistiu ainda, fiz uma minissérie falando sobre redes e logo em seguida começando a falar sobre Linux. Como foi muita coisa técnica, eu me entediei, então resolvi mudar a marcha hoje pra falar sobre gerenciamento de projetos, em particular finalmente quero discutir sobre o famigerado desenvolvimento orientado a testes. É um puta tema cabeludo que daria pra fazer um canal inteiro sobre, mas a idéia é discutir só alguns pontos básicos, pra iniciantes no assunto mesmo. Então vamos lá.

(…)

Se você já tem experiência, trabalha em grandes empresas e grandes projetos, certamente vai discordar de algumas coisas que vou falar hoje e não está errado. Processos de gerenciamento de projetos de software variam bastante e devem ser customizados especificamente pro seu tipo de empresa, pro seu estilo de trabalho em equipe. Não existe nenhuma metodologia que vai se encaixar magicamente em todos os lugares. Simplesmente não existe, é inútil tentar fazer isso. Eu falei sobre isso no video de Esqueça Metodologias Ágeis. Recomendo assistir esse também depois.

A expectativa é que existe algum conjunto de procedimentos que toda equipe consegue seguir pra manter os projetos estáveis e eficientes. Certamente deve existir algum tipo de PMI, Agile, CMMi, bla bla bla Alguma fórmula que o Spotify, o Netflix, a Microsoft, alguém inventou, que resolve todos os problemas. E não tem. Quanto mais cedo aceitarem isso, menos dor de cabeça vão ter. Se você se ver dizendo “a gente segue o modelo Spotify” ou segue qualquer modelo, certamente está fazendo errado. Veja no meu video do Guia Definitivo de Organizações.

Além disso, se você é um empreendedor não-técnico, certamente assistiu um monte de palestras motivacionais, bullshit de startups e tá fazendo um monte de coisas erradas. Eu fiz 3 videos pra vocês também, o de Empreendendo Errado com Software e o video em duas partes dos 10 Mitos sobre Tech Startups. Vou tentar não repetir o que já disse lá, então assistam depois também.

Vamos lá, no final do dia, você, como membro de uma equipe de desenvolvimento de software, precisa entregar alguma coisa que seu chefe ou seu cliente precisam no produto deles. Ou mesmo no seu próprio produto. Se for iniciante, é muito mais fácil integrar uma equipe que já existe, que tem membros experientes e processos já em andamento. Um iniciante sempre vai fazer errado da primeira vez, especialmente sozinho. Não tem como acertar de cara sem nunca ter feito, e isso não é um defeito, é natural. São muitas peças móveis que você nunca viu funcionando. É que nem eu dar um carro desmontado e mandar montar tudo e ainda funcionar direito no final. Impossível.

Vai parecer que é simples, só encaixar as peças e apertar os parafusos. Mas não é só encaixar. Precisa monitorar cada pedaço, testar, ver se não tem vazamentos, se tá tudo alinhado, balanceado, etc. Porque se sair só montando tudo sem testar nada, quando terminar e tentar ligar o carro, vai explodir. Ou, o mais provável, nem vai ligar, e ninguém vai saber porque. E agora que tá tudo montado, vai precisar desmontar tudo e ir testando. No mínimo vai ser uma grande perda de tempo.

Antes de mais nada, você precisa de pelo menos um membro da equipe um pouco mais experiente. Nem vou dizer sênior porque não quero ficar tentando definir hoje o que é junior ou sênior, mas alguém que já entregou no mínimo um projeto de sucesso. Porque essa pessoa precisa se responsabilizar pelas decisões técnicas. Decidir qual framework, bibliotecas, módulos, como as coisas vão ficar organizadas, como vai ser feito deployment. E lógico, todo mundo da equipe pode e deve contribuir com idéias, sugestões, mas alguém precisa bater o martelo e todo mundo seguir em frente.

Senão toda hora se perde tempo com discussão inútil. Um grupo cheio de opiniões que leva horas ou dias pra decidir as coisas é ineficiente e o resultado sempre vai ser uma droga. Aliás, se isso acontece, é um bom sinal que o tal sênior responsável é ruim. Nenhuma equipe respeita alguém que só fala mas não faz. Um bom sênior fala menos e mostra mais, ensina como faz na prática. E o melhor é errar cedo, ter evidências de porque a primeira decisão deu errado, e isso servir de input pra uma segunda decisão melhor. Do que ficar horas discutindo o melhor caminho, pra no final dar errado de qualquer jeito.

Isso talvez seja a coisa mais fundamental numa equipe. Errar antes e consertar rápido é infinitamente melhor do que horas e horas de discussão tentando chegar em consenso e bikeshedding. Ninguém tem certeza? Foda-se. Cara ou coroa. Faz um teste. Vê se funciona. Se falhar, agora veja porque falhou, conserta, e segue em frente. Essa é a essência do processo de lidar com o desconhecido. Todo mundo pensa que quando algo é desconhecido o certo é tentar planejar infinitamente até ter todos os passos minuciosamente detalhados. Mas tá errado. É desconhecido, qualquer planejamento que tentar fazer, quanto mais detalhado for, mais errado vai estar.

Acho que esse é o ponto principal da discussão de hoje. Quando você e sua equipe são inexperientes, das duas uma, ou vão andar super lento porque vão tentar planejar em excesso, discutir em excesso, ou vão ser kamikazes retardados que vão começar a fazer e só ir fazendo sem parar pra ver se estão indo na direção certa. Ambos estão errados. Não consigo entender porque o desespero não leva ao mais óbvio, que é errar cedo, consertar rápido e o mais importante: garantir que o que já foi feito e está certo, não quebre à toa, porque isso seria o equivalente a andar pra trás.

Não tem nenhum problema rascunhar o que precisa ser feito. Faça um checklist de funcionalidades. Faça post-its com cada tarefa. Faça uma planilha. Não importa. Todo mundo da equipe precisa ter uma noção geral do que precisa ser feito. Mas não tente detalhar em excesso. Só coloque detalhes no que estiver muito incerto, no momento em que precisa ser feito e não com meses de antecedência. Portanto, qualquer um que tenha estudado engenharia de software ou gerenciamento de projetos tradicional, e viu coisas como requisitos, casos de uso, ou até mesmo stories, pára. Você só precisa de uma lista, curta, com poucas palavras. Não é pra levar dias escrevendo, é pra levar horas, no máximo. Vou voltar nesse ponto mais pro fim.

Não importa quantos diagramas, fluxogramas, photoshops ou words vocês produzam, nada disso é o software. Pra um amador, dá impressão que o ideal é ter o máximo de páginas de requerimentos detalhados quanto possível. Tá errado. Essa noção errada vem pelo seguinte: qualquer projeto de engenharia civil, pra fazer uma casa ou um prédio, precisa de meses de planejamento, várias plantas baixas, diagramas de encanamento, diagrama elétrico e tudo mais, pra garantir que o prédio seja construído perfeitamente dentro das especificações.

Portanto, software deveria ser a mesma coisa. Vamos fazer quinhentas páginas de diagramas UML, que é o equivalente a planta baixa, porque daí, quando for escrever o software propriamente dito, vai sair tudo perfeitamente dentro das especificações. Essa premissa está errada. Todo mundo acha que um programador é um pedreiro. Não querendo desvalorizar o trabalho de pedreiros, mas um programador, na realidade, é o arquiteto. O trabalho de pedreiro, é 100% automático desde sempre. O pedreiro de software é o compilador ou interpretador. A planta baixa É o código fonte do software. Portanto todo programador, quer ele queira ou não, faz trabalho de um arquiteto.

Lógico, se sua linha de trabalho é só instalar Wordpress pra diversos clientes. Não se está produzindo software novo, só copiando e colando o que já existe e esse trabalho, sim, parece mais uma linha de fábrica. Mas estamos falando de fazer software que não existe, quase do zero. Reusando vários componentes como frameworks ou bibliotecas, sim, mas o software final não seria possível fazer numa linha de fábrica. Cada passo no desenvolvimento desse software requer tomadas de decisões de cada programador envolvido. Não existe receita.

O famoso exemplo de fazer um botão com cor na tela. Dá pra fazer de dezenas de jeitos diferentes. Posso fazer todo o CSS e HTML do zero. Posso escolher usar um Tailwind da vida. Mas se escolher isso, não pode ser só pra um botão, o certo é usar em todos os botões e elementos gráficos de todas as telas. Eu quero isso? Posso escolher fazer todo o sistema de eventos do zero ou usar React ou Vue. Mas de novo, isso vai afetar todo o sistema. Qual minha equipe tem mais facilidade pra usar? Já tinha começado como um sistema em Angular? Se eu decidir que quero usar Vue no lugar, quanto custa reescrever tudo? Vale a pena?

Tudo são decisões. Muitas sem grandes consequências, mas algumas podem quebrar seu projeto inteiro se feito de forma irresponsável. Como se toma esse tipo de decisão? Não tem receita pra isso. Na maioria das vezes, seu prazo tá apertado, e o ideal é não escolher decisões que envolvam jogar tudo fora e fazer tudo de novo, então isso já elimina várias escolhas. Mas algumas são incertas, se der certo talvez vocês ganhem produtividade pra frente. Pra isso se fazem provas de conceito.

Todo mundo ignora o poder das provas de conceito. Prova de conceito ou protótipos são pedaços de código, uma pequena parte da aplicação, que deve ser feito com o objetivo de potencialmente jogar fora depois. Portanto não precisa ser integrado ao código principal. Pode ser feito como uma branch do repositório, o que num GitHub chamamos de pull requests ou num GitLab chamamos de merge requests. Tecnicamente é um desvio no repositório de código. Enquanto todo mundo continua trabalhando no tronco principal, a branch main, alguém trabalha nesse desvio, num galho, por alguns poucos dias, pra ver na prática se a mudança sugerida realmente trás benefícios ou não.

Provas de conceito tem que ser um empreendimento curto, um micro-projeto de prazo fixo. Coisa de 2 dias, uma semana no máximo. Mesmo estando incompleto, no final desse período deve dar pra equipe ver na prática como a idéia se materializa em código, os impactos que causa, e se todo mundo está confortável em seguir em frente. Daí pode até jogar fora esse galho e todo mundo voltar pro tronco principal aplicando seja lá qual seja essa mudança técnica. Ou então se prova que a idéia era mais complexa do que se imaginava, e todo mundo descarta essa idéia. Mas isso não foi perda de tempo.

Você tem 10 grandes dúvidas técnicas que podem custar muito tempo, coisas no nível: devemos usar React ou Vue? Devemos ficar no Postgres ou migrar pra Firebase? Devemos ficar só em APIs REST ou já começar tudo em GraphQL? Vamos dar deploy das coisas em Vercel ou criar Terraform pra AWS? Só que ninguém da equipe nunca teve muita experiência em nenhuma dessas coisas. Cada uma pode potencialmente custar 2 a 4 meses. Sua equipe só tem 3 pessoas. Então fácil, se for fazer tudo, não vai sair por menos que 10 meses pra equipe, e com a falta de experiência, fácil vai virar o ano.

Em vez disso, pára tudo, cada um da equipe vai fazer provas de conceito de cada coisa, num prazo máximo de 2 semanas. E esse prazo é fixo, depois de 2 semanas vamos ver o que saiu. No final, mais da metade dessas coisas se provam realmente mais complicadas ou o custo claramente não vai compensar. Em vez de ir em frente com 10 coisas incertas que vai custar pelo menos 1 ano pra fazer, vocês concordam agora em desistir de 7 delas, porque a prova de conceito deu evidências que não vai dar certo. Por outro lado, 3 dessas coisas se provaram boas, e vocês vão seguir em frente.

Ao custo de 2 semanas da equipe, vocês economizaram mais de meio ano de trabalho que ia dar errado, e vão prosseguir com 3 coisas que vão custar um mês da equipe e que todo mundo tem mais certeza que vai dar certo. Esse é o grande truque: não se comprometa com coisas de longo prazo que ninguém tem certeza. Pague um tempo curto pra descobrir se dá pra cobrir essa incerteza. Não é jogar tempo fora, é pagar um pouco pra não jogar muito mais fora. Essa noção deveria ser simples, mas na minha experiência, pouca gente parece entender que mais vale a pena jogar fora 2 semanas do que se comprometer cegamente com um projeto incerto que vai levar um ano.

Na cabeça de muita gente, como 1 ano tá longe, fica aquela sensação de “vamos indo, lá na frente a gente vê como faz”. Especialmente em tech startups que vivem de dinheiro de investimento, esse tipo de decisão errada acontece muito, porque afinal é muito mais fácil gastar o dinheiro dos outros. E mesmo quem tem que gastar do próprio bolso, fica apreensivo com essa noção de “jogar 2 semanas fora”. Só que não é “jogar fora”, é o mesmo que pagar um seguro.

Ninguém gosta de pagar mil reais, dois mil reais, todo ano, que ao final do ano, parece que não serviu pra nada. Só que se durante esse ano tiver um acidente, e você atropelar e machucar alguém, agora não é dois mil reais que vai custar, vai ser 100 mil, 200 mil reais. Quem faz economia porca e fica de bravata achando que “não precisa, não vai acontecer”, é o primeiro que se envolve em acidentes e depois fica falido. Em projetos é a mesma coisa. Se for coisa que você já faz várias vezes antes, o risco é baixo, já sabe o que tem que fazer, tem noção de quanto vai custar e mais ou menos sabe o que pode ou não dar errado, então consegue ir em frente. Mas se nunca fez, é melhor fazer um teste antes de decidir.

E caindo no dia a dia de programação, é esse o mesmo argumento de porque falamos que todo programador deveria fazer, no mínimo, testes unitários de tudo que está trabalhando. Toda nova funcionalidade, deveria ser coberta de testes. Toda correção de bugs, deveria começar com um teste que simula o bug, pra que já comece falhando, e você sabe que corrigiu quando esse teste passa. Não só isso, esse bug em particular não vai acontecer de novo. Todo teste que você começa escrevendo antes de fazer o código, é como uma mini prova de conceito antes de tentar fazer uma coisa que não tem muita certeza. Se não tem certeza, comece escrevendo um teste.

Muitas pessoas já me pediram pra fazer um video sobre testes, mas eu realmente não tenho vontade, porque testes é um assunto que tem já toneladas de documentação, livros, tutoriais, cursos, blog posts, PDFs gratuitos online, pra cada linguagem diferente, pra cada framework. Testes não é um troço que você aprende em 5 minutos e faz igual pra sempre. É um conjunto de técnicas. O ideal é um junior parear com alguém mais experiente e aprender na prática: quando precisa fazer, e com que nível de detalhes. É muito importante que sua equipe tenha pelo menos uma pessoa mais experiente que entende a importância de ter testes e oriente os demais a fazer.

Deixa eu fazer o sales pitch de 2 minutos de porque todo programador deve fazer testes, de porque nenhum pull request pode ser mergeado sem testes, e porque uma pessoa que se diz sênior e é contra fazer testes, por definição, não deveria se considerar sênior. Toda regressão é tempo e dinheiro jogado fora. E o que é uma regressão?

Regressão é exatamente o que o nome diz. Se até este momento, digamos que alguém de QA testou tudo e tinha zero bugs. Alguém me faz um pull request que ficou trabalhando sem integrar por duas semanas. Sem testar. E dá merge na master. Faz deploy, e o que acontece? Surgem um monte de bugs. Não só na funcionalidade que ele tava trabalhando, mas em outros lugares que antes funcionava. Esse amador regrediu o trabalho de todo mundo. Tudo deu passos pra trás.

Agora o certo é dar revert nesse pull request, reverter mesmo. Só que esse pull request não tem mais como voltar atrás, porque dar deploy, ele alterou o schema do banco de dados e não tem como voltar mais ao schema anterior sem um grande downtime. Um desastre. E, claro, tenha certeza que esse indivíduo fez esse deploy na tarde de sexta-feira. Lógico. Cancela o happy hour porque a noite de sexta vai ser longa, fim de semana adentro, pra consertar essa cagada.

O fluxo é simples: todo programador, seja fazendo testes-antes ou testes-depois, quando diz que concluiu seu pull request, também adicionou um mínimo de testes, fez rebase com a master, e indicou pra equipe que tá tudo pronto. Alguém da equipe sempre deve avaliar esse pull request, normalmente alguém mais experiente. Pelo menos pra bater o olho e ver que não tem nada que parece muito mau feito ou muito fora do lugar e, principalmente, se tem testes. Se não tiver, já rejeita.

Se for uma equipe minimamente bem equipada, está usando repositórios privados de Git seja num GitHub ou GitLab. Ambos tem suporte a rodar testes automatizados num serviço separado. Nesse momento ele já puxou o que está nesse pull request, subiu um container de docker, e executou os testes automatizados do projeto. E quando o avaliador for checar o pull request, já vai saber inclusive se os testes passaram ou não. O GitLab tem a própria ferramenta que é o GitLab CI, de Continuous Integration. Tem diversos serviços externos que integram com GitHub como CircleCI, Travis CI, Semaphore e outros. É super simples configurar no seu projeto e não vejo nenhum motivo pra não usar.

Se o pull request parece que está ok, e o CI diz que os testes passaram, só agora é permitido fazer merge desse código novo na master. No mínimo, sabemos que as funcionalidades que funcionavam antes, cobertas com testes, continuam funcionando depois, mesmo com a inclusão desse código novo. É um bom indicativo pra toda a equipe que as coisas estão andando pra frente, e não ficando com débito técnico acumulado pra trás. Eu vi um tweet alguns dias atrás, de alguém que tava relatando como um idiota da equipe resolveu atualizar a versão do Java, acho que do 16 pro 18 e fez deploy pra produção. Óbvio que deu pau. Óbvio que o pau apareceu na sexta-feira.

Tem idiota que acha que porque usa uma linguagem compilada, com tipagem estática como Java, não tem problema não ter testes, porque se tudo compila, obviamente é porque funciona. Não tem nada que é mais certificado de júnior, do que pensar assim. Ahhnnnn como assim? Voltando ao exemplo de software livre. Vamos ver o projeto do navegador Firefox. Sabe Firefox? Sim, aquele Firefox. Eu baixei o código aqui na minha máquina. Firefox é feito na maior parte em C++, um pouco de Rust, um pouco de Javascript. É um navegador bem estável e quem usa acho que raramente tem algum problema dele renderizar errado, crashear ou coisas estranhas assim.

Se você é desenvolvedor de front-end, certamente já usou o Developer Tools certo? Pra debugar o que está programando. E esse Developer Tools tem uma suite de testes, pra garantir que toda nova versão, antes de lançar pra você baixar na sua máquina, passa todos os testes e não introduz nenhuma regressão. Ou seja, tudo que funcionava numa versão continua funcionando na mais nova. No repositório de código fonte, só rodar mach test devtools/* e olha só, abre a versão que acabei de compilar direto do código fonte e roda uma suite de testes de integração, simulando cada funcionalidade do Developer Tools. É assim que a Mozilla garante que código novo não introduz regressões óbvias.

Se der uma fuçada no código, olha só, cada diretório tem um sub-diretório de testes. E muitos deles tem testes específicos pra bugs que foram reportados. Assim eles garantem que bugs corrigidos também não vão aparecer do nada de novo. Bugs que foram corrigidos e aparecem de novo porque não tinha um teste pra cobrir, se chama “jogar dinheiro fora”. Porque tem que corrigir mais de uma vez. Ao longo do tempo, você está perdendo tempo, dinheiro, eficiência, e mercado pra outro projeto que vai fazer melhor que você com menos recursos.

Tem gente que acha que porque é programador front-end, não precisa se preocupar com testes. Acho que todo mundo gosta do projeto React do Facebook, quer dizer “meta”, certo? Eu baixei aqui o código fonte da biblioteca React. E olha só, se rodar yarn test, o React tem uma suite de testes feita em Jest. Pelo mesmo objetivo. Mais de 7 mil testes unitários garantem que quando você atualiza o React, não vai quebrar tudo.

Sabe aquela biblioteca de estilos, o TailwindCSS? Um amador poderia imaginar que é só uma coleção de CSS, obviamente não precisa de testes, certo? Errado. Eu baixei o código fonte do Tailwind e adivinha, se rodar yarn test, mais testes unitários em Jest. Quase 900 testes unitários, fora checagens com eslint que por acaso deu alguns erros. Eu baixei do branch principal, ainda estão mexendo e na próxima versão esses bugs serão corrigidos. Mas está claro o que funciona e o que não funciona pra quem está contribuindo.

Bah. Esse povo de front tá muito fresco. Ficar fazendo testes é coisa de hipster. Certamente povo de Python, mais calejado, mais raíz, não se importa com essas besteiras. Por isso eu baixei aqui o código fonte do framework Django. E olha só, tem um diretório chamado tests e dentro eu posso rodar esse script chamado runtests.py. E lá vai ele rodar centenas de testes pra garantir também que versões novas do Django não tá quebrando nada que já funcionava antes. Mais de 16 mil testes. Passando bonitinho.

Foda-se povo de Javascript e Python. Vamos mudar pra PHP. PHP sempre foi conhecido por ser Quick and Dirty, rápido e sujo. Código raíz. Programador Cowboy que programa orientado a gambiarra. POG-zão na veia. Eu baixei aqui o código fonte do framework Laravel que é um dos mais usados hoje. Só que não. Eu posso rodar composer exec phpunit e olha só, quase 8 mil testes, de novo, pra garantir que a versão mais nova não introduz nenhuma regressão. Por acaso falhou, povo ainda tá mexendo, próxima versão estável certamente já vai ter corrigido esse bug. Mas nós sabemos que tem o bug, porque tem suite de testes.

Aliás, sabe o editor de textos mais usados por programadores hoje? O tal do Visual Studio Code? Provavelmente até você assistindo que não gosta de testes aí usa pra fazer seus códigos porcaria. Eu baixei o código fonte também e tem testes automatizados rodando yarn smoketest, que segundo a documentação deles, é rodado antes de gerar o binário final que você baixa pra instalar. Igual o Firefox, tem testes de integração onde abre o aplicativo e vai testando cada funcionalidade que a gente aceita que simplesmente funciona em toda nova versão. E tudo só funciona, porque tem testes pra garantir isso.

E voltando ao Firefox. Parte dele é feito em Rust. E pra você, seu infeliz, que ainda acha que só porque o código compila, tá tudo bem? Não era o Rust que tem o tal compilador mais inteligente de todos os tempos? Que muita gente acha que é mágica e garante não só binário super performático como se tivesse sido feito em C e sem bugs de gerenciamento de memória e problemas de segurança? Muita gente só falta dizer que o compilador escreve o código pra você, de tão bom que ele é. Certamente, se o código em Rust compila, não precisa de testes, certo?

Bom, eu baixei o código fonte da biblioteca Tokio, que é o framework pra desenvolvimento assíncrono em aplicativos feitos em Rust. Todo projeto Rust acompanha um arquivo Cargo.toml, assim como todo projeto Javascript acompanha um package.json. E assim como existe npm ou yarn, em Rust temos o comando cargo. cargo install é equivalente a um npm install. E adivinha, o próprio cargo, ferramenta padrão que já vem com o Rust, tem essa opção test. E o que isso faz? Vamos ver. Só executar cargo test. Olha só ele rodando a suite de testes da biblioteca Tokio.

Ou seja, nem mesmo um projeto em Rust, que é armado com o compilador que é considerado a obra prima dos compiladores, evita os autores do Tokio de não fazer testes. Aliás, pode ver, ele sai rodando centenas de testes, não é um ou dois. Ahhh mas só de compilar já devia ser suficiente … não, sua múmia paralítica, os criadores do Rust armaram o Cargo pra rodar testes. Você acha que você, logo você, entende mais do que os criadores do Rust?

E você que é de Java e também detesta testes, que tem essa noção atrasada de porque o Java compila, tem tipos estáticos, então se compila tá tudo certo. Você que acha que só linguagens dinâmicas não compiladas como Ruby ou Javascript que precisam de testes. Sabe onde nasceu o conceito de TDD? Foi com Kent Beck, que fez o primeiro jUnit, em Java. Desde os anos 90 a gente sabe que só porque alguma coisa compila, não quer dizer que funciona. Só porque compila não significa que bugs não foram introduzidos. E por ficarem cansados de toda hora ter que correr atrás do próprio rabo, de ficar corrigindo coisa que já funcionava, que os agilistas originais formalizaram o conceito de testes.

Aliás, falei de Java e não mostrei Java. Só de exemplo, baixei o código fonte de um dos frameworks web mais usados que é o Spring Boot. Rodando o bom e velho gradlew build olha só. Baixa todas as dependências, junto com a internet inteira duas vezes, e roda todos os testes automatizados na sequência. O build só é considerado ok se compila e os testes rodam sem erro até o fim. E são milhares de testes. Ué, mas não era só compilar que já tava garantido que funciona? Obviamente não.

Muito antes de existir o conceito de TDD a gente já fazia testes automatizados de um jeito ou de outro. Toda empresa de software madura faz testes. É por isso que seus programas e seu sistema operacional não quebram o tempo todo, toda hora. E mesmo com tudo isso, ainda assim bugs acontecem. Significa que se não tivessem todos esses testes, teríamos ordens de grandeza mais bugs em tudo. Novas versões iam demorar ordens de grandeza mais pra sair. Ia precisar de ordens de grandeza mais pessoas testando. Mas não. Hoje em dia quase todo dia algum programa que você tem instalado ganha uma versão nova, mas você raramente é incomodado. Bugs acontecem, mas são raros. E a razão disso é que todo software maduro, proprietário ou de código aberto, tem testes.

Veja meu blogzinho feito em Ruby on Rails. Ele é ridiculamente simples. Eu mesmo que fiz em 2012. Não lembro se foi em Rails versão 3 ou 4. De lá pra cá eu atualizei até o Rails 6 rodando em Ruby 3. Toda vez que sai versão nova da linguagem ou do framework, eu atualizo, pra ganhar as correções de segurança principalmente. Eu venho atualizando faz 10 anos. E toda vez atualizo as bibliotecas também. Mas diferente do tweet da pessoa que falou que o cara atualizou o Java e subiu pra produção. Antes eu rodo meus testes em Rspec. Se não passa, obviamente não subo. Faço pequenos ajustes quando precisa, se a API de alguma biblioteca mudou. Mas meus testes pegam a maior parte dos problemas. Uma vez por ano, gasto 30 minutos, atualizo as coisas e subo.

Ter testes não é burocracia, não é perda de tempo. É um seguro. Não fazer testes é a mesma coisa que dirigir sem seguro. Na maior parte do tempo, não parece ter muito valor mesmo. Sempre dá pra fazer tudo rápido, sujo e na gambiarra. Você se sente o herói de entregar as coisas rápido. Mas é inevitável, sua produtividade, e da sua equipe, vão gradativamente caindo. Porque mais e mais se perde tempo corrigindo bugs do que fazendo coisa nova. Em breve, a maior parte do seu tempo é só corrigindo bugs. E o que o amador fala? Ahhh, vamos mudar pro framework mais novo. Vamos mudar pra linguagem mais da hora. Quantos de vocês conseguiram manter e atualizar o mesmo sistema por uma década?

Não existe nenhuma linguagem inventada na história que só pelo fato de compilar garante que não precisa ter testes. Todo mundo que entendia isso já fazia testes de alguma forma. A gente fazia alguns scripts separados do código pra rodar partes que eram mais sensíveis se quebrasse, ou que sabíamos que sempre alguém fazia merda e quebrava. Era uma das coisas que separavam os amadores dos espertos. O que aconteceu foi que as comunidade ágeis deram nomes aos bois e criaram convenções e semânticas pra todo mundo falar a mesma língua. Mas não existiu uma data especial que divide antes, com zero testes, e depois, com testes. Foi gradual, onde décadas atirando no próprio pé naturalmente levaram os programadores mais experientes a chegar na mesma conclusão.

Enfim. O problema é que a maioria de vocês assistindo detesta fazer testes. A desculpa é perda de tempo. Mas a verdade é porque vocês não conseguem fazer. Vocês acham que ninguém percebe. Todo mundo que se sente incapaz de fazer alguma coisa, tenta denegrir esse alguma coisa. E é óbvio, não sabe fazer porque nunca faz. Assim como tudo em programação, fazer testes depende de treino e prática. Não existe nenhum livro ou curso que dá pra ler e automaticamente sair fazendo testes perfeitos.

Você que é front, assistiu um curso e já saiu criando interfaces do nível de complexidade de um Canvas instantaneamente? Ou precisou de semanas e semanas apanhando de CSS obscuro? Ou você que é back, só leu um tutorial e já saiu criando APIs perfeitas em GraphQL integrado com backend de Firebase? Em 5 minutos já saiu codando como se não houvesse amanhã? Duvido.

Não adianta ficar só procurando coisa pra ler. Precisa praticar. Assim como tudo que já fez, todos os seus primeiros testes vão ser uma bosta. Mas é assim que começa. Eu citei vários projetos de código aberto. Dá uma olhada nos testes deles pra se inspirar. Tem centenas de outros projetos mais parecidos com o que estiver trabalhando agora. Baixa e lê os testes deles. Copia. Altera. Testa. Joga fora. Começa de novo. Repete. É assim mesmo.

Outra desculpa é falar que o projeto já tá faz meses ou até anos sem nenhum teste. É o cúmulo da preguiça ouvir isso. Ótimo. Faça você o primeiro teste. Pelo menos essa uma funcionalidade que acabou de entregar, está coberto e vai ser mais difícil de aparecer bug aleatório pela falta de atenção de outro programador depois. E se alguém pisar em cima do seu código, só de rodar esse um teste, dá pra saber que quebrou, quem foi, em qual commit, e corrigir mais fácil. De 1 teste em 1 teste, a cobertura naturalmente aumenta.

Alguém reportou um bug? Abriu um ticket? Faça o teste que simula o bug reportado. Agora corrige. Pronto, esse é 1 bug que dificilmente vai aparecer de novo. E olha só, do nada, você começou a andar pra frente em vez de ficar só olhando pra trás. E total de cobertura? Precisa ser 100%? Isso é outra pergunta idiota que sempre aparece numa discussão de quem é desleixado. Foda-se. Você não fez nem 1% ainda, pra que quer discutir 100%? Não interessa. Faz 50%, faz 500%. Só, faz, a, porra, dos, testes.

O que acontece é o seguinte. Sua equipe tem 3 pessoas. Cada um consegue pegar 2 ou 3 tarefas do backlog por semana. 6 a 9 tarefas entregas toda semana. Se o sistema começa a ser usado por usuários de verdade, rapidamente começam a aparecer bugs e problemas. Surge 1 ticket, 2 tickets. De repente a equipe só consegue entregar 3 a 6 tarefas por semana, porque precisa resolver bugs urgentes. Mas continua entregando coisas. Só que essas coisas novas, causam mais bugs. Na próxima semana a produtividade caiu pra 2 a 4 tarefas. E o número de bugs aumenta em vez de diminuir. Em pouco tempo, a equipe male male entrega 1 ou 2 tarefas novas, o resto do tempo é só resolvendo bugs.

E qual a decisão do gerente do projeto? “Ah, é normal, precisa contratar mais programadores.” Ele convence a diretoria. Dobra a equipe. E voilá, a equipe volta e entregar 6 a 9 tarefas novas por semana. E todo mundo continua sem se importar com testes ou qualidade em geral, é crunch, só entregar e entregar. O volume de código só aumenta, ninguém joga nada fora, vai só acumulando débito técnico. Mais código novo significa mais bugs. No final acontece a mesma coisa, nas semanas seguintes a produtividade cai pra 3 a 6 tarefas, depois pra 2 a 4 tarefas, e de novo, a nova equipe, com o dobro de integrantes, tá male male entregando 1 ou 2 coisas novas por semana, o resto é só apagando incêndio.

Digamos que todo mundo é ruim em testes. Se lá no começo tivesse decidido entregar tudo com testes, em vez de 6 a 9 tarefas, a equipe estaria entregando só de 4 a 6 coisas, talvez menos. Parece bem ruim. A diferença é que vai ser 4 a 6 TODA semana. Surgiu um bug novo? O programador que pega pra corrigir adiciona testes, e segue todo o processo que descrevi antes. Esse bug em particular não aparece de novo. Entregou coisa nova? A suite de testes garante que o que tinha antes não quebrou por conta disso. E assim, toda semana, de forma sustentável, a equipe entrega 4 a 6 tarefas. Não é o máximo de 9, mas não cai pra 1 ou 2.

Daí a empresa decide contratar mais gente e dobra a equipe. Mas a equipe é diligente e treina os novos integrantes sobre a importância de qualidade. A produtividade quase dobra, de 4 a 6 pra 8 a 10 tarefas. A produtividade só dobra se todo mundo segue o protocolo, ninguém pisa no calo de ninguém, e tudo que já foi feito e testado continua funcionando no futuro. Todo upgrade de bibliotecas e correções de segurança tem garantia que o sistema continua funcionando, porque a suite de testes tá passando. Daí nenhum deploy de upgrade feito na sexta feira causa desastre que vai precisar varar fim de semana corrigindo. Olha só que mágico.

Muita gente vai inventar um monte de desculpas pra não fazer testes, e eu garanto que pra cada desculpa nós já temos soluções. Nenhum programador precisa rodar a suite de testes o tempo todo se essa suite demora muito pra executar. Basta rodar alguns poucos ao redor do trabalho que está fazendo naquele momento. Daí sobe um pull request que vai ser pego por um GitLab CI e esse servidor de CI é quem vai rodar a suite inteira de testes. Não só isso, se a suite passar, esse CI pode fazer CD, que é continuous deployment, e automaticamente subir em ambiente de staging e notificar a equipe de QA.

Obviamente eu não posso mostrar projetos confidenciais dos meus clientes, mas posso mostrar esse projeto interno que nós usamos. Olha um pull request. Se olharmos o que mudou podemos ver que além do código, temos ajustes em specs também, que são testes. Quando o desenvolvedor subiu o código, o CI pegou e iniciou o job pra rodar os testes. Nesse caso levou pouco mais de 5 minutos. Passou com sucesso e, lógico, só porque todos os testes passaram não significa que não tem nenhum bug, só que não tem nenhum bug muito óbvio. Mais do que isso, no nosso caso tem configurado também checagens de segurança. No ecossistema Ruby temos coisas como Brakeman, que avalia o código por buracos de segurança conhecidos como injections.

Essa aplicação sobe no Heroku, que tem uma funcionalidade chamada review apps. Podemos ter um deployment separado de testes pra cada pull request que ainda está aberta. Justamente pra alguém conseguir testar de verdade antes de aprovar. Um review app é um ambiente de staging, só que isolado pra cada pull request. Dá pra ter dezenas de review apps em paralelo. Assim não precisa ficar acumulando e integrando tudo no mesmo ambiente de staging pra testar, o que seria uma zona. Testa tudo isolado. Vai aprovando no ritmo do responsável pelos testes. E no final, quando estiver tudo testado, aprovado e mergeado no branch principal, daí faz um deployment pra produção aqui do lado.

Neste exemplo, no dia que fui tirar foto de tela, não tinha nenhum pull request aberto. Mas eles apareceriam listados aqui. Cada um com uma URL separada de testes. Esse é outro motivo de porque eu sempre recomendo Heroku. Ele não é o mais barato, mas esse tipo de recurso facilita o fluxo de trabalho em ordens de grandeza. Só as horas de desenvolvimento que se economiza de cada desenvolvedor já se paga.

Enfim, uma vez cada pull request de cada desenvolvedor sendo aprovado, tudo vai sendo integrado no branch principal e podemos fazer um deploy de tudo integrado pro ambiente de staging. Agora o pessoal de QA pode fazer o trabalho deles direito, que é testar as coisas novas, e não ficar retestando tudo de novo que já funcionava antes. Todo report de bugs volta pro programador, que faz a correção e ajusta os testes pra cobrir os casos que não tinha pensado.

Com o pull request foi ajustado, os testes passam, QA já viu em staging, o sênior da equipe pode dar a última olhada e fazer o merge na branch principal. E aí alguém de devops ou alguém responsável pela produção pode pegar o que está na branch principal e fechar uma versão pra produção, com a segurança de saber que se está na branch principal, então está funcionando corretamente.

E se estiver usando Heroku, ainda tem uma facilidade extra. Digamos que todo mundo fez tudo direitinho, mas mesmo assim surgiu um bug que só aparecem em produção. Basta ir nesta aba de atividades e clicar em roll back pra voltar pra versão anterior. Heroku é caro, mas é nessas horas que ele se paga. Medo de deploy na sexta-feira só existe em equipes disfuncionais que não fazem esse básico que acabei de falar.

Falando em disfuncional, o maior desafio em toda equipe de projetos, é coordenar a comunicação. Ao ter um repositório de códigos como Git, um processo de testes de integração contínua, pareamento entre sêniors e juniors pra compartilhar conhecimento, e um protocolo como de pull requests, estabelecemos um conjunto simples e objetivo de entendimento nessa equipe. Não seguir esse protocolo é um desrespeito à equipe. Você não programa pra você mesmo, você contribui com sua equipe. O importante não é andar rápido, o importante é não estragar o que já funcionava.

Da mesma forma, ninguém deve sair adicionando coisas no projeto que ninguém está sabendo. Por isso que no mundo ágil se inventou os tais rituais como de planejamento e revisão. Rituais não devem ser obrigações, mas pontos de coordenação. Se os rituais estão sendo meramente pras pessoas aparecerem mas não participar, então não servem pra nada e devem ser eliminados e repensados. Esse é um ponto não-técnico que não quero tentar detalhar demais, mas preciso falar de um ponto específico: estimativas.

Se tem uma coisa que programador odeia fazer mais do que testes é estimar tarefas. Já disse isso em outros videos, mas existem duas palavras que todo mundo não-técnico confunde: estimar e prever. O programador estima, mas os gerentes ou diretores acham que receberam previsões. Estimativas são ordens de grandeza, não está certo nem errado. É uma ordem de grandeza. Previsões sim, é pra serem precisas. Quando um programador diz que pode levar uns 2 ou 4 dias, é isso que pode levar, 2 a 4 dias. Talvez leve 5. E aí o gerente que achava que tinha uma previsão na mão, fica puto, porque tava esperando 2 dias, recebeu em 5 e quer sair chutando tudo. E é isso que eu chamo de um idiota.

Eu acho que todo gerente de projetos deveria gastar um tempo movimentando o próprio dinheiro no mercado financeiro. Comprar e vender ações, ou opções, ou criptomoedas, não importa. Porque todo mundo gostaria de saber pra onde vai o mercado, se vai subir ou se vai cair. É impossível acertar 100% do tempo. Se alguém soubesse prever isso, quebraria o mercado financeiro. O máximo que podemos fazer é dar chutes educados. Estimativas. A gente tenta acertar, comprar na baixa, vender na alta. Ou no mínimo planejar pra alta e se proteger da baixa. Criamos contingências, e sabemos que é impossível ganhar sempre. O máximo que podemos fazer é tentar minimizar perdas. E as perdas nunca vão ser zero.

Gerenciamento de projetos é a mesma coisa. Um gerente inteligente não se interessa em tentar prever cada tarefa individualmente. Ele observa o movimento geral da equipe e do produto. Tá em tendência de alta de produtividade? Baixa de produtividade? Tem como influenciar a baixa? Qual é o obstáculo? Algum diretor deu carteirada e quebrou o planejamento? Alguém ficou doente? Um bom gerente está numa posição que um analista financeiro não tem: de influenciar as tendências.

Lógico, quanto mais um programador ganha experiência e tem mais segurança no que realmente sabe e o que não sabe, mais e mais suas estimativa se aproximam de previsões. Ele já tem uma boa noção de quanto tempo leva a maioria das coisas. Quanto mais inexperiente, mais longe vai ser essa estimativa. Faz parte do crescimento profissional de cada um começar a quantificar suas próprias capacidades. Ninguém tem obrigação de “acertar” estimativas, mas claro, quanto mais precisas forem, mais todo mundo consegue confiar mais e mais em você. É uma das formas de subir na carreira. Entregar o que promete.

Tarefas, stories ou seja lá como quer chamar, são meras formalidades. Quanto mais curtas, objetivas, direto ao ponto forem, melhor. O objetivo não é um concurso de literatura onde todo mundo tem que fazer uma dissertação. A quantidade de palavras deve ser o suficiente pra que toda a equipe envolvida saiba no que está sendo trabalhado. Só isso. Tem quinhentos blog posts, livros e cursos tentando ensinar “a melhor forma” de escrever requerimentos. E a maioria é bullshit. Quer dizer, até faz sentido, pode ser usado como inspiração, mas não existe nenhuma receita que dá pra só seguir. Assim como testes e estimativas, escrever requerimentos também depende de prática. Estude o que se sugere, mas não siga ao pé da letra.

User Stories tem aquele formato idiota de “eu, como usuário, quero conseguir adicionar um produto no carrinho e ter o total do pedido, para poder pagar minha compra” ou algo assim. Pode ser, é bonitinho, tem o objetivo de forçar as pessoas a pensar em pra quem é a funcionalidade sendo feita, qual o objetivo e facilitar pensar na melhor forma de fazer. Tem coisa que precisa de mais detalhe que isso. Um protótipo de tela no Canvas. Um rascunho de conta de imposto. Tem coisa que nem precisa de tanto detalhe assim. Bugs costumam ser mais diretos “quando o usuário abre no firefox de mac, o box de items fica em cima do box de cartão e não dá pra digitar o código de segurança do fucking pedido e a fucking compra não finaliza”. Tá super claro.

Eu tive um cliente que o imbecil do CTO mandava todo programador descrever em detalhes como ia programar, antes de escrever uma linha de códigos. Tinha que listar que classes novas ia criar, com que métodos, com quais nomes. Era a coisa mais idiota que eu já vi, só perde pra época que povo achava que precisava fazer diagramas de classe UML precisos meses antes de escrever uma linha de código. É idiótico. É da época que falei que se achava que programador era só pedreiro e havia uma forma mágica de descrever tudo, antes de escrever o código. É uma noção boçal.

O resumo é simples: a descrição deve ser a mais concisa, com o menor número de palavras possível. A equipe deve conseguir se reunir e em pouco tempo entender o que precisa ser feito, quem vai fazer, quem precisa de ajuda. O gerente, ou Product Owner, e o equivalente tech lead ou programador mais sênior, deveriam estar alinhados. Daí quando seja lá qual programador entregar o pull request praquela funcionalidade, o tech lead consegue avaliar rápido e mandar pro QA. O PO e o QA precisam estar alinhados, pra ver se o que foi entregue resolve o que se queria resolver.

Burocracia e formalidades em excesso aparecem em empresas onde esses personagens tem preguiça de conversar ou pior: não sabem o que estão fazendo. Porque se soubessem, poderiam ir direto ao assunto. Toda burocracia em excesso é defendida por aqueles que não sabem o que estão fazendo, porque aí podem usar a desculpa de “mas, mas, eu segui os procedimentos, a culpa não é minha”. Toda burocracia é uma muleta pra cabideiro que não deveria estar ocupando as posições que estão ocupando. É assim simples.

Voltando pra estimativas. Não existe nenhuma fórmula nem procedimento que, dado uma descrição em texto de um caso de uso, ou user story ou seja lá o que for, chega num número de horas ou dias exatos pra resolver essa tarefa. Cocomo e outras bullshitagens são lixo. Não tem como. Só a experiência dos programadores envolvidos é capaz de dar uma ordem de grandeza, cuja qualidade vai ser proporcional à experiência da equipe. Se a equipe for super experiente, mesmo assim vai ser uma ordem de grandeza.

Não tem nada mais retardado do que gente que pega esses números de estimativas, número de horas realizadas, vai pondo num gráfico e fica tentando derivar coisas desses números, fazer integral, aplicar fórmulas. Só porque se tem números, não signfica que existe cálculos que dê pra fazer. Eu posso sair jogando dados, colocar todos os resultados num gráficos e gerar um monte de conclusões. É assim que nasce pseudo-ciência, numerologia, astrologia e todas essas logias idiotas. Estimativa é um chute. Estimativas nunca estão erradas, porque não são previsões. Fazer contas com esses números não faz nenhum sentido.

Dá pra saber que vai ser perto de 6 meses mas menos de 1 ano. Agora, se vai ser 5 meses, 2 semanas, 4 dias e 5 horas, exatamente. Isso é impossível. Gastar horas tentando estimar tudo é um exercício de futilidade. Não perca tempo tentando prever com exatidão. Aprenda a lidar com ordens de grandeza. Simplesmente escreva o que se sabe que realmente precisa fazer. E nem tente detalhar 6 meses de trabalho de uma só vez. É inútil. Descreva o curto prazo em detalhes, 1 mês, no máximo 2 meses de trabalho. Tenha a direçao do longo prazo em mente, mas ajuste enquanto vai andando. Deixe a equipe se dividir em quem faz o que. E siga o que falei até agora sobre pull requests e merge.

Mesmo sem ter estimativa nenhuma, você como gerente ou como qualquer membro da equipe vai ver que numa semana a equipe entregou 10 tarefas, stories ou seja lá como quer chamar. Na semana seguinte, entregou 9. Na outra semana conseguiu entregar 11. Na semana seguinte entregou 7. O que o gerente ou facilitador dessa equipe começa a notar? Uma tendência. Parece que, seja lá como se descreve tarefas nessa equipe, eles conseguem entregar uma média de 8 a 9 unidades dessas “coisas”. E se for esperto, vai notar que quando entrega menos coincide quando sobe versão nova pra produção, daí o suporte recebe reports de bugs, que entram no backlog da equipe e isso diminui a quantidade de “coisas” entregues.

O gerente fala com o tech lead, que revê o processo, e vê que ele tava deixando passar pull requests com testes não tão bons. Ele pareia com o programador júnior que tava fazendo errado. Ensina na prática onde tava errando. E agora ele passa a produzir melhor. E é assim que uma equipe evolui, um passo de cada vez. Não é via metodologia, nem aumentando formalidades e burocracias, é via bom senso. Resolvendo problemas na raíz em vez de ficar inventando band-aids, ou pior, mais burocracias inúteis. E o principal: reorganizado a lista de coisas a fazer pra garantir que as coisas mais importantes estão sendo feitas primeiro e tudo que é opcional ou de pouco valor está no fim da lista. Assim, caso não dê tempo de fazer tudo, pelo menos você sabe que o mais importante foi feito.

Cuidado, não estou dizendo que não se deve perder tempo descrevendo tarefas ou que não se deve fazer estimativas. Estou falando que a formalidade não é tão importante, tem que começar a escrever e aceitar que vai estar mau escrito. Aceitar o feedback de que o programador fez errado porque do jeito que tava escrito ficou ambíguo. E aí vai ajustando os detalhes pra próxima vez, até o nível que faz sentido. “Ah, se tivesse descrito essa conta com um exemplo, ele teria entendido”, ou algo assim. Aceitar que uma estimativa nunca vai estar certa ou errada. É só uma referência. Não tente fazer projeções baseado em estimativas, porque isso só vai multiplicar um erro com outro erro.

Em vez disso veja em ordens de grandeza como falei. Seja lá como organiza as tarefas da equipe, veja, no geral, que tipos de funcionalidades ou correções de bugs a equipe entrega num certo período de tempo, como toda semana. Daí nem precisa perguntar pra equipe se o que tem no backlog cabe ou não na semana. Você já sabe essa resposta pela velocidade que já conhece. Quando sabe que não vai caber, seja honesto e faça seu trabalho: corte ou simplifique. Não tem mágica. Se não cabe, não cabe. Se tentar fazer caber, obviamente a qualidade vai cair. É onde vai vir o “se eu pular fazer testes, talvez caiba”. E quando se cede uma vez, isso vai acumular. Na semana seguinte já começa a vir a conta. E uma decisão feita no desespero numa semana, vai prejudicar todo o resto do andamento daqui pra frente.

Não existe almoço de graça. Toda vez que vai se deixando passar uma pequena coisa errada, isso vai acumulando. Em breve, vai estar tudo errado. Ser sustentável é exercitar disciplina. E não tem coisa mais maçante, mais entediante, do que ser disciplinado. Quando tudo é uma bagunça, é difícil elencar os problemas. Mas numa equipe disciplinada, fica fácil ver quem tá puxando a equipe pra trás. Sem ter a muleta da burocracia, fica fácil ver quem é a pessoa inconstante, aquele que promete demais, entrega de menos, e quando entrega outra pessoa precisa consertar. A equipe inteira sabe quem é essa pessoa. Eles devem ensinar, ajudar, mas quando a pessoa é resistente a trabalhar em equipe, ela deve ser removida. É assim simples.

A decisão errada é manter essa pessoa e contratar outra pra aumentar produtividade. Muitas equipes que eu já vi teriam a produtividade aumentada só de cortar os maus elementos, porque agora eles não precisam ficar consertando o que o mau elemento tá entregando de mau jeito. Automaticamente a produtividade aumenta, o stress diminui, todo mundo trabalha melhor. Uma coisa que aconteceu durante esse período que já passou de vacas gordas, com montes de empresas contratando gente ruim no atacado, é que em vez de aumentar a produtividade, eles prejudicaram a qualidade do produto e das equipes. Imagina um monte de gente ruim, fazendo o contrário de tudo que falei até agora. Só acumulou um monte de código porcaria que funciona em produção na força bruta, com alguns poucos hiper estressados, varando noite, consertando a porcaria que recebe.

Se a equipe não se importa com o que está entregando, nada do que eu falei até agora importa. E todo novo integrante, ao ver que ninguém tá realmente muito interessado, vai aprender do jeito errado: que o melhor é ligar o foda-se e fazer igual todo mundo. E é assim que um projeto entra em colapso, porque ninguém está ligando. Em empresas com dinheiro dos outros demais, é o que mais acontece. Mas se sua empresa realmente depende do código sendo feito, sinto dizer, rapidamente todo mundo vai perder o controle. E daí pra frente é só cavar o buraco mais fundo.

De novo. Todo projeto é uma incerteza, especialmente nos primeiros dias. Especialmente se for uma equipe nova, recém constituída. Precisam aprender a trabalhar juntos ao mesmo tempo que precisam entender o que diabos vão construir. É uma montanha de incertezas. Por isso o ideal é garantir que o básico do básico está garantido: que pelo menos o que está sendo entregue vai continuar funcionando ao longo do tempo. Exercitem o processo de testes, pull requests, integração contínua, deployment em staging. Daí comecem a ver até que nível de detalhes realmente as tarefas precisam ser definidas. E vai ajustando.

Não tente estabelecer regras escritas em pedra no dia um. É inútil. Comece no equivalente a fazer rascunhos. Avalie se o rascunho está num nível de detalhes suficiente. Se não estiver, vai ajustando. O PO, o UX, precisam ir refinando isso. Daí o QA e o suporte precisam também ir refinando o processo de testes. Esse processo volta pra equipe de desenvolvimento, que reflete se está cometendo deslizes técnicos que poderiam evitar bugs óbvios. Todo mundo ainda estava crú em fazer testes, e aos poucos vai aprendendo a realmente testar os casos que interessam e deixar de lado os casos que não precisa. Naturalmente vão se acostumando a saber até onde precisa ou não cobrir determinados tipos de funcionalidades.

Sério. Exercite sua equipe em usar Git direito, em usar os recursos de testes que certamente já tem no seu framework. Como falei, Rails tem, Django tem, Laravel tem, Spring Boot tem, Express tem, React tem. Todo mundo tem suporte a testes que vocês só escolheram não usar. Só que vocês não são seres ungidos que fazem código sem erros. Pelo contrário, todo programador vai mais fazer erros do que acertar. Especialmente se for júnior. É normal. Só que hoje todo mundo deixa esses erros acumularem no repositório, porque os deploys pra produção acontecem só 1 vez por mês, ou 1 vez por bimestre. Daí toda vez que faz deploy fica todo mundo apreensivo, porque já sabe que vai dar merda. Todo mundo sabe que empurrou os problemas com a barriga. Daí o dia do deploy é o dia da pizza na madrugada. Todo mundo correndo atrás do próprio rabo pra consertar os erros que vão aparecendo. Um caos.

Não seja esse clichê. Faz direito um pouco todo dia pro dia de deploy em produção ser só mais um dia normal, tedioso, sem nenhuma adrenalina, porque todo mundo tem segurança que tá tudo testado e funcionando. Fazer as coisas direito é muito chato, eu sei. Deixa pra fazer código porco gambiarrado nos seus projetinhos pessoais. Mas em projeto dos outros, aprenda a ser profissional. Imagina se seu médico também fizesse programação orientada a gambiarras sem testes como você faz. Imagine se o médico do seu filho fizesse como você faz. Acho que não ia gostar né? Cresce, e age como profissional. Se ficaram com dúvidas, mandem nos comentários abaixo. Se curtiram o video deixem um joinha, assinem o canal e compartilhem o video com seus amigos. A gente se vê, até mais!

DESCRIÇÃO

Gestão é um mundo enorme e complicado e por isso muito iniciante tem muita dificuldade de entender o que realmente precisa fazer. E no video de hoje resolvi falar um pouco sobre a arte de gerenciar e alguns pontos que eu pessoalmente considero importante depois de 30 anos gerenciando projetos de uma forma ou de outra. Não é o guia definitivo nem nada disso, só um pequeno empurrão que pode trazer alguns insights, seja você gerente ou não.

Conteúdo

• 00:00:00 - Intro
• 00:01:47 - O problema com histórias
• 00:02:39 - PMI
• 00:04:52 - Onde aprender?
• 00:06:30 - O que é gestão?
• 00:08:47 - O mais difícil em gestão
• 00:10:54 - A trindade de projetos
• 00:14:02 - PO e stakeholders
• 00:17:50 - Jovem demais
• 00:20:36 - Cicatrizes de guerra
• 00:23:26 - Filosofia Peaky Blinders
• 00:26:13 - Hardware vs Software
• 00:30:09 - Tipos diferentes de software
• 00:32:39 - Tomando decisões
• 00:35:01 - Motivação
• 00:36:20 - Alguns livros
• 00:37:10 - Métricas
• 00:40:19 - Comunicação
• 00:42:54 - Cortando na carne
• 00:44:12 - Knowledge Workers
• 00:48:10 - Evoluindo as pessoas
• 00:52:28 - Conclusão
• 00:54:02 - Bloopers

Links

• A Arte da guerra: Os treze capítulos originais (https://www.amazon.com.br/Arte-guerra-treze-cap%C3%ADtulos-originais-ebook/dp/B00BBFSD3O/ref=sr_1_1?__mk_pt_BR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=GEA04AJZ22PV&keywords=sun+tzu&qid=1655163041&s=digital-text&sprefix=sun+tzu%2Cdigital-text%2C186&sr=1-1)
• Managers Not MBAs: A Hard Look at the Soft Practice of Managing and Management Development (https://www.amazon.com.br/Managers-Not-MBAs-Management-Development-ebook/dp/B0064R22Q8/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=1655153736&sr=1-1)
• The Psychology of Computer Programming: Silver Anniversary eBook Edition (https://www.amazon.com.br/Psychology-Computer-Programming-Anniversary-English-ebook/dp/B004R9QACC/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=1655125738&sr=1-4)
• Peopleware: Productive Projects and Teams (https://www.amazon.com.br/Peopleware-Productive-Projects-Teams-English-ebook/dp/B00DY5A8X2/ref=sr_1_1?__mk_pt_BR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=XU8MUZWUAH9M&keywords=peopleware&qid=1655159919&s=digital-text&sprefix=peoplewa%2Cdigital-text%2C215&sr=1-1)
• The Balanced Scorecard: Translating Strategy into Action (https://www.amazon.com.br/Balanced-Scorecard-Translating-Strategy-English-ebook/dp/B000SEIJPG/ref=sr_1_2?__mk_pt_BR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2BBLX7HO86ELX&keywords=balanced+scorecard+kaplan+norton&qid=1655161125&s=digital-text&sprefix=balanced+scorecard+kaplan+norto%2Cdigital-text%2C173&sr=1-2)
• The New New Product Development Game (https://hbr.org/1986/01/the-new-new-product-development-game)
• Soldier To soldier || Thomas Shelby to Mr. Churchill || Peaky Blinders | @JARAEditz (https://www.youtube.com/watch?v=H-DF8nzcjlM)

SCRIPT

Olá pessoal Fabio Akita

Se tem um papel que é difícil de definir e também de evitar em qualquer empresa de tecnologia é o do famigerado “gerente”, seja um product owner, seja um scrummaster, seja um chapter leader ou seja lá que nome andam inventando agora. Todo mundo reclama quando eu fico cagando regra, mas já aviso que esse episódio vai realmente ser uma grande cagação de regra. Esse episódio é pra você que é gerente, ou quer ser gerente ou se viu obrigado a atuar como gerente. Todo mundo, em algum momento, vai passar por isso. Depende de você decidir se vai abraçar a oportunidade ou fugir. Porque sempre é mais fácil ser o reclamão do grupo, mas ninguém quer ser o cara que vai realmente resolver o problema.

O objetivo deste episódio não é ser um guia definitivo de tudo que existe sobre gestão mas só apresentar alguns pontos que eu pessoalmente considero importantes quando se discute esse assunto. Pontos que se você já não gerenciou diversos tipos diferentes de projetos, talvez não seja tão óbvio.

(…)

Tenho que deixar claro que tudo que eu disser hoje não são verdades absolutas. O problema de projetos e administração em geral é que a gente vê resultados ao longo do tempo. E durante esse tempo prestamos atenção em alguns poucos pontos que parecem importantes pra gente e ignoramos dezenas de pequenos pontos que pra mim pode não parecer importante porque são coisas que eu faço sem pensar, mas pra outras pessoas não são óbvias porque elas não estão acostumadas a fazer. Daí eu conto uma história que vai ser incompleta e por isso é difícil de replicar. O mesmo vale pra versão de outras pessoas. Por isso que ninguém vira gerente só assistindo videos ou lendo meia dúzia de histórias.

Se duas pessoas contarem a mesma história sobre um mesmo projeto, as histórias vão ser diferentes e ambas vão ser incompletas. É impossível resumir tudo que realmente foi importante num projeto que durou 12 meses em 12 minutos. Por isso valorizamos a tal da experiência. Parte da experiência são items que são fáceis de explicar, outra parte é implícito e difícil de colocar em palavras. São as várias pequenas decisões invisíveis que podem fazer a diferença no final. Portanto não, não tem nenhum livro que você possa ler que vai te ensinar essas coisas, só prática real, várias vezes, em cenários diferentes, prestando atenção em tudo que está fazendo e quais as consequências. Algumas vezes foram ações específicas que levaram ao sucesso, outras vezes foi literalmente a sorte de estar no lugar certo na hora certa. Não dá pra prever.

Falando em livros e teoria, uma cena que ficou famosa do meu video sobre o Guia de Aprendendo a Aprender foi quando rasguei meu certificado de PMP. Eu acho que expliquei isso lá mas vale repetir: eu quis dizer que certificados não significam nada. Colecionar papel pode ser um hobby, mas na prática é inútil. Porém não significa que eu não respeite o PMBOK.

Pra quem não sabe, existe um corpo de conhecimento documentado no Project Management Body of Knowledge, que é o PMBOK. É o material ensinado pelo PMI pra quem quiser se certificar como gerente PMP. É como se fosse uma enciclopédia e dicionário dos principais temas e termos de gestão como custos, escopo, comunicação. É o básico de conhecimento pra quem tem intenções sérias de se tornar um bom gestor. Mas como todos os cursos, ele não ensina como se tornar um bom gestor.

Pense no PMBOK como uma caixa de ferramentas. Só um bom carpinteiro sabe como usar quais ferramentas pra fazer bons móveis, mas só o manual de cada ferramenta nunca vai te tornar um bom carpinteiro. O PMBOK é a mesma coisa, tem chave de fenda, tem martelo, tem alicate, e como usar cada uma. Mas só isso é inútil pra você se considerar um gestor de verdade. Mas, vale a pena estudar pra saber o que todo mundo já sabe e não ficar tentando reinventar a roda.

No mundo de agilidade existem até alguns frankensteins como Agile PMI. Pelo mesmo motivo, isso não quer dizer muita coisa. Só misturar vocabulário de PMI com de Agile. E só mais um produto de marketing que consultorias tentam empurrar goela abaixo dos desavisados. O famoso “se der certo, é porque a metodologia é boa, mas se der errado, é porque você não seguiu exatamente como a gente falou, então paga a gente de novo pra corrigir”.

Eu falo disso no episódio de “Esqueça Metodologias Ágeis” onde explico como o termo Agile foi sequestrado e diluído por consultorias tentando vender a próxima grande moda da vez. E no episódio “O Guia Definitivo de Organizações” explico porque se você usa o tal modelo do Spotify, você não entendeu o modelo do Spotify. Em ambos os episódios explico o básico sobre a evolução e filosofia de organizações, então recomendo que assistam depois de terminar aqui porque não vou repetir o que já expliquei lá.

As maneiras formais de aprender sobre gestão é fazer faculdades como de engenharia de produção ou administração ou um MBA. E antes que comecem a me perguntar qual deveriam fazer, já respondo: tanto faz. Varia de pessoa pra pessoa e eu não te conheço pra dizer o que é melhor pra você, só você sabe disso e já digo que se você sequer consegue decidir o que é melhor pra você, como acha que vai decidir o que é melhor pro projeto dos outros? Já começa aqui o indicativo que você talvez não tenha inclinação pra ser um gerente.

Falando em MBAs, muita gente faz pelo prestígio do papel. Poder dizer que é um MBA. Tem quem coloque “virgula MBA” depois do nome no LinkedIn. Não posso criticar demais porque eu também colocava “virgula PMP” no meu, mas a vergonha alheia me fez tirar rápido. Também era 2003. Em 2022 já fica ridículo. Aproveite que ninguém viu e tira o seu porque é cringe. Nos anos 90 até 2000 alguns consideravam grande coisa. Hoje nem tanto. E se alguém se exibe por ser MBA, é um sinal vermelho. Que nem foto de Tinder com carrão atrás.

Tem quem confunda ser MBA com ser um bom gestor, e não existe correlação. Fazer MBA em instituições renomadas tem o objetivo maior de criar networking, não muito mais que isso. Se você está nesse caminho recomendo ler livros como do professor Henry Mintzberg e seu clássico “Managers, not MBAs”. Se certificar como PMP ou se formar como MBA é só mais uma forma de colecionar papel, e não garantia de se tornar um bom gestor. Eu ainda acho que se você puder estudar o material deles, é super válido. Só não pode achar que já sabe tudo e sim que pelo menos sabe o básico do básico.

Se eu fosse resumir o que é gestão em poucas palavras diria que é a capacidade de tomar decisões na hora que precisa, mesmo tendo informações incompletas. Alguém que não consegue tomar decisões e assumir responsabilidades nunca deveria gerenciar nada. Ser gerente não é obedecer ordens e preencher planilhas e relatórios sem fim. Qualquer idiota pode fazer isso. Isso não é um talvez, se seu dia a dia é só checar o backlog, checar as métricas, preencher nas suas planilhas e reportar, isso não é ser um gerente, é só ser um burocrata. E sim, existe a necessidade de burocratas em empresas grandes, mas não se iluda achando que está gerenciando porcaria nenhuma.

Vamos voltar ao conceito mais básico. Qual é o objetivo de uma empresa? Você pode inventar que é inovação, que é fazer diferença social e todo bla bla, mas isso é marketing. Não há nada de errado nisso porque toda empresa precisa construir sua marca em torno de algum tipo de marketing. Mas vamos tirar o marketing do caminho e ir na realidade nua e crua. O objetivo de toda empresa é dar lucro de forma sustentável. Nada mais, nada menos. Empresas que não dão lucro e ficam vivas ao custo de investimento é o que chamamos de “empresas zumbi”.

Mas não é “lucro a qualquer custo” como amadores pensam. Se o objetivo for dar lucro rápido sem nenhuma preocupação com futuro é simples: venda drogas. Dá muito mais dinheiro com muito menos trabalho do que tentar fazer uma tech startup. Só que o risco de você acabar preso ou morto é muito alto, por isso eu enfatizo o “sustentável”. Não é difícil ter lucro de vez em quando, é muito difícil sustentar esse lucro por anos a fio. Crescer 10%, 20%, todo ano, anos seguidos.

Outra definição importante é que projetos tem começo, meio e fim. Muita gente esquece disso, mas se alguma coisa não tem objetivo bem definido e não tem uma data final, não é projeto, é operação. Não existe projeto que não tem fim. E mais importante: na prática nem todo projeto precisa ir até o fim. Saber quando cancelar um projeto e não insistir numa coisa que não vai dar certo é uma arte. Não existe nada de errado em descobrir que as premissas iniciais estavam erradas e reajustar. Mas tem muito problema em insistir num erro depois de descobrir que estava errado.

Na verdade, em cursos e em guias sobre gestão se dá muita ênfase em como documentar as coisas, como fazer métricas, e muita coisa que, francamente, é bem inútil. Eu quero começar falando sobre o que quase nunca vejo ninguém discutindo fora de happy hour e conversa de bebedouro. Como dizer “não”. Ser um yes man ou yes woman é muito fácil. O cachorrinho abanando o rabo quando o superior manda fazer alguma coisa. Um yes man nunca vai ser um bom gestor porque um bom gestor é aquele que sabe dizer não quando precisa.

Por outro lado, alguém que só diz não e nunca entrega nada, é igualmente inútil. Um bom gestor é como um bom general, ele sabe escolher quais batalhas vai investir. Porque batalhas custam seu batalhão, custam tempo. Só lute batalhas que sabe que vai ganhar, e espere ter condições mais pra frente de lutar as batalhas que hoje iria perder. E só assim, escolhendo certo uma batalha de cada vez que se vence uma guerra. Sabedoria militar é especialmente interessante em empresas. Não a toa todo mundo fala sobre Sun Tzu e sua arte da guerra, mas ninguém sabe o que ele quer dizer, porque seu livro não pode ser lido literalmente. São alegorias inúteis pra qualquer um que já não tenha lutado uma guerra. E de fato, eu mesmo lá no começo era estilo mais kamikaze, ficava pegando briga que não era minha, e perdendo tempo com batalhas inúteis. Demorei anos pra aprender isso.

Um gestor ou um general só precisam existir porque lidamos com recursos escassos. Não existe dinheiro infinito, não existe tempo infinito, porque se existisse, ninguém precisaria gerenciar nada, era só gastar eternamente. É por isso que eu sempre acho que toda tech startup unicórnio e essa idéia maluca de só crescer fatia de mercado sem se preocupar em dar lucro tem como consequência gerar pessoas fracas. Porque muito pouca decisão precisa ser tomada, o problema sempre pode rolar pra frente, até o próximo round de investimentos. É viver a ilusão que se tem dinheiro infinito. E se tem dinheiro infinito, pra que escolher ser eficiente? Basta sair contratando mais gente, infinitamente. Até a bolha estourar. E podem acreditar, ela sempre estoura.

Um projeto costuma ser definido pela trindade escopo, tempo e custo. É impossível ter o maior escopo no menor custo e tempo. Se aumentar o escopo ou o custo aumenta ou o tempo aumenta. Não existe outra forma. Como custo e tempo costumam ser os fatores limitantes o que sempre precisa variar, pra menos, é o escopo. E sempre o escopo é mau definido e os objetivos do projeto que esse escopo quer cumprir são mau entendidos. Só durante o projeto que esse entendimento vai melhorando e isso sempre tem que levar à revisão do projeto.

Quase 10 anos atrás tive um cliente muito burro, o cara era tipo herdeiro. Quem construiu tudo foi a família dele, agora ele achava que só porque fez seu MBA ou sei lá, sabia alguma coisa. Herdeiros acham tudo fácil, lógico, sempre ganhou tudo de mão beijada. É um saco. Na época ele veio com o clássico “Akita, a gente podia encaixar aqui uma funcionalidade de chat, igual o Facebook Messenger, agora que já existe deve ser fácil né? Não dá pra fazer em um mês?” Minha resposta é sempre a mesma “igual? Claro que dá. Se você pagar a mesma coisa que o Facebook pagou, a gente faz”. Sério, lidar com gente que acha que tudo é fácil é foda. Tenho pena de quem trabalhava embaixo dele.

O que um mau gestor sempre vai preferir fazer primeiro, é tentar limitar o problema do tempo fazendo a equipe trabalhar mais horas no dia. E isso é outra burrice sem tamanho. Isso pode funcionar numa emergência de poucos dias. Mas transforme isso numa rotina e automaticamente a qualidade geral de tudo vai cair, e isso se torna uma bola de neve muito rápido, porque as coisas mau feitas dessa semana vão atrapalhar a semana que vem, e agora todo mundo vai ficar correndo atrás do próprio rabo pelo resto do projeto. Como um projeto atrasa 1 ano? Simples, um dia de cada vez.

A trindade de projetos é escopo, custo e tempo, mas existe a quarta variável invisível que todos esquecem. Tente entuchar o máximo de escopo, num tempo pequeno, cortando custos e naturalmente a variável que vai decair drasticamente é a qualidade. Essa é a quarta variável invisível. Falei no episódio anterior que qualidade foi um fator que passou a aparecer entre os anos 80 e 90, mas até hoje muita gente ainda ignora esse fator, porque é mais fácil falar em dólares e horas, mas é difícil de descrever qualidade. Os problemas gerados por um projeto mau feito tendem a ser empurrados pra operação depois.

Comece estabelecendo uma data final. Estabeleça um orçamento. Saiba quais são os objetivos que precisam ser atingidos, em ordem de prioridade, e estabeleça qualidade como fator importante. Daí acomode um escopo que caiba nessas restrições. Normalmente não cabe. E agora vem a inteligência de toda a equipe envolvida em decidir as melhores formas de executar cada tarefa de forma eficiente. Sem fazer horas extras. Garantindo que o que foi feito até agora não seja uma bomba relógio que vai explodir lá na frente. Tudo que é feito às pressas e sem cuidado vai virar um problema muito rápido.

Hoje em dia existe a figura de um PO ou Product Owner. Que é um nome mais bonito pra um gerente de projetos e gerente de operações. Dependendo de pra quem perguntar, vai ter definições diferentes. Mas eu gosto de pensar num PO como sendo um gerente com uma responsabilidade a mais, a de ser responsável pelo ROI do produto, o retorno do investimento. Numa empresa grande, abaixo de um PO vão existir várias equipes, cada uma com projetos próprios, que contribuem pro produto principal. As decisões do PO devem sempre levar em consideração o retorno de investimento de todos. Essa é uma das formas de limitar suas decisões e priorizar seus recursos nos lugares certos. Dê prioridade nos projetos que trazem o maior retorno de investimento. Parece fácil falar, mas muitos se esquecem disso.

Toda empresa e todo projeto tem diversos stakeholders, que são as partes mais interessadas. O financeiro está interessado em manter as contas sob controle, de preferência faturando mais do que gasta. O marketing está interessado em atingir novos clientes, aumentar a fatia de mercado, aumentar as vendas. O marketing só se preocupa com clientes que já existem quando o churn começa a ficar preocupante, ou seja, quando o cliente já existente desiste de você. O suporte ao cliente é o oposto, ele está mais preocupado com o cliente que já existe do que com os que ainda não pagam nada.

Os gerentes de projeto estão no meio desse fogo cruzado. Eles precisam saber colaborar entre si, mas seu foco é no projeto que está executando nesse instante. É nesse fogo cruzado que deveria atuar a camada C, o CEO, CFO, CMO, CTO, etc. A camada C existe pra tomar as decisões que afetam a empresa como um todo. As decisões que um gerente isolado não pode tomar. Facilitar a resolução de conflitos. Por isso eu digo que não existe nada pior que um C-level que não toma decisões e fica empurrando problemas com a barriga, normalmente jogando o osso e deixando os gerentes abaixo brigando entre si pra ver quem ganha ou fala mais alto. É o sintoma de um péssimo C-level e, por consequência, uma péssima empresa.

Da mesma forma, especialmente em empresas grandes, existe uma camada do meio muito gorda, os gerentes midlevel. Eles nem são C-level que podem tomar as decisões mais cruciais e nem estão na linha de frente vendo a guerra de verdade sendo travada nos fronts, onde estão os coordenadores e funcionários em geral. Eles acabam sendo mais burocratas, os famigerados pilotos de Excel e Powerpoint. É um mau necessário em muitas empresas, e eu realmente não consigo ver uma forma de eliminar isso totalmente, só minimizar. Não importa se você chama departamentos de chapters, é tudo a mesma coisa, estrutura hierárquica profunda e pior, estática.

Onde esse problema já existe, que é na maioria das multinacionais e empresas realmente grandes, só vejo isso mudando em épocas de mudança de liderança. Numa mudança de CEO, por exemplo. Onde é forçado a tal “reestruturação” de cima pra baixo. Não é garantia de melhoria, mas pelo menos o caos força mudanças, algumas podendo ser boas. Mas isso é arriscado e custa caro, por isso não se vê todo dia. Em empresas pequenas e médias, o problema é evitar chegar nesse ponto cedo demais.

No começo de uma empresa, ela vai necessariamente ter a cara dos sócios fundadores, que são a primeira geração de C levels dessa empresa. Se os sócios são ruins, a empresa vai ser ruim. As exceções são quando esses sócios tem conexões e investidores que forçam um C level diferente dos fundadores. Mas pensando no caso geral, é por isso que eu sempre digo que um jovem nos seus 20 e poucos anos não deveria pensar em abrir empresa se já não tiver sido muito bem criado e educado com herdeiro de um negócio pré-existente.

Eu disse isso em episódios anteriores, porque muito jovem ingênuo até hoje ainda fala das histórias lendárias dos jovens Bill Gates, Steve Jobs ou Mark Zuckerbergs e a lendária história da startup de garagem, como se todo mundo pudesse fazer a mesma coisa. Existe uma razão de porque se menciona Bill Gates, que abriu a Microsoft no fim dos anos 70. Tem muito pouco exemplo na história. Todos os nomes que eu falei largaram faculdades renomadas. Harvard e Stanford. Experimente entrar nelas. O nome do Bill Gates é William Henry Gates Terceiro. A família já era reconhecida. O famoso contrato da Microsoft com a IBM pra licenciar o MS-DOS só saiu porque o a mãe do Bill Gates era amiga do CEO da IBM daquela época. É assim que se faz. Nem eu, nem você temos como ter contatos assim aos 20 anos.

Quem não é um bom herdeiro vai precisar gastar pelo menos a primeira década de trabalho criando conexões. Conhecendo outras pessoas em começo de carreira que vai confiar em você porque viu em primeira mão que você é competente e entrega o que promete. Daqui alguns anos, ele vai ser dono de empresa, investidor, ou diretor, agora você tem networking de verdade. Isso se constrói e se conquista demonstrando competência de verdade e não se conectando no LinkedIn. Vou repetir: eu não aceito nenhum convite no LinkedIn de quem eu ja não tenha conhecido antes na vida real. Quando aceito desconhecido foi acidente. E outras pessoas que aceitam também não dão nenhum peso. Convite de LinkedIn, cartão de visita, e-mail de spam, vai tudo pro lixo. Não perca seu tempo. Quem eu confio tá no speed dial do meu celular, o resto é resto.

Enfim, o ponto que estava falando é que a empresa vai sempre ter a cara dos fundadores. Se os fundadores forem inexperientes e incompetentes, é assim que a empresa vai ser. Daí vai precisar ter sorte pra conseguir contratar alguém bom que aceite trabalhar pra você. É bem loteria. Por isso eu acho que o certo é primeiro você se tornar bom, um profissional nível A, porque só assim, vai conseguir contratar outro profissional nível A. Um profissional nível B só contrata caras nível C. E caras nível C só conseguem contratar caras nível E, e assim por diante. Só A contrata A.

E isso é importante porque quando possível, parte do trabalho de um gestor é contratar pessoas. Só que se ele próprio não for um cara reconhecido como nível A, vai continuamente contratar as pessoas erradas e colocar nos lugares errados. Das duas uma, ou vai contratar cara nível C quando precisava de um A. Ou vai dar tarefas nível C pra um cara nível A. Em ambos os casos vai ser uma equipe ruim.

Muitos gestores em começo de carreira ficam lendo os cases e metodologias aplicadas em grandes empresas como Netflix ou Google e enchem a boca pra falar “vamos fazer do jeito X porque a Netflix faz assim”. Mas reconheça como isso é idiota. Uma grande empresa como Netflix pode pagar profissionais nível A que ganham meio milhão de dólares por ano ou mais. Primeiro se pergunte: você pode pagar isso? O budget dos projetos que eles executam são da ordem de milhões de dólares. Seu projeto tem esse tipo de orçamento? Se não, por que diabos você está se iludindo achando que pode fazer o que eles fazem?

Sinceramente eu não acredito num gestor que não foi ele próprio um profissional igual aos membros de sua equipe. Um time de futebol onde o treinador não foi ele próprio jogador de futebol. Um chef de cozinha que não foi ele próprio descascador de batatas. Um general que não foi ele próprio soldado raso. E um gerente de equipe de desenvolvimento que não foi ele próprio um desenvolvedor de software. Nem todo programador tem capacidade de virar um gestor, mas certamente um gestor não técnico, nunca vai saber o que é ser um programador num seminário de poucas semanas. Nenhum soldado jamais vai respeitar um general que nunca esteve numa batalha de verdade.

Daí caímos no caso onde temos uma equipe que não respeita seu gestor e o gestor que não confia na própria equipe, que eu chutaria que descreve a maioria das equipes por aí. Respeito e confiança é diferente de ser o cara engraçado no happy hour. Foda-se ser engraçado. Bons profissionais tem respeito mútuo entre si, independente do ranking e classificação. Eles nem precisam ser amigos e gostar um do outro. Mas cada um sabe que na hora H pode contar com o outro. Acaba sendo natural. E esse é o terror das equipes de RH e recrutamento porque eles também não tem a mínima idéia de como contratar certo, porque são só burocratas, nunca estiveram na linha de frente.

E como eu sei que eu sou bom, nível A? Tem um checklist? Tem pré-requerimentos? Tem curso ou certificados que preciso ter? Não, não, não e não. Eu gosto de dizer que ser bom é que nem paixão. Como eu sei que estou apaixonado? Bom, quando estiver apaixonado, você vai saber. E todo mundo ao seu redor também vai saber. É a mesma coisa de ser bom. Se você não sabe se é bom, provavelmente não é. Quando for, vai saber, e todo mundo ao seu redor - que não for sua família e amigos - vão saber. E eu faço essa distinção porque quem automaticamente diz pra você que é bom, mesmo não sendo, tem boas intenções, mas está sendo desonesto. Um amigo de verdade diz quando você está errado, caso contrário está sendo um péssimo amigo, porque está roubando sua oportunidade de melhorar às custas dele se sentir bem consigo mesmo.

Quando você for bom, naturalmente, vai conseguir identificar outras pessoas boas. É assim que funciona. Pra ilustrar, eu gosto da série Peaky Blinders. E me identifico com um aspecto que o protagonista Tommy Shelby tende a no mínimo respeitar quem lutou na guerra como ele. Ele tem vários traumas das trincheiras da França na Primeira Grande Guerra Mundial, que foi uma das mais carniceiras de todos os tempos. Quando você encontra outro ex-soldado condecorado que esteve em batalhões que lutaram juntos, você meio que sabe do que ele é feito. Todo filme de guerra tem esse aspecto, e no mundo fora das guerras de verdade, é similar, a gente que tem cicatrizes sabe reconhecer as cicatrizes dos outros. Só que um recém formado ou iniciante não tem cicatrizes ainda. Esse é o ponto.

Mas não é só executar o trabalho? Não é só preencher planilhas e preencher relatórios e meu trabalho como gestor tá acabado? Esse é o pensamento que muito iniciante tem. Das duas uma, você vira o yes man, que vai só executando o que pede. Ou você se torna o maverick, o imprudente que acha que precisa revolucionar as coisas do seu jeito. Mas como eu disse, nenhum dos dois tem cicatrizes ainda pra saber até onde pode ir e nem como ir. E ambos estão fazendo bobagens. O problema é que o termo “gerenciar projetos” é o jeito errado de dizer. O objetivo é entregar projetos mas você sempre gerencia pessoas. Sua taxa de sucesso em projetos é diretamente proporcional ao seu bom relacionamento com suas equipes.

E pessoas não são máquinas. Especialmente em programação. Aliás, eu sempre falo que essa é a diferença entre software e hardware. Quando falei que é importante saber PMI mas não seguir nada deles ao pé da letra é porque muito do que existe documentado sobre gerenciamento de projetos deriva da engenharia de produção, da gestão de fábricas, relíquias da revolução industrial, o legado de modelos como da Ford. Aquele estereótipo de Charles Chaplin onde pessoas são secundárias e a linha de produção é o principal.

Nesse ambiente, tudo é minuciosamente planejado, você faz blueprints, plantas baixas, esquematizações e daí é possível calcular até que com bastante precisão quanto vai custar e quanto tempo vai levar pra construir a fábrica. E a partir daí a produção dos items é bem uniforme, com pouca variabilidade. Muita coisa é automatizada e no mundo ideal, nem é pra ter pessoas envolvidas, só robôs, como numa fábrica de carros mais moderna. A maior parte do conhecimento de administração e gerenciamento deriva desse cenário de produção em massa.

No jeito antiquado de pensar, se em hardware funciona, em software também deveria funcionar. Afinal, o programador é como se fosse o operário da linha de produção. Basta desenhar o projeto da forma mais detalhada possível, fazer a planta baixa, que seria função de um arquiteto, daí é só o programador executar como um operário numa linha de fabricar carros. Outra metáfora que se usa quando povo tenta falar de software como arte é equiparar com uma orquestra de música clássica, onde temos um maestro ou condutor, que é o gerente de projetos, a composição que é o trabalho do equivalente arquiteto, daí cada um na orquestra com seu instrumento só precisa executar sua parte com precisão pra termos uma peça de sucesso.

Só que ambos os pontos de vista estão errados. O trabalho de operário ou do músico da orquestra, o trabalho repetitivo, braçal, já é totalmente automatizado. Quem cumpre esse papel é o compilador ou interpretador. É o compilador que recebe a tal planta baixa e cospe o binário que o computador vai executar, mecanicamente. Agora o que é essa planta baixa? Esse é o código-fonte, o programa propriamente dito. O programador não é o operário. Todo programador é tecnicamente arquiteto. E na realidade não se trata de uma orquestra de música clássica e sim um grupo de jazz, onde intuição, improvisação, trabalho em equipe, fazem toda a diferença.

Eu não sou músico, mas do pouco que entendo, jazz seria o mais próximo de programação. Cada integrante toca improvisando, complementando e competindo com os demais no mesmo grupo, mas trabalhando de forma a criar uma música que faça sentido. Programação é a mesma coisa. Cada programador tem seu estilo, seu ritmo, e apesar de precisarem ter alguma base mínima pra não virar só barulho, a contribuição individual de cada um conta.

Um programador não é um operário. E software é ordens de grandeza mais complicado do que hardware porque hardware obedece as mesmas leis da natureza que são não-ambíguos pra todo mundo. Duas empresas de construção que recebem a mesma planta baixa, no final vão construir basicamente o mesmo prédio. Com quantidades similares de cimento, tijolos e tudo mais. A especificação é precisa o suficiente pra isso. E tem que ser assim porque uma vez construído, não tem como refatorar uma ponte. Não tem como adicionar ou tirar um andar no meio de um prédio.

Software é diferente. Dois programadores que receberem qualquer tipo de especificação de software, vão sair com dois conjuntos de código completamente diferentes. E quanto mais específico você tentar ser, mais próximo do código final você vai chegar, então no final é como se estivesse você mesmo fazendo o código. O código é a especificação. E o erro é justamente esse: achar que é possível especificar um software com precisão antes de comecar a codificar. Isso é impossivel.

Claro, se você está num ramo de atividade onde sempre faz o mesmo software o tempo todo, aí é mais fácil. Por exemplo, uma agenciazinha cujo trabalho é customizar Wordpress pra pequenos clientes. Nesse caso o grosso do software já está pronto, é o Wordpress. Você muda tema, muda logotipo, faz uma ou outra customização. Mas agora sim, você está muito mais próximo de uma linha de montagem de fábrica. Porque o grosso do trabalho não é codificar, é copiar e colar mesmo.

Mesma coisa um ERP como os de uma Totus da vida. O trabalho de programação mesmo é fazer e atualizar esse ERP, adicionar novas funcionalidades. Mas o grosso do trabalho de instalar nos clientes é customização, e não totalmente programação. A maior parte do software é padronizado e já está pronto. Daí o que tem de programação é mais a integração dele com outros sistemas, por exemplo. Daí é um ambiente um pouco mais controlado. Nesse tipo de ambiente que funciona as tais ferramentas low code ou no code, que é pra grudar peças que já existem e foram codificadas por um programador. Daí um operador só precisa customizar a integração desses peças. Mas o grosso do software em si, que é o ERP, já está pronto.

Na prática, em graus diferentes, ninguém mais faz 100% de todo software do zero. O sistema operacional é padronizado. Componentes como bancos de dados são padronizados. Pouco a pouco plataformas como AWS da Amazon ou Azure da Microsoft foram comoditizando diversas coisas que antes fazíamos do zero, até machine learning e inteligência artifical hoje são serviços que a gente só integra. A maioria dos projetos hoje tem uma parte grande que é basicamente só integração. O que muitos programadores fazem o dia inteiro é na realidade o trabalho de um integrador.

E mesmo assim o trabalho ainda não é linear de linha de produção porque temos diversos aspectos que mudam. Requerimentos de performance, requerimentos de escalabilidade, requerimentos de segurança, requerimentos de usabilidade. Nenhum deles permanece estático pra sempre. Mudanças nesses requerimentos às vezes exigem reescrever uma parte do software que não atende mais o que precisa. Às vezes é jogar fora um legado por um produto mais moderno. E é aí que entram as equipes de desenvolvimento pra decidir qual o melhor caminho: um band-aid em cima do que já existe, reescrever um pedaço, integrar com um produto de terceiros, ou uma combinação de tudo isso.

E de novo voltamos à formação da equipe. Uma vez definido a direção e objetivos. Quem decide como as coisas vão ser feitas? Um gerente não técnico tem zero condições de decidir essas coisas. Então, ou ele precisou receber essa ordem de alguém, ou precisou confiar que a equipe sabe quais as melhores decisões técnicas. E agora ele se ferrou, porque se não teve a oportunidade de criar essa equipe, se for o caso que falei antes de um gestor que não conquistou o respeito da equipe, tenha certeza que parte dessas decisões vai ser tomada no automático, e os resultados nunca vão ser os melhores.

Quando um gestor não tem a capacidade de decidir essas coisas, ele precisa de suporte. É onde normalmente deveria entrar o tal do CTO, o Chief Technology Officer. Dependendo do tamanho da empresa ele vai ter pares como um CSO ou Chief Security Officer que se preocupa com coisas como governança. E um bom CTO se for realmente um nível A, deveria já ter uma equipe de líderes técnicos que ele confia, e juntos conseguem prototipar, criar provas de conceito, e decidir a melhor solução técnica e orientar as demais equipes dos caminhos que decidiram tomar.

Agora cabe aos gestores de cada equipe coordenar com suas equipes e ver se é possível executar o que foi demandado. Às vezes a resposta vai ser não, e aqui um bom gestor tem que ser o firewall da equipe. Ele tem que saber decidir quando precisa forçar a solução pra equipe ou quando a equipe sabe que não vai dar certo, e porquê, e rediscutir o problema pra cima. E isso é sempre um problema quando o gestor não confia na própria equipe ou a equipe não respeita o gestor. Alguém sempre vai estar vendido nessa situação, e por isso eu disse que gestão de projetos é na realidade gestão de pessoas.

Por princípio, se não for do tipo kamikaze como eu, a maioria das pessoas detesta conflitos, e vai fazer o possível pra evitar, inclusive prejudicando os projetos, empurrando o problema com a barriga até ser tarde demais. Esse é o pior tipo de gestor, na minha opinião, porque ele vai dar burn out na equipe, executando uma coisa que já se sabia que não ia dar certo, só pra postergar a discussão do problema. O famoso jogar embaixo do tapete e torcer pra ninguém ver. Dentro da equipe, o único que tem obrigação de não fugir de conflitos, é o gestor. A equipe deve ser blindada de conflitos desnecessários, e o gestor é quem tem que aguentar a úlcera e blindar a equipe.

E falando na equipe, agora temos o problema de composição e comunicação. A realidade é que na maior parte do tempo, nenhum trabalho é realmente interessante. Você tem períodos de coisas legais e períodos de coisas chatas. Infelizmente as duas coisas são importantes. Sabendo disso, muito gestor tenta o caminho de tentar ser o motivador, cheerleader ou algo assim. Isso não funciona. Nenhum gestor motiva equipes, no máximo eles evitam desmotivar. Motivação é intrínseco, cada pessoa só consegue motivar a si mesma. Motivação externa é no máximo um rush temporário. Cada pessoa precisa encontrar propósito nela mesma, e isso é um trabalho individual. Psicólogos podem ajudar, mas gestores só precisam ajudar a não atrapalhar.

Se o gestor enxerga as coisas como fábrica, projetos como linha de produção, programadores como operários, a vida vai ser difícil. Porque ele vai sempre passar só o mínimo de informação, normalmente na forma de ordens, vai microgerenciar como se não houvesse amanhã, e raramente vai ter a via inversa que é de conversa e comunicação. Dizer uma informação é diferente de se comunicar. Comunicação é diálogo. Um diálogo não precisa ter uma resolução imediata, mas no mínimo precisa existir duas mãos na conversa. Isso é o mínimo.

Não dá pra aprender relacionamento de pessoas lendo livros, mas não tem nenhum mau em complementar seu conhecimento com alguns bons livros. E eu recomendo dois. O primeiro é o lendário “Psychology of Computer Programming” do grande Gerald Weinberg. E ele tem vários outros livros interessantes como o “Becoming a Technical Leader”. Mas se quiserem só um resuminho, acho que no mínimo todo mundo já deveria ter lido outro livro famoso, o “Peopleware”, do Tom DeMarco. Esse eu acho que tá um pouco defasado. Várias coisas que eram novidade nele, valiam pro começo dos anos 2000 e hoje parte já é meio considerado comum, mas continua sendo válido ler. Eu vou bater no ponto que a parte mais importante de gerir projetos é entender pessoas, então todo gestor deveria fazer um esforço nessa direção, nem que seja ler alguns livros.

O pior caso é quando o gerenciamento passa a ser em sua maior parte orientado a métricas. Métricas são boas e necessárias. Mas nem toda métrica é boa. As piores métricas são as de produtividade. E isso sempre cai no problema das famigeradas estimativas. O primeiro grande erro é quem confunde estimar com prever. Sabem porque existem duas palavras diferentes? Porque elas significam coisas diferentes. Muita gente ainda pede estimativa mas na realidade estão esperando previsão. Por isso sempre dá discussão “ah, mas você disse que 2 semanas estaria pronto”.

Estimativa é sempre aquela brincadeira de “você finge que fala a verdade e eu finjo que acredito”. Na prática não importa muito com que instrumentos você quer estimar, seja story points, seja horas-homem. O problema é dividir as tarefas ou storys em tamanhos que não sejam muito diferentes. Por exemplo, se o menor tipo de story é de meio dia, o maior não deveria ser mais que uns 2 ou 3 dias. Mais do que isso é um épico e deveria ser dividido mais. Acho importante no mínimo se ter um backlog com stories e um acompanhamento de stories por sprint, tipo um burn out chart. Se não sabe do que estou falando leia os papers originais de Scrum do Schwaber e Sutherland.

Agora, muito mais do que isso eu acho desnecessário. Isso porque essas medidas já são grosseiras, é mais pra ter ordem de grandeza e não exatidão. Sprints também deveriam ser semanais, duas semanas no máximo, mais do que isso e eu posso adivinhar que tem outros problemas graves sendo escondidos. Por exemplo, suas reuniões duram tempo demais e certamente são desnecessárias. Lógico que não dá pra ter um sprint de 1 semana se a segunda feira inteira é gasta só em planejamento e a sexta feira inteira é gasta com review e retrospectiva, e de terça a quinta todo mundo da equipe é toda hora interrompido.

Não adianta querer medir produtividade, no sentido de código entregue por semana. Seu maior problema de produtividade é desperdício de tempo. De novo, um gestor que não tem muita noção do que está fazendo acha que discutir por horas, vai chegar em algum lugar. No máximo é um gestor que sente que está trabalhando muito por gastar muitas horas fazendo reunião. Fazer reunião é o oposto de trabalhar. Tudo que pode ser resolvido por email, deve ser resolvido por email. Você se junta cara a cara quando a discussão claramente não está evoluindo. Aí faz uma reunião pra bater o martelo, e não pra gerar mais discussões.

Isso sem contar métricas aleatórias que obviamente são prejudiciais. Por exemplo, já vi lugares que mediam quantidade de bugs corrigidos. Ou seja, parecia uma coisa boa, quem mais corrigisse bugs, era o melhor. Não precisa ser nenhum gênio pra saber o que isso vai gerar: ninguém vai se preocupar em não gerar bugs. Já que a métrica é corrigir bugs, então o incentivo vai ser em criar mais bugs. Métricas ruins podem afundar sua empresa, porque se você encheu o lugar de pessoas ruins e deu incentivos pra elas serem ruins, é isso que elas vão ser: ruins. Nunca se esqueçam que no geral, as pessoas sempre vão escolher o caminho de menor esforço, é praticamente uma lei econômica isso.

Não tem nada em comunicação que me irrita mais do que quem não sabe o objetivo da comunicação. Ninguém gosta de ouvir sua voz por mais tempo do que o necessário. Ninguem está interessado no seu discurso. A gente só quer saber: qual o objetivo? Qual a direção? Se for um navio é “virar 15 graus a bombordo”. Pronto, essa é a informação. Tudo que você falar antes ou falar depois é desnecessário. O bom dia pode vir na mesma mensagem e não antes de um “digitando …” que fica nos três pontinhos por 5 minutos e me faz ficar esperando que nem um idiota. E você tem que estar disponível pra todo mundo da equipe o tempo todo, porque o papel de um bom gestor é ser um facilitador. Gestor que é difícil de encontrar, não presta. Ah, mas é porque ele tá sempre em reunião. Não tenho dúvidas, e isso é um problema que ele precisa se virar e resolver.

Toda interrupção é desperdício. Toda tarefa de 1 hora que foi interrompida por 5 minutos no meio vira 1h e meia ou mais. Porém, toda informação relevante precisa chegar na hora certa. Nem antecipado que não altera o fluxo de nada, e nem atrasado que agora vai custar o dobro pra agir em cima. Qual é a hora certa? É pra isso que existe um gestor. Interrompa todo mundo o tempo todo e sua produtividade vai pro buraco. Evite interromper quando realmente precisa e vai cometer erros que vai custar mais caro lá na frente. Se fosse fácil decidir isso, não precisaríamos de gestores.

Chats como Slack não foram feitos pra serem usados o tempo todo. Se algo realmente urgente surgiu que não pode esperar, sim, acione o alerta vermelho, interrompa quem precisar pra resolver. Porém, se tudo é alerta vermelho, em breve ninguém mais vai dar atenção. Se a informação não for urgente, anote, comunique quem precisa por email no fim do dia. É o tipo de etiqueta que não deveria precisar ser dito.

Falando nisso, aprenda de uma vez por todas: se tudo é uma prioridade, por definição, nada é prioridade. Eu fiz um video só sobre priorizar. E saber priorizar vale pra todo mundo, todo integrante de qualquer equipe, até chegar no dono da empresa. Não existe querer fazer tudo, porque não temos recursos infinitos. Gerenciar é a eterna tarefa de eleger prioridades e cortar coisas que não são prioridade. E como define prioridades? Essa é a pergunta de um milhão de dólares, se existisse forma fácil eu estaria vendendo. Agora, se você não consegue definir prioridades, certamente não deveria estar liderando. Foi o que eu falei antes: tomar decisões quando elas precisam ser tomadas, e não empurrar problemas com a barriga.

Estimativas e prioridades são coisas que só quem está ativamente participando do projeto deveria se preocupar. Burocratas que aparecem de vez em quando, não tem que dar pitaco em nenhuma das duas. E esse é outro problema frequente, especialmente em empresas grandes demais onde um diretor não tem como fisicamente estar presente em todos os lugares. E aí voltamos ao problema do nível A que contrata outro nível A. Todo mundo precisa poder confiar em outras pessoas. Não cegamente, mas com o mínimo de informações que te dão segurança o suficiente pra poder focar em outros lugares que precisam mais da sua atenção. Não existe metodologia nem fórmula mágica pra isso. Ou você tem pessoas que confia ou não tem, e se não tem, não dá pra substituir por métricas mágicas. Elas só vão te iludir por mais tempo do que deveria.

Eu disse antes que um soldado não confia num general que não foi ele mesmo um soldado antes. No mundo ágil temos a história do porco e da galinha. O gerente que não precisamos ter são os galinhas. Por que galinha bota o ovo e vai embora, mas o porco corta na carne. Quem toma decisões precisa cortar na própria carne e não largar o problema pra equipe e ir embora, e só aparecer quando é pra tomar o crédito. Faça isso muitas vezes, e daqui a pouco vai estar se perguntando porque a produtividade da sua equipe só cai.

Houve uma época que toda decisão era mais baseada em métricas financeiras. É de onde vem a má reputação no meme popular de que empresas são entidades do mau que só pensam em dinheiro. E muitas realmente são assim. Daí teve a época de qualidade total, onde finalmente caiu a ficha que qualidade faz tanta diferença quanto financeiro. Foi a partir do fim dos anos 60 que passamos a diferenciar trabalhadores entre aqueles que executam tarefas rotineiras e padronizadas, como numa fábrica, versus uma categoria que começou a crescer cada vez mais, o que Peter Drucker cunhou como knowledge workers ou trabalhadores do conhecimento, que executam tarefas não-rotineiras, como nós programadores.

Muitos conceitos de gestão ainda vem da época da Revolução Industrial. A idéia de hora-homem por exemplo. Mas esses conceitos não funcionam pro dia a dia moderno porque fábricas deixaram de ser o principal componente das indústrias. Então medir só com base nos números financeiros já não dava mais indicativos da saúde geral da empresa. Foi quando surgiram outras formas de enxergar empresas como o famoso Balanced Scorecard do Kaplan e Norton e suas variações a partir do fim dos anos 80, com métricas financeiras e não-financeiras.

Se você for de admistração certamente já viu Balanced Scorecards, se não for, os detalhes não interessam tanto, mais a noção que hoje as empresas não são todas tão burras de só olhar métricas financeiras como muitos ingenuamente assumem. Elas podem ser incompetentes em alguns aspectos, mas a maioria tem que preocupar com múltiplos aspectos da empresa, hoje em dia incluindo coisas como reputação em redes sociais. Mas tudo bem, eu sei que tem empresas burras porque vira e mexe ouço falar dos idiotas que querem monitorar produtividade mandando o funcionário ligar a câmera e instalando software pra ver se ele tá mesmo digitando ou coisas assim. São empresas assim que mancham nosso mercado e eu espero que eles entrem em falência logo. Ou você confia em quem contrata, ou então não contrata. Se alguém quebra sua confiança nesse nível, você não fica brincando de monitorar, você manda embora. É simples asim.

Pra complementar, o maior problema de uma empresa é quando ela trata todo mundo como criança. Sabe, piscina de bolinha e afins? Quando é uma creche, sim, consigo ver a necessidade de monitoramento ativo. Porque crianças são difíceis de prever, e alguém pode acabar se machucando. Mas uma empresa precisa tratar todo mundo como adulto. Se você tem adultos, não precisa ficar microgerenciando nem monitorando. Por outro lado, se você trata todo mundo como criança, de novo é culpa sua. Empresas não são creches. Não acumule crianças birrentas. Monitorar crianças só funciona quando elas mijam nas próprias calças e brincam de ficar fuçando onde achar faca da cozinha pra se cortar. Num trabalho sério, monitoramento desse tipo não serve pra nada, só pra comprovar que a liderança é completamente incompetente.

Enfim, Peter Drucker, pelo menos na minha época, era o be-a-ba da administração. E naquela época também tivemos trabalhos como de Ikujiro Nonaka e Hirotaka Takeuchi, como eu falei no episódio anterior os japoneses aceleraram seus processos de qualidade e gestão. E Nonaka e Takeuchi escreveram vários artigos, incluindo o famoso The New New Product Development Game, que é de onde surgiu o termo “scrum” que depois o Ken Schwaber usou pra formular a metodologia Scrum e se tornou uma das raízes do movimento Ágil.

Qualquer um que tenha minimamente estudado agilidade já leu esse paper. E eu recomendo que dêem uma boa estudada caso ainda não tenham feito isso. É o resumo do resumo sobre organizações e termos como auto organização. Não é de hoje que se fala em coisas como autonomia. Esse paper é dos anos 80 e até hoje a maioria das empresas ignora o que já sabemos que funciona. Uma boa parte das idéias dessa época fala em elevar os funcionários a pensar em vez de só obedecer e executar. Mas sem entrar em caos. Eu explico isso no meu video sobre Organizações.

Parte disso tem a ver com evoluir as pessoas e passar esse conhecimento pra novos projetos. Por exemplo, um dos erros que até hoje ainda vejo muitas empresas cometendo é quando querem iniciar um novo projeto, mas todo mundo está ocupado já. O que eles fazem? Contratam uma empresa terceirizada pra fazer o novo projeto. Isso é um grande erro.

Às vezes não existe outra forma a não ser aumentar o head count, ou seja, quantidade de pessoas. Um bom gestor sempre deve designar novos projetos pros membros mais seniors das suas equipes e colocar terceiros embaixo deles. Se por acaso for uma especialização que ninguem das suas equipes tem, mesmo assim você coloca seus seniors junto com os terceiros pra eles aprenderem seja lá qual especialização que não tem.

Terceiros devem ser tratados como juniors internos. Ambos os casos embaixo dos seniors internos. Os seniors se tornam seniors quando eles aprendem a mentorar os membros menos experientes. Esse é o ciclo sustentável. Depois que o projeto que eles entregaram passa pra fase de operação, que é realmente ser usado, receber correções, ajustes, manutenção, eles precisam aprender a criar sucessores pras suas posições, pra continuar o trabalho enquanto eles assumem novos projetos.

Autonomia só existe se todos os membros conseguem confiar nos demais membros, não cegamente, mas porque os mais experientes sabem que conseguem mentorar os mais novos, e porque os mais novos sabem que tem quem consultar quando tem dúvidas ou problemas. Uma equipe só de seniors é um desperdício e uma equipe só de juniors é um desastre esperando pra acontecer. Toda equipe deve ter capacidades mistas e serem rotativas. Um junior bem mentorado vai se tornar o novo senior no futuro, que vai passar a mentorar os novos juniors. Os antigos seniors vão continuar em novos projetos, que passa a aceitar novos juniors pra mentorar e assim por diante.

Bons gestores sabem reconhecer os pontos fortes e fracos de cada membro e a ajustar as equipes de acordo com isso. Se em todo jogo você só manda o dream team jogar, quem está de reserva nunca vai ganhar experiência, e quando um dos membros estrela tiver problemas, ninguém vai conseguir jogar no seu lugar, a equipe não sabe como lidar com a mudança. Todo jogo não decisivo precisa misturar reservas. Todo treinador sabe disso. É assim que começam a surgir novas estrelas. Todo gestor precisa saber disso também. Nada que fica estático tempo demais é bom, sempre vai deteriorar. Pequenas mudanças, periódicas, é bom. É a beira do caos que falei no episódio passado.

Confiança não é amizade. Entendam isso de uma vez por todas. Uma coisa é o happy hour. Outra coisa é o trabalho. Quem confunde essas coisas, acha que esconder os erros do amigo é uma coisa boa, porque ele não quer se o cagoeta, o x9. Mas isso prejudica ele, prejudica a equipe e prejudica quem está cometendo os erros. Se você desse o feedback honesto, estaria dando a chance dele corrigir o erro e melhorar. E quando a pessoa se recusa a corrigir o erro, ele é quem está quebrando a confiança com você. Ninguém precisa de pessoas desonestas do lado, especialmente aquele que te chama de amigo só quando interessa. Corte essas pessoas, o quanto antes. Seja realista. Incompetência é algo que podemos tentar consertar. Porém, maucaratismo se corta na raíz. Eu sempre digo que se a mãe dele não conseguiu criar caráter nele em 20 anos, não sou eu que em 2 meses vai conseguir. Corta.

Mas o trabalho é assim mesmo: quando você faz algo certo, não é nada demais, afinal você é pago pra fazer certo. Por outro lado, quando comete erros, eles sempre se sobressaem. É a vida, se fosse fácil, qualquer um fazia e ninguém precisaria de você. Senioridade é aprender a lidar com isso e continuar caminhando em frente. E o papel do gestor não é fazer tudo sozinho, é conseguir construir uma equipe onde todos tem essa mentalidade, e naturalmente os projetos tendem a alcançar sucesso. Não porque todo mundo previu logo no começo tudo que precisava fazer, mas sim porque entendem que erros vão acontecer no caminho e as expectativas vão sendo realinhadas de acordo. Os stakeholders não ficam sabendo de desastres só quando já é tarde demais, esse é o principal. Todo erro identificado o quanto antes, tem chances de ser arrumado.

Gerenciar projetos é gerenciar pessoas. E gerenciar pessoas é gerenciar expectativas. Ninguém precisa de alguém que só faz promessas. Todo mundo precisa de pessoas que assumem seus erros e fazem o possível pra corrigir e, claro, evitar repetir os mesmos erros. É só isso. Promessas e discursos são inúteis e desnecessários. A camada de gestão é responsável pela estratégia, a direção e objetivos. As equipes são responsáveis pela tática, a execução. Todo soldado na frente precisa confiar que o soldado de trás vai cobrir sua retaguarda, e assim todos avançam coordenados em busca do mesmo objetivo, que é ganhar mais uma batalha.

Como falei no começo, esses foram só alguns pontos que eu considero importante lembrar. Mas cada parágrafo que eu falei não é mais que um pequeno resumo de um assunto gigante. O tema completo de gerenciamento engloba décadas de experiência e técnicas que vieram sendo aprimoradas, modificadas, e continuam em evolução. Toda técnica moderna de gerenciamento de software nasceu nos últimos 15 a 20 anos. Muita literatura ainda fala de coisas de 3 ou mais décadas no passado. Algumas coisas continuam valendo, outras não. E a função de todo bom gestor é se manter atualizado, experimentar coisas novas, e não perder o foco sobre sua missão, que é entregar projetos de forma sustentável e ajudar a evoluir suas equipes. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal, e compartilhem o video com seus amigos. A gente se vê, até mais.

DESCRIÇÃO

Finalmente chegamos na marca de 300 mil assinantes no canal! E hoje vai ser mais um video de Rant, Rated R, onde quero só falar livremente sobre minhas pesquisas e hipóteses sobre uma teoria geral sobre os princípios de aprendizado, gestão, empreendedorismo e qualidade. Vai ser uma longa conversa metafísica que costuma ser assunto de minhas conversas de bar. Vamos tentar falar sobre isso sem o efeito de álcool. Vai ser meio bizarro, mas aguentem firme.

Conteúdo

• 00:00:00 Intro
• 00:01:55 Determinismo
• 00:06:54 Atualizando Newton
• 00:10:41 Caos
• 00:13:10 Lavagem Cerebral
• 00:15:02 História da Qualidade
• 00:21:18 Deming a Six Sigma
• 00:25:14 Origens de Agile
• 00:31:34 Resolvendo Problemas Desconhecidos
• 00:33:28 Priorização
• 00:34:44 Mito da Ordem e Progresso
• 00:36:01 Beira do Caos
• 00:39:00 Ordem e Caos
• 00:45:02 Jogando Tudo Fora
• 00:47:21 Medo do Erro
• 00:52:08 Gestão de Risco
• 00:55:44 Saindo da sua Área
• 00:58:31 Conclusão
• 01:01:00 Bloopers

Links

• DR. DEMING’S 14 POINTS FOR MANAGEMENT (https://deming.org/explore/fourteen-points/)
• Edge of Chaos (https://www.systemsinnovation.io/post/edge-of-chaos-1)
• Education at the edge of chaos (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3207078/)
• Your Brain Operates at the Edge of Chaos. Why That’s Actually a Good Thing (https://www.cnet.com/science/biology/features/your-brain-operates-at-the-edge-of-chaos-why-thats-actually-a-good-thing/)
• Edge of chaos as a guiding principle for modern neural network training (https://arxiv.org/abs/2107.09437)
• Optimal Machine Intelligence at the Edge of Chaos (https://arxiv.org/abs/1909.05176)
• cowsay and cowthink (https://web.archive.org/web/20120225123719/http://www.nog.net/~tony/warez/cowsay.shtml)

SCRIPT

Olá pessoal, Fabio Akita

Minha voz anda ruim esses dias, mas decidi gravar assim mesmo, espero que não incomode. Este video é pra comemorar os 300 mil assinantes do canal. Obrigado a todos que acompanham e quem é recém chegado, os videos deste canal foram feitos pra serem assistidos desde o começo. Não tem videos opcionais aqui. Se você tem uma pergunta, eu provavelmente já respondi antes. Enfim, já faz muitos episódios que eu só tenho abordado temas bem técnicos, e sendo honesto até pra mim é cansativo editar tanto detalhe de conceito técnico então resolvi dar uma pausa hoje pra falar de alguns assuntos que estudei por muitos anos mas ainda não discuti no canal. O assunto vai ser sobre como eu penso sobre aprendizado. Uma teoria mais geral sobre aprendizado.

Este video é pra todos vocês que já me perguntaram, “Akita, como eu devo estudar?” ou “Akita, como devo gerenciar um projeto?” ou “Akita, como devo administrar uma empresa?” Impressionante, que apesar de eu já ter falado diversas vezes que vocês não deveriam estar fazendo essas perguntas pra mim nem pra nenhum outro influencer, elas continuam aparecendo. Mas hoje eu quero tentar ensinar a fundação de como vocês mesmos podem tentar responder essas perguntas.

Já deixo avisado logo de cara que quase tudo que vou contar vai soar como auto-ajuda, coaching e tudo mais. A diferença é que não estou vendendo nada. O problema é que assuntos como aprendizado, gestão, empreendedorismo, são abstratos por natureza. Não existem definições exatas e objetivas pra nenhuma delas. Por isso cada um precisa ter uma imagem na cabeça, um modelo pra encaixar na realidade. O que vou contar agora não é a resposta definitiva nem nada disso. É só a forma como eu penso sobre esses assuntos. Alguns de vocês talvez já tenham imagens diferentes na cabeça, e não tem nenhum problema. Vocês queriam saber como eu penso, bem, eis como eu penso.

(…)

Lógico, sei que não importa quantas vezes eu disser que é perda de tempo fazer perguntas como “Akita, o que eu devo fazer da minha vida”, é da natureza humana querer uma resposta fácil, resultados fáceis. Consigo simpatizar com a idéia de imaginar “cara, esse sujeito parece ter sucesso, vou perguntar pra ele como que ele fez, daí é só copiar”. Existem milhões de coisas simples que conseguimos achar respostas fáceis. Como faz pra fazer um ovo cozido com gema meio mole? Procura no Google, e descobre que é só deixar exatamente 7 minutos em água fervente.

Se pra achar como cozinhar um ovo é tão fácil, por que tudo não pode ser assim fácil? Aliás, dá pra extrapolar bastante. Se quero viajar, basta colocar o destino no Waze ou Google Maps, e ele consegue me estimar com bastante precisão o tempo que vai levar pra chegar. De novo, parece fácil. E posso ficar o resto do dia só elencando exemplos de coisas que você não sabe, mas com uma rápida pesquisa no Google, eu acho a resposta e vai ser até bem exata.

Se eu consigo achar respostas tão fáceis pra coisas como achar um trajeto no Waze, por que não consigo achar qual o melhor caminho pra estudar? Ou qual a melhor forma de gerir um projeto que vai ser barato e acabar rápido? Ou qual a forma mais eficiente de administrar uma empresa? Ou simplesmente, como ter sucesso na vida? Por que diabos o Google não consegue me dar essa resposta? Será que é só questão de tempo até a tal da inteligência artificial e machine learning melhorarem um pouco mais?

No fim das contas, por trás de todas essas perguntas que me fazem, elas podem ser reduzidas só a essa mais simples: “Akita, como eu faço pra ter sucesso na vida?” Cara, todo coaching vai te vender que sabe como. E se você for bem trouxa ou muito desesperado, vai cair que nem um pato. Mas como eu não tenho paciência pra isso já digo logo de cara: nem eu, nem ninguém sabe essa resposta e nem nunca vai saber. Nem se juntar todas as cem pessoas consideradas de maior sucesso do século XXI na mesma sala e mandar eles escreverem uma lista de procedimentos. Ninguém vai conseguir seguir e ter o resultado esperado. E intuitivamente a maioria de vocês assistindo já sabem disso, mas por que exatamente?

Foi fazendo essa pergunta que eu me interessei em estudar mais um pouco sobre conceitos de outras áreas. E se você ler demais vai começar a entrar em filosofia e em diversos outros campos. Apesar de achar filosofia clássica chata pra caralho, obviamente tem coisas interessantes a considerar. É fazer as perguntas difíceis, aquelas que todo mundo vai responder “ah, isso é óbvio”, mas se pedir pra detalhar, ninguém consegue colocar em palavras. Deixa eu pegar um exemplo super simples. Lembra as aulas de física básica que você teve no colégio? Lembra daquela formulinha besta de S = v x t? Ou espaço é igual a velocidade vezes o tempo?

Com essa fórmula, se eu estiver num carro a uma velocidade média de 100 quilômetros por hora, e dirigir por exatamente 2 horas, significa que no final vou ter percorrido 200 quilômetros. Você já parou para pensar a implicação disso? Não só dessa mas de todas as fórmulas que aprendeu no colegial? Com tudo que Newton descobriu e documentou no que chamamos de “física clássica” eu não consigo só prever onde meu carro vai estar daqui 2 horas, mas até a órbita de planetas do sistema solar. Dá pra prever onde Marte vai estar em relação à Terra daqui 20 anos, e dá pra saber onde estava 20 anos atrás. Essas fórmulas descrevem o presente, confirmam com os dados vistos no passado e conseguem prever o futuro! Já parou pra pensar nisso?

Um século atrás isso levantou várias questões filosóficas e morais. Aqui eu posso estar sendo simplista porque realmente não sou estudante de filosofia, mas se começar a pensar no que acabei de explicar vai cair no ramo da filosofia conhecida como Determinismo, que na real teve sua origem na Grécia antiga, 7 ou 8 séculos antes de Cristo, época dos primeiros e verdadeiros “influencers”, como Aristóteles. Mas no Ocidente ela é associada com a física clássica de Newton e a busca pelas leis e fórmulas que descrevem a realidade como algo estático e previsível. Vocês entendem a implicação das fórmulas? Se eu tenho na fórmula todas as variáveis que causam um efeito, como velocidade e aceleração, e se eu consigo extrapolar a variável de tempo pro futuro, e se o resultado tem que bater com a realidade, então em essência, estou prevendo o futuro.

Por um lado isso parece extremamente agradável, se a pesquisa continuar e conseguirmos desvendar todas as leis da natureza, quem sabe, não existe uma fórmula mágica, determinista, de como ter sucesso? Por outro lado, se parar pra pensar no lado moral, se essas leis realmente existem, o que isso diz sobre coisas como nosso livre arbítrio? Na realidade a gente não tem agência sobre nós mesmos? Se é possível existir leis que prevêem o futuro, então tudo que estamos fazendo agora, neste minuto, eu gravando este video, ou vocês aí assistindo, não são escolhas que fizemos mas sim passos já pré-destinados que não temos nenhum controle? Será que existe uma fórmula pra isso que a gente só não descobriu ainda?

Na realidade, não. No século XX as chamadas Leis de Newton foram quebradas, caso vocês não saibam. Elas não eram bem “leis”. É por isso que as pessoas tem dificuldade de confiar na ciência. Por um lado mantemos a “Teoria da Evolução de Darwin” ainda como “Teoria” sendo que na verdade já tem bases mais que suficientes pra ser promovida a Lei. E eu sei que alguém já tá indo nos comentários pra discordar, mas esquece, só aceita que dói menos. Mas por outro lado, as “Leis” de Newton não são leis. Deixa eu explicar.

A física clássica de Newton funciona super bem pra fenômenos com dimensões que vão desde o átomo até o tamanho de algumas estrelas e planetas. Parece um escopo bem grande, mas não é o total, nem de longe. Essa mesma física que consegue prever com boa precisão onde meu carro vai estar depois de dirigir por um determinado tempo ou onde um planeta vai estar em relação à outra daqui alguns anos, falha miseravelmente em tamanhos ou densidades muito maiores que estrelas, particularmente quando falamos de coisas como buracos negros. Ela não consegue explicar da onde vem a gravidade. E falha miseravelmente em tamanhos muito menores que o átomo, o mundo sub-atômico da física quântica.

No campo cosmológico, Einstein nos trouxe a Teoria Geral da Relatividade e a Teoria Especial da Relatividade. Na prática, a física clássica de Newton é um caso especial, simplificado, da Relatividade. Ou seja, das teorias de Einstein você consegue derivar física newtoniana pra dimensões “pequenas” onde o espaço-tempo parece estático e linear. Quando falamos em escalas de quilômetros, Newton funciona, por isso ainda aprendemos na escola. Mas quando falamos de escalas de anos-luz, velocidade da luz, aí precisa de Einstein. Mesma coisa quando falamos de efeitos quânticos, não dá pra prever onde uma sub-particula vai estar usando Newton.

Literalmente não dá realmente pra prever onde uma sub-particula vai estar porque no mundo quântico falamos em espaços de probabilidades. Ela pode estar na direita, mas também pode estar na esquerda. As diferentes respostas existem ao mesmo tempo em superposição e só vamos realmente saber exatamente onde depois que colapsarmos o sistema. O mundo quântico não é determinista. A gente sempre acha que toda causa tem um efeito. Mas no mundo quântico temos uma gama de probabilidades. Incerteza e aleatoriedade passam a fazer a diferença. E descobrimos que Deus joga dados. Nada é sagrado, nem as Leis de Newton.

E como eu sempre aviso: cuidado pra não cair em papo de coach quântico. Como o nome diz, física quântica só se aplica no mundo quântico, sub-atômico. Mas o ponto é que até o colegial, você só aprendeu a encarar a natureza como se fosse algo determinista, causa e efeito, segundo as Leis de Newton, que por coincidência corroboram visões antiquadas de destino ou algum tipo de força maior te guiando num caminho pré-definido. Por intuição, na cabeça de muitos, ou existe uma fórmula mágica determinista pra alcançar algum tipo de sucesso, ou na verdade, você está pré-destinado a não ter sucesso e só aceita isso. E a resposta é bem mais complicada do que isso.

Onde eu quero chegar é primeiro fazer vocês entenderam o seguinte: atividades curtas, em dimensões de seres humanos como um ingrediente de cozinha, ou em tempos curtos com poucas variáveis, como a duração de uma viagem pra uma cidade vizinha, existem sim, fórmulas Newtonianas, que conseguem prever como partir de um ovo cru e chegar em um ovo com gema cremosa em 7 minutos. E se o destino da sua viagem fica a 200 quilômetros daqui, se conseguir manter uma velocidade média de 100 quilômetros por hora, vai chegar em aproximadamente 2 horas. Ordens de grandeza muito diferente disso, nem machine learning, nem inteligência artificial, vão conseguir ajudar. Tudo passa a ser uma probabilidade.

Aleatoriedade é um campo inteiro de pesquisas que levam a física do Caos. Pequenas variações iniciais que pareciam insignificantes e podem levar a grandes efeitos difíceis de prever. É uma das razões de porque apesar de todo o poder computacional que nós temos, até hoje é impossível prever a meteorologia com precisão, todos os dias do ano, sem errar. Conseguimos sim, ter uma noção geral, mas nunca vamos acertar como exatamente vai estar o tempo daqui exatamente 1 ano. Não digo no mesmo mês de daqui um ano, mas se vai estar chovendo ou não no dia 1o de junho do ano 2033, volume exato de precipitação entre quais horários. É impossível, e se acertarmos não vai ser porque previmos, vai ser sorte ou coincidência.

Tudo isso que falei foi pra concluir o seguinte: sim, pra coisas com tempo de duração relativamente curto, é possível ignorar muitas dessas variáveis e aleatoriedade, e conseguir seguir um conjunto de passos que te leva de algo simples como um ovo cru pra um ovo cozido decente. É um período de tempo e dimensões onde conseguimos reduzir objetivos a passos deterministas. Porém, estique pra um período de tempo maior, e de repente variáveis que estávamos ignorando começam a aparecer e a dar efeito, até perdermos o controle. Pra todos os efeitos e propósitos, toda receita funciona pra coisas pequenas na dimensão de horas ou dias, mas nunca anos ou décadas, e pra todos os efeitos e propósitos, considere que é impossível ter uma receita determinista, repetível, de como ter sucesso na vida ou mesmo num projeto curto. Quanto mais complexo o objetivo e mais tempo for necessário, mais a aleatoriedade vai quebrar toda fórmula e todo planejamento.

Entenderam? É impossível prever o futuro. Os deterministas newtonianos perderam faz mais de um século já, desde quando descobrimos Relatividade, Física Quântica e Teoria do Caos. Por um lado, não perdemos nosso livre arbítrio. O futuro é incerto e suas decisões afetam o futuro, portanto você é responsável por elas. Mas por outro lado, é seguro dizer que é impossível ter uma receita de sucesso. Mas, cuidado, não é a mesma coisa dizer que estamos totalmente à mercê da aleatoriedade. Isso também nos tira livre arbítrio. O futuro não depende de só ter sorte ou ter azar. Na realidade ela depende das suas decisões somado a ter sorte ou azar. Se tudo fosse só aleatório, nós estaríamos vivendo em caos total. Mas você sabe que não é verdade. Então deixa eu explicar o que é a realidade.

Imagino que estejam confusos. Lembra em episódios passados do Guia de Aprendendo a Aprender ou o que Cursos não tem ensinam? Eu disse que todos vocês sofreram lavagem cerebral a vida inteira. Até se formar no colégio sua vida toda foi pré-determinada. Você sabia passo a passo o que vinha pela frente. Toda matéria era explícita. Você podia escolher não estudar, mas só. De repente você cai no mundo real, e descobre que não tem matéria pré-definida, não tem prova bimestral, não adianta tirar 5. Você não repete mais de ano, mas mesmo assim parece que todo ano é uma repetição do mesmo fracasso anterior. E por isso fica desesperado tentando achar de novo uma receita, como tinha no colégio. Você é um junkie, viciado em passar de ano artificialmente como se isso representasse algum tipo de progresso.

Toda vez que vem à sua cabeça “vou perguntar a receita do sucesso” pra alguém, você está com a noção que existe uma fórmula determinista, uma fórmula newtoniana, pra ter uma carreira de sucesso, ou um projeto de sucesso ou uma empresa de sucesso ou sucesso em geral. Você acha que existe uma forma de seguir passos pré-definidos, algum segredo que ninguém te contou, mas que se conseguir achar, seguir, trabalhar duro todos os dias, garantidamente vai atingir esse sucesso.

E eu contei toda essa história pra te confirmar o que você já sabia mas não queria admitir: esse segredo não existe. E só trabalhar duro não te garante absolutamente nada. Vou repetir: só trabalhar duro, sem método, não adianta nada. Na verdade, até tem um tipo de “segredo” sim, mas você provavelmente não vai acreditar que funciona. Na verdade é irônico que vocês preferem acreditar numa mentira bonita do que numa verdade inconveniente. Antes de chegar nela vou precisar contar outra história pra vocês que começa com um outro tema relacionado, chamado “qualidade”.

A primeira vez que parei pra pensar no termo qualidade, foi numa matéria eletiva na faculdade, lá no meio dos anos 90, alguma coisa sobre Qualidade Total. E eu quero que vocês parem dois segundos pra pensar: vocês conseguem definir a palavra “qualidade”? O que significa alguma coisa ter qualidade? Pra alguns, qualidade significa “ter muitas funcionalidades”. Pra outros significa “ter a menor quantidade de defeitos”. Também pode significar “o que deixa o cliente mais satisfeito”. Você consegue pensar numa definição não-ambígua, objetiva, que teria consenso de todo mundo? Acha que é possível?

Qualidade, assim como aprendizado, empreendedorismo, gestão, sucesso, é outro termo abstrato e subjetivo. O que pra mim parece ser de qualidade, pra outra pessoa pode ser o oposto. Um exemplo bobo é uma coisa que quem me segue no insta já me viu reclamando. Pra grande maioria das pessoas aqui no Ocidente, o que você encontra de sushi num buffet de churrascaria é de excelente qualidade. Inclusive, quanto mais cream cheese, mais qualidade parece ter. Não é isso? Agora, pra mim, e pra maioria dos Orientais, um sushi com cream cheese faz todos os melhores sushiman que já existiram no Japão virar nos seus caixões de desgosto. E o ponto é que no contexto de Ocidente, eu provavelmente estou errado: se existe demanda, provavelmente a qualidade não é zero, especialmente na definição que falei antes de “o que deixa o cliente mais satisfeito”. Se o cliente tem mau gosto, quem sou eu pra julgar.

Mas deixa eu voltar um pouco na história. No fim dos anos 70, começo dos anos 80, o mundo Ocidental se viu numa encruzilhada estranha. Assistam este trechinho do filme De Volta pro Futuro 3, que saiu no fim dos anos 80.

(… trecho)

Esse trecho é da hora, porque o Doc versão de 1955 fica chocado quando o Marty de 1985 fala que componentes eletrônicos japoneses são os melhores, mas na visão dos anos 50, se um componente dava problema, obviamente era por ser japonês. Lembrem-se, em 1945 o Japão perdeu a 2a Guerra Mundial, foi tomada pelos americanos, proibida de se armar de novo, e teve que reconstruir o país, depois de ter tomado duas bombas nucleares no rabo. Fazer o que, meio que mereceu. Mas o resultado é que o país inteiro ficou totalmente quebrado. Imagina reconstruir um país não do zero, mas do negativo.

Em pouco mais de 30 anos, só 3 décadas, ela foi de um país devastado que não conseguia produzir nada de qualidade, pra chegar nos anos 80 com os melhores produtos eletrônicos do mundo. Pra você que é novo, quanto é 30 anos? Se contar de hoje, é mais ou menos a partir dos anos 90 pra cá. Alguns podem achar que é pouco tempo, outros que é muito tempo, mas considere que essa é mais ou menos a idade da internet comercial. Nesse período nós evoluímos de todo mundo fazer ligações telefônicas de orelhão, pra quase todo mundo ter um computador ligado na internet no bolso. 30 anos é o tempo da minha carreira inteira.

Mas o ponto é que quando chegamos nos anos 80, pela primeira vez os Estados Unidos realmente ficaram com medo da invasão de produtos japoneses. Outro fator, foi na Inglaterra que começou a Revolução Industrial no fim do século 19. E nos anos 80 foi quando pela primeira vez ela tava importando mais produtos manufaturados do que exportando. E o Oriente, liderado pelo Japão, tava causando uma invasão inesperada, mas em vez de uma invasão de mísseis e explosivos, era uma invasão no sistema econômico, via produtos de consumo de alta qualidade e mais baratos que da concorrência.

E não só do Japão, mas de outros países orientais que ficaram conhecidos como os Tigres Asiáticos, incluindo Cingapura, Coréia do Sul, Hong Kong, Taiwan. Enquanto os Estados Unidos ficaram perdendo tempo com a Guerra do Vietnam e com a recessão até os anos 70, os asiáticos cresceram monstruosamente. Tudo bem que logo depois, o Japão meio que se fodeu com o estouro da bolha imobiliária e a grande recessão nos anos 90 que se segue até hoje. Essa foi a primeira década perdida deles. E nós notamos isso quando as marcas mais reconhecidas de produtos asiáticos eram Sony, Mitsubishi, Toyota, Honda e agora são Samsung, LG, Xiaomi, Huawei.

Mesmo assim, no começo dos anos 80 tava claro que o Ocidente precisava se modernizar. E por isso todos os olhos se voltaram pra Ásia, em particular, pro Japão. Que diabos eles estavam fazendo que conseguiam produzir produtos de alta qualidade em larga escala a preços baixos? Os governos e empresas ocidentais estavam realmente determinados a quebrar esse código. Eles mandaram pesquisadores e delegações pro Japão pra entender esse fenômeno. Nunca é um único fator. Tem o contexto histórico, tem a diferença cultural, tem até fator sorte. Por isso nunca acredite numa única resposta mágica que seja bala de prata.

Mas uma das coisas que eles descobriram, mais próximo de uma receita, foi o tal Modelo Toyota de Produção ou TPS. Esse modelo descreve o funcionamento e filosofia de uma fábrica inteira, não só a linha de produção, mas desde a contratação até a evolução das pessoas. O Ocidente se focou mais em técnicas, como o sistema de pull em vez de push, pra evitar desperdícios, que muitos de vocês já devem ter ouvido falar, o tal do Kanban. E o conceito que é o coração de praticamente toda metodologia que surgiu depois disso, o ciclo de melhoria contínua conhecido como Kaizen.

No começo dos anos 80 foram publicados vários livros relacionados mas tem 2 que preciso mencionar. O primeiro foi o famoso livro Out of Crisis, ou Saindo da Crise, do Dr. Edward Deming, famoso pelo ciclo PDCA que é similar ao modelo Kaizen da Toyota. PDCA pra quem nunca viu, é o ciclo básico de Planejar, Fazer, Checar, Ajustar e repetir. Já falo mais sobre isso mas esse livro tornou famoso os 14 pontos de gerenciamento de Deming como: criar constância de propósito, ou parar de depender de inspeção pra ter qualidade. Todo mundo que tem posição de gerência precisa pelo menos saber o que são esses pontos. Alguns são óbvios e ninguém faz direito até hoje, justamente porque ignora a história. Vou deixar um link com o resumo dos 14 pontos na descrição abaixo.

O segundo livro eu vejo coaches porcaria falando dele até hoje. É sobre o TOC, ou Teoria das Restrições do Dr. Goldratt. O livro onde ele apresenta essa teoria é o “The Goal”, publicado em 1984, no formato de uma novela, uma historinha mesmo, de um cara trabalhando numa fábrica e otimizando processos. Em resumo muito resumido ele fala sobre a idéia de resolver um problema de cada vez, a analogia de “qual é a força total de uma corrente?” E a resposta correta é “a força do elo mais fraco”. Portanto conserte o elo mais fraco primeiro. Mas agora outro anel vai se tornar o elo mais fraco, então conserte ele. E vai indo um anel de cada vez. É outra forma de explicar melhoria contínua.

Mas mais influente do que todos eles, acho que foi a Motorola por volta de 1986. Ela também foi afetada pela invasão japonesa e conseguiu dar a volta por cima criando uma nova metodologia que chamou a atenção de diversas outras empresas como a poderosa General Electric, de Jack Welsh. Foi a metodologia Six Sigma, que tem como objetivo fazer o processo de fabricação não produzir mais que 3.4 DPMOs ou 3.4 defeitos por milhão de oportunidades. Essa metodologia é bem mais detalhada, densa e tratada praticamente como uma doutrina que deve ser seguida à risca. Se você acha engraçado uma posição como scrummaster hoje em dia, Six Sigma tem faixas pretas e faixas verdes. E eles levam a sério saporra.

Se pra você um CEO influente é alguém como Elon Musk ou Jeff Bezos, nos anos 90 só se falava de Jack Welsh da GE. A Motorola inventou isso de Six Sigma mas foi a GE que tornou ela famosa. O objetivo era esse mesmo: como aumentar qualidade e diminuir custos ao mesmo tempo? E os resultados da Motorola foram impressionantes na época. O objetivo deles era melhorar 10X ao longo de 5 anos e eles ainda aumentaram a aposta de melhorar pra ser 10X a “cada” dois anos ou 100X em quatro anos! E em 10 anos de 1987 até 1997 eles cresceram as vendas em 5 vezes, lucros de 20 porcento ao ano, economia de uns USD 14 bilhões, e os preços das ações da Motorola subiram pra uma taxa de mais de 21 porcento ao ano.

Era isso que a gente lia nos anos 90. Mas olhando agora de 2022, obviamente você pode ver que nem mesmo os criadores do Six Sigma tiveram sucesso por tempo indeterminado. Quantos de vocês tem algum produto da Motorola hoje em dia? Não só isso, em paralelo, eu falei do tal Modelo Toyota, que todo mundo de gestão de desenvolvimento de software adotou também, o tal de Lean. Povo startupeiro ficou doido com o Lean Startup do Eric Ries em 2009, inspirado no mesmo Lean da Toyota. Mas se era tão bom assim, era pra gente estar vendo muito mais produtos Toyota ou Motorola hoje em dia, não? Cadê?

Vários autores já tentaram responder a essa pergunta como Clayton Christensen e seu famoso livro The Innovator’s Dillemma, ou O Dilema do Inovador. Ou Chan e Renée no livro The Blue Ocean Strategy. De novo, variáveis imprevisíveis que a fórmula não tem como prever, somado a um comportamento de sentar em berço esplêndido, em bom português, achar que já ganhou e desacelerar até concorrentes menores e mais motivados passarem na sua frente. Ou condições de mercado imprevisíveis como crises aparecerem quando você não tava preparado. Ninguém consegue prever o futuro e muitas vezes você fracassa mesmo, mesmo achando que sabe tudo.

O Ocidente se assustou com o Japão nos anos 80 mas ao longo dos anos 90 e 2000 eles aceleraram e alcançaram patamares semelhantes, daí tivemos a recessão do mercado japonês, e o surgimento do milagre Chinês no século XXI. O mundo não é estático e ninguém está de braços cruzados esperando. Todo mundo já já superou esses métodos. Mas isso não quer dizer que o Modelo Lean ou o Six Sigma são ruins, só quer dizer que a geração de administradores depois dos criadores dos modelos originais fracassaram em continuar evoluindo o método, pelo menos fracassaram em andar rápido o suficiente pra não ficarem pra trás.

Eu trago esses casos porque hoje em dia todo mundo vai encontrar um monte de jargões e conceitos que nasceram nos anos 80 mas todos repetem e usam sem entender porque. Enquanto o mundo de fábricas, manufatura e gestão empresarial em geral estava passando por essa revolução de qualidade ao longo dos anos 90, o mundo de desenvolvimento de software também estava passando por outras revoluções. A transição do mundo de mainframes e computadores inacessíveis para os microcomputadores nos anos 70 e 80 e depois a internet comercial dos anos 90 aos anos 2000. E não por acaso, nós pegamos inspirações no mundo de manufatura.

De onde veio essa idéia de Ágil que todo mundo fala hoje em dia? Da onde saiu esses rituais de planejamento, retrospectiva, sprints e Scrum? De onde veio essa idéia de desenvolvimento baseado em testes? Depois de estudar tudo que saiu dos anos 80 até hoje em gestão, eu penso que todo mundo chegou na mesma conclusão mais ou menos ao mesmo tempo. Alguns foram inspirados por autores como Deming, alguns copiaram uns aos outros mesmo, e alguns realmente pararam pra pensar no problema e naturalmente chegaram a soluções parecidas. Os princípios de todos eles são simples e qualquer um conseguiria chegar em conclusões semelhantes. E chegaram, na real.

No coração do mundo Lean da Toyota está um princípio chamado Kaizen, ou melhoria contínua. Foi Deming quem definiu esse princípio em sua forma mais geral no chamado ciclo PDCA, que é sigla pra Planejar, Definir, Checar e Agir. No mundo da Toyota o conceito é que nenhum problema é resolvido permanentemente na primeira tentativa. Todo problema identificado deve dar origem a uma contramedida. E essas contramedidas podem ser de curto prazo, tipo um band-aid pra corrigir rápido, mas seguido de contramedidas de longo prazo, que buscam resolver o problema na raíz. Daí que vem técnicas como os famosos 5 Ps ou 5 porques. Deixa eu pegar um exemplo do livro.

Digamos que o problema identificado seja “as unidades de fabricação por hora estão abaixo da meta”. Por que? “Não conseguimos produzir peças suficientes por hora”. Por que? “Estamos perdendo oportunidades de produção”. Por que? “Perda de tempo”. Por que? “Perdas de tempo de ciclo”. Por que? “A carga da máquina leva muito tempo”. Por que? “O operador precisa caminhar um metro e meio pra ir pegar o material”. Opa. Esse parece ser a raíz do problema, e o que podemos fazer?

Dar um jeito de reduzir essa caminhada. Portanto, isso vai diminuir o tempo pra carga da máquina. Portanto, isso vai reduzir perdas de tempo de ciclo. Portanto, isso vai aumentar o tempo disponível. Portanto, isso vai aumentar as oportunidades de produção. Portanto, isso vai produzir peças suficientes por hora. Portanto, talvez consigamos atingir as metas de unidades de fabricação por hora.

Ou seja, temos o problema que estamos fabricando poucas peças por hora. A hipótese da raíz do problema é que o operador precisa caminhar demais toda hora pra pegar material e recarregar a máquina. Uma possível solução é trazer mais material pra perto do operador. Mas isso vai resolver de verdade? Só nos restar testar. Depois de um certo período de tempo, que poderíamos chamar de “sprint”, vamos verificar a quantidade de peças produzidas por hora e verificar se realmente voltamos a atingir a meta por hora. Se sim, podemos definir uma contramedida de longo prazo talvez colocando um armazém mais próximo com os materiais pra todos os operários. Se não, analisamos de novo e buscamos uma nova hipótese pra testar.

O que eu falei pareceu meio óbvio? Esse exemplo é da página 334 do manual de aplicação do Modelo Toyota. Um livro de 423 páginas. Isso não é o primeiro capítulo, é uma das partes finais do manual. O que eu acabei de explicar é o processo PDCA. Planejar uma contramedida que é diminuir o tempo de carga do operador. Realizar a contramedida que é estocar mais material próximo dele. Daí checar, medir o tempo médio de produção e validar que a meta foi atingida ou não. Finalmente, agir em estabelecer uma contramedida de longo prazo ou procurar outra possível raíz do problema. Resolveu? Então o elo mais fraco mudou pra outro elo, repete o processo e assim por diante.

No mundo Six Sigma não se fala de PDCA e sim de DMAIC, que é sigla pra Defina, Meça, Analise, Melhore, Controle. É um pouco mais específico no sentido que uma vez resolvido o problema, controle e garanta que o problema não se repita. Além disso as métricas também são estatisticamente mais exigentes, a começar pelo objetivo do nome: alcançar o nível Six Sigma que significa não mais que 3,4 defeitos por milhão de oportunidades ou 99,9997% de qualidade. Mas em princípio, PDCA e DMAIC são a mesma coisa.

Sabe o que mais é a mesma coisa? Um sprint de Scrum. Planeje as stories, trabalhe e programe, no final faça retrospectiva, revise as métricas, ajuste o processo, recomece outro sprint. Isso não é por acaso. Existe outro ciclo parecido que é a base da civilização moderna. Sim, o tal método científico que todo pseudo-cientista de Twitter esquece que existe. O método começa pela observação, que deve ser sistemática e controlada, a fim de que se obtenham os fatos científicos.

O método é cíclico, girando em torno do que se denomina teoria científica, a união do conjunto de todos os fatos conhecidos e de um conjunto de hipóteses testáveis. Os fatos, embora não necessariamente reprodutíveis, têm que ser necessariamente verificáveis. As hipóteses têm que ser testáveis frente aos fatos, e por tal, falseáveis. As teorias nunca são provadas e sim corroboradas. Se você está focado em tentar provar alguma coisa via algumas poucas evidências, você não está praticando o método científico, está só se inventando uma história.

Mais importante, o método científico é cíclico. Se a hipótese falhou, checam-se os novos fatos, ajusta-se a teoria, e verificamos as previsões de novo. A cada nova tentativa, aprendemos novos fatos. Melhoramos a teoria, continuamente. De novo, melhoria contínua, ou Kaizen. Todos os modelos ciclicos, PDCA de Deming, DMAIC de Six Sigma, Kaizen de Lean, Sprints de Scrum, MVPs de Lean Startup, tem em comum o fato de serem métodos de resolução de problemas desconhecidos. Eu iria um passo além e dizer que esse é o único método que conhecemos hoje pra resolução de qualquer problema desconhecido.

É meio anticlimático, mas eu falei que vocês talvez tenham dificuldade de aceitar que a única solução pra todos os seus problemas se chama literalmente “tentativa e erro”. Qual a melhor forma pra estudar? Tentativa e erro. Qual a melhor forma de gerir um projeto? Tentativa e erro. Qual a melhor forma de administrar uma empresa? Tentativa e erro. Qual a receita pra ter sucesso? Tentativa e erro.

Todos que tentaram seguir receitas, fracassaram. O mundo não é determinista nem newtoniano. A fórmula que você está procurando não existe. A coisa mais frustrante que existe no mundo corporativo até hoje, em particular com empresários amadores, é justamente essa idéia de trazer consultores com balas de prata, que ficam ali um, dois anos tentando implementar um monte de ferramentas e métricas, e no final o resultado é uma droga. É o mesmo problema do monte de gente confiando em cursos mágicos que garantem resultados irreais e achar que certificados garantem alguma porcaria. Todos vocês estão cometendo o mesmo erro, que foi o que a Toyota dos anos 80, a GE dos anos 90, a Apple dos anos 2000 conseguiram melhor que os outros: resolver um problema de cada vez e melhorando um passo de cada vez de maneira sistemática.

Óbvio, quando eu falo “tentativa e erro” não é só sair tentando qualquer coisa e se contentar com todos os erros. Tentativa e erro não é isso. Primeiro, é não errar a mesma coisa mais de uma vez. Isso tem que ser sistemático, é o ítem de controle do DMAIC de Six Sigma. Segundo, é testar logo, é a contrapartida de curto prazo de Lean da Toyota. Terceiro, é ter obcessão por evitar todo e qualquer tipo de desperdício, que é a raíz de toda metodologia de qualidade. Quarto, é não copiar ninguém, e sim identificar e resolver um problema de cada vez que você tenha, sistematicamente, disciplinadamente, obcessivamente, num nível de psicopata mesmo.

Isso me lembra um meme de desenvolvimento de software que alguns de vocês já devem ter visto alguma versão. Lembra os 5 Ps que falei antes? Por que vocês não escrevem testes pras novas funcionalidades? Porque não temos tempo. E por que não tem tempo? Porque tem muita coisa pra fazer e o sistema tem muitos bugs inesperados que nos atrasam. E por que tem tantos bugs? Porque o sistema não tem testes. E por que vocês não escrevem testes? Porque não temos tempo! - É impressionante que toda desculpa se resume a “não tenho tempo”. Quer uma novidade? Ninguém nunca tem tempo. A diferença entre eu e você é que eu não uso tempo como desculpa. Se tem uma coisa que todo mundo tem igual é tempo, a diferença é que alguns priorizam as coisas melhores do que outros. Por que vocês acham que um dos primeiros videos que fiz neste canal é justamente sobre priorização?

Se voltar pra você enquanto estudante. Tem milhões de coisas que você não sabe. E isso deixa você explodindo em ansiedade. Você gasta um tempo fazendo cursos ou seguindo tutoriais. Mas parece que não está evoluindo. O tempo passa, a quantidade de coisas que você não sabia parece que só aumenta. E no desespero começa a ouvir coaches e gurus vendendo cursos mágicos que prometem que vão te acelerar. E você vai na conversa.

Seja tentando descobrir como estudar, ou como gerir um projeto, ou como administrar uma empresa, você sempre entra num momento de desespero e tenta achar alguma fórmula mágica. Você tenta sair do caos e encontrar alguma ordem, seja lá qual ordem, pra tentar conseguir algum progresso. Ordem e Progresso. Eu pessoalmente sempre achei essa frase muito estranha. Ordem não leva ao progresso. Ordem no máximo mantém as coisas no mesmo lugar, o que não é progresso, mas o mais natural é que só ordem eventualmente deteriora e retorna à desordem. É inevitável. Até se falarmos de novo em termos de física, é a 2a lei da termodinâmica. Todo sistema fechado tende a aumentar a entropia, que é o grau de desordem. É literalmente uma lei da física.

Ordem e progresso é o lema dos positivistas de Auguste Comte, ironicamente ela é pró-ciência, mas derivada da época da Revolução Industrial e realmente se acreditava que o pré-requisito pro progresso seria criar ordem. Obviamente é um pensamento já ultrapassado, assim como o determinismo newtoniano. Mas o que eu quero argumentar é que ordem não leva ao progresso. E alguns poderiam concordar dizendo que caos leva ao progresso. Mas anarquia absoluta também não leva a progresso. Então qual a saída?

Já que falei da física que você aprendeu no colégio, lembra outra coisa que aprendeu naquela época? O que acontece quando você ferve água e ele chega no ponto de ebulição de 100 graus celsius no nível do mar? Ele começa a virar vapor certo? Por outro lado se congelar essa água pra baixo de zero graus celsius, ela muda de líquido pra sólido. São as mudanças de fases de um material. Isso é transição de fase de um sistema em equilíbrio. Não vou tentar explicar termodinâmica, nem sou especialista e é muito fácil fazer metáforas erradas, mas deixa eu só arriscar um pouco. A parte importante é só pra lembrar que existe esse fenômeno de transição de fases de um estado de baixa entropia pra um estado de mais entropia, da ordem do gelo pro caos do vapor e de volta pra líquido.

Eu gostaria de ter um pouco mais de bases pra conseguir explicar Einstein, Podolski, Rosen, condensado Bose-Einstein, transição de fase de não-equilíbrio. Quem for físico assistindo, vejam se conseguem explicar em português nos comentários abaixo. Mas vamos nos contentar só com um conceito. A entre-fase entre uma fase e outra, a fronteira que separa uma fase de outra durante sua transição, que é conhecido como Edge of Chaos ou beira do caos, como foi cunhado nos anos 80 na Teoria do Caos por Norman Packard. Mas é na biologia que esse conceito me chamou mais a atenção, em particular no fenômeno de adaptabilidade de sistemas complexos não-lineares. Eu falei um pouco sobre isso no episódio sobre Organizações, depois assistam.

Eu sei que tá ficando bem meta isso, mas aguentem firme. A observação interessante é que todos sabemos que ao longo de milhões de anos, todos os seres biológicos sofrem mutações e via seleção natural temos a evolução das espécies. Mas interessante como apesar de tantas mutações, apesar da segunda lei da termodinâmica que falei antes, os ecossistemas não decaem em caos. Fala-se em adaptabilidade na beira do caos. E falando em termos mais gerais, beira do caos é usado como metáfora pra descrever outros fenômenos difíceis de explicar em sistemas complexos, como uma sociedade por exemplo. Se tudo tendesse ao caos e aleatoriedade, como explicar que todos nós, conseguimos conviver numa sociedade organizada e estruturada que, apesar de altos e baixos, não regride pra puro caos, mas parece avançar. Devagar e sempre?

Beira do caos é o que temos na transição de fase entre ordem e aleatoriedade ou caos. Não temos nem ordem e nem caos, mas ficamos indo e voltando entre ordem e caos. E se isso tá ficando esquisito, existem pesquisas que argumentam que nosso cérebro, nossa rede neutral, funciona mais ou menos na beira do caos. E em particular no campo de Deep Learning existem pesquisas de aplicação do conceito de beira do caos pra melhorar inteligência artificial. Ainda é um campo aberto e em estudo, mas onde eu quero chegar é que nem ordem e nem caos levam ao progresso, nem à adaptabilidade e evolução, mas sim um estado transitório entre ordem e caos, que é a beira do caos.

E aqui vem uma hipótese minha. Pra mim, beira do caos, é o que todo mundo realmente quer dizer quando falamos em “encontrar balanço”, ou “ser equilibrado”. Quando falamos isso, todo mundo pensa automaticamente em ordem, num sistema estático, fixo. Mas eu acho que isso tá errado. Balanço é justamente balançar entre ordem e caos. Por um lado você entende balanço como ordem, como equilíbrio estático, que significa uma balança com os dois lados sempre imóveis e fixos. Pra mim balanço é beira do caos, pendendo entre ordem e caos de tempos em tempos. É um equilíbrio, só que é dinâmico. Hora é +10 pontos, hora é -10 pontos, na média dá zero, saca. Esse é o “segredo”. E como fazemos isso? Disciplinadamente evoluindo um passo de cada vez num ciclo entre ordem e caos.

Se não ficou claro ainda: todos os ciclos que eu expliquei antes: o PDCA de Deming, o DMAIC de Six Sigma, o Kaizen de Lean, o Sprint de Scrum. Durante um sprint de Scrum exercitamos a ordem: trabalhamos linearmente, uma story de cada vez, ao longo da semana. No final fazemos retrospectiva e no review adicionamos um pouco de caos, uma mudança com objetivo de testar uma nova hipótese de resolver um problema. Iniciamos um novo sprint, ordem de novo. Terminamos com um novo review e adicionamos mais um pouco de caos, que é sair um pouco da ordem anterior. Assim como uma mutação genética esperando uma seleção natural no mundo biológico. Ou como nossos neurônios funcionam pra promever aprendizado.

É por isso que você está constantemente ansioso e inseguro quando está estudando. Você tem um programa pra seguir, aulas pra assistir, trabalhos pra fazer, materiais pra ler, mas não sente que tá evoluindo. E é claro. Provavelmente não está mesmo, só tá fazendo o tempo passar. Quantas vezes você pára e testa o que sabe? Realmente testar. No caso de programação, parar e fazer um programinha simples do zero diferente de tudo que já foi pedido nos exercícios? Fora da zona de conforto, tirando as rodinhas da bicicleta? Você nunca faz isso. E quando tenta, não consegue e desiste rápido. Mesmo quando um professor pára pra dar uma prova, isso não testa nada, no máximo que você é bom de decorar as coisas. Mas decorar coisas não torna ninguém um bom profissional em nada.

O ideal seria que os professores dessem provas surpresa o tempo todo. E que as aulas fossem ajustadas e modificadas depois dessas provas. E as provas não tivessem nada de decoreba e sim de raciocínio lógico, que desse pra deduzir a maioria das respostas só por indução e bom senso. Todo mundo aqui ia odiar isso, e eis o motivo: seria caótico, seria fora de ordem, poderia até parecer injusto. Mas eis a realidade: o mundo real é caótico, fora de ordem e injusto, mas você nunca treinou pra isso. Sua reação instintiva é tentar encontrar ordem onde ela não existe. E aí vocês ficam que nem idiotas perguntando pra influencers o que eles acham que você deveria estudar, que cursos deveria fazer, que livros deveria ler. Não importa. Nada disso importa se você não está preparado pra viver à beira do caos. Abandonar esse conceito que existe uma ordem, e abraçar momentos de caos e incerteza como coisas boas.

Se ainda não ficou claro vou repetir. É impossível prever o futuro. Tentar prever é um exercício em futilidade. Tentar planejar tudo que vamos fazer anos pra frente é inútil. Em vez disso planejamos só o que é possível: uma semana pra frente, um mês pra frente, não muito mais. Agora executamos. Seja estudo, seja trabalho num projeto, seja administração de uma empresa. O importante é parar depois de um período curto de tempo e checar a hipótese. Conseguimos atingir essa pequena meta? O que deu errado? O que dá pra melhorar? Adicionamos um pouco de caos, reformulamos a hipótese, e agora continuamos executando por mais um período de tempo. Paramos de novo. E repetimos esse ciclo, resolvendo um pequeno problema de cada vez, melhorando um pequeno aspecto de cada vez, mas garantindo que não estamos cometendo os mesmos erros, e que a melhoria que fizemos vai se acumular.

Você tem dúvida se vai gostar de um determinado curso de 10 meses? Nunca, jamais, sob hipótese nenhuma, compre os 10 meses adiantado, isso é estupidez, é tentar prever o futuro - que já estabelecemos que é impossível. Pare de insistir no impossível. Pague 1 mês e teste. Se gostar e ver resultados, pague mais um mês. Ah, mas se pagar os 10 meses de uma vez vai ser mais barato. Não, não vai. Porque se você não gostar, vai jogar 10 meses fora. Por outro lado, se pagar só um mês e não gostar, vai jogar fora só esse 1 mês. Mas e se o curso não der opção de pagar só um mês? Isso é sinal que eles não acreditam no que estão vendendo e precisam já te forçar a pagar tudo de uma vez pra não poder desistir. Isso é um sinal claro que você pode descartar essa opção porque sem nem experimentar já sabemos que se trata de uma grande fraude. Tá vendo, é assim que evitamos ser feitos de idiotas.

E isso vale pra tudo. Pegue um projeto longo, como garanto que consigo entregar? Eu não garanto. Sempre use a boa e velha estratégia de Jack o estripador: vá por partes. E sempre se lembre do bom e velho Napoleão: dividir pra conquistar. É daí que nasce o conceito de Minimal Viable Product ou MVP de Lean Startup. Em vez de tentar planejar um sistema gigante que parece que vai levar 2 anos pra uma equipe de 10 pessoas entregar, primeiro escolha 1 funcionalidade, em versão simplificada, que é a mais importante do sistema e que 2 pessoas consigam fazer em 2 meses.

Você vai aprender mais sobre a equipe, sobre o produto, e no final de 2 meses, se não gostar do resultado, só perdeu 2 meses e não 2 anos. E se não ficou claro, todo projeto você define o custo e o tempo primeiro, daí encaixa só o que couber nesse limite. O que não couber, não coube. O errado é definir todo o escopo primeiro e tentar fazer o custo e o tempo encaixar. Isso é impossível e quem faz isso parece um idiota tentando encaixar uma peça redonda num buraco quadrado.

A mesma coisa vale do ponto de vista de um programador como eu ou você. Na dúvida, comece fazendo um protótipo. Um código que talvez você pode jogar fora. Talvez não, um código que certamente vai jogar fora. Programar não é só digitar código que nem um idiota. É jogar fora a maior parte do que digitar. Escreva e jogue fora. Escreva e jogue fora. Acostume-se a jogar fora o que faz. Nem tudo que você faz é especial, a maior parte nunca é. Nunca vai ser especial se guardar tudo.

Você precisa jogar fora e produzir mais. Programe um dia inteiro, qualquer coisa, sem nenhum propósito real. E no final do dia, jogue tudo fora. Quantas vezes ouviu alguém dizer isso? Se nunca ouviu falar isso, você só teve péssimos professores. Jogue, tudo, fora. Respira. Começa tudo de novo. Se você economiza e escreve só o que parece que precisa, só pra uma tarefa em especial, e raramente joga alguma coisa fora, eu tenho certeza que você é medíocre.

Só quando tiver uma versão mínima que se sinta realmente confortável, só aí comece a se comprometer com esse código. Desde o começo você vai cometer erros e, pior, começar a repetir os mesmos erros. Adicione testes unitários. Isso garante que no mínimo o que já foi feito, vai continuar funcionando, mesmo que você continue experimentando adicionando mais coisas. Pare, reflita o que fez, adicione caos, refatore o código, pague parte da dívida técnica, e continue. E repita esse ciclo. É como desenvolvimento de software moderno funciona, e não é à toa.

Tudo que você, ou faz sem pensar e só vai fazendo no caos, ou tudo que planeja demais e segue cegamente um plano sem parar pra revisar, vai dar errado. Você precisa balancear ordem e caos. O que significa que precisa intercalar períodos de ordem com períodos de caos, é isso que significa achar balanço. E não é aleatório. Em todo intervalo você mede e critica a hipótese original. Modifica a hipótese e tenta de novo. Nem só ordem, nem só caos. Dar um passo pra trás pra conseguir dar dois passos pra frente. Isso é o que eu quis dizer no começo com “tentativa e erro”, uma forma cíclica de sistematicamente melhorar um passo de cada vez. Melhoria contínua ou Kaizen. Sempre balanceando na beira do caos.

O que estou tentando fazer vocês refletirem é que provavelmente sua forma de pensar ainda é newtoniana determinista positivista, buscando ordem absoluta, evitando caos o máximo possível, com a promessa de progresso. A razão disso é muito simples: vocês tem medo de errar. E nesse medo acaba acreditando que algum guru ou alguém mais especial que você vai dar o camiho das pedras. O segredo é simples: assuma que vai errar, só garanta que vai errar pouco e errar cedo pra não sair tão caro. Daí é só ajustar e repetir.

A raíz do problema de tudo na sua vida é medo. E é um grande clichê mas ainda bem que você tem medo. Parece que tem gente que não tem medo de nada e sai enfiando a cabeça em tudo, até literalmente rachar a cabeça num poste, ou pior, atropelar alguém. Isso não é coragem, isso é imprudência, ou melhor, pura burrice mesmo. Coragem é dar um passo pra frente, mesmo com medo. Eu falei no video sobre como eu aprendi inglês que o que falta pra maioria dos adultos é voltar a ser criança um pouco. A diferença de porque crianças parecem ter mais facilidade de aprender as coisas que adultos é porque elas não tem medo de serem julgadas, de alguém ridicularizar os resultados ruins que ela vai ter no começo. Elas simplesmente ignoram os comentários dos outros e seguem em frente até conseguir o que querem.

Elas viram adultos quando a prioridade passa a ser imaginar o que essa entidade abstrata e fantasiosa chamada “outros” pode pensar dela. Será que vão achar que sou lento? Será que vão achar que sou incompetente? Será que vão achar que eu não levo jeito. Será que vão achar que sou velho demais pra começar? Esse monte de “será” inútil se torna sua muleta e sua rotina de desculpas pra não fazer nada e você se torna um adulto realmente inútil, absolutamente chato e totalmente desinteressante. Todo dia que você não faz nada porque acha que é tarde demais só garante uma coisa, que amanhã vai ser tarde demais menos um dia.

O que você precisa fazer? Ligar o foda-se pra opinião dos outros. Opinião é lixo, opinião não vale nada, e principalmente, a opinião dos outros não paga minhas contas. Felizmente eu pago minhas próprias contas, não dependo de ninguém e por isso eu tô literalmente cagando e andando pro mundo. Se o mundo resolver criticar o que eu estou fazendo falando que é infantil, ou não combina ou qualquer merda dessas, minha resposta é sempre a mesma: vem pegar minhas bolas pra ver se tá gelado.

Programação é a mesma coisa: você não precisa começar programando nada que seja útil. Só precisa começar a programar qualquer coisa, qualquer lixo, pra perder o medo da janela vazia do editor de textos. Programe qualquer coisa e jogue fora. E se você não consegue imagina o que significa algo inútil, esses dias me lembrei que toda distribuição Linux dá pra instalar um programinha super inútil chamado “cowsay”. Em alguns já vem instalado, mas num Arch linux dá pra instalar com pacman -S cowsay ou num Ubuntu acho que um apt install cowsay também funciona. Daí abre um terminal e digita cowsay seguido de uma mensagem qualquer e olha o que aparece.

Sim, esse programa desenha uma vaca com caracteres ASCII na tela. Só isso. Você já viu um programa mais inútil que isso? E mesmo assim é um programa que todo mundo que usa Linux faz algum tempo sabe que existe. Pode sair perguntando pros seus amigos mais veteranos e todos eles vão saber disso. Esse programa existe faz anos, foi escrito em Perl e eu acho que é um excelente exercício pra um iniciante de qualquer linguagem. Experimente fazer um cowsay em Javascript, ou em C# ou em Go, não importa. E pra que? Pra absolutamente nenhuma razão, só pra fazer. Jogue fora no final, faça de novo em outra linguagem, faça outra imagem diferente da vaca, como do pinguim Tux que é outra opção desse programa. Só faz. Programar não tem que ter outro objetivo além de programar em si mesmo. O código no final não é importante, só saber que você é capaz. No final pode jogar fora esse código.

Aliás, eu fico pasmo e chocado quando vejo gente com medinho de começar a escrever código sem objetivo, sem utilidade, com a mentalidade que se ele não fizer algo que funcione perfeito, nem vale a pena começar a fazer. Mas ao mesmo tempo perde horas vendo TikTok, Instagram, jogando Candy Crush ou LOL ou qualquer outra porcaria desses. O que você produziu depois de ficar 1 hora jogando LOL? Absolutamente nada. Ficou mais rico? Não. Ficou mais inteligente? Não. Avançou sua carreira? Não. Foi uma total e completa perda de tempo. Mas você fez mesmo assim. Encare fazer código da mesma forma. Só faça, sem objetivo. Garanto que vai ser mais útil fazer um cowsay pra jogar fora do que jogar meia hora de Candy Crush.

Aprendizado, gestão, empreendedorismo, qualidade, todas essas palavras subjetivas pra mim se resumem a uma coisa: gerenciamento de risco. Gerenciar risco não significa ter zero risco. Muita gente medrosa acha que o objetivo é zerar os riscos. Zero risco é você nunca sair da sua cama, porque só de se levantar você corre o risco de tropeçar, bater a cabeça e morrer. Todos os dias você aceita diversos riscos. Risco de morrer num acidente de carro. Risco de ser morto num assalto na rua. Risco de um fucking meteoro cair na sua casa. Não existe vida sem risco. Se você tentar só minimizar risco, é a mesma coisa que não viver. Morre de uma vez então. Em vez disso assuma que o risco vai existir e você vai avançar de forma prudente, só isso.

Pra finalizar esse motivacional, relembrei de um video motivacional que eu mostrava em palestras que eu fazia lá por 2010 e 2011. É super clichê. Mas nem por isso é menos verdade.

(life == risk)

De novo, nada disso significa ser imprudente. Significa ter coragem. Pra ter coragem você não precisa quebrar leis nem migrar pra esportes radicais. Significa a coragem de simplesmente fazer uma página de código inútil que vai jogar fora no final. Significa testar uma idéia num projeto, num ambiente controlado, e assumir que se não der certo, tudo bem porque o experimento no mínimo vai te informar que aquela direção não ia dar certo. Saia da ordem tempo suficiente pra testar um caos controlado, aprender algo com isso, e reajustar pra uma direção melhor.

Em vez de tentar prever o futuro e errar completamente, você vai ajustando a direção um pedaço de cada vez até chegar no objetivo que queria, com menos desperdício do que se tivesse tentado planejar tudo em detalhes desde o começo. Tentar planejar todos os passos antes de começar a achar que vai conseguir adivinhar todos os passos até o fim é o maior desperdício de todos. Em gerenciamento de risco a máxima é que se sentar ter zero riscos vai acabar tendo 100% de perda. Gerenciar riscos é que nem um seguro de carros. Todo ano você paga e parece um desperdício porque nunca tem um acidente. Imprudência é decidir que isso é um desperdício e cancelar o seguro. É quando você vai ter um acidente feio e não vai ter dinheiro pra cobrir o prejuízo. Isso sim é um desperdício de verdade. Aceite um prejuízo pequeno pagando o seguro. Economia porca não é a mesma coisa que não desperdiçar.

Isso tudo dito, agora eu quero que vocês pensem em outra coisa. Tudo isso que eu falei aqui, eu não li num post de blog essa semana e vim repetir pra vocês. Quem acompanha meu blog desde pelo menos 2008 já leu algumas dessas coisas. Eu sempre tive as mesmas dúvidas que todos vocês. Será que eu estou estudando do jeito certo? Será que estou gerenciando projetos da melhor forma? Será que administro empresa do jeito certo? E se não ficou claro, todas essas perguntas sempre são a mesma coisa. Administrar uma empresa, gerenciar um projeto ou aprender algo novo, tem os mesmos princípios. Você é uma empresa de uma pessoa só, sua carreira é um projeto, e tudo é um aprendizado. Não são assuntos distintos.

Como você vai aprender se não sabe o que significa aprendizado? Como vai entregar um projeto se não sabe definir o que é gerenciar? Como quer empreender se sequer sabe definir o que significa a palavra empreender? A maioria de vocês tem um entendimento superficial dessas palavras e os diversos posts de Linkedin, palestras de gurus e videos de influencers, cada um vai vomitando definições erradas, sem dar fontes, dizendo só o suficiente pra você comprar os cursos deles. Fazendo frases bonitas de efeito com tom afirmativo e confiante. É tática de vendedor e você cai que nem um pato, porque tem preguiça de pesquisar.

Ao mesmo tempo que sempre teve um monte de coisas de programação e tecnologia que eu queria aprender e nunca parei de estudar, eu me cansei de não ter certeza e em paralelo gastei uma década estudando todas as coisas que mencionei neste video e muito mais. Essas coisas não se ensina na escola. Quem é de engenharia de produção deve ter reconhecido quando falei sobre coisas como Lean e Six Sigma. Quem é de física e biologia reconheceu quando falei de transição de fases e adaptabilidade. Quem é de economia já deve ter ouvido conceitos similares também.

Parte da sua carreira, se quiser evoluir pra uma etapa superior, é sair da sua própria área e investigar um pouco da área dos outros, em particular das ciências de verdade. Vai notar que muitos assuntos que discutimos em engenharia de software como se fosse uma grande novidade na verdade já existe em economia, física, biologia, outras engenharias, faz décadas. Pare de ler posts motivacionais de LinkedIn, que contribuem zero pra sua carreira, e busque a literatura original. Eu sempre falo que os livros que realmente compensam ler precisam passar pelo teste do tempo, e a maioria é do século passado. No meu caso, eu tive a sorte de esbarrar em alguns deles lá atrás, nos anos 90 e começo dos anos 2000. E já adianto que de lá pra cá não teve tanta novidade não, só os mesmos assuntos que ganharam outros nomes e por isso parece que tem tanta coisa nova. De novo, técnica de venda, marketing, e você continua caindo. Os últimos 10 anos foram muito tediosos nesse sentido.

Em resumo, por mais estranho que os conceitos apresentados pareçam, é basicamente assim que todo ecossistema da natureza funciona. Sem um sistema centralizado de autoridade. Sem um planejamento centralizado. Sem uma ordem definitiva que todos os animais e seres vivos sigam. À primeira vista parece um sistema fechado que vai deteriorar com o tempo, aumentar a entropia, como na segunda lei da termodinâmica. Mas em vez disso sabemos que não só esse sistema não deteriorou como evoluiu, desde microorganismos nos oceanos milhões de anos atrás, até a diversidade de espécies que temos hoje. Esse é o resultado de um sistema de beira do caos.

Mais importante, descentralização, livre competição, adaptação, são características de um sistema natural. Autoridade centralizada, planejamento ordenado, são características de um sistema artificial que sempre deteriora. É inevitável. Portanto tirem da cabeça que qualquer sistema assim possa jamais funcionar, seja sistema educacional, sistema empresarial, sistema econômico ou sistema político. Mesmo que por um curto período de tempo parece que funciona, eventualmente começa a deteriorar.

Enfim, como disse no começo, a intenção desse episódio foi só apresentar as fontes de onde tirei meu modelo mental de como fazer as coisas. A idéia não é vender nada e nem dizer que essa é a única maneira de pensar. Só uma introdução pra desmistificar o que alguns gurus possam estar tentando te vender de forma incompleta como se fosse grande novidade. Eu tenho um pensamento quase obcessivo nessa idéia de beira do caos e melhoria contínua. Toda vez que estou fazendo a mesma coisa do mesmo jeito por muito tempo, eu preciso chacoalhar e fazer alguma coisa diferente.

E pra quem chegou faz pouco tempo no canal. Eu venho contando aspectos disso em diversos videos, em particular na playlist de carreira, onde falo sobre faculdade, mercado, carreira e como encarar os desafios de se comprometer, assumir suas responsabilidades e parar de terceirizar suas decisões pra um influencer bosta qualquer. O medo é sempre o mesmo: e se eu errar. Ué, se errar errou. Levanta, e faz de novo, diferente, pra não errar a mesma coisa. Louco é aquele que fazendo sempre a mesma coisa, espera ter resultados diferentes. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais.

No episódio “Esqueça Metodologias ‘Ágeis’” eu critico como consultorias e coaches deturparam e prostituíram as idéia originais de agilidade.

O episódio de hoje continua na mesma idéia de como a idéia do tal “Modelo Spotify” ou “Modelo de Squads” foi também surrupiada pelos mesmos perpetradores e deturpada até o próprio Spotify não reconhecer mais.

Mas eu resolvi andar a última milha e ir além, eu quero usar o que o paper do Spotify descreve pra explicar de onde vêm conceitos como “Auto-organização”, o que de fato são “organizações ágeis” e quais são todos os erros que que todas as empresas cometem quando pensam em implementar metodologias desse tipo.

O vídeo é BEM longo, e a primeira metade vai soar bastante estranho. Em algum momento vocês vão pensar “onde esse cara tá querendo chegar”, mas eu peço que tenham um pouco de paciência e assistam até o final pra entender meu ponto.

Links:

• Scaling Agile @ Spotify with Henrik Kniberg (https://www.youtube.com/watch?v=jyZEikKWhAU)

• MARCIN FLORYAN | From Principles to Practices | Agile Rock Conference (https://www.youtube.com/watch?v=QX2RN07P4Hg)

• Marcin Floryan | There is no Spotify Model | Slides (https://www.infoq.com/presentations/spotify-culture-stc/)

• 3 Razões Porque O Modelo Do Spotify Não Serve Para Você (https://raphaelmolesim.github.io/spotify-model/#/)

• O modelo Spotify não é nenhum “Nirvana da Agilidade” (https://www.infoq.com/br/news/2018/02/spotify-agile-nirvana/)

• Demystifying Conway’s Law (https://www.thoughtworks.com/insights/blog/demystifying-conways-law)

• The Science of Sync (https://www.ted.com/talks/steven_strogatz_on_sync?language=en#t-1296137)

• The Misunderstood Nature of Entropy (https://www.youtube.com/watch?v=kfffy12uQ7g)

• Reversing Entropy with Maxwell’s Demon (https://www.youtube.com/watch?v=KR23aMjIHIY)

• AkitaOnRails Management Posts (https://www.akitaonrails.com/management)

=== Script

Olá pessoal, Fabio Akita

O vídeo que eu fiz chamado “Esqueça metodologias Ágeis” fez um sucesso enorme no canal e vocês andaram compartilhando pra lá e pra cá e eu agradeço bastante por isso! Eu fiz o video como faço todos os outros: eu peguei um assunto que me interessa e tentei explicar de uma forma que a maioria consiga entender, e eu realmente não esperava que fosse viralizar assim. Ao que parece muito mais gente do que eu pensava estava incomodado com as mesmas coisas.

No vídeo de hoje quero fazer uma continuação. O problema original foi como uma Boa idéia que é o conceito de agilidade foi prostituído e transformado em um produto que consultorias e coaches vendem e cuja implementação em nada lembra os objetivos originais do Manifesto. Quando nós agilistas dizemos que Ágil está morto significa dizer que o que você consome hoje como Ágil provavelmente não é mais Ágil.

Eu venho pesquisando, aplicando e escrevendo a respeito do assunto geral de gerenciamento faz mais de 10 anos. Se você entrar no meu blog na url akitaonrails.com/management vai encontrar artigos e traduções que eu acumulei desde 2007 até pelo menos 2017. Recomendo dar uma olhada nesse material também.

À medida que os termos de agilidade se tornaram diluídos ao ponto de quase não reconhecermos mais, assim também aconteceu com outros conceitos do passado como o Lean da Toyota que hoje virou o irreconhecível Kanban ou Lean Startup. E agora outro conceito que vem sendo esticado além do que deveria que é o tal modelo do Spotify ou modelo de Squads. A idéia desses episódios não é dizer que agilidade, lean ou Squads não funcionam. Claro que funcionam, só que eu vou argumentar que quase todas as pessoas implementando esses modelos vão fracassar.

(…)

O que é o tal modelo do Spotify? Eu não vou explicar em detalhes, porque assim como Scrum ou Lean, você pode ir no Google e vai achar dúzias e dúzias de posts de blog, palestras e até eventos repetindo as estruturas como se não houvesse amanhã. Então vou resumir. Todo mundo a essa altura já conhece o conceito de equipes cross-funcionais, ou feature-teams, que no Spotify eles decidiram chamar de Squads. São como unidades de negócios numa organização em matriz, estrutura que se conhece desde os anos 80 por causa da Digital Equipment Corporation, ou DEC.

Teoricamente, um Squad é responsável por uma funcionalidade ou feature inteira, do design, programação até deployment. Por exemplo, um squad que lida só com a feature de playlist, ou outro só com a organização de álbuns. Você também pode ter dois ou mais squads que no fim acabam lidando com a mesma funcionalidade ou experiência do usuário, então esses squads se coordenam no que eles chamaram de tribes.

Cada squad é composto por profissionais de diferentes capacidades, então além do Product Owner ou PO, você pode ter um designer, quatro programadores, dois devops, um tester e assim por diante. Dois ou mais testers de múltiplos Squads formam outra organização horizontal chamada Chapters, por exemplo Chapters de devs front-end ou chapters de QA.

Por fim, você pode ter grupos com interesses similares mas não necessariamente do mesmo squad e nem do mesmo chapter, e pra isso eles se organizam em Guilds. Em termos de estrutura é só isso. Basicamente você chama departamentos de chapters, unidades de negócio de squads e tribes, e grupo do bebedouro ou cafezinho de guilds e boom, temos o modelo do Spotify.

Mais importante do que a estrutura são os princípios e aqui a coisa fica mais interessante. Nenhum dos pontos que o Spotify listou no seu modelo são novidades ou estão errados, são todos os mesmos pontos que qualquer um que já tenha lido The Mythical Man Month, Extreme Programming, The Pragmatic Programmer, Continuous Delivery do Martin Fowler, e mesmo os originais de Scrum do Ken Schwabber, ou Feature Driven Development do Jeff de Luca e Pete Code já ouviram falar várias vezes.

Quando o Spotify fala de Release Trains, Feature toggles ou feature flags, é tudo conceito de continuous delivery. Pra chegar ao nível de continuous delivery você precisa ter tudo que o Extreme Programming já ensinou: incluindo continuous integration.

Como eu disse no começo, o modelo Spotify não tem nenhum problema em si. Ele é meramente uma descrição do estado que supostamente, supostamente, estava a organização do Spotify por volta de 2012 a 2014 que foi quando eles soltaram o post de blog com o paper descrevendo o modelo e quando o Henrik Kniberg começou a palestrar e evangelizar o modelo em eventos de agilidade.

Eu fico pasmo vendo gente agora em 2019 vendendo explicitamente a implementação do tal “modelo Spotify” quando temos pessoas como o Marcin Floryan, diretor de engenharia do Spotify explicitamente explicando em palestra que Não existe um modelo Spotify. Vou deixar linkado a palestra dele do ano passado, onde ele mesmo diz que o que estava no paper de 2012 sequer descrevia corretamente como as coisas eram em 2012 e certamente já é diferente de como estava em 2018. Por isso eu disse “supostamente” agora a pouco. Ele fez questão de dizer: sabe porque chamamos as estruturas de Tribes ou Chapters? Porque ninguém estava usando esses termos antes! A idéia era criar um vocabulário próprio pra diferenciar dos outros. Por isso mesmo se você começa a copiar o modelo do Spotify pelo vocabulário, você já perdeu o ponto.

E sendo justo, se você pesquisar direito, no Google mesmo vai achar diversas pessoas, inclusive no Brasil, corretamente explicando porque o modelo do Spotify não é algo que você deva sair copiando. Exemplo disso é a palestra de Thiago Soares e Raphael Molesim chamado “3 razões porque o modelo do Spotify não serve pra você”, que vou deixar linkado os slides nas descrições abaixo. As explicações variam em qualidade e escopo, mas em princípio eles estão corretos. Por isso me deixa pasmo ainda ver empresas contratando coaches pra implementar esse elusivo pseudo-modelo.

E onde funciona o modelo do Spotify? Bom, se você for uma plataforma de música com milhões de usuários, em Stockholm, com várias pessoas que vieram da universidade KTH, em 2012, talvez esse modelo se encaixe. Ou seja, se você for o Spotify, então o modelo Spotify talvez faça sentido, por um período de tempo. Parem de comprar balas de prata! Balas de prata não existem! Qualquer empresa que compre um modelo como o do Spotify pra alguém implementar é só preguiçoso e não quer de fato entender como organizações funcionam. Parem de comprar implementação de modelos, seja de Spotify, seja de Lean, seja de Ágil ou qualquer variante.

Agora vem a parte difícil da minha explicação e eu vou ser o primeiro a dizer que eu mesmo tenho muita dificuldade de explicar isso. Se implementar modelos não funciona, o que a gente deve fazer?

Primeiro de tudo vocês precisam entender o que são modelos. Modelos são nada mais, nada menos, do que a descrição em forma de texto de uma observação em algum ambiente específico durante um período curto e finito de tempo. Por exemplo, eu poderia definir o modelo “Nature”, natureza mesmo. Poderia falar que eu vejo como ecossistema nas savanas da África são eficientes e auto-sustentáveis, poderia dizer como os animais se organizam em Bandos ou, em inglês pra ficar mais marketável, vamos chamar de Herds. Então esqueçam Squads, vamos implementar Herds.

Posso dizer como a natureza foi sábia em fazer as leoas atacar os antilopes, zebras e gnus, então podemos implementar herds que se alimentam de outros herds, afinal é uma cadeia alimentar e isso faz sentido, o herd que ganha fica com o budget do herd que perdeu. O Herd Lead é o leão, claro. Mas outros herd leads podem clamar a posição e então eles podem se desafiar e quem matar o outro se torna o lead daquele herd. E assim eliminamos a necessidade de precisar fazer reuniões e stand ups pra discutir o assunto, basta um lead tomar a posição do outro. E como diz o nome da metodologia “Nature” é tudo naturalmente justificado e fácil de entender. Olha só que da hora, acabamos de inventar mais um modelo. Coaches, quero meus royalties se vocês implementarem!

Piadas à parte, agora vamos falar sério. O que está errado não é a configuração das estruturas de Squads ou Tribes do modelo descrito. O problema é que modelos são meras fotografias de um processo em constante mudança. Você não implementa modelos de gerenciamento de cima pra baixo e espera que tudo funcione. Por exemplo, eu sou uma instituição que por N motivos é gigante, uma instituição financeira, vamos dizer. Ao longo dos anos acumulamos 4000 funcionários. Só que a cada ano a entrega das coisas fica mais lenta e mais custosa. Enquanto isso essa nova onda de fintechs tá aí, atacando sem parar, sendo mais rápidos e mais eficientes. Precisamos evoluir!

E pra evoluir o que fazer? Oras, vamos ver os modelos que tem no mercado e reconfigurar todas as nossas equipes! Vamos desintegrar as unidades de negócios e departamentos que temos hoje, dividir todo mundo em equipes cross-funcionais, mudar fisicamente o lugar de todo mundo em Squads! Pronto! Agora vamos começar a entregar com velocidade de startup! Menos, bem menos … Em qualquer implementação desses tipos de modelos, você sempre vai ver alguns resultados muito acima da média com alguns resultados medíocres ou bem abaixo do esperado. Você esconde os resultados ruins, reporta os bons pra diretoria e pro conselho e a vida segue.

O problema é o seguinte: em qualquer empresa, se você implementar qualquer modelo dessa forma, você vai sim ver algum resultado, especialmente se sua empresa era uma porcaria pra começo de conversa. Qualquer coisa é melhor do que nada num ambiente estagnado, você adiciona energia, joga um pouco de caos num lugar onde a entropia já começou a desintegrar a eficiência, e naturalmente vão emergir nichos de resultados até que bons. Isso acontece em qualquer lugar. Porém isso é um efeito colateral, não o efeito principal. Se for só isso que você fez, muito em breve a mudança vai se tornar o novo status quo, o nível de energia vai voltar ao normal, e a entropia volta a aumentar começando a deteriorar o novo modelo também. É inevitável.

Agora vem uma parte que eu pessoalmente gosto mas que é tão difícil de explicar que você vai ser obrigado a meio que engolir minha cagação de regra e depois buscar os detalhes. Como eu disse, eu escrevi bastante sobre isso no meu blog, tem vários artigos com mais detalhes. Mas você vai notar que no paper e palestras do povo do Spotify, bem como em material original de Scrum ou no próprio Manifesto de Desenvolvimento Ágil de Software, um termo que aparece bastante é Auto-organização e em alguns lugares aparece o tempo Complex adaptive systems, e com mais frequência mas sempre interpretado da maneira errada aparece a palavra Autonomia. Esqueça todas as estruturas, squads, chapters, sprints, scrums, kanbans, six sigma, e qualquer outra coisa. Enquanto você não entender o que é auto-organização, nada mais interessa.

Complex adaptive systems ou sistemas adaptativos complexos é um termo que vai aparecer em lugares tão diferentes quanto biologia, física, matemática. Se eu for explicar de maneira muito, muito grosseira, vamos pensar no seguinte: o que estamos tentando fazer é criar uma organização o mais eficiente possível. O que são organizações? São formas de organizar pessoas em torno de algum objetivo em comum. Ou mais corretamente, são formas que as pessoas se organizam pra atingir algum objetivo. Complexo não quer dizer difícil ou que você precisa de um phd pra entender. Pense num sistema como um grupo de agentes, onde cada agente tem possibilidades de se comunicar com outros agentes. Como já expliquei no vídeo sobre The Mythical Man Month, as linhas de comunicação aumentam muito rápido, de forma não-linear, com a inclusão de poucos agentes. Quanto mais agentes, mais complexas se tornam as linhas de comunicação. É muito difícil prever o comportamento desse sistema só observando o comportamento de um agente individualmente. A interação dessas linhas de comunicação criam redes dinâmicas complexas. Complex adaptive systems é um sub-grupo de uma área maior chamada Non Linear Dynamical Systems. A palavra chave é não-linear. Ou seja, se dobrarmos a quantidade de agentes, a complexidade não dobra, ela pode ser exponencial e aumentar ao quadrado ou mais.

Quando eu tento aprender uma coisa, mesmo em software, eu não procuro só na área de software. Obviamente outras áreas provavelmente já apanharam no assunto muito antes de nós, então eu tento estudar fora e ver o que já foi estudado. É claro que existem formas de organização diferentes de empresas. Todos nós vivemos já em alguma organização fora das empresas. Nossa família é uma organização, com hierarquia baseada na senioridade dos membros, onde teoricamente você devia respeitar sua mãe e seu avô, por exemplo. As famílias vivem em bairros ou comunidades, onde elas interagem e convivem umas com as outras, uns ajudando os outros ou fofocando sobre os outros pelos cantos, como todos gostam de fazer. Essas comunidades formam cidades, que se aglutinam em estados, que são unidos num grupo maior chamado país. E por último os países se organizam em blocos econômicos pra realizar comércio entre si.

Mas muito, muito antes disso, centenas de milhões de anos atrás, tivemos os primeiros seres monocelulares. Esses seres não tinham cérebro nem nenhum tipo de cognição, não tinham ambições de dominar o planeta ou mesmo consciência de que eles estavam em um lugar chamado planeta. Com os objetivos mais simples e imediatos como conseguir comida e reproduzir, eles foram se organizando e se aglutinando. Milhões de anos se passam e eles foram organismos multicelulares. Algumas dessas combinações dão errado e eles não sobrevivem no ambiente, alguns dão certo e eles conseguem reproduzir e criar mais cópias com características similares. Alguns desses grupos se separam do original e vagam pra mais longe, eventualmente alguns saem do mar e encontram terra. E agora temos grupos que vivem no mar e grupos que vivem na terra. Se você nunca leu a fascinante história da evolução recomendo que leiam livros como The Selfish Gene de Richard Dawkins.

Enfim, todo mundo aprendeu em biologia como literalmente do nada, por mero acaso e coincidência, uma combinação aleatória de fatores permitiu o surgimento das primeiras proteínas no ambiente precário da Terra do passado e com o passar dos milênios esses organismos foram se auto-organizando e evoluindo. Tentativa e erro atrás de tentativa e erro. Cada nova tentativa que deu certo deixando descendentes. E ao longo de centenas de milhões de anos saímos dos organismos monocelulares até chegar ao Homo Sapiens moderno e seja lá qual for a próxima evolução da nossa espécie. E antes que alguém comente, não, isso não é teoria que ainda não se tem certeza, já é um fato e uma lei. Nenhum ser divino fez um plano ultra detalhado e um belo dia disse “que se faça o ser humano” e boom, tudo apareceu como é hoje. É exatamente o que eu estou falando que também não funciona com implementação de modelos, um plano master que já nasce pronto e os divinos CEOs e COOs mandam implementar e você ganha um Spotify no dia seguinte. Aproveitando, se você nunca leu sobre o que é o método científico propriamente dito, recomendo que leia o clássico The Demon-Haunted World, Science as a Candle in the Dark do lendário Carl Sagan.

Eu brinquei falando da metodologia Nature antes mas foi uma meia brincadeira, porque foi exatamente assim que as coisas aconteceram e continuam a acontecer. O ecossistema natural, que compreende não só os grandes animais mamíferos que conseguimos ver mas até os micróbios e bactérias, todas existem num ambiente em equilíbrio dinâmico. Aliás, esse é outro conceito que vocês precisam entender: quando falamos em equilíbrio a maioria pensa em equilíbrio estático, que significa chegar num certo nível e não mexer em mais nada. Equilíbrio dinâmico é assim: nesta década nasceram pessoas demais, na década passada morreram pessoas demais, beleza, na média deu 0, estamos em equilíbrio, dinâmico. Nunca considere equilíbrio como sendo algo fixo ou estático mas sim sistemas que trocam energia entre si e na média estão em equilíbrio.

Essa história toda é pra encaixar alguns termos. Na sopa primordial do começo dos tempos na Terra tínhamos praticamente puro caos. Caos é basicamente desordem. Milhares de tipos diferentes de componentes químicos expostos numa terra em formação, ar irrespirável, trovões e raios. A parte interessante do Caos é que ao contrário do senso comum, a ordem tende a emergir do Caos. Da ordem surge entropia e entropia pode levar de volta ao caos. Por pura sorte, se você der tempo suficiente, milhões de anos, numa sopa de caos, é probabilisticamente inevitável que uma combinação de materiais químicos e energia vai acabar resultando em elementos como aminoácidos. E isso é o processo de evolução: seleção natural em mutações que surgem aleatoriamente. As mutações são aleatórias, a seleção natural não é, ela é cumulativa, por isso a evolução tende, no geral, a andar pra frente.

Agora entenda uma limitação da biologia: carregar a melhor combinação de genes acontece via reprodução. Dois animais precisam reproduzir pra gerar um filhote que carrega a combinação dos seus genes e talvez uma ou outra mutação acidental. É uma combinação de 2 pra 1 durante semanas ou meses. Idéias, ou o que Richard Dawkins cunhou como memes, tem a vantagem de ser N pra M em vez de só 2 pra 1, e não precisa de mais que alguns segundos pra reprodução de um novo meme. Fora que memes não precisam andar pra frente, ele pode fazer o equivalente a incesto e reproduzir com os pais, ou com os irmãos. Idéias podem ser misturadas pra qualquer direção. E a propagação de memes é muito mais rápida que a propagação de genes, por isso podemos fazer tentativas e erro muito mais rápido, criar mutações de memes e fazer seleção artificial dos melhores memes. O que no mundo biológico levaria centenas ou milhares de anos, no mundo da memética, das idéias, podemos executar em minutos ou horas. Organizações ou modelos de organização são idéias, memes, e eles podem e devem estar evoluindo constantemente. Nenhuma idéia é sagrada demais que não possa ser contestada e substituída.

Teoria do Caos é uma vertente da física, a maioria das pessoas vai reconhecer por causa do exemplo clichê da borboleta que bate as asas no Brasil causando um furacão no Texas. Ou os filmes do Efeito Borboleta como Ashton Kutcher, a idéia de que um pequeno evento causa efeitos em cascata imprevisíveis. E é isso mesmo: sistemas dinâmicos, que são altamente sensitivos a condições iniciais, embora aparentemente aleatórios, começam a demonstrar padrões emergentes, constante feedback loops - outro termo usado na palestra do Spotify - repetição, auto-similaridade, fractais e por fim, auto-organização.

Nós estamos acostumados a criar correlações entre causa e efeito de forma linear. É a descendência do pensamento determinista de René Descartes, melhor representado pelas equações da física de Isaac Newton. A física de Newton descreve um mundo determinístico, se eu souber a posição inicial, a velocidade inicial e a aceleração de alguma coisa, eu consigo saber onde no futuro esse alguma coisa vai estar com precisão. Consigo saber onde certo planeta vai estar, com precisão, daqui 50 anos. Se você parar pra pensar nisso, seu pensamento foi naturalmente treinado pra pensar em determinismo, previsibilidade, e praticamente a acreditar em destino.

Porém, o mundo real não é tão determinístico assim, especialmente depois da Teoria da Relatividade e Física Quântica. Aliás, aqui tome muito cuidado: você tem certeza que está vendo um charlatão quando ele aplica conceitos de física quântica no mundo macroscópico. Entanglement só existe no mundo sub-atômico, então esqueça essas teorias new age de consciência coletiva. Trabalhos como esse (What the bleep to we know) ou esse (The Secret) ou esse (Deepak Chopra) são todos bullshit de pseudo-quânticos e pseudo-ciência.

Agora, o comportamento de animais num ecossistema, o comportamento de seres humanos em mercados, o comportamento de particulas sub-atômicas, o comportamento da luz ao redor de um buraco negro, tudo isso não é trivialmente determinístico. E agora temos diferentes escolas com modelos pra entender essas coisas, em particular Teoria do Caos.

Existem alguns autores que eu vou recomendar que vocês leiam se tiverem interesse: Chaos, the new Science do James Gleick. Se você não sabia, o personagem Iam Malcolm de Jurassic Park foi inspirado em Gleick. Um autor extremamente importante pra entender sistemas não lineares e emergência é Steven Strogatz, começando pelo NonLinear Dynamics and Chaos. Daí Sync: How Order Emerges from Chaos in the Universe. Strogatz foi mestre de outro autor importante pra entender como as idéias de sistemas não lineares afetam relacionamentos em grupos, que descrevemos como networks ou redes, Duncan Watts que escreveu sobre o famoso Six Degrees: The Science of a Connected Age. Se você já ouviu falar sobre os seis graus de separação e porque isso acontece, recomendo ler Watts e outro autor importante: Albert Lazlo Barabási com seu excelente livro Linked. Finalmente pros mais inclinados a matemática provavelmente um dos nomes mais importantes na área que é Paul Erdös.

Agora, como tooodo esse mambo jambo de ciências se encaixa na nossao discussão de modelos de organizações? Simples, porque pra todos os efeitos, especialmente quando você tem um número grande de pessoas, você pode tentar usar os efeitos de emergência e auto-organização. Em teoria do caos, pense em caos quando você tem desordem entre um número grande de agentes. Agentes podem ser qualquer coisa, um micróbio, um animal, um ser humano, ou até mesmo um ser inanimado, nem precisa estar vivo.

Steven Strogatz tem um vídeo interessante sobre emergência, do TED Talk de 2004, uma época onde TED Talks ainda valiam alguma coisa. Eu gostava muito de mostrar em palestras que eu fiz até 2009. Nós tendemos a achar que sistemas tendem a aumentar sua entropia e isso leva inevitavelmente à desordem, a entropia no universo tende sempre a aumentar e por isso não é tão óbvio de entender que ordem pode emergir desse caos. Mas sem entrar em muitos detalhes sobre segunda lei da termodinâmica, entenda que o universo como um todo pode aumentar a entropia, mas a entropia em sub-sistemas menores pode decair e sua ordem pode aumentar à medida que trocamos entropia de um sistema pelo outro. Recomendo que procure sobre o demônio de Maxwell e a entropia de Shannon, de Claude Shannon que escreveu sobre Teoria da Informação.

(starlings)

De qualquer maneira, entenda que no mundo real, coisas tendem a demonstrar comportamento de sincronização e ordem tende a emergir desses sistemas. O mambo jambo todo anterior é meio pra dizer que sim: sabemos que esse tipo de comportamento realmente acontece naturalmente. E como eu disse, você sequer precisa de seres vivos pra obter esse comportamento. Veja este exemplo de Strogatz.

(metronomes)

De tudo que já li a respeito, resumindo de forma bem simplória, temos organizações da era da Teoria X, onde assumimos que as pessoas que contratamos simplesmente nunca vão ter vontade de realizar nenhum trabalho, então criamos estruturas de microgerenciamento, pra garantir que cada engrenagem da máquina esteja funcionando como deveria. Seja numa empresa com 10 pessoas ou com 10 mil pessoas, colocamos todo mundo em pequenas caixas altamente reguladas e limitadas, com o mínimo possível de liberdade. É um sistema de baixa entropia, porém é um sistema com baixas chances de ordem emergente, pelo contrário é a que tende a entrar em decadência mais rápido e exige quantidades maiores de energia entrando nesse sistema para manter a baixa entropia. Por isso custa caro, precisamos de grandes hierarquias, enormes quantidades de regras e procedimentos, pra manter o sistema em ordem.

Na teoria Y as premissas são diferentes. A palestra do Spotify de Marcian cita leituras como o livro Drive de Daniel Pink. Por acaso outro autor que eu citei como se não houvesse amanhã lá por 2008 e que fala sobre motivação, não era mais pra ser nenhuma novidade hoje. O conceito é simples mas não deve ser confundido com o que se fazia nos anos 90 onde começaram movimentos motivacionais, o famoso vamos juntar todo mundo da empresa pra se conhecer numa chácara, e fazer todo mundo se importar uns com os outros, todo mundo abraçar árvore e mimimi. Esse conceito até eu já considero bem antiquado.

A hipótese de Daniel é que empresas, chefes, não tem como motivar as pessoas. É impossível. As pessoas motivam elas mesmas. Segundo Daniel, o que as pessoas procuram é Autonomia, Mastery que eu não sei como traduzir em português mas seria a vontade de ser melhor no que faz, e Propósito. E daí você vê de novo a palavra Autonomia que aparece no paper do Spotify e inúmeras outras metodologias.

Na teoria de emergência de Strogatz existe outro insight que eu considero importante. Vemos no vídeo aquele bando enorme de pássaros todos voando em sincronia, formando uma coreografia no ar, e conseguindo desviar de predadores e rapidamente avisar os pássaros que estão dezenas de metros mais à frente através da propagação de ondas, que é uma maneira de propagar informação de forma eficiente pra frente. Entao os pássaros vão desviando dos ataques e rapidamente retornam à formação próximo um dos outros. O bando inteiro, olhado de longe, parece um grande organismo.

É a propriedade de auto-similaridade e fractal do comportamento emergente de sistemas complexos adaptativos. O mesmo comportamento pode ser observado no nível microscópico como células ou no nível macroscópico como bando de pássaros ou peixes. E ao contrário da nossa tendência antropomórfica de imaginar que os pássaros de alguma forma se importam uns com os outros e por isso andam em bando, não, não existe essa correlação. No exemplo da simulação de computador, basta termos agentes completamente egoístas, que tendem a voar perto dos demais, desviar de outros agentes tentando voar por cima deles, e tentar retornar pra perto do bando quando puder.

Por que eles voam em bando? Por que aumenta as chances individuais de sobrevivência de cada indivíduo. O predador vai acabar pegando alguns, mas se você tentar voar sozinho separado do bando, você é o alvo fácil. Portanto pra ter comportamento emergente de grupo, trabalhando em sincronia, sequer existe a necessidade de alguma causa em comum. Basta que cada agente do grupo tenha liberdade de reagir em favor de seu próprio interesse individual e encontrar valor em preservar sua estadia no grupo pra atingir esses objetivos.

Como eu disse, eu poderia ficar semanas esmiuçando todas as vertentes de teoria do caos de maxwell, mandelbrot, lorenz, começar a chegar na física termodinâmica, explorar todas as derivações da segunda lei da termodinâmica, entropia, conservação e transferência de energia, teoria da informação, até esbarrar na teoria quântica com von neumann. E mesmo depois de tudo isso, a aplicação em teoria das organizações continua sendo mais especulativa do que uma aplicação consistente. A idéia não é dizer pra começar a fazer equações físicas pra descrever organizações, mas já que todo mundo fica roubando vocabulário da física e biologia eu resolvi mostrar de onde vem essas palavras que todo mundo usa sem saber do que se trata.

A maioria dos trabalhos de organizações, por alguma razão, tende a convergir pra essas vertentes de estudo. Mas, isso só vai ser útil se você é nerd como eu e gosta de tentar entender os mecanismos das coisas. Mas com tudo isso dito o que eu concluo é o seguinte. Comece pensando no indivíduo. Evite pensar em grupos ou comunidades. Todo mundo gosta de ser politicamente correto pseudo-socialista pró-causas sociais e bla bla bla. Tudo isso é bonito, é marketável, mas falando friamente em organizações, elas são irrelevantes.

O erro é tentar formar grupos de cima pra baixo, é mais fácil dar a direção e deixar os grupos se formarem sozinhos, emergirem a partir das vontades individuais de cada agente no sistema. Você tem duas maneiras de obter ordem nesse tipo de sistema. Um deles é de alto gasto de energia, que é via microgerenciamento. Você precisa tornar as coisas difíceis pra todo mundo, gastar muita energia pra conseguir fazer alguma coisa, e assim você obtém o maior grau de ordem, porém com o menor grau de mobilidade. Você estabelece um microestado e cada agente vai ficar preso no mesmo lugar, o sistema fica estático e tende a se linearizar.

Você pode ir pelo caminho do mínimo esforço, que seria literalmente apostar no caos e esperar a ordem emergir naturalmente. Porém a probabilidade de você chegar num microestado dentre milhões de combinações aleatórias diferentes em tempo hábil tende a zero. Ou seja, simples anarquia não vai te levar a um lugar algum, a menos que você seja muito sortudo. E nem vou dizer que isso não acontece.

Por fim, só existe uma outra solução: trabalhar no limite do caos, o Edge of Chaos em Teoria do Caos. E aqui vou ter que ser nerd de novo. Em termos simples pensa em transições de fase. Da água líquida pra cubo de gelo, é uma transição de fase de um estado de maior desordem pra um estado de menor desordem. Quando pesquisadores começaram a explorar esse limite entre as fases começamos a falar sobre adaptação.

Adaptação no limite do caos se refere à ideia de sistemas complexos adaptativos de intuitivamente evoluir a um regime próximo às fronteiras entre caos e ordem. Muitos começaram a discutir alguns anos atrás sobre aprendizado no limite do caos. E eu não lembro onde li que tentava demonstrar que uma organização de aprendizado é justamente uma organização que consegue andar na linha bamba próximo ao limite do caos. Na realidade, variando de forma controlada entre momentos de ordem e momentos de caos.

Se de novo isso parece um pouco familiar com o comportamento de um modelo circular ou iterativo, não é mera coincidência. Pode ser uma das razões de porque modelos circulares parecem funcionar tão bem, e justamente porque quando você trabalha sobre muita coisa desconhecida, ir e voltar do limite do caos aumenta sua probabilidade de resolver o problema e aprender alguma coisa.

A vantagem desse tipo de organização é que ela teoricamente gasta menos energia pra manter com o trade-off de causar erros e desperdícios. E ao contrário de uma anarquia, ela maximiza a probabilidade de se chegar num estado de entropia que forneça máxima eficiência mais rápido. A forma de fazer isso é abrir mão do micro-controle. Você nunca, mas nunca, deve confiar cegamente nas pessoas. Porém você não deve controlá-las tão de perto. Você precisa ter mecanismos de auto-preservação no ambiente. De preferência deve fazer parte do interesse de cada agente nesse sistema trabalhar somente do lado de outros bons agentes, assim como no bando de pássaros, não pelo bem da empresa ou qualquer outra causa, mas pelo seu próprio bem, porque não faz bem pra reputação dele estar num grupo de gente ruim, por exemplo.

Finalmente chegando na parte importante, o que o paper do Spotify faz corretamente é falar sobre alinhamento e autonomia. Alinhamento é outro termo vago, mas é basicamente dar direção ao barco. Se os C-level da empresa não sabem pra onde o barco deve ir, fodeu, pra todo mundo. Mas partindo do princípio que a direção está clara, você pode dar a autonomia aos funcionários pra atingir esses objetivos da forma como quiserem. Mas não de qualquer jeito, direção exige regras claras. Não se trata de criar organizações democráticas ou holocracias.

Na prática, nenhum funcionário jamais deve ter autonomia completa numa empresa, por exemplo via voto da maioria. Uma empresa não é e nunca deve ser uma democracia, que é basicamente a máfia da maioria. E a explicação é simples: qualquer pessoa que continua ganhando a mesma coisa todo mês, independente se fez tudo certo ou tudo errado, não pode ter autonomia completa. Somente os sócios majoritários podem ter essa autonomia porque se tudo der errado, quem vai sofrer os ônus do prejuízo vão ser eles. Os funcionários ganham se forem mandado embora, inclusive. Por isso você como funcionário, nunca deve se sentir mal de não poder decidir o gasto do orçamento da empresa, não é da sua responsabilidade. Se quiser que seja, assuma o prejuízo e torne-se sócio. Por esse simples fato, democracias puras não tem como funcionar no ambiente privado. Pra assuntos mais relevantes como por exemplo, quais ferramentas de trabalho vão usar, quem vai fazer parte de qual equipe, ou seja, tudo que tem a ver diretamente com a competência para os quais os funcionários foram contratados, então sim, eles podem e devem ter autonomia.

E só essa autonomia já é suficiente se você não contratou um bando de idiotas. Essa é outra coisa que pouco se fala: um modelo de auto-organização só acontece com bons agentes no sistema, agentes que não se sabotam e atiram no próprio pé sem perceber. Novamente, definir o que são boas pessoas é complicado. A maioria das pessoas de recursos humanos é incompetente em reconhecer boas pessoas, porque elas procuram ou por quantidade de capacitações e experiência ou personalidade das pessoas, se elas parecem boazinhas ou simpáticas. E nenhuma das duas coisas está correto, boas pessoas são aquelas que procuram Mastery.

Se você assistiu meus videos neste canal, já deve ter ficado muito claro que eu estou tentando falar com um tipo muito específico de profissional, e não com todos: os que programam ou estudam programação porque gostam de programar. Não importa se vai trabalhar num produto unicórnio ou num legado de repartição pública. Não importa se vai ganhar 4 dígitos ou 6 dígitos de salário por mês. Claro, todo mundo gosta de reconhecimento, mas não é esse o drive mas sim o mastery, e por causa disso também não gostam de trabalhar com pessoas medíocres do lado deles, e não gosta de coisas mal feitas dos outros e, se puder, vai ajudar os demais ao redor espalhando conhecimento, ou se isso não der certo, vai expurgar os maus elementos. Mastery. O problema é que somente pessoas que são assim conseguem enxergar outras pessoas que são assim. Como diria Jobs: pessoas A contratam outras pessoas A, pessoas B sempre contratam C. E recursos humanos, desculpem, nesse quesito vocês são C contratando D, deixe esse trabalho pros A.

Partindo da premissa que você contratou gente A, e partindo da premissa que você tem direção bem definida, naturalmente uma organização que se parece com Squads, Tribes e Chapters vai emergir. E aqui parece um pouco mágica, mas é basicamente isso: dê a pessoas A, um ambiente A, e naturalmente uma auto-organização A vai emergir. E dar um ambiente A não significa piscina de bolinhas ou xbox na sala comum. Ambiente A significa um ambiente estável e simples, onde salários não atrasam, onde reuniões sem sentido não aparecem aleatoriamente, onde a direção não muda toda hora obrigando o trabalho a recomeçar o tempo todo, onde a comunicação é liberada e não precisa de formalidades, nem rituais, nem reuniões especiais, onde feedbacks podem ser repassados o tempo todo pra cima ou pra baixo, novamente, sem formalidade de avaliações 360 ou qualquer bullshit assim, ou seja, onde adultos podem trabalhar como adultos sem babás tentando trocar as fraudas deles toda hora.

Outra coisa é quando falamos de transparência, que é outra coisa importante. Transparência não é terapia de casal pra ficar expondo tudo. Informação inútil demais também não ajuda ninguém. No caso de programadores, todo programador deveria ter acesso a todo o código da empresa. Todo devops precisa ter acesso a toda a infraestrutura da empresa. Todos os designers precisam ter acesso a todo o roadmap de produtos da empresa. Porém, coisas como abrir faturamento, lucro, dívidas, conversas com investidor e todas essas coisas, é bonitinho mas é inútil pra maioria das pessoas. De novo, uma empresa não é nem deve ser uma democracia. Novamente, se você é sócio da empresa sim, deveria ter que ler essas chatices. Se você não é, então não faz diferença. Por muitos anos eu pensei o contrário, mas de fato nunca achei nenhum bom argumento pra justificar. Empresas privadas Não são órgãos públicos ou ONGs.

Todo o resto que você já viu sobre esse modelo está melhor descrito em todos os materiais que eu já repeti mil vezes como extreme programming. Por exemplo, continuous delivery. O código no master do repositório deveria estar sempre pronto pra deploy em produção. Pra isso nenhum desenvolvedor deveria subir código incompleto ou que crasheia o sistema. Pra isso todo desenvolvedor deveria desenvolver num branch, ou pull request no caso do GitHub, e só quando o código estiver completo, com testes automatizados, que passam pelo sistema de integração contínua, só aí ele deveria ser mergeado na master e somente quando pelo menos um colega de equipe revisar. É uma coisa meio básica, bem arroz com feijão mesmo, mas incrivelmente poucas empresas fazem isso.

Outra coisa é releases frequentes, porque se demorar demais pra lançar em produção começa a acumular muito código que nunca foi testado de verdade por gente de verdade, e quanto mais demorar maiores as chances desse deploy falhar. E quanto mais aumenta essas chances mais todo mundo prefere protelar pra fazer deploy e vira um ciclo vicioso. É melhor fazer deploys constantes, com bastante frequência. Assim, mesmo se tiver um bug, é mais fácil de reverter e consertar do que lançar uma tonelada de código novo de uma só vez e depois virar um pesadelo pra saber o que exatamente quebrou aonde. E é isso que nas palestras do Spotify o CEO fala que eles falham rápido toda hora. Fail Fast é um conceito que ficou famoso no Lean Startup, novamente nenhuma novidade.

Mas claro, ser assim o tempo todo é uma utopia, e nem no Spotify é assim. Nessa entrevista de 2018 com Joakim Sundén, que é “coach” de equipes e liderança no Spotify ele mesmo diz: Não me entenda mal: amo o Spotify, a nossa cultura e forma de trabalhar, mas está longe de ser um “Nirvana Ágil”. Aliás, uma coisa que sempre surpreende aqueles que tem uma vasta experiência com o Ágil é que as práticas de engenharia como TDD, programação em par, código limpo e design simples não são tão comuns por aqui. Squads que usam estas práticas geralmente são exceção, e não a regra. Na verdade, muitos squads não estão habituados nem com as práticas ágeis em geral. Talvez até fazem reuniões de planejamento, mas não necessariamente revisam o plano ou refletem sobre como melhorá-lo. As equipes que usam kanban raramente usam a limitação de trabalho em progresso, ou se usam, frequentemente a ignoram. Não estou dizendo que esta seja a realidade de todos as equipes, mesmo porque tendo na organização cerca de 150 equipes, não teria como saber detalhes de cada um. Estas observações vêm do trabalho feito com dezenas de equipes ao longo de seis anos, além de conversas com muitos outros coaches e Spotifiers.

E aqui vem uma coisa que eu digo faz anos: nenhuma metodologia vai salvar pessoas ruins. Se você já sabe que a maioria dos seus funcionários não é boa, não tem essa vibe de mastery e está lá mais porque não tem outro lugar pra ir e ninguém contrataria eles, então esqueça metodologias. Scrum, Lean, Kanban, Spotify, nenhum modelo vai jamais salvar profissionais ruins ou mal caráters. Aliás, pouca experiência técnica é algo que sempre podemos evoluir, mas mal caratismo não tem cura. Eu digo que se nem a coitada da mãe dele conseguiu dobrar o mal caratismo do filho por toda a vida dele, não sou em que em um mês vou conseguir. Portanto quando alguém se mostra mal caráter corte imediatamente, não tem salvação. Nunca, jamais, mantenha alguém mal caráter na equipe mesmo que ele pareça ser o melhor técnico. A pior coisa que uma empresa novata pode fazer é acumular escória assim.

Pra concluir. Esqueça metodologias ágeis, lean, kanban, spotify ou qualquer outra coisa. Na verdade, esqueça quem vende essas coisas. Se quem vende essas coisas não começou com a questão de tirar do cargo de chefia quem emperra decisões ou demitir os mal caraters que ainda estão no cabideiro da empresa, já começou errado. A primeira coisa que qualquer empresa que quer implementar esse tipo de processo precisa fazer é cortar a gordura fora e começar com o essencial: evitar desperdícios. O diretor de marketing que está lá só porque é cunhado do CEO, e todo mundo sabe que só fala besteira e não entrega nada? Precisa ir embora. O tal líder técnico que diz que manja bastante mas os programadores juniors que varam noite consertando os bugs que ele comitou direto na master, e que só aparece pra trabalhar 2 horas da tarde? Esse precisa ir embora. O gerente de projetos que sempre promete A pro diretor, manda a equipe fazer B, e depois muda de idéia pra C no meio do projeto mas mantém o prazo igual porque não quer contar pro diretor que fez merda? Esse precisa ir embora.

Eu não acredito em nenhuma tentativa de se implementar um novo modelo de gestão que não inicia com uma limpeza de RH. De departamentos inteiros se possível. Depois disso é ver toda a burocracia que se tem hoje em dia e jogar tudo fora se possível. Eu já vi casos imbecis de empresa com sprints de Scrum de 3 semanas ou mais! 3 semanas é ridículo. Uma semana é o ideal, na minha opinião. E quando você vai perguntar porque é tão longo eles falam que as reuniões de grooming, planning, review e retrospectiva acabam levando tantos dias que não cabe em 1 semana. Ou seja, estão desperdiçando o tempo da equipe toda em reunião 1 semana inteira por mês.

E isso tudo porque alguém leu que se deveria ouvir a opinião de todos os membros da equipe toda hora, que é uma desculpa pro PO e pro líder técnico não fazerem os trabalhos deles que é definir exatamente o que se precisa fazer e daí só discutir com a equipe toda quem vai fazer o que e como, o que deveria ser super rápido. É de novo a falta de alinhamento. Ninguém sabe exatamente que direção precisa ir, e na última hora durante o planning tem que ficar especulando cenários, começar a fazer pra alguém decidir diferente no meio e aí ter que parar tudo e recomeçar. Daí claro, 3 semanas de sprint, 6 semanas de sprint, não importa, você nunca vai ser ágil. Porque dessa forma toda vez você começa um sprint de 3 semanas, as coisas dão errado e só nas 3 semanas seguinte dá pra corrigir e potencialmente você atrasa as coisas 1 mês e meio toda vez, e isso vai acumulando. Daí seus deploys são atrelados ao aceite total no final de 2 ou 3 sprints, e você só tem coisa indo pra produção a cada 2 ou 3 meses. E, lógico, bugs vão se acumulando, todo deploy é uma dor de cabeça, daí na sequência todo mundo vara noite resolvendo bug e o próximo sprint já começa com burn out.

Isso porque a prioridade tá errada: você precisa criar restrições pro processo e fazer caber. O sprint é 1 semana. Mas daí não cabe as reuniões, oras, elimine as reuniões. Mas metade do backlog tá mal definido e não dá pra começar, oras corte fora do backlog tudo que tá mal definido. Ah, mas foi o diretor que pediu, oras, devolva pro diretor definir o que quer direito e escolher uma das opções, porque todas não dá pra fazer. É assim que se começa a tomar decisões. Se isso não é possível, então não adianta escolher metodologias, a fundação da empresa tá errada. Começa se livrando desse diretor e metade dos problemas vão embora com ele. Squads não vão ajudar.

É como o caso de microserviços que eu gosto de comentar como sintoma de más empresas. A Lei de Conway é outra lei das antigas que até hoje todo mundo cai nela. Melvin Conway postulou que qualquer organização que desenvolve sistemas vai inevitavelmente produzir um design que reflete a estrutura de comunicação da organização. Microserviços ficaram famosos porque ela aparentemente resolve um problema em organizações: a inabilidade de duas equipes de colaborarem entre si. Qual a melhor solução? Cada um cria seu próprio microserviço e eles não precisam colaborar agora. Uma organização com 10 equipes cria 10 ou mais microserviços. Claro, existem usos legítimos de microserviços, mas é muito mais comum ver eles sendo usados como tapa buraco em problemas de organização.

Toda implementação de bala de prata é alguém incompetente querendo esconder sua incapacidade atrás da muleta de uma metodologia. Daí quando tudo der errado você sempre pode dizer, ah mas a culpa não foi minha, nós seguimos todos os passos da metodologia, então outra pessoa deve ter implementado um passo errado. E pronto, todo mundo vai ficar discutindo ad eternum sobre especificidades de uma metodologia genérica. E ninguém vai ter o culhão de discutir o elefante no meio da sala: foda-se a metodologia. Qual é o real problema? É a quantidade de bugs em todo release? É a demora em se fazer deploys? É a quantidade de mudanças frequentes no backlog a cada sprint? Defina o problema objetivamente e ataque um de cada vez. Se fizer dessa forma, um modelo de organização naturalmente vai emergir.

Mas comece eliminando desperdícios. E contratar coaches é um desperdício. Se você como diretor ou C-level não fez merda demais, você já deveria ter tech leads ou similares na empresa que sabem o que precisa ser feito, mas não podem porque você enterrou todos eles em burocracia ou em backlogs impossíveis e estão todos varando noite correndo atrás do próprio rabo. A coisa mais óbvia? Desatole eles, assuma o prejuízo de fazer isso do que jogar dinheiro fora numa consultoria de agilidade que, se eles fizessem o trabalho deles direito, deveria te dizer pra fazer exatamente isso: desatole seus líderes e deixe eles fazerem o que eles já sabem que precisa ser feito.

Por fim, o próprio Spotify vem repetindo ao longo dos anos que nem eles seguem o modelo que eles mencionaram em 2012. E nem deveriam. Porque qualquer organização que esteja seriamente pensando à frente em sua qualidade e eficiência, está mudando as coisas o tempo todo. Um modelo, assim como a tal “Cultura”, que tooooodo mundo adora ficar falando em palestra ou post de blog é nada mais do que uma fotografia num determinado momento. Toda cultura muda, cultura é simplesmente o conjunto de costumes e valores de um grupo num determinado local e num determinado momento no tempo. Em 2019 a maioria das pessoas que trabalhava em 2012 talvez nem esteja mais lá, a cultura com 100 pessoas e com 2000 pessoas é diferente. Não se pode nunca achar que cultura é algo que vai ser preservado ou mesmo que deve ser preservado. Pelo contrário, é algo que deve estar em constante mudança, por isso eu acho meio idiota quando uma pessoa quer entrar numa empresa pela “cultura” que ela leu num post de blog.

Em Lean se popularizou um conceito que é melhoria contínua. É a única coisa importante depois de evitar desperdícios, Kaizen. Incentivar as pessoas a errarem rápido, aprender com os erros, ensinar os outros, e não errar a mesma coisa na próxima vez. É meio óbvio, mas parece que tudo que é óbvio precisa ser explicitamente dito numa organização. E esquece Kanban, foda-se OKR e rhythms e dibbs, que porra é dibbs? Fuck. Se quiser saber sobre Lean de verdade só tem uma fonte pra ler: Taiichi Ohno e seus discípulos como Shigeo Shingo. Na verdade, quem vende Kanban hoje já até avisa que o Kanban de software não tem mais nenhum paralelo com o Kanban da Toyota. É mais uma apropriação de vocabulários pra vender os mesmos produtos de sempre.

Como eu já disse no vídeo de Ágil: esqueça metodologias. O objetivo é entregar valor, software que funciona. O objetivo é maximizar os lucros. O objetivo é que todos trabalhem num ambiente minimamente funcional, com salários pagos em dia, com poucas interrupções, onde feedback não precise de burocracias e comunicação seja livre e aberta, onde cada profissional possa executar seu trabalho no máximo das suas capacidades, em vez de ter que se conformar com um padrão de ferramentas ou plataformas ou processos. Onde exista incentivo para que as pessoas vejam que existem ganhos individuais quando ele contribui com as outras pessoas, seja direta ou indiretamente. Use a ambição do indivíduo em prol da organização em vez de tentar convencer as pessoas a participar de um grupo só porque é politicamente correto colaborar com os outros. E, principalmente: demita esse maldito CMO ou C-FUCK-O ou VP de sei lá o que, que só atrapalha, só toma decisões erradas e só fica inventando de implementar o próximo Squad da moda.

Não menos importante, na dúvida sempre se lembre: um scrum master, um agile coach, um arquiteto, um chapter lead, ou qualquer coisa assim que vêm cagar regra em programação e nunca ele mesmo programa e não consegue se expressar em código pra explicar o que quer, não tem lugar numa equipe de desenvolvimento de software. E pra finalizar, tudo que falamos até agora não é novidade pra quem leu o Manifesto de Desenvolvimento de Software Ágil de 2001. Ele tem os famosos 4 valores, mas também tem 12 princípios, lembra? Vamos alguns deles e você vai ver como tudo que aparece no modelo Spotify e outras metodologias vem de lá também.

Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. - olha squads aqui Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. - voltando ao ponto de autonomia e alinhamento O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. - ou seja, sem rituais, simplesmente fale Software funcional é a medida primária de progresso. - esse é o objetivo: software que funciona e não estruturas de controle Contínua atenção à excelência técnica e bom design, aumenta a agilidade. - que é o pré-requisito a profissionais A Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. - e o que eu sempre repito que o melhor software é zero software. Se não precisa ser feito, não faça. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis. - e o manifesto também trás auto-organização Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. - e aqui é o manifesto remetendo ao princípio de melhoria contínua de Lean

Eu não vi nada de novo surgindo no mundo de teorias de gerenciamento faz mais de 10 anos já. É tudo a mesma coisa que a gente já sabia até o fim do século XX. Em vez de olhar pra esse tanto de bullshit quero que pensem outra coisa. Vejam software livre, código aberto. Você que é uma empresa de desenvolvimento de software, tentando implementar squads e scrums, nunca se sentiu meio envergonhado que um grupo aleatório de voluntários, que sequer ganham salário, consegue se juntar num projeto e entregar código de melhor qualidade do que seus squads com 10 coaches? Quando você se vê conseguindo entregar um framework como React? Quando você se vê entregando um banco de dados como Redis? Quando você se vê entregando um sistema como Git? Você está criando uma tonelada de estruturas inúteis de controle e sequer consegue entregar um formulário de login sem erro. Não tá muito claro que as prioridades estão erradas?

O mundo de software livre funciona porque ele tem só o mínimo necessário pra funcionar. O voluntário consegue baixar o código, rodar os testes e avaliar como prosseguir. Os bugs e roadmap estão expostos de forma transparente no issue tracker e wiki do projeto. Os membros estão disponíveis em mailing list ou chats. Existe um indivíduo ou grupo que é o ditador benevolente do projeto que é quem garante a integridade conceitual - como Fred Brooks já disse que era necessário no The Mythical Man Month. Discussões longas que se arrastam são cortadas por alguém que toma uma decisão. Boa ou ruim, ela é tomada. A principal métrica do projeto é sua utilidade aos usuários, caso contrário o projeto simplesmente morre. Como deveria.

E com isso eu vou fechar o assunto sobre agilidade por algum tempo. Acho que já falei tudo que eu queria falar. Prometo não voltar nesse assunto tão cedo porque quero falar de outras coisas mais interessantes: software. Então se ficaram com dúvidas, nao deixe de mandar nos comentários abaixo, se curtiram o video mandem um joinha, assinem o canal e cliquem no sininho pra não perder os próximos videos. Compartilhem o video com seus amigos pra ajudar o canal. A gente se vê semana que vem, até mais!

Finalmente, resolvi tocar num assunto divertido: o lamentável estado atual do mundo do “Ágil”.

A intenção é contrabalancear a exuberância irracional dos vendedores de “Ágil” como se fosse a sétima maravilha da humanidade. TL;DR não é.

Também foi uma boa desculpa para eu adicionar trechos da entrevista que fiz com Robert Martin (em 2010!)

O recado é muito simples: não existe bala de prata. Agilidade não são processos, metodologias, nem a miríade de numerologia e astrologia que assola este mercado. É hora de recuperar um pouco da essência original do mundo da Agilidade.

Se você ficou deprimido com o video (sorry) eu já tinha publicado alguns videos que podem te dar uma luz de caminhos a seguir:

• The MM-M: O Melhor Livro de Software? - veja todos os problemas que vocês tem na sua empresa de hoje descritas em detalhes num livro de quase meio século atrás (https://www.youtube.com/watch?v=wcGGklDfHM4)
• Projetos: Aprendendo a Priorizar - a 1a e mais importante lição que todos num projeto, não só gerentes, deveriam pensar todos os dias (https://www.youtube.com/watch?v=akKRtjIqRjs)

Links:

• Agile is Dead (Long Live Agility) (https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html)
• Agile: a Verdade por trás do Método (http://www.akitaonrails.com/2014/09/28/off-topic-agile-a-verdade-por-tras-do-metodo)
• #noEstimates Debunked (http://www.akitaonrails.com/2013/10/07/off-topic-desmontando-o-noestimates/)
• Accountability (https://pt.wikipedia.org/wiki/Accountability)
• GOTO 2015 • Agile is Dead • Pragmatic Dave Thomas (https://www.youtube.com/watch?v=a-BOSpxYJ9M)
• Don’t do Spotify Model ! (https://masterofnone.io/dont-do-spotify-model/)

=== Script

Olá pessoal, Fabio Akita

Continuando no assunto que comecei semana passada introduzindo um pouco da minha filosofia sobre profissão de prática, vou entrar em um assunto que pessoalmente me frustra muito. Essa tal de agilidade ou movimento ágil. A essa altura mesmo sem nunca ter estudado sobre o assunto no mínimo você já ouviu que Agile é a maior invenção da humanidade desde o pão fatiado.

Esse movimento me frustra porque a grande maioria das coisas que você lê ou assiste sendo apresentado sobre o assunto junta tanta asneira que perde completamente o foco do que era o movimento original. Dá mais trabalho separar o joio do trigo do que realmente focar no que interessa.

Eu acompanhei o nascimento, a evolução e a decadência desde quase quando o movimento surgiu. Lembrem que eu desenvolvia software desde os anos 90 e a idéia das práticas ágeis foi uma mudança muito bem vinda pra mim, por isso é particularmente frustrante ver o que isso se tornou hoje.

Eu nunca tive muita vontade de participar de eventos ou conferências sobre Ágil, sempre achei perda de tempo. Eu tenho minha própria empresa de desenvolvimento de software, mas eu não “vendo” agilidade. O foco sempre usar as práticas de desenvolvimento de software como algo básico, e não vender implementação de metodologias exotéricas feng shui de projetos. Eu pessoalmente não gosto de quase tudo que consultorias “ágeis” vendem hoje em dia, e detesto todo tipo de jargão moderno que tenta empacotar a idéia de agilidade em pacotes atraentes para empresas que não sabem o que estão fazendo. Lean Kanban, SAFe ou qualquer bobagem assim.

O episódio de hoje não é explicar Agilidade em detalhes ou fazer um checklist enorme de tudo relacionado ao assunto, mas explorar porque eu acho que os valores originais foram esquecidos e as práticas foram distorcidas e acabaram nos levando de volta ao ponto anterior, à época das tediosas metodologias monumentais dos anos 90. A camiseta que estou usando combina com o tom que vou usar pelo resto do episódio, então já fica aviso pros mais frágeis que o tom de hoje é Rated R.

(…)

Como sempre, vamos começar do começo. Todo mundo faz referências ao Manifesto, mas quantos de vocês sabem quem são os tais signatários, os autores originais do manifesto? Martin Fowler todo mundo conhece por outros livros como Refactoring e seus artigos muito bons publicados no seu site pessoal. Alistair Cockburn tinha sua metodologia Crystal Clear. O Jim Highsmith tinha sua metodologia Adaptive Software Development. Kent Beck e Brian Marick todo mundo associa com Test Driven Development. E no caso de Kent Beck, junto com Ward Cunningham e Ron Jeffries publicaram uma das coisas mais importantes pré mundo Ágil: as práticas de desenvolvimento de software de XP ou Extreme Programming. Se tem um único conjunto de métodos e práticas de desenvolvimento de software que você deveria estudar, é XP.

Ward Cunningham também criou a idéia original de Wiki e tem um dos wikis antigos mais interessantes: o C2, um dos lugares que eu sempre gostei de ler faz anos ou décadas. Dave Thomas e Andy Hunt a maioria deve conhecer tanto pelo livro The Pragmatic Programmer, que até hoje é uma das leituras que eu diria que é muito recomendada pra todo programador, mas também pela editora online PragProg que publicou muitos livros técnicos importantes.

Outro signatário foi Steve Mellor que alguns veteranos podem conhecer por causa do Shlaer-Mellor do fim dos anos 80, uma das muitas metodologias de análise e design de sistemas orientados a objetos. Eu não sei nada sobre Arie van Bennekum, James Greening ou Jon Kern, mas ainda temos Robert Martin, mais conhecido como Uncle Bob que adora falar de Clean Code até hoje. Mike Beedle, Ken Schwabber e Jeff Sutterland, que fundaram o famigerado Scrum, que pra muitos ainda é sinônimo de Agilidade.

Em 2010 eu tive a oportunidade de trocar idéia com o Bob Martin. Ele é muito eloquente e um excelente orador, é muito fácil ser convencido só pelo seu carisma. A mitologia do Manifesto Ágil é outra história que já se transformou numa lenda maior do que realmente foi. Todo mundo já ouviu a versão desses dezessete cavaleiros da agilidade, que se reuniram em Snowbird, Utah, numa távola redonda e de lá saíram as escrituras sagradas que definem a Igreja Dogmática da Agilidade!! Ohhhhhh Vamos ouvir dele como as coisas aconteceram.

(… trecho da história do agile …)

Provavelmente existem vídeos de outros agilistas mas esta palestra do Dave Thomas na conferência GOTO em 2015 é uma das melhores que já achei. Vamos ouvir o trecho dele explicando como surgiram com a estrutura do texto do manifesto em si:

(… trecho da história por Dave Thomas …)

Nessa palestra que vou deixar o link nas descrições, o Dave Thomas levanta um ponto importante. O Manifesto se chama “Manifesto do Desenvolvimento Ágil de Software”. Não é “Manifesto Ágil”. Falando dessa forma parece que o manifesto em si de alguma forma tem a “qualidade” de ser ágil, como ele diz, parece que o manifesto vai sair por aí dançando. Ágil não é um nome, é um adjetivo. Ou você é ágil ou não é. Não existe isso de “Você faz ágil?” ou “Estamos fazendo Ágil da forma correta?” Mas quem precisa vender alguma coisa, não tem como vender um adjetivo, e daí as consultorias, cursos, conferências, passaram a usar o termo como um nome, quase como se fosse possível dizer “quero levar meio quilo de Ágil, por favor, … pra viagem”

Eu não vou repetir o que o Dave Thomas explica nessa palestra, por isso recomendo que vocês assistam depois. Ele também escreveu um blog post um ano antes em 2014 na mesma época em que eu escrevi um artigo no meu blog: Ágil está morto, que vou deixar linkado nas descrições abaixo também. Muitos de nós já declaramos a “morte” do Ágil mas ele continua existindo nessa forma irreconhecível como um zumbi em The Walking Dead.

O que todo agilista de verdade vai concordar é que o termo foi prostituído. A beleza do Manifesto é sua simplicidade. Todos os profissionais de prática dessa área, com anos de experiência nas costas, consegue ler esse manifesto e se identificar. Ele descreve quatro simples valores que definem o que os agilistas chamam de “ser Ágil”. Seria algo similar às sete virtudes do Bushido, o caminho do Samurai. Ou os 10 mandamentos da Bíblia. O problema disso é que também é muito simples de distorcer a interpretação pra qualquer coisa que você quiser.

É como eu dizer “os 5 valores de ser saudável”. Ser saudável não é uma coisa que você compra numa prateleira. Ou um programa com 10 passos que você implementa em um mês e automaticamente você é saudável. Não adianta nada fazer almoços veganos e tomar multi vitamínicos e continuar comendo pizza na janta e enchendo a cara no fim de semana. Ser saudável é uma mudança completa em todos os seus hábitos e rotinas, todos os dias, e não alguma coisa que você liga e desliga quando quiser. A mesma coisa com honra. Não existe ser honrado de vez em quando. Mesma coisa com ser bom, não adianta roubar às terças e quintas e ser bom nas segundas e quartas. Ser ágil é a mesma coisa: é uma estilo de vida. Nunca um procedimento ou metodologia. Ou você é um profissional de desenvolvimento ágil de software ou não é.

Dado tempo suficiente, qualquer interpretação repetidas muitas vezes vai parecer mais verdadeira que a intenção original. Tome Scrum, por exemplo, por um período de tempo, talvez até hoje, muitos chegaram a associar sua implementação como o equivalente a se tornar Ágil. Scrum na verdade foi inventado nos anos 80, o guia sequer menciona o termo “ágil”. Mas era o texto mais simples e palatável para não-programadores.

Hoje em dia muitos adotam o tal de Kanban da mesma forma, que não se parece em nada com o Kanban original inventado na Toyota. As premissas e os fins são completamente diferentes, mas o nome é bem marketável, por isso é usado. Distorção dos objetivos originais funciona assim: muitos poderiam associar pagar uma contribuição pra Igreja como o equivalente a ter virtudes pra ir pro céu. Implementar as cerimônias do Scrum ou as técnicas de Kanban não torna ninguém automaticamente Ágil, da mesma forma como contribuir pra uma instituição não o torna Bom. E falando em Bom, o Bob Martin coloca muito bem porque o termo Ágil foi distorcido até se tornar irreconhecível:

(… trecho do Bom de Bob Martin …)

Se eu quiser ser mais extremo, não existe isso de metodologia Ágil. Existem métodos e práticas adotadas por profissionais ágeis. Não existe “implementar Ágil”. Existe “ser Ágil”. Toda consultoria que quer diferenciar seus produtos, e já percebeu que o valor da Agilidade vem caindo, está vendendo alguma variação com a etiqueta de Lean ou Kanban, ou simplesmente adotando práticas de outros corpos de conhecimento como PMI ou CMMI e re-etiquetando como parte de Ágil, ou então tentando inflacionar etiquetando alguma coisa como “Ágil Escalável” pra grandes organizações. Tudo isso é um monte de besteiras. Nas palavras de um signatário do Manifesto “Ágil”, o que significa ser ágil?

(… trecho dave thomas agil …)

Como Dave Thomas explica na palestra e como eu também venho explicando nos últimos quase 10 anos, agilidade é simplesmente andar um passo de cada vez, avaliar o resultado a cada passo, ajustar o caminho se o resultado não estiver de acordo com o esperado e repetir. Só isso, é exatamente o que devemos fazer pra atingir qualquer objetivo que não sabemos como atingir. Se quiser uma definição mais formal, é exatamente o que está na origem do Lean de verdade da engenharia de produção: o ciclo PDCA de Deming, que em resumo é planejar, executar, checar e agir. Todo processo cíclico deriva da mesma idéia. O DMAIC de Six Sigma é exatamente a mesma coisa: definir, medir, analisar, melhorar e controlar.

Todas as técnicas que se nascem desse ciclo de melhoria contínua, como um Kanban, fazem sentido para resolver os problemas encontrados especificamente na engenharia de produção da Toyota décadas atrás. Sob as premissas daquela época, sob as restrições daquele contexto, que são completamente diferentes de desenvolvimento de software do século XXI.

E falando em engenharia de produção. Parem, pelamordejesus, de querer associar técnicas de engenharia de fábricas em software. Vamos entender de uma vez por todas: software se chama soft porque não é hard. Hardware, equipamentos, coisas palpáveis, obedecem as leis da física. Tem peso. Sofrem a força da gravidade. Existem limites e restrições muito específicas sobre o que é possível ou não fazer com materiais físicos.

Todos os campos da engenharia foram sendo refinados pra lidar com isso. Fabricar carros, fabricar navios, construir prédios, produzir bens de consumo. É nesse tipo de ambiente que faz sentido falar em Kanban, Lean, Six Sigma. PQP Monte Carlo em estimativa de software não faz absolutamente nenhum sentido. De novo: só porque os números computam, não quer dizer que você tem qualquer resultado útil. É a mesma coisa com numerologia, só porque os números contam uma história que te agrada, não torna isso uma ciência. Isso não uma prova, não é sequer evidência de coisa nenhuma. É apenas coincidência e o resultado de torturar números pra contar a história que você quer ouvir.

Software, por definição, é uma abstração sem forma física e sem limites físicos. A mesma coisa vale pra literatura, música, pintura, qualquer coisa no campo criativo e das idéias. Software não tem peso, não tem cor, não tem cheiro, não obedece nenhuma lei da física a não ser o tempo de execução determinado pelo clock das CPUs ou GPUs. O principal: dois programadores diferentes tentando representar em código a mesma especificação da mesma tarefa vão chegar em códigos diferentes, gastando tempos muito diferentes. Diferente da engenharia do mundo real: duas construtoras diferentes, seguindo a mesma especificação, vão construir as mesmas casas dentro de custos e tempos muito similares, com qualidades similares, dadas as mesmas condições.

Mas no campo do soft, código, palavras, idéias, as diferenças são gritantes entre os melhores e os medíocres. Estamos falando em ordens de grandeza. Às vezes um medíocre pode precisar de dezenas de linhas e dezenas de horas pra representar uma tarefa em código, mas os melhores podem precisar de uma linha e alguns minutos. Não existe paralelo entre as técnicas de engenharia de produção e engenharia de software além de aspectos superficiais. Quanta gente já tentou gerenciar produtividade de escrever livros usando Lean Writing? Quantas vezes você já viu alguém controlando composição de música usando Kanban Songs? Soa ridículo? Lean Software soa tão ridículo quanto.

A parte bem conceitual de um Lean faz algum sentido: evitar desperdícios. Errar rápido. Mudar de direção quando faz sentido. Mas é só. As técnicas e métricas em si, não fazem sentido. Mas todos os que defendem isso tem números pra “provar” que as técnicas funcionam. Bobagem. A grande vantagem de usar números para explicar coisas pra pessoas não treinadas em matemática é que é muito fácil torturar números pra dizer qualquer coisa que você quiser. Qualquer um que lida com números sabe como é fácil mentir com números. Nós mesmos nos enganamos, muitas vezes sem querer. Mas sempre tente entender as condições sob as quais esses números foram colhidos, com que precisão? Com que procedimentos? Quão repetíveis são esses testes? Como são configurados os grupos de controle?

Repetindo: ter algo que parecem ser evidências não é nem de longe perto de ter provas. Não subestimem o método científico, não é assim que ciência funciona. Diferente de uma engenharia civil onde podemos teorizar, calcular, e provar fisicamente o funcionamento, o mesmo não pode ser dito de absolutamente nenhuma metodologia ágil. Ah, mas no Google funciona! Ah, mas os squads do Spotify funcionam! Ah mas na empresa X ou Y funciona. Bullshit. Sob quais condições? Quais premissas? A resposta mais óbvia é: dado 100 tech startups que surgiram e morreram, uma sobreviveu chamada Spotify, que por acaso tem elementos que parecem uma metodologia. Mas não foi por causa dela.

Vamos estabelecer o seguinte: contratar uma consultoria que vende implementação ou coaching de metodologias ágeis costuma ser perda de tempo na maioria das vezes. Mas por que parece que dá resultados? Se partirmos do princípio que quem você contratou de fato sabe como fazer software. Seria como contratar um personal trainer. Só funciona se você vai realmente continuar a disciplina mesmo quando ele não estiver presente. O problema é que o treinamento não é só de uma pessoa, normalmente é uma equipe inteira, e o ideal seria a empresa inteira. Depois que o coach ou consultoria for embora, o normal é a maioria das pessoas voltar a fazer as mesmas coisas erradas que faziam antes. E por isso todo mundo vende metodologias e processos de controle, e cerimônias, e algum jeito de medir se todo mundo está seguindo esses procedimentos.

Releia o Manifesto: “Indivíduos e Iterações em vez de processos e ferramentas”. É o primeiro valor do Manifesto. E qual é a primeira coisa que você pensa em fazer? Contratar uma consultoria externa com indivíduos que não fazem parte do seu time, para implementar processos e ferramentas e mecanismos de controle. É basicamente a pessoa que entra em dieta toda segunda feira, perde peso por algumas semanas, posta no LinkedIn “olha só como minha dieta funciona” mas no mês seguinte ganhou mais peso do que tinha perdido, e ninguém mais ouve falar dele.

A principal razão de porque as pessoas e as empresas fazem isso, é o mesmo motivo de sempre: medo e insegurança. Ninguém gosta de estar errado. Um medroso ou medíocre sempre vai terceirizar a decisão pra algum expert ou coach ou mentor ou consultoria, dessa forma ninguém pode dizer que ele estava errado já que ele fez o que todo mundo está dizendo pra fazer: “implementar Ágil”. Hoje em dia você tem essa atitude esnobe de “como assim você não faz ágil?”

Pras consultorias ou coaches, a situação é muito fácil. É que nem um personal trainer que precisa trabalhar pouco, e colocar um espelho convexo pra parecer que está dando resultados. E, principalmente, não ficar muito tempo. Implementar, colocar alguma numerologia que cospe algum número interessante pra parecer que existe controle, e ir embora. Assim você tem o benefício de ter um “caso de sucesso”, já que tem post numa rede social deve ser verdade. E se depois de implementado os resultados começarem a desaparecer - como obviamente vão - eles sempre podem dizer “olha só, vocês não continuaram o processo que implementamos, por isso tá dando errado, mas tudo bem, só contratar a gente de novo que ajustamos”. E bem vindo ao mercado de ganhar dinheiro em troca de pouco ou nenhum resultado. É o melhor tipo de indústria que tem. Você pega qualquer coisa que parece um resultado e faz posts no Linkedin como se fosse salvador da pátria e esconde embaixo do tapete tudo que não mostrou resultado.

Por que as pessoas querem uma boa definição formal do que é uma especificação de software, seja na forma de user stories ou qualquer coisa assim? Porque a maioria não tem saco pra escrever, e quem vai programar não tem saco pra ler. Então perde-se mais tempo discutindo o formato e o protocolo do que em realmente discutindo o que precisa ser feito. Já que ninguém senta e chega num consenso do que é uma boa produtividade, vamos discutir lead time, vamos discutir story points, ou inutilidades como WIP, não importa, qualquer numerologia arbitrária em vez de realmente entender quais são os fatores que estão afetando a produtividade naquele contexto em particular, como a indecisão dos donos da empresa ou o acúmulo de más contratações que já deveriam ter sido demitidos.

Ou então, já que programador odeia ter que estimar, vamos associar agilidade com não-estimar, o estúpido movimento de hashtag #noEstimates. Essa acho que tentou pegar tração mas não foi muito pra frente. Eu diria que se um programador gosta de no-estimates pros projetos devia tentar vender isso junto com no-estimates pra ser pago também, acho justo. E é verdade, eu já discuti bastante porque eu acho que estimar é uma tarefa ingrata mas necessária, e não ajuda nada que os clientes tem uma grande dificuldade de entender como as coisas são feitas e quais são as expectativas reais. Mas pelo menos todo não-programador sabe que se perguntar a um programador quanto tempo alguma coisa leva pra alguma ficar pronto, e ele responder, 200 horas, você sabe que em 200 horas seja lá o que foi pedido, vai estar pela metade. É quase uma lei universal isso.

E é exatamente o tipo de problema que a idéia de agilidade original quer tentar resolver. A idéia de parar de brincar de “vamos fingir que você não tá me enganando e vamos fingir que eu tô acreditando”. Agilidade não tem nada a ver com implementar uma ferramenta, ou um processo, ou uma forma mensurável e numérica de controle. Agilidade é fazer o que precisa ser feito para atingir os objetivos concordados, sem meias palavras, com as expectativas alinhadas.

O programador promete o que tem segurança que consegue entregar e a discussão é se isso é o suficiente e se vale a pena pro cliente, e o cliente entender que se não cabe tudo, ele precisa decidir se metade é suficiente. Ou então ninguém nem começa e o projeto deve ser abandonado. E sim, não começar algo inseguro demais é ser ágil, é evitar desperdícios. Eu tô cansado de recusar projetos porque eu acho que tá tão mal definido que vai me dar mais dor de cabeça do que vale a pena. Prefiro ser claro e dizer: volta pra casa, o dia que você souber o que quer, daí me procura.

Eu falei disso no episódio sobre Priorização que você pode assistir linkado acima. A muleta das metodologias fica mais preocupada em ver o formato em que determinada requisição deve ser feita, se no formato de stories, cadastrado em qual ferramenta, como marcar quem fica responsável e bla bla bla em vez de se perguntar se a tal requisição sequer deveria existir, pra começo de conversa.

Quantas vezes alguém já chegou em mim pra um projeto pequeno e fala coisa do tipo, “ah, e deve ser fácil, mas eu queria ver se dava pra colocar um mensageiro no meu MVP, tipo o Messenger do Facebook, sabe?” e eu digo, “ah, claro, dá pra fazer sim, você vai pagar o mesmo que o Facebook pagou pra fazer o deles?” E esses dias alguém me pergunta “ah, vocês conseguem fazer um Spotify?” ah vá, nem vou perder tempo.

Hoje em dia em grandes empresas, com montes de equipes ou “squads”, gasta-se todo o tempo enchendo os backlogs ou kanbans de coisas pra fazer e depois comemoram porque o “throughput” desse sprint foi maior do que o do sprint anterior, ou porque conseguiram diminuir o “lead time”, ou porque o tamanho dos “lotes” estabilizou, Quanto bullshit.

O que deveria importar é: o software planejado que tinha mais valor foi entregue ou não? Qual foi o retorno do investimento? Qual é o custo total de propriedade do software atual? Essas coisas ninguém responde. Por isso a coisa mais importante que é não desperdiçar, ninguém sabe se tá sendo cumprido ou não. Na maior parte do tempo, numa empresa com sei lá, umas 10 equipes desenvolvendo software, eu poderia olhar por 1 dia e decidir cortar umas 2 equipes inteiras, ou mais, e não impactaria o negócio como um todo. Muitas vezes os que deveriam tomar as decisões têm essa noção, mas poucos tem o culhão de cortar, e assim vai queimando mais recursos do que deveria produzindo software que não traz valor pro negócio enquanto outras partes que poderiam estar sendo priorizadas sofrem ficando pra trás.

Toda a idéia de alguém nível C numa empresa, um CEO, um CTO, um COO, é tomar as decisões difíceis que funcionários não podem tomar. Não tem como saber com 100% de certeza qual decisão é a melhor. Mas a pior coisa é não tomar nenhuma. Sempre parece mais fácil se esconder atrás de alguma muleta, tipo um Scaled Agile Framework. Daí dizer pros investidores como isso vai melhorar as métricas X ou Y da empresa, mas vai levar um ou dois anos pra implementar. E literalmente coçar o saco se escondendo atrás disso em vez de estar fazendo o que deveria: tomando uma decisão de verdade.

Na vida real, tudo é um risco. Em particular gestão de projetos é em boa parte gestão de riscos. Gerenciar riscos não significa evitar todos os riscos. Pense como contratar um seguro. Não existe zero riscos a zero reais. Quanto mais você quiser de cobertura, mais caro vai ser o seguro e mais caro a franquia se precisar usar. Pior do que tentar economizar não fazendo seguro é achar que é possível ter cobertura completa. Se você tentar garantir 100% de certeza mais você vai errar. É melhor assumir uma perda pequena: a realidade é que você não tem como acertar 100%, então pare de tentar.

Se for pra micro gerenciar um projeto, adicionando o máximo de ferramentas e procedimentos de controle, é melhor nem começar. Num pensamento assim seria como eu dizer, “cara, você quer ter certeza que seu carro não vai bater? É muito simples, pra que complicar? Simplesmente não tire seu carro da garagem, nunca, assim você tem 100% de certeza”. Ou então quem quer ter 100% de segurança de que seus computadores não vão ser invadidos por hackers? Simples, nunca ligue na internet, fique offline o tempo todo. Mas obviamente nada disso é prático. É quando você é obrigado a assumir algum risco. Entenderam? Ter controle de verdade e “achar” que tem controle são duas completamente diferentes.

A partir do momento que você decide que precisa fazer mais do que simplesmente enfiar a cabeça num buraco e esperar o problema passar sozinho, significa que você precisa assumir o controle de verdade e assumir riscos. Bem vindo à vida de um adulto. Significa também que você precisa assumir o prejuízo de uma decisão errada. E novamente, sinto muito te dizer, você vai tomar decisões erradas, muitas, incluindo contratar funcionários ou fornecedores errados ou começar projetos que nem precisava. Em vez de apostar tudo que você tem numa opção só, é melhor fazer planejar um ponto de corte, testando por um curto período de tempo. E se não gostar, cortar o quanto antes. Simples assim. Nada disso é garantir que uma hora você vai chegar onde precisa, mas pelo menos vai ter mais chances de tentar.

Ser ágil é ser adulto. Você nunca vai transformar uma equipe de crianças mimizentas em adultos via metodologia. Todo moleque adora falar em querer ter mais autonomia, que é uma das coisas que parece que as metodologias ditas ágeis parecem fornecer, dado que a ênfase era ser mais leve e principalmente pela interpretação errada do primeiro valor do manifesto, que diz valorizar pessoas mais que processos. Não é isso que o valor quer dizer. Ela basicamente diz o óbvio: em vez de apostar num monte de micro controles pra gerenciar um projeto de software, partindo da premissa que todos os envolvidos são adultos, deixe os adultos discutirem (interações) e resolver o problema, como adultos.

Todo mundo quer ter autonomia. Mas só na hora que interessa. Autonomia é a junção de ter liberdade e assumir as consequências dessas liberdade. Não existe ter liberdade e não ter nenhum ônus, isso seria só libertinagem. Em inglês existe uma palavra pra isso: accountability. Não existe uma palavra equivalente em português, o mais próximo seria ser responsável mas é mais do que isso. Veja a definição da Wikipedia. Mas a idéia de ser ágil é ser accountable, não só ter mais liberdades. A diferença de alguém que faz alguma coisa por hobby e alguém que faz alguma coisa por profissão é que um profissional é accountable. Bem vindo ao mundo dos adultos.

Agora, se esconder atrás da metodologia dizendo bobagens como “puxa, não sei porque as coisas não estão andando como vocês querem, eu preenchi os tickets do Jira como vocês pediram, eu participei dos sprint plannings, e mesmo assim vocês não tão satisfeitos? Bom, não é minha culpa porque eu fiz tudo que pediram”. E isso é exatamente a mesma coisa que eu ouvia desde antes da era da Agilidade e é o oposto de accountability. Todo mundo que não quer trabalhar ou que vai seguir a lei do menor esforço, sempre vai se esconder atrás de todos os procedimentos que você der. Pois bem, tire todas essas muletas, e o que sobra é o trabalho em si. E agora você pode realmente medir as pessoas pelo mérito do trabalho individual de cada um.

Quando um manifesto é interpretado do jeito que todo mundo quiser, cada um pra justificar sua falta de profissionalismo, ele não tem nenhum valor. É como a Bíblia, se você vai ficar pegando pedaços pra ler ao pé da letra e outras vezes vai ignorar algumas partes ou interpretar diferente, pra que serve a Bíblia? Uma pessoa boa é boa com ou sem estrutura religiosa. Justificar uma atitude porque “está escrito na Bíblia” é o tipo de muleta sem sentido que não precisamos, especialmente no mundo profissional.

Você é dono ou gestor de uma empresa e quer uma equipe ágil? Pare de contratar crianças e tratar todo mundo como criança. Quando você quer adultos, você trata as pessoas como adultos. Em vez de fazer telefone sem fio, diga exatamente o que quer, e deixe os profissionais trabalharem. Os profissionais foram abaixo das expectativas? Mande embora. Agora, se você está no mercado de babá de programador, coloque metodologias ágeis.

Aos programadores, vocês querem ser profissionais? Sejam accountables. É o que eu comecei falando no episódio anterior. Ao usar as falhas óbvias nas metodologias pra esconder sua falta de vontade de trabalhar você está ocupando o lugar de outra pessoa que quer trabalhar e está desrespeitando sua profissão. Como eu disse no começo, se você é iniciante, as práticas que realmente interessam começam no Extreme Programming e não no Scrum. Test Driven Development, Small Releases, Continuous Integration, Simple Design, Collective Code Ownership (que é hoje em dia é basicamente Git) e práticas desse tipo é o que realmente se faz. Brincar de cartas pra estimar tarefas ou ficar usando chapéu em círculos pra dar vez pra se falar é o tipo de cerimônia ridícula que não faz nenhum sentido. O que é isso? Uma empresa de desenvolvimento de software ou uma creche? Daqui a pouco vamos estar todos abraçando árvores.

(… bob martin outros agilistas …)

Os reais objetivos e modo de pensar e agir de um agilista não é complicado. Não é pra ser complicado. Todos os corpos de conhecimentos em gestão de projetos, seja PMI, Lean, Scrum ou qualquer coisa não são necessariamente inválidos, não me entenda mal, são técnicas, meras ferramentas. Assim como uma caixa de ferramentas sozinha não constrói uma casa, você pode usar a combinação de ferramentas que quiser. Mas não acredite que existe um martelo especial que vai construir a casa melhor pra você automaticamente, isso não existe.

Em particular, você quer saber o que é agilidade? Leia os autores originais, os dezessete originais que o Bob Martin falou. Não precisa de mais do que isso. O foco não são as ferramentas, não são as cerimônias, nada disso. O objetivo não é atingir determinado número em algum gráfico arbitrário: é entregar valor. Se o que mais importa no seu projeto é atingir números, você precisa questionar seus valores.

Eu posso estender esse assunto ad eternum mas vou parar por aqui, já reclamei demais pra um episódio só. Mas a mensagem que precisa ficar clara: o estado atual do ecossistema de agilidade está poluído de prioridades erradas. Não é a toa que todo mundo se sinta tão confuso que precisa contratar um guru qualquer pra dizer o que fazer. Simplifique: jogue tudo fora, pare de ouvir os outros e simplesmente olhe pro seu problema de forma objetiva, sem achar que está fazendo errado por não estar usando algum novo jargão da moda.

No final das contas, claro que eu estou sendo hiperbólico pra salientar meu ponto. O dinheiro é seu e eu realmente acho que cada um deve fazer com seu próprio dinheiro o que bem entender, inclusive queimar ou jogar fora. E muita gente realmente gosta da presença de um guru ou coach, é que nem uma terapia, faz se sentir melhor e dormir melhor a noite. E ei, tudo isso é um motivo muito válido. Porém, se você acha que existe realmente alguma ciência por trás disso que você está comprando, pode parar. Se você tem uma doença séria e estão te vendendo homeopáticos, me desculpe, tirando o efeito placebo, você não vai se curar. Procure medicina de verdade. A era New Age já acabou, e ninguém vai sentir falta.

Vocês tem dúvidas específicas sobre esse tema? Talvez valha um episódio de repescagem pra responder perguntas específicas, então mandem suas dúvidas nos comentários abaixo pra eu saber. Se curtiram o vídeo mandem um joinha, assinem o canal e cliquem no sininho pra não perder os próximos episódios e compartilhem o video com seus amigos pra ajudar o canal. A gente se vê na próxima, até mais!

Descrição no YouTube

Vocês vão encontrar dezenas de listas de “Top 10 Livros sobre desenvolvimento de Software”. Mas como realmente confiar numa lista? Vou explicar um dos critérios que eu uso para escolher.

E aproveitando o gancho do vídeo anterior, de porque blockchains não são balas de prata pra tudo, vamos ver a origem da frase Balas de Prata.

O livro The MM-M é possivelmente um dos livros que eu consideraria obrigatório a qualquer um que leve a sério a área de Engenharia de Software, particularmente como gerir um projeto de software.

Mas um livro publicado em 1975 não está atrasado? Agile não é o jeito moderno?

Vamos quebrar esses e muitos outros mitos que muitos de vocês devem ter até hoje sobre gerenciamento ágil de software.

Quando gravei eu disse que não sabia de onde tinha ouvido falar desse livro pela primeira vez, mas fui vascular meus e-mails mais velhos e sem querer achei exatamente. Foi no dia 27 de julho de 2002 (então eu estava certo, 15 anos atrás), e foi no Slashdot.org, exatamente nesta página: https://web.archive.org/web/20040412002157/http://slashdot.org/books/980805/1148235.shtml

Fica aqui pra posteridade :-)

Links:

• The MM-M (https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959)
• Peopleware (https://www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113/ref=sr_1_1?s=books&ie=UTF8&qid=1540781158&sr=1-1&keywords=peopleware)
• The Pragmatic Programmer (https://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=pd_sim_14_4?_encoding=UTF8&pd_rd_i=020161622X&pd_rd_r=c5fdf2b8-db24-11e8-8f8d-3f9a1c609712&pd_rd_w=NX6su&pd_rd_wg=Md4XU&pf_rd_i=desktop-dp-sims&pf_rd_m=ATVPDKIKX0DER&pf_rd_p=18bb0b78-4200-49b9-ac91-f141d61a1780&pf_rd_r=FW20HKV0BHRZNE9MEWZH&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&psc=1&refRID=FW20HKV0BHRZNE9MEWZH)
• Clean Code (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=pd_sim_14_13?_encoding=UTF8&pd_rd_i=0132350882&pd_rd_r=c5fdf2b8-db24-11e8-8f8d-3f9a1c609712&pd_rd_w=NX6su&pd_rd_wg=Md4XU&pf_rd_i=desktop-dp-sims&pf_rd_m=ATVPDKIKX0DER&pf_rd_p=18bb0b78-4200-49b9-ac91-f141d61a1780&pf_rd_r=FW20HKV0BHRZNE9MEWZH&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&psc=1&refRID=FW20HKV0BHRZNE9MEWZH)

Script

Olá pessoal, Fabio Akita

Alguns vídeos atrás, alguém pediu nos comentários para recomendar livros na área de tecnologia. Vou dizer logo de cara: qualquer lista de top 10 livros de tecnologia que não mencione Fred Brook’s e seu magnum opus The Mythical Man-month perto do topo, não é uma lista confiável. … by Akita

Na verdade, aqui vai uma dica importante: os livros publicados mais recentemente, por autores “celebridadezinhas” raramente, muito raramente, são úteis. Eu não compro, eu recomendo não comprar se o objetivo for criar fundações sólidas. Deveria ser meio óbvio, mas pra um livro ser considerado realmente bom, ele PRECISA passar pelo teste do TEMPO. Durou 10 anos e ainda é válido? Começo a considerar. Durou 30, 50 anos? Agora eu começo a considerar se entra numa lista top 10. Colocar livros de menos de 10 anos num top 10 normalmente expõe a fraqueza da lista.

Muitos autores modernos desprezam os livros antigos de engenharia de software porque tem a noção errada que os atuais livros de fake-agile ou os to-do list glorificados do kanban são a única doutrina necessária e os antigos programadores de Cobol faziam tudo errado. Se você pensa assim ou tem algum resquício disso no fundo da sua cabeça, vou dizer de novo logo de cara: você é moleque! Continue pensando assim e prepare-se para uma longa carreira medíocre.

(…)

Se você já está na área faz algum tempo, o livro de Fred Brooks The Mythical Man-Month vai ser surpreendentemente atual. Quando eu li esse livro uns 15 anos atrás, eu pensei, cara se eu tivesse lido esse livro uns 10 anos antes, no começo da minha carreira, talvez eu tivesse evitado muitos problemas ou pelo menos teria tido insights pra soluções diferentes. Brooks descreveu em detalhes TODOS os problemas que eu já passei em projetos e possíveis soluções. Ele foi publicado em 1975! seguindo as experiências adquiridas em diversos projetos como o sistema operacional OS/360 da IBM.

Ou seja, quase meio século depois, nossa área de engenharia de software continua errando nos MESMOS lugares que já se errava desde os anos 60!! George Santayana já dizia: aqueles que não se lembram do passado estão condenados a repetí-la. Eu tento não ser idiota, por isso passei os últimos anos indo atrás do passado, e é por isso que eu lido com projetos e equipes de uma maneira um pouco diferente e também por isso tenho zero interesse em discussões atuais de “agile”. Vou falar disso em outro vídeo.

Na verdade todos os grandes clichês que você já ouviu falar foram provavelmente tirados desse livro de Brooks. Por exemplo o título do livro é o capítulo 2 e também a chamada Lei de Brooks: adicionar mais gente num projeto atrasado só vai deixá-lo mais atrasado. Man-month ou pessoa-mês é a definição da quantidade de trabalho que uma pessoa faz em um mês. É a falácia de achar que pessoas e tempo são recursos iguais: ou seja, que se você tem 1 pessoa num projeto de 3 meses ou 3 pessoas num projeto de 1 mês, é tudo igual. O maior problema em projetos é a coordenação dessas pessoas.

Coordenação entre pessoas, combinação de caminhos diferentes entre múltiplos nós. Qual era mesmo a fórmula que você aprendeu na faculdade? AH sim ! No pior caso, você tem n x (n-1) / 2 caminhos de comunicação. Lembrou?

Ou seja, 10 x 9 / 2 ou 45 linhas de comunicação entre 10 pessoas. Vamos adicionar 5 pessoas a mais, achando que vai melhorar. Agora vc tem 15 x 14 / 2 = 105 linhas de comunicação. E se for um time de 20 pessoas? 190 linhas de comunicação. Está vendo como o problema escala rapidamente?

Toda vez que você adiciona pessoas novas no projeto, segundo Brooks e segundo minha experiência como evidência, você perturba o projeto de 3 maneiras importantes: você agora precisa reparticionar as tarefas com as pessoas novas. Essas pessoas novas precisam ser treinadas no que já foi feito até agora, é o tempo de phase-in ou on-boarding. E finalmente, temos as novas linhas de comunicação pra piorar.

Como fazemos num projeto grande então? Brooks descreve a solução: você divide o sistema em sub-sistemas, cada qual com uma Equipe Cirúrgica - que ele define em detalhes no capítulo 3 -, uma equipe pequena - ele até menciona o conceito de Feature Teams. Uma equipe multidisciplinar com um líder claro. Já se sabe faz décadas, empiricamente, que uma equipe jamais deveria ter mais que 10 pessoas. Tem uma parte do capítulo que eu gosto que ele diz: “se um projeto de 200 pessoas tem 25 gerentes que são os programadores mais competentes e experientes, demita a tropa de 175 e coloque os gerentes de volta pra programar”. MAS isso faria o projeto levar 25 anos pra acabar. Portanto, melhor dividir as 200 pessoas em 20 equipes cirúrgicas de 10, cada um com um sub-sistema.

No capítulo 7 ele inicia descrevendo a Torre de Babel. Segundo o livro de Genesis a torre de Babel foi a segunda obra de engenharia da humanidade, a primeira tendo sido a Arca de Noé. Mas Babel foi o primeiro fiasco de engenharia. Vamos analisar esse conto bíblico pela ótica da engenharia: Eles tinham:

1. uma missão clara? sim.
2. pessoas suficiente, sim
3. materiais? sim
4. tempo suficiente? sim
5. tecnologia adequada? Sim

Se eles tinham tudo isso, porque o projeto falhou? Em 2 aspectos: comunicação e, por consequência, organização. A conclusão? como pequenas equipes devem se comunicar uns com os outros? DE TODAS AS MANEIRAS POSSÍVEIS. Pega o maldito telefone e liga. Manda pombo correio, sinal de fumaça, mas se comunique! Falta de comunicação, já é sabido, desde a Genesis se você acredita na Bíblia, ou desde os anos 60 se você acredita em Brooks, é a principal causa de fiasco de projetos. Por que você acha que alguns dos softwares mais famosos hoje em dia são todos de coordenação? Jira, Trello, Slack, Basecamp, Github, etc.

Falando em Github. Na republicação de 1995 ele reflete sobre o capítulo da Torre de Babel. Citando: “No projeto do OS/360 nós decidimos que TODOS os programadores deveriam ver TODO o material. Harlan Mills argumentou de maneira persuasiva que programação deveria ser um processo público, e que expor todo o trabalho pra todo mundo ajuda o controle de qualidade, tanto por peer-pressure de fazer as coisas direito e por cada um poder de fato ajudar a encontrar falhas e bugs”. OS/360, o projeto de 1964. Você acha que a noção de “quanto mais olhos no código melhor” vem de open source? Eu diria que a noção de open source vem dessa visão dos anos 60!

No capítulo 4, ele fala de Aristrocracia, Democracia e Design de Sistemas, onde ele postula provavelmente algo ainda mais importante do que o título do livro: Integridade Conceitual. Citando Brooks: “Eu vou defender que integridade conceitual é a coisa MAIS importante a se considerar em design de sistemas. É melhor um sistema omitir certas features e melhorias, mas refletir apenas Um conjunto de idéias de design, do que ter um sistema que contém muitas idéias boas mas independentes e descoordenadas”.

Uma equipe ou várias equipes, não importa, precisa de líderes cuja principal função é manter a Integridade Conceitual. Projetos de software não são e nunca devem ser democracias onde toda boa idéia de alguém entra no sistema. Alguém precisa ser responsável pela integridade do PRODUTO, como ele diz no título do capítulo, uma aristocracia mesmo, um ditador benevolente. Ou você já viu um projeto open source sem um Core Team que decide o que mergeia ou o que não mergeia? Deixe entrar tudo e você ganha uma Torre de Babel.

Nos anos 90 nós erramos nesse conceito e elevamos a idéia do famoso “arquiteto de sistemas” alto demais sem colocar esta missão de forma clara: integridade conceitual. Mas foi de novo um erro de não ler o livro porque Brooks deixa muito claro: o propósito de programar um sistema é deixar o computador mais fácil de usar. Uma arquitetura monumental feita por um arquiteto não serve pra nada se serviu ao sistema mas não ao Uso desse sistema. Outra coisa que eu sempre digo mas que Brooks disse primeiro: um arquiteto que não sabe programar não serve pra nada, citando Brooks: “o arquiteto deve estar sempre preparado para mostrar uma implementação pra toda feature que descreve, embora ele não deva ditar A implementação”. Mudamos um pouco o foco disso e dividimos o arquiteto entre líder técnico e outro papel para manter a parte da integridade conceitual: Hoje em dia você tem um conceito semelhante: chama-se PRODUCT OWNER.

E já que falamos num termo de Agile, vamos voltar a outra falácia: que só no século XXI aprendemos que waterfall é ruim e por isso substituímos por Agile. Isso é uma das noções mais erradas de todos os tempos. Eu digo isso por experiência porque isso assume que programadores dos anos 90 como eu eram todos burros. Bom, alguns eram. Mas pense assim: a gente entregava software no século XX.

Vamos ao capítulo 11: Planeje jogar um fora. Citando Brooks: “na maioria dos projetos, o primeiro sistema é quase inusável. Pode ser lento demais, grande demais, complicado demais, ou todos os 3. Não há outra alternativa a não ser começar de novo, melhor, e construir uma versão redesenhada em que esses problemas são resolvidos. Isso pode ser feito de uma vez ou pedaço por pedaço.” Tudo que você discute hoje sobre reescrever ou refatorar, é uma discussão que vem sendo feita faz décadas, nada de novo aqui. Nesse capítulo ele define que a única constante é mudança e a primeira coisa a se fazer é aceitar o fato que mudanças são fatos da vida, do que uma exceção. Prepare o gerenciamento do projeto para aceitar mudanças. Parece um tema moderno de Agile? Essa frase também é de 1975.

Ele fala que eventualmente você vai, de uma vez ou em partes, acabar reescrevendo o primeiro sistema. Mas no capítulo 5 ele avisa dos perigos do Efeito do Segundo Sistema. Citando: “A tendência geral é fazer um design grande demais no segundo sistema, usando todas as idéias que foram cautelosamente deixadas de lado no primeiro.” Ele avisa que o segundo é o mais perigoso sistema que uma pessoa vai desenhar. Exemplo clássico? Lembram do Windows Vista? Ou no nosso mundo mais recente: todo novo framework de Javascript?

Ele define e descreve em detalhes essas etapas. Incluindo a quantidade de bugs que aparecem no sistema por conta dessas mudanças e como lidar com elas. Ele não chama dessa forma mas ele advoga testes, fixtures, testes de regressão. Deixa eu citar um trecho desse capítulo de novo: “O problema fundamental com manutenção é que consertar um defeito tem uma chance substancial - 20 a 50%- de introduzir outro defeito. Então o processo todo é dois passos pra frente e um passo pra trás. E porque defeitos não são corrigidos melhor? Primeiro, porque mesmo um defeito pequeno que parece local tem ramificações pelo sistema todo. Qualquer tentativa de consertar com pouco esforço vai reparar o defeito local e óbvio, mas a menos que a estrutura seja pura ou muito bem documentada, os efeitos do reparo vão passar despercebidos. Segundo, porque o reparador é normalmente alguém que não escreveu o código original, e normalmente é um junior ou trainee. … Como consequência da introdução de novos bugs, programas de manutenção requerem mais testes de sistemas. Teoricamente, depois de cada correção você deve rodar a suíte inteira de casos de teste, para garantir que o sistema não foi danificado”. Você acha que o conceito de rodar suites de testes, manulmente ou automatizado, é algo moderno? De novo, 1975.

No capítulo 14 tem a frase que eu usei no video de Prioridades. “Como um projeto atrasa 1 ano? 1 dia de cada vez“. No capítulo ele diz: “Como alguém pode controlar um projeto grande com agenda apertada. O primeiro passo é TER uma agenda”. Defina milestones, defina prioridades, defina datas. Milestones precisam ser concretos, altamente específicos, mensuráveis. No mundo agile seria próximo da definição de DONE, ou finalizado, de cada etapa. Defina datas e faça caber, pra isso você precisa mudar alguma coisa: equipes, arquiteturas, backlogs. Mude, só não mude a data. Isso é gerência, qualquer coisa diferente é ingerência.

Se só isso não te convenceu. Vamos à edição de 1995. A parte interessante das edições modernas é que Brooks vem criticando seu próprio livro e atualizando ou expandindo alguns dos conceitos. Em 95 ele fala do capítulo 11 onde ele postula que você vai jogar fora o primeiro sistema e explica melhor. Ele começa falando que o modelo Waterfall ou cascata está errado e também corretamente explica como Winston Royce melhorou o modelo sequencial em cascata em 1970 (!!) adicionando: estágios de feedback. Então Brooks resume: a primeira falácia básica do modelo de cascata é que ele assume que o projeto avança pelo processo somente UMA vez” e a segunda falácia é que ele assume que o sistema é construído de uma vez. Qual a solução? Um modelo de construção incremental (!), por exemplo, ele menciona o modelo de Harlan Mills onde começamos a construir primeiro o esqueleto do sistema e várias funções vazias e vamos preenchendo uma a uma. Compile, teste, repita. E citando Brooks: “Em TODO estágio temos um sistema que roda. Se formos diligentes em cada estágio temos um sistema debugado e testado … e já que temos um sistema funcionando toda vez, nós podemos começar testes com usuários muito mais cedo, podemos adotar estratégias que fazem caber no orçamento o que protege contra atrasos no planejamento (ao custo de ter menos features)”. Ele basicamente descreveu conceitualmente o modelo de test driven development, deploys frequentes, ambiente de staging com versões que sempre funcionam. É só o que há de mais moderno no mundo “Agile” de hoje. Em 1995!!

Na verdade com os conceitos do capítulo 11, do Second System, e esse de 95, ele fala muito sobre protótipos que vão ser jogados fora mas vão te ajudar a “pivotar”. Ele define MVP ou Most Viable Product sem usar o termo MVP que só foi cunhado no Lean Startup do Eric Ries em 2011. Mas o conceito já é conhecido na engenharia de software faz décadas!

Você acha que continuous integration ou CI e continuous deployment ou CD são criações do Agile moderno? Esse capítulo de 95 menciona James McCarthy que descreve o processo de Nightly Builds, ou builds toda noite que a Microsoft fazia desde aquela época, um processo automatizado que toda noite recompila e reconstrói a versão mais nova, daí na manhã seguinte dava pra testar a última versão. Se tivesse um defeito grave, pára tudo, até consertar, e repete o processo.

Outra frase que todo mundo já ouviu pelo menos uma vez: “não existe bala de prata”. De onde vocês acham que vem isso? É o primeiro paper incluso na republicação de 20 anos de aniversário, de 1995! Ela se contrapõe à lei de Moore. Na Lei de Moore, que já acabou também aliás, Moore postulava que o poder de processamento dobraria a cada 12 a 18 meses. Simplesmente não há nada assim em software. Nós não conseguimos fazer projetos de software na metade do tempo a cada 12 a 18 meses. Nós estamos longe de ter sequer uma ordem de grandeza em eficiência de engenharia de software, é o elo perdido da nossa engenharia.

Durante a leitura do livro ele vai citando outros autores que vocês deveriam dar uma olhada. Se você assistiu minha série de porque sua linguagem não é especial, vão lembrar que eu mencionei Nicklaus Wirth que inventou talvez uma das coisas mais importantes de programação: a modularização, com sua linguagem Modula, antes do Pascal. Mas Brooks menciona bastante outro pesquisador importante: David Parnas, que criou o conceito de esconder informação, ou encapsulamento, um dos pilares da orientação a objetos que você usa até hoje e - eu tenho certeza - nunca sequer ouviu falar de David Parnas.

Além deles, Harlan Mills que desenvolveu uma metodologia de engenharia de software chamado Cleanroom e, que em muitos aspectos, já tem traços do que você poderia chamar de Agile. Finalmente Tom DeMarco, que eu tenho certeza que pelo menos você já ouviu falar por causa de seu famoso livro Peopleware.

Como podem ver The Mythical Man-Month é conterrâneo de alguns dos mais importantes nomes da computação, ele tem vários pontos que só fazem sentido se você pensar que ele foi escrito em 75 (portanto menciona-se linguagens como APL, Modula, ALGOL, COBOL, ADA, mas obviamente não menciona nada de Java ou Python, eles sequer tinham sido inventados na época!)

Eu vi Agile, técnicas de Extreme Programming, Repositórios como Git, todo o processo open source nascer desde o dia 1, e vejo como os conceitos já existiam antes. Se você só começou a programar no século XXI eu sei que parece que não havia nada antes, mas pra mim que começou a programar no fim dos anos 80, nada foi realmente surpreendente, só uma evolução do que eu já sabia. Eu vi muitas das coisas que eu já fazia ganhar nomes, só isso. Vou falar disso em outro episódio.

Novamente, se você leva a sério sua carreira de programação, deixe um pouco de lado os livros mais recentes - não estou dizendo pra não ler - mas comece por este. A partir dele, procure pela bibliografia de Fred Brooks, esses são os autores que realmente importam. Exemplos, eu mencionei nomes como Christopher Strachey do CPL ou Codd ou Dijkstra.

Não leia o livro de Brooks como um procedimento ou doutrina a ser seguida. Ele é uma conversa: um programador experiente de 75 dizendo ao programador de 2018 como ele continua cometendo os mesmos erros, usando como contexto, os projetos e tecnologias dos anos 70 e 80. E você deveria ficar mais assustado em ver como em 50 anos, muito pouco realmente mudou na engenharia de software.

E faz sentido, porque se toda vez você ignora o que já se sabe do passado, vai simplesmente cometer os mesmos erros e, se tiver sorte, chegar às mesmas conclusões. Seria mais inteligente subir no ombro de gigantes e usar o que eles já sabiam e nos avisaram. Eu faço isso, a forma como eu trabalho deriva mais de Brooks do que de Agile moderno. E quando eu vejo algumas barbaridades vindas do mundo Agile eu só penso … é …

Num lado mais positivo, ele fez um capítulo chamado “The Joys of the Craft” onde ele tenta explorar porque programação é legal. Em resumo ele chegou nestes pontos: Primeiro, simplesmente a graça em fazer coisas. Isso é crafting. Programação é uma profissão de prática. Ela depende de, prática! Segundo, o prazer em fazer coisas que são úteis pra outras pessoas Terceiro, o fascínio de ligar objetos complexos como quebra-cabeças de peças móveis e ver funcionar, brincando com as consequências dos princípios construídos no começo Quarto é o prazer de estar sempre aprendendo Finalmente, existe o deleite de trabalhar numa mídia tão maleável

Lembram o que eu venho dizendo nos vídeos sobre faculdade? A única coisa que você precisa é aprender a aprender, e o único jeito de fazer isso é primeiro gostando de aprender coisas. É o único jeito de começar a se tornar um bom programador. Se você se tornar doutrinado, só seguir certas marcas e só usar certas ferramentas, você nunca vai evoluir como programador. Você vai, no máximo, virar um bom codificador, ou datilógrafo. Copia mas nunca cria. Repete mas não sabe porque. Onde está a ciência em ciência da computação. Ciência não é dogmática.

E aí, o que acharam desse vídeo? Não me enganem, vocês já conheciam esse livro? Comentem abaixo se sim e o que mais gostam desse livro. Se curtiram o vídeo mantem um joinha, assinem o canal e cliquem no sininho pra não perder os próximos episódios! A gente se vê, até mais!

Descrição no YouTube

Esse é um assunto que todo mundo bate cabeça, mas o básico não é tão complicado quanto parece. Em vez de complicar as coisas sem necessidade, entenda a linha geral primeiro. Esqueça processos e metodologias se ainda não entendeu a primeira coisa mais importante em qualquer projeto: priorizar as coisas!

Links:

• AkitaOnRails: [Off-Topic] Lendo os Princípios Ágeis (http://www.akitaonrails.com/2010/01/30/off-topic-lendo-os-principios-ageis)
• AkitaOnRails: Estimates are Promises - A Better Metaphor (http://www.akitaonrails.com/2017/06/26/estimativas-sao-promessas-uma-metafora-melhor)

Script

Olá pessoal, Fabio Akita

HOJE quero tocar no assunto sobre projetos. Em particular sobre a importância de entender o que significa priorizar as coisas e o processo de gerenciar um projeto Não tem nada tão complexo que requer uma pós-graduação no assunto. Qualquer um pode entender os conceitos básicos e como um conceito naturalmente leva ao próximo.

Em outros episódios vou entrar em mais detalhes sobre cada um desse conceitos, mas hoje quero só mostrar a linha de raciocínio geral que você podem levar para qualquer projeto, pequeno ou grande, basta expandir as premissas que vou mostrar hoje.

…

Um dos problemas mais frequentes que eu vejo é a surpreendente capacidade das pessoas de fugir da priorização. Parece medo de priorizar. E não é difícil de entender porque.

O modo mais normal das pessoas é: “vou fazendo, uma hora dá certo”. Ou pior: “eu não escolho o que fazer, alguém escolhe por mim, e eu só vou fazendo”.

A molecada é muito ligeira pra postar no Twitter como a gerência do projeto ou da empresa é ruim. Mas eu pergunto: quantos desses já assumiram de fato o bastão da responsabilidade pra criticar com tanta confiança? É muito fácil se esconder na anonimidade da internet. Difícil é executar e mostrar resultado. Nunca ouça ninguém que não tem resultados mensuráveis pra mostrar.

Você não precisa ser um MBA ou um “Certified Scrum Master” … pra entender esses conceitos, porque eles são meio triviais na verdade.

Primeiro entenda uma verdade absoluta: você não tem tempo infinito. Sua vida não é infinita, uma coisa que temos em comum é que um dia vamos morrer. Se fôssemos imortais, priorizar seria irrelevante já que poderíamos realmente fazer o que quiser, quando quiser.

No mundo real, tudo é finito. Tempo é a primeira coisa finita. Segundo são recursos, dinheiro, pessoas, materiais. É finito, é restrito e normalmente é pouco. Sua expectativa é investir 1 unidade de recurso pra no futuro conseguir recuperar 2 ou 3. Sim, retorno. Senão você estaria simplesmente jogando recursos fora. Por exemplo, eu costumo dizer que o objetivo de qualquer Product Owner é a responsabilidade sobre o retorno do investimento. Na verdade, eu diria que o objetivo de qualquer profissional é o retorno de investimento sobre seu trabalho, senão pra que você trabalha?

Sendo tempo e dinheiro coisas finitas, você precisa Escolher o que fazer. A primeira coisa a precisa fazer é planejar, enxergar o começo e o fim. Essa é a definição de um projeto. Você tem uma lista de coisas pra fazer, mas provavelmente não dá pra fazer tudo.

Quem me conhece sabe que eu tenho um certo desdém por material de auto-ajuda. Porém sou obrigado a aceitar que analogias e metáforas ajudam a visualizar um conceito abstrato.

Eu vi um vídeo anos atrás, acho que foi de Stephen Covey, autor do famoso Os 7 Hábitos das pessoas altamente eficazes. Ele ensinava o conceito e a importância de priorizar. Eu nunca mais achei esse vídeo online, então quero recriar minha própria versão aqui.

Priorizar funciona assim: você costuma ter tarefas pequenas e tarefas grandes. Tarefas mais fáceis e tarefas mais complicadas. Se você não tem experiência, o normal é a inércia tomar conta e você começar a fazer as tarefas menores ou mais fáceis.

Só quando já é tarde demais se lembra que tinha as tarefas mais importantes que ficaram pra trás. Você percebe que desperdiçou seu tempo fazendo o que não era importante e agora não tem mais tempo. É assim que projetos atrasam: um dia de cada vez, deixando a priorização pra amanhã.

O que o povo aprende a fazer com o tempo? A olhar o big picture: quais são TODAS as tarefas? Quais são as MAIS importantes? Vamos fazer as mais importantes PRIMEIRO e ir encaixando as menos importantes no meio.

Iteração, iteração. E no final, a mesma quantidade de tarefas pode até mesmo CABER no mesmo TEMPO que antes não caberia.

Priorizar é avaliar. É tomar uma decisão e se comprometer. É errar, assumir o erro, reajustar e seguir em frente. É colaborar com os colegas, criar relacionamentos de confiança. Nosso povo sabe que pode confiar um no outro, sabe quem pode procurar pra qual tipo de problema, não existe perda de tempo e desperdício onde a gerência cria silos de influência e um grupo começa a sabotar outro grupo. Nosso povo funciona tão bem que eu posso quase que aleatoriamente ir formando equipes entre eles e eles sabem o que fazer.

Eu aprendi que todo projeto funciona como um gás: ele vai ocupar todo o espaço que você der pra ele. Se você der um ano, o projeto vai durar um ano e mais um pouco. O mesmo projeto se você der 6 meses, vai durar 6 meses e um pouco. A coisa mais importante em um projeto é delimitar os tetos: o custo e o tempo.

E como você sabe que vai durar isso? Você NÃO sabe. Não é uma previsão. Já notou que existem 2 palavras: estimar e prever? Pára de tentar prever. Estime. E estimar não é exato, pela definição da palavra. Estimar é chutar uma ordem de grandeza. Ordens de grandeza não é dizer que vai durar 743 horas e 54 minutos. É saber dizer a ordem de grandeza que estamos falando é uma semana, ou um mês, um semestre, um ano.

O que você faz quando precisa ir pra um lugar longe e não tem um Waze pra te guiar? Você pega um mapa. Mas não tem como ir vendo o mapa o tempo todo e dirigindo ao mesmo tempo. Então você dirige um trecho até onde acha que ainda sabe o caminho. Daí você pára, olha o mapa e vê se continua no caminho certo. Daí prossegue. Pára de novo. De repente você nota que entrou numa curva errada, então você volta até a última bifurcação e corrige. E vai assim até o fim. Por isso a temos sprints ou iterações, senão você ia até o fim do caminho pela estrada errada e quando perceber que tinha feito uma curva errada, já é muito tarde pra voltar. Se for reavaliando em trechos menores, mesmo que precise voltar um pouco ainda dá tempo de corrigir. Faz sentido?

Essa é a essência de gerir um projeto: não é acertar todos os passos, mas garantir que se você errar - e vai por mim, você vai errar - dá tempo de voltar um pouco atrás e corrigir o percurso. Gerir não é evitar 100% dos erros, é garantir que o 1% que errar Não vai comprometer os 99%. Tente ir às cegas: você cai do barranco.

E como você sabe de quanto em quanto tempo parar? Na dúvida pára no menor período possível. Por isso quando me falam de sprints de 3 semanas eu dou muita risada. Significa que se você errar, você vai levar no mínimo 3 semanas pra corrigir e isso pode gerar um efeito cascata de erros que vai prejudicar pelo menos 1 mês e meio de trabalho. Agora começa a escalar isso, é assim que um projeto atrasa 1 ano.

E como você estima as coisas? Tanto faz. Esqueça fórmulas complicadas, diferença de story points, ou qualquer tipo de points. Usa uma escala assimétrica. O menos granular possível. Por exemplo: fácil, médio ou difícil. 1, 2, 5, 8. Por que assimétrico assim? Porque numa ordem de grandeza você quer saber só se a tarefa leva meio dia, um dia inteiro, dois dias ou 1 semana. Mais que isso tanto faz, 5 ou 4 ou 6 dias não faz diferença. Basta 1 story de 8 pontos pra quebrar suas pernas, daí as outras stories de 1 ou 2 pontos não fazem diferença porque essa de 8 é que vai definir seu andamento. É como a demonstração da esfera maior ou das bolinhas menores. Ordem de grandeza. Você só precisa saber quais são as histórias que representam o maior risco, e lidar com o risco. Talvez quebrar em história menores se possível.

Finalmente, você vai ter sua velocidade: quantas dessas histórias são possíveis de serem feitas dentro de um período ou sprint. Com uma ordem de grandeza de velocidade, agora você olha pro projeto como um todo e diz: com essa velocidade atual, dá pra chegar ao fim?

Normalmente não dá. Então você precisa começar a cortar o que é menor prioritário e está no fim da lista. E avisar o quanto antes todo mundo: NÃO VAI DAR TEMPO DE TUDO. É simples assim. Das duas uma: ou simplifica o que precisa fazer ou CORTA o excesso, corta. E não tenta como primeira opção aumentar o custo ou aumentar o tempo. Faz caber! E nem adianta tentar aumentar a velocidade à força. É como no exemplo da viagem de carro sem Waze. Tenta acelerar sem ter certeza, você só vai errar mais bifurcações mais vezes e ter que voltar atrás mais vezes. Não compensa só pisar no acelerador.

Mas e se não for aceitável simplificar ou cortar? Então cancela o projeto, pára agora. Se a premissa inicial tava subestimada, é melhor aceitar um prejuízo pequeno do que tentar acelerar e no final gastar mais e o prejuízo aumentar. É o problema do custo perdido. Sempre é melhor perder o que já gastou no curto prazo do que insistir no erro e no final gastar mais. Deixa eu parar pra explicar custo perdido um pouco.

Digamos que você comprou um ingresso de cinema mas só depois vai ver as críticas e descobre que o filme é uma droga por unaminidade. Assumindo que você não tem nenhum conhecido idiota que compraria seu ingresso, você tem duas opções:

1. Já que você já pagou pelo ingresso, vai assistir pra não desperdiçar
2. Jogar o ingresso fora

A falácia do custo perdido é não perceber que em qualquer das duas opções, você já pagou pelo ingresso e não vai ter reembolso e portanto o custo perdido não é relevante pra tomar uma decisão racional.

Opção 1: Você sofre o custo do ingresso + Você sofre pelo resto do filme Opção 2: Você sofre só o custo do ingresso e não desperdiça também o seu tempo

Racionalmente a opção 2 é melhor.

E pra chegar nessa conclusão, primeiro você teve que fazer os passos anteriores que falei: enxergar os limites do projeto que são o tempo e o custo, enxergar o que é o objetivo do projeto, organizar o que é essencial e importante e o que é opcional e pode ser deixado pro fim ou até mesmo cortado, começar a fazer, parar e ver se não errou o caminho, e uma vez determinada a velocidade normal, ver o objetivo é alcançável ou não. E, se não for, parar imediatamente antes de gastar mais do que precisaria pra não chegar em lugar nenhum de qualquer jeito.

E isso, senhoras e senhores, é a essência de gerência de projetos. Avançar num objetivo inalcançavel, continuar remando num navio que vai afundar, não é gerenciar, é simplesmente dirigir às cegas sem um mapa. E tudo começa com priorização.

Como eu disse no começo, o objetivo desse vídeo não é transformar ninguém em um ultra gerente de projetos. É só introduzir os primeiros conceitos do que todo mundo, gerente ou não gerente, deveria saber. Em outros vídeos eu quero explorar alguns desses conceitos em mais detalhes, algum em especial que você tenha interesse? Não deixe de mandar nos comentários quais aspectos de projetos mais deixam você inquieto. E se gostou deste vídeo mande um joinha, assine o canal e não deixe de clicar no sininho pra não perder os próximos episódios. A gente se vê até a próxima !

Uma das mais populares responde à pergunta “Qual é a coisa mais difícil que você faz como engenheiro de software?”. Escrevi algo parecido em português no post “Estimativas são Promessas. Promessas devem ser cumpridas.”.

Em resumo: você nunca consegue dar uma estimativa “correta”. Se conseguisse, não seria uma “estimativa”, seria uma “previsão”.

Vamos assumir que não temos poderes de precognição nem bolas de cristal para prever o futuro.

Estimar algo é “chutar” o valor de alguma coisa. É sempre um chute, a mesma coisa que uma avaliação. Como todo chute, nunca pode ser considerado “correto”: é só um candidato provável dentro de uma faixa infinita de valores possíveis.

Não existe nenhuma conexão entre um chute e o resultado. Entenda essa verdade simples: dizer que algo pode acontecer não FAZ com que aconteça.

Estimar que vai chover amanhã não FAZ chover. Estimar o resultado do Super Bowl não FAZ o jogo acontecer daquele jeito. Não há correlação entre uma estimativa e o resultado real.

Eu disse nos artigos mencionados que “Estimativas são Promessas”. A intenção era provocar uma reação, porque a maioria das pessoas assume que estimativas jamais podem ser promessas, justamente pelo que acabei de explicar.

O que torna uma promessa especial é que, ao prometer algo, espera-se que você AJA para realizá-la.

Ninguém que não tem “skin in the game” deveria dar estimativas.

Se você não é um jogador ativo no jogo, não deveria dar chutes. Do mesmo jeito que ninguém faz promessas em nome de outra pessoa.

Dá pra fazer promessas críveis e cumpri-las? Dá, mas primeiro você precisa entender mais algumas verdades sobre a realidade.

Você provavelmente já leu muitos artigos explicando metodologias e técnicas de gestão de projetos. A maioria consegue explicar os “o quês” e os “comos”, mas como sempre, falha nos “porquês”.

Por que precisamos dessas metodologias? Por que elas são necessárias? Por que funcionam? Que mecanismos ocultos elas colocam em movimento?

O que diferencia as técnicas Ágeis da homeopatia ou de um clichê barato de autoajuda?

É sempre sobre Pareto

Não existe escopo de projeto preciso. Existe um limite para adicionar detalhes, e depois dele você só tem retornos decrescentes.

O nível mais preciso de detalhe que o escopo de uma funcionalidade pode ter é o próprio código. E isso importa: as linhas de código NÃO são o produto final. O que os usuários experimentam de fato é a execução desse código em tempo de execução.

A programação em si é o blueprint de verdade. Os diagramas, os casos de uso, as user stories e tudo que vem antes da programação são só rascunho, um esboço.

Um arquiteto ou designer ingênuo pode achar que diagramas detalhados, documentos de casos de uso e slides bonitos de PowerPoint valem o mesmo que um blueprint de engenharia. Eles valem menos: são o equivalente a um rabisco no guardanapo. Voláteis e, na prática, quase inúteis.

“Mas a programação não é a mesma coisa que a fase de construção, colocar tijolo sobre tijolo?” NÃO, não é isso que um programador faz. Empilhar tijolos é trabalho do interpretador da linguagem ou do compilador que gera o binário executável.

Essa é a metáfora que deixa os não-programadores malucos. Na engenharia, a construção em si é a parte mais cara e demorada. Na programação, a parte cara é criar o blueprint (escrever o código), e a “construção” é trivial: só compilar, o que é automático.

Do mesmo jeito, o escopo de um projeto é só um conjunto de esboços. Precisamos abandonar a ideia de que vai existir um escopo “completo”. Não dá pra dizer “100% do escopo” ou “escopo fechado”, porque o escopo de um projeto de software é, por definição, sempre incompleto.

Além disso, sustento que cerca de 80% desse tal “escopo”, o que prefiro chamar de esboço, é praticamente inútil para a maioria das atividades dos usuários finais: a seção administrativa, as páginas institucionais que ninguém lê, processos complicados de cadastro e por aí vai.

Por isso toda lista de funcionalidades precisa ser priorizada. Você costuma se virar com 20% das funcionalidades, que é o que as pessoas querem dizer com “MVP” ou “produto mínimo viável”. Entregue o mais cedo possível, colete feedback dos usuários e refine o resto do “esboço” que você chama de backlog.

Então, em vez de mirar numa proposição de tudo-ou-nada, procurando equações complexas e estúpidas para calcular uma estimativa “precisa” de um esboço incompleto, assuma que dá pra entregar CEDO os primeiros 20% que realmente importam e descubra o resto em iterações.

É isso que chamamos de “Ágil”, aliás.

Ágil é sobre Gestão de Riscos

As pessoas assumem que Agilidade é gerenciar os próprios instrumentos de gestão: o backlog, os rituais, as métricas.

Ter instrumentos parecidos com Ágil não te torna Ágil.

Ser Ágil é manter o Risco sob controle.

Em vez de tratar projetos como uma proposição de tudo-ou-nada, comece a pensar como um investidor pensa no seu portfólio de ações. Você não espera que o portfólio inteiro dê lucro; parte do princípio de que alguns ativos vão ter desempenho abaixo do esperado. Como não sabe quais, você dilui o risco.

Tentar prever o mercado de ações é um exercício de futilidade.

Tentar prever a implementação exata de um projeto, ainda mais os longos, também é um exercício de futilidade.

Então você precisa lidar com a incerteza do jeito certo: tornando-se Antifrágil.

“Algumas coisas se beneficiam de choques; elas prosperam e crescem quando expostas à volatilidade, aleatoriedade, desordem e estressores, e adoram aventura, risco e incerteza. No entanto, apesar da ubiquidade do fenômeno, não existe uma palavra para o exato oposto de frágil. Vamos chamá-lo de antifrágil. A antifragilidade vai além da resiliência ou robustez. O resiliente resiste aos choques e permanece igual; o antifrágil melhora.” - Nassim Taleb

Em vez do exercício absurdo e inútil de tentar prever incertezas e eventos aleatórios, você faz a coisa sensata: assume que Cisnes Negros existem e que você não consegue prevê-los. E aí se prepara para a incerteza da única forma razoável, que é não tentar prevê-los.

Exponha os pequenos erros cedo e corrija com frequência. Implementar tudo numa caixa-preta e fazer um deploy Big Bang é o caminho mais fácil para o fracasso. Entregar sempre, expor os bugs e corrigi-los constantemente é aceitar que erros vão acontecer e ganhar força no processo.

Uma Metáfora Melhor

Imagine que você, seja o cliente não-programador, seja o programador que não faz ideia de como explicar o processo para esse cliente, tem um alto-forno de minério de ferro para gerenciar.

O problema desses fornos é que, se você aquecer demais, eles podem explodir na sua cara. Se esfriar demais, o minério endurece.

Seu trabalho é adicionar carvão ao forno, e você decide o ritmo. Rápido demais, fica quente o bastante para explodir. Devagar demais, o fogo apaga e você perde o forno.

Agora tente estimar uma entrada constante de carvão para manter o forno em bom estado.

Não dá.

A saída mais fácil é instalar um termômetro que acompanha a temperatura atual do forno.

Você fica seguro dentro de uma certa margem de temperatura e acelera ou reduz a entrada de carvão consultando o termômetro o tempo todo.

O TEMPO TODO.

É isso que a “Velocidade” do Ágil (ou qualquer simulação de Monte Carlo mais sofisticada) realmente é: um termômetro.

Se a Velocidade está alta demais, seu time provavelmente está fazendo hora extra ou entregando código de qualidade inferior. Isso vai dar problema: ou o time estoura rápido demais, ou o código acumula dívida técnica rápido demais e você não vai conseguir pagar. Mantido esse ritmo, a Velocidade despenca até parar (o forno explode).

Se a Velocidade está baixa demais, seu time está enrolando, seu backlog é um lixo que ninguém entende nem depois de 10 horas de reunião, ou você deixou a Velocidade subir demais e agora está pagando a dívida técnica, ou seu time está morto de burnout (o fogo apagou).

Você quer manter a Velocidade estável, constante. É disso que se trata ser Ágil: ficar de olho no termômetro e responder.

O Triângulo de Ferro dos Projetos

Bem-vindo ao Triângulo de Ferro da Gestão de Projetos.

Repita comigo: se eu quero travar o tempo, o custo e o escopo, sou um idiota.

Repita de novo.

Você deve travar tempo e custo. Se leu até aqui, sabe que nunca consegue travar o “escopo”: só dá pra engordá-lo, e nem sempre torná-lo mais valioso. Por isso sempre digo que a definição de um Product Manager ou Product Owner é ser o guardião do ROI (Retorno sobre Investimento).

Por quê?

Porque o Triângulo de Ferro tem o seguinte corolário:

• Se quer rápido e bom, não pode ser barato
• Se quer rápido e barato, não pode ser bom
• Se quer bom e barato, não pode ser rápido

Isso é uma Lei, não tem como contornar. Escolha o seu.

Como Cumprir Promessas então?

Com essas 3 verdades em mãos:

• Não dá pra ter tudo ao mesmo tempo (barato, rápido e bom)
• Você está gerenciando a temperatura do forno
• Você só precisa de 20% do “esboço” que chama de “escopo”

Sim, qualquer desenvolvedor experiente consegue te dar uma estimativa de “ballpark”. Uma estimativa de ballpark é assim:

• 1 mês (talvez 1 mês e meio, mas com certeza menos de 2)
• 3 meses (mais de 2 meses, menos de 6)
• 6 meses (mais de 4 meses, menos de 9)
• mais de 6 meses, provavelmente menos de 1 ano

Nem tente granular mais que isso. É inútil.

Trave o tempo. E trave o custo (o número de desenvolvedores vezes a taxa horária vezes o total de horas estimadas). Só isso.

Agora anote o que o cliente chama de “escopo” como user stories num backlog e peça pra ele priorizar.

Comece as iterações. Depois de cada uma, faça deploy num ambiente de staging. Não-programadores, atenção: SEMPRE garanta que o programador que você contratar entregue versões testáveis das stories numa URL pública que você possa visitar e testar.

Se o programador recusar isso ou vier com desculpa: DEMITA.

Se o programador, a empresa ou seja lá o que for te prometer um preço de “escopo fechado”, prometer fazer tudo e você acreditar, você é ingênuo demais.

Acha graça em jogar esse jogo idiota de “vou fingir que sei a verdade e você vai fingir que acredita no que estou dizendo”?

Nenhum profissional sério tem tempo pra jogos idiotas. A única coisa honesta que alguém pode dizer sobre qualquer projeto de software é: “com base na minha experiência, acredito que o ballpark para esse tipo de projeto é de X meses, dados os pressupostos Y e Z”.

Você não precisa acreditar nele. Só precisa começar a verificar o termômetro. Qualquer não-programador consegue avaliar a qualidade da entrega a partir das entregas frequentes das funcionalidades priorizadas.

“Mas e se depois de 2 semanas eu não gostar do resultado?” Simples: DEMITA.

E às vezes “demitir” nem é a palavra certa. Às vezes o relacionamento é difícil e o melhor é seguir caminhos separados.

Você precisa aceitar perder 2 semanas, ou qualquer período curto, como parte da Gestão de Riscos. É melhor aceitar perder 2 semanas do orçamento do projeto do que acreditar cegamente em alguém por 6 meses e perder o orçamento inteiro e mais um pouco.

Pareto de novo: Agilidade é sobre Gestão de Riscos. Você aceita que perder 20% do orçamento está de bom tamanho e joga com isso. E tudo bem, porque você só precisa de um pouco mais de 20% do esboço vago que chama de escopo.

Viu o que fiz com a matemática aqui?

Paramos de jogar o faz-de-conta e passamos a gerenciar de fato os riscos do projeto. Você colabora no termômetro equivalente, que combina o backlog priorizado (a escala) e a velocidade (a temperatura), e fica de olho nas entregas parciais no ambiente de staging.

Conclusão

Então sim, Estimativas devem ser levadas tão a sério quanto Promessas. Você consegue dar Estimativas razoáveis desde que consiga gerenciar os Riscos e o Cliente aceite as regras do jogo: não existe “escopo fechado e completo”, prioridades primeiro, e testar e aceitar funcionalidades entregues toda semana.

A ideia por trás das Promessas é que você precisa GERENCIAR para cumpri-las. A melhor forma é parar com frequência, reavaliar e seguir. Parece perda de tempo, mas é assim que você evita desperdiçar tempo de verdade.

Se você não tem skin in the game, dê um passo atrás.

A Velocidade deve ser mantida estável, num ritmo previsível. Use a variância como sinal de estar rápido demais ou devagar demais, ajuste a outra variável, meça de novo e siga. Igual a um termômetro de forno.

Existem várias versões de “termômetros”, do Evidence Based Scheduling do Joel Spolsky às sofisticadas simulações de Monte Carlo e outros processos estocásticos (todos são termômetros, e NÃO ferramentas de estimativa).

O que te impede de fazer isso é usar as metáforas e as referências erradas.

Em vez de procurar metáforas equivalentes na construção civil, nas fábricas e em outras montagens de “hard”-ware, olhe para outro lugar, onde você vai encontrar processos de “soft”-ware.

Músicos têm prazos. Pintores têm prazos. Coreógrafos têm prazos. Esportes têm prazos. Laboratórios de pesquisa têm prazos. Como eles cumprem? Verificando constantemente o estado atual, comparando com os objetivos, avaliando se o que fazem está funcionando e mudando o que não funciona.

Hollywood tem prazos. Tem variáveis muito piores de controlar do que qualquer projeto de software que você vá encontrar, e ainda assim entrega. E lucra.

Aceite que você não controla todas as variáveis e pare de tentar. Pense nos mercados financeiros. Um dia o Ethereum dispara 4.000% e no dia seguinte despenca num flash-crash.

Não tente ficar resistente ou resiliente. Prepare-se para ser Antifrágil.

Mas você é uma pequena startup de tecnologia ou uma equipe pequena dentro de uma grande corporação. Por onde começar?

A recomendação é simples: faça a menor coisa que funciona primeiro. Sempre. Claro, evite o “rápido e sujo” ao máximo. Mas não seja paranoico nem exagere na engenharia.

Super-engenharia é tão cara quanto fazer as coisas de forma “suja”.

Adicione “Tempo” à sua equação

O erro mais comum que a maioria das pessoas comete é ignorar a variável “Tempo”.

Todo mundo vai a conferências de tecnologia, lê posts badalados ou assiste screencasts chamativos. A conclusão errada que tiram é: “a Netflix usa isso, então deve ser bom pra mim, porque eu quero me tornar a Netflix”.

O pressuposto falso é que a Netflix, ou o Google, ou o Facebook, ou o Spotify, é um sistema estático e sempre funcionou da forma como divulga hoje.

As pessoas esquecem que toda empresa unicórnio teve um dia 1. E no dia 1, elas não usavam microsserviços. Não tinham React.js. Não tinham Go nem Elixir. Algumas nem tinham bons programadores de início. A Netflix começou como um serviço de aluguel de VHS, lembra? O Google começou num quarto de dormitório universitário com componentes de hardware montados num rack de Lego.

Imagine que você é fã de uma celebridade. Essa celebridade tem uma Lamborghini. Você quer ser como essa celebridade um dia. O que você faz? Compra a mesma Lamborghini que ela tem?

Se você fizer isso, a única coisa que vai conseguir é uma DÍVIDA ENORME para pagar.

Pare de invejar a Lamborghini do rico.

Dívida (Técnica)

Esse não é um termo novo nem um tema novo. Cada decisão que você toma em programação é um compromisso entre o que o “futuro ideal” deveria ser e o que você consegue fazer agora. Tomar empréstimo para comprar a Lamborghini equivalente cedo demais, e você vai ter que lidar com uma Dívida (Técnica) impagável. Você vai travar, vai parar e não vai fazer nada além de pagar essa dívida daqui pra frente.

Você quer “codar mais rápido”, então pula a escrita de testes automatizados, porque acha que vai te atrasar. E você está certo. O desenvolvimento orientado a testes não te deixa mais rápido de início, e nem deveria. Ele protege seu eu futuro do seu eu presente e evita que você acumule Dívida Técnica.

De novo: você esqueceu a variável “Tempo”.

Você escreve e entrega rápido no primeiro mês. Depois que a primeira versão está em produção, você começa a ser obrigado a pagar a dívida. Sua produtividade cai. Bugs de regressão aparecem. Cada nova funcionalidade que você tenta adicionar quebra algo de forma inesperada. Como não tem testes automatizados, você fica corrigindo as mesmas coisas várias vezes. A dívida vai cobrar, e você vai pagar. De um jeito ou de outro.

Suítes mínimas de testes são como um Seguro. Você não precisa dele agora, no dia 1. Mas no dia 100 você vai ficar feliz que tem.

Fazer microsserviços demais no dia 1 é dívida. Parece ótimo estar fazendo aquela coisa bacana que você leu num blog. No dia 100, com sua equipe de 3 pessoas e uma dúzia de microsserviços, você não vai fazer nada além de pagar a dívida acumulada, com Juros. Cada novo deploy de microsserviço quebra seu sistema. E claro, você não adicionou monitoramento, não adicionou testes integrados. Então toda vez que você sobe algo, outra coisa quebra de forma inesperada.

Ainda está curtindo a Lamborghini antecipada?

O Mítico Homem-Mês

Philip Calçado escreve ótimos posts e apresentações sobre microsserviços do jeito certo. Se você leva esse assunto a sério, recomendo fortemente que leia seus textos, como o “Prerequisites” ou sua apresentação “Economics”.

Ele cita corretamente O Mítico Homem-Mês, de Fred Brooks. Insisto que os desenvolvedores leiam esse livro pequeno. É impressionante como a indústria inteira ainda repete exatamente os mesmos erros que Brooks relatou em seu livro, de projetos dos anos 60!

Para mim, microsserviços são um subproduto de empresas de tecnologia com programadores em excesso. Quando você ultrapassa a barreira de 5 desenvolvedores, um sistema “monolítico” com organização ruim e poucos testes automatizados pode ficar difícil de lidar. A consequência natural é a vontade de fragmentar. Você cria 2 equipes e 2 microsserviços e tenta coordenar. As equipes começam a se isolar e a praticar o jogo de culpar o outro quando novos bugs aparecem (“é culpa do microsserviço da outra equipe”).

É a Lei de Conway aplicada da forma errada:

Qualquer organização que projeta um sistema (definido de forma ampla) produzirá um design cuja estrutura é uma cópia da estrutura de comunicação da organização.

Também entra em jogo outro capítulo do livro do Brooks: o Efeito do Segundo Sistema. Todo desenvolvedor e toda startup precisa assumir que a primeira versão de qualquer coisa não é o melhor design. E o segundo sistema (a primeira grande reescrita) é o sistema mais perigoso que você vai construir. Como Brooks descreve:

O primeiro trabalho de um arquiteto tende a ser enxuto e limpo. Ele sabe que não sabe o que está fazendo, então procede com cuidado e grande contenção.

Enquanto projeta o primeiro trabalho, adornos e embelezamentos vão ocorrendo a ele. Esses ficam guardados para serem usados “na próxima vez.” Cedo ou tarde o primeiro sistema está pronto, e o arquiteto, com confiança firme e maestria demonstrada nessa classe de sistemas, está pronto para construir o segundo.

Esse segundo é o sistema mais perigoso que um homem já projeta. Quando faz o terceiro e os posteriores, suas experiências anteriores se confirmarão mutuamente quanto às características gerais de tais sistemas, e as diferenças identificarão as partes de sua experiência que são particulares e não generalizáveis.

A tendência geral é super-projetar o segundo sistema, usando todas as ideias e adornos que foram cautelosamente deixados de lado no primeiro. O resultado, como diz Ovídio, é uma “grande pilha.”

O que acontece depois? O CEO, o conselho, os investidores, seja lá quem for, começam a fazer a coisa errada: contratar mais e mais pessoas. Tomar mais e mais empréstimos. Em vez de pagar as dívidas, acumulam mais dívida. Caíram na armadilha que Brooks relatou no primeiro capítulo e que dá nome ao livro: O Mítico Homem-Mês.

Adicionar mão de obra a um projeto de software atrasado o atrasa ainda mais.

Projetos de programação complexos não podem ser perfeitamente particionados em tarefas discretas que possam ser executadas sem comunicação entre os trabalhadores e sem estabelecer um conjunto de inter-relações complexas entre as tarefas e os trabalhadores que as executam.

Portanto, alocar mais programadores a um projeto que está atrasado o atrasará ainda mais. Isso porque o tempo necessário para os novos programadores aprenderem sobre o projeto e a sobrecarga de comunicação aumentada consumirão uma quantidade cada vez maior do tempo disponível no calendário.

De novo: ignorando a variável “Tempo”. E confundindo “dívida” com “investimento”.

Antes de tudo, faça um favor a si mesmo e leia o maldito livro, duas vezes.

Faça Agile do jeito certo! E não, não é Kanban!

Se há uma coisa boa que todo o barulho do Lean produziu, é a noção de “Produto Mínimo Viável” ou MVP. Alguns chamam de “protótipo”. Outros chamam de “lançar em Beta” ou simplesmente “versão 1.0”. Não importa o nome. É o reconhecimento de que você não sabe muita coisa no início, então fazer engenharia excessiva na primeira versão é desperdício de tempo. Lean é sobre controlar o “desperdício”: fazemos o mínimo que funciona, medimos os resultados e evoluímos a partir daí.

Os cínicos vão dizer que qualquer protótipo que chega a produção nunca morre. E não estão errados.

O equilíbrio está em não fazer a versão “rápida e suja”. É pra isso que existem as técnicas ágeis. Faça o mínimo, organize o mínimo. É pra isso que existem os padrões de design orientado a objetos, do GoF ao DDD. Você não precisa aplicar TODOS os padrões, e é justamente isso que significa “super-engenharia”. Mas dá pra fazer o monolito mínimo que vai te permitir evoluir depois.

As pessoas criticam Ruby on Rails por não ser organizado “o suficiente”. Nick Sutterer, o criador do Trailblazer, tem um ponto válido.

Rails feito errado é ruim. Mas a conclusão NÃO deveria ser: “vamos fazer microsserviços”. Esse salto de fé é idiota e não faz sentido por todos os motivos que citei acima.

“Vamos fazer Agile de verdade e orientação a objetos de verdade” deveria ser a resposta inicial.

E por “Agile”, esqueça os post-its idiotas, esqueça as equações de estimativa baseadas em numerologia (isso dá um post inteiro por si só, porque story points e velocity são úteis, mas adicionar Montecarlo e outras coisas baseadas em distribuição Gaussiana não faz sentido). As únicas coisas “Ágeis” com as quais você deveria se preocupar são as técnicas de Extreme Programming (XP), incluindo os timeboxes baseados em iterações.

Você PRECISA fazer timeboxes. Pare, reavalie, mude de direção, e então continue. O modelo de “Pull” só faz sentido quando sua direção é muito, muito clara, escrita em pedra e imutável, como numa linha de produção de fábrica. (Que é exatamente onde o conceito de Pull, e o Lean, nasceram!)

Iterações, como testes automatizados, são como um Seguro. Você nunca consegue evitar todo o desperdício, mas pode minimizá-lo. Você pode se dar ao luxo de jogar fora o trabalho de uma Iteração inteira. Depois da iteração você mede os resultados e descarta se necessário, mudando de direção no processo. Jogar fora o que não serve é tão importante quanto adicionar coisas novas. Se você só acumula, está com um transtorno de acumulação!

Na dúvida, faça XP. Sim, parece mais “difícil”, e o Kanban é “mais simples” de explicar. Mas isso é motivo suficiente?

Esqueça Performance Bruta quando você NÃO precisa dela!

Outro problema é escolher linguagens ou frameworks por causa de performance.

Se você está no negócio de desenvolvimento web, isso é um DESPERDÍCIO enorme.

Entenda essa verdade: seus servidores vão ficar OCIOSOS na maior parte do tempo. E se você acha que seu web app está lento, a lentidão vem da PROGRAMAÇÃO RUIM que você fez, não da linguagem. Nenhuma linguagem boa vai salvar um programador ruim. Sempre digo que se performance fosse assim tão importante, todo mundo deveria estar usando C.

A maior parte do que você serve em apps baseados em HTTP, seja conteúdo para o usuário, seja resultado de API GET, pode ser CACHEADA! Se você não está usando uma CDN, está fazendo errado.

Sim, sim, sim, você acha que está construindo o próximo Spotify. Não está, pelo menos 99% de vocês não estão. E os 1% que fazem engenharia personalizada, com técnicas e stack próprios, e com sucesso: vocês são os 1%. Na verdade, são uma fração dos 1%. Não assuma que o que você faz é bom para o resto da população.

90% do que a maioria das pequenas empresas e desenvolvedores web solo precisam é só uma conta no Shopify e uma instalação padrão do WordPress. É isso.

Você está fazendo desenvolvimento de infraestrutura, como construir componentes customizados para Docker, Kubernetes, Terraform? Ferramentas de linha de comando? Daemons? Então escolha GO.

Está fazendo bibliotecas embutidas? Talvez a próxima geração do OpenSSL? Drivers? Então escolha RUST.

Está fazendo desenvolvimento mobile? Não tem muita escolha: Swift para iOS, Kotlin/Java para Android. Ou React Native para apps mais simples.

Está realmente construindo o próximo Whatsapp? O próximo Waze? O próximo Snap? Tem centenas ou milhares de usuários precisando de conexões de longa duração em redes não confiáveis fazendo broadcast de mensagens? Ou está construindo a próxima evolução de bancos de dados NoSQL distribuídos? Ou qualquer coisa que tenha o sentido real de “Distribuído” em sua definição? Então escolha ELIXIR.

Está fazendo uma aplicação web baseada em CRUD? Vai de RAILS e não olha pra trás.

Está fazendo tudo isso ao mesmo tempo? Use todas as alternativas então. E espero que tenha orçamento, porque vai precisar de uma equipe grande.

Conclusão

A Economia só faz sentido quando você considera o dia 1. Não esqueça a variável “Tempo”. Ela faz toda a diferença.

Você sempre vai ter Dívidas a pagar. Então seja inteligente na escolha de qual tipo de dívida você assume. Porque vai ter que pagar de volta eventualmente.

De novo: leia Brooks. Ele disse isso décadas atrás: NÃO EXISTE BALA DE PRATA. Não se iluda. Uma nova linguagem, um novo framework, uma nova arquitetura. Nada disso vai te salvar.

Em qualquer empreitada tecnológica, código não é a única preocupação. Diria até que numa startup de tecnologia, código é apenas 20% do problema. Uma startup de tecnologia é só uma empresa, como qualquer outra. Se você é o fundador ou CEO, tem que lidar com os 80% restantes: marketing, contabilidade, recursos humanos, questões legais, etc. Já é difícil o suficiente sem que sua equipe técnica te traga uma Dívida Técnica indesejada, a Lamborghini desnecessária, que você não vai conseguir pagar.

Você pode começar humilde no dia 1. Continue evoluindo, continuamente. Esse é o núcleo de qualquer processo Agile ou Lean: KAIZEN. Escolha dívidas inteligentes, pague-as aos poucos, continuamente. É o mesmo raciocínio de fazer um empréstimo no banco.

O dia 7.200 da Netflix NÃO é o seu dia 1.

O dia 4.800 do Facebook NÃO é o seu dia 1.

O dia 6.809 do Google NÃO é o seu dia 1.

Seja humilde. Entregue rápido. Pague suas Dívidas. Continue evoluindo continuamente. Pare de acreditar em contos de fadas e balas de prata.

Uso o Pivotal Tracker desde 2010 até 2015, e isso porque eu acredito que ele é muito superior ao Trello e outras listas de tarefas glorificadas por aí.

O Dilema do Custo

Como em todos os outros relatos, vou começar pelo argumento do custo. O Pivotal Tracker tem preço baseado na quantidade de usuários.

Se você tem um time pequeno e poucos clientes externos, um plano básico de 10 usuários já resolve, e você vai pagar apenas USD 420 por ano. Simplesmente pague e pronto.

Se você tem até 25 usuários, ainda continua barato, e sai por USD 1.800 por ano. Vale muito a pena.

Mesmo se você tiver 50 usuários, o plano máximo, você vai pagar USD 3.600 por ano. Acima disso, precisa entrar em contato direto com eles.

O custo está longe de ser proibitivo e, se você puder pagar, meu conselho é que pague.

No meu caso, a estratégia é ter controle total sobre nossos dados e conhecimento, e por isso prefiro ter a propriedade do serviço.

E como o Fulcrum estava “quase” bom o suficiente, resolvi testar e ver se conseguíamos evoluí-lo com o tempo. Acredito que, mesmo estando ainda muito longe do Tracker completo, o que temos hoje já atende à maior parte dos nossos projetos.

Deixa eu repetir: provavelmente você não vai ganhar nada com isso se seu time for pequeno. O Pivotal Tracker continua sendo, até hoje, a melhor ferramenta de gestão de projetos para times de desenvolvimento de software, e você deveria testá-lo primeiro, se acostumar com o fluxo dele (como vou explicar abaixo), e só depois decidir se quer assumir o controle e instalar a alternativa open source.

Tem o fator custo, claro, mas ele não é o incentivo principal para essa mudança.

As Funcionalidades Importantes

Pesquisando um pouco, encontrei o projeto Fulcrum. É um projeto Rails muito simples, muito bare-bone, que imita as funcionalidades mais importantes do Tracker.

Qualquer ferramenta competente de gestão de projetos precisa ter, no mínimo, 4 pilares:

• Stories (com threads de discussão, upload de arquivos, tags, organização em Epics e busca)
• Estimativa numérica adequada (story points, tamanho proporcional para as stories)
• Sprints com time-box (períodos curtos e fixos de tempo)
• Velocity (a produtividade real de um determinado time em um determinado projeto)

Qualquer ferramenta que tenha todos os itens acima já é útil.

O próprio Fulcrum tem quase tudo. Fizemos um fork interno do projeto e começamos a adicionar algumas das funcionalidades que faltavam. Já estamos usando ele há mais ou menos 1 ano e tem sido bom o suficiente para nossa rotina. Ainda há alguns bugs e funcionalidades faltando que pretendemos incluir.

Se você se interessar, estou disponibilizando esse fork publicamente para cumprir a licença Affero GPL.

Qualquer contribuição é bem-vinda.

Sobre Gestão Ágil Adequada

Desviando um pouco do assunto, quero explicar por que esse tipo de ferramenta (no estilo Tracker) é a melhor opção quando comparada ao que chamei de “listas de tarefas glorificadas”.

Os princípios são muito simples:

• Todo projeto precisa começar com o backlog mais completo possível (a incerteza está no seu pico no começo, e vão faltar detalhes, mas é importante ter uma visão do que significa “minimamente completo” e a ordem de importância de cada story, uma “prioridade” adequada).
  • O nível de detalhe em si não importa. Uma story precisa ter informação suficiente para que qualquer desenvolvedor do time consiga implementar as tarefas necessárias. Caso contrário, ela deve ser marcada como “bloqueada”, para que o Product Owner saiba que precisa adicionar mais detalhes, e nenhum desenvolvedor encosta nela até que a tag seja removida.
• Todas as stories precisam ser estimadas (falo mais sobre isso na próxima seção). A unidade realmente não importa. Você pode pensar em horas, em frações de um dia ou no que ela realmente é: uma proporção. Uma story de tamanho “2” deveria ter aproximadamente metade da complexidade de uma story de tamanho “4”. É só isso. Até stories “bloqueadas” devem receber tamanho.
• Projetos precisam ser divididos em Sprints com tempo fixo e duração fixa, para que o time tenha a oportunidade de reavaliar frequentemente. É aqui que a estimativa pode ser refinada, onde mais níveis de detalhe nas stories devem ser exigidos.
• Bugs não podem ter estimativa numérica. Eles servem justamente para puxar a velocity do time para baixo, e são um indicativo de entregas mal feitas.
• Velocity é a quantidade real de story points entregues até o fim de uma Sprint.
  • O total de story points de todas as stories do backlog do projeto dividido pela velocity do time dá uma “Data de Término” estimada por alto. Isso é importante, porque é assim que você sabe quando determinados grupos de funcionalidades serão entregues ao longo do tempo, e é isso que o Product Owner precisa saber para priorizar stories, simplificar stories ou até cortar funcionalidades desnecessárias.
  • A única responsabilidade do Product Owner é prestar contas pelo Retorno sobre o Investimento das funcionalidades implementadas. E a única forma de medir custo-benefício é saber “quanto” uma funcionalidade vai “custar” em termos de story points divididos pela velocity.

O que a ferramenta vai expor:

• Se um backlog tem muitas stories “bloqueadas” ou muitas stories entregues sem aceitação, isso é sintoma de um Product Owner que não está fazendo o trabalho dele.
• Se a velocity varia demais entre sprints, isso é sintoma ou de stories mal escritas (e portanto desenvolvedores com dificuldade de entender o que fazer), ou de desenvolvedores sem concentração no trabalho e entregando resultados inconsistentes.
• Velocities inconsistentes com muitos bugs a cada sprint são sintoma de desenvolvedores que não estão fazendo código com qualidade adequada (testes automatizados para evitar regressões, por exemplo).
• Um “bug” não é a mesma coisa que o Product Owner mudar de ideia sobre uma story e rejeitá-la. O time não deve implementar mudanças não documentadas. A aceitação está amarrada ao que a story diz. O Product Owner precisa mudar de ideia antes da story ser implementada ou criar uma nova story para adicionar a mudança (e, portanto, adicionar mais custo ao projeto; não existe almoço grátis).
• Stories no “Chilly Bin” (no Fulcrum, ou “Ice Box” no Tracker) são “lista de desejos” e nunca serão implementadas até o Product Owner movê-las para o backlog.
• A velocity deveria ser aproximadamente a mesma entre sprints. Picos ou vales na velocity são sintoma de um problema que precisa ser atacado na próxima sprint. É assim que um projeto evolui para melhor ao longo do tempo.

Sobre Estimativa

Muita gente se preocupa demais com “estimativa correta” a ponto de criar tanta tensão que os desenvolvedores começam a gritar por “no estimates”. Isso é loucura. Por isso “estimativa” é uma palavra diferente de “previsão”: uma é incerta, um chute de grosso calibre, a outra é exata.

Não existe estimativa “correta”.

Eu diria que em muitos projetos, se as stories estiverem minimamente descritas (ou seja, um desenvolvedor consegue implementar o que está escrito), poderíamos estimar todas como tamanho “1” e esquecer disso.

Rodamos 2 ou 3 sprints (normalmente uma sprint deveria ser uma semana de trabalho - 5 dias de no máximo 8 horas, nem mais, nem menos) e medimos quantas stories foram entregues. E essa é a velocity.

Agora podemos ver quantas stories temos até o fim do projeto e dividir por essa velocity. E esse é o número de semanas que vamos levar para terminar o projeto.

Não há necessidade de estimativa por consenso.

Consenso em estimativas normalmente é desperdício de tempo. Estimativa é apenas a constatação de que é difícil escrever cada story no exatamente mesmo tamanho, e por isso adicionamos proporções a elas (uma story tamanho 2 é metade do tamanho de uma story tamanho 4).

Mas se um projeto tem 3 meses ou mais, menos as proporções importam (a menos que você caia na anti-prática de ter stories muito desproporcionais, algumas tamanho 1 e muitas tamanho 5, 8 ou até 10, por exemplo). Mas se você ficar abaixo de tamanho 5 para toda story, então quanto maior o projeto, menos as estimativas individuais importam. A velocity vai diluir as diferenças ao longo do tempo.

A tarefa do Project Manager, do Product Owner, do time em geral, é ficar de olho no total de pontos dividido por essa velocity, de onde sai a data estimada de término do projeto. E todos podem negociar, com antecedência, quais stories podem ser feitas, quais não podem, mudar prioridades, remover stories ou simplificar stories.

Não perca tempo tentando criar fórmulas para derivar consenso de estimativa.

Se você administra a Velocity, então você administra o projeto inteiro. Esse é o cerne de toda metodologia Ágil adequada. Todo o resto é acessório a essa finalidade.

Tentar aumentar a velocity artificialmente é um dos vários pecados. Você não consegue. É melhor investir tempo adicionando mais detalhes a uma story, ou simplificando uma story, ou decidindo que algumas stories simplesmente não são necessárias para entregar um produto decente no final.

Simulações de Monte Carlo, técnicas Six Sigma, conceitos de Kanban, nada disso importa. Todas as técnicas da indústria tradicional foram pensadas para linhas de produção de fábricas, onde o tempo de cada tarefa é bem definido e você administra a variância, a exceção. É um mundo Gaussiano, Normal.

Em projetos de software, ou qualquer trabalho artesanal e de pesquisa, você administra expectativas sobre resultados com base em marcos e cortando excessos e incertezas. É um mundo Pareto, onde não existe “média”, não existe meio, não existe variância.

Em um mundo Pareto, tudo está interconectado, e nada é estatisticamente independente (um requisito para Gaussianas). É portanto 80/20: onde 20% do projeto rende 80% dos resultados, onde 20% do escopo pode ser cortado.

Qualquer coisa que não seja “estatisticamente independente” (como jogar uma moeda) não pode ser tirada a média, não cabe em uma distribuição Normal. Provavelmente é uma Pareto, Power Law, Zipf, Exponencial, ou até uma Poisson, mas não uma Gaussiana. As partes de um software estão todas entrelaçadas em uma rede, elas não são eventos independentes, não podem ser reorganizadas aleatoriamente, elas não são facilmente intercambiáveis.

Conclusão

Este artigo é bem curto e eu posso expandir cada item acima em seu próprio artigo, bem longo. Me diz nos comentários se eu devo, e quais pontos levantam mais dúvidas.

Venho refinando essas técnicas ao longo dos últimos 10 anos, e pelo menos 5 deles dentro das restrições de uma ferramenta como o Tracker. E acredito que consegui chegar ao conjunto mínimo de princípios que levam a uma gestão adequada, longe de superstição, fantasia ou ilusão que você vê por aí hoje em dia.

Projetos sofrem quando as recomendações acima não são seguidas:

• Product Owners não cumprem suas responsabilidades: falham em adicionar detalhes às stories, negligenciam funcionalidades entregues e não as testam direito, não participam.
• Backlogs estão incompletos, com falta de detalhe, falta de estimativa, falta de priorização.
• Desenvolvedores não começam nem terminam suas tarefas direito, com qualidade de código adequada.
• Tempo é desperdiçado em bikeshedding em vez de entrega.

Nosso fork do Fulcrum, chamado “Central”, está longe de ser perfeito, mas funciona bem o suficiente e nos dá controle para continuar adicionando funcionalidades que tornam nossa rotina mais confortável, e estamos apenas começando.

Espero que essa técnica e essa ferramenta sejam úteis para mais times, e adoraria ouvir o feedback de quem se interessar.

Comece simples com o artigo que empresta título a esta coletânea, Processos e Metodologias não vão te Ajudar, que publiquei nos blogs da Abril em 2011. É o ponto de partida para entender o que são processos, metodologias e procedimentos.

Em seguida, vá direto ao mais recente Agile: a Verdade por trás do Método e entenda de uma vez: nenhuma metodologia ou receita mágica vai salvar membros incompetentes ou de mau caráter em nenhuma equipe. Depois de tentar melhorar postura e treinamento sem sucesso, você só livra o time desses elementos de uma forma: trocando os membros. Nada salva um Net Negative Producing Programmer.

Muitos ficam com aquela sensação de “desperdício”, tipo “puxa, mas já investimos tanto nele, e se investirmos mais um pouco?”. Isso vem da falta de compreender que Custo Perdido é melhor do que aumentar seu Custo de Oportunidade.

No mesmo tema “Agile is Dead”, ou, mais explicitamente, “Agile-by-bikeshedding-consultants is Dead”, vale relembrar o antigo tema de O problema das credenciais e A Argumentação através da Intimidação. O cara da credencial tem o trabalho mais fácil do mundo: chega na sua empresa para implementar “práticas” que ele não pratica de verdade. E tentar implementar em uma ou meia dúzia de lugares é ridiculamente a mesma coisa que nada.

Quando “parece” que dá certo, ele coloca o caso na lista do portfolio como “sucesso”. Quando dá errado, diz “você não fez direito”. Péssimo.

Esqueçam nomes pomposos e diferentes escolas de metodologias. Tudo parte exatamente do mesmo princípio: Método Científico vs Cargo Cult, onde é claro que ninguém compreende o principal do método: ele não escolhe lados, nem torce por nenhum time.

Não existe a frase “está provado que funciona porque já vi funcionando em 100 lugares”.

Qualquer um que use uma frase similar a esta é claramente um amador. Pelo princípio da “Falseabilidade” de Karl Popper, em vez de tentar provar que algo funciona, o melhor é tentar desprovar que ela funciona. Porque não importa quantas toneladas de evidências conseguimos acumular de que algo é verdadeiro, basta uma única evidência que a torne falsa pra destruir qualquer hipótese. É por isso que o corpo científico é robusto, não porque temos montanhas de evidências a seu favor, mas porque o que temos acumulado até hoje ainda não foi provado falso.

Porém, seres humanos são falíveis. Nosso cérebro não-racional, resquício de nossa longa evolução, ainda é excepcional em enxergar padrões onde eles não existem, como descrevo em Somos Matematicamente Ignorantes e Processos, Metodologias e o Cérebro Humano.

A hipótese mais aceita é que temos a tendência de confundir correlação com causalidade. Porque “A” veio antes de “B”, tendemos a achar que “A” causou “B”, e isso, na maioria das vezes, não é verdade. O mundo é mais aleatório do que gostaríamos de aceitar. Shit just happens.

Isso leva aos pseudo-intelectuais, que querem empurrar sua “Dieta Southbeach” da vez e se tornam meros trolls ou haters, como descrevo em Matemática, Trolls, Haters e Discussões de Internet. Eles criam mais e mais dietas, como falo em #noEstimates Debunked, Desmistificando o método Kanban e Cuidado com o Kanban-butt.

E tudo isso que linkei acima é apenas a introdução da coisa mais importante de todas: seja cético o tempo todo, nada é automaticamente verdade, não importa quem esteja dizendo. E como Carl Sagan diria: “afirmações extraordinárias EXIGEM evidências extraordinárias”. No fim, sempre voltamos ao tema dos Inimigos da Razão.

O problema é: se nada disso funciona, o que fazer? É bem mais fácil dizer o que está errado do que dizer o que fazer. O problema nunca foi a receita. Tudo se resume às decisões que você toma.

Cada decisão traz consequências, que levam a novos dilemas, que exigem mais decisões. Como Neo diria em Matrix Reloaded: “O problema são as escolhas”. Simplesmente não existe receita, dieta ou metodologia mágica que faça você tomar decisões melhores o tempo todo.

Existe uma vontade de buscar uma ferramenta externa, uma fonte externa de “validação”, que é uma das piores palavras inventadas nos últimos tempos. O detalhe é que decisões carregam consequências, e a maioria das pessoas simplesmente gostaria de não ter que assumi-las. Essa é a raiz do problema. É a zona de conforto: todos reclamam e querem coisas, mas ninguém quer tomar decisões e, muito menos, encarar suas consequências.

A única forma de tomar decisões melhores é estudar e treinar, o máximo possível, o tempo todo, continuamente. Experiência não é fazer a mesma coisa 10 anos seguidos, e sim se tornar muito bom em 10 coisas diferentes ao longo desses 10 anos. Seguir a moda não vai te ajudar, assim como seguir dietas mágicas. Elas te deixam um pouco mais magro no começo, e logo vem o rebote que te deixa mais gordo do que você era antes. É por isso que Processos e Metodologias não vão te ajudar.

O problema é usar a frase como desculpa. Ela vira “não precisamos de processos, basta deixar as pessoas escolherem”, ou então “as pessoas escolhem, então vamos ter consenso pra tudo”, a falácia da organização democrática. No fundo, é justificativa para não entender o valor de ter processos.

Agile, derivado do Lean, é inteiramente baseado em processos. E o pilar do Lean original (não das derivações como Lean Startup ou Kanban) é o “Kaizen”, ou seja, a “melhoria contínua”.

A ideia é que o hoje seja pelo menos um pouco melhor do que o ontem. O que fazemos é mensurável, e por isso dá para afirmar que hoje ficou melhor do que ontem. O princípio é simples; a execução, nem tanto. Se ainda não leu, siga os links deste parágrafo para entender esses conceitos.

Agora vem a parte ruim: como falar sobre pessoas? Ou, mais especificamente, sobre o comportamento das pessoas?

Como todos nós somos “pessoas”, temos a certeza de que sabemos como as pessoas pensam. E nada poderia estar mais distante da verdade. Carregamos ideias pré-concebidas, falaciosas, supersticiosas e preconceituosas, muitas ultrapassadas há tempos. De tanto serem repetidas como clichê, ainda acreditamos nelas, do mesmo jeito que muita gente acredita que só usamos 10% do cérebro ou que não dá para tomar manga com leite.

E não precisamos adivinhar. Assim como no caso dos processos, existe uma longa literatura sobre pessoas: psicologia, sociologia (que evoluiu muito a partir dos anos 90 graças ao estudo de redes), economia comportamental, entre outras. É impossível para quem vem da tecnologia virar especialista em Humanas, mas se a responsabilidade é priorizar pessoas, além dos processos, é melhor se equipar o suficiente.

Este é um Small Bite porque não pretendo, desta vez, entrar em detalhes sobre o assunto. Prefiro deixar alguns livros de que gosto muito para dar uma base.

Dentro da própria área de tecnologia existem alguns clássicos que valem a leitura:

• Peopleware do Tom DeMarco
• The Mythical Man Month do Fred Brooks
• The Psychology of Computer Programming do Gerald Weinberg

Daí podemos ir para Economia Comportamental e Psicologia:

• Thinking, Fast and Slow do prêmio Nobel Daniel Kahneman
• Predictably Irrational do Dan Ariely
• The Upside of Irrationality: The Unexpected Benefits of Defying Logic do Dan Ariely
• The (Honest) Truth about Dishonesty do Dan Ariely
• The Lucifer Effect do Philip Zimbardo
• Talent Is Overrated do Geoffrey Colvin
• Descartes’ Error: Emotion, Reason, and the Human Brain do Antonio Damasio
• The Black Swan do Nassim Taleb
• Fooled by Randomness do Nassim Taleb

E, mais especificamente, sobre o comportamento de diversos agentes em grupos (teoria de redes):

• Linked, the New Science of Networks do Albert-László Barabási
• Six Degrees: The Science of a Connected Age do Duncan Watts
• Everything Is Obvious: How Common Sense Fails Us do Duncan Watts
• Sync: How Order Emerges From Chaos In the Universe, Nature, and Daily Life do Steven H. Strogatz
• Chaos: Making a New Science do James Gleick
• Nonlinear Dynamics and Chaos do Steven H. Strogatz
• The (Mis)behavior of Markets do Benoit Mandelbrot

Sim, muitos desses livros são bem superficiais (nenhum é técnico ou de especialista), mas a intenção é só dar uma introdução às diversas áreas. Com o tempo, eliminei alguns superficiais demais, já na categoria de entretenimento e auto-ajuda, como Malcolm Gladwell, Dan Pink, Clayton Christensen e Clay Shirky. Ainda assim, vale a pena ler alguns deles.

O principal é a conclusão: ao contrário do que costumamos pensar, nós, pessoas, não somos tão racionais quanto gostaríamos, e nosso comportamento é fortemente influenciado por agentes externos e pelo ambiente.

Alguns artigos que podem dar base ao resto da discussão:

• de Dave Thomas Agile Is Dead (Long Live Agility)
• de Richard Bishop Agile Is Dead: The Angry Developer Version
• de Giles Bowkett: Why Scrum Should Basically Just Die In A Fire

Na minha empresa, desde a concepção, não usamos a palavra “Ágil”, “Scrum” nem qualquer outro buzzword. Temos “sprints”, sim, mas coisas como grooming e planning poker (brincadeira!) não são de jeito nenhum “impostas”. As práticas são usadas, com ou sem os nomes, sempre que necessárias. Não gosto de usar “Scrum”, “Kanban” ou qualquer outro rótulo, me dá uma leve vergonha mencionar esses nomes.

Para quem de fato aplica as práticas de agilidade no dia a dia, isso não é nenhuma novidade. Não há dúvidas sobre coisas como Collective Code Ownership (Github!), Continuous Integration (Jenkins, Travis, Semaphore, etc), Test Driven Development (Rspec, Jasmine, Capybara, etc), Refactoring, YAGNI, User Stories/Requirements/Use Cases (ou tanto faz a nomenclatura: basicamente, escopo). Veja os processos de projetos open source: em termos de práticas de programação, não é muito mais do que isso.

O problema é o processo: o gerenciamento de projeto em si. Fala-se muito em Waterfall vs Agile, mas isso é um grande bullshit. O que se lamenta é como o mundo das consultorias “especializadas” em “processos Ágeis” prostituiu a Agilidade.

E é verdade. É por isso que eu não “vendo” coisas como “implementação de metodologias”, e na verdade não recomendo que ninguém contrate um terceiro para isso. Se precisar muito, avalie quanto de hands-on direto no código e no dia a dia o candidato realmente tem. A maioria acumula mais horas “verbais” do que de ação.

Neste artigo não vou dar a solução, isso fica para um próximo. Aqui quero apenas dizer a única grande verdade que ninguém avisa, e por isso qualquer tentativa de implementação vai falhar: a implementação de quaisquer práticas, processos e métodos Ágeis exige uma boa equipe, tanto programadores quanto gerentes e todo o resto.

“Boa equipe” significa uma equipe só de “sêniors”? Não. Exige gente comprometida com sua prática, sejam juniores ou sejam sêniores. Aliás, os que muitos hoje consideram “sêniores” ou “ninjas” (argh, seja porque palestram, seja pelos muitos anos de “experiência”) são quase todos bem pouco comprometidos e meramente arrogantes. De novo, mais verbo do que ação.

Este ponto é crucial: muita gente vai tentar implementar “Ágil” na esperança de transformar uma equipe ruim, ou uma empresa ruim, em algo melhor. Isso não vai acontecer. No começo vai parecer que “melhorou” ou, pelo menos, que alguma coisa “mudou”. Mas é óbvio: você está implementando algumas práticas meramente “diferentes”, claro que por algum tempo alguma coisa vai mudar.

Programação é uma profissão de prática. Não dá para transformar um programador ruim num bom só adicionando métodos, da mesma forma que fazer um jogador de futebol novato assistir a um treinamento de dois dias nunca vai transformá-lo num fazedor-de-gols. Somente a prática árdua, ininterrupta, consistente, feita de pequenas melhorias contínuas, talvez o leve a ser um goleador. No meu cinismo, eu disse diretamente a Bob Martin minha teoria sobre o que motivou Ken Schwaber a criar algo tão idiota quanto a Certificação de Scrum, na Railsconf 2010.

Quem programava nos anos 80 e 90 não viu nada tão disruptivo quando as descrições dos princípios e práticas chamados “Ágeis” apareceram no fim dos anos 90, até a publicação do manifesto em 2001. O que foi diferente é que finalmente alguém condensou tudo num pacote comercial marketável, principalmente o Scrum (que sozinho não inclui nenhuma das importantes práticas de programação do Extreme Programming). Quer ver como as práticas vêm evoluindo há muito mais tempo? Leia The Cathedral and the Bazaar e The Mythical Man Month.

Portanto não: implementar Scrum ou mesmo começar a implementar XP não vai salvar uma equipe ruim. Um ou outro, que já tinha pré-disposição, talento e vontade, vai conseguir se tornar ágil, depois de praticar, errar e praticar mais. Os outros, que não têm o talento nem a pré-disposição, ou pior ainda, são de fato mal-caráter, não vão mudar.

Nenhuma metodologia do mundo jamais vai mudar a personalidade de uma pessoa, pelo menos não em tão pouco tempo. Pense assim: a mãe dele não conseguiu fazer o cara deixar de ser preguiçoso e enrolador, você também não vai conseguir, e nem é essa a sua função. Sua função é entregar valor.

A verdade não dita do mundo Ágil é que a aplicação das práticas ágeis nasce naturalmente entre bons programadores já com experiência. Ela não será útil numa equipe novata, que ainda precisa praticar muito, com ou sem princípios ágeis.

Eu disse que basta ver como funciona o mundo open source. Ao contrário do que muitos brasileiros novatos imaginam, open source não tem nada, a princípio, a ver com inclusão ou movimentos esquerdistas. Eu resumiria open source como “a forma capitalista mais eficiente de se manter commodities”. Ele é altamente exclusivo para desenvolvedores.

Sem nenhum vínculo empregatício, de forma puramente voluntária, os interesses giram em torno de marketing: exposição da empresa, exposição do desenvolvedor, redução de custos, oportunidades. Você realmente precisa ser “bom” para se manter no topo da lista. A opinião de todo mundo tem o mesmo peso? Pergunte a Linus Torvalds o que ele faz quando uma ideia ruim aparece.

O mundo open source expõe problemas imediatamente. Só porque você acha o seu projeto “legal” isso não se traduz automaticamente em voluntários e exposição. A taxa de projetos que morrem é ordens de grandeza maior do que a de projetos que ganham tração. Comparado ao mundo comercial, o open source mata projetos muito mais rápido.

Ágil foi feito para expor os problemas o quanto antes. Entenda: as práticas Ágeis são mecanismos de exposição de problemas! Ágil é um mecanismo de redução e gerenciamento de Risco! Encontrar os obstáculos no momento em que acontecem e tratá-los imediatamente para mitigar riscos futuros desnecessários, que só levam a desperdício.

Só que ninguém quer fazer isso. Se o problema for o gerente, que consultoria vai conseguir removê-lo do cargo, a menos que o dono acima dele esteja comprometido em cortar na própria carne? Se o problema é o programador mal-caráter que todo mundo gosta (o tipo mais perigoso: o que sabe se articular e criar zonas de influência entre pares e superiores), como mandar esse cara embora?

Sim: consertar uma equipe em pouco tempo significa necessariamente substituir seus membros. No pior dos casos, trocar todos eles. Se o método for bem aplicado, ele imediatamente demonstra e expõe os problemas. E como na grande maioria dos casos o problema está no comportamento, e não na prática, é preciso resolver na hora. Se você, stakeholder e responsável pela sua empresa, não está mandando ninguém embora depois de começar a implementar Ágil, está fazendo errado.

E aqui está o grande problema: ninguém entende esse compromisso. Não há almoço de graça. Não há como fazer omeletes sem quebrar alguns (ou todos) os ovos. Sem esse entendimento e esse compromisso, não há agilidade. Aliás, não é a primeira vez que eu digo isso, se você leu meu artigo de 2009: Net Negative Producing Programmer. Mas como a maioria parece ainda não ter entendido, resolvi deixar mais claro.

Esta foi uma introdução. Dependendo dos comentários, talvez eu desça mais alguns degraus para explicar exatamente os mecanismos do que apresentei muito rapidamente aqui.

O ano era 2001. Um grupo de programadores sêniores se reuniu numa estação de esqui em Snowbird, Utah. Estavam ali os principais nomes da programação nos Estados Unidos: Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Ron Jeffries, Brian Marick, Bob Martin, Ken Schwaber, Jeff Sutherland, Andy Hunt, Dave Thomas, Mike Beedle, Arie van Bennekum, James Grenning, Jon Kern, Steve Mellor. Uma lista de “quem é quem” da área.

Desse encontro histórico surgiu um manifesto de 4 valores e 12 princípios, que ficou conhecido como o “Manifesto Ágil”.

Treze anos depois, Dave Thomas, autor de “The Pragmatic Programmer” e um dos que mais se envolveram na redação do texto do manifesto, publicou um artigo de desabafo chamado “Agile is Dead, Long Live Agility”.

A intenção dos agilistas originais era quebrar a forma antiquada de pensar e executar engenharia de software, o mesmo modelo obsoleto que ainda é ensinado hoje na maioria das universidades do país. Isso causou um enorme furor na indústria.

Vieram as derivações, os treinamentos, as ferramentas, as certificações, as conferências, as consultorias. Um portfólio imenso de opções, para qualquer tamanho e a qualquer preço. No meio de todo esse circo, esqueceu-se o que é de fato ser um agilista.

E, como Dave Thomas resumiu bem no seu desabafo, você não “faz” Ágil nem “compra” Ágil. Agilidade é uma qualidade, um adjetivo. Para ser ágil, é preciso voltar aos princípios. Citando:

• Descubra onde você está.
• Ande um pequeno passo em direção ao seu objetivo.
• Ajuste seu entendimento baseado no que aprendeu.
• Repita

Como fazer isso:

“Quando se deparar com duas ou mais alternativas que entregam mais ou menos o mesmo valor, escolha o caminho que facilite modificações futuras.”

E é só isso: quatro linhas e uma prática.

Treze anos depois que algo tão simples foi publicado pela primeira vez, o mundo parece ter ficado complicado demais. Scrum, Kanban, Scrumban, Lean Programming, Lean Six Sigma, Agile PMI. Num momento em que o caos reina, quem “parece” saber explicar o caos vira guru.

E aí surgem as associações, as certificações, os treinamentos, as conferências. Funciona assim para dietas, funciona assim para terapias, funcionou assim para engenharia de software. É isso que Dave Thomas lamenta.

Mas é um resultado inevitável. As pessoas são fáceis de enganar: procuram sempre alguém ou alguma coisa para seguir e raramente questionam. Foram dogmatizadas a nunca contestar a autoridade e a torcer para times de futebol sem nenhum critério.

Em 2010 estive numa conferência em Baltimore e tive a chance de conversar com Bob Martin, que organizou o encontro em Snowbird. Foi no escritório da Object Mentor dele que aconteceu o primeiro treinamento de certificação Scrum do Ken Schwaber.

Eu já era imune ao “Agile Hype”, mas queria dizer ao Bob Martin o que achava daquilo. Para quem não sabe, o treinamento “oficial” de Scrum Master é um curso de dois dias, e no fim você sai certificado. Nem precisa comparecer: basta pagar pelo curso.

Eu disse a ele, cinicamente, que a ideia do Ken provavelmente saiu pela culatra. “Provavelmente o Ken pensou ‘puxa, como convencer essas grandes corporações a adotar práticas ágeis?’ e aí ele pensou ‘claro, empresas grandes gostam de certificações’, e então criou um Cavalo de Tróia, um curso-piada de 2 dias onde pessoas sérias saberiam que não dá para aprender nada sério em 2 dias mas aí ele poderia inserir a ideia nas empresas. Porém todo mundo levou isso a sério, e é aí que o tiro saiu pela culatra.” Pule direto para o minuto 6:24 do vídeo abaixo se quiser ouvir essa história.

Aprendendo a Aprender

Agora vamos sair um pouco de software e entrar no mundo das “startups”. Esse mundo tem o seu próprio “Agile”, batizado de “Lean Startup”. Eric Ries cunhou o termo em 2008 e o popularizou com o livro de mesmo nome, de 2011, derivado direto dos princípios de Lean da Toyota. É uma reembalagem de ideias antigas.

Esse Lean vem das mesmas ideias de W. Edwards Deming sobre PDCA, “Plan, Do, Check, Act”, ou “Planejar, Fazer, Checar, Agir”. Você vai notar a semelhança com os quatro princípios de Dave Thomas que citei acima.

Não importam nomes pomposos, celebridades, gurus, ferramentas caras nem cargos de destaque. Os princípios básicos de Agile e Lean são os mesmos: entregar valor o mais rápido possível com o menor desperdício possível, aprendendo e usando esse aprendizado no processo, planejando e replanejando para atingir objetivos que ficam mais claros ao longo do caminho. É só isso.

O maior problema aparece quando um programador amador se pergunta “qual o próximo passo?” e a resposta é “o objetivo é montar um Kanban.” Ou quando um empreendedor amador se pergunta “qual o próximo passo?” e a resposta é “o objetivo é montar um Business Canvas.”

Kanban e Business Canvas não são objetivos, são meios. Se esses meios não ajudam a atingir os fins, entregar valor ao cliente e ter lucro no seu empreendimento, então são descartáveis. O objetivo é ter lucro. MVP, protótipo, Lean UX e Business Canvas são apenas caminhos possíveis para chegar lá. Quais deles servem?

Se você quer aprender qualquer coisa, os passos para começar são simples:

• Não crie ídolos, nunca “idolize” ninguém, pelo menos não a sério.
• Ignore quase tudo o que você vê ou ouve em grupos. Faça anotações, mas não leve tudo a sério.
• Ignore conselhos e mentorias. É como um gerente de banco dando dica de investimento: se ele fosse bom de verdade, estaria rico em vez de vender conselho. É vendedor com outro nome.
• Tudo, absolutamente tudo, começa com poucos princípios. Ninguém vira cirurgião cardíaco querendo cortar a aorta antes de aprender a lavar as mãos. Procure os princípios e ignore os títulos pomposos.
• Assuma que sabe pouco, sempre. Encare cada assunto com os olhos de um ignorante. Quem acha que já sabe tudo não aprende mais nada. Mas seja um ignorante esperto, não um ignorante idiota.

Aprenda a questionar. Todo o mundo das Ciências, do mundo quântico absolutamente pequeno até o mundo cosmológico infinito e imenso, só existe porque aceita um único princípio: o Método Científico.

Ele é basicamente o PDCA: defina o problema, faça hipóteses, faça experimentos controlados, descarte as hipóteses provadas erradas, repita. Sendo mais exato, o PDCA de Deming é que se inspira diretamente no Método Científico.

Aí está o princípio de tudo. De Agile a Lean a PDCA, voltamos a Karl Popper e à sua filosofia do “Racionalismo Crítico”, que ensina que tudo deve estar aberto à crítica racional.

É por isso que o Lean, enquanto guarda-chuva para vender produtos e serviços de que você não precisa, está morto. Longa vida ao princípio de alcançar valor evitando desperdício com aprendizado contínuo, ou seja, Eficiência. Não existem fórmulas mágicas. Se as dietas mágicas funcionassem, não existiria obesidade no mundo.

PS: Eu sei, tem #tongueincheek no título e no artigo, mas a intenção, pra variar, é dar uma provocada mesmo ;-)

Vale a distinção. Um profissional júnior, que ainda tem deficiências técnicas e vontade de crescer, aprende técnicas, práticas e ferramentas, e ganha qualidade técnica, produtividade e eficiência. Um mau profissional, que até pode ter alguma capacidade técnica, está mais interessado em pouco trabalho, pouco esforço e pouca responsabilidade, e chega a ser mal caráter na conduta e na atitude. Esse não muda.

Agile é mais uma fórmula cuja imagem (resultado) é a promessa de hiper-produtividade que pode chegar a 500% do atual. Novamente, qual o Domínio (as premissas)?

A premissa mais básica para Agile é que a equipe tenha capacidade técnica e comprometimento. Isso nenhuma metodologia ensina ou muda. Cada indivíduo da equipe é uma pessoa capaz ou simplesmente não vai funcionar. Código bem feito, bem organizado, seguindo as boas práticas conhecidas, com testes e disciplina, é o mínimo para começar, o arroz com feijão.

Se isso não existir, desista. Nenhuma metodologia, nem macumba, nem exorcismo, nem feng shui vão ajudar. Colocar Scrum, práticas de XP, Kanban ou qualquer outra coisa numa equipe ruim, com liderança fraca, produz algumas das seguintes prostituições das boas práticas:

Planning para Inglês ver

Um bom planning só é possível se o Product Owner se dedicar a manter um backlog priorizado e bem definido. E entenda: a definição das User Stories deve estar pronta antes do Sprint Planning. Uma User Story vaga, mal definida, não ajuda em nada.

Enquanto a equipe trabalha no Sprint, o PO define as próximas User Stories, e pode chamar um ou mais membros da própria equipe ou de equipes paralelas para ajudar. No Sprint Planning tudo já deve estar bem definido, de preferência pré-pontuado e priorizado. A equipe apenas pontua o Sprint e, de acordo com a Velocidade atual, vê o que cabe no próximo. Uma reunião bem feita dura 1 ou 2 horas no máximo.

Sintomas: se demorar mais que 2 horas, tiver pessoas demais só para fazer quórum, User Stories mal definidas que geram discussões intermináveis e nenhuma ação, você está fazendo errado.

Pair Programming para Inglês ver

Pair Programming é uma prática muito boa, e a equipe decide como praticá-la. Só que você pode encontrar um membro que quase nunca programa bem sozinho e, ao fazer o “pair”, vira mais ouvinte do que participante. É o famoso “peso morto”. Fica só dando pitaco, ou fica em silêncio jogando Candy Crush e navegando no Facebook. Não tem valor algum.

Sintomas: isso é mais fácil de acontecer em equipes muito grandes (acima de 6), pois fica mais fácil se “esconder” fazendo pair-fake com diferentes pessoas. Aliás, eu nunca recomendo mais do que 4 pessoas numa equipe ágil. Mesmo sendo um único produto, se tiver 15 pessoas, por exemplo, melhor dividir em 3 equipes de 5. Melhor ainda se as pessoas rotacionarem nessas equipes para que não se criem “panelas” onde um ruim protege o outro ruim.

Protecionismo Departamental

Programadores profissionais hoje precisam ser multi-funcionais, polivalentes. Obviamente cada um tem um tipo de capacidade melhor do que a outra. Por exemplo, o que chamaríamos de um “front-end” deve ser o mestre do HTML 5, CSS 3, Javascript, mas também deve saber o mínimo de Rails, Node.js, Python ou o que for o back-end para conseguir organizar os templates e integrar com controllers, models, helpers, etc. E os “back-ends” também devem minimamente saber HTML, e mesmo infraestrutura.

Pontuação de User Stories (seja em Story Points, Working Hours, etc) deve ser sempre a mesma não importa quem puxe a User Story. Não existe isso de: “essas 3 stories são minhas, essas 2 são do Fulano, essas 4 são do Ciclano”. As stories são priorizadas e cada um vai puxando uma story de cada vez à medida que termina a anterior.

Sintomas: stories que são pontuadas diferente dependendo da pessoa que vai pegar, ou stories “reservadas”, ou tipos de stories que só um “tipo” de profissional pode pegar. Não existe isso de “esta story é de infra, só um cara de infra deve poder pegar, e o cara de back não deveria estar olhando pra ela”. Sprints são responsabilidade da equipe toda.

Uma das vantagens de pair programming e equipes pequenas é cada um aprender novas capacidades com os outros. Um back pode puxar uma Story que tem alguma coisa de front, mesmo sem ser o melhor de front, e nada impede de pedir pair com um bom front da equipe na hora que precisar. Uma User Story pode demorar 2 horas se for feita por um bom back, mas pode levar 5 horas se feita por um front.

O correto é o cara de front se aproximar das 2 horas, e não reservar a story. O correto é a velocidade da equipe aumentar gradativamente, e para isso a velocidade individual de cada membro também precisa aumentar. E para isso ele deve constantemente aprender novas capacidades. É assim que todos evoluem. Reservar stories é o melhor exemplo de batedor-de-ponto querendo ‘proteger’ seu emprego e esconder sua mediocridade.

Qualidade para Inglês ver

Todos os membros da equipe devem estar preocupados tanto com a qualidade técnica do código quanto com a qualidade funcional, ou seja, se a funcionalidade realmente se comporta da forma correta com os usuários finais. Muitas vezes existem equipes que alocam pessoas com o objetivo único de ser um “Q&A” (Quality Assurance), que se responsabiliza de montar casos de teste, automatizar testes de integração, alinhar com o PO e com analistas de negócios, marketing, etc.

Vou dizer que pessoalmente não gosto dessa distinção, mas confesso que em alguns casos faz muito sentido. Só que isso deve ser feito de forma que não se retire da equipe a responsabilidade de entregar funcionalidades que de fato funcionam. Não pode existir a sensação de “foda-se se tiver bugs, depois o Q&A pega”. Mas é isso que acontece muitas vezes.

Sintoma: procure User Stories que são entregues, depois rejeitadas, depois refeitas, depois rejeitadas de novo, e ficam assim por muito tempo. Uma User Story que fica 1 mês sem ser aceita é um absurdo monstruoso, uma abominação. Pior ainda se existirem membros da equipe que, quando você olha o backlog passado, estão sempre envolvidos em stories que sempre são rejeitadas e sempre demoram dias para serem aceitas. É o típico caso do profissional que mantém o emprego resolvendo problemas que ele mesmo criou. Remova essas maçãs podres da equipe o quanto antes, porque contaminam o pote todo muito rapidamente.

Desculpas, Desculpas, Desculpas

“Não deu pra fazer porque faltou teste, mas o cara que faz teste estava sobrecarregado então travei.”

“Não deu pra fazer porque tinha um obstáculo na outra equipe que não resolveram, então travei.”

“Não deu pra fazer porque estava mal especificado, mandei um e-mail pra tirar a dúvida, ninguém respondeu, então travei.”

Um bom profissional dá soluções, não aponta culpados nem fica procurando desculpas para justificar a própria incompetência. Significa que ninguém pode reclamar? Claro que não. Sempre existem problemas difíceis de resolver, e as pessoas podem e devem procurar ajuda quando necessário.

Sintomas: é fácil identificar o procrastinador profissional. O sujeito nunca está na mesa dele, passa mais tempo conversando no café do que trabalhando. Chega tarde todo dia, sai cedo todo dia. Quando está na mesa, você olha e o infeliz está no YouTube ou no Hacker News.

E que fique bem claro: nenhuma dessas atividades, isolada, é um problema. Até eu dou uma pausa e fico no Facebook. Só que quem age assim constantemente, rotineiramente, está de palhaçada. Pior: se no fim do dia a tarefa dele estivesse pronta, com código bem feito e sem bugs, eu não reclamaria. Normalmente não está. A tarefa fica incompleta, o código mal feito, sempre precisando ser refeito, e o sujeito aparece com desculpas parecidas com as de cima.

Isso é ser mal caráter, é atitude de criminoso. Ele está deliberadamente roubando a empresa: o salário está sendo pago e o valor não está sendo entregue. É um ladrão.

Um bom profissional, que trabalha sério, não espera ser cobrado para dizer “ah, eu perguntei, ninguém respondeu, então não fiz”. Quando encontra um obstáculo, corre atrás do problema. Dúvida técnica, pergunta aos colegas do lado (pessoalmente, e-mail, chat, gtalk). Problema funcional, procura o PO direto. Problema departamental, levanta da cadeira e vai até a outra equipe tirar a dúvida. Se a tarefa depende de um terceiro que não colaborou, vai direto ao chefe resolver.

O sintoma básico do mau profissional é o oposto: ele não vai atrás. Fica contente quando encontra o obstáculo, porque daqui a uma semana, só na próxima reunião de Review, vai dizer “puuuuuts, eu até tentei, mas o Fulano não colaborou, então não deu”. Tá de brincadeira.

Conclusão

Se sua equipe tiver apenas 1 dos problemas descritos acima, já é uma catástrofe. Se tiver mais de um, é um problema de intervenção militar, nível Iraque. Mais do que isso, só uma bomba nuclear para resolver. E pior ainda, alguém que apresenta todos os maus comportamentos descritos acima é um sociopata criminoso. Não adianta dar bronca, não adianta tentar consertar: não tem conserto… mas tem solução: trocar as maçãs podres o quanto antes.

E novamente, para ficar claro, é óbvio que existem todos os tipos de maus profissionais, e não estou falando somente de programadores. Existem maus gerentes, maus analistas, maus coordenadores, maus supervisores, maus diretores, etc. Isso vale para todo mundo.

Se você é um programador e está vendo tudo isso, corra atrás. Se o problema for na diretoria, sinto dizer que não há o que fazer. Agora, se você é um gerente, um supervisor, alguém em cargo de autoridade, e não está tomando nenhuma atitude sabendo de tudo isso: se demita, você está fazendo muito errado e sendo conivente com um ambiente cuja cultura é o mau-caratismo.

Aplicar ‘algumas’ práticas Ágeis, interpretadas da maneira errada, não é ser Ágil, é se enganar. É como uma dieta nutricional. Durante o dia você segue a dieta à risca, mas quando ninguém está olhando come chocolate e doces, e no dia seguinte fala “puts, não sei porque essa dieta não funciona, estou seguindo direitinho, acho que a dieta não presta, vamos tentar outra.” #lamentavel

Vamos deixar isso parelho: você adota #noEstimates se, e somente se, estiver disposto a adotar #noSalary. Seu empregador segura o seu pagamento até você entregar, e nesse cenário o valor precisa ser depreciado quanto mais tempo demorar. A CLT não permite isso, infelizmente. Mas seria um cenário interessante.

Tem muita gente falando sobre #noEstimates ultimamente. Já li boa parte dos argumentos a favor, e qualquer um pode fazer uma busca rápida no Google, então não vou ficar referenciando cada um. A essência é a seguinte: estimativas nunca vão ser boas o bastante, e quanto mais especificação e planejamento você faz, menos a qualidade delas parece melhorar. Num mercado dinâmico as especificações mudam o tempo todo, e quanto maior o esforço de estimativa, maior o desperdício. Se estimativa é tanto desperdício assim, por que não jogar tudo fora de uma vez?

Soa como uma ideia nobre, especialmente para desenvolvedores de software. Software é maleável, é abstrato, e parece simplesmente não caber nas noções tradicionais de gerenciamento de projeto. E já que estamos nessa, por que não jogar fora a ideia inteira de projetos também? Foi assim que surgiu outra moda, o #noProjects.

Minha intenção aqui não é responder a cada argumento, e esse nem é o ponto. O que vou fazer é explicar por que a ideia toda é absurda já na origem. Então vamos começar pelo básico.

Uma coisa que eu defendo desde pelo menos 2008 é olhar o gerenciamento de projetos e os mercados em geral pelos modelos de Sistemas Adaptativos Complexos, Teoria do Caos e Biologia Evolutiva. Fui muito influenciado pelas ideias de Nassim Nicholas Taleb e seu magnum opus “A Lógica do Cisne Negro”. A ideia é incrível: os mercados são movidos por agentes caóticos que influenciam um sistema complexo, longe de qualquer caminho linear.

Todas as empresas são gerenciadas para lidar com médias, com sigmas limitados como margem de erro operacional. Mas quando algo grande acontece, um “Cisne Negro” como a crise econômica de 2008, a maioria não está preparada. Nenhum modelo consegue prever, e o sistema inteiro trava e desaba.

Se você não conhece a ideia, dá uma googlada rápida e vai perceber que empresas, mercados e relações entre pessoas são sistemas dinâmicos que obedecem às regras da biologia evolutiva. Sistemas descentralizados parecem ser o caminho, e esses conceitos influenciam vários dos movimentos Lean que vemos hoje. Então, sim, eu estou bem ciente desses efeitos.

Resumindo, quem tem mais chance de sobreviver num sistema complexo desses são os mais adaptáveis, muito mais do que os que se prendem rigidamente a planos. Cumprir planos de longo prazo com rigidez é o jeito mais fácil de cair quando os Cisnes Negros aparecem.

Isso me levou a outro conceito: a Teoria da Relatividade Geral de Einstein. Na cosmologia moderna, ela substituiu a Teoria de Newton. Quando aprendi isso, meu primeiro pensamento foi: se Newton está “errado”, por que não usamos a Relatividade para calcular tudo no dia a dia?

A resposta é que Newton só está “errado” se você exigir dele calcular qualquer coisa. Ele não se aplica ao muito muito grande, ao cálculo gravitacional, a cálculos no nível de galáxias. Mas em tamanhos da Terra, calculando a trajetória de um avião ou de uma bala, ele continua valendo, porque as margens de erro são desprezíveis. No dia a dia dá para reduzir o problema a Newton e deixar a Relatividade Geral de lado. É uma simplificação grosseira, claro, mas me acompanhe.

O mesmo se aplica às empresas. Estamos todos sujeitos a distribuições de Lei de Potência, à Biologia Evolutiva e às forças implacáveis do Caos que fazem tudo se comportar como Sistemas Adaptativos Complexos. Mas num ambiente restrito eu vou argumentar que dá para reduzir o cálculo de volta para Curvas de Sino. Essa é a parte mais difícil de “provar”, então não vou tentar agora, mas a explicação a seguir talvez te leve até lá.

Vamos definir o que é uma empresa: um conjunto de operações. Operações são atividades repetitivas, como “pagar um fornecedor”, “enviar um pedido de compra”, “processar a folha de pagamento” ou “transportar produtos”. O conjunto dessas atividades define o que uma empresa é.

A ideia central de uma empresa é executar essas operações da forma mais eficiente possível. Você faz isso refinando o processo continuamente, em pequenos passos, ou através de um breakthrough que muda totalmente a forma de fazer uma operação específica.

Um exemplo: antigamente havia grupos inteiros de pessoas dedicadas a preencher formulários de papel e organizá-los para a informação fluir dentro da empresa. Com o surgimento dos sistemas digitais, dos ERPs, essa papelada toda deixou de ser necessária. Eliminamos uma profissão inteira de digitadores e agregamos eficiência e precisão ao sistema. Breakthroughs costumam ser a automação digital de trabalho manual, ou a eliminação completa de um processo.

Para alcançar esses breakthroughs existem os Projetos. Projetos são empreitadas temporárias, onde um grupo de pessoas se concentra para atingir um objetivo pré-estabelecido. Costumam ter data fixa de início e de entrega, orçamento fixo e quantidade fixa de pessoas envolvidas.

E aqui chegamos na parte da Estimativa. Todo projeto quer atingir algum objetivo, e no caso de um projeto de software escrevemos código para chegar lá. Para isso, criamos features e as quebramos em Casos de Uso, User Stories, Requisitos ou qualquer artefato que descreva o que precisa ser construído. Depois estimamos quanto recurso (tempo, dinheiro, pessoas) é necessário para implementar cada peça e integrá-las numa “solução” que resolve o problema.

A reclamação dos desenvolvedores é que não dá para estimar essas peças com precisão, e que projetos sempre vão sair atrasados e estourando o orçamento. Daí a ideia de não estimar nada, simplesmente começar a codar, entregar valor o mais rápido possível e considerar pronto só quando estiver pronto.

Alguns desenvolvedores ficam tão de saco cheio dessa noção que querem largar suas empresas para abrir suas próprias startups, onde vão poder fazer o que quiserem sem nenhum controle. Aí saem atrás de investidores, porque precisam de muito dinheiro e muito tempo. Claro que precisam. O que eles não percebem é que TODO MUNDO precisa de muito dinheiro e muito tempo.

E os investidores sabem disso: a ideia é irrelevante, execução é que é tudo. Quem merece mais dinheiro e mais tempo são exatamente os que conseguem se pressionar para entregar abaixo do orçamento e na frente de todo mundo. Fazer alguma coisa sem se preocupar com restrições é o reino do medíocre. E medíocre não merece nada.

Voltando ao básico: existe uma coisa chamada Economia justamente porque os recursos não são infinitos. Tudo que tem valor tem preço, seja um produto físico ou horas trabalhadas.

Entenda o seguinte: no negócio de serviços, onde nós desenvolvedores estamos todos, seja como empregado, seja como co-fundador, valor tem só duas variáveis, qualidade e eficiência. A gente costuma enxergar qualidade como a única coisa que importa. Pior: costuma enxergar aquilo que nós achamos que é qualidade como a única coisa que importa.

Isso nos traz de volta ao CONTEXTO. A maioria dos programadores é ruim de estimativa, e a raiz disso é que eles costumam ser absolutamente incompetentes em entender contexto. Como alguém com formação em Matemática, eu leio todos esses artigos sobre processos, metodologias e coisas como “#noEstimates” como se fossem “fórmulas”.

Fórmulas sozinhas não significam nada. Qualquer matemático sabe que você precisa definir um Domínio e uma Imagem, a origem e o destino de todas as entradas e saídas. Se eu mostro uma fórmula como “f(x) = 1 / x”, você pode dizer que ela é inválida, porque não dá para dividir quando x é zero. Mas se eu disser que o Domínio é todo número Natural exceto o zero, agora ela é uma fórmula totalmente válida para a Imagem dos Racionais.

Então, quando alguém fala “#noEstimates”, a pergunta natural é: em qual Domínio e para qual Imagem? Essa é a origem da confusão na maior parte das discussões na Internet. As pessoas argumentam a favor ou contra uma ideia porque cada uma está num Domínio diferente. Vale para Agile em geral, Lean Startups, Lean Manufacturing e por aí vai: costumam definir só práticas, procedimentos, fórmulas, mas raramente definem Domínio e Imagem. Isso gera confusão e perde o ponto.

O que eu vou definir é o seguinte: Projetos são necessários toda vez que existe um objetivo definido a ser atingido. Esse é o domínio. E vou afirmar também que quem fala “#noEstimates” está pensando no Domínio de “Operações Contínuas”, enquanto Projetos são um Domínio à parte. É justamente aí que o Lean Manufacturing em geral também se encaixa.

Já expliquei Operações acima, e é onde os pequenos passos de melhoria (Kaizen) emergem. Às vezes o feedback de uma operação dá insumo suficiente para justificar um Projeto e dar um passo maior, um breakthrough.

Projetos, por outro lado, continuam sendo empreitadas temporárias. A ideia toda é estabelecer fronteiras, como restrições de tempo e custo. E voltamos à pergunta original: é impossível prever os esforços necessários para algo tão maleável quanto desenvolvimento de software?

Antes de mais nada, sim, é impossível prever com precisão exata. Vamos definir de novo: é impossível prever um número com margem zero de erro. Estimativa é previsão com margem de erro. E por que alguns projetos custam mais que o dobro e demoram mais que o dobro do que foi estimado?

Na maior parte das vezes, em 90% dos casos, porque o time é incompetente. O problema não é a estimativa, é a execução. Estimativa é o estabelecimento de uma expectativa, e expectativas precisam ser gerenciadas. Uma estimativa só é boa se o contexto for levado em conta.

A maioria não gosta de estimar por causa dos cenários “e se”. E se o cliente mudar de ideia? E se a gente esbarrar num obstáculo difícil? E se um meteoro atingir a Terra e todas as criaturas vivas perecerem? “E se” não dá para gerenciar; o que dá para gerenciar é o que você sabe, criando restrições. As restrições de um projeto começam pelo objetivo. Para atingir esse objetivo, também estabelecemos as regras de engajamento, as premissas. Sem objetivos e sem premissas, não tem jogo.

Nada disso garante uma Previsão. Uma estimativa é tão boa quanto a execução. Agora a gente tem que gerenciar, e todo mundo tem que gerenciar.

De nada adianta definir regras claras e de repente ver um programador parado. Você pergunta por que ele está parado, e a resposta é “ah, porque eu mandei email pro cliente sobre uns requisitos e ele nunca respondeu, então fiquei esperando”. Você pergunta “e você tentou ligar pra ele?”, e a resposta costuma ser “Não, não tentei”. Não existe quantidade de processo ou metodologia que “conserte” um funcionário incompetente. Falta de habilidade técnica dá para consertar. Má-fé não.

Os defensores do #noEstimates podem argumentar que eles não são assim, e eu acredito. Mas 90% dos projetos que fracassaram tinham funcionários assim. Programadores tendem a colocar a culpa no cliente, nos chefes, no mercado, mas nunca em si mesmos. E como programador eu vou argumentar: a maioria dos projetos fracassa por causa de funcionários preguiçosos, muito mais do que por mudança de requisitos ou tempo limitado. Quer fazer projetos darem certo? Comece pelos Recursos Humanos, depois vá atrás de metodologia e práticas.

O problema das metodologias que não declaram o Domínio sob o qual suas fórmulas funcionam é que a maioria não percebe onde esse Domínio começa: em “ter funcionários competentes, comprometidos e habilidosos”. A maioria adota metodologias na esperança de transformar funcionários incompetentes em competentes, e isso simplesmente não acontece.

Resolvido isso, por que precisamos de estimativas? Ou, de forma mais geral, por que precisamos de restrições? Porque essa é a essência do valor de qualquer sistema. A natureza pressiona toda espécie viva: clima mudando, comida limitada, predadores. As espécies mais adaptáveis evoluem, e as que não conseguem se adaptar perecem.

Quando alguém fala “é impossível fazer X”, esse é provavelmente o objetivo mais valioso a perseguir. Porque a frase completa é “é impossível fazer X com o que sabemos hoje”. Era impossível dar a volta no globo em 24 horas, hoje não é mais. Era impossível se comunicar com o outro lado do mundo em tempo real, hoje não é mais.

Restrições são a base da inovação. Se eu tivesse que definir inovação, diria que “é o processo pelo qual você realiza algo que antes era considerado impossível”.

Se você tem recursos infinitos, ou simplesmente não precisa se preocupar com restrições, que é o que acontece nas bolhas, você não inova. Isso é tão importante que vou repetir:

Inovação é o subproduto das Restrições.

A gente estima com base no conhecimento passado. Se não conseguimos superar o nosso próprio passado, o quão incompetentes somos? Dá para argumentar que software não é previsível, e eu concordo. Mas errar por ordens de grandeza ao recriar software parecido, para mim, cheira incompetência.

A maior parte do software que produzimos é a mesma coisa de sempre: site de conteúdo, e-commerce, e-learning, rede social, social commerce, fórum, enquete. Raramente é ideia nova ou algoritmo de ruptura. A não ser que você trabalhe em programa de pesquisa, que tipo de software realmente diferente você fez ultimamente?

Estimativa raramente é o problema. Toda estimativa parte de um conjunto de premissas, e o problema é não gerenciar essas premissas. Se os requisitos mudam, tudo bem, isso a gente sempre consegue gerenciar. O que não dá para gerenciar é o problema acumulado no último dia do projeto, quando os programadores empurraram tudo com a barriga. De novo, isso é um problema de Recursos Humanos.

Meritocracia só existe num sistema de escassez, onde um se destaca em relação ao outro diante de uma restrição. Num sistema de pura abundância, não há necessidade de inovar nem de mérito. Empresas que acabaram de receber uma quantidade absurda de grana invariavelmente mostram sintomas de preguiça, muito mais do que de inovação.

A confusão acontece porque algumas das “práticas” defendidas vêm dessa situação temporária e irreal de bolha, e não aguentam a pressão do tempo. Dá tempo suficiente e você vai se perguntar: “como é que a gente, com tanto dinheiro e tanto tempo, conseguiu tão pouco, e aquela startupzinha, com recursos tão limitados, conseguiu nos superar?”. Essa é a resposta de por que um Yahoo! compra um Tumblr, por que um Facebook compra um Instagram, por que um Google compra um Waze.

Se você defende #noEstimation, por que não dar mais um passo e defender #noWork? É só um passo a mais.

Eu retornei no último fim de semana de uma viagem a Baltimore, Maryland, onde palestrei na RailsConf. Foi um evento com grandes palestras, algumas voltadas não só a Ruby on Rails, mas à carreira de programação em geral. Uma delas foi de ninguém menos que Robert Martin, da Object Mentor. Eu traduzi um artigo dele no meu post anterior.

Recomendo assistir à palestra na íntegra.

Desde que comecei este blog, tento explicar as condições e dificuldades que um Gestor de Projetos enfrenta. Mas venho tomando cuidado para não repetir o termo “Agile” a todo momento. Estamos no meio de uma febre de “agilidade”. Todo CIO, CTO, gerente ou consultor, para parecer moderno, diz que sabe “Scrum” e que é “ágil”.

Isso tem um lado bom: algumas empresas talvez enfim adotem essas ideias do jeito certo. Tem também um lado ruim, e grande. Estamos queimando o nome “Agile” por causa de consultorias ruins que implementam tudo errado no cliente. O resultado é a percepção, entre os desavisados, de que “Agile não funciona”.

Pois bem, durante a RailsConf, tive a oportunidade de conversar e entrevistar o Robert Martin, cuja gravação você pode assistir abaixo:

Dessa entrevista, o trecho que quero apresentar é a história de como surgiu o “Agile”. Robert Martin, também conhecido como “Uncle Bob”, é programador há décadas, certamente mais do que qualquer um de nós. Nos anos 90 ele foi um dos que notaram o surgimento de metodologias “leves” ou “lean”. Muito disso derivava dos conceitos de manufatura que revolucionaram a indústria japonesa a partir dos anos 60.

Vários nomes de peso começaram a propor formas mais inteligentes de desenvolver software. Kent Beck com o Extreme Programming (XP); Ken Schwaber e Jeff Sutherland com o Scrum; Alistair Cockburn com o Crystal.

Todos seguiam uma linha parecida: iterações curtas, feedback constante e muita comunicação. Vendo esse padrão, Uncle Bob procurou Martin Fowler, outro nome forte no mundo de arquitetura de software, e juntos passaram a organizar uma reunião, convocando um grupo desses profissionais.

A lendária reunião aconteceu na estação de esqui de Snowbird, em Utah, entre 11 e 13 de fevereiro de 2001. Dezessete profissionais passaram três dias ali e saíram com o “Manifesto Ágil”. Ele reúne 4 valores e 12 princípios que todos os participantes aceitaram como o mínimo denominador comum na prática de desenvolvimento de software. O manifesto diz:

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Como disse antes, existe uma febre crescente de adoção de metodologias ágeis. Pior que isso, existe a tendência de expropriar o termo “Ágil” e seus derivados, como “XP” e “Scrum”, criando verdadeiros frankensteins que misturam o jeito antigo com o novo. É o caso de tentar juntar RUP com Scrum, ou PMI com Scrum, e assim por diante.

São tentativas oportunistas que aproveitam a febre para ganhar dinheiro fácil. Algumas empresas, por exemplo, fazem questão de um “Certified Scrum Master” no currículo de um gerente, entre outras coisas igualmente irrelevantes.

E, para piorar, muitos tentam implementar metodologias ágeis “by the book”, ou seja, de forma dogmática. Todo dogma, por definição, é burro.

Voltando aos 4 valores: a prioridade é software que funciona e valor ao cliente. Implantar uma metodologia vem depois disso, quando vem. O primeiro valor é claro: valoriza muito mais Indivíduos e Interações do que Processos e Ferramentas. O que se vê hoje é o oposto, um esforço para empurrar processos, metodologias e ferramentas.

Agora é uma boa hora para começar a desmistificar o mundo Agile. Isto aqui é só uma introdução, mas vale o conselho que o Uncle Bob dá na entrevista: siga os originais. Se você está mesmo comprometido em melhorar as coisas e entregar projetos com qualidade e valor, largue essa nova geração de consultorias. Comece pelos primeiros livros de Ken Schwaber, Kent Beck, Alistair Cockburn e Mike Cohn.

Pergunte-se o tempo todo: estou de acordo com os 4 valores?

Se estiver dando mais ênfase ao processo do que às pessoas, você já começou errado. Muito errado.

O cérebro humano é uma máquina fantástica, e dizer isso é basicamente uma redundância do termo. Porém existem muitas anedotas e misticismo quando se fala sobre ele.

Todos já discutiram alguma vez a separação da “Emoção” do “Raciocínio”. Desde os tempos de Platão, as emoções são vistas como algo que atrapalha o pensamento lógico. Pior ainda: a maioria das pessoas acredita que, pelo menos nas decisões mais importantes, somos capazes de deixar as emoções de lado. A ideia é pensar de acordo com a economia clássica, baseados em fatos, evidências e custo-benefício.

Porém, na grande maioria das vezes não é assim que nos comportamos. Quando vamos a um supermercado, dificilmente ficamos fazendo aritmética, considerando os ingredientes de cada produto ou o valor nutricional. Normalmente olhamos para um produto e decidimos se compramos ou não com base no que sentimos.

No meio de dezenas de marcas para um mesmo tipo de produto, escolhemos com base em experiências passadas, em algum acontecimento marcante, nas lembranças, e tudo em frações de segundos. Preferimos levar um produto “80% light” a levar um “20% gorduroso”, apesar de ambas as frases dizerem a mesma coisa.

Antonio Damasio é um conhecido neurologista que estuda o cérebro e nosso comportamento. Ele acompanhou pacientes que literalmente perderam a capacidade de ter emoções por causa de danos cerebrais, seja por tumor, seja por problema genético. Poderíamos imaginar, como o filósofo Platão, que uma pessoa sem emoções tomaria as melhores decisões o tempo todo, já que não seria influenciada por elas.

Porém, sem as emoções essas pessoas não conseguem aprender. Qualquer decisão trivial vira uma análise de custo-benefício. Escolhas cotidianas como que roupa vestir, que canal de televisão assistir, tomar chá ou café, todas as coisas mundanas que decidimos quase instantaneamente, podem levar horas até esse tipo de paciente chegar a uma conclusão.

Um fato que já conhecemos: todas as emoções, tristeza, compaixão, alegria, depressão, prazer, são reações químicas no cérebro. E já sabemos como influenciar ou controlar muitas delas.

Usuários de drogas conhecem a sensação de prazer. Quem toma antidepressivos também. São todos químicos que atuam no cérebro e modificam nossas emoções. Esquizofrenia e Parkinson, por outro lado, são danos nesse sistema químico.

Outro fato é que nosso cérebro evoluiu para aprender. Aprendemos por tentativa e erro. Aprendemos observando e inferindo padrões. As emoções influenciam fortemente nossas decisões, e isso é bom.

Quando aprendemos algum padrão, dopamina é liberada no cérebro e cria uma sensação de prazer. Gostamos de descobrir o padrão das coisas e de tentar prever eventos futuros.

Pegue um experimento com macacos: tocamos um sino e depois damos uma banana. O macaco aprende o padrão “depois do sino vem a banana”. Dá para medir a dopamina sendo liberada já quando o sino toca, porque o macaco passa a prever esse acontecimento.

Se acendermos uma luz, tocarmos o sino e depois dermos a banana, o macaco aprende que o evento “luz” dá sequência ao sino e depois à banana. O padrão pode ser repetido com várias etapas, e o macaco aprende. Porém, se seguirmos o padrão e a banana não vier no final, o macaco fica triste, porque a previsão falhou.

Nós também funcionamos assim.

Para muitos eventos simples, com poucas variáveis, isso funciona bem. Talvez por isso muitos gostem de rotina, onde os resultados são bem definidos.

Nosso cérebro, no entanto, tem um defeito: na ânsia de encontrar padrões, ele tenta encaixá-los onde não existem. É assim que nascem as superstições. Antes de entendermos meteorologia, tribos primitivas achavam que “chover” estava ligado a uma dança que acabaram de fazer, e imaginavam que repetir a dança traria a chuva de novo.

Traduzi no meu outro blog um artigo da Scientific American demonstrando como somos “matematicamente ignorantes”. Tentamos achar um padrão para tudo. Um trecho que ilustra nossas superstições e explicações sobre coincidência é este:

Sempre é possível combinar dados aleatórios e encontrar alguma regularidade. Um exemplo muito bem conhecido é a comparação das coincidências nas vidas de Abraham Lincoln e John Kennedy, dois presidentes com 7 letras em seus últimos nomes, e eleitos com 100 anos de diferença, 1860 e 1960. Ambos foram assassinados numa sexta-feira na presença de suas esposas, Lincoln no teatro Ford e Kennedy num automóvel feito pela Ford. Ambos assassinos têm 3 nomes: John Wilkes Booth e Lee Harvey Oswald, com 15 letras em cada nome completo. Oswald atirou em Kennedy de um armazém e correu para um teatro, e Booth atirou em Lincoln em um teatro e correu para um tipo de armazém. Ambos os sucessores vice-presidentes eram Democratas sulistas e ex-senadores chamados Johnson (Andrew e Lyndon), com 13 letras em seus nomes e nascidos com 100 anos de diferença, 1808 e 1908.

Mas se compararmos outros atributos relevantes falhamos em encontrar coincidências. Lincoln e Kennedy nasceram e morreram em datas (dia e mês) e em estados diferentes, e nenhuma das datas é separada de 100 anos. Suas idades eram diferentes, assim como os nomes das esposas. Claro, se alguma dessas fosse correspondente estariam na lista de coincidências “misteriosas”. Para qualquer pessoa com vidas razoavelmente cheias de eventos é possível encontrar coincidências entre elas. Duas pessoas se encontrando numa festa normalmente encontram coincidências chocantes entre elas, mas o que são – aniversários, cidades natais, etc – não são previstos de antemão.

O mundo real é cheio de aleatoriedades, e não é difícil encontrar padrões nelas. Na verdade é muito fácil. Situações complexas têm muitos aspectos aleatórios, mais do que se imagina. E nosso cérebro ainda não evoluiu o suficiente para se sentir confortável num mundo totalmente aleatório.

Um exemplo são as pessoas de sucesso. Imagine um mega-investidor como Warren Buffett. Livros e mais livros são impressos, com análises, biografias e teorias, tentando explicar o processo que leva uma pessoa comum a ganhar bilhões na bolsa. Só por especulação: e se Warren Buffett for nada mais, nada menos, do que um acidente estatístico?

Nassim Taleb explica isso num artigo de Malcolm Gladwell:

Suponha que existem 10 mil gerentes de investimento por aí, o que não é um número tão irreal assim, e que a cada ano metade deles, totalmente por acaso, ganharam dinheiro e a outra metade perdeu dinheiro, também totalmente por acaso. E suponha que todo ano os que perderam dinheiro saem do mercado, e esse jogo é repetido todos os anos com os que sobraram. Ao final de 5 anos, ainda existiriam 313 pessoas que ganharam dinheiro seguidamente em todos os anos. E depois de 10 anos ainda existiriam 9 pessoas que ganharam dinheiro todos os anos, seguidamente, totalmente por acaso, por pura sorte da aleatoriedade. E quem pode dizer que Buffett não é um desses 9?

Nosso cérebro tem prazer em procurar padrões em tudo, especialmente em casos de sucesso. Queremos encontrar a receita, a fórmula mágica. Às vezes fica aquela sensação de “o que ele tem que eu não tenho?”

Às vezes duas pessoas são tecnicamente igualmente capazes, mas uma fica rica e a outra não. A diferença pode ser simplesmente aleatoriedade. “Mas isso não é justo!”, você reclama. O mundo não foi feito para ser justo. Justiça é um conceito humano, e a realidade não tem senso de moralidade: ela apenas “é”.

A ciência, felizmente, tem um procedimento para evitar essa armadilha do cérebro: o método científico. Tudo pode começar com um desses enganos, achando que encontrou um padrão e gerando uma teoria. Agora essa teoria precisa ser colocada à prova.

Para virar uma boa teoria, precisamos não só tentar comprová-la, mas principalmente tentar desprová-la. E mesmo que não achemos como desprovar a hipótese, nem por isso ela vira uma “Lei”. A ciência toma muito cuidado com as afirmações que faz.

Mesmo que uma teoria funcione bem mil vezes, basta um único fracasso para que seja rejeitada. É graças a essa forma de pensar que temos fundações sólidas e confiáveis na ciência, livres de superstição e misticismo.

Processos, Metodologias e Superstições

Dei toda essa explicação para chegar ao assunto principal deste blog: gerenciamento de projetos e de pessoas. Quem acompanha meus posts notou que em nenhum momento eu prego uma metodologia, um processo, uma receita de bolo. Coisas do tipo “como fazer estimativas corretas” ou “como prever o sucesso de um projeto”.

Se você é bem atualizado, sabe que existe todo um mercado de indivíduos e empresas que tentam justamente isso: vender processos e metodologias. Seja a Engenharia de Software tradicional, seja o PMI, sejam as chamadas “metodologias Ágeis”.

Antes preciso deixar um alerta: todas essas metodologias foram pensadas com a melhor das intenções. A ideia era compartilhar os fatores que levaram determinado projeto ao sucesso.

Minha explicação é mais ou menos assim: os líderes desses projetos, ou melhor, seus cérebros, começam incansavelmente a procurar padrões. Talvez seja o post-it na parede. Talvez o tipo de documento usado. Talvez a forma de as pessoas se sentarem à mesa.

Tudo isso forma um conjunto de “pseudo-verdades” que o cérebro entende como as “luzes” e os “sinos” que levam à “banana”. Esses líderes aplicam a receita em outros projetos e, como Nassim Taleb explicou, têm sucesso seguidamente.

Eureca! Parece que encontramos a fórmula para transformar ferro em ouro! Rapidamente essas pseudo-verdades são formatadas como metodologias, enlatadas, empacotadas e vendidas.

Porém pensem por um momento: e se todas essas metodologias forem exatamente como a dança da chuva? Como eu disse, é muito fácil encontrar padrões na aleatoriedade.

Quando começamos a discutir minúcias, com que nível de detalhe fazer uma estimativa, que métricas usar, quais os mecanismos de comunicação da equipe, não consigo deixar de pensar nas tribos primitivas discutindo “Quais penas devemos vestir? Que cores usar na cara? Devemos dar passos longos ou curtos na dança?”

Mas a questão principal não vem à tona: é a dança da chuva que efetivamente faz chover? Ou, no nosso caso, é a metodologia que de fato leva o projeto ao sucesso?

E o método científico? O problema é que um “projeto” é uma situação muito complexa. Mesmo os menores projetos são complexos, no sentido de que têm mais variáveis do que é possível medir.

Um dos jeitos de testar uma teoria é fazer um experimento duplo-cego, como os laboratórios de remédios fazem: um grupo recebe o medicamento de verdade e outro recebe um placebo, sem saber. Se ambos tiverem aproximadamente o mesmo resultado, o remédio não funciona.

Porém uma metodologia é mais complicada do que um remédio. Mesmo que a gente crie dois ambientes de trabalho isolados e idênticos, coloque dois grupos de pessoas “aproximadamente” semelhantes em cada um, comece no mesmo horário e com os mesmos requisitos, um lado com a metodologia “A” e o outro com a “B”, ainda assim não dá para comparar os resultados.

Isso porque metodologias envolvem as micro-decisões e as capacidades de cada pessoa, e “aproximadamente semelhante” é muito diferente de “igual”. É impossível duplicar o mesmo grupo de pessoas em cada ambiente.

Teríamos primeiro que clonar as pessoas com sucesso. Aí sim, com grupos exatamente idênticos, daria para fazer um experimento duplo-cego. Mas isso é impossível.

A conclusão é que provar uma metodologia desse tipo como “correta” é impossível, assim como é difícil desprová-la. Portanto, é inútil tentar afirmar que elas funcionam ou não. É claro que influenciam e, separadamente, cada técnica pode ser testada com mais cuidado. Mas não acho possível afirmar cientificamente que elas funcionam.

“Mas eu testei a metodologia X no meu projeto e funcionou!”

Excelente, bom para você. Porém, para cada projeto bem-sucedido com determinada metodologia, dá para encontrar um caso em que deu errado.

E os indivíduos e consultorias que vendem essas metodologias são espertos: se o projeto deu certo, foi graças à metodologia; se deu errado, foi porque as pessoas não seguiram a metodologia como deveriam. A culpa nunca é da metodologia. É uma ótima retórica para montar um argumento de vendas.

E como as pessoas não estão acostumadas a avaliar as coisas racionalmente, e como expliquei, na maioria das vezes nem raciocinam, sobram muitos consultores ganhando muito dinheiro sem precisar se comprometer com resultados.

Isso importa porque muita gente acredita que, com a ajuda da metodologia da moda, basta aplicá-la a uma equipe só de inexperientes para um bom resultado aparecer, como se o importante fosse o processo e não as pessoas. Acontece o contrário.

Na maioria das vezes essas metodologias não descrevem as qualificações exatas que cada membro precisa ter, porque é impossível listar todas. No máximo trazem descrições vagas de “papéis”, que geram mais discussão do que resposta. Um projeto com chance de dar certo começa com pelo menos algumas pessoas muito experientes, capazes de conduzir o resto da equipe.

Enfim, minha recomendação: estude as tais “metodologias”, porque, como eu disse, algumas técnicas ali têm valor. Mas entenda que nenhuma delas representa a verdade.

E não adianta somar duas meia-metodologias achando que isso as torna “mais completas”. Projetos são executados por pessoas, o comportamento humano é difícil de prever e o mundo real é cheio de variáveis imprevisíveis, formando um sistema complexo com muita aleatoriedade envolvida.

Comece aceitando que o mundo é aleatório e está fora do seu controle. Em situações complexas é melhor errar antes do que depois, porque os erros trazem informação que ajuda a refinar as decisões seguintes.

Aceite que prever o futuro num sistema complexo é impossível e adapte-se: algumas coisas vão sair como previsto e outras vão precisar mudar. Talvez uma funcionalidade não prevista precise ser feita, e o prazo tenha que esticar. Talvez uma funcionalidade prevista não fosse tão necessária e possa ser descartada. É assim que se lida com um ambiente complexo e imprevisível: adaptando.

A biologia explica: todos os seres vivos do planeta são resultado de uma sequência constante de tentativa e erro. A natureza não é “perfeita”, no sentido de que não há criador, não há design inteligente, não há grande plano, não há destino. Todo ser vivo veio de um rascunho biológico muito ruim que, pouco a pouco, via seleção natural, foi descartando o que não funcionava e favorecendo o que funcionava.

Nós humanos carregamos resquícios biológicos, como o apêndice. Somos um produto em constante evolução, e para muita coisa o estágio atual é “bom o suficiente”. Em termos de projeto, é nesse ponto que ele pode ser lançado: quando está “bom o suficiente”, ainda com arestas a arrumar, mas funcionando no geral.

Tentativa e erro. Adaptação. Evolução. É assim que se gerencia qualquer coisa.

Se quiser uma visão mais detalhada sobre esse assunto recomendo começar lendo os seguintes livros:

• How We Decide do Jonah Lehrer
• Descartes’ Error do Antonio Damasio
• Predictably Irrational do Dan Ariely
• Fooled by Randomness do Nassim Taleb
• The Lucifer Effect do Philip Zimbardo