Estimativas e incerteza

Nível: B1

Objetivo

Dar estimativas de tempo e esforço em discussões de engenharia usando linguagem com hedge (soft) — frases como `It should take about two days`, `Roughly a week`, `At least three hours` e `No more than five days` — e distinguir marcadores soft (`should`, `roughly`, `about`, `at least`, `no more than`) de marcadores confident (`will`, `exactly`) para explicar incertezas sem prometer demais.

Explicação

Em engenharia, estimativas são quase sempre imprecisas por natureza: dependem de código que ainda não foi escrito, de pessoas que podem sair de férias, de serviços que podem falhar. Por isso, a maior parte das estimativas em inglês técnico é feita com linguagem soft (com hedge): expressões que mostram o quanto você tem (ou não tem) de certeza sobre um número. O objetivo é dar uma referência útil sem virar uma promessa firme que você não vai conseguir cumprir.

Marcadores soft: roughly, about, approximately, around

Esses adverbios/discursos reduzem o peso do número: ele é uma ordem de grandeza, não um prazo. Compare:

• `It will take exactly 3 days.` (promessa firme — se atrasar uma hora, você falhou)
• `It should take about 3 days.` (estimativa com margem — `about` deixa claro que é aproximado)
• `It should take roughly 3 days.` (ainda mais informal, comum em fala; `roughly` = "de modo aproximado")
• `It should take approximately 3 days.` (mais formal; comum em documentos, RFCs, post-mortems)

Os três significam "mais ou menos". A diferença é mais de registro do que de sentido:

Regra prática: use `about` ou `roughly` em conversas, e `approximately` em textos escritos. Os quatro são intercambiáveis em sentido, mas o registro muda o tom da sua fala.

Limites: at least, no more than, at most

Quando você sabe que um número é um limite (mínimo ou máximo) e não uma média, use `at least` e `no more than` / `at most`:

• `It will take at least 2 hours to set up the environment.` (no mínimo 2h — pode demorar mais)
• `The migration should take no more than 5 days.` (no máximo 5 dias — idealmente menos)
• `We need at most one engineer on this task.` (no máximo um engenheiro)

`At least` indica piso (o pior caso razoável, ainda mais): "precisamos de pelo menos X". `No more than` e `at most` indicam teto (o melhor caso razoável): "não deve passar de X". Misturar os dois (`at least 3 days and no more than 3 days`) deixa a frase vazia.

Should vs will: a diferença central

A diferença mais importante deste tópico está no verbo:

• `will` = previsão firme, compromisso: "isso vai acontecer". Use quando você tem certeza ou está prometendo um resultado.
• `should` = expectativa razoável, não compromisso: "é o que eu espero que aconteça, com base no que sei hoje". Use quando você não tem certeza total.

Compare em frases de estimativa:

• `The build will finish in 10 minutes.` (certeza: o build é determinístico, sempre leva esse tempo)
• `The migration should finish in 10 minutes.` (expectativa: pode levar mais, dependendo do tamanho do banco)

Regra de ouro: se existe alguma chance real de o número não bater, use `should` em vez de `will`. Trocar `will` por `should` numa frase de estimativa quase nunca está errado; trocar `should` por `will` é uma promessa que pode se voltar contra você.

It takes / it should take

A estrutura clássica em inglês técnico é `It + take + tempo`:

• `It takes 5 minutes to deploy.` (presente: fato)
• `It took 5 minutes to deploy.` (passado: o que aconteceu)
• `It should take about 5 minutes to deploy.` (futuro com hedge: expectativa razoável)
• `It will take about 5 minutes to deploy.` (futuro sem hedge: compromisso)

A forma mais segura em estimativa de prazo é sempre `It should take + (about/roughly/approximately) + tempo`.

Dependências e ressalvas

Para mostrar que uma estimativa depende de algo, use `depending on` ou `it depends on`:

• `It should take about a week, depending on how much the API changes.`
• `The time depends on the size of the dataset.`

Adicione uma frase de ressalva curta depois do número. Isso mostra maturidade técnica: você não está vendendo prazo, está explicando a sua leitura do problema.

Exemplos

Erros comuns

• Prometer demais com will: `It will take 2 days` (compromisso firme) deve ser `It should take about 2 days` quando há risco real de variar.
• Trocar at least por at most: `The task will take at most 3 hours` significa 'no máximo 3h' (teto); para dizer 'pelo menos 3h' (piso), use `at least 3 hours`.
• Esquecer should em It take: `It take 3 days` e `It takes 3 days to do` (presente) e `It will take 3 days` (futuro) — sem -s e sem auxiliar, está errado.
• Usar about com números exatos: `about 100%, exactly` ou `about exactly 3 days` mistura um hedge com um número firme, perdendo o sentido.
• Dizer `at least` e `no more than` com o mesmo número: `at least 3 days and no more than 3 days` é vazio; se for teto, use só `no more than 3 days`.
• Confundir roughly com rough: `rough estimate` (substantivo) é o nome da estimativa; `roughly` é o advérbio que vai antes do número — `a rough estimate` ≠ `a roughly estimate`.
• Esquecer o verbo da estrutura `It takes / It should take`: `It take 3 days` está errado; o sujeito `It` exige `takes` (presente) ou `should take` (futuro com hedge).
• Traduzir `mais ou menos` literalmente: em PT dizemos `mais ou menos 3 dias`; em inglês isso vira `about 3 days` ou `roughly 3 days`, nunca `more or less 3 days`.

Prática guiada

Reescreva cada afirmação usando a forma soft correta:

• Compromisso firme: `The deploy will take 2 hours.`

→ Com hedge: `The deploy should take about 2 hours, depending on the size of the change.`

• Piso (no mínimo): `We need 3 days for the tests.`

→ Com at least: `We need at least 3 days for the tests.`

• Teto (no máximo): `The migration takes 5 days at most.`

→ Com no more than: `The migration should take no more than 5 days.`

• Ordem de grandeza: `It will take a week.`

→ Com roughly: `It should take roughly a week, depending on the API review.`

Repare que toda boa estimativa tem três partes: verbo soft (`should`) + marcador (`about/roughly/at least/no more than`) + ressalva curta (`depending on...`), quando aplicável.

Resumo

Use should (não will) quando a estimativa pode variar. Use about, roughly ou approximately para dar uma ordem de grandeza. Use at least para piso (no mínimo) e no more than / at most para teto (no máximo). Adicione uma ressalva curta com depending on quando a estimativa depender de um fator externo. Regra de ouro: se existe chance real de o número não bater, troque `will` por `should` e adicione um hedge — é melhor subestimar a precisão do que prometer demais.

História: Estimativas e incerteza

Nível: B1

História em inglês

The Friday question

On Wednesday morning, PM Carla pinged Rafael, the backend lead, on Slack. "How long will the payment retry feature take? The client is asking for a delivery date for next sprint." Rafael looked at the design doc and thought for a moment before typing his reply. "It should take about a week and a half," he wrote, "but I want to scope the unknowns first." Carla replied, "A week and a half feels long. Can we do it in one week?"

Breaking down the work

Rafael opened a quick call and walked Carla through the rough breakdown. "The retry logic itself should take no more than three days, give or take," he said. "But the queue layer needs at least two days of refactoring before we touch the retry code." "And QA for the failure scenarios will need roughly a day and a half on top of that." "So a week and a half is a reasonable estimate, depending on how clean the queue refactor goes." Carla nodded and wrote the date down, leaving a small buffer for the unknowns.

An old mistake

On the way out, the senior engineer Diego joined the call and shared a story. "Last quarter we promised the same feature in one week, will be done by Friday," he said. "We overpromised; the queue refactor was twice as long as we thought." "The team worked the weekend, and the feature shipped on Monday, three days late." "If we had said 'roughly a week and a half' from the start, nobody would have been surprised." Rafael agreed: it is better to estimate with margin than to overpromise and slip.

Aligning on ranges

Back on the call, Carla asked Rafael to write the estimate in the planning doc. Rafael wrote: "Estimate: roughly 1.5 sprints, with a hard ceiling of 2 sprints if the queue refactor takes longer than expected." "The first milestone is the queue refactor, which we should land by the end of week one." "Beyond that, the exact delivery date depends on the failure tests passing cleanly." Carla updated the client with the new range, and both sides felt more confident about the timeline. Rafael closed the call and added a small note: "Better to under-promise and over-deliver, every time."

Tradução linha por linha

Notas de vocabulário

• It should take about a week and a half = should + about: expectativa soft com ordem de grandeza
• I want to scope the unknowns first = scope: mapear o que ainda não se sabe antes de estimar
• no more than three days, give or take = no more than = teto; give or take = ressalva coloquial no fim
• at least two days of refactoring = at least = piso: precisa de pelo menos esse tempo, pode ser mais
• roughly a day and a half on top of that = roughly + duração: ordem de grandeza informal
• depending on how clean the refactor goes = depending on + clause: aponta a variável da estimativa
• a small buffer for the unknowns = buffer: margem de segurança no prazo para imprevistos
• we overpromised = to overpromise: prometer mais do que se pode cumprir
• a hard ceiling of 2 sprints = hard ceiling: teto firme que não deve ser ultrapassado
• Better to under-promise and over-deliver = princípio clássico de estimativa: prometer menos e entregar mais

Perguntas de compreensão

1. Why did Carla ping Rafael on Wednesday morning?
2. What was Rafael's first answer when Carla asked for a delivery date?
3. What did Rafael say about the retry logic itself?
4. Why did Rafael say the queue layer needs at least two days?
5. What did Diego say about last quarter's estimate?
6. What would Diego have said differently at the start of that project?
7. What did Rafael write in the planning doc as the final estimate?
8. What is the first milestone of the payment retry feature?
9. Why did both sides feel more confident about the timeline at the end?
10. What is the principle Rafael wrote at the end of the call?

Prática com a história

1. Reescreva como estimativa soft: The migration will take 5 days.
2. Reescreva com piso: The QA needs 2 days.
3. Reescreva com teto: The build takes 10 minutes max.
4. Passe para forma soft: It takes 2 hours to set up the environment.
5. Escreva uma frase com `depending on` mostrando que a entrega depende do code review.
6. Reescreva para evitar a promessa firme: We will deliver the feature in one week, exactly.