Hoe ga je te werk als de vereisten onduidelijk zijn?

Question

Accepted Answer

Ambiguïteit is normaal in praktijkwerk. Ze willen zien dat je **actief onzekerheid reduceert** in plaats van vast te lopen of stilzwijgend te gissen en het verkeerde ding te bouwen.

## Waarom het belangrijk is

```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
```

## Uitgewerkt voorbeeld

```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.
```

## Goed versus zwak

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

## Waarom het belangrijk is

Duidelijke specificaties zijn zeldzaam; de engineers die slagen zijn degenen die door de mist kunnen navigeren.

Het onderliggende doel vinden voorkomt dat je precies bouwt wat werd gevraagd, maar niet wat nodig was.

Een dunne slice vroeg demonstreren verandert dure gissingen in goedkope, snelle correcties.