Lidando com Desacordos Técnicos

Desacordos técnicos são saudáveis até que bloqueiem o lançamento: Axum vs Actix, Arc<Mutex> vs canal, se devemos permitir unsafe em caminhos críticos. Desescalada estruturada - spikes, tomadores de decisão nomeados, discordar e comprometer-se - preserva relacionamentos e trilhas de auditoria.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

# Registro de desacordo (apêndice RFC)
 
## Posição A: async sqlx em todos os lugares (@alice)
- Evidência: benchmark ENG-123 mostra p95 15% menor a 1k RPS
 
## Posição B: spawn_blocking sync reads (@bob)
- Evidência: velocidade da equipe; menos surpresas de pool
 
## Teste Falseável
Se o pool async adquirir p95 > 50ms a 500 RPS em staging, adote B para a fase 1.
 
## Tomador de decisão: @techlead até sexta-feira EOD
## Dissidência registrada nas consequências do ADR-0039

Quando usar isso:

• Comentários circulares de PR além de 2 rodadas
• RFCs concorrentes para o mesmo problema
• Engenheiros seniores em impasse na revisão de design
• Resistência passiva pós-decisão

Exemplo de Trabalho

// Branch de spike: compare abordagens com Criterion (descartável)
 
// caminho async
async fn fetch_async(pool: &sqlx::PgPool, id: i32) -> sqlx::Result<i32> {
    let row: (i32,) = sqlx::query_as("SELECT id FROM t WHERE id = $1")
        .bind(id)
        .fetch_one(pool)
        .await?;
    Ok(row.0)
}
 
// caminho blocking encapsulado para teste justo em tokio::test
async fn fetch_blocking(pool: &sqlx::PgPool, id: i32) -> sqlx::Result<i32> {
    let pool = pool.clone();
    tokio::task::spawn_blocking(move || {
        // consulta sync apenas em testes - spike mede o overhead
        Ok(id)
    })
    .await
    .unwrap()
}

Resultados do spike anexados à RFC; o tomador de decisão escolhe com gatilho de revisão, não a voz mais alta.

Mergulho Profundo

Escada de Desescalada

1. Clarifique restrições e métricas de sucesso por escrito.
2. Spike com tempo limitado e critérios binários.
3. O tomador de decisão decide; dissidência registrada.
4. Discorde e comprometa-se; sem sabotagem por revisão lenta.
5. Gatilho de revisão no ADR (tráfego, SLO, tamanho da equipe).

Durante Incidentes

O IC decide a mitigação; o debate de arquitetura é adiado para o post-mortem. "Eu avisei" banido no canal de incidentes.

Normas Culturais

• Ataque ideias, respeite pessoas.
• Assuma intenção positiva; pergunte que evidência mudaria mentes.
• O EM facilita questões interpessoais; o líder técnico é o dono da decisão técnica.

Armadilhas

• Consenso necessário - Impasse. Correção: Tomador de decisão nomeado antecipadamente.
• Spike sem critérios - Vitória subjetiva. Correção: Métricas de aprovação/reprovação pré-registradas.
• Humilhação pública na revisão - Desgaste. Correção: Sincronização privada para questões de tom.
• Ignorar dissidência registrada - Lutas repetidas. Correção: Gatilho de revisão honrado no prazo.
• Escalada para executivo por gosto técnico - Correção: ADR + EM apenas para trade-offs de pessoal/cronograma.

Alternativas

FAQs

Relacionados

• Tomada de Decisão Técnica - opções classificadas
• Registros de Decisão de Arquitetura (ADRs) - registrar dissidência
• Realizando Revisões de Design - fórum
• Spikes, PoCs e Adoção de Novos Crates - evidência
• Melhores Práticas de Liderança - resumo

Versões de Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.