Hogyan járunk el, amikor a követelmények nem világosak?

Question

Accepted Answer

A kétértelműség a valós munka normája. Azt akarják látni, hogy **aktívan csökkentitek a bizonytalanságot** ahelyett, hogy megmerevedtek vagy csendben találgatnátok, és rossz dolgot építenétek.

## Hogyan közelítsük meg

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

## Kidolgozott példa

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

## Jó vs gyenge

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

## Miért fontos

Az egyértelmű specifikációk ritkák; a sikeres mérnökök azok, akik képesek a ködön át haladni.

Az alapvető cél megtalálása megakadályozza, hogy pontosan azt építsük, amit kértek, de nem azt, amire szükség volt.

Egy vékony szelet korai bemutatása drága találgatásokat olcsó, gyors korrekcióvá alakít.