1.2 ٹیم ٹاپولوجیز اور تنظیمی ڈیزائن

جائزہ اور محرکات

آپ لوگوں کو ٹیموں میں کیسے تقسیم کرتے ہیں، یہی طے کرتا ہے کہ آپ کون سا سافٹ ویئر بنا سکتے ہیں اور کتنی تیزی سے۔ یہ کوئی استعارہ نہیں ہے۔ یہ تقریباً میکانکی نتیجہ ہے جسے کانوے کا قانون کہا جاتا ہے: ادارے ایسے نظام ڈیزائن کرتے ہیں جو ان کے اپنے ابلاغی ڈھانچے کا عکس ہوتے ہیں۔ اگر تین ٹیمیں کمپائلر بنائیں تو آپ کو تین مرحلوں والا کمپائلر ملتا ہے۔ اگر آپ کی ادائیگیوں کی منطق فرنٹ اینڈ ٹیم، بیک اینڈ ٹیم اور ڈیٹا بیس ٹیم میں بٹی ہو تو ہر ادائیگی کی تبدیلی کو تین طرفہ ہم آہنگی چاہیے۔ چھوٹے ادارے کے لیے یہ قابل برداشت ہے۔ بڑے ادارے کے لیے تنظیمی چارٹ کی شکل آپ کی انجینئرنگ، فن تعمیر، ترسیل کی رفتار اور معیار پر سب سے بڑی رکاوٹ بن جاتی ہے۔ لہٰذا ٹیم کی ساخت کا ڈیزائن انجینئرنگ کی اولین سرگرمی ہے، انسانی وسائل کا بعد کا خیال نہیں۔

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

انٹرپرائز اور حکومت کے لیے یہ نظم و ضبط فیصلہ کن ہے۔ بڑے ادارے فطری طور پر گہری درجہ بندیوں، لمبی قطاروں والی مشترک خدمات، اور ایسی حوالگی کی زنجیروں میں پھیل جاتے ہیں جو دو دن کی تبدیلی کو دو ماہ کا منصوبہ بنا دیتی ہیں۔ حکومت میں خریداری کی حدود، ٹھیکیدار ٹیمیں اور لازمی فرائض کی علیحدگی ملکیت کو مزید ٹکڑے کر دیتی ہیں۔ واضح ٹاپولوجی ڈیزائن ہی وہ طریقہ ہے جس سے یہ ادارے بہاؤ دوبارہ حاصل کرتے ہیں: ٹیموں کو قدر کے دھاروں کے ساتھ ہم آہنگ کریں، ایسے پلیٹ فارم بنائیں جو ذہنی بوجھ کم کریں، اور ایسے تعامل کے نمونے چنیں جو انحصارات کو چھپے ہوئے اور مستقل کے بجائے نظر آنے والا اور ارادی بنائیں۔

بنیادی اصول

• کانوے کا قانون ناگزیر ہے؛ ٹیموں کو اس سافٹ ویئر انجینئرنگ کے مطابق ڈیزائن کریں جو آپ چاہتے ہیں (“الٹی چال”)۔
• افراد کے زیادہ سے زیادہ استعمال کے بجائے ٹیم کے ذہنی بوجھ کو بہتر بنائیں۔
• ایسی اسٹریم الائنڈ ٹیموں کو ترجیح دیں جو قدر کا ایک حصہ شروع سے آخر تک اپنے پاس رکھتی ہوں۔
• پلیٹ فارم اسٹریم الائنڈ ٹیموں کا ذہنی بوجھ کم کرنے کے لیے ہیں، دربانی کے لیے نہیں۔
• ٹیموں کے باہمی تعامل کو واضح اور کم رکھیں: تعاون، X-as-a-service، یا سہولت کاری۔
• انحصارات کم سے کم کریں؛ ہر ٹیموں کے بیچ حوالگی ایک قطار اور ایک خطرہ ہے۔
• ٹیم کی ساخت ایک زندہ ڈیزائن ہے جسے نظام اور کاروبار بدلنے کے ساتھ ارتقا کرنا چاہیے۔

سفارشات

چار بنیادی ٹیم اقسام استعمال کریں

ٹیم ٹاپولوجیز چار ٹیم اقسام متعین کرتی ہیں جو زیادہ تر ضرورتیں پوری کرتی ہیں۔ اسٹریم الائنڈ ٹیمیں ڈیفالٹ ہیں: ہر ایک کسی مخصوص پروڈکٹ، سروس یا صارف سفر کے کام کے مسلسل بہاؤ کی شروع سے آخر تک مالک ہے۔ پلیٹ فارم ٹیمیں اندرونی پروڈکٹس (کمپیوٹ، تعیناتی، ڈیٹا پائپ لائنیں، شناخت) فراہم کرتی ہیں جنہیں اسٹریم الائنڈ ٹیمیں خود سروس کے طور پر استعمال کرتی ہیں، جس سے ان کا ذہنی بوجھ کم ہوتا ہے۔ معاون ٹیمیں ماہرین (ٹیسٹنگ، سلامتی، مشاہدہ پذیری) ہوتی ہیں جو اسٹریم الائنڈ ٹیموں کو صلاحیت بنانے کی کوچنگ دیتی ہیں، پھر پیچھے ہٹ جاتی ہیں۔ پیچیدہ ذیلی نظام والی ٹیمیں ان اجزا کی مالک ہوتی ہیں جنہیں گہری مہارت چاہیے (قیمت کا انجن، ویڈیو کوڈیک، خفیہ نگاری کا ماڈیول)، جہاں ہر ٹیم کا اس علم کو رکھنا بے معنی ہے۔ آپ کی زیادہ تر ٹیمیں اسٹریم الائنڈ ہونی چاہئیں؛ باقی تین اقسام انہی کی مدد کے لیے ہیں۔

الٹی کانوے چال اپنائیں

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

ذہنی بوجھ کو واضح طور پر سنبھالیں

ایک ٹیم صرف اتنا ہی سنبھال سکتی ہے۔ ذہنی بوجھ میں شعبے کی پیچیدگی، ٹیکنالوجیز، آپریشنل بوجھ، اور اسٹیک ہولڈرز کی وسعت شامل ہے۔ جب کوئی ٹیم بہت سی غیر متعلقہ سروسز کی مالک ہو تو معیار اور رفتار دونوں ٹوٹ جاتے ہیں۔ اس لیے ہر ٹیم کی ذمہ داریوں کو اس شعبے تک محدود رکھیں جس میں وہ واقعی مہارت حاصل کر سکے، اور پلیٹ فارم اور معاون ٹیموں سے وہ غیر امتیازی پیچیدگی اتروائیں۔ ٹیموں کو تقریباً پانچ سے نو افراد تک رکھیں: اتنی چھوٹی کہ آسانی سے بات ہو سکے اور، مذاقاً، دو پیزا سے پیٹ بھر جائے۔

تعامل کے طریقے سوچ سمجھ کر چنیں

ٹیموں کے باہمی تعامل کو تین طریقوں تک محدود رکھیں۔ تعاون دو ٹیموں کے درمیان ایک مقررہ مدت کے لیے قریبی، اعلیٰ بینڈ وڈتھ کام ہے؛ یہ دریافت کے لیے طاقتور ہے مگر مہنگا، اس لیے اسے عارضی رکھیں۔ X-as-a-service صاف فراہم کنندہ/صارف رشتہ ہے جس کا انٹرفیس واضح ہو، بڑے پیمانے پر پلیٹ فارم کے استعمال کے لیے مثالی۔ سہولت کاری یہ ہے کہ ایک ٹیم دوسری کو سیکھنے میں مدد دے، جو معاون ٹیمیں کرتی ہیں۔ ہر اہم بین ٹیم رشتے کا طریقہ نام سے طے کریں، اور ایک ہی دو ٹیموں کے درمیان طویل مدتی تعاون کو اس بات کی علامت سمجھیں کہ ان کی حد غلط جگہ پر ہے۔

مشترک شعبوں کے لیے آپریٹنگ ماڈل چنیں

سلامتی، ڈیٹا، ڈیزائن اور اس جیسے شعبے تین طریقوں سے منظم ہو سکتے ہیں: مرکزی (ایک ٹیم سب کے لیے مالک ہو)، وفاقی (ماہرین جزوی وقت کے لیے شامل ہوں اور گلڈ کے ذریعے ہم آہنگی کریں)، یا جڑا ہوا (ہر اسٹریم الائنڈ ٹیم کے اندر ایک مخصوص ماہر)۔ مرکزی ماڈل یکسانیت اور گہرائی دیتا ہے مگر رکاوٹ بن جاتا ہے۔ جڑا ہوا ماڈل رفتار اور سیاق دیتا ہے مگر بے ربطی اور تکرار کا خطرہ رکھتا ہے۔ وفاقی ماڈل (اکثر حب اور اسپوک یا مہارت کی برادری) ان دونوں کے بیچ میں ہے۔ ہر شعبے اور ہر پیمانے کے لیے الگ چنیں۔ زیادہ تر بڑے ادارے ان شعبوں کے لیے وفاقی ماڈل پر پہنچتے ہیں، ایک چھوٹے مرکزی مرکز کے ساتھ جو معیارات طے کرے۔

اندرونی سورس میں سرمایہ کاری کریں

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

سمجھوتے: فوائد اور نقصانات

مشترک شعبوں کا ماڈل	فوائد	نقصانات
مرکزی (سب کے لیے ایک ٹیم)	یکسانیت، گہری مہارت، واضح معیارات	رکاوٹ، قطاریں، پروڈکٹ کے سیاق کا زیاں
وفاقی (حب اور اسپوک، گلڈز)	یکسانیت اور رفتار میں توازن؛ علم کی شراکت	ہم آہنگی کے نظم و ضبط کا تقاضا؛ جوابدہی دھندلا سکتی ہے
جڑا ہوا (ہر ٹیم میں ماہر)	تیز، سیاق سے بھرپور، اعلیٰ ملکیت	تکرار، بے ربطی، بڑے پیمانے پر عملہ پورا کرنا مشکل

ٹیم کی قسم	کس کے لیے بہترین	حد سے زیادہ استعمال کا خطرہ
اسٹریم الائنڈ	زیادہ تر پروڈکٹ اور سروس کی ترسیل	کوئی نہیں؛ یہی غالب ہونی چاہیے
پلیٹ فارم	مشترک ذہنی بوجھ کم کرنا	ہاتھی دانت کے مینار کا دربان بن جاتا ہے
معاون	صلاحیت عارضی طور پر پھیلانا	مستقل انحصار میں بدل جاتی ہے
پیچیدہ ذیلی نظام	واقعی گہرے ماہرانہ شعبے	عام کام ذخیرہ کرنے کا بہانہ بن جاتی ہے

بار بار آنے والا سمجھوتا خود مختاری بمقابلہ یکسانیت ہے۔ مکمل خود مختار ٹیمیں تیز چلتی ہیں، مگر معیارات، ٹولنگ اور سلامتی کی کیفیت میں ایک دوسرے سے دور ہو جاتی ہیں۔ مکمل مرکزی کنٹرول چیزوں کو یکساں رکھتا ہے، مگر بہاؤ کا گلا گھونٹ دیتا ہے۔ اچھا ٹاپولوجی ڈیزائن وہ جوڑ تلاش کرتا ہے: اسٹریم الائنڈ ترسیل کے لیے خود مختاری، اور جن چیزوں کو واقعی یکساں ہونا چاہیے ان کے لیے پتلے مرکزی معیارات اور پکی سڑک والے پلیٹ فارم (اچھی طرح سپورٹ شدہ ڈیفالٹ ٹولنگ جو تعمیل والا انتخاب آسان بنا دے)۔

اپنی ٹیم کے ساتھ بحث کے سوالات

1. کون سے ٹھوس اشارے آپ کو بتائیں گے کہ ٹیم کا ذہنی بوجھ بہت زیادہ ہے، معیار ٹوٹنے سے پہلے؟ “ہر ٹیم کو ایسے شعبے تک محدود رکھیں جس میں وہ مہارت حاصل کر سکے” کہنا آسان ہے اور شواہد کے بغیر اس پر عمل مشکل، کیونکہ ذہنی بوجھ اس وقت تک نظر نہیں آتا جب تک ترسیل اور قابل اعتمادی بگڑ نہ جائیں۔ قابل پیمائش علامات پر نظر رکھیں: ٹیم کی ملکیت میں کتنی غیر متعلقہ سروسز یا ریپوزٹریز ہیں، آغاز کار میں کتنا وقت لگتا ہے، ایک انجینئر کو ہفتے میں کتنے شعبوں کے بیچ سیاق بدلنا پڑتا ہے، اور ٹیم کے دائرے کے کونوں میں واقعات کی بڑھتی شرح۔ بڑے ادارے کے لیے یہ اس لیے اہم ہے کہ زیر بار ٹیمیں خاموشی سے رکاوٹ بن جاتی ہیں جن کی پیش گوئی کوئی تنظیم نو کا خاکہ نہیں کرتا۔ یہ اعداد بحث میں لائیں، ساتھ ٹیم کا اپنا احساس کہ وہ ذہن میں کیا رکھ سکتی ہے اور کیا نہیں۔ اگر اشارے زیر بار ہونے کا کہیں تو قدم یہ ہے کہ غیر امتیازی کام پلیٹ فارم یا معاون ٹیم پر منتقل کیا جائے، نہ کہ مزید ہیرو پرستی کا مطالبہ۔

2. کیا یہاں تنظیم نو واقعی خلل کے قابل ہے، یا آپ تنظیم نو کی لت کو کھلا رہے ہیں؟ الٹی کانوے چال لاگو کرنے کے لیے حدود دوبارہ کھینچنا طاقتور ہے، اور ہر تنظیم نو ٹیموں کو جمنے کے لیے درکار استحکام بھی تباہ کرتی ہے اور مشکل سے کمایا ہوا شعبے کا علم دوبارہ صفر کر دیتی ہے۔ متصادم تقاضے موجودہ ساخت کا مسلسل ہم آہنگی محصول بمقابلہ اسے بدلنے کی ایک بار کی لاگت اور حوصلے کا نقصان ہیں۔ انٹرپرائز اور سرکاری ماحول میں خریداری کی حدود، ٹھیکیدار ٹیمیں اور لازمی فرائض کی علیحدگی تنظیم نو کو سست اور مہنگا بناتی ہیں، اس لیے معیار اونچا ہونا چاہیے۔ انحصار سے پیدا ہونے والی تاخیر کے شواہد لائیں: کتنے اقدامات کسی دوسری ٹیم کے انتظار میں رکے ہیں، اور کتنی دیر سے۔ تنظیم نو تب کریں جب یہ انتظار ساختی اور بڑا ہو، اور تب نہ کریں جب تکلیف عارضی ہو یا اندرونی سورس کی شراکتوں اور واضح انٹرفیسز سے سستے میں حل ہو سکتی ہو۔

3. سلامتی، ڈیٹا اور ڈیزائن کے لیے، کون سا واقعہ آپ کو جڑے ہوئے، وفاقی اور مرکزی ماڈل کے درمیان منتقل ہونے پر آمادہ کرے گا؟ باب کی سفارش ہر شعبے اور ہر پیمانے کے لیے الگ چننا ہے، اور مشکل نظم و ضبط یہ پہلے سے طے کرنا ہے کہ کون سی ترقی یا خطرہ اس انتخاب پر نظر ثانی کرائے گا۔ جو ماڈل پچاس انجینئروں کے لیے ٹھیک بیٹھتا ہے وہ پانچ سو پر رکاوٹ یا یکسانیت کی تباہی بن سکتا ہے، اور انٹرپرائز اور سرکاری اداروں کو خاص طور پر ان معیارات کا نام لینا چاہیے جو ایک چھوٹا مرکزی مرکز ہمیشہ اپنے پاس رکھے گا۔ ہر شعبے کے موجودہ قطار کے اوقات اور یکسانیت کے خلا لائیں: ہفتوں لمبی ریویو قطار والی مرکزی سلامتی ٹیم وفاقی بننے کی علامت ہے، جبکہ جڑے ہوئے ماہرین کا ناہم آہنگ ڈیٹا ماڈل بنانا مرکزی معیاراتی مرکز شامل کرنے کی علامت ہے۔ محرک ابھی طے کریں، جیسے قطار کی لمبائی کی حد یا آڈٹ کا نتیجہ، تاکہ تبدیلی بحران کے ردعمل کے بجائے منصوبہ بند ارتقا بنے۔ جواب طے کرے گا کہ آپ پکی سڑکوں اور چیمپئنز میں سرمایہ کاری کہاں کریں اور مرکزی حب میں کہاں۔

4. آپ کیسے جانیں گے کہ آپ کی پلیٹ فارم ٹیم واقعی ذہنی بوجھ کم کر رہی ہے یا خاموشی سے دربان بن رہی ہے؟ پلیٹ فارم اس لیے ہے کہ خود سروس کے ذریعے تعمیل والا، قابل اعتماد انتخاب آسان بنائے، اور وہی ٹیم ٹولز مسلط کرنے، ہر درخواست ہاتھ سے دیکھنے، اور وہی رگڑ بڑھانے کی طرف بھٹک سکتی ہے جو اسے ختم کرنی تھی۔ بڑے ادارے کے لیے یہ فرق طے کرتا ہے کہ پلیٹ فارم کی سرمایہ کاری وصول ہوتی ہے یا ایسی مرکزی رکاوٹ بن جاتی ہے جس کے پیچھے ہر اسٹریم الائنڈ ٹیم قطار لگاتی ہے۔ متصادم تقاضے ایک طرف یکسانیت اور کنٹرول ہیں، دوسری طرف صارف کی خود مختاری اور بہاؤ۔ ایسے شواہد لائیں جنہیں صارف پہچانے: ٹکٹ کھولے بغیر اسٹریم الائنڈ ٹیم کو نیا ماحول یا پائپ لائن خود سروس کرنے میں کتنا وقت لگتا ہے، خود سروس کارروائیوں اور انسان کی ثالثی والی کارروائیوں کا تناسب، اور پلیٹ فارم کا اپنانا ان ٹیموں سے ناپا جائے جو اسے چنتی ہیں، ان سے نہیں جنہیں اس پر مجبور کیا گیا۔ انٹرپرائز اور سرکاری ماحول میں اصرار کریں کہ پلیٹ فارم آڈٹ اور تعمیل کے شواہد دستی دروازوں کے بجائے خود بخود پیدا کرے، کیونکہ جو پلیٹ فارم فرائض کی علیحدگی کے قواعد انسانی ریویور ڈال کر پورے کرتا ہے اس نے وہی رکاوٹ دوبارہ بنا دی جسے تحلیل کرنے کے لیے اسے فنڈ ملا تھا۔

5. آپ کے کون سے بین ٹیم رشتے مستقل تعاون میں بدل چکے ہیں، اور ہر ایک کو صاف سروس انٹرفیس یا نئی کھینچی گئی حد میں کیا چیز بدلے گی؟ تعاون کا طریقہ شدید اور عارضی ہونا چاہیے، اور کبھی ختم نہ ہونے والی جوڑی عموماً اس بات کی علامت ہے کہ ملکیت غلط جگہ ہے یا دو ٹیموں کے درمیان انٹرفیس کبھی واضح کیا ہی نہیں گیا۔ بڑے پیمانے پر یہ اس لیے اہم ہے کہ بے نام، مستقل تعاون وہ جگہ ہے جہاں ہم آہنگی کی لاگت چھپتی ہے: یہ کسی تنظیمی چارٹ پر نہیں آتی، پھر بھی ان دونوں ٹیموں کی چھوئی ہر تبدیلی پر محصول لگاتی ہے۔ متصادم تقاضے قریب رہنے کی دریافتی قدر بمقابلہ رشتے کو واضح انٹرفیس والے X-as-a-service معاہدے میں بدلنے، یا ذمہ داری ایک ٹیم میں ضم کرنے سے ملنے والا بہاؤ ہیں۔ ان ٹیم جوڑوں کی فہرست لائیں جو ایک سہ ماہی سے زیادہ مسلسل تعاون کر رہی ہیں، پچھلے چند مہینوں کی وہ تبدیلیاں جن میں دونوں ٹیمیں درکار تھیں، اور یہ کہ کیا ان کے بیچ مستحکم انٹرفیس لکھا جا سکتا ہے۔ انٹرپرائز اور سرکاری سیاق میں، جہاں ٹھیکیدار کی حدود اور خریداری کے حصے حوالگی کو برسوں جامد کر سکتے ہیں، نام لیں کہ کون سے رشتے آپ انٹرفیس اور اندرونی سورس شراکتوں سے بدل سکتے ہیں اور کون سے معاہدے کے لحاظ سے طے شدہ ہیں اور انہیں واضح انحصار کے طور پر سنبھالنا ہوگا۔

6. جب معاون ٹیم دوسری ٹیم کو صلاحیت بنانے میں مدد دے تو آپ کیسے جانیں گے کہ وہ کامیاب ہو گئی اور پیچھے ہٹ سکتی ہے، مستقل انحصار بننے کے بجائے؟ معاون ٹیمیں اسٹریم الائنڈ ٹیم کو ٹیسٹنگ، سلامتی یا مشاہدہ پذیری میں مہارت دلانے کی کوچنگ کے لیے ہیں اور پھر آگے بڑھ جانے کے لیے، اور واضح اخراجی شرط کے بغیر کوچنگ کا رشتہ ایسی مستقل خدمت میں سخت ہو جاتا ہے جسے اسٹریم الائنڈ ٹیم کبھی جذب نہیں کرتی۔ بڑے ادارے کے لیے یہ اس فرق کا نام ہے کہ صلاحیت درجنوں ٹیموں میں پھیلتی ہے یا نئی مشترک رکاوٹ بنتی ہے جو ہر سال بدتر پھیلتی ہے۔ متصادم تقاضے ماہر ٹیم کی دی ہوئی گہرائی اور یکسانیت بمقابلہ وہ خود مختاری اور شروع سے آخر تک ملکیت ہیں جو آپ اسٹریم الائنڈ ٹیموں میں بنانا چاہتے ہیں۔ صلاحیت کی منتقلی کے شواہد لائیں: کیا وصول کرنے والی ٹیم اب معاون ٹیم کی موجودگی کے بغیر کام سنبھال لیتی ہے، مقررہ معاون گروپ بیک وقت کتنی ٹیموں سے وابستہ ہے، اور ہر مصروفیت اپنی ارادی حوالگی سے کتنی آگے چل چکی ہے۔ انٹرپرائز اور سرکاری ماحول میں، جہاں نایاب ماہرانہ مہارت ایک مرکزی ٹیم یا ایک معاہدے کے پیچھے ہو سکتی ہے، پہلے سے طے کریں کہ صلاحیت کی منتقلی اور چیمپئنز کو کیسے فنڈ کریں تاکہ مہارت ترسیلی ٹیموں میں پھیلے اور اس قطار کے پیچھے بند نہ رہے جس کا ہر آڈٹ اور ریلیز کو انتظار کرنا پڑتا ہے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ مٹھی بھر انجینئروں اور کم رن وے کے ساتھ، درست ٹاپولوجی ایک واحد اسٹریم الائنڈ ٹیم ہے جو پوری پروڈکٹ کی مالک ہو، اور نظم و ضبط یہ ہے کہ ضرورت پڑنے سے پہلے سائلو نہ بنائیں۔ اکیلے “DevOps” یا “QA” شخص کی بھرتی سے بچیں جو دروازہ بن جائے؛ ان مہارتوں کو اس ایک ٹیم میں جڑی ہوئی صلاحیت کے طور پر ضم کریں۔ ادارے کو چپٹا رکھ کر کانوے کے قانون کو اپنے حق میں چلائیں، تاکہ فن تعمیر اتنا ہی سادہ اور بدلنے کے قابل رہے جتنی ٹیم۔

چھوٹا کاروبار۔ آپ مخصوص پلیٹ فارم یا معاون ٹیم نہیں رکھ پائیں گے، اس لیے پلیٹ فارم خریدیں: اپنی ایک دو ٹیموں سے غیر امتیازی ذہنی بوجھ اتارنے کے لیے منظم کلاؤڈ سروسز، میزبانی والی پائپ لائنیں اور تیار شدہ سلامتی ٹولنگ استعمال کریں۔ سلامتی اور ڈیٹا جیسے مشترک معاملات کو ایسی چیز سمجھیں جسے آپ ترتیب دیتے اور استعمال کرتے ہیں، کوئی شعبہ نہیں جو آپ بنائیں۔ مخصوص ملکیت صرف اس ایک پیچیدہ ذیلی نظام کے لیے رکھیں جو واقعی آپ کو ممتاز کرتا ہے، اور باقی فروخت کنندگان کو اٹھانے دیں۔

بڑا ادارہ۔ بڑے پیمانے پر مسئلہ بہت سی ٹیموں کے درمیان ہم آہنگی کی لاگت ہے، اس لیے ٹاپولوجی کو واضح اور منظم ڈیزائن بنائیں: چار ٹیم اقسام کی مشترک درجہ بندی، نام زد تعامل کے طریقے، پکی سڑک والا پلیٹ فارم، اور بین ٹیم قطاریں کم کرنے کے لیے اندرونی سورس۔ انحصار سے پیدا ہونے والی تاخیر اور ٹیم کے ذہنی بوجھ کو پورٹ فولیو اشاریوں کے طور پر ٹریک کریں، اور تنظیم نو کو سالانہ ردعمل کی بجائے اونچے معیار کے ساتھ سوچے سمجھے ارتقا کے طور پر چلائیں۔ ایک پتلا مرکزی مرکز ان معیارات کو رکھتا ہے جو یکساں ہونے چاہئیں، جبکہ اسٹریم الائنڈ ٹیمیں ترسیل پر خود مختار رہتی ہیں۔

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

مثالیں

اسٹارٹ اپ۔ دس افراد کے ایک اسٹارٹ اپ میں ایک اسٹریم الائنڈ ٹیم ہے جو پوری پروڈکٹ کی شروع سے آخر تک مالک ہے، جو اس کے پیمانے پر بالکل درست ہے: کوئی حوالگی نہیں، کوئی ہم آہنگی محصول نہیں، سب ایک ہی سیاق میں شریک ہیں۔ مسئلہ تب شروع ہوتا ہے جب وہ ایک مخصوص “DevOps شخص” اور ایک الگ “QA شخص” بھرتی کرتے ہیں اور اتفاقاً فعلی سائلو دوبارہ بنا لیتے ہیں، یوں اب ہر ریلیز دو افراد کا انتظار کرتی ہے۔ وہ ان بھرتیوں کو اس ایک ٹیم کے اندر جڑی ہوئی پلیٹ فارم اور ٹیسٹنگ صلاحیت سمجھ کر راہ درست کرتے ہیں، ان دروازوں کی طرح نہیں جن سے کام گزرے۔ اس حجم پر سب سے سستی ٹاپولوجی وہ ہے جو سب کو ایک ہی بہاؤ میں رکھے۔

بڑا ادارہ۔ ایک بڑے خوردہ فروش کا چیک آؤٹ بدلنے میں سست تھا کیونکہ فرنٹ اینڈ، بیک اینڈ اور فلفلمنٹ کی منطق تین فعلی طور پر منظم ٹیموں میں بٹی تھی، جس سے ہر تبدیلی تین بیک لاگز سے گزرتی تھی۔ الٹی کانوے چال اپنا کر انہوں نے صارف کے سفروں (“براؤز”، “کارٹ اور چیک آؤٹ”، “خریداری کے بعد”) کے گرد اسٹریم الائنڈ ٹیمیں بنا دیں، ہر ایک اپنے حصے کی آگے سے پیچھے تک مالک، اور ان کے پیچھے ایک پلیٹ فارم ٹیم جو تعیناتی اور مشاہدہ پذیری بطور سروس فراہم کرتی تھی۔ چیک آؤٹ کی جو تبدیلیاں ایک سہ ماہی لیتی تھیں، دنوں میں ریلیز ہونے لگیں، کیونکہ جو ہم آہنگی پہلے ٹیموں میں پھیلی تھی وہ اب ایک ہی ٹیم کے اندر ہوتی تھی۔

حکومت۔ ایک سرکاری ٹیکس ایجنسی میں مرکزی سلامتی ٹیم ہر ریلیز کا جائزہ لیتی تھی، جس سے ہفتوں لمبی قطار بنتی اور اہم اصلاحات میں تاخیر ہوتی۔ انہوں نے وفاقی ماڈل اپنایا: ایک چھوٹا مرکزی سلامتی شعبہ معیارات طے کرتا اور پہلے سے منظور شدہ، خود بخود اسکین ہونے والی پائپ لائنوں کی “پکی سڑک” فراہم کرتا، جبکہ ہر ترسیلی ٹیم میں جزوی وقت کے لیے شامل سلامتی چیمپئنز روزمرہ فیصلے سنبھالتے۔ پلیٹ فارم تعمیل کے شواہد خود بخود پیدا کرتا تھا۔ فرائض کی علیحدگی کے لازمی تقاضے پھر بھی پورے ہوئے، مگر انسانی رکاوٹ کے بجائے ٹولنگ اور واضح انٹرفیسز کے ذریعے، جس سے ریلیز کا لیڈ ٹائم ڈرامائی طور پر کم ہوا اور آڈٹ کی تیاری بہتر ہوئی۔

کاروباری جواز: محرکات، ROI اور TCO

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

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

ضد نمونے اور خامیاں

• کانوے کے قانون کو نظر انداز کرنا: ایسا فن تعمیر ڈیزائن کرنا جو ادارے کی ساخت فراہم نہ کر سکے۔
• فعلی سائلو: الگ فرنٹ اینڈ، بیک اینڈ، QA اور آپس ٹیمیں جو ہر تبدیلی کے لیے ہم آہنگ ہونے پر مجبور ہوں۔
• مشترک خدمات کی رکاوٹ: ایک مرکزی ٹیم جس کے پیچھے ہر منصوبے کو قطار لگانی پڑے۔
• دربان کے طور پر پلیٹ فارم: ایسی پلیٹ فارم ٹیم جو خدمت کرنے کے بجائے حکم دے، رگڑ ختم کرنے کے بجائے بڑھائے۔
• ذہنی بوجھ کی زیادتی: ٹیمیں جو پھیلے ہوئے غیر متعلقہ نظاموں کی مالک ہوں جن میں وہ مہارت حاصل نہیں کر سکتیں۔
• مستقل “تعاون”: دو ٹیمیں ہمیشہ الجھی ہوئی، جو غلط جگہ کی حد کی علامت ہے۔
• تنظیم نو کی لت: مسلسل ادل بدل، جو ٹیموں کے جمنے کے لیے درکار استحکام تباہ کرتی ہے۔

پختگی کا ماڈل

• سطح 1، آغاز۔ ٹیمیں اتفاق، سروں کی گنتی یا وراثتی درجہ بندی سے بنتی ہیں؛ کوئی ٹیم اقسام یا تعامل کے طریقوں کا نام نہیں لیتا؛ فعلی سائلو اور مشترک خدمات کی رکاوٹیں ہر جگہ ہیں اور انحصارات اس وقت تک چھپے رہتے ہیں جب تک کسی ریلیز کو نہ روک دیں۔
• سطح 2، ترقی۔ کچھ اسٹریم الائنڈ ٹیمیں موجود ہیں اور پہلی پلیٹ فارم یا اندرونی سورس کوشش ظاہر ہوتی ہے، مگر نمونہ ناہموار طور پر لاگو ہے: چند ٹیمیں اپنا حصہ شروع سے آخر تک رکھتی ہیں جبکہ دوسری اب بھی مرکزی شعبوں کے پیچھے قطار میں ہیں، اور ذہنی بوجھ کو منظم کرنے کے بجائے محض قصوں میں زیر بحث لایا جاتا ہے۔
• سطح 3، معیار بندی۔ چار ٹیم اقسام اور تین تعامل کے طریقے دستاویزی ہیں اور پورے ادارے میں سوچ سمجھ کر استعمال ہوتے ہیں؛ پلیٹ فارم اور اندرونی سورس ٹیموں کے درمیان انحصارات ہلکے کرتے ہیں؛ سلامتی، ڈیٹا اور ڈیزائن کا آپریٹنگ ماڈل چنا اور لکھا گیا ہے، اور نئی ٹیمیں فی البدیہہ کے بجائے انہی معیارات کے مطابق بنتی ہیں۔
• سطح 4، انتظام۔ ٹاپولوجی کو بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے: ٹیمیں ذہنی بوجھ، انحصار سے پیدا ہونے والی تاخیر (کتنے اقدامات کسی دوسری ٹیم کے انتظار میں رکے ہیں، اور کتنی دیر سے)، پلیٹ فارم کی خود سروس شرح اور اپنانا، تعامل کے طریقے کا دورانیہ، اور ترسیل کے بہاؤ کے اشاریے جیسے لیڈ ٹائم اور تبدیلی کی تعدد ٹریک کرتی ہیں۔ حدیں عمل کو متحرک کرتی ہیں، مثلاً قطار کی وہ لمبائی جو کسی شعبے کو وفاقی بننے پر مجبور کرے یا مستقل تعاون جو غلط جگہ کی حد کی نشاندہی کرے، اس طرح فیصلے رائے کے بجائے شواہد پر ٹکتے ہیں۔
• سطح 5، ہم آہنگی۔ ٹیم کا ڈیزائن مسلسل بہتر ہوتا ہے اور فن تعمیر، پروڈکٹ اور خطرے کی منصوبہ بندی سے جڑا ہے؛ ادارہ نظام اور کاروبار کے ارتقا کے ساتھ حدود دوبارہ ڈھالتا ہے، صلاحیت منتقل ہو جانے پر معاون مصروفیات ختم کرتا ہے، اور ذہنی بوجھ بدلنے پر پلیٹ فارم کی سرمایہ کاری کا توازن بدلتا ہے، تیز بہاؤ کو ایک بار کی تنظیم نو کے بجائے مستقل، لچکدار خاصیت کے طور پر برقرار رکھتا ہے۔

بحث کے لیے خیالات

• ایک عام تبدیلی کے لیے کتنی ٹیموں کو ہم آہنگ ہونا پڑتا ہے، اور کیوں؟
• ہماری کون سی ٹیمیں بہت زیادہ ذہنی بوجھ اٹھائے ہوئی ہیں، اور پلیٹ فارم کیا اتار سکتا ہے؟
• ہم کہاں حدود دوبارہ کھینچنے کے بجائے کانوے کے قانون سے لڑ رہے ہیں؟
• کیا ہماری پلیٹ فارم ٹیمیں اسٹریم الائنڈ ٹیموں کی خدمت کر رہی ہیں یا ان کی دربانی؟
• کیا ابھی ہمارے لیے سلامتی، ڈیٹا اور ڈیزائن مرکزی، وفاقی یا جڑے ہوئے ہونے چاہئیں؟
• کون سے “عارضی” تعاون خاموشی سے مستقل انحصار بن چکے ہیں؟

اہم نکات

• ادارے کی ساخت فن تعمیر اور ترسیل کی رفتار طے کرتی ہے؛ اسے سوچ سمجھ کر ڈیزائن کریں۔
• چار ٹیم اقسام استعمال کریں، اسٹریم الائنڈ کو ڈیفالٹ اور باقی کو مدد کے طور پر۔
• مطلوبہ فن تعمیر کو آسان راستہ بنانے کے لیے الٹی کانوے چال اپنائیں۔
• ذہنی بوجھ کو سنبھالیں؛ ہر ٹیم کو اس شعبے تک محدود رکھیں جس میں وہ مہارت حاصل کر سکے۔
• بین ٹیم تعامل کے طریقوں کو محدود اور نام زد کریں؛ طول پکڑتے انحصارات کو حدود کی خرابی سمجھیں۔
• مشترک شعبوں کے لیے پیمانے کے مطابق مرکزی، وفاقی یا جڑا ہوا ماڈل چنیں، اور قطاریں کم کرنے کے لیے InnerSource استعمال کریں۔

حوالہ جات اور مزید مطالعہ

• Matthew Skelton and Manuel Pais, “Team Topologies: Organising Business and Technology Teams for Fast Flow”
• Melvin Conway, “How Do Committees Invent?” (the origin of Conway’s Law)
• Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate”
• Will Larson, “An Elegant Puzzle: Systems of Engineering Management”
• Sam Newman, “Building Microservices” (on aligning services to teams)
• Danese Cooper and Klaas-Jan Stol, “Adopting InnerSource,” and the InnerSource Commons patterns
• Frederick Brooks, “The Mythical Man-Month” (communication overhead)