Kaip elgiesi, kai reikalavimai neaiškūs?

Question

Accepted Answer

Dviprasmybė yra įprastas dalykas realaus darbo metu. Jie nori pamatyti, kad tu **aktyviai mažini netikrumą**, o ne sustabyti ar tyliai atspėti ir pastatyti ką nors netinkamo.

## Kaip tai atlikti

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

## Praktinis pavyzdys

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

## Gerai vs. silpnai

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

## Kodėl tai svarbu

Aiškios specifikacijos yra retos; inžinieriai, kurie sukuria šanso, yra tie, kurie gali judėti per miglą.

Rasti pagrindinį tikslą neleidžia tau pastatyti tiksliai to, ko buvo paprašyta, bet ne to, ko reikėjo.

Ankstyvas plonos dalies demonstravimas paverčia brangius spėjimus į pigius, greitus pataisymus.