> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2024/essay-collection-informal-talks.md).

# Coletânea de ensaios — Reflexões diversas

Antes do Ano-Novo, pesquisei a construção de plataformas de testes A/B. Os detalhes estão reunidos em [Domínio dos problemas de A/B](https://km.sankuai.com/collabpage/2103469706).

1. Avaliação do estágio em que estamos. Pelo modelo de maturidade da experimentação, Jingwan está aproximadamente na fase de caminhar, e os demais negócios, na de engatinhar. Engatinhar já é a primeira etapa do modelo. Antes disso, eu chamaria a fase de despertar ou iniciação. Seu objetivo é criar as condições básicas para experimentar, principalmente ferramentas e capacidade elementar de ciência de dados.
2. As plataformas A/B mais avançadas da empresa. Conversamos principalmente com o Horizon, da plataforma central do grupo, e com a plataforma A/B da operação de atendimento de serviços em domicílio. Ambas estão aproximadamente na fase de correr. A direção é reduzir, em escala, as barreiras à experimentação e garantir a confiabilidade dos resultados. Isso evita que os experimentadores gastem energia demais justificando o desenho do experimento e que fatores humanos prejudiquem sua confiabilidade. Foram introduzidas funções ligadas à ciência de dados. Pelos indicadores, já se percebe uma visão de toda a cadeia: integração, divisão do tráfego, execução e decisão. Exemplos são a proporção de novos experimentos cuja objetividade pode ser avaliada e a proporção de resultados objetivos entre os experimentos importantes.
3. **Lições da evolução da plataforma A/B de atendimento dos serviços em domicílio. Essas informações vieram de uma conversa com um de seus integrantes centrais. Vejo ali um exemplo típico de tecnologia a serviço do negócio. Na evolução contínua dessa relação, o mais valioso é a mentalidade e o talento para integrar negócio e tecnologia.** Num domínio tão especializado, o negócio não consegue descrever claramente os problemas e, às vezes, nem percebe que eles existem. Para servi-lo bem, é preciso sair da própria especialidade, ir à linha de frente, entender a operação e mudar de perspectiva. A execução do serviço é o núcleo do atendimento em domicílio; sua eficiência é, portanto, decisiva. O modelo de múltiplos participantes dos serviços baseados em localização exige muitos experimentos com algoritmos e estratégias, ampliando a necessidade de uma plataforma A/B de alto nível. No início, plataforma e negócio funcionavam com acoplamento fraco, destacando a leveza do modelo de plataforma. Em 2022, a equipe passou a se concentrar na operação de atendimento e a oferecer um serviço totalmente gerenciado. O negócio só precisa apresentar a demanda; o desenho, a execução e a análise do experimento são fechados dentro da equipe de dados. Ela oferece uma solução, com capacidades, ferramentas e métodos, não apenas uma capacidade isolada. Diante de desafios de negócio suficientemente profundos, essa operação também explorou cedo a colaboração com a pesquisa. A plataforma oferece três níveis de abertura: totalmente gerenciada, parcialmente gerenciada e acesso ao mecanismo de análise. Eles correspondem, respectivamente, à gestão unificada pela plataforma, à abertura das capacidades de desenho e avaliação dos experimentos e à disponibilização de métodos analíticos elementares.

***

Ao revisar recentemente o trabalho com a biblioteca de componentes, tentei responder a uma pergunta bastante vaga: como construir uma biblioteca com muita vitalidade? Bibliotecas são tão comuns que o assunto parece claro, simples e fácil de entender. Mas são poucas as que se tornam populares, agradáveis de usar e duradouras, principalmente duradouras. Vou tentar responder por dois ângulos.

**Resolver problemas reais dentro de um escopo definido, mantendo uma relação positiva entre investimento e retorno.**

É preciso identificar o problema real a partir do valor pretendido, fazer uma investigação detalhada e resolvê-lo concretamente. O escopo importa: custos e escolhas de solução mudam conforme a abrangência. Uma biblioteca para todo o Meituan, para serviços financeiros ou para uma única equipe pode buscar valores bem diferentes.

Quando o alcance potencial do valor de um projeto já é limitado, a relação entre investimento e retorno exige atenção constante. Sem perceber, o custo de manutenção pode superar o valor real, e isso acaba sendo corrigido no médio ou longo prazo. Recentemente, muita gente lamentou o fim da manutenção do YAPI, uma ferramenta de mock de APIs com experiência melhor, enquanto o PAPI continua sendo a primeira recomendação oficial. Deixando de lado as diferenças organizacionais entre os dois, suponho que o custo de manutenção do YAPI já superasse o ganho de experiência para os desenvolvedores. Não tenho dados para provar isso. Mas o fato de a maioria dos projetos não ter migrado para o YAPI sugere que esse ganho era pequeno, talvez nem suficiente para compensar a migração.

**Resolver o problema no nível certo de abstração.**

A essência do problema, somada ao seu escopo, define o problema real. Uma biblioteca de componentes já é uma solução. Em escopos mais amplos, talvez não seja a melhor. Subindo nos níveis de abstração, podemos dividir as soluções, de forma aproximada, em implementação, biblioteca, framework e padrão. A biblioteca está no segundo nível. Acredito que essa seja a razão de o MTD não ter dado certo. Existe na comunidade um projeto chamado [A Global Design System](https://component-odyssey.com/articles), cuja visão é oferecer componentes universais a designers e desenvolvedores do mundo inteiro. Na verdade, não é uma biblioteca de componentes, mas um sistema; também não é um design system como o Material Design. Não é preciso se fixar em saber se o projeto dará certo. O importante é aprender a explorar uma questão num nível mais alto de abstração.

***

Os assuntos técnicos de uma equipe de negócio podem ser divididos em duas grandes categorias. Uma resolve os problemas mais urgentes da etapa atual, concentrando esforços para enfrentá-los um por um, geralmente por meio de iniciativas técnicas específicas. A outra exige construção e operação contínuas, como bibliotecas de componentes e infraestrutura de engenharia. É um trabalho constante, denso e de longo prazo, para o qual falta um mecanismo adequado de funcionamento. Esse mecanismo também poderia responder, em parte, à questão de como manter a atividade e a vitalidade da infraestrutura.

Com o crescimento da equipe e a consolidação das bases de engenharia, nosso foco precisa passar gradualmente das campanhas pontuais para os mecanismos duradouros.

Nossa infraestrutura já percorreu o caminho de zero a um. Agora precisamos aprender a ir de um ao infinito. O funcionamento atual é relativamente fechado, e o que é fechado depende de indivíduos. Há pouca disposição espontânea para contribuir; a equipe depende de ordens administrativas. Minha ideia é aprender com projetos maduros de código aberto para criar um mecanismo de trabalho aberto e sustentável, capaz de estimular a criatividade.

Segue uma versão preliminar do [Mecanismo de grupo de trabalho — Working Group](https://km.sankuai.com/collabpage/2610619313). Ela adota o conceito de Working Group e introduz mecanismos como RFC e Membership. Também faz adaptações ao tamanho da equipe para equilibrar eficiência e abertura. Quem tiver ideias, por favor, contribua.

***

Com as mudanças recentes do negócio no livro de registros, tanto frontend quanto backend passaram a enfrentar questões sobre a adequação da arquitetura. Essa adequação se reflete diretamente na qualidade. A refatoração do cartão empresarial começou por aí. Quero compartilhar algumas ideias sobre arquitetura de negócio no frontend.

1. Arquitetura não ocupa a mesma posição no frontend e no backend. No frontend, ainda não há consenso suficiente sobre o desenho da arquitetura de negócio. Fala-se mais da escolha de frameworks e ferramentas. Uma razão importante talvez seja que o frontend enfrente menos desafios arquiteturais. Muitos projetos nunca chegam, durante toda a sua vida útil, aos gargalos produzidos por essas decisões. Um projeto genérico criado por um scaffold pode atender até o limite das necessidades do negócio.
2. O que é uma decisão arquitetural e o que não é? Arquitetura resulta de comunicação, análise e raciocínio, não apenas da escolha de ferramentas. Olhar somente para a estrutura de diretórios e a documentação entregues facilita esquecer conceitos importantes, como isolamento e reutilização, gestão de estado e inversão de dependências. Esses aspectos têm mais relação com a qualidade real e com a capacidade de atender ao negócio. A arquitetura ECS em jogos, por exemplo, resolve um problema de manutenibilidade específico daquele domínio.
3. É necessário separar as arquiteturas de frontend e backend, ou basta uma equipe geral? A questão é ampla. A estrutura do sistema naturalmente reflete como a equipe se comunica; não vou desenvolver aqui a parte da lei de Conway. Há dois pontos que vale comentar. Primeiro, o desenho da arquitetura global passará a incluir o frontend. Ainda estamos no processo de fazer uma língua minoritária explicar seu trabalho à língua dominante. A discussão sobre qualidade e eficiência já começou a considerar o frontend, embora o exame de prevenção de riscos técnicos ainda pareça uma prova teórica de informática desconectada da prática. Será que a arquitetura também não está perto? Segundo, frontend e backend podem aprender um com o outro. O frontend pode aproveitar DDD e outras ideias de desenho do backend para entender melhor os problemas de negócio. O backend pode aprender os métodos eficientes de prototipagem do frontend e a ideia de componentes como serviços.
4. Para entender arquitetura frontend, [What is Frontend Architecture?](https://ducin.dev/what-is-frontend-architecture) é leitura obrigatória. Vale acompanhar seu autor, Tomasz Ducin, nesse campo.

***

Limites físicos, limites de engenharia e limites da experiência. Essas distinções ajudam a responder a uma pergunta que observei na semana passada: quando falamos em otimização, de qual nível estamos falando e dentro de quais fronteiras estamos trabalhando?

Entender os limites físicos permite reconhecer restrições fundamentais, manter a clareza em processos complexos de inovação e investir recursos com mais discernimento. Ainda há pesquisadores amadores tentando construir máquinas de movimento perpétuo, embora Carnot tenha demonstrado no século XIX um limite teórico para a eficiência das máquinas térmicas. Essa tentativa está, portanto, condenada ao fracasso. Hoje também há quem acredite que a IA resolverá todos os problemas e substituirá os humanos. Turing já permitia responder claramente a essa questão no século XX. Entre todos os problemas do mundo, apenas uma pequena parte é matemática. Desses, só uma parte tem solução; outra parte é computável por uma máquina de Turing; e outra pode ser executada nos computadores atuais. Os problemas que a IA consegue resolver são apenas um subconjunto disso tudo. É quase impossível derrubar limites físicos. Limites matemáticos são totalmente impossíveis de derrubar, porque a matemática se apoia estritamente na lógica, não em observações experimentais.

Os limites de engenharia dão direção e eficiência à prática. Dentro das fronteiras físicas conhecidas, é possível otimizar várias dimensões e encontrar a melhor solução de engenharia. Um DVD que usa luz azul no lugar da vermelha, por exemplo, aproveita o comprimento de onda menor para aumentar a capacidade. A evolução de 2G a 6G também não ultrapassou o limite teórico de capacidade de canal definido por Shannon para uma dada largura de banda e relação sinal-ruído. Cada geração faz otimizações de engenharia no espectro, na codificação e modulação, na arquitetura da rede e em outros aspectos. A lei de Moore continua se manifestando. À medida que nos aproximamos dos limites físicos do silício, ainda vemos ganhos por meio de técnicas de encapsulamento, como empilhamento 3D, e de melhorias arquiteturais, como SoCs e computação heterogênea.

Os limites da experiência mostram que se trata de um jogo infinito. A experiência interage com as fronteiras. Necessidades, expectativas e imaginação humanas continuam evoluindo. Por mais que a tecnologia avance, nunca se esgotarão as melhorias de experiência em torno dos momentos da verdade, ou MOT, e dos fatores humanos. Assim, não existe um ponto do desenvolvimento tecnológico a partir do qual determinada otimização deixe definitivamente de ser necessária.

***

Li um livro cujo título em chinês significa “O caixa é rei”. Receita é vaidade, lucro é sensatez, mas o caixa é rei. Isso vale especialmente para o período atual, em que o crescimento do mercado é limitado e a eficiência domina. A competição já não é apenas expandir a escala e buscar crescimento, mas explorar a eficiência em profundidade.

O livro usa o controle do peso como analogia para a lógica de priorizar o caixa.

1. Usar um prato menor. Ser econômico e manter os custos operacionais dentro de um limite razoável de recursos. A lei de Parkinson diz que a demanda por algo cresce junto com a oferta. É por isso que ampliar ruas para reduzir congestionamentos nunca resolve definitivamente o problema: sempre aparecem mais motoristas para ocupar as novas faixas.
2. Comer vegetais antes dos carboidratos. Reescrever a fórmula contábil clássica “receita − despesas = lucro” como “receita − lucro = despesas”. Primeiro separar o lucro; depois decidir como gastar o restante. A base é o efeito de primazia.
3. Eliminar a tentação e esconder o que não deve ser consumido. Colocar o lucro reservado, a remuneração dos sócios e o dinheiro dos impostos numa conta separada, de preferência com acesso pouco conveniente.
4. Comer menos, mais vezes, para suavizar os altos e baixos. Consultar o saldo bancário duas vezes por mês e avaliar o negócio a partir do caixa disponível: a forma mais simples de contabilidade baseada no saldo do banco.

Isso me lembra a reformulação do despertador no gerenciamento de sono da Apple. Não lembro em qual versão do iOS começou. Normalmente, configurar um despertador é pensar em que hora acordar. O despertador de sono da Apple faz o usuário pensar primeiro na duração desejada do sono e ajustar, a partir dela, os horários de deitar e levantar. É uma mudança de conceito refletida no design do produto. A ideia de lucro primeiro deveria ter uma expressão semelhante no nosso pequeno aplicativo de registros financeiros.

***

A ampliação do uso do checkout em painel parcialmente sobreposto, depois da refatoração, ficou muito tempo sem solução. Agora chegou o momento de enfrentar o problema diretamente. Diante de uma questão que vem desgastando a determinação da equipe há quase um ano, tenho duas opções: resolvê-la ou liderar pessoas para resolvê-la. Pensando no que se espera de um gestor competente, acredito que a organização prefira a segunda. Para conduzir esse esforço, preciso esclarecer, nesta ordem, mentalidade, pessoas, objetivo e estratégia. Primeiro, reconstruir o quadro mental. Diante do mesmo desafio, é preciso adotar uma nova atitude, uma nova disposição e transmiti-la à equipe.

Por coincidência, encontrei o livro *Reframe Your Brain*. Reenquadrar é estabelecer um novo quadro e interpretar ativamente a realidade como uma história mais útil para si. É reprogramar o cérebro, como um chip FPGA. A psicologia tem um conceito semelhante, a reestruturação cognitiva. Diante de uma situação, experiência, pensamento ou emoção, você identifica como a interpreta, questiona essa visão e adota outra. Uma dificuldade pode virar um desafio; o desafio, uma aventura; e a aventura, um jogo.

O livro apresenta muitas técnicas. Uma das mais importantes é transformar a postura passiva em ativa. Lembro que Jerry me disse algo parecido alguns anos atrás: passar de “o que querem que eu faça” para “o que eu quero fazer”. Indo além, passar do que quero fazer, *want to*, para o que decido fazer, *decide to*. Decidir é uma atitude plenamente ativa, um compromisso consigo mesmo. A vontade pode desaparecer quando as condições mudam. Mas, ao decidir fazer algo, você procura todos os meios para conseguir, sem deixar que nada o impeça.

Essa reconstrução mental seria apenas uma autoajuda baseada em se declarar vencedor na própria cabeça? É como comparar marketing e esquema de pirâmide: na superfície, ambos vendem coisas; a diferença essencial está em quem produz valor final. O importante no novo enquadramento não é tanto se ele está correto, mas se funciona. Algumas formulações podem estar erradas, mas ser úteis para a pessoa.

***

Na semana passada, num caso de integração ao checkout, as limitações do contêiner da plataforma obrigaram a equipe de negócio a mudar de tipo de produto de pagamento, com um custo alto de comunicação. Aproveitamos para revisar o impacto das mudanças de contêiner sobre o negócio ao longo do tempo. Ao organizar a cronologia, os problemas centrais apareceram. Como diz a assinatura de tiange, devemos “evitar, tanto quanto possível, tornar os objetos vagos, simplificar demais as normas e mecanizar as ações durante a padronização”. Para mim, tornar os objetos vagos é o problema mais evidente. Serviços financeiros talvez sejam o maior cliente dos contêineres padronizados. Ainda assim, nas muitas decisões técnicas do passado, nunca vi uma iniciativa de entrevistar nossos colegas da linha de frente. Um desenho pragmático exige entrar no negócio e entender sua realidade.

Produtos técnicos e padrões promovidos por uma plataforma costumam cobrir bem 90% dos cenários. O mais difícil é que os 10% restantes, os casos de cauda longa, geralmente decorrem do que os projetistas “não sabiam”. O negócio precisa compensar as falhas de desenho com perda de experiência ou custos adicionais. São justamente esses últimos 10% que determinam nossa avaliação do trabalho da plataforma. Numa jornada de cem unidades, as primeiras noventa representam apenas metade do esforço. Isso lembra a teoria Seis Sigma no controle de qualidade: para alcançar resultados de alto nível, a capacidade do processo deve chegar a seis desvios-padrão. É preciso eliminar os últimos defeitos de desenho, difíceis de perceber. A atenção aos casos limites e sua resolução trazem os ganhos significativos de qualidade ou vantagem competitiva.

Essa é uma lição para nós também, especialmente nos trabalhos de padronização e governança.