आप संगठन और टीम संरचना को कैसे डिज़ाइन करते हैं?

Question

IT Interview Practice · Accepted Answer

संगठन डिजाइन **टीम सीमाओं को आकर्षित करने के बारे में है ताकि जो काम एक साथ बदलता है वह एक साथ रहे** — उन चीजों के लिए क्रॉस-टीम निर्भरता को कम करता है जो तेजी से आगे बढ़ते हैं। संरचना को रणनीति और सिस्टम का पालन करना चाहिए, इसके विपरीत नहीं।

## सिद्धांत

```text
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
```

## स्ट्रीम-संरेखित सोच

दीर्घकालिक, स्ट्रीम-संरेखित टीमों को अनुकूल करें जो काम के प्रवाह को स्वामित्व देते हैं, प्लेटफॉर्म टीमों द्वारा समर्थित जो दूसरों के संज्ञानात्मक भार को कम करते हैं। पुनर्गठन करें जब संरचना काम से लड़ने लगे — किसी झटके पर नहीं।

## खतरे

- **कार्यात्मक साइलो** (एक "QA टीम," एक "फ्रंटएंड टीम") जो हर विशेषता को कई हैंडऑफ पार करने के लिए मजबूर करता है।
- **कॉनवे के कानून को नजरअंदाज करना** और आश्चर्य से कि आर्किटेक्चर संगठन चार्ट को प्रतिबिंबित करता है।
- **लगातार पुनर्गठन**, जो हर बार विश्वास और स्वामित्व को रीसेट करता है।
- **फजी स्वामित्व**, जहां सब कुछ "साझा" है और इसलिए किसी के द्वारा स्वामित्व में है।

## यह क्यों मायने रखता है

संरचना चुपचाप गति निर्धारित करती है।

खराब सीमाएं अंतहीन समन्वय बैठकें और धुंधली जवाबदेही बनाती हैं; अच्छी सीमाएं टीमों को स्वतंत्र रूप से आगे बढ़ने देती हैं।

कॉनवे के कानून के कारण, संगठन डिजाइन *आर्किटेक्चर डिजाइन* है।

टीम सीमाओं को गलत तरीके से प्राप्त करें और कोई भी इंजीनियरिंग वीरता सिस्टम को साफ नहीं बनाएगी।

सिद्धांत

स्ट्रीम-संरेखित सोच

खतरे

यह क्यों मायने रखता है

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