Aula 4: Dimensões Humanas, Sociais e Éticas da Engenharia de Software
Computação e Sociedade
1 Um Sistema Quebrado por Comunicação, Não por Código
As Aulas 1 a 3 desta disciplina trataram a responsabilidade como algo que recai sobre um profissional individual: seguir ou não um código de conduta (Aula 3), reconhecer ou não os atores afetados por um sistema (Aula 1), avaliar ou não as consequências de uma decisão à luz de uma teoria ética (Aula 2). Hoje mudamos de nível. A pergunta não é mais “o que um profissional individual deveria fazer” — é “o que a própria estrutura de como um time se organiza produz, independentemente da boa vontade de qualquer pessoa dentro dele”.
Vale reativar rapidamente o mapa de atores da Aula 1: todo sistema de software tem, por trás, um conjunto de pessoas e grupos que o constroem, mantêm, usam e são afetados por ele — e as relações entre esses atores (quem fala com quem, quem decide o quê) já fazem parte do sistema sociotécnico, não são um detalhe de “gestão de projeto” alheio à engenharia propriamente dita. Esta aula mostra dois mecanismos concretos pelos quais essa estrutura social deixa uma marca direta e previsível no artefato técnico final — e fecha mostrando como traduzir um compromisso ético/social abstrato em algo concreto no código e no processo.
- Por que a arquitetura de um sistema tende a copiar o organograma de quem o construiu?
- Levantar requisitos é um ato neutro de “descobrir o que o cliente quer”, ou um processo social com voz e poder desiguais entre quem participa?
- Como um compromisso ético ou social abstrato (ex.: acessibilidade, privacidade) se transforma em algo concreto no código e no processo de desenvolvimento?
- Que decisões de processo — quem participa, como decisões são revisadas — mudam o resultado técnico final, não só o resultado organizacional?
- Toda fricção que o usuário sente contra um sistema é um acidente estrutural — ou às vezes é uma escolha deliberada, otimizada contra o próprio usuário?
Um problema motivador concreto, para tirar tudo isso do abstrato, extraído do próprio artigo que batizou o fenômeno central de hoje — Mel Conway, programador e pesquisador, publicou em 1968 um pequeno artigo com dois exemplos que continuam sendo citados até hoje:
“Uma organização de pesquisa contratada tinha oito pessoas encarregadas de produzir um compilador de COBOL e um de ALGOL. Depois de estimativas iniciais de dificuldade e tempo, cinco pessoas foram alocadas à tarefa do COBOL e três à tarefa do ALGOL. O compilador de COBOL resultante rodava em cinco fases; o compilador de ALGOL rodava em três.” (tradução livre, Conway, 1968, p. 31)
“Duas forças militares foram instruídas por seu Comandante-em-Chefe a desenvolver um sistema de armas comum, que atendesse às necessidades de ambas. Depois de grande esforço, produziram uma cópia de seu organograma.” (tradução livre, Conway, 1968, p. 31)
Repare no primeiro exemplo: o número de fases do compilador é idêntico ao número de pessoas alocadas para construí-lo — cinco pessoas, cinco fases; três pessoas, três fases. Nenhuma especificação técnica pediu isso. Nenhuma “melhor prática” de compiladores exige que o número de fases coincida com o tamanho do subgrupo que o constrói. E, no segundo exemplo, duas organizações que deveriam produzir um sistema de armas conjunto produziram, em vez disso, uma réplica da própria divisão institucional entre elas. Isso não parece coincidência — e não é: é a manifestação concreta de um fenômeno que vamos formalizar no Bloco 3.
2 O Mapa de Papéis da Indústria
Antes de formalizar a Lei de Conway, vale tornar concreto quem, de fato, participa da construção de um sistema de software real — porque “a organização” do Bloco 1 não é uma abstração, é um conjunto real de papéis com interesses, informações e poder de decisão diferentes entre si.
Essa divisão em papéis não é burocracia arbitrária: cada papel exige um tipo de raciocínio genuinamente diferente, que raramente cabe bem numa única cabeça ao mesmo tempo. Priorizar entre pedidos concorrentes (PM) é um raciocínio de custo-benefício de negócio; desenhar um fluxo de tela sem ambiguidade (UX) é um raciocínio sobre percepção e erro humano; decidir uma estrutura de dados (Dev) é um raciocínio sobre corretude e desempenho; prever o que quebra sob carga (SRE) é um raciocínio sobre falha e escala. Uma equipe grande demais para uma só pessoa dominar todos esses raciocínios simultaneamente se especializa — e a especialização, uma vez que existe, é exatamente o tipo de fronteira de comunicação que a Lei de Conway vai formalizar no Bloco 3.
Um pedido “simples” de um usuário final — “eu queria poder cancelar um pedido depois de finalizado” — passa, tipicamente, por essa cadeia de papéis antes de virar uma linha de código, e cada papel produz um artefato concreto e específico, não só uma opinião:
| Papel | O que faz com o pedido | Artefato que produz |
|---|---|---|
| Usuário final | Formula o pedido em linguagem cotidiana, sem saber o que é tecnicamente viável | Um relato informal (ticket de suporte, comentário, reclamação) |
| PM / PO (Gerente/Proprietário de Produto) | Traduz o pedido em uma “necessidade de negócio”, priorizando-o (ou não) frente a outros pedidos | Um item de backlog priorizado, com justificativa de negócio |
| UX (Design de Experiência) | Traduz a necessidade em uma interação concreta — telas, fluxos, textos de erro | Wireframes/protótipos e um fluxo de tela passo a passo |
| Dev (Desenvolvedor) | Traduz o fluxo de UX em código, decidindo estruturas de dados e integrações | Código-fonte e as decisões de modelagem de dados que o sustentam |
| QA (Garantia de Qualidade) | Traduz o comportamento esperado em casos de teste, revelando o que “cancelar” de fato significa em casos-limite (pedido já enviado? já pago?) | Um plano de testes e a lista de casos-limite descobertos |
| SRE / Operações | Traduz a funcionalidade em requisitos de confiabilidade em produção — o que acontece se o cancelamento falhar sob alta carga? | Métricas de alerta e um plano de contingência para falha em produção |
| Stakeholders de negócio | Podem vetar ou alterar o pedido por razões que nada têm a ver com o usuário (custo, política comercial, contrato com fornecedor) | Uma decisão de aprovação/veto, geralmente sem registro formal do motivo |
Três desses artefatos têm nome técnico específico, que vale nomear antes de seguir: um ticket é o registro de um único pedido ou problema, aberto num sistema de atendimento (ex.: um formulário de suporte), geralmente com um número de identificação que permite rastreá-lo até ser resolvido. Um item de backlog é uma entrada numa lista viva e priorizada de tudo que a equipe de produto poderia construir — um pedido só sai do papel quando sai do backlog para a fila de trabalho ativo da equipe (o sprint, no jargão ágil). Um wireframe é um desenho esquemático de tela: mostra onde cada elemento (botão, campo de texto, mensagem de erro) fica, sem se preocupar ainda com cor ou estilo visual definitivo; um protótipo vai um passo além, permitindo clicar e navegar entre as telas para simular o uso real, antes de existir qualquer linha de código.
Cada passagem nessa tabela é uma tradução — e toda tradução perde ou adiciona algo. Um PM que prioriza “cancelamento” mais baixo do que o usuário gostaria já mudou o resultado antes de qualquer código existir. Um UX que desenha um fluxo de cancelamento sem considerar o que acontece com um pedido já em transporte já tomou uma decisão que o usuário nunca articulou explicitamente. Um QA que só testa o caminho feliz (cancelar antes do pagamento) deixa passar um requisito que existia desde o início — “cancelar depois de pago” —, mas que se perdeu ao longo da cadeia. Nada disso exige más intenções de nenhum papel individual: é uma propriedade estrutural de qualquer cadeia de tradução com mais de um elo.
Isso já entrega a intuição central: um “requisito” não é um dado bruto que existe pronto, esperando para ser “descoberto” — é o produto final de uma cadeia de pessoas, cada uma vendo e traduzindo apenas parte do quadro. Falta só nomear os dois mecanismos formais que os Blocos 3 e 4 desenvolvem: por que a arquitetura do sistema também acaba copiando essa mesma estrutura de papéis (Bloco 3), e por que a etapa de “descobrir o que o cliente quer” já é, ela mesma, um processo social com voz desigual entre quem participa (Bloco 4).
3 A Lei de Conway: Premissas e Passo a Passo
Voltamos ao exemplo do Bloco 1 — o compilador com cinco fases e três fases — agora para formalizar por que ele não é coincidência. Conway (1968) chega a essa conclusão a partir de duas premissas, e um raciocínio passo a passo que liga ambas ao resultado final.
Premissa (a): construir uma interface entre duas partes de um sistema exige comunicação entre quem constrói cada parte. Se o Módulo A precisa chamar uma função do Módulo B, alguém que constrói A precisa saber, com precisão, o que B espera receber e o que B devolve — isso só se resolve com comunicação entre as duas partes.
Premissa (b): organizações minimizam custo de comunicação alinhando equipes a subsistemas. Comunicar-se tem custo — tempo, atenção, reuniões, documentação. Uma organização racional tende a reduzir esse custo agrupando, na mesma equipe, quem precisa se comunicar com mais frequência.
Conway (1968, p. 29) formula a consequência dessas duas premissas de forma direta:
“Dada qualquer organização de equipe de design, existe uma classe de alternativas de design que não pode ser efetivamente perseguida por essa organização, porque os caminhos de comunicação necessários não existem. Portanto, não existe uma coisa como um grupo de design que seja, ao mesmo tempo, organizado e imparcial.” (tradução livre)
O passo a passo, a partir daí:
- Se dois módulos interagem, mas os times que os constroem não se falam, a interface entre eles tende a ficar malfeita ou inconsistente — ninguém tem a informação completa dos dois lados para projetá-la bem.
- Para reduzir o custo de comunicação, a organização — de forma consciente ou não — tende a alinhar a fronteira dos times à fronteira “natural” dos módulos que ela já antecipa.
- Resultado: a arquitetura do sistema, no fim, espelha o organograma — não por design técnico deliberado, mas por pressão estrutural de comunicação. É exatamente o que aconteceu no exemplo do compilador: a divisão de pessoas (5+3) precedeu e causou a divisão de fases (5+3), não o contrário.
Conway (1968, p. 31) resume a tese central do artigo assim:
“A tese básica deste artigo é que organizações que projetam sistemas (no sentido amplo usado aqui) são obrigadas a produzir projetos que são cópias das estruturas de comunicação dessas organizações. […] Principalmente, encontramos um critério para a estruturação de organizações de design: um esforço de design deve ser organizado de acordo com a necessidade de comunicação.” (tradução livre)
O diagrama acima redesenha a ideia central do artigo (não é uma reprodução literal de nenhuma figura de Conway): quando duas equipes se comunicam, a interface entre os módulos que elas constroem tende a ficar bem definida; quando não se comunicam, a interface tende a ficar malformada ou inconsistente — porque nenhuma das duas equipes tem, por si só, a informação completa dos dois lados.
Implicação prática — a Manobra Inversa de Conway: se a arquitetura tende a seguir o organograma, então, para mudar a arquitetura de um sistema de forma duradoura, muitas vezes é preciso mudar primeiro a estrutura do time, não só o código. Reescrever um monólito em microsserviços sem jamais tocar em como as equipes estão organizadas tende a falhar: a pressão estrutural de comunicação (premissa b) volta a empurrar a arquitetura de volta ao formato antigo, porque as pessoas que precisam se falar seguem sendo as mesmas, na mesma configuração.
Se a Lei de Conway está certa — a arquitetura tende a copiar a estrutura de comunicação de quem constrói —, o que isso implica sobre tentar consertar um sistema mal-arquitetado só reescrevendo código, sem tocar em como as equipes estão organizadas?
Dica: pense na Manobra Inversa de Conway — o que precisaria mudar primeiro para que uma nova arquitetura se sustentasse, e não fosse revertida pela própria pressão estrutural da organização?
- □ Se as organizações não precisassem, por hipótese, minimizar custo de comunicação entre subsistemas (comunicação fosse grátis e instantânea, sem nenhum custo cognitivo ou de coordenação), a pressão estrutural para a arquitetura do sistema espelhar o organograma desapareceria, mesmo que as duas partes do sistema ainda precisassem trocar informação para funcionar.
- □ No limite em que uma organização tem uma única equipe indivisa construindo o sistema inteiro (nenhuma subdivisão), a Lei de Conway deixaria de fazer qualquer previsão sobre a arquitetura resultante, pois não há mais nenhum organograma interno a ser espelhado.
- □ A Manobra Inversa de Conway sugere que, para migrar um sistema monolítico para uma arquitetura de microsserviços de forma duradoura, bastaria reescrever o código em módulos separados, sem alterar a estrutura das equipes que o mantêm.
- □ Como a Lei de Conway afirma que a arquitetura tende a copiar a estrutura de comunicação organizacional, isso implica que uma organização bem comunicada entre todas as suas equipes produzirá necessariamente uma arquitetura de software tecnicamente superior.
5 Quando a Assimetria É Deliberada: Dark Patterns
O Bloco 4 mostrou um mecanismo de exclusão sem intenção explícita: um requisito fica de fora da especificação porque quem o carrega nunca teve acesso ao processo — ninguém, individualmente, decidiu excluí-lo. Mas nem toda fricção que o usuário sente contra um sistema nasce de uma ausência estrutural. Às vezes ela é o resultado exato e deliberado de uma decisão de design — tomada, com frequência, pelo próprio papel de “Stakeholders de negócio” da tabela do Bloco 2, que pode “vetar ou alterar o pedido por razões que nada têm a ver com o usuário”. Aqui essa célula da tabela, até agora abstrata, ganha um mecanismo concreto e um nome técnico.
Você provavelmente já sentiu isso na pele: assinar um serviço digital costuma levar um clique; cancelar o mesmo serviço costuma exigir navegar por várias telas de “tem certeza?”, ofertas de desconto de última hora, e um botão de cancelamento visualmente discreto — como quem já tentou cancelar uma assinatura de transporte por aplicativo ou streaming conhece bem. Essa assimetria entre “entrar” e “sair” quase nunca é acidente de design malfeito: com frequência, é uma escolha deliberada, otimizada para uma métrica de negócio (retenção, receita recorrente) às custas do tempo e da paciência do usuário.
A taxonomia usada abaixo (Insistência, Obstrução, Sonegação, Interferência de Interface, Ação Forçada) segue Gray, Kou, Battles, Hoggatt & Toombs (2018), “The Dark (Patterns) Side of UX Design” (CHI ’18) — um artigo acadêmico revisado por pares. O texto integral do artigo está atrás do paywall da ACM Digital Library, e nenhuma cópia de acesso aberto legítima foi encontrada durante a pesquisa desta sessão; os nomes e descrições das categorias abaixo vêm de coberturas secundárias confiáveis sobre o artigo (não é citação literal verificada linha a linha, mesmo padrão de sinalização já usado no Bloco 2). Já o caso Amazon/FTC, discutido depois da tabela, tem verificação mais forte: a frase “quatro páginas, seis cliques, quinze opções” e o valor do acordo (US$ 2,5 bilhões) aparecem, de forma consistente e independente, em múltiplas coberturas jornalísticas e jurídicas da denúncia oficial; o PDF da denúncia em si, hospedado em ftc.gov, bloqueou o acesso automatizado durante esta pesquisa.
| Categoria (Gray et al., 2018) | O que faz | Exemplo típico |
|---|---|---|
| Insistência (Nagging) | Interrompe repetidamente o que o usuário está tentando fazer | Pop-up pedindo para avaliar o app ou ativar notificações, que reaparece mesmo depois de recusado |
| Obstrução (Obstruction) | Torna deliberadamente mais difícil um processo que o usuário já decidiu completar | O padrão “Motel de Baratas” (Roach Motel): fácil entrar, difícil encontrar a saída — o caso Amazon abaixo é exatamente este |
| Sonegação (Sneaking) | Esconde ou omite informação relevante até o último momento possível | Taxa extra revelada só na última tela do checkout, depois que o usuário já investiu tempo no processo |
| Interferência de Interface (Interface Interference) | Manipula a hierarquia visual da tela para empurrar a escolha da empresa | Botão “Aceitar todos os cookies” grande e colorido; “Rejeitar” cinza, pequeno, ou escondido atrás de outro clique |
| Ação Forçada (Forced Action) | Exige uma ação sem relação direta com o que o usuário queria, como pré-condição | Obrigar criação de conta e compartilhamento de contatos de celular só para usar uma função básica do app |
O caso mais documentado e verificável de Obstrução dos últimos anos veio de um processo judicial, não de um artigo acadêmico. Em 2023, a Federal Trade Commission (FTC) — a agência de proteção ao consumidor dos EUA — processou a Amazon alegando que inscrever-se na assinatura Prime era possível em um ou dois cliques, enquanto cancelar exigia navegar por um fluxo interno que a própria empresa batizara de “Iliad” (referência à Ilíada, a longa e árdua guerra de Troia): um processo, segundo a denúncia, de “quatro páginas, seis cliques e quinze opções” (tradução livre), pontuado por telas intermediárias — avisos sobre benefícios perdidos, descontos de última hora — desenhadas para fazer o cliente desistir do cancelamento no meio do caminho. O caso terminou em 2025 com um acordo de US$ 2,5 bilhões, a maior penalidade civil já obtida pela agência por violação de uma norma regulatória sobre assinaturas.
O caso Amazon deixa claro por que “dark pattern” não é sinônimo de “design ruim” ou de qualquer tela de confirmação: uma única tela perguntando “tem certeza que quer cancelar?” pode ser, legitimamente, uma proteção contra cliques acidentais. O que caracteriza o padrão é a assimetria deliberada — o mesmo time de produto que faz a inscrição levar um clique é, tecnicamente, perfeitamente capaz de fazer o cancelamento levar um clique também; a diferença de fricção entre os dois fluxos não é limitação técnica, é escolha de design alinhada a uma métrica de negócio específica (nesse caso, taxa de retenção mensal da assinatura).
Isso fecha o elo com os Blocos 2 a 4 de um jeito diferente dos anteriores: lá, o resultado indesejado nascia de ausência estrutural (nenhum papel específico responsável, nenhuma voz convidada à mesa). Aqui, o resultado indesejado nasce de presença deliberada — alguém, dentro da cadeia de papéis do Bloco 2, decidiu ativamente otimizar para uma métrica que não é o bem-estar do usuário. Se a fricção pode ser projetada deliberadamente contra o usuário, uma pergunta fica em aberto: o mesmo maquinário de tradução — de intenção abstrata a comportamento concreto do sistema — pode ser apontado na direção contrária, a favor do usuário? É exatamente essa pergunta que o Bloco 6 responde.
5.1 Pergunta
Se a mesma equipe de engenharia que constrói o fluxo de inscrição também é, tecnicamente, capaz de construir um fluxo de cancelamento igualmente simples, o que explica a diferença de fricção entre os dois fluxos, se não é limitação técnica?
Dica: volte à tabela de papéis do Bloco 2 — qual papel específico tem o poder de “vetar ou alterar” um fluxo “por razões que nada têm a ver com o usuário”?
- □ Se a métrica interna usada para avaliar o sucesso do fluxo de cancelamento fosse “tempo até a resolução do pedido do usuário”, em vez de “taxa de retenção mensal da assinatura”, o incentivo estrutural para alongar deliberadamente esse fluxo, como no caso do “Iliad Flow”, deixaria de existir.
- □ Como qualquer tela de confirmação antes de cancelar uma assinatura introduz fricção deliberada no fluxo, toda tela desse tipo é, por definição, um exemplo da categoria Obstrução de dark pattern.
- □ A mesma lógica de assimetria estrutural entre “entrar em um clique, sair só com muito esforço” se aplicaria a um contrato de aluguel que permite assinatura digital instantânea, mas exige carta registrada em cartório para a rescisão.
- □ Como o processo da FTC contra a Amazon terminou em um acordo bilionário, conclui-se que toda decisão de design voltada a aumentar a taxa de retenção de um produto é, necessariamente, um dark pattern ilegal.
6 Da Responsabilidade Social ao Artefato de Engenharia Concreto
Os Blocos 3 a 5 mostraram três mecanismos pelos quais a estrutura social de construir software deixa marca no resultado técnico — por ausência (Blocos 3 e 4) ou por presença deliberada (Bloco 5) — sempre de forma indesejada para o usuário. Este bloco fecha o “gap” na direção contrária: como transformar deliberadamente um compromisso ético ou social abstrato em algo concreto, que sobrevive no tempo em vez de depender da boa memória de quem o propôs — o mesmo maquinário de tradução do Bloco 5, agora a favor do usuário, não contra ele.
O método que estrutura essa tradução — usado, por exemplo, quando uma equipe decide que “o sistema deve ser acessível a usuários com baixa visão” — vem de Marc Steen (2022), no capítulo sobre Value Sensitive Design (Design Sensível a Valores, VSD):
“Value Sensitive Design (VSD) coloca valores no centro do palco. É um método que permite às pessoas discutir, explorar e negociar valores explicitamente, com cuidado e sistematicidade. O VSD visa permitir que diversos interessados expressem seus valores e os combinem produtivamente durante o processo de inovação.” (tradução livre, p. 154)
O VSD completo tem três tipos de investigação, combinadas de forma iterativa — não uma vez só, no início, e depois nunca mais:
“Uma versão completa do VSD consiste em três tipos de investigação, que podem ser combinadas em um processo iterativo: investigações empíricas, conceituais e tecnológicas. Investigações empíricas envolvem estudar os valores em jogo em um projeto específico, por exemplo, conduzindo entrevistas ou workshops com os interessados relevantes. […] Essas investigações resultam em requisitos (tentativos) para o sistema que está sendo desenvolvido.” (tradução livre, pp. 155–156)
Repare na última frase: as investigações resultam em requisitos — não em princípios soltos. É exatamente esse elo — de valor investigado empiricamente a requisito concreto — que este bloco formaliza em três passos adicionais, levando o valor um passo além do requisito, até o código e o processo em si:
- Requisito Não-Funcional (NFR) testável. O compromisso “acessível a usuários com baixa visão” se torna, por exemplo, “todo texto da interface deve ter contraste mínimo de 4.5:1 em relação ao fundo” — uma condição que se pode verificar automaticamente, sim ou não, em vez de ficar em um nível de intenção vaga.
- Decisão de Arquitetura (ADR) registrada. Um Architecture Decision Record documenta a escolha concreta que implementa o NFR — por exemplo, “adotar a biblioteca X de componentes de interface, que já garante o contraste mínimo por padrão” — e, crucialmente, documenta por que essa escolha foi feita, preservando o raciocínio para quem vier depois.
- Porta de processo (gate de CI). Um checklist de revisão de PR ou, melhor ainda, um teste automatizado no pipeline de integração contínua que bloqueia o deploy se o contraste mínimo for violado — sem isso, nada impede que uma mudança futura, feita por alguém que nunca leu a ADR, quebre silenciosamente o compromisso original.
A caixa vermelha do diagrama reconecta deliberadamente com o Bloco 3: se não existe nenhum time ou pessoa responsável por essa fronteira específica, o requisito de acessibilidade tende a “cair no buraco” entre equipes — exatamente do mesmo jeito que uma interface técnica sem comunicação cai, na Lei de Conway. Um NFR bem escrito e uma ADR bem documentada não bastam por si só; sem um gate que impeça automaticamente a regressão, e sem um dono claro dessa fronteira, o compromisso original sobrevive só enquanto alguém se lembrar dele.
Vale uma ressalva importante, coerente com a regra de precisão de conteúdo desta disciplina: transformar um valor em NFR testável é uma simplificação necessária, não uma tradução perfeita. “Acessibilidade” é mais rico do que “contraste 4.5:1” — a métrica captura uma parte operacionalizável do valor, não o valor inteiro. É por isso que o VSD insiste em investigações iterativas, não um checklist único: o NFR de hoje pode precisar ser revisitado quando o contexto (ou o próprio entendimento do valor) mudar.
6.1 Pergunta
Uma equipe decide, em uma reunião, que “o sistema deve ser acessível a usuários com baixa visão”. Seis meses depois, uma nova funcionalidade quebra essa promessa sem que ninguém perceba, até que reclamações cheguem. O que, entre a reunião e o código, faltou para que isso não acontecesse?
Dica: pense na diferença entre “documentar uma decisão” (ADR) e “impedir automaticamente que ela seja violada” (gate de CI) — e no que cada um resolve, ou não, sozinho.
- □ Se um compromisso ético fosse traduzido diretamente em uma Decisão de Arquitetura (ADR), sem antes passar por um Requisito Não-Funcional (NFR) testável, ainda seria possível, a partir só da ADR, construir automaticamente um gate de CI que impeça regressão desse compromisso.
- □ No limite em que um gate de CI testa uma condição tão frouxa que praticamente qualquer código passa por ele sem alteração de comportamento, esse gate ainda cumpriria, na prática, a função de “impedir regressão” descrita nesta aula.
- □ A cadeia de tradução (compromisso → NFR testável → decisão de arquitetura → porta de processo) se aplicaria a um compromisso corporativo de reduzir vieses discriminatórios em um sistema de contratação, na forma de um NFR sobre taxas de erro por subgrupo, uma ADR sobre qual métrica de justiça adotar, e um gate de CI que bloqueia deploys que piorem essa métrica.
- □ Como um Requisito Não-Funcional testável é, por definição, mensurável, isso significa que qualquer compromisso ético que não possa ser perfeitamente quantificado deve ser descartado como requisito de engenharia.
7 Fechamento e Ponte para a Aula 6
Voltamos ao roteiro que abriu a aula, uma frase de resposta para cada pergunta:
- Por que a arquitetura tende a copiar o organograma? Porque construir uma interface exige comunicação, e organizações minimizam custo de comunicação alinhando equipes a subsistemas — a arquitetura é um efeito colateral estrutural dessa pressão, não um acidente nem, necessariamente, um projeto técnico deliberado (Lei de Conway, Bloco 3).
- Elicitar requisitos é neutro, ou social? É social: cada etapa do processo clássico envolve uma decisão sobre quem tem voz, e dados — assim como requisitos — nunca são o produto de uma extração neutra, mas de relações sociais desiguais que precedem qualquer coleta (Data Feminism, Bloco 4).
- Como um compromisso ético abstrato vira algo concreto? Passando por três traduções sucessivas — Requisito Não-Funcional testável, Decisão de Arquitetura registrada, porta de processo (gate de CI) — cada uma reduzindo a distância entre a intenção e o comportamento real do sistema em produção (Bloco 6).
- Que decisões de processo mudam o resultado técnico? As duas mostradas hoje — como o time se organiza, e quem participa da elicitação — mas também, implicitamente, quem é o “dono” de uma fronteira entre módulos ou entre requisitos: sem esse dono, tanto a interface técnica (Bloco 3) quanto o compromisso ético (Bloco 6) tendem a “cair no buraco” entre equipes.
- Toda fricção contra o usuário é acidente estrutural, ou às vezes é deliberada? As duas coisas acontecem, por mecanismos diferentes: às vezes é ausência estrutural (Blocos 3 e 4, ninguém decidiu excluir); às vezes é presença deliberada (Bloco 5, dark patterns — alguém escolheu otimizar contra o usuário). O caso Amazon/FTC mostra a segunda forma em escala real, com consequência regulatória.
O que fica em aberto: hoje vimos que decisões de processo e organização têm consequência técnica e social — mas essa consequência também é material. A Aula 6 continua a Parte 2 do curso, “Computação e Seus Impactos”, mostrando que decisões de arquitetura — quantos serviços, onde rodam, como escalam — têm também um custo ambiental e energético real, não só organizacional. A pergunta que atravessa a transição: se decisões “só de processo” já mudam o resultado técnico do jeito que vimos hoje, o que mais, além do organograma e da elicitação, deixa marca concreta num sistema sem que ninguém tenha “decidido” isso explicitamente no código?
Esta aula mostrou três mecanismos — Lei de Conway, elicitação de requisitos, e dark patterns — pelos quais decisões de processo e organização produzem consequências técnicas concretas. Que outro tipo de decisão “não técnica” você imagina que também deixa marca direta no sistema final, mesmo sem nenhuma linha de código específica prevendo isso?
Dica: pense em decisões sobre onde a equipe está localizada, em que fuso horário, ou sobre como o orçamento é dividido entre módulos — nenhuma delas é uma decisão “de código”, mas todas moldam o resultado técnico.
- □ Se a elicitação de requisitos fosse, de fato, um processo perfeitamente neutro de “descobrir o que o cliente quer” (sem nenhuma assimetria de poder envolvida), a conexão entre Data Feminism e Engenharia de Requisitos apresentada nesta aula perderia sua motivação central.
- □ No limite em que uma organização tivesse exatamente um time responsável por cada módulo do sistema E por cada fronteira/requisito entre módulos (nenhuma lacuna de responsabilidade), o problema de um requisito “cair no buraco” entre equipes, descrito no Bloco 6, deixaria de ocorrer pelo mecanismo discutido nesta aula.
- □ A tese de que decisões de processo e organização têm consequência técnica, apresentada nesta aula sobre Engenharia de Software, se estenderia, pela mesma lógica, ao argumento da Aula 6 de que decisões de arquitetura (quantos serviços, onde rodam) têm consequência material e ambiental — em ambos os casos, uma escolha aparentemente “só de processo/design” tem efeito concreto fora do código em si.
- □ Como esta aula mostrou três mecanismos pelos quais a prática social de construir software afeta o resultado técnico, conclui-se que qualquer falha técnica de um sistema deve ser explicada primariamente por causas organizacionais, nunca por erros técnicos comuns (bugs, escolhas de algoritmo etc.).