آپ اپنی ٹیم میں آرکیٹیکچر کے اختلافات کو کیسے حل کرتے ہیں؟

Question

Accepted Answer

ہوشیار انجنیئرز آرکیٹیکچر پر اختلاف رکھیں گے، یہ صحت مند ہے۔ TL کا کام اختلاف کو **ایک اچھے فیصلے اور ایک متعہد ٹیم** میں تبدیل کرنا ہے، نہ کہ بحث جیتنا۔ زیادہ تر تنازعات حل ہو جاتے ہیں جب سب کو معیار پر اتفاق ہو جائے۔

## اسے حل کرنے کا طریقہ

```text
1. AGREE on the criteria first — what are we optimizing for?
   (scale, simplicity, time-to-ship, team familiarity)
2. Let each side make its STRONGEST case — steelman, don't strawman
3. Look for DATA — spike it, benchmark it, prototype it
4. If still tied — the TL decides, and explains why
5. DISAGREE AND COMMIT — once decided, everyone rows together
```

## ایک حقیقی مثال

دو انجنیئرز microservices بمقابلہ monolith پر بحث کریں۔ آپ اسے دوبارہ تشکیل دیتے ہیں: "ہم اگلے سال میں کس چیز کے لیے بہتری کر رہے ہیں؟" جواب، ایک چھوٹی ٹیم کے ساتھ تیزی سے deliver کرنا، monolith کو واضح انتخاب بناتا ہے۔ بحث حقیقت میں غیر بیان شدہ اہداف کے بارے میں تھی۔

## کب فیصلہ کریں بمقابلہ التوا کریں

موڑنے کے قابل فیصلوں کے لیے، جلدی ایک منتخب کریں اور آگے بڑھیں، غلط فیصلہ کرنے کی قیمت کم ہے۔ یک طرفہ دروازوں کے لیے، سست ہوں اور ڈیٹا جمع کریں۔ غور و فکر کو موڑنے کی صلاحیت سے مماثل کرنا bikeshedding اور لاپرواہ فیصلوں دونوں سے بچاتا ہے۔

## ایک خطرہ

اپنی seniority سے بحث کو بند نہ کریں، اور نہ ہی بحث کو ہمیشہ کے لیے چلنے دیں۔ دونوں ٹیمز کو مار ڈالتے ہیں: ایک نفرت پیدا کرتا ہے، دوسرا فالج پیدا کرتا ہے۔

## اردو ہیڈنگ

حل نہ ہونے والی آرکیٹیکچر کی لڑائیاں بدک جاتی ہیں اور ٹیمز کو کیمپوں میں تقسیم کرتی ہیں۔

ایک TL جو منصفانہ طریقے سے سہولت فراہم کرتا ہے، پھر فیصلہ کرتا ہے، ایک صحیح ڈیزائن اور ایک ٹیم حاصل کرتا ہے جو اسے ملتا ہے، یہاں تک کہ وہ جو دوسری طرف بحث کریں۔