Πώς προχωράτε όταν οι απαιτήσεις είναι ασαφείς;

Question

Accepted Answer

Η ασάφεια είναι ο κανόνας στην πραγματική δουλειά. Θέλουν να δουν ότι **μειώνετε ενεργά την αβεβαιότητα** παρά να παγώνετε ή να μαντεύετε σιωπηλά και να χτίσετε το λάθος πράγμα.

## Πώς να το προσεγγίσετε

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

## Πρακτικό παράδειγμα

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

## Καλό vs αδύναμο

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

## Γιατί σημαίνει

Οι σαφείς προδιαγραφές είναι σπάνιες· οι μηχανικοί που ευδοκιμούν είναι αυτοί που μπορούν να κινούνται μέσα από την ομίχλη.

Η εύρεση του υποκείμενου στόχου σας εμποδίζει να χτίσετε ακριβώς αυτό που σας ζητήθηκε αλλά όχι αυτό που χρειαζόταν.

Η επίδειξη ενός λεπτού slice νωρίς μετατρέπει ακριβές εικασίες σε φτηνές, γρήγορες διορθώσεις.