Complexidade e Incerteza em Projetos

radio_button_uncheckedshort_textObjetivo do capítulo

Distinguir problemas claros/simples, complicados e complexos; compreender por que o desenvolvimento de produtos digitais contém incerteza persistente; reconhecer como requisitos, mercados, tecnologia e comportamento dos usuários invalidam premissas; e relacionar ciclos curtos de feedback ao empirismo, ao controle de riscos e à lógica iterativa e incremental utilizada pelo Scrum.

radio_button_uncheckedshort_textIntrodução: quando o plano do projeto encontra a realidade

Os riscos de projeto mais difíceis muitas vezes não são aqueles para os quais deixamos de planejar. São as premissas em torno das quais planejamos como se já fossem fatos.

Todo projeto começa com uma história sobre o futuro. Um cliente precisará de algo. Um mercado se comportará de determinada maneira. Uma arquitetura técnica suportará a carga esperada. Uma equipe concluirá o trabalho no ritmo estimado. Os usuários compreenderão um fluxo de trabalho. Um concorrente não mudará radicalmente o mercado no mês seguinte. Uma API externa continuará a se comportar conforme documentado. Uma regulamentação permanecerá estável por tempo suficiente para a entrega planejada. Raramente registramos todas essas premissas, mas elas estão incorporadas em cronogramas, orçamentos, requisitos, roadmaps e decisões de arquitetura.

A gestão tradicional de projetos frequentemente tenta converter esse futuro incerto em um plano detalhado. Esse impulso é compreensível. As organizações precisam de orçamentos, datas, coordenação, decisões de investimento e responsabilização. A dificuldade começa quando o plano é tratado não como uma previsão útil, mas como uma descrição da realidade. No desenvolvimento de software e de produtos digitais, fatos importantes frequentemente não existem no início do projeto. Eles só emergem depois que as pessoas constroem, integram, testam, lançam, observam e aprendem.

Essa é a ponte conceitual entre os capítulos anteriores sobre desenvolvimento orientado por planos e as ideias de Scrum apresentadas mais adiante. O Waterfall não é problemático porque planejar seja ruim. Planejar é valioso. A questão mais profunda é que tipos diferentes de problemas exigem formas diferentes de planejar e decidir. Um procedimento para uma tarefa conhecida e repetível não deve ser gerenciado como um produto experimental. Um cálculo de engenharia difícil não deve ser gerenciado como uma plataforma de consumo que muda rapidamente. E um problema complexo de produto não deve ser forçado a uma falsa certeza simplesmente porque uma planilha consegue exibir datas com precisão de um dia.

A ciência da complexidade e abordagens modernas de sense-making deram aos gestores um vocabulário para essa distinção. Um modelo influente é o framework Cynefin, desenvolvido por Dave Snowden e posteriormente amplamente popularizado por trabalhos que incluem o artigo de 2007 da Harvard Business Review, de Snowden e Mary Boone. O Cynefin distingue contextos nos quais causa e efeito são claros, contextos nos quais eles podem ser descobertos por meio de análise especializada e contextos nos quais padrões emergem da interação e muitas vezes só se tornam evidentes em retrospecto. A terminologia atual do Cynefin usa o rótulo clear para o domínio historicamente descrito como simple ou obvious. Para fins didáticos, este capítulo utilizará “simples/claro” ao relacionar a terminologia mais familiar ao framework moderno.

Para um candidato à PSM I, esse não é um tema secundário. O Guia do Scrum define Scrum como um framework leve para gerar valor por meio de soluções adaptativas para problemas complexos. O Scrum é fundamentado no empirismo e utiliza uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Essas afirmações passam a fazer mais sentido quando compreendemos o que “complexo” significa. O Scrum não promete eliminar a incerteza. Ele cria uma forma disciplinada de aprender mais rápido do que a incerteza pode se acumular silenciosamente.

radio_button_uncheckedshort_textProblemas simples ou claros: quando a padronização funciona

Um problema simples - ou, na terminologia atual do Cynefin, claro - é aquele em que a relação entre causa e efeito é estável, repetível e amplamente compreendida. O trabalho ainda pode exigir atenção e disciplina, mas a resposta correta costuma ser conhecida. Se as mesmas condições estiverem presentes, a mesma ação bem estabelecida tende a produzir o resultado esperado. Esse é o território dos procedimentos operacionais padrão, checklists, automação e melhores práticas.

Considere uma tarefa operacional conhecida: criar uma nova conta de usuário em um sistema interno maduro quando as informações, permissões e o processo exigidos estão completamente padronizados. A organização pode ter executado essa tarefa milhares de vezes. Um checklist pode descrever as etapas. Desvios são incomuns. Treinar um novo funcionário consiste principalmente em transferir um procedimento conhecido. Nesse ambiente, improvisar costuma ter menos valor do que manter a consistência.

A lógica de gestão é, portanto, direta: perceber o que está acontecendo, categorizar de acordo com um padrão conhecido e responder com a prática estabelecida. A padronização reduz variações desnecessárias. A automação pode aumentar a confiabilidade. Métricas podem revelar desvios em relação ao processo esperado. Procedimentos detalhados são úteis porque o ambiente é suficientemente estável para que o conhecimento anterior continue aplicável.

O perigo surge quando líderes pressupõem que todo trabalho deve se parecer com esse domínio. Organizações frequentemente preferem problemas claros porque eles transmitem sensação de controle. Há procedimentos fixos, resultados previsíveis e conformidade visível. Como consequência, um desafio complexo de produto pode ser forçado a modelos detalhados, cadeias de aprovação e planos rígidos concebidos para trabalho repetível. A documentação se torna mais certa, enquanto o problema subjacente continua incerto.

Essa distinção importa no software. Parte do trabalho de software é, de fato, clara. Rotacionar um certificado seguindo um runbook maduro, implantar uma configuração bem conhecida, provisionar um ambiente por meio de infraestrutura como código estável ou executar um backup padrão de banco de dados podem ser atividades procedurais. O Scrum não é necessário para toda tarefa. Julgamento profissional significa adequar a abordagem à natureza do trabalho, em vez de utilizar um único framework para tudo.

radio_button_uncheckedshort_textProblemas complicados: a especialização pode descobrir a resposta

Problemas complicados diferem dos simples porque a resposta não é óbvia. Eles podem conter muitas partes interagindo entre si, matemática avançada, tecnologias especializadas ou múltiplas soluções válidas. Entretanto, causa e efeito ainda são suficientemente estáveis para que uma análise qualificada os descubra. A especialização importa porque o sistema pode ser compreendido, mesmo quando essa compreensão exige tempo, ferramentas, modelagem ou especialistas.

Projetar uma estratégia de indexação de banco de dados para uma carga de trabalho conhecida pode ser complicado. Diagnosticar um gargalo de desempenho em um sistema distribuído pode ser complicado. Calcular cargas estruturais de uma ponte é complicado. Selecionar entre várias arquiteturas de criptografia sob restrições definidas pode ser complicado. Especialistas diferentes podem recomendar soluções diferentes, e pode haver trade-offs em vez de uma única resposta perfeita, mas o problema continua analisável.

A resposta apropriada, portanto, enfatiza perceber, analisar e responder. Em vez de aplicar imediatamente uma melhor prática universal, a organização estuda o contexto. Especialistas modelam alternativas, coletam medições, comparam opções e recomendam uma boa prática adequada à situação. Mais análise pode, de fato, reduzir a incerteza porque as relações relevantes existem e podem ser descobertas.

É por isso que a palavra “complicado” não deve ser usada de forma casual como sinônimo de “complexo”. Um motor a jato é extraordinariamente complicado, mas engenheiros conseguem decompô-lo em subsistemas, modelar forças, compreender tolerâncias, testar componentes e reproduzir processos de fabricação. Uma rede social tentando prever qual nova funcionalidade fará milhões de usuários mudarem de comportamento é complexa em outro sentido. O comportamento emerge das interações entre pessoas, incentivos, cultura, produtos concorrentes, algoritmos e efeitos de rede. Mais análise ajuda, mas a análise, por si só, não consegue revelar com certeza o que acontecerá depois que a mudança entrar no sistema real.

Projetos de software contêm tanto trabalho complicado quanto complexo. A arquitetura de um protocolo de autenticação conhecido pode ser complicada. Saber se os usuários confiarão em uma nova experiência de onboarding biométrico pode ser complexo. Uma boa equipe não rejeita conhecimento especializado porque utiliza Scrum; ela combina especialização com aprendizagem empírica. O desafio é saber quando a análise pode responder à pergunta e quando somente a interação com a realidade pode fazê-lo.

radio_button_uncheckedshort_textProblemas complexos: quando o futuro precisa ser descoberto

Um problema complexo contém relações dinâmicas, entrelaçadas e sensíveis à interação. Causa e efeito não podem ser previstos de forma confiável com antecedência. Padrões podem se tornar compreensíveis depois que os eventos ocorrem, mas a retrospectiva não garante que a mesma intervenção produzirá novamente o mesmo resultado. O sistema inclui muitos agentes que respondem uns aos outros, e essas respostas podem alterar as próprias condições do problema.

Produtos digitais frequentemente existem nesse domínio. Uma equipe de produto pode saber que clientes abandonam um fluxo de onboarding em determinada tela, mas talvez não saiba por quê. A linguagem é confusa? A verificação de identidade gera desconfiança? Falta algum documento ao usuário? A página é lenta demais em celulares de baixo custo? O cliente prefere um concorrente? Um requisito como “reduzir o abandono em 20%” descreve um resultado, não uma solução conhecida.

Em um contexto complexo, a lógica produtiva é sondar, perceber e responder. A equipe executa um experimento delimitado ou cria uma pequena mudança capaz de gerar informação. Em seguida, observa o sistema e se ajusta. O experimento deve ser pequeno o suficiente para que uma falha seja suportável e informativa. Em vez de exigir certeza antes de agir, a equipe utiliza uma ação cuidadosamente escolhida para produzir conhecimento.

Isso muda o significado do planejamento. Planejar continua importante, mas o plano passa a ser uma hipótese sobre como avançar em direção a um objetivo. A organização planeja no nível adequado às evidências disponíveis. Objetivos de longo prazo podem ser claros, enquanto o caminho detalhado permanece adaptável. Quanto mais distante estiver o horizonte do plano, mais ele deve ser tratado como previsão, e não como promessa sobre tarefas exatas.

A estrutura do Scrum é coerente com essa lógica. Um Product Owner ordena o trabalho relacionado a um problema complexo em um Product Backlog. A Scrum Team cria um Increment durante uma Sprint. A equipe e os stakeholders inspecionam o resultado, aprendem com ele e se adaptam. O ciclo se repete. Isso não é iteração apenas para “andar mais rápido”. É um mecanismo para converter desconhecidos em evidências enquanto se controla a quantidade de investimento colocada sobre premissas ainda não validadas.

radio_button_uncheckedshort_textUma comparação prática: simples, complicado e complexo

As fronteiras entre essas categorias não são determinadas pelo vocabulário utilizado em um termo de abertura de projeto. Elas são determinadas pela natureza da causalidade e da incerteza. Uma tarefa pode migrar entre domínios à medida que o conhecimento cresce. Algo que antes era complicado pode se tornar claro depois que uma organização o padroniza. Uma funcionalidade de produto que parece clara pode revelar complexidade oculta depois que usuários reais interagem com ela. O objetivo da distinção não é classificar por classificar; é evitar a utilização do modelo de decisão errado.

Uma pergunta diagnóstica útil é: “Mais análise consegue nos dizer, de forma confiável, o que acontecerá, ou precisamos interagir com o sistema real para aprender?” Se a análise consegue revelar a resposta, o problema provavelmente é complicado. Se o conhecimento relevante só emerge depois que usuários, mercados, tecnologias ou equipes reagem a uma intervenção, o problema apresenta características complexas.

radio_button_uncheckedshort_textPor que produtos digitais são tão frequentemente incertos

O desenvolvimento de produtos digitais combina várias fontes de incerteza ao mesmo tempo. A equipe não está apenas resolvendo um problema técnico. Ela toma decisões sobre comportamento do usuário, valor de negócio, momento de mercado, regulamentação, dados, integrações, segurança, operações e mudanças futuras. Cada dimensão pode invalidar premissas feitas em outra. Um produto tecnicamente elegante pode fracassar comercialmente. Uma funcionalidade valiosa pode ser bloqueada por regulamentação. Um design correto pode se tornar obsoleto porque um fornecedor de plataforma altera uma API. Um produto que os usuários pediram pode decepcioná-los quando finalmente o utilizarem.

Isso não significa que produtos digitais sejam incognoscíveis. Equipes podem pesquisar, modelar, prototipar, estimar, testar e fazer previsões. O ponto é que parte da incerteza é irredutível antes da interação com a realidade. Uma entrevista de usabilidade pode reduzir riscos, mas não consegue prever perfeitamente o comportamento em escala. Um teste de carga pode modelar desempenho, mas o tráfego em produção pode revelar padrões que o modelo não continha. Uma análise de mercado pode estimar a demanda, mas concorrentes e preferências dos clientes continuam evoluindo.

O software também possui uma capacidade incomum de mudança. Um edifício físico torna-se caro de redesenhar depois que o concreto é lançado. Em comparação, software muitas vezes pode ser alterado rapidamente, e essa flexibilidade cria novas expectativas. Usuários comparam produtos continuamente. Concorrentes lançam funcionalidades. Plataformas mudam. Ameaças de segurança evoluem. O que era aceitável há seis meses pode ser inadequado hoje. A capacidade de mudar passa a fazer parte do ambiente competitivo do produto.

Por essa razão, a incerteza não é apenas um problema do início do projeto que desaparece depois que os requisitos são aprovados. Ela persiste por todo o ciclo de vida do produto. Equipes maduras aprendem a gerenciar a incerteza como uma propriedade normal do trabalho de produto, em vez de tratar todo desvio do plano original como falha de disciplina.

radio_button_uncheckedshort_textMudança de requisitos: um sinal, não automaticamente uma falha

Requisitos mudam por muitos motivos. Às vezes, o requisito original foi mal compreendido. Às vezes, stakeholders aprendem ao ver software funcionando. Às vezes, uma regulamentação muda. Às vezes, uma dependência revela uma nova restrição. Às vezes, usuários se comportam de maneira diferente dos participantes de uma pesquisa. Às vezes, um objetivo estratégico muda porque a economia do mercado mudou. Às vezes, a equipe descobre uma forma mais barata de alcançar o mesmo resultado, e a especificação original deixa de valer a pena.

Em uma cultura de projeto preditiva, a mudança de requisitos costuma ser tratada principalmente como instabilidade de escopo. Solicitações de mudança são contabilizadas, baselines são protegidas e variações são escaladas. Esses controles podem ser necessários em contratos ou ambientes regulados, mas também podem estimular a ilusão de que a estabilidade em si é o objetivo. No desenvolvimento de produtos, o objetivo é valor. Um requisito estável e errado é pior do que um requisito alterado que reflita novas evidências.

A distinção principal está entre mudança descontrolada e adaptação informada. Alterar prioridades aleatoriamente todos os dias pode destruir o foco. O Scrum não celebra o caos. Uma Sprint cria um horizonte protegido de curto prazo por meio da Sprint Goal. O Product Backlog pode evoluir conforme mais conhecimento é obtido, enquanto a Sprint oferece um contêiner estável para trabalho focado. A adaptação acontece dentro de limites explícitos, e não por meio de interrupção constante.

Essa é uma das sutilezas que candidatos à PSM I devem compreender. O Scrum é adaptativo, mas adaptativo não significa “qualquer coisa pode mudar a qualquer momento sem custo”. Mudanças que colocam em risco a Sprint Goal não são tratadas de maneira casual. O objetivo é criar estabilidade suficiente para realizar trabalho significativo e flexibilidade suficiente para responder às evidências.

radio_button_uncheckedshort_textMudanças de mercado: o alvo pode se mover enquanto você constrói

Um plano de projeto pode ser internamente perfeito e ainda assim fracassar porque o ambiente fora do projeto mudou. Concorrentes introduzem novos preços. O proprietário de uma plataforma altera regras de distribuição. Taxas de juros mudam o comportamento dos clientes. Um evento geopolítico afeta cadeias de suprimentos. Uma nova lei altera requisitos de retenção de dados. Uma nova capacidade de IA muda aquilo que os clientes consideram normal. O business case original do projeto, portanto, pode se tornar mais fraco ou mais forte durante a execução.

É por isso que estratégia de produto não pode ser completamente separada da entrega. Quando equipes passam meses implementando um escopo fixo sem obter feedback do mercado, acumulam exposição a mudanças ambientais. Quanto maior o atraso do feedback, mais capital é investido em premissas que talvez já não sejam válidas.

Ciclos curtos não tornam uma empresa clarividente. Eles reduzem o tempo entre uma mudança externa e a oportunidade de a organização responder. Uma equipe que revisa resultados reais do produto a cada poucas semanas dispõe de mais pontos de decisão do que uma equipe comprometida com um lançamento de doze meses antes de qualquer validação significativa. A opcionalidade possui valor econômico: a organização pode continuar, mudar de direção, encerrar um experimento ou investir mais quando as evidências forem favoráveis.

Uma forma útil de pensar sobre agilidade, portanto, não é “fazer as coisas rapidamente”, mas “manter a capacidade de mudar de direção a um custo razoável”. Velocidade sem feedback pode apenas levar uma equipe mais rapidamente ao destino errado.

radio_button_uncheckedshort_textMudança tecnológica: o espaço de solução também não é estável

A incerteza também existe dentro da solução. A tecnologia evolui continuamente. Serviços de nuvem alteram capacidades e preços. Frameworks lançam novas versões. Vulnerabilidades de segurança aparecem. O comportamento dos navegadores muda. Sistemas operacionais móveis descontinuam APIs. Limitações de infraestrutura tornam-se visíveis sob carga de produção. Serviços de terceiros alteram contratos ou características de confiabilidade. Decisões de arquitetura que pareciam sensatas no início do projeto podem precisar de revisão à medida que as evidências se acumulam.

Mesmo quando a tecnologia em si não muda, a compreensão da equipe sobre ela muda. Um protótipo pode revelar que uma biblioteca não atende aos requisitos de latência. Testes de integração podem expor comportamentos não documentados em um sistema parceiro. Uma revisão de segurança pode mostrar que um design aparentemente conveniente amplia a superfície de ataque. Em cada caso, o projeto aprende algo que não poderia ser plenamente conhecido a partir do plano inicial.

É por isso que spikes técnicos, protótipos, experimentos de arquitetura, integração contínua, testes automatizados, observabilidade e implantação incremental podem ser vistos como mecanismos de aprendizagem. Seu valor não se limita à eficiência de engenharia. Eles encurtam a distância entre uma premissa técnica e a evidência sobre sua validade.

O Scrum não prescreve essas práticas de engenharia, mas cria uma cadência na qual o aprendizado técnico pode influenciar repetidamente o planejamento. O framework é intencionalmente incompleto. As equipes podem empregar processos, técnicas e métodos que as ajudem a resolver o problema, desde que o framework Scrum permaneça intacto.

radio_button_uncheckedshort_textFeedback dos usuários: o produto muda quando as pessoas o utilizam

Usuários são uma das fontes mais fortes de incerteza porque o comportamento humano não pode ser reduzido a documentos de requisitos. As pessoas dizem uma coisa em entrevistas e fazem outra em contextos reais. Criam soluções alternativas. Interpretam rótulos de forma equivocada. Evitam funcionalidades que pareciam desejáveis durante a pesquisa. Combinam funcionalidades de maneiras inesperadas. Encontram restrições de acessibilidade, dispositivo, idioma, confiança e ambiente que a equipe de produto não imaginou por completo.

É por isso que “o cliente aprovou a especificação” é uma evidência mais fraca do que “clientes reais alcançaram o resultado pretendido usando o produto”. A aprovação valida um acordo. O uso valida comportamento. Resultados de negócio validam valor. Cada nível fornece informações diferentes, e os níveis posteriores frequentemente revelam premissas ocultas nos documentos anteriores.

Um bom feedback também vai além de perguntar se os usuários gostam de uma funcionalidade. As equipes podem inspecionar taxas de conclusão, pontos de abandono, tempo de execução de tarefas, contatos com suporte, padrões de defeitos, retenção, conversão, receita, taxas de erro e comentários qualitativos. O objetivo é criar múltiplos sinais que reduzam a chance de confundir opinião com evidência.

A Sprint Review é relevante nesse ponto porque representa uma oportunidade para a Scrum Team e os stakeholders inspecionarem o resultado da Sprint e determinarem adaptações futuras. Ela não deve ser reduzida a uma demonstração teatral cujo propósito seja provar que a equipe concluiu tarefas. O propósito mais profundo é a inspeção colaborativa do que mudou no produto e no ambiente, bem como do que deve acontecer a seguir.

radio_button_uncheckedshort_textHipóteses versus fatos: a disciplina da honestidade intelectual

Um dos hábitos mais importantes no desenvolvimento de produtos complexos é aprender a rotular a incerteza com precisão. Equipes frequentemente falam sobre premissas usando a gramática dos fatos: “Os clientes precisam deste dashboard.” “A integração suportará o volume.” “Os usuários pagarão pela automação premium.” “Este redesign reduzirá as chamadas de suporte.” Cada afirmação pode ser plausível, mas plausibilidade não é evidência.

Uma hipótese é uma afirmação que pode ser testada. Tratar uma hipótese como hipótese não enfraquece a equipe; melhora a qualidade das decisões. Isso permite perguntar quais evidências aumentariam ou reduziriam a confiança. Também torna a discordância mais produtiva, porque a pergunta deixa de ser “A opinião de quem vence?” e passa a ser “O que podemos observar que nos ajudaria a aprender?”.

A descoberta de produto frequentemente funciona tornando as premissas explícitas, priorizando-as por risco e projetando experimentos que testem as incertezas mais relevantes. Uma equipe pode criar um protótipo clicável antes de implementar um fluxo, expor uma funcionalidade a um pequeno grupo de usuários, instrumentar um funil, realizar sessões de usabilidade, construir um spike técnico ou executar um teste de desempenho. Essas ações transformam debate abstrato em evidência.

Nem toda decisão exige um experimento. Questões claras e complicadas podem ser respondidas por procedimento ou análise. A disciplina está em adequar o método de aprendizagem à incerteza. Executar um teste A/B para decidir uma exigência legal seria absurdo. Criar um projeto de análise de seis meses para descobrir se os usuários compreendem o rótulo de um botão pode ser igualmente absurdo.

radio_button_uncheckedshort_textPor que não podemos prever o projeto inteiro antecipadamente

Um plano de projeto detalhado é construído a partir de premissas sobre escopo, sequência, duração, dependências, capacidade, disponibilidade, dificuldade técnica, decisões de stakeholders e eventos externos. Cada premissa introduz incerteza. Quando muitas premissas interagem ao longo de meses, pequenos erros se acumulam. O problema não é incompetência dos planejadores. O problema é que detalhes de longo alcance frequentemente excedem a informação disponível.

Esse fenômeno é visível na estimativa. Uma equipe geralmente consegue prever trabalho de curto prazo com mais confiança do que trabalho situado vários trimestres à frente, porque itens próximos são mais bem compreendidos e há menos eventos desconhecidos capazes de interferir. À medida que o horizonte se expande, a incerteza cresce. Em trabalho complexo, tentar eliminar essa incerteza por meio de mais especificação pode produzir precisão sem exatidão: o plano pode conter datas exatas e, ainda assim, repousar sobre premissas frágeis.

Também existe um paradoxo de descoberta. Algumas informações necessárias para o planejamento posterior só se tornam disponíveis depois que o trabalho anterior é executado. Talvez você não conheça o esforço real de integração até que um protótipo se comunique com o sistema parceiro. Talvez não conheça o fluxo de usuário correto até que usuários experimentem uma versão realista. Talvez não saiba qual fronteira arquitetural importa até que dados operacionais revelem gargalos. O aprendizado muda o plano porque o aprendizado muda aquilo que a equipe sabe.

É por isso que abordagens empíricas utilizam elaboração progressiva. Elas tomam decisões no último momento responsável compatível com as evidências disponíveis, em vez de decidir cada detalhe no primeiro momento possível. O objetivo não é procrastinar. É evitar compromissos caros construídos em torno de premissas que ainda são frágeis.

radio_button_uncheckedshort_textCiclos curtos de aprendizagem: transformando incerteza em evidência

Um ciclo de feedback conecta ação à informação. A equipe faz algo, observa o que aconteceu, compara o resultado com o objetivo pretendido e se adapta. Quanto mais curto o ciclo, mais cedo premissas incorretas se tornam visíveis. Essa é a lógica econômica por trás do desenvolvimento iterativo, da integração contínua, dos testes automatizados, da colaboração frequente com stakeholders e das entregas incrementais.

Ciclos curtos reduzem riscos de várias maneiras. Primeiro, limitam o tamanho do lote: menos decisões dependem de uma premissa não validada. Segundo, melhoram memória e causalidade: quando o feedback chega logo após uma mudança, é mais fácil compreender o que produziu o resultado. Terceiro, preservam a opcionalidade: a equipe pode redirecionar o investimento antes que dinheiro ou tempo demais sejam comprometidos. Quarto, criam um ritmo de responsabilização no qual o progresso é demonstrado por resultados e Increments funcionando, e não por relatórios otimistas de “percentual concluído”.

O Scrum formaliza esse ritmo de aprendizagem por meio da Sprint e de seus eventos. A Sprint cria um contêiner de duração fixa de um mês ou menos. O Sprint Planning estabelece uma Sprint Goal e um plano. O Daily Scrum cria um ponto diário de inspeção para os Developers. A Sprint Review inspeciona o resultado com stakeholders e considera o que mudou no ambiente. A Sprint Retrospective inspeciona a eficácia da equipe e identifica melhorias. A Sprint seguinte começa imediatamente, de modo que a adaptação se torna contínua, em vez de uma atividade especial de recuperação realizada depois que uma grande fase do projeto fracassa.

O objetivo não é maximizar o número de reuniões. Os eventos são oportunidades formais de inspeção e adaptação. Se uma equipe apenas realiza cerimônias enquanto informações importantes permanecem ocultas, o feedback é ignorado ou as decisões não podem mudar, o ciclo é cosmético. O empirismo exige transparência, inspeção e adaptação em conjunto.

radio_button_uncheckedshort_textExemplo prático: criando um novo alerta contra fraude em pagamentos instantâneos

Imagine que um banco queira reduzir perdas causadas por clientes que aprovam transferências de pagamento instantâneo para golpistas. Um stakeholder sênior propõe um requisito: antes de qualquer transferência de alto valor, exibir um alerta em tela cheia com texto vermelho, um checkbox obrigatório e uma contagem regressiva de 20 segundos. A solicitação parece precisa; portanto, uma equipe de projeto poderia tratá-la como fato e estimar a implementação.

Mas a necessidade subjacente não é “mostrar um alerta vermelho”. O resultado desejado é reduzir golpes bem-sucedidos sem causar atrito inaceitável a clientes legítimos. Se o alerta proposto alcançará esse resultado é algo incerto. Táticas criminosas mudam. Clientes podem aprender a ignorar alertas repetitivos. Usuários mais velhos e pessoas com necessidades de acessibilidade podem experimentar a tela de maneira diferente. Uma longa contagem regressiva pode aumentar o abandono sem reduzir fraude. A intervenção correta é uma hipótese de produto, não uma receita conhecida.

Uma abordagem de produto complexo separaria fatos de premissas. Fatos poderiam incluir dados atuais de perdas por fraude, valores de transação, padrões conhecidos de golpes, taxas de abandono e exigências regulatórias. Hipóteses poderiam incluir “um alerta contextual fará usuários em risco reconsiderarem o pagamento” ou “adicionar uma etapa curta de confirmação reduzirá fraude sem prejudicar de forma relevante as taxas legítimas de conclusão”.

A equipe poderia então projetar um ciclo de aprendizagem pequeno e controlado. Poderia primeiro prototipar diversos modelos de alerta e testar a compreensão com clientes. Em seguida, poderia liberar o modelo mais promissor para um segmento limitado, medir indicadores de fraude e abandono, coletar feedback do suporte e inspecionar os resultados. Se o alerta ajudar apenas em determinados cenários, a iteração seguinte poderia direcionar sinais de risco em vez de todos os pagamentos de alto valor.

Observe o que mudou. A equipe continua planejando, projetando, construindo, testando e medindo. A diferença é que ela não finge conhecer a solução antes de existirem evidências. Investe de forma incremental, aprende e se adapta. Um experimento que falha não é necessariamente um projeto que falhou; se for pequeno e informativo, ele evita um fracasso maior ao invalidar cedo uma premissa fraca.

Essa é a mentalidade que conecta diretamente complexidade e Scrum. A Product Goal pode expressar o resultado de longo prazo de reduzir perdas relacionadas a fraude e danos aos clientes. Itens do Product Backlog podem representar intervenções candidatas. Cada Sprint pode criar evidências utilizáveis por meio de um Increment. Stakeholders inspecionam os resultados, e o Product Backlog muda à medida que o conhecimento cresce. O plano passa a servir ao aprendizado, em vez de tentar eliminar a necessidade dele.

radio_button_uncheckedshort_textO que isso significa para um candidato à PSM I

Questões da PSM I raramente exigem que você nomeie um framework de complexidade, mas a complexidade explica muitas regras do Scrum. Quando você entende o problema subjacente, o framework se torna mais fácil de raciocinar. Por que o Product Backlog é emergente? Porque a compreensão muda. Por que os Sprints são curtos e de duração fixa? Porque inspeções frequentes limitam riscos e criam oportunidades de aprendizagem. Por que a Scrum Team produz um Increment a cada Sprint? Porque produto integrado e utilizável fornece evidências mais fortes do que planos sobre trabalho futuro.

Por que a Sprint Review é colaborativa, e não um gate formal de aprovação? Porque stakeholders e a Scrum Team precisam inspecionar juntos os resultados e as mudanças no ambiente. Por que o Guia do Scrum enfatiza adaptação? Porque informação nova não tem valor se o sistema não puder mudar em resposta. Por que transparência é essencial? Porque inspeção baseada em uma imagem imprecisa da realidade produz decisões ruins.

Isso também ajuda a identificar respostas erradas. Um cenário pode apresentar incerteza e, em seguida, oferecer uma resposta de comando e controle: congelar todos os requisitos, pedir a um gestor que atribua tarefas detalhadas, estender a Sprint até que todo compromisso seja entregue ou evitar feedback de stakeholders até que a solução esteja completa. Essas opções podem parecer organizadas, mas frequentemente reduzem a aprendizagem empírica. Em trabalho complexo, disciplina profissional não é ausência de mudança. É a capacidade de aprender e se adaptar sem perder foco, qualidade e responsabilização.

A perspectiva da prova, portanto, é direta: o Scrum foi projetado para problemas complexos, e problemas complexos não podem ser gerenciados com sucesso fingindo que todo conhecimento importante está disponível antecipadamente. O framework cria oportunidades delimitadas para transformar incerteza em informação e informação em decisões melhores.

radio_button_uncheckedshort_textConclusão: preveja menos, aprenda melhor

Problemas simples, complicados e complexos exigem respostas de gestão diferentes. Problemas claros recompensam a padronização porque causa e efeito são conhecidos. Problemas complicados recompensam especialização e análise porque causa e efeito podem ser descobertos. Problemas complexos exigem aprendizagem empírica porque padrões importantes emergem apenas por meio da interação com o sistema real. Confundir esses domínios leva ou a experimentação desnecessária onde um procedimento bastaria ou, de forma mais perigosa, à falsa certeza onde aprender é inevitável.

O desenvolvimento de produtos digitais frequentemente contém características complexas porque requisitos, mercados, tecnologia, usuários, concorrentes, regulamentações e restrições organizacionais evoluem em conjunto. Um projeto pode reduzir a incerteza por meio de pesquisa e análise, mas não consegue eliminar todo desconhecido antes da implementação. Parte do conhecimento só é criada ao construir, integrar, lançar e observar.

A resposta prática não é abandonar o planejamento. É mudar o papel do planejamento. Planos passam a ser previsões e hipóteses continuamente comparadas com evidências. Equipes distinguem fatos de premissas, validam cedo as crenças de maior risco, trabalham em lotes menores e encurtam ciclos de feedback. Isso reduz o custo de estar errado e aumenta a capacidade da organização de mudar de direção enquanto a mudança ainda é economicamente viável.

Na minha visão, essa é uma das mudanças intelectuais mais importantes por trás do Agile e do Scrum. A alternativa madura à previsão não é desordem; é aprendizagem disciplinada. O Scrum oferece estrutura precisamente porque a complexidade exige estrutura: objetivos, accountabilities, timeboxes, artefatos transparentes, Increments utilizáveis e oportunidades formais de inspecionar e adaptar. O que ele se recusa a oferecer é a ficção confortável de que um plano detalhado pode substituir evidências.

À medida que avançar para os próximos capítulos, mantenha uma pergunta simples disponível: “O que realmente sabemos e o que estamos apenas supondo?” Em trabalho complexo de produto, essa pergunta pode ser mais valiosa do que outras cem linhas em um cronograma de projeto. Ela também é um dos fundamentos do pensamento empírico - a mentalidade que torna o Scrum coerente, e não meramente cerimonial.

radio_button_uncheckedshort_textO ciclo de aprendizagem no desenvolvimento de produtos complexos

Mentalidade para a prova

Quando um cenário da PSM I contiver informações que mudam, não pergunte como forçar a realidade de volta ao plano original. Pergunte como o Scrum cria transparência, inspeção e adaptação enquanto preserva a Sprint Goal, as accountabilities, a qualidade e a autogestão.

radio_button_uncheckedshort_textPrincipais conclusões

• Problemas simples/claros possuem relações de causa e efeito estáveis e óbvias e frequentemente se beneficiam de procedimentos padronizados.
• Problemas complicados podem ser difíceis, mas a análise especializada consegue descobrir relações causais e soluções viáveis.
• Problemas complexos contêm comportamento emergente; conhecimento significativo frequentemente aparece somente após interação com o sistema real.
• Produtos digitais estão expostos a mudanças de requisitos, mercado, tecnologia, usuários, regulamentação e organização ao longo de todo o ciclo de vida.
• Um requisito ou uma ideia de produto frequentemente é uma hipótese até que evidências demonstrem que ela produz o resultado desejado.
• Planos detalhados de longo alcance podem criar falsa precisão quando a informação necessária para decisões futuras ainda não existe.
• Ciclos curtos de feedback reduzem o custo de premissas erradas ao limitar o tamanho do lote e aumentar as oportunidades de adaptação.
• O Scrum utiliza empirismo e uma abordagem iterativa e incremental porque foi concebido para soluções adaptativas de problemas complexos.

radio_button_uncheckedshort_textVocabulário para pesquisa e estudo

Termos úteis para estudo adicional e preparação para a PSM I:

complexidade em projetos de software; incerteza no desenvolvimento de software; problemas simples versus complicados versus complexos; framework Cynefin; desenvolvimento de produtos digitais; mudança de requisitos; incerteza de mercado; incerteza tecnológica; feedback de usuários; hipóteses de produto; controle empírico de processos; empirismo no Scrum; transparência, inspeção e adaptação; desenvolvimento iterativo e incremental; ciclos curtos de feedback; aprendizagem contínua; emergência do Product Backlog; Sprint Review; gestão de riscos no Agile; planejamento adaptativo.

radio_button_uncheckedshort_textReferências oficiais e fundamentais

• Schwaber, Ken, e Jeff Sutherland. Guia do Scrum, novembro de 2020. Define o Scrum como um framework leve para soluções adaptativas de problemas complexos e explica empirismo, pensamento Lean, entrega iterativa e incremental, transparência, inspeção e adaptação.
• ScrumGuides.org - página oficial de download do Guia do Scrum. Confirma o Guia do Scrum de novembro de 2020 como a versão oficial vigente considerada por este material.
• Snowden, David J., e Mary E. Boone. “A Leader’s Framework for Decision Making.” Harvard Business Review, novembro de 2007. Introdução amplamente citada ao framework Cynefin e à distinção entre contextos simples/claros, complicados, complexos, caóticos e de desordem.
• The Cynefin Co. - About the Cynefin Framework. Descrição atual do Cynefin como um framework de sense-making que ajuda tomadores de decisão a adequar a ação à natureza do contexto.
• Manifesto para Desenvolvimento Ágil de Software, 2001. Apresenta o valor histórico do Agile de responder a mudanças mais do que seguir um plano, reconhecendo explicitamente que também há valor no planejamento.

Nota terminológica: o framework Cynefin evoluiu ao longo do tempo. Materiais atuais do Cynefin usam com frequência “Clear”, enquanto explicações mais antigas utilizavam “Simple” ou “Obvious”. Este capítulo adota “simples/claro” para conectar o vocabulário comum de gestão de projetos à terminologia atual. Os conceitos de Scrum são baseados no Guia do Scrum oficial de novembro de 2020.