مضمون کا ترجمہ خاص طور پر کورس کے طلباء کے لیے تیار کیا گیا تھا۔ .
انٹرکام کا مشن آن لائن کاروبار کو ذاتی بنانا ہے۔ لیکن جب کسی پروڈکٹ کے کام نہ ہو تو اسے ذاتی بنانا ناممکن ہے۔ . اپ ٹائم ہمارے کاروبار کی کامیابی کے لیے اہم ہے، نہ صرف اس لیے کہ ہمارے کلائنٹ ہمیں ادائیگی کرتے ہیں، بلکہ اس لیے بھی کہ ہم استعمال کرتے ہیں۔ . اگر ہماری سروس کام نہیں کرتی ہے، تو ہم لفظی طور پر اپنے صارفین کے درد کو محسوس کرتے ہیں۔
بلاتعطل آپریشن کا انحصار بہت سے عوامل پر ہوتا ہے، جیسے کہ سافٹ ویئر کی تعمیر اور روزمرہ کے کام کا معیار۔ تاہم، اکثر یہ حقیقت سامنے آتی ہے کہ جو شخص ہمیشہ رابطے میں رہتا ہے وہ کال کا جواب دیتا ہے۔ . یہ تکنیکی معاونت ایک طاقتور کسٹمر فوکسڈ ٹول ہو سکتا ہے جو انجینئرز کی مدد کو اس کے ساتھ جوڑتا ہے جو گاہک آپ کی پروڈکٹ خریدنے پر حاصل کرتے ہیں۔ یہ سیکھنے اور ترقی کے لیے ایک بہترین موقع بھی کھولتا ہے، کیوں کہ آخر کار، ناکامیاں اور غلطیاں مہارتوں کی مشق کرنے اور کام کرنے کے پیچیدہ طریقہ کار کو سمجھنے کے لیے ایک اچھا میدان ثابت ہو سکتی ہیں۔
کام کے اوقات سے باہر "ہمیشہ رابطے میں" رہنا آپ کی زندگی کے لیے نقصان دہ ہے۔
لیکن ایک ہی وقت میں، "ہمیشہ جڑے" رہنے سے آپ کی زندگی پر نقصان دہ اثر پڑ سکتا ہے۔ آپ کو اس اطلاع کا فوری اور قابلیت سے جواب دینے کے لیے تیار ہونا چاہیے کہ کچھ ٹوٹ گیا ہے۔ یہاں تک کہ اگر آپ کو اس خاص لمحے پر صفحہ نہیں بنایا جا رہا ہے، تو "ہمیشہ آن" حالت بے چینی کا احساس پیدا کرتی ہے، اور میں یہ ذاتی تجربے سے جانتا ہوں۔ خاص طور پر اس کی وجہ سے نیند کا معیار خراب ہو جاتا ہے۔ دن کے کسی بھی وقت ایکسیس زون میں باقاعدگی سے رہنا برن آؤٹ، بے حسی، یا عام طور پر، کمپیوٹر کو دوبارہ کبھی نہ دیکھنے کی خواہش کا باعث بن سکتا ہے۔
انٹرکام میں "ہمیشہ منسلک" حالت کی تاریخ
انٹرکام کے ابتدائی دنوں میں، ہمارے CTO Ciaran اکیلے ہی پوری XNUMX/XNUMX تکنیکی مدد کی ٹیم تھی، دفتر کے اندر اور باہر۔ جیسے جیسے انٹرکام بڑھتا گیا، سیاران کی مدد کے لیے ایک ٹاسک فورس بنائی گئی۔ اس کے فوراً بعد، نئی ترقیاتی ٹیموں نے بہت سی نئی خصوصیات اور خدمات بنانا شروع کر دیں، اور انہوں نے پہلے ہی تکنیکی معاونت کی تمام ذمہ داریاں سنبھال لیں۔
کسی بھی لمحے "لائن پر" بہت زیادہ لوگ موجود تھے۔
اس وقت، یہ نقطہ نظر ایک غیر ذہین کی طرح لگتا تھا، کیونکہ یہ ہماری تکنیکی مدد کی ٹیم کو کسی بھی وقت اسکیل کرنے کا ایک آسان طریقہ تھا، یہ ہماری اقدار کے مطابق تھا، اور اس نے ہماری حوصلہ افزائی کی۔ . نتیجے کے طور پر، بغیر کسی منصوبے کے، ہم چار یا پانچ ٹیموں کے ساتھ ختم ہوئے جو اپنے غیر کام کے اوقات کے دوران گاہکوں سے باقاعدگی سے رابطہ کرتی تھیں۔ باقی ترقیاتی ٹیموں کے پاس بہت مشکل پوائنٹس نہیں تھے جو غلطی کر سکتے تھے، اس لیے انہیں شاذ و نادر ہی، اگر کبھی، بلایا جاتا تھا۔
ہم نے محسوس کیا کہ ہم ایسی صورت حال میں تھے جہاں ہمارے پاس تکنیکی مدد کے میکینکس تھے جن پر فخر کیا جاسکتا تھا اور بہت سے اہم مسائل تھے جنہیں ہم حل کرنا چاہتے تھے، جیسے:
- کسی بھی وقت، بہت سارے لوگ چیلنج لینے کے لیے تیار تھے۔ ہمارا انفراسٹرکچر اتنا بڑا نہیں تھا کہ کم از کم پانچ ڈویلپمنٹ انجینئرز کی ضرورت ہو جو عام دنوں کی چھٹی کے بغیر کام کریں۔
- ہمارے انتباہات اور کال کرنے کے طریقہ کار کا معیار ٹیموں میں یکساں نہیں تھا، ہم نے نئے اور موجودہ مسائل کے انتباہات کے لیے ایڈہاک جائزہ کے عمل کا استعمال کیا۔ رن بک میں ہدایات (جب کوئی مسئلہ اٹھایا جائے تو اس پر عمل کیا جائے) زیادہ تر ان کی غیر موجودگی کی وجہ سے نمایاں تھے۔
- انجینئرز نے جس ٹیم کے لیے کام کیا اس پر انحصار کرتے ہوئے، ان کی متضاد توقعات تھیں۔ مثال کے طور پر، صرف پہلی ٹیکنیکل سپورٹ ٹیم کو ڈیوٹی شفٹوں اور تعطیلات میں خلل ڈالنے کے لیے کوئی معاوضہ حاصل تھا۔
- معلوم ہوا کہ طاق اوقات میں غیر ضروری کالوں کے لیے رواداری کی عمومی سطح ہے۔
- آخر میں، اس قسم کا کام ہر کسی کے لیے نہیں ہے۔ زندگی کے حالات نے بعض اوقات یہ ظاہر کیا کہ ڈیوٹی پر شفٹوں سے لوگوں کو بہترین طریقے سے متاثر نہیں ہوتا ہے۔
"ہمیشہ منسلک" کی صحیح حالت تلاش کرنا
ہم نے ایک نئی ورچوئل ٹیم بنانے کا فیصلہ کیا ہے جو ہر ٹیم کی تکنیکی معاونت کا کام کرے گی جب ان کے پاس اوقات نہیں ہوں گے۔ ٹیم رضاکاروں پر مشتمل ہو گی، تنظیم میں کسی بھی ٹیم سے بھرتی نہیں ہوگی۔ ورچوئل ٹیم کے انجینئر ہر چھ ماہ بعد گھومتے ہیں، ہفتے "رابطے میں" گزارتے ہیں۔ خوش قسمتی سے، ہمیں ورچوئل ٹیم کو اکٹھا کرنے کے لیے کافی رضاکار تلاش کرنے میں کوئی دقت نہیں ہوئی۔
نتیجے کے طور پر، ہماری سپورٹ ٹیم 30 افراد سے گھٹ کر صرف 6 یا 7 رہ گئی۔
اس کے بعد ٹیم نے اتفاق کیا اور وضاحت کی کہ ایشو الرٹس اور رن بک کی تفصیل کس طرح کی ہونی چاہیے، اور نئی سپورٹ ٹیم کو الرٹس کو آگے بھیجنے کے عمل کا خاکہ پیش کیا۔ انہوں نے Terraform ماڈیول کا استعمال کرتے ہوئے کوڈ میں تمام انتباہات کی نشاندہی کی، اور ہر تبدیلی کے لیے ہم مرتبہ کا جائزہ لینا شروع کیا۔ ہم نے ہفتہ وار شفٹ کے لیے معاوضے کی ایک سطح متعارف کرائی جو ڈیوٹی افسران کے لیے کافی مناسب تھی۔ ہم نے ایک بڑھے ہوئے دوسرے درجے کی ٹیم بھی بنائی، جو صرف مینیجرز پر مشتمل تھی۔ یہ کمانڈ ٹیکنیکل سپورٹ انجینئرز کے لیے اضافہ کا واحد نقطہ ہونا چاہیے۔
ہمارے پاس کئی ماہ کی محنت تھی جس کے دوران ہم نے یہ عمل قائم کیا، جس کے نتیجے میں، اب پہلے کی طرح 30 انجینئرز رابطے میں نہیں رہے، بلکہ صرف 6 یا 7۔ اس وقت عام طور پر سب سے زیادہ خرابیاں ہوتی ہیں، لیکن باقی وقت تکنیکی مدد رضاکاروں کے ذریعے ہینڈل کی جاتی ہے۔
ہم نے کیا سیکھا ہے۔
ہم نے اپنی ورچوئل ٹیکنیکل سپورٹ ٹیم کو شروع کرنے کے بعد، ہمیں نئے کاموں کے سیلاب کی توقع تھی، جیسے مسائل کی وجوہات کی چھان بین کرنا یا کسی ایک مسئلے کو حل کرنے کے لیے ایک عام اجتماع جس کی وجہ سے حادثہ پیش آیا۔ تاہم، ہماری ڈیولپمنٹ ٹیموں نے کریشوں کا سبب بننے والے عوامل کی پوری ذمہ داری قبول کی، اور اس کے بعد آنے والا کوئی بھی ردعمل عام طور پر فوری کارروائی تھا۔ ہمیں اس صورتحال سے بچنے کی بھی ضرورت تھی جس میں تکنیکی مشاورت کا کام اس ٹیم کو واپس کر دیا جائے جس سے وہ آئی تھی، تاکہ انجینئرز کو گھنٹوں بعد رابطہ کرنے پر مجبور نہ کیا جائے۔
اوقات سے باہر کی کالیں ماہانہ 10 سے کم کر دی گئی ہیں۔
رسمی طور پر، ہمارے بڑھنے کا عمل شاذ و نادر ہی استعمال ہوتا تھا۔ زیادہ عام خیال یہ تھا کہ انجینئر کی غیر سرکاری طور پر اس ٹیم کی مدد کی گئی جو فی الحال آن لائن تھی، خاص طور پر سان فرانسسکو کے دفتر میں ہمارے لوگ۔ ٹیم ورک اور آن دی فلائی ریزولوشن کے ذریعے بہت سے مسائل کو طے یا کم کیا گیا ہے۔
ہمارے سان فرانسسکو آفس میں انجینئرز ٹیم میں ایک مکمل ٹیم کے طور پر شامل ہوتے ہیں اور باقاعدہ تکنیکی مدد سے آگے بڑھتے ہیں۔ اس میں کچھ اوور ہیڈز شامل تھے، لیکن متعدد مقامات پر ہماری سپورٹ ٹیم کی رکنیت کو بڑھانے سے ہمارے حق میں کام ہوا ہے کیونکہ یہ تعلقات استوار کرنے، انہیں مضبوط کرنے اور ٹیکنالوجی کے اسٹیک کے بارے میں مزید جاننے کا ایک اچھا طریقہ ثابت ہوا ہے جس کے ساتھ ہم سب کام کرتے ہیں۔
ہماری ٹیموں میں، انٹرکام ڈویلپرز کا کام زیادہ مستقل ہو گیا ہے، اور ہم اپنی ویب سائٹ پر سسٹم انجینئر کے عہدے کے فوائد کے بارے میں اعتماد کے ساتھ بات کر سکتے ہیں۔ یہ بتاتے ہوئے کہ اگر آپ خود نہیں چاہتے ہیں تو ہمیشہ رابطے میں رہنے کی ضرورت نہیں ہے۔
ہمارے ڈیٹا گوداموں کو مستحکم کرنے اور اسکیل کرنے کے بنیادی کام کے ساتھ ساتھ، مسائل کے حل پر مسلسل توجہ دینے کے نتیجے میں باہر کی کالیں ماہانہ 10 سے کم ہو گئی ہیں۔ ہمیں اس نمبر پر بہت فخر ہے۔
ہم اپنی تکنیکی معاونت کی ٹیم کو برقرار رکھنے اور بہتر بنانے پر کام کرتے رہتے ہیں، اور جیسے جیسے انٹرکام بڑھتا ہے ہمیں اپنے فیصلوں پر نظر ثانی کرنے کی ضرورت پڑ سکتی ہے، کیونکہ جو آج کام کرتا ہے ضروری نہیں کہ اگلی بار ہمارے عملے کی تعداد دوگنی ہو جائے۔ تاہم، یہ تجربہ ہماری تنظیم کے لیے انتہائی مثبت رہا ہے، جس سے ہمارے ترقیاتی انجینئرز کے معیار زندگی، چیلنجز کے لیے ہمارے ردعمل کے معیار اور سب سے بڑھ کر ہمارے صارفین کے تجربے میں بہتری آئی ہے۔
ماخذ: www.habr.com