जब आपसे तेज़ी से चलने को कहा जाता है लेकिन अधिक लोग नहीं दिए जाते, तो आप क्या करते हैं?

Question

IT Interview Practice · Accepted Answer

लोगों को जोड़ना वैसे भी अल्पावधि में शायद ही कभी टीम को तेज़ बनाता है, इसलिए असली सवाल है: टीम का *समय वास्तव में कहाँ जा रहा है*, और मैं उसके बारे में क्या बदल सकता हूँ? मैं "तेज़ी से चलो" को लंबे घंटे काम करने की माँग के बजाय leverage खोजने के संकेत के रूप में मानता हूँ।

## मैं गति कहाँ ढूँढता हूँ

- **कोनों को नहीं, scope को काटें।** तेज़ी से ship करने का सबसे तेज़ तरीका है कम बनाना। मैं PM के साथ निर्ममता से प्राथमिकता देने और सबसे छोटा version खोजने के लिए काम करता हूँ जो मूल्य देता है। अधिकांश features 20% काम में 80% मूल्य होते हैं।
- **घर्षण और प्रतीक्षा समय हटाएँ।** अक्सर bottleneck coding गति नहीं है — यह धीमा CI, flaky tests, कष्टदायक deploys, धीमी reviews, या approvals का इंतज़ार है। एक 30-मिनट के build या दो-दिन के review turnaround को ठीक करना मुफ़्त में असली velocity खरीदता है।
- **work-in-progress कम करें।** दस चीज़ों को संभालने वाली टीमें कुछ भी पूरा नहीं करतीं। समानांतर में कम चीज़ों पर ध्यान केंद्रित करना चीज़ों को जल्दी ship करता है।
- **दोहराव को automate करें।** Manual testing, manual releases, manual environment setup — एक बार निवेश करें, हमेशा बचाएँ।
- **उस debt को चुकाएँ जो सक्रिय रूप से आपको धीमा कर रही है।** सारी नहीं; सिर्फ़ वह हिस्सा जिस पर टीम रोज़ ठोकर खाती है।
- **फ़ोकस समय की रक्षा करें।** कम meetings और बाधाएँ किसी भी tool से बड़ी जीत हो सकती हैं।

## मैं माँग का जवाब कैसे देता हूँ

मैं बस "असंभव" नहीं कहता या चुपचाप इसे स्वीकार नहीं करता। मैं एक **trade-off** के साथ जवाब देता हूँ: "हम उस तारीख को हिट कर सकते हैं अगर हम features A और B काट दें, या testing पर अधिक जोखिम स्वीकार करें। यहाँ मेरी सिफ़ारिश है।" यह गति को एक शांत गुणवत्ता जुआ के बजाय एक साझा, सचेत निर्णय बनाता है।

## बचने योग्य गलतियाँ

- **overtime अनिवार्य करना।** यह एक छोटा sprint खरीदता है और इसे burnout, बग्स, और attrition के साथ चुकाता है।
- **चुपचाप tests और reviews छोड़ना।** आज गति, अगले महीने एक outage।
- **कुछ भी बदले बिना तारीख को हाँ कहना** — यह बस आशा करना है, और आशा deadlines चूकती है।

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

सतत गति बर्बादी हटाने से आती है, लोगों को निचोड़ने से नहीं। एक Tech Lead जो दबाव का जवाब स्पष्ट trade-offs और प्रक्रिया सुधारों के साथ देता है, वह एक ऐसी टीम बनाता है जो वास्तव में तेज़ और टिकाऊ है — उसके बजाय जो दौड़ती है, दुर्घटनाग्रस्त होती है, और अपने सबसे अच्छे इंजीनियरों को खो देती है।

मैं गति कहाँ ढूँढता हूँ

मैं माँग का जवाब कैसे देता हूँ

बचने योग्य गलतियाँ

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

संबंधित प्रश्न