Hur gör du när kraven är otydliga?

Question

Accepted Answer

Tvetydighet är normen i verkligt arbete. De vill se att du **aktivt minskar osäkerhet** snarare än att frysa eller gissa i tysthet och bygga fel sak.

## Hur man närmar sig det

```text
1. Ask the questions that change what you'd build
2. Find the goal behind the request (the "why")
3. State your assumptions in writing and confirm them
4. Build a thin slice, demo early, adjust fast
```

## Utarbetat exempel

```text
S: A ticket said "add a dashboard" with no detail on metrics or users.
T: Building blind risked weeks of wasted work.
A: I asked who'd use it and what decision it drove, wrote down three assumptions,
   and built a clickable prototype of the top two metrics first.
R: The demo surfaced that they actually needed exports, not charts. We pivoted
   after two days instead of two weeks.
```

## Bra kontra svagt

```text
✓ Clarifies the "why," states assumptions, demos early
✗ Building the full thing on a guess
✗ Refusing to start until everything is spec'd
```

## Varför det är viktigt

Klara specifikationer är sällsynta; de ingenjörer som trivs är de som kan navigera genom dimma.

Att hitta det underliggande målet förhindrar dig från att bygga exakt vad som frågades men inte vad som behövdes.

Att demonstrera en tunn skiva tidigt förvandlar dyra gissningar till billiga, snabba korrigeringar.