आप requirements कैसे इकट्ठा और स्पष्ट करते हैं?

Question

Accepted Answer

**Requirements gathering** यह पता लगाने की प्रक्रिया है कि वास्तव में क्या बनाने की ज़रूरत है — और *क्यों* — इसे बनाने से पहले। जूनियर्स की सबसे बड़ी गलती किसी अनुरोध को उसकी अंतर्निहित समस्या को समझे बिना शाब्दिक रूप से ले लेना है।

## इसका सामना कैसे करें

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

## माँग को ज़रूरत से अलग करें

एक stakeholder कहता है "एक export-to-PDF बटन जोड़ो।" असली ज़रूरत शायद "मुझे अपने बॉस के साथ रिपोर्ट साझा करनी है" हो सकती है। ईमेल, एक shared link, या एक dashboard इसे बेहतर तरीके से हल कर सकता है। *क्यों* पूछना बेहतर समाधानों के रास्ते खोलता है।

## अच्छे स्पष्टीकरण वाले सवाल

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

## एक आम गलती

यह मान लेना कि आप समझ गए हैं और बनाना शुरू कर देना। हमेशा requirements को वापस दोहराएँ — "तो जो आपको चाहिए वह X है, Y तक, और Z स्कोप से बाहर है?" — ताकि खामियाँ जल्दी पकड़ी जा सकें।

## यह क्यों महत्वपूर्ण है

विचार के चरण में सुधारी गई एक requirements की गलती की कीमत कुछ मिनट होती है; वही गलती रिलीज़ के बाद मिले तो उसकी कीमत कई दिन या हफ्ते का दोबारा काम होती है।

स्पष्ट requirements गलत चीज़ बनाने के खिलाफ सबसे सस्ता बीमा हैं।

*क्यों* पूछना आपको एक ऑर्डर-लेने वाले से एक समस्या-समाधानकर्ता में बदल देता है।