Miten toimit, kun vaatimukset ovat epäselvät?

Question

Accepted Answer

Epäselvyys on normia oikeassa työssä. He haluavat nähdä, että **aktiivisesti vähennät epävarmuutta** sen sijaan, että pysähtyt tai arvaat hiljaa ja rakennat väärän asian.

## Kuinka lähestyä sitä

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

## Käytännön esimerkki

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

## Hyvä vs heikko

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

## Miksi sillä on merkitystä

Selkeät vaatimukset ovat harvinaisia; insinöörit, jotka menestyvät, ovat ne, jotka voivat liikkua sumun läpi.

Taustalla olevan tavoitteen löytäminen estää sinua rakentamasta tarkalleen sitä, mitä sinua pyydettiin, mutta ei sitä, mitä tarvittiin.

Ohuuden viipaleen esittäminen aikaisin muuttaa kalliit arvailut halvoiksi, nopeiksi korjauksiksi.