کس چیز نے ہمیں نئے حالات میں آن لائن ٹریڈنگ کو تیزی سے ڈھالنے میں مدد کی۔

ہیلو!

میرا نام میخائل ہے، میں اسپورٹ ماسٹر کمپنی میں آئی ٹی کا ڈپٹی ڈائریکٹر ہوں۔ میں اس کہانی کو شیئر کرنا چاہتا ہوں کہ ہم نے وبائی امراض کے دوران پیدا ہونے والے چیلنجوں سے کیسے نمٹا۔

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

بنیادی طور پر، جو بنیادی طور پر ہمارا سائیڈ آپریشن تھا وہ ہمارا بنیادی کاروبار بن گیا۔ ہر آن لائن آرڈر کی اہمیت بہت بڑھ گئی ہے۔ یہ ہر روبل کو بچانے کے لئے ضروری تھا جو کلائنٹ کمپنی میں لایا تھا. 

صارفین کی درخواستوں کا فوری جواب دینے کے لیے، ہم نے کمپنی کے مرکزی دفتر میں ایک اضافی رابطہ مرکز کھولا، اور اب ہر ہفتے تقریباً 285 ہزار کالیں موصول ہو سکتی ہیں۔ اسی وقت، ہم نے 270 اسٹورز کو ایک نئے کنٹیکٹ لیس اور محفوظ آپریٹنگ فارمیٹ میں منتقل کیا، جس سے صارفین کو آرڈرز اور ملازمین کو اپنی ملازمتیں برقرار رکھنے کی اجازت ملی۔

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

آن لائن خدمات کا آپریشن

Kolesnikov Sergey، آن لائن سٹور اور مائیکرو سروسز کے آپریشن کے ذمہ دار ہیں۔

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

18 مارچ سے 31 مارچ تک آرڈرز کی تعدادآن لائن ادائیگی مائیکرو سروسز کے لیے درخواستوں کی تعدادویب سائٹ پر آرڈرز کی تعداد

پہلے گراف میں ہم دیکھتے ہیں کہ اضافہ تقریباً 14 گنا تھا، دوسرے میں - 4 گنا۔ ہم اپنی درخواستوں کے رسپانس ٹائم میٹرک کو سب سے زیادہ اشارے سمجھتے ہیں۔ 

اس گراف میں ہم محاذوں اور ایپلی کیشنز کا ردعمل دیکھتے ہیں، اور خود ہم نے طے کیا کہ ہمیں اس طرح کی کوئی ترقی نظر نہیں آئی۔

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

اس پوری کہانی میں جس اہم ٹول نے ہماری مدد کی وہ ہمارا مانیٹرنگ سسٹم تھا۔ سچ ہے، ابھی تک ہمارے پاس ایک بھی ایسا نظام نہیں تھا جو ہمیں جسمانی آلات اور ہارڈ ویئر کی سطح سے لے کر کاروباری میٹرکس کی سطح تک تمام پرتوں پر میٹرکس جمع کرنے کی اجازت دیتا۔ 

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

کسی وقت، ہم نے سوچا اور فیصلہ کیا کہ ہمارے پاس یہ برداشت کرنے کے لیے کافی ہے - ہمیں پوری تصویر کو مکمل طور پر دیکھنے کے لیے ایک متحد نظام کی ضرورت ہے۔ ہمارے اسٹیک میں شامل اہم ٹیکنالوجیز ہیں Zabbix ایک الرٹنگ اور میٹرکس سٹوریج سنٹر کے طور پر، ایپلیکیشن میٹرکس کو اکٹھا کرنے اور اسٹور کرنے کے لیے Prometheus، پورے مانیٹرنگ سسٹم سے ڈیٹا کو لاگنگ اور اسٹور کرنے کے لیے Stack ELK، نیز گرافانا برائے ویژولائزیشن، Swagger، Docker۔ اور دیگر مفید اور چیزیں جو آپ کو معلوم ہیں۔

ایک ہی وقت میں، ہم نہ صرف مارکیٹ میں دستیاب ٹیکنالوجیز کا استعمال کرتے ہیں، بلکہ اپنی کچھ ٹیکنالوجیز بھی تیار کرتے ہیں۔ مثال کے طور پر، ہم نظاموں کو ایک دوسرے کے ساتھ مربوط کرنے کے لیے خدمات بناتے ہیں، یعنی میٹرکس کو جمع کرنے کے لیے کسی قسم کا API۔ اس کے علاوہ ہم اپنے نگرانی کے نظام پر کام کر رہے ہیں - کاروباری میٹرکس کی سطح پر ہم UI ٹیسٹ استعمال کرتے ہیں۔ اور ٹیموں کو مطلع کرنے کے لیے ٹیلیگرام میں ایک بوٹ بھی۔

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

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

یقیناً، ہمارے پاس آپریٹنگ سسٹمز کے لحاظ سے بڑھنے اور ترقی کرنے کی گنجائش ہے، اور ہم اس پر سرگرمی سے کام کر رہے ہیں۔ آپ ہمارے مانیٹرنگ سسٹم کے بارے میں مزید پڑھ سکتے ہیں۔ یہاں. 

تکنیکی ٹیسٹ 

Orlov Sergey، ویب اور موبائل ڈیولپمنٹ کے قابلیت کے مرکز کے سربراہ ہیں۔

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

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

اور ہمارے پاس بنیادی طور پر ایک نہ ختم ہونے والا بلیک فرائیڈے تھا، جس کے دوران نظام کو تبدیل کرنا ضروری تھا۔ اور نظام میں کوئی خرابی، مسئلہ یا ناکامی کاروبار کے لیے بہت مہنگی ہوگی۔

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

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

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

تیسرا ستون CI/CD پائپ لائن ہے۔ کسی درخواست کی تعمیر، جانچ، اور تعیناتی کے عمل کو زیادہ سے زیادہ خودکار ہونا چاہیے؛ اس میں کوئی دستی مداخلت نہیں ہونی چاہیے۔ CI/CD پائپ لائن کا موضوع کافی گہرا ہے، اور میں اس پر مختصراً بات کروں گا۔ یہ صرف قابل ذکر ہے کہ ہمارے پاس ایک CI/CD پائپ لائن چیک لسٹ ہے، جسے ہر پروڈکٹ ٹیم قابلیت کے مراکز کی مدد سے گزرتی ہے۔

اور یہاں چیک لسٹ ہے۔

اس طرح بہت سے مقاصد حاصل ہوتے ہیں۔ یہ ریلیز ٹرین سے بچنے کے لیے API ورژن اور فیچر ٹوگل ہے، اور مختلف ٹیسٹوں کی کوریج اس سطح پر حاصل کرنا ہے کہ ٹیسٹنگ مکمل طور پر خودکار ہو، تعیناتیاں بغیر کسی رکاوٹ کے ہوں، وغیرہ۔

چوتھا ستون تعمیراتی اصول اور تکنیکی حل ہے۔ ہم فن تعمیر کے بارے میں کافی دیر تک بات کر سکتے ہیں، لیکن میں چند اصولوں پر زور دینا چاہتا ہوں جن پر میں توجہ مرکوز کرنا چاہوں گا۔

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

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

تکنیکی حل کے بارے میں بات کرتے ہوئے، ہم نے پروڈکٹ ٹیموں سے سفارشات، آئیڈیاز اور حل کا ایک تازہ سیٹ تیار کرنے کو کہا، جسے انہوں نے کام کے بوجھ کی اگلی لہر کی تیاری میں لاگو کیا۔

کیشی

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

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

اس کے علاوہ، ہیزل کاسٹ میں سیریلائزر کو کریو میں تبدیل کرنے سے ہمیں ایک اچھا فروغ ملا۔ اور ReplicatedMap سے IMap + Near Cache میں Hazelcast میں منتقلی نے ہمیں پورے کلسٹر میں ڈیٹا کی نقل و حرکت کو کم کرنے کی اجازت دی۔ 

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

رد عمل کا ڈھیر

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

سب سے اہم اصول کالوں کو بلاک کرنے سے گریز کرنا ہے۔ رد عمل والے فریم ورک میں ہڈ کے نیچے چلنے والے لائیو سروس تھریڈز کی ایک چھوٹی سی تعداد ہوتی ہے۔ اگر ہم لاپرواہی سے اپنے آپ کو براہ راست بلاکنگ کال کرنے کی اجازت دیتے ہیں، جیسے کہ JDBC ڈرائیور کال، تو سسٹم بس رک جائے گا۔ 

غلطیوں کو اپنے رن ٹائم استثناء میں تبدیل کرنے کی کوشش کریں۔ پروگرام پر عمل درآمد کا اصل بہاؤ رد عمل والے فریم ورک میں منتقل ہو جاتا ہے، اور کوڈ پر عمل درآمد نان لائنر ہو جاتا ہے۔ نتیجے کے طور پر، اسٹیک ٹریس کا استعمال کرتے ہوئے مسائل کی تشخیص کرنا بہت مشکل ہے۔ اور یہاں حل یہ ہوگا کہ ہر غلطی کے لیے واضح، معروضی رن ٹائم مستثنیات بنائیں۔

Elasticsearch

Elasticsearch استعمال کرتے وقت، غیر استعمال شدہ ڈیٹا کو منتخب نہ کریں۔ یہ، اصولی طور پر، بھی بہت آسان مشورہ ہے، لیکن اکثر یہ وہی ہے جو بھول جاتا ہے. اگر آپ کو ایک وقت میں 10 ہزار سے زیادہ ریکارڈز منتخب کرنے کی ضرورت ہے، تو آپ کو اسکرول استعمال کرنے کی ضرورت ہے۔ مشابہت استعمال کرنے کے لیے، یہ قدرے متعلقہ ڈیٹا بیس میں کرسر کی طرح ہے۔ 

جب تک ضروری نہ ہو پوسٹ فلٹر استعمال نہ کریں۔ مرکزی نمونے میں بڑے ڈیٹا کے ساتھ، یہ آپریشن ڈیٹا بیس کو بہت زیادہ لوڈ کرتا ہے۔ 

جہاں قابل اطلاق ہو وہاں بلک آپریشنز کا استعمال کریں۔

API

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

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

تنظیمی تبدیلی

ایروشکینہ ایلینا، ڈپٹی ڈائریکٹر برائے آئی ٹی

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

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

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

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

اس کے لیے کسی خاص انتظامی کوششوں کی ضرورت نہیں تھی، کیونکہ اپنے عمل کو منظم کرنے، پروڈکٹ کی تکنیکی بہتری، اور کوالٹی ایشورنس کے طریقوں کے ساتھ، ہم اپنی ٹیموں کو خود کو منظم کرنا سکھاتے ہیں - انتظامی وسائل کو شامل کیے بغیر اپنے پیداواری عمل کو خود منظم کرنا۔

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

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

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

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

طریقہ کار کے ماہرین، وہ لوگ جو ٹیموں کو ایک عمل کی تعمیر میں مدد کرتے ہیں، مواصلات قائم کرتے ہیں، اور کام کی کارکردگی کو بہتر بناتے ہیں، بنیادی طور پر تبدیلی کے ایجنٹ ہیں۔ ابھی، ہمارے پہلے گروپ کے گریجویٹ ٹیموں کے ساتھ کام کر رہے ہیں اور انہیں کامیاب ہونے میں مدد کر رہے ہیں۔ 

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

نتائج

اس مشکل وقت کے دوران، ہم نے بنیادی اصول وضع کیے ہیں جن پر سافٹ ویئر ڈویلپمنٹ قائم ہے، جو میرے خیال میں ہر اس کمپنی کے لیے متعلقہ ہوں گے جو اس سے نمٹتی ہے۔

لوگ. یہ وہی ہے جو سب کچھ پر منحصر ہے. ملازمین کو اپنے کام سے لطف اندوز ہونا چاہیے اور کمپنی کے اہداف اور ان مصنوعات کے مقاصد کو سمجھنا چاہیے جن پر وہ کام کرتے ہیں۔ اور، یقینا، وہ پیشہ ورانہ طور پر ترقی کر سکتے ہیں. 

Технология. کمپنی کے لیے یہ ضروری ہے کہ وہ اپنی ٹیکنالوجی کے اسٹیک کے ساتھ کام کرنے کے لیے ایک پختہ انداز اختیار کرے اور جہاں واقعی ضرورت ہو وہاں قابلیت پیدا کرے۔ یہ بہت سادہ اور واضح لگتا ہے۔ اور اکثر نظر انداز کیا جاتا ہے۔

پروسیسنگ. یہ ضروری ہے کہ پروڈکٹ ٹیموں اور قابلیت کے مراکز کے کام کو مناسب طریقے سے منظم کیا جائے، کاروبار کے ساتھ ایک پارٹنر کے طور پر کام کرنے کے لیے اس کے ساتھ تعامل قائم کیا جائے۔

عام طور پر، یہ بہت زیادہ ہے کہ ہم کیسے بچ گئے. ہمارے زمانے کے مرکزی مقالے کی ایک بار پھر تصدیق ہوئی، ماتھے پر ایک زوردار کلک کے ساتھ

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

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

ماخذ: www.habr.com