আপনি কীভাবে সংস্থা এবং দল কাঠামো ডিজাইন করেন?

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 দল," একটি "frontend দল") যা প্রতিটি বৈশিষ্ট্যকে অনেক হস্তান্তর জুড়ে যেতে বাধ্য করে।
- **কনওয়ের আইন উপেক্ষা করা** এবং স্থাপত্য সংগঠন চার্ট প্রতিফলিত করে অবাক হওয়া।
- **ক্রমাগত পুনর্সংগঠন**, যা প্রতিবার বিশ্বাস এবং মালিকানা পুনরায় সেট করে।
- **অস্পষ্ট মালিকানা**, যেখানে সবকিছু "ভাগ করা" এবং তাই কেউ মালিক নয়।

## এটি কেন গুরুত্বপূর্ণ

কাঠামো নিঃশব্দে গতি নির্ধারণ করে।

খারাপ সীমানা অসংখ্য সমন্বয় সভা এবং অস্পষ্ট দায়বদ্ধতা তৈরি করে; ভাল সীমানা দলগুলিকে স্বাধীনভাবে চলতে দেয়।

কনওয়ের আইনের কারণে, সংস্থা ডিজাইন *হল* স্থাপত্য ডিজাইন।

দল সীমানা ভুল করুন এবং কোন পরিমাণ প্রকৌশল বীরত্ব সিস্টেমকে পরিষ্কার করবে না।

নীতিগুলি

স্ট্রিম-সারিবদ্ধ চিন্তাভাবনা

ত্রুটিগুলি

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন