Aula 4: Dimensões Humanas, Sociais e Éticas da Engenharia de Software

Computação e Sociedade

Marcos M. Raimundo — Instituto de Computação, UNICAMP

2026-08-30

Um Sistema Quebrado por Comunicação, Não por Código

Da Responsabilidade Individual à Estrutura

Aulas 1–3: responsabilidade recai sobre o profissional individual — seguir um código (Aula 3), reconhecer atores (Aula 1), avaliar consequências (Aula 2).

Hoje: e quando o problema não está em nenhuma decisão individual, mas na própria estrutura de como o time se organiza para construir o sistema?

Dica

Relembrando a Aula 1: o mapa de atores já mostrava que quem fala com quem, e quem decide o quê, faz parte do sistema sociotécnico — não é um detalhe de gestão de projeto alheio à engenharia.

O Roteiro de Hoje

1. Por que a arquitetura de um sistema tende a copiar o organograma de quem o construiu?

2. Levantar requisitos é neutro, ou um processo social com voz e poder desiguais?

3. Como um compromisso ético/social abstrato se transforma em algo concreto no código e no processo?

4. Que decisões de processo mudam o resultado técnico final, não só o organizacional?

5. Toda fricção contra o usuário é acidente estrutural, ou às vezes é deliberada?

O Compilador Que “Contou” as Pessoas

Conway (1968), p. 31 — tradução livre

“Oito pessoas foram encarregadas de produzir um compilador de COBOL e um de ALGOL. Cinco pessoas foram alocadas ao COBOL, três ao ALGOL. O compilador de COBOL resultante rodava em cinco fases; o de ALGOL, em três.”

Conway (1968), p. 31 — o segundo exemplo

“Duas forças militares foram instruídas a desenvolver um sistema de armas comum. Depois de grande esforço, produziram uma cópia de seu organograma.”

Repare: o número de fases do compilador é idêntico ao número de pessoas do subgrupo que o construiu. Nenhuma especificação técnica pediu isso. Coincidência? (Bloco 3 formaliza a resposta.)

Pergunta

Cinco pessoas, cinco fases: coincidência?

O compilador de COBOL, construído por cinco pessoas, saiu com cinco fases; o de ALGOL, construído por três pessoas, saiu com três fases. Isso foi coincidência, ou o número de pessoas alocadas causou o número de fases do software? Se causou, por qual mecanismo, já que nenhuma especificação técnica dizia “faça cinco fases”?

Dica: pense no que cada subequipe precisaria negociar com a outra para que as peças do compilador se encaixassem — e no que aconteceria com essa negociação se a divisão de tarefas fosse diferente.

• □ Se a organização tivesse alocado quatro pessoas para cada compilador (COBOL e ALGOL), em vez de cinco e três, o número de fases de cada compilador ainda teria sido determinado apenas pela dificuldade técnica intrínseca de cada linguagem, e não pela divisão de pessoas.
• □ Se uma única pessoa fosse responsável por construir os dois compiladores sozinha, o fenômeno de “o número de módulos copia o número de subequipes” deixaria de se manifestar da mesma forma, porque não haveria fronteira de comunicação interna a copiar.
• □ O mesmo padrão observado no caso do compilador se aplicaria, em princípio, a duas squads de um aplicativo de e-commerce — uma responsável pelo carrinho de compras, outra pelo checkout —, mesmo sem qualquer intenção deliberada de arquitetá-lo assim.
• □ Como as duas forças militares do segundo exemplo produziram “uma cópia do próprio organograma”, isso mostra que a estrutura organizacional sempre produz sistemas de pior qualidade do que uma equipe unificada produziria.

V/F — Cinco Pessoas, Cinco Fases: Resposta

Dica

• ✗ Falso — o próprio exemplo mostra o oposto: a divisão de pessoas, não só a dificuldade técnica, moldou o número de fases.
• ✔ Verdadeiro — sem subdivisão, não há fronteira de comunicação interna para o software copiar.
• ✔ Verdadeiro — é exatamente o tipo de transferência que a Lei de Conway prevê (formalizada no Bloco 3).
• ✗ Falso — o artigo fala de correspondência estrutural, não de qualidade superior ou inferior.

Retomando: o número de pessoas causou o número de fases — via a necessidade de comunicação (ou falta dela) entre subequipes. É exatamente isso que o Bloco 3 formaliza.

O Mapa de Papéis da Indústria

Quem Constrói um Sistema de Software Real?

A divisão em papéis não é burocracia: cada um exige um raciocínio diferente (negócio, percepção humana, corretude de código, falha em escala) — poucas pessoas dominam todos ao mesmo tempo.

Um pedido “simples” — “quero poder cancelar um pedido depois de finalizado” — passa por essa cadeia de papéis antes de virar código.

A Cadeia de Tradução de um Pedido

Usuário final → formula em linguagem cotidiana, sem saber o que é tecnicamente viável. Produz um ticket (registro do pedido, com número de rastreamento).

PM/PO → traduz em “necessidade de negócio”, prioriza frente a outros pedidos. Produz um item de backlog (lista viva e priorizada do que a equipe pode construir).

UX → traduz em telas, fluxos, textos de erro concretos. Produz wireframes (esboço de tela, sem estilo visual) e protótipos (já clicáveis, simulam o uso).

Dev → traduz o fluxo em código, estruturas de dados, integrações. Produz o código-fonte e as decisões de modelagem que o sustentam.

QA → traduz o comportamento esperado em casos de teste — revela casos-limite (pedido já pago? já enviado?). Produz um plano de testes.

SRE/Operações → traduz em requisitos de confiabilidade em produção. Produz métricas de alerta e um plano de contingência.

Stakeholders de negócio → podem vetar/alterar por custo ou política comercial, sem relação com o usuário. Produz uma decisão de aprovação/veto, geralmente sem registro formal do motivo.

Cada Passagem é uma Tradução

Um PM que prioriza “cancelamento” mais baixo do que o usuário gostaria já mudou o resultado antes de qualquer código existir.

Um QA que só testa o caminho feliz deixa passar um requisito que existia desde o início — “cancelar depois de pago” — mas que se perdeu ao longo da cadeia.

Dica

Nada disso exige más intenções de nenhum papel — é uma propriedade estrutural de qualquer cadeia de tradução com mais de um elo.

Requisito: Dado Bruto, ou Produto de uma Cadeia?

Um “requisito” não é um dado bruto esperando para ser “descoberto” — é o produto final de uma cadeia de pessoas, cada uma traduzindo só parte do quadro.

Falta nomear dois mecanismos formais:

• Bloco 3 — por que a arquitetura do sistema também acaba copiando essa mesma estrutura de papéis.
• Bloco 4 — por que “descobrir o que o cliente quer” já é, em si, um processo social com voz desigual entre quem participa.

Pergunta

O jogo do telefone dos requisitos

Se você entrevistasse cada pessoa na cadeia entre “o que o usuário pediu” e “o que virou código” — PM, UX, dev, QA, SRE — e perguntasse “o que o usuário quer”, você esperaria receber a mesma resposta de todos? Se as respostas divergissem, qual delas seria a “certa”?

Dica: pense em cada papel como um tradutor que só vê parte do quadro — e o que cada um adiciona, ou perde, ao traduzir para a etapa seguinte.

• □ Se um único papel (ex.: um profissional que acumula PM, dev, QA e UX) concentrasse todas as etapas entre o pedido do usuário e o código, o risco de um requisito “se perder” entre etapas desapareceria por completo.
• □ No limite em que existisse apenas uma única etapa entre o usuário final e o código (nenhum intermediário), a lógica de que “cada tradução perde ou adiciona algo” deixaria de ter qualquer aplicação, pois não haveria mais nenhuma tradução ocorrendo.
• □ A mesma lógica de “cada passagem é uma tradução que perde ou adiciona algo” se aplicaria a uma cadeia de atendimento médico em que o paciente relata o sintoma à recepção, a recepção resume para o enfermeiro, e o enfermeiro resume para o médico, antes de qualquer diagnóstico ser feito.
• □ Como cada papel entre o pedido do usuário e o código representa uma tradução com possível perda de informação, a conclusão correta é que sistemas de software deveriam sempre minimizar o número de papéis envolvidos, sem exceção, para reduzir esse risco.

V/F — o Jogo do Telefone: Resposta

Dica

• ✗ Falso — o risco de perda de informação diminui, mas não some: o ponto único de falha (viés e limites de uma só pessoa) permanece.
• ✔ Verdadeiro — sem tradução intermediária, não há mais o mecanismo de perda/adição de informação em jogo.
• ✔ Verdadeiro — mesma estrutura de tradução em cadeia, domínio diferente.
• ✗ Falso — cada papel especializado também agrega expertise; a lição é sobre custo de tradução, não que menos papéis seja sempre melhor.

Retomando: não existe resposta “mais certa” — cada papel vê e traduz parte real do quadro. O ganho de especialização tem um custo de tradução; a aula não recomenda eliminá-la, mas reconhecê-la.

A Lei de Conway: Premissas e Passo a Passo

Duas Premissas da Lei de Conway

(a) Construir uma interface entre duas partes de um sistema exige comunicação entre quem constrói cada parte.

(b) Organizações minimizam custo de comunicação alinhando equipes a subsistemas.

Conway (1968), p. 29

“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

1. Módulos que interagem, mas cujos times não se falam → interface malfeita/inconsistente.

2. Para reduzir custo de comunicação, a organização alinha a fronteira dos times à dos módulos.

3. Resultado: a arquitetura espelha o organograma — não por design deliberado, mas por pressão estrutural.

No compilador do Bloco 1: a divisão de pessoas (5+3) precedeu e causou a divisão de fases (5+3), não o contrário.

A Tese Central do Artigo

Conway (1968), p. 31

“Organizações que projetam sistemas são obrigadas a produzir projetos que são cópias das estruturas de comunicação dessas organizações.” (tradução livre)

Dica

Comunicação entre equipes → interface bem definida. Sem comunicação → interface inconsistente. (Redesenho da ideia de Conway, não reprodução literal de figura.)

A Manobra Inversa de Conway

Se a arquitetura tende a seguir o organograma, então, para mudar a arquitetura de forma duradoura, muitas vezes é preciso mudar primeiro a estrutura do time.

Aviso

Reescrever um monólito em microsserviços sem tocar na organização das equipes tende a falhar: a pressão de comunicação empurra a arquitetura de volta ao formato antigo — as pessoas que precisam se falar continuam as mesmas.

Pergunta

Consertar código, ou consertar organograma?

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.

V/F — Consertar Código, ou Organograma? Resposta

Dica

• ✔ Verdadeiro — remover a premissa (b) remove a pressão de espelhamento, mesmo que a premissa (a) — necessidade de comunicação — permaneça.
• ✔ Verdadeiro — sem subdivisão, não há organograma interno para o software copiar.
• ✗ Falso — é exatamente o oposto do que a manobra propõe: mudar a estrutura do time é o passo necessário, não opcional.
• ✗ Falso — a lei prevê correspondência estrutural, não qualidade técnica superior.

Retomando: reescrever código sem tocar na organização tende a falhar — a pressão estrutural (premissa b) empurra a arquitetura de volta, pois as pessoas que precisam se falar continuam as mesmas.

Elicitação de Requisitos como Processo Social

O Mecanismo Irmão: Requisitos

Bloco 3: a arquitetura copia a comunicação de quem constrói.

Este bloco: a etapa que decide o que vai ser construído — elicitação de requisitos — também não é neutra.

Aviso

Processo clássico de 4 etapas (Cap. 4 de Sommerville): conhecimento geral consolidado, sem citação literal verificada. A conexão com Data Feminism é análise nossa.

O Que Cada Etapa Faz, de Verdade

Elicitação: entrevistas, workshops com vários stakeholders juntos, observação etnográfica, protótipos descartáveis — não uma conversa única.

Análise/negociação: priorização estruturada (MoSCoW, Kano), matrizes de trade-off, “o que acontece se isto não for feito?”.

Especificação: casos de uso, histórias de usuário + critérios de aceite testáveis, requisitos numerados e rastreáveis.

Validação: revisões estruturadas do documento, walkthroughs passo a passo, protótipos de baixa fidelidade — não é testar código.

Dica

Só com o mecanismo real nomeado a pergunta social fica precisa: em cada uma dessas atividades, quem participa — e quem fica de fora?

As Quatro Etapas, Reinterpretadas

Etapa	Padrão	Decisão social escondida
Elicitação	Entrevistar usuários	Quem conta como “o usuário”?
Análise/negociação	Resolver conflitos	Quem tem voz na mesa — normalmente quem paga
Especificação	Documentar o acordado	Requisitos sem voz ficam implícitos/ausentes
Validação	Confirmar com stakeholders	Confirma os mesmos pontos cegos de sempre

Dados Nunca São Neutros

D’Ignazio & Klein (2020), p. 53

“Dados são sempre o produto de relações sociais desiguais […]. Como diz Ben Green: ‘o que o aprendizado de máquina realmente faz é prever o passado.’” (tradução livre)

Se dados nunca são neutros, requisitos levantados a partir de “o que os usuários dizem” carregam a mesma assimetria histórica.

Os Quatro Pontos de Partida de Data Feminism

1. Coletar — compilar contra-dados diante de ausência/negligência institucional.

2. Analisar — auditar algoritmos, demonstrar resultados desiguais.

3. Imaginar — ir além do resultado desigual, atacar a causa raiz.

4. Ensinar — quem faz ciência de dados importa; capacitar recém-chegados.

(D’Ignazio & Klein, 2020, p. 53 — tradução livre)

O Caso do DGEI (1971)

D’Ignazio & Klein (2020), pp. 49–50

“‘Onde Motoristas Atropelam Crianças Negras na Rota Pointes-Downtown.’ […] Ninguém mantinha registros […]. ‘Não conseguíamos obter aquela informação’, explica Gwendolyn Warren.” (tradução livre)

A comunidade já sabia do problema por experiência vivida — faltava poder para transformar essa experiência em dado formal.

O Elo com o Bloco 3

Interface técnica sem comunicação entre equipes → malformada.

Requisito sem ninguém com voz para levá-lo à mesa de negociação → fica de fora da especificação.

Dica

Em nenhum dos dois casos há uma decisão explícita de excluir — é ausência estrutural de representação no processo.

Pergunta

Quem é “o usuário”, de fato?

Quando uma equipe de produto diz que vai “levantar os requisitos entrevistando os usuários”, quem exatamente conta como “o usuário” nessa frase — e quem, na prática, tende a ficar de fora dessa lista, mesmo sendo afetado pelo sistema?

Dica: pense no caso do DGEI — quem tinha o problema não era, necessariamente, quem tinha acesso ao processo formal de registrar ou comunicar esse problema.

• □ Se todos os grupos afetados por um sistema tivessem exatamente o mesmo poder de voz durante a etapa de negociação, a lista final de requisitos ainda poderia refletir as prioridades de quem já detém mais poder social, caso o processo de coleta em si — quem é entrevistado “como” o usuário — não mudasse.
• □ No limite em que instituições oficiais mantêm registro completo e preciso de todos os incidentes relevantes, a prática de compilar contra-dados, como fez o DGEI, deixaria de ter qualquer função, pois a assimetria de informação que a motiva já não existiria.
• □ A lógica de “quem constrói o mapa de requisitos decide o que existe e o que fica de fora”, usada no caso do DGEI, se aplicaria igualmente a uma equipe de produto que decide quais bugs entram no backlog de correção com base apenas nos tickets abertos por usuários que sabem preencher um formulário técnico de report.
• □ Como Data Feminism argumenta que dados nunca são neutros porque refletem relações sociais desiguais, a conclusão correta é que toda coleta de dados institucional deveria ser abandonada em favor exclusivo de contra-dados produzidos por comunidades afetadas.

V/F — Quem é “o Usuário”? Resposta

Dica

• ✔ Verdadeiro — a assimetria pode entrar antes da negociação, na própria seleção de quem é ouvido.
• ✔ Verdadeiro — o motivo do DGEI era exatamente a ausência de registro oficial; removendo essa ausência, a motivação específica desaparece.
• ✔ Verdadeiro — mesmo mecanismo de exclusão por barreira de acesso ao processo formal.
• ✗ Falso — Data Feminism propõe quatro pontos de partida complementares (Coletar/Analisar/Imaginar/Ensinar), não o abandono da coleta institucional.

Retomando: “o usuário” da elicitação de requisitos não é dado — é construído por quem tem acesso ao processo. O DGEI é o caso-limite de alguém sem esse acesso, forçado a criar seu próprio registro.

Quando a Assimetria É Deliberada: Dark Patterns

O Mecanismo Ativo: Quando Alguém Decide Contra Você

Bloco 4: exclusão sem intenção explícita — ninguém decidiu deixar o requisito de fora, faltou estrutura de representação.

Aqui: às vezes a fricção nasce de uma decisão deliberada — o papel de “Stakeholders de negócio” (Bloco 2) otimizando por uma métrica que não é o bem-estar do usuário.

Você já sentiu isso: assinar leva um clique; cancelar exige várias telas de “tem certeza?”, ofertas de última hora, botão discreto.

Cinco Categorias de Dark Patterns

Aviso

Taxonomia de Gray et al. (2018, CHI) — artigo atrás de paywall, sem cópia de acesso aberto encontrada; nomes/descrições vêm de fontes secundárias sobre o artigo, não citação literal. Caso Amazon/FTC abaixo tem verificação mais forte (múltiplas fontes independentes).

Insistência — interrompe repetidamente (pop-up de avaliação que volta sempre).

Obstrução — dificulta deliberadamente um processo já decidido (“Motel de Baratas”: fácil entrar, difícil sair).

Sonegação — esconde informação até o último momento (taxa extra só na última tela do checkout).

Interferência de Interface — manipula a hierarquia visual (“Aceitar todos” grande, “Rejeitar” minúsculo).

Ação Forçada — exige algo sem relação com o pedido original (conta + contatos só para uma função básica).

O Caso Amazon/FTC (2023–2025)

FTC processou a Amazon: inscrever no Prime, 1–2 cliques. Cancelar, processo interno batizado de “Iliad” (a longa guerra de Troia).

Denúncia da FTC — tradução livre

“Quatro páginas, seis cliques e quinze opções” para cancelar — pontuado por avisos de benefícios perdidos e descontos de última hora.

Resultado (2025): acordo de US$ 2,5 bilhões — maior penalidade civil já obtida pela agência por violação de norma sobre assinaturas.

O Que Realmente Caracteriza o Padrão

Uma tela de confirmação isolada (“tem certeza?”) não é, por si só, um dark pattern — pode ser proteção legítima contra clique acidental.

O que caracteriza é a assimetria deliberada: o mesmo time capaz de fazer inscrever = 1 clique escolheu fazer cancelar = 6 cliques. Não é limitação técnica — é escolha alinhada a uma métrica.

Dica

Blocos 2–4: resultado indesejado por ausência estrutural. Aqui: por presença deliberada — alguém decidiu otimizar contra o usuário.

A Pergunta Que Fica em Aberto

Se a fricção pode ser projetada deliberadamente contra o usuário…

…o mesmo maquinário de tradução — de intenção abstrata a comportamento concreto do sistema — pode apontar na direção contrária, a favor do usuário?

É a pergunta que o Bloco 6 responde.

Pergunta

Quem decide o quanto de fricção você sente?

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.

V/F — Quem Decide o Quanto de Fricção? Resposta

Dica

• ✔ Verdadeiro — a métrica otimizada é exatamente o que cria (ou remove) o incentivo estrutural para a fricção deliberada.
• ✗ Falso — uma confirmação isolada pode ser proteção legítima contra erro; o que define a categoria é a assimetria deliberada entre fluxos, não a mera existência de uma tela de confirmação.
• ✔ Verdadeiro — mesma lógica estrutural de assimetria entre entrada e saída, em outro domínio contratual.
• ✗ Falso — o caso da FTC girou em torno de engano e obstrução deliberada, não da otimização de retenção em si; aumentar retenção por um produto genuinamente melhor não é, por si só, um dark pattern.

Retomando: a diferença de fricção entre dois fluxos tecnicamente equivalentes revela a métrica que a equipe responsável escolheu otimizar — nem sempre essa métrica coincide com o interesse do usuário.

Da Responsabilidade Social ao Artefato de Engenharia Concreto

De Valor a Requisito

Value Sensitive Design (VSD) — Design Sensível a Valores (Steen, 2022, Cap. 18): método que coloca valores no centro do processo de inovação, permitindo negociá-los explicitamente entre stakeholders.

Steen (2022), Cap. 18, p. 154

“VSD permite que diversos interessados expressem seus valores e os combinem produtivamente durante o processo de inovação.” (tradução livre)

Steen (2022), pp. 155–156

“Investigações empíricas […] resultam em requisitos (tentativos) para o sistema que está sendo desenvolvido.” (tradução livre)

Repare: as investigações resultam em requisitos, não em princípios soltos. Falta um passo além: do requisito ao código e ao processo.

Três Passos: de Compromisso a Código

1. NFR testável — “acessível a baixa visão” → “contraste mínimo 4.5:1 em todo texto” (verificável, sim/não).

2. ADR registrada — decisão concreta que implementa o NFR + por que foi tomada, preservada para quem vier depois.

3. Gate de CI — checklist/teste automatizado que bloqueia regressão — sem isso, uma mudança futura quebra o compromisso em silêncio.

A Cadeia Completa — e o Elo com o Bloco 3

Aviso

NFR e ADR não bastam por si só: sem gate que impeça automaticamente regressão, e sem dono claro da fronteira, o compromisso sobrevive só enquanto alguém se lembrar dele.

Uma Ressalva: Simplificação, Não Tradução Perfeita

“Acessibilidade” é mais rico que “contraste 4.5:1” — a métrica captura uma parte operacionalizável do valor, não o valor inteiro.

Dica

Por isso 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 entendimento do valor) mudar.

Pergunta

O que faltou entre a reunião e o código?

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.

V/F — o Que Faltou? Resposta

Dica

• ✗ Falso — sem um NFR testável, não há critério de pass/fail concreto para automatizar; a ADR documenta intenção, não define o teste.
• ✗ Falso — um gate frouxo demais não bloqueia regressão real; a função depende do critério ser efetivo, não só existir.
• ✔ Verdadeiro — mesma estrutura de tradução, domínio diferente.
• ✗ Falso — a métrica captura parte operacionalizável do valor; nem todo compromisso precisa ser 100% quantificável para gerar algum requisito de engenharia útil.

Retomando: faltou o passo de NFR testável + gate de CI — a reunião produziu intenção (nível de ADR, na melhor hipótese), não proteção automática contra regressão futura.

Fechamento e Ponte para a Aula 5

Retomando o Roteiro — Pergunta 1 e 2

1. Por que a arquitetura copia o organograma? Construir uma interface exige comunicação; organizações minimizam custo de comunicação alinhando equipes a subsistemas — efeito colateral estrutural, não acidente nem projeto deliberado.

2. Elicitar requisitos é neutro, ou social? É social: cada etapa envolve decisão sobre quem tem voz — dados e requisitos nunca são extração neutra, são produto de relações sociais desiguais anteriores.

Retomando o Roteiro — Pergunta 3 e 4

3. Como um compromisso ético vira algo concreto? Três traduções: NFR testável → ADR registrada → gate de CI — cada uma reduz a distância entre intenção e comportamento real em produção.

4. Que decisões de processo mudam o resultado técnico? Como o time se organiza, quem participa da elicitação — e quem é o “dono” de uma fronteira: sem dono, interface técnica e compromisso ético caem no buraco do mesmo jeito.

5. Fricção contra o usuário: acidente, ou deliberada? As duas formas acontecem: ausência estrutural (Blocos 3–4) e presença deliberada (Bloco 5, dark patterns) — Amazon/FTC mostra a segunda em escala real, com consequência regulatória.

Pergunta

O que mais deixa marca sem ninguém decidir?

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 5 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.).

V/F — Síntese Final: Resposta

Dica

• ✔ Verdadeiro — sem assimetria, não haveria o mecanismo social que a conexão com Data Feminism visa explicar.
• ✔ Verdadeiro — dono explícito de cada fronteira é exatamente a condição que evita a “queda no buraco”.
• ✔ Verdadeiro — mesma lógica estrutural, de processo/organização para consequência fora do código-fonte em si.
• ✗ Falso — a aula acrescenta uma lente sociotécnica; não elimina causas técnicas comuns como explicação legítima de falhas.

Ponte para a Aula 5: se decisões “só de processo” já mudam o resultado técnico assim, decisões de arquitetura — quantos serviços, onde rodam — têm também consequência material e ambiental real. É por aí que a Parte 2 do curso começa.