Kaip jūs renkate ir aiškinate reikalavimus?

Question

Accepted Answer

**Reikalavimų rinkimas** yra procesas, kurio metu sužinoma, ką iš tikrųjų reikia statyti — ir *kodėl* — prieš tai statant. Didžiausia klaida, kurią daro jaunesni programuotojai, yra daryti prielaidą, kad reikalavimas yra šiaip tiesioginis, nepažinę pagrindinio problemos.

## Kaip tai spręsti

```text
1. ASK WHY → understand the problem behind the request, not just the request
2. TALK to the real users / stakeholders, not just the requester
3. CLARIFY scope → what's in, what's out, what "done" looks like
4. SURFACE assumptions and constraints (deadlines, budget, tech limits)
5. WRITE IT DOWN → confirm your understanding back to them
```

## Skirkite prašymą nuo poreikio

Interesantas sako "pridėkite PDF eksporto mygtuką." Tikrasis poreikis gali būti "Turiu pasidalinti ataskaitomis su mano vadovu." Elektroninis paštas, bendinama nuoroda arba prietaisa galėtų būti geresnė sprendimas. Klausimas *kodėl* atskleidžia geresnių sprendimų.

## Geri paaiškinamieji klausimai

```text
✓ "What problem does this solve for the user?"
✓ "What happens today without it?"
✓ "How will we know it worked?"
✓ "What's explicitly out of scope?"
✓ "What are the edge cases / what could go wrong?"
```

## Dažna klaida

Prielaida, kad supratote ir pradėjote statyti. Visada pakartokite reikalavimus — "taigi, jums reikia X, iki Y, ir Z yra už ribų?" — norėdami anksti nustatyti spragų.

## Kodėl tai svarbu

Reikalavimų klaida idėjos etape kainuoja minutes; ta pati klaida, aptikta po paleidimo, kainuoja dienų ar savaičių pakeitimus.

Aiškūs reikalavimų yra pigiausias draudimas nuo kažko neteisingo statymo.

Klausimas *kodėl* paverčia jus iš įsakymų priėmėjo į problemos sprendėją.