आप बदलते हुए requirements को कैसे संभालते हैं?

Question

Accepted Answer

Requirements बदलते हैं — बाज़ार बदलते हैं, आप यूज़र्स से सीखते हैं, प्राथमिकताएँ बदलती हैं। लक्ष्य बदलाव को *रोकना* नहीं है (यह असंभव और अवांछनीय दोनों है) बल्कि उसे **सोच-समझकर** संभालना है ताकि वह प्रोजेक्ट को पटरी से उतारने के बजाय प्रोडक्ट को बेहतर बनाए।

## बदलाव को अपनाएँ, लेकिन उसे नियंत्रित करें

```text
✓ EXPECT change → build flexibility into plans (don't over-commit far ahead)
✓ ASSESS each change → impact on scope, timeline, cost, other work
✓ Make the TRADE-OFF visible → "yes, but it costs X or pushes Y"
✓ Let the stakeholder DECIDE with full information
✓ COMMUNICATE the new plan to everyone affected
```

मुख्य अनुशासन वही है जो scope management का है: कभी भी किसी बदलाव को चुपचाप मत सोखें। हर बदलाव एक सचेत trade-off है जिसका स्वामी कोई होता है।

## Agile कैसे मदद करता है

Agile बदलते requirements के लिए ही बना है: छोटे iterations का मतलब है कि आप बार-बार दोबारा प्राथमिकता तय करते हैं, इसलिए एक बदलाव साल भर के प्लान को बाधित करने के बजाय अधिक से अधिक एक स्प्रिंट तक इंतज़ार करता है। छोटे increments में काम करना यह सीमित करता है कि कोई एक बदलाव कितना दोबारा काम पैदा कर सकता है।

## खोज को churn से अलग करें

```text
HEALTHY change → new learning, better understanding of the problem
UNHEALTHY churn → indecision, unclear goals, no one owning priorities
```

यदि requirements लगातार उथल-पुथल में रहते हैं, तो असली समस्या ऊपर की ओर है — अस्पष्ट लक्ष्य या कमज़ोर प्राथमिकता-निर्धारण — और यही ठीक करने वाली चीज़ है।

## एक ठोस उदाहरण

स्प्रिंट के बीच में, यूज़र रिसर्च से पता चलता है कि नियोजित फ्लो लोगों को भ्रमित करता है। आगे बढ़ने के बजाय, आप आकलन करते हैं: इसे दोबारा बनाने में तीन दिन लगते हैं और एक कम-प्राथमिकता वाला आइटम आगे खिसकता है। आप वह trade-off पेश करते हैं, PM सहमत होता है, और आप समायोजित करते हैं — एक ऐसा बदलाव जिसने प्रोडक्ट को *बेहतर* बनाया, बिना अराजकता के संभाला गया।

## एक आम गलती

या तो सख्ती से हर बदलाव को मना करना (कुछ ऐसा शिप करना जिसे आप *जानते* हैं कि गलत है) या बिना किसी impact assessment के हर बदलाव को स्वीकार करना (पुरानी फिसलन और बर्नआउट)।

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

अनुकूलन की क्षमता एक ताकत है — ऐसा सॉफ़्टवेयर जो बदल नहीं सकता वह सॉफ़्टवेयर है जो धीरे-धीरे अप्रचलित हो रहा है।

बदलाव को अच्छी तरह संभालना (आकलन, trade-offs को दृश्यमान बनाना, संवाद, increments में काम करना) आपको डिलीवरी पर नियंत्रण खोए बिना वास्तविकता के प्रति उत्तरदायी बने रहने देता है।