یہ معلوم ہوتا ہے کہ سی ٹی او کی اہلیت کا امتحان صرف دوسری بار ہوتا ہے جب وہ یہ کردار ادا کرتا ہے۔ کیونکہ یہ ایک چیز ہے کہ کمپنی میں کئی سالوں تک کام کرنا، اس کے ساتھ ترقی کرنا اور اسی ثقافتی تناظر میں ہونے کی وجہ سے آہستہ آہستہ مزید ذمہ داری حاصل کرنا۔ اور وراثت کے سامان والی کمپنی میں ٹیکنیکل ڈائریکٹر کے عہدے پر آنا بالکل دوسری بات ہے اور مسائل کا ایک گروپ صفائی کے ساتھ قالین کے نیچے بہہ گیا ہے۔
اس لحاظ سے، لیون فائر کا تجربہ، جو اس نے شیئر کیا۔ بالکل انوکھا نہیں، لیکن اپنے تجربے اور مختلف کرداروں کی تعداد سے جو وہ 20 سالوں کے دوران آزمانے میں کامیاب ہوئے، یہ بہت مفید ہے۔ کٹ کے نیچے 90 دنوں سے زیادہ کے واقعات اور بہت ساری کہانیاں ہیں جو کسی اور کے ساتھ پیش آنے پر ہنسنے میں مزہ آتی ہیں، لیکن جن کا سامنا ذاتی طور پر کرنا اتنا مزہ نہیں آتا۔
لیون روسی میں بہت رنگین بات کرتا ہے، لہذا اگر آپ کے پاس 35-40 منٹ ہیں، تو میں ویڈیو دیکھنے کا مشورہ دیتا ہوں۔ نیچے وقت بچانے کے لیے ٹیکسٹ ورژن۔
رپورٹ کا پہلا ورژن مفید سفارشات پر مشتمل لوگوں اور عمل کے ساتھ کام کرنے کی ایک اچھی ساختہ تفصیل تھی۔ لیکن اس نے ان تمام حیرتوں کو بیان نہیں کیا جن کا راستے میں سامنا کرنا پڑا۔ لہٰذا، میں نے فارمیٹ کو تبدیل کیا اور نئی کمپنی میں جیک ان دی باکس کی طرح میرے سامنے آنے والے مسائل، اور ان کو تاریخی ترتیب کے مطابق حل کرنے کے طریقے پیش کیے ہیں۔
ایک ماہ پہلے
بہت سی اچھی کہانیوں کی طرح، یہ بھی شراب سے شروع ہوئی۔ ہم دوستوں کے ساتھ ایک بار میں بیٹھے تھے، اور جیسا کہ آئی ٹی ماہرین کے درمیان توقع تھی، ہر کوئی اپنے مسائل کا رونا رو رہا تھا۔ ان میں سے ایک نے ابھی نوکری بدلی تھی اور وہ ٹیکنالوجی، لوگوں اور ٹیم کے ساتھ اپنے مسائل کے بارے میں بات کر رہا تھا۔ میں نے جتنا زیادہ سنا، اتنا ہی مجھے احساس ہوا کہ اسے صرف مجھے ملازمت پر رکھنا چاہیے، کیونکہ یہ وہ قسم کے مسائل ہیں جن کو میں گزشتہ 15 سالوں سے حل کر رہا ہوں۔ میں نے اسے بتایا، اور اگلے دن ہم کام کے ماحول میں ملے۔ کمپنی کو ٹیچنگ اسٹریٹیجیز کہا جاتا تھا۔
بہت چھوٹے بچوں کے لیے پیدائش سے لے کر تین سال کی عمر تک کے نصاب میں تدریسی حکمت عملی ایک مارکیٹ لیڈر ہے۔ روایتی "کاغذی" کمپنی پہلے ہی 40 سال پرانی ہے، اور پلیٹ فارم کا ڈیجیٹل SaaS ورژن 10 سال پرانا ہے۔ نسبتاً حال ہی میں، ڈیجیٹل ٹیکنالوجی کو کمپنی کے معیار کے مطابق ڈھالنے کا عمل شروع ہوا ہے۔ "نیا" ورژن 2017 میں لانچ ہوا اور تقریباً پرانے جیسا ہی تھا، صرف اس نے بدتر کام کیا۔
سب سے دلچسپ بات یہ ہے کہ اس کمپنی کا ٹریفک بہت قابل پیشن گوئی ہے - دن بہ دن، سال بہ سال، آپ بہت واضح طور پر اندازہ لگا سکتے ہیں کہ کتنے لوگ آئیں گے اور کب آئیں گے۔ مثال کے طور پر، دوپہر 13 سے 15 بجے کے درمیان کنڈرگارٹن کے تمام بچے بستر پر جاتے ہیں اور اساتذہ معلومات درج کرنا شروع کر دیتے ہیں۔ اور یہ ہر روز ہوتا ہے، ویک اینڈ کے علاوہ، کیونکہ ویک اینڈ پر تقریباً کوئی بھی کام نہیں کرتا۔
تھوڑا سا آگے دیکھتے ہوئے، میں نوٹ کروں گا کہ میں نے اپنا کام سب سے زیادہ سالانہ ٹریفک کے دوران شروع کیا تھا، جو مختلف وجوہات کی بنا پر دلچسپ ہے۔
پلیٹ فارم، جو بظاہر صرف 2 سال پرانا معلوم ہوتا ہے، اس میں ایک عجیب اسٹیک تھا: کولڈ فیوژن اور ایس کیو ایل سرور 2008 سے۔ ColdFusion، اگر آپ نہیں جانتے، اور غالباً آپ نہیں جانتے، ایک انٹرپرائز پی ایچ پی ہے جو 90 کی دہائی کے وسط میں سامنے آیا تھا، اور تب سے میں نے اس کے بارے میں سنا تک نہیں ہے۔ وہاں بھی تھے: روبی، مائی ایس کیو ایل، پوسٹگری ایس کیو ایل، جاوا، گو، ازگر۔ لیکن مرکزی یک سنگی کولڈ فیوژن اور ایس کیو ایل سرور پر چلتی ہے۔
مسائل
جتنا میں نے کمپنی کے ملازمین سے کام کے بارے میں بات کی اور کن مسائل کا سامنا کیا، اتنا ہی مجھے احساس ہوا کہ مسائل صرف تکنیکی نوعیت کے نہیں تھے۔ ٹھیک ہے، ٹیکنالوجی پرانی ہے - اور انہوں نے اس پر کام نہیں کیا، لیکن ٹیم اور عمل کے ساتھ مسائل تھے، اور کمپنی نے اسے سمجھنا شروع کیا۔
روایتی طور پر، ان کے تکنیکی لوگ کونے میں بیٹھ کر کوئی نہ کوئی کام کرتے تھے۔ لیکن زیادہ سے زیادہ کاروبار ڈیجیٹل ورژن کے ذریعے جانے لگا۔ اس لیے، میرے کام شروع کرنے سے پہلے پچھلے سال میں، کمپنی میں نئے لوگ نمودار ہوئے: بورڈ آف ڈائریکٹرز، CTO، CPO اور QA ڈائریکٹر۔ یعنی کمپنی ٹیکنالوجی کے شعبے میں سرمایہ کاری کرنے لگی۔
بھاری میراث کے نشانات نہ صرف نظاموں میں تھے۔ کمپنی میں میراثی عمل، میراثی لوگ، میراثی کلچر تھا۔ یہ سب کچھ بدلنا تھا۔ میں نے سوچا کہ یہ یقینی طور پر بورنگ نہیں ہوگا، اور میں نے اسے آزمانے کا فیصلہ کیا۔
دو دن پہلے
نیا کام شروع کرنے سے دو دن پہلے، میں دفتر پہنچا، آخری کاغذی کارروائی پُر کی، ٹیم سے ملاقات کی، اور پتہ چلا کہ ٹیم اس وقت کسی مسئلے سے دوچار تھی۔ یہ تھا کہ صفحہ لوڈ ہونے کا اوسط وقت 4 سیکنڈ تک بڑھ گیا، یعنی 2 گنا۔
گراف کے مطابق، کچھ واضح طور پر ہوا، اور یہ واضح نہیں ہے کہ کیا. پتہ چلا کہ مسئلہ ڈیٹا سینٹر میں نیٹ ورک لیٹنسی کا تھا: ڈیٹا سینٹر میں 5 ms لیٹنسی صارفین کے لیے 2 s میں بدل گئی۔ مجھے نہیں معلوم کہ ایسا کیوں ہوا، لیکن کسی بھی صورت میں یہ معلوم ہو گیا کہ مسئلہ ڈیٹا سینٹر میں تھا۔
ایک دن
دو دن گزر گئے اور اپنے کام کے پہلے دن میں نے دریافت کیا کہ مسئلہ دور نہیں ہوا ہے۔
دو دنوں تک، صارفین کے صفحات اوسطاً 4 سیکنڈ میں لوڈ ہوتے ہیں۔ میں پوچھتا ہوں کہ کیا انہیں پتہ چلا کہ مسئلہ کیا ہے۔
- ہاں، ہم نے ایک ٹکٹ کھولا۔
- اور؟
- ٹھیک ہے، انہوں نے ابھی تک ہمیں جواب نہیں دیا ہے.
تب میں نے محسوس کیا کہ وہ سب کچھ جس کے بارے میں مجھے پہلے بتایا گیا تھا وہ آئس برگ کا صرف ایک چھوٹا سا سرہ تھا جس سے مجھے لڑنا تھا۔
ایک اچھا اقتباس ہے جو اس پر بہت اچھی طرح فٹ بیٹھتا ہے:
"کبھی کبھی ٹیکنالوجی کو تبدیل کرنے کے لیے آپ کو تنظیم کو تبدیل کرنا پڑتا ہے۔"
لیکن چونکہ میں نے سال کے مصروف ترین وقت میں کام شروع کیا تھا، اس لیے مجھے مسئلے کو حل کرنے کے لیے دونوں آپشنز کو دیکھنا پڑا: فوری اور طویل مدتی۔ اور اس کے ساتھ شروع کریں جو ابھی اہم ہے۔
تیسرا دن۔
لہذا، لوڈنگ 4 سیکنڈ تک رہتی ہے، اور 13 سے 15 سب سے بڑی چوٹیوں تک۔
اس مدت کے دوران تیسرے دن، ڈاؤن لوڈ کی رفتار اس طرح نظر آئی:
میرے نقطہ نظر سے، کچھ بھی کام نہیں ہوا. باقی سب کے نقطہ نظر سے یہ معمول سے تھوڑا سست چل رہا تھا۔ لیکن یہ صرف اس طرح نہیں ہوتا ہے - یہ ایک سنگین مسئلہ ہے۔
میں نے ٹیم کو قائل کرنے کی کوشش کی، جس پر انہوں نے جواب دیا کہ انہیں صرف مزید سرورز کی ضرورت ہے۔ یہ، یقیناً، مسئلے کا حل ہے، لیکن یہ ہمیشہ واحد اور سب سے زیادہ مؤثر نہیں ہوتا ہے۔ میں نے پوچھا کہ اتنے سرور کیوں نہیں تھے، ٹریفک کا حجم کیا تھا۔ میں نے ڈیٹا کو اکٹھا کیا اور پتہ چلا کہ ہمارے پاس فی سیکنڈ تقریباً 150 درخواستیں ہیں، جو اصولی طور پر معقول حدود میں آتی ہیں۔
لیکن ہمیں یہ نہیں بھولنا چاہیے کہ آپ کو صحیح جواب ملنے سے پہلے، آپ کو صحیح سوال پوچھنے کی ضرورت ہے۔ میرا اگلا سوال تھا: ہمارے پاس کتنے فرنٹ اینڈ سرورز ہیں؟ جواب نے "مجھے تھوڑا سا حیران کر دیا" - ہمارے پاس 17 فرنٹ اینڈ سرورز تھے!
- میں پوچھنے میں شرمندہ ہوں، لیکن 150 کو 17 سے تقسیم کرنے سے تقریباً 8 ملتا ہے؟ کیا آپ کہہ رہے ہیں کہ ہر سرور فی سیکنڈ 8 درخواستوں کی اجازت دیتا ہے، اور اگر کل 160 درخواستیں فی سیکنڈ ہوتی ہیں تو ہمیں مزید 2 سرورز کی ضرورت ہوگی؟
یقینا، ہمیں اضافی سرورز کی ضرورت نہیں تھی۔ حل خود کوڈ میں تھا، اور سطح پر:
var currentClass = classes.getCurrentClass();
return currentClass;
ایک تقریب تھی۔ getCurrentClass()کیونکہ سائٹ پر موجود ہر چیز کلاس کے تناظر میں کام کرتی ہے - یہ ٹھیک ہے۔ اور اس کے لیے ہر صفحے پر ایک فنکشن موجود تھا۔ 200+ درخواستیں۔.
اس طرح کا حل بہت آسان تھا، آپ کو کچھ بھی دوبارہ لکھنے کی ضرورت نہیں تھی: بس وہی معلومات دوبارہ نہ مانگیں۔
if ( !isDefined("REQUEST.currentClass") ) {
var classes = new api.private.classes.base();
REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;میں بہت خوش تھا کیونکہ میں نے فیصلہ کیا کہ صرف تیسرے دن ہی مجھے اصل مسئلہ مل گیا ہے۔ بولی جیسا کہ میں تھا، یہ بہت سے مسائل میں سے ایک تھا۔
لیکن اس پہلے مسئلے کو حل کرنے سے گراف بہت نیچے گر گیا۔
ایک ہی وقت میں، ہم دوسری اصلاح کر رہے تھے۔ بہت سی چیزیں نظر میں تھیں جنہیں ٹھیک کیا جا سکتا تھا۔ مثال کے طور پر، اسی تیسرے دن میں نے دریافت کیا کہ سسٹم میں سب کے بعد ایک کیش موجود ہے (پہلے میں نے سوچا کہ تمام درخواستیں براہ راست ڈیٹا بیس سے آرہی ہیں)۔ جب میں کسی کیشے کے بارے میں سوچتا ہوں، تو میں معیاری Redis یا Memcached کے بارے میں سوچتا ہوں۔ لیکن میں صرف وہی تھا جس نے ایسا سوچا، کیونکہ اس سسٹم نے کیشنگ کے لیے مونگو ڈی بی اور ایس کیو ایل سرور کا استعمال کیا تھا - وہی جس سے ڈیٹا پڑھا گیا تھا۔
دن دس
پہلے ہفتے میں نے ان مسائل سے نمٹا جن کو ابھی حل کرنے کی ضرورت ہے۔ دوسرے ہفتے میں کہیں، میں ٹیم کے ساتھ بات چیت کرنے کے لیے پہلی بار اسٹینڈ اپ پر آیا، یہ دیکھنے کے لیے کہ کیا ہو رہا ہے اور سارا عمل کیسے چل رہا ہے۔
ایک بار پھر دلچسپ چیز دریافت ہوئی۔ ٹیم پر مشتمل تھی: 18 ڈویلپرز؛ 8 ٹیسٹرز؛ 3 مینیجرز؛ 2 معمار۔ اور ان سب نے مشترکہ رسومات میں حصہ لیا یعنی روزانہ صبح 30 سے زائد لوگ اسٹینڈ اپ پر آتے اور بتایا کہ انہوں نے کیا کیا۔ واضح رہے کہ ملاقات میں 5 یا 15 منٹ نہیں لگے۔ کسی نے کسی کی نہیں سنی کیونکہ ہر کوئی مختلف نظاموں پر کام کرتا ہے۔ اس فارم میں، گرومنگ سیشن کے لیے فی گھنٹہ 2-3 ٹکٹ پہلے ہی ایک اچھا نتیجہ تھا۔
پہلی چیز جو ہم نے کی وہ ٹیم کو کئی پروڈکٹ لائنوں میں تقسیم کرنا تھا۔ مختلف سیکشنز اور سسٹمز کے لیے، ہم نے الگ الگ ٹیمیں مختص کیں، جن میں ڈویلپرز، ٹیسٹرز، پروڈکٹ مینیجر اور کاروباری تجزیہ کار شامل تھے۔
نتیجے کے طور پر ہمیں ملا:
- اسٹینڈ اپ اور ریلیوں کو کم کرنا۔
- پروڈکٹ کا موضوع علم۔
- ملکیت کا احساس۔ جب لوگ ہر وقت سسٹم کے ساتھ ٹنکر کرتے تھے، تو وہ جانتے تھے کہ کسی اور کو ان کے کیڑے کے ساتھ کام کرنا پڑے گا، لیکن خود نہیں۔
- گروپوں کے درمیان تعاون۔ یہ کہنے کی ضرورت نہیں کہ QA پہلے پروگرامرز کے ساتھ زیادہ بات چیت نہیں کرتا تھا، پروڈکٹ نے اپنا کام کیا، وغیرہ۔ اب ان کے پاس ذمہ داری کا ایک مشترکہ نقطہ ہے۔
ہم نے بنیادی طور پر کارکردگی، پیداواریت اور معیار پر توجہ مرکوز کی - یہ وہ مسائل ہیں جنہیں ہم نے ٹیم کی تبدیلی کے ساتھ حل کرنے کی کوشش کی۔
گیارہ دن
ٹیم کے ڈھانچے کو تبدیل کرنے کے عمل میں، میں نے دریافت کیا کہ کیسے گننا ہے۔ کہانیپوائنٹ. 1 SP ایک دن کے برابر تھا، اور ہر ٹکٹ میں ترقی اور QA دونوں کے لیے SP ہوتا تھا، یعنی کم از کم 2 SP۔
میں نے یہ کیسے دریافت کیا؟
ہمیں ایک بگ ملا: رپورٹوں میں سے ایک میں، جہاں اس مدت کے آغاز اور اختتام کی تاریخ درج کی گئی ہے جس کے لیے رپورٹ کی ضرورت ہے، آخری دن کو مدنظر نہیں رکھا گیا ہے۔ یعنی کہیں درخواست میں <= نہیں تھا، لیکن صرف <۔ مجھے بتایا گیا کہ یہ تین سٹوری پوائنٹس ہیں، یعنی 3 دنوں.
اس کے بعد ہم:
- اسٹوری پوائنٹس کی درجہ بندی کے نظام پر نظر ثانی کی گئی ہے۔ اب معمولی کیڑوں کے لیے اصلاحات جو سسٹم سے تیزی سے گزر سکتی ہیں تیزی سے صارف تک پہنچتی ہیں۔
- ہم نے ترقی اور جانچ کے لیے متعلقہ ٹکٹوں کو ضم کرنا شروع کر دیا۔ پہلے، ہر ٹکٹ، ہر بگ ایک بند ماحولیاتی نظام تھا، کسی اور چیز سے منسلک نہیں تھا۔ ایک صفحہ پر تین بٹن تبدیل کرنے سے فی صفحہ ایک خودکار ٹیسٹ کے بجائے تین مختلف QA عمل کے ساتھ تین مختلف ٹکٹ ہو سکتے تھے۔
- ہم نے لیبر کے اخراجات کا تخمینہ لگانے کے نقطہ نظر پر ڈویلپرز کے ساتھ کام کرنا شروع کیا۔ ایک بٹن کو تبدیل کرنے کے لئے تین دن مضحکہ خیز نہیں ہے.
بیسواں دن
پہلے مہینے کے وسط میں کہیں، صورتحال قدرے مستحکم ہوئی، میں نے سوچا کہ بنیادی طور پر کیا ہو رہا ہے، اور پہلے ہی مستقبل کو دیکھنا اور طویل مدتی حل کے بارے میں سوچنا شروع کر دیا۔
طویل مدتی مقاصد:
- منظم پلیٹ فارم۔ ہر صفحے پر سینکڑوں درخواستیں سنجیدہ نہیں ہیں۔
- متوقع رجحانات۔ وقتاً فوقتاً ٹریفک کی چوٹیاں تھیں جو پہلی نظر میں دیگر میٹرکس کے ساتھ مربوط نہیں تھیں - ہمیں یہ سمجھنے کی ضرورت تھی کہ ایسا کیوں ہوا اور پیشین گوئی کرنا سیکھیں۔
- پلیٹ فارم کی توسیع۔ کاروبار مسلسل بڑھ رہا ہے، زیادہ سے زیادہ صارفین آ رہے ہیں، اور ٹریفک بڑھ رہا ہے۔
ماضی میں اکثر کہا جاتا تھا: "آئیے ہر چیز کو [زبان/فریم ورک] میں دوبارہ لکھتے ہیں، سب کچھ بہتر کام کرے گا!"
زیادہ تر معاملات میں یہ کام نہیں کرتا، یہ اچھا ہے اگر دوبارہ لکھنا بالکل کام کرتا ہے۔ لہذا، ہمیں ایک روڈ میپ بنانے کی ضرورت تھی - ایک مخصوص حکمت عملی جو قدم بہ قدم یہ بتاتی ہو کہ کس طرح کاروباری اہداف حاصل کیے جائیں گے (ہم کیا کریں گے اور کیوں)، جو:
- منصوبے کے مشن اور اہداف کی عکاسی کرتا ہے۔
- اہم اہداف کو ترجیح دیتا ہے؛
- ان کو حاصل کرنے کے لئے ایک شیڈول پر مشتمل ہے.
اس سے پہلے کسی نے بھی ٹیم سے کسی تبدیلی کے مقصد کے بارے میں بات نہیں کی تھی۔ اس کے لیے کامیابی کی صحیح پیمائش کی ضرورت ہے۔ کمپنی کی تاریخ میں پہلی بار، ہم نے تکنیکی گروپ کے لیے KPIs کا تعین کیا، اور یہ اشارے تنظیمی اشارے سے منسلک تھے۔
یعنی تنظیمی KPIs کو ٹیموں کے ذریعے سپورٹ کیا جاتا ہے، اور ٹیم KPIs کو انفرادی KPIs کے ذریعے سپورٹ کیا جاتا ہے۔ دوسری صورت میں، اگر تکنیکی KPIs تنظیمی لوگوں کے ساتھ موافق نہیں ہیں، تو ہر کوئی اپنے اوپر کمبل کھینچ لیتا ہے۔
مثال کے طور پر، تنظیمی KPIs میں سے ایک نئی مصنوعات کے ذریعے مارکیٹ شیئر بڑھا رہا ہے۔
آپ مزید نئی مصنوعات رکھنے کے مقصد کی حمایت کیسے کر سکتے ہیں؟
- سب سے پہلے، ہم نقائص کو دور کرنے کے بجائے نئی مصنوعات تیار کرنے میں زیادہ وقت گزارنا چاہتے ہیں۔ یہ ایک منطقی حل ہے جس کی پیمائش کرنا آسان ہے۔
- دوم، ہم لین دین کے حجم میں اضافے کی حمایت کرنا چاہتے ہیں، کیونکہ جتنا زیادہ مارکیٹ شیئر ہوگا، اتنے ہی زیادہ صارفین اور، اس کے مطابق، زیادہ ٹریفک۔
پھر انفرادی KPIs جنہیں گروپ کے اندر عمل میں لایا جا سکتا ہے، مثال کے طور پر، اس جگہ پر ہوں گے جہاں سے اہم نقائص آتے ہیں۔ اگر آپ خاص طور پر اس سیکشن پر توجہ مرکوز کرتے ہیں، تو آپ اس بات کو یقینی بنا سکتے ہیں کہ اس میں بہت کم نقائص ہیں، اور پھر نئی مصنوعات تیار کرنے اور تنظیمی KPIs کو سپورٹ کرنے کا وقت بڑھ جائے گا۔
اس طرح، ہر فیصلہ، بشمول ری رائٹنگ کوڈ، کو ان مخصوص اہداف کی حمایت کرنی چاہیے جو کمپنی نے ہمارے لیے مقرر کیے ہیں (تنظیمی ترقی، نئی خصوصیات، بھرتی)۔
اس عمل کے دوران، ایک دلچسپ بات سامنے آئی، جو نہ صرف تکنیکی ماہرین کے لیے، بلکہ کمپنی میں عام طور پر خبر بن گئی: تمام ٹکٹ کم از کم ایک KPI پر مرکوز ہونے چاہئیں۔ یعنی، اگر کوئی پروڈکٹ کہتی ہے کہ وہ ایک نیا فیچر بنانا چاہتی ہے، تو پہلا سوال پوچھا جانا چاہیے: "یہ فیچر کس KPI کو سپورٹ کرتا ہے؟" اگر نہیں، تو معذرت - یہ ایک غیر ضروری خصوصیت کی طرح لگتا ہے۔
تیس دن
مہینے کے آخر میں، میں نے ایک اور نزاکت دریافت کی: میری Ops ٹیم میں سے کسی نے بھی وہ معاہدے نہیں دیکھے جو ہم کلائنٹس کے ساتھ کرتے ہیں۔ آپ پوچھ سکتے ہیں کہ آپ کو رابطے دیکھنے کی ضرورت کیوں ہے۔
- سب سے پہلے، کیونکہ SLAs معاہدوں میں بیان کیے گئے ہیں۔
- دوم، SLAs سب مختلف ہیں۔ ہر کلائنٹ اپنی ضروریات کے ساتھ آیا، اور سیلز ڈیپارٹمنٹ نے بغیر دیکھے دستخط کر دیئے۔
ایک اور دلچسپ بات یہ ہے کہ سب سے بڑے کلائنٹس میں سے ایک کے ساتھ معاہدہ یہ بتاتا ہے کہ پلیٹ فارم کے ذریعہ تعاون یافتہ تمام سافٹ ویئر ورژن n-1 ہونے چاہئیں، یعنی تازہ ترین ورژن نہیں، بلکہ آخری ورژن۔
یہ واضح ہے کہ ہم n-1 سے کتنے دور تھے اگر پلیٹ فارم ColdFusion اور SQL Server 2008 پر مبنی تھا، جو جولائی میں بالکل بھی تعاون یافتہ نہیں تھا۔
دن پینتالیس
دوسرے مہینے کے وسط میں میرے پاس بیٹھنے اور کرنے کے لئے کافی وقت تھا۔ قیمتسٹریمتعریفیں مکمل طور پر پورے عمل کے لیے۔ پروڈکٹ بنانے سے لے کر اسے صارفین تک پہنچانے تک یہ وہ ضروری اقدامات ہیں جن کو اٹھانے کی ضرورت ہے، اور انہیں زیادہ سے زیادہ تفصیل سے بیان کرنے کی ضرورت ہے۔
آپ اس عمل کو چھوٹے چھوٹے ٹکڑوں میں توڑ دیں اور دیکھیں کہ کس چیز میں بہت زیادہ وقت لگ رہا ہے، کس چیز کو بہتر بنایا جا سکتا ہے، کیا بہتر کیا جا سکتا ہے، وغیرہ۔ مثال کے طور پر، کسی پروڈکٹ کی درخواست کو گرومنگ سے گزرنے میں کتنا وقت لگتا ہے، یہ ایک ٹکٹ تک کب پہنچتی ہے جسے ڈیولپر لے سکتا ہے، QA وغیرہ۔ لہذا آپ ہر انفرادی قدم کو تفصیل سے دیکھتے ہیں اور سوچتے ہیں کہ کس چیز کو بہتر بنایا جا سکتا ہے۔
جب میں نے یہ کیا تو دو چیزوں نے میری نظر پکڑی:
- QA سے واپس ڈویلپرز کو واپس آنے والے ٹکٹوں کا زیادہ فیصد؛
- پل کی درخواست کے جائزوں میں کافی وقت لگا۔
مسئلہ یہ تھا کہ یہ نتائج تھے جیسے: لگتا ہے کہ اس میں کافی وقت لگتا ہے، لیکن ہمیں یقین نہیں ہے کہ کتنا وقت ہے۔
"آپ اسے بہتر نہیں کر سکتے جس کی آپ پیمائش نہیں کر سکتے۔"
یہ کیسے ثابت کیا جائے کہ مسئلہ کتنا سنگین ہے؟ کیا یہ دن یا گھنٹے ضائع کرتا ہے؟
اس کی پیمائش کرنے کے لیے، ہم نے جیرا کے عمل میں دو مراحل شامل کیے: "ڈیو کے لیے تیار" اور "QA کے لیے تیار" یہ پیمائش کرنے کے لیے کہ ہر ٹکٹ کتنی دیر تک انتظار کرتا ہے اور کتنی بار کسی خاص مرحلے پر واپس آتا ہے۔
ہم نے یہ جاننے کے لیے "جائزہ میں" بھی شامل کیا کہ اوسطاً کتنے ٹکٹ جائزے کے لیے ہیں، اور اس سے آپ ناچنا شروع کر سکتے ہیں۔ ہمارے پاس سسٹم میٹرکس تھے، اب ہم نے نئے میٹرکس شامل کیے اور پیمائش کرنا شروع کی:
- عمل کی کارکردگی: کارکردگی اور منصوبہ بند/فراہم کی گئی۔
- عمل کا معیار: نقائص کی تعداد، QA سے نقائص۔
یہ واقعی یہ سمجھنے میں مدد کرتا ہے کہ کیا اچھا ہو رہا ہے اور کیا اچھا نہیں جا رہا ہے۔
پچاسواں دن
یہ سب کچھ یقیناً اچھا اور دلچسپ ہے، لیکن دوسرے مہینے کے آخر میں کچھ ایسا ہوا جو اصولی طور پر قابل قیاس تھا، حالانکہ مجھے ایسے پیمانے کی توقع نہیں تھی۔ لوگ جانے لگے کیونکہ اعلیٰ انتظامیہ بدل چکی تھی۔ نئے لوگ انتظامیہ میں آئے اور سب کچھ بدلنا شروع کر دیا، اور پرانے لوگ چھوڑ گئے۔ اور عام طور پر کئی سال پرانی کمپنی میں ہر کوئی دوست ہوتا ہے اور سب ایک دوسرے کو جانتے ہیں۔
یہ توقع کی جا رہی تھی، لیکن برطرفی کا پیمانہ غیر متوقع تھا۔ مثال کے طور پر، ایک ہفتے میں دو ٹیم لیڈز نے بیک وقت اپنی مرضی سے استعفے جمع کرائے ہیں۔ لہذا، مجھے نہ صرف دیگر مسائل کے بارے میں بھولنا پڑا، بلکہ توجہ مرکوز کرنا پڑا ایک ٹیم بنانا. یہ حل کرنا ایک طویل اور مشکل مسئلہ ہے، لیکن اس سے نمٹنا پڑا کیونکہ میں ان لوگوں کو بچانا چاہتا تھا جو باقی رہ گئے (یا ان میں سے زیادہ تر)۔ ٹیم کے حوصلے کو برقرار رکھنے کے لیے کسی نہ کسی طرح اس بات پر ردعمل ظاہر کرنا ضروری تھا کہ لوگ چلے گئے۔
اصولی طور پر، یہ اچھا ہے: ایک نیا شخص آتا ہے جس کے پاس مکمل کارٹ بلینچ ہوتا ہے، جو ٹیم کی مہارت کا اندازہ لگا سکتا ہے اور اہلکاروں کی جگہ لے سکتا ہے۔ درحقیقت، آپ بہت ساری وجوہات کی بنا پر صرف نئے لوگوں کو نہیں لا سکتے۔ توازن ہمیشہ ضروری ہے۔
- پرانا اور نیا۔ ہمیں پرانے لوگوں کو رکھنے کی ضرورت ہے جو بدل سکتے ہیں اور مشن کی حمایت کر سکتے ہیں۔ لیکن ایک ہی وقت میں، ہمیں نیا خون لانے کی ضرورت ہے، ہم اس کے بارے میں تھوڑی دیر بعد بات کریں گے.
- تجربہ۔ میں نے اچھے جونیئرز سے بہت بات کی جو بے چین تھے اور ہمارے ساتھ کام کرنا چاہتے تھے۔ لیکن میں انہیں نہیں لے سکا کیونکہ جونیئرز کی مدد کرنے اور ان کے لیے سرپرست کے طور پر کام کرنے کے لیے کافی سینئرز نہیں تھے۔ سب سے پہلے اعلیٰ اور پھر نوجوانوں کو بھرتی کرنا ضروری تھا۔
- گاجر اور چھڑی.
میرے پاس اس سوال کا کوئی اچھا جواب نہیں ہے کہ صحیح توازن کیا ہے، اسے کیسے برقرار رکھنا ہے، کتنے لوگوں کو رکھنا ہے اور کتنا دھکیلنا ہے۔ یہ ایک خالصتاً انفرادی عمل ہے۔
اکیاون دن
میں نے ٹیم کو قریب سے دیکھنا شروع کیا تاکہ یہ سمجھ سکے کہ میرے پاس کون ہے، اور ایک بار پھر مجھے یاد آیا:
"زیادہ تر مسائل لوگوں کے مسائل ہیں۔"
میں نے محسوس کیا ہے کہ اس طرح کی ٹیم - دیو اور اوپس دونوں - کو تین بڑے مسائل ہیں:
- موجودہ حالات پر اطمینان۔
- ذمہ داری کا فقدان - کیونکہ کسی نے بھی کاروبار پر اثر انداز ہونے کے لیے اداکاروں کے کام کے نتائج نہیں لائے ہیں۔
- تبدیلی کا خوف۔
تبدیلی ہمیشہ آپ کو اپنے کمفرٹ زون سے باہر لے جاتی ہے، اور نوجوان لوگ اتنے ہی زیادہ تبدیلی کو ناپسند کرتے ہیں کیونکہ وہ نہیں سمجھتے کیوں اور وہ نہیں سمجھتے کہ کیسے۔ سب سے عام جواب جو میں نے سنا ہے وہ ہے، "ہم نے ایسا کبھی نہیں کیا۔" مزید برآں، یہ مکمل بیہودگی کے مقام پر پہنچ گیا - معمولی تبدیلیاں کسی کے ناراض ہونے کے بغیر نہیں ہوسکتی ہیں۔ اور اس بات سے کوئی فرق نہیں پڑتا ہے کہ تبدیلیوں نے ان کے کام کو کتنا متاثر کیا، لوگوں نے کہا: "نہیں، کیوں؟ یہ کام نہیں کرے گا۔"
لیکن آپ کچھ بھی تبدیل کیے بغیر بہتر نہیں ہو سکتے۔
میں نے ایک ملازم کے ساتھ بالکل مضحکہ خیز گفتگو کی، میں نے اسے اصلاح کے لیے اپنے خیالات بتائے، جس پر اس نے مجھے بتایا:
- اوہ، آپ نے نہیں دیکھا کہ ہمارے پاس پچھلے سال کیا تھا!
- تو کیا؟
"اب یہ پہلے سے کہیں بہتر ہے۔"
- تو، یہ بہتر نہیں ہو سکتا؟
- کس کے لئے؟
اچھا سوال - کیوں؟ گویا یہ پہلے سے بہتر ہے، پھر سب کچھ کافی اچھا ہے۔ یہ ذمہ داری کی کمی کی طرف جاتا ہے، جو اصولی طور پر بالکل عام بات ہے۔ جیسا کہ میں نے کہا، تکنیکی گروپ تھوڑا سا موقع پر تھا۔ کمپنی کا خیال تھا کہ ان کا وجود ہونا چاہیے، لیکن کوئی بھی کبھی معیار قائم نہیں کرتا. تکنیکی مدد نے کبھی بھی SLA کو نہیں دیکھا، اس لیے یہ گروپ کے لیے کافی "قابل قبول" تھا (اور اس نے مجھے سب سے زیادہ متاثر کیا):
- 12 سیکنڈ لوڈنگ؛
- ہر ریلیز میں 5-10 منٹ کا ڈاؤن ٹائم؛
- اہم مسائل کو حل کرنے میں دن اور ہفتے لگتے ہیں۔
- ڈیوٹی اہلکاروں کی کمی 24x7 / آن کال۔
کسی نے کبھی یہ پوچھنے کی کوشش نہیں کی کہ ہم اسے بہتر کیوں نہیں کرتے، اور کسی نے کبھی محسوس نہیں کیا کہ ایسا نہیں ہونا چاہیے۔
بونس کے طور پر، ایک اور مسئلہ تھا: تجربے کی کمی. سینئرز چلے گئے، اور باقی نوجوان ٹیم پچھلی حکومت میں پروان چڑھی اور اس نے زہر کھا لیا۔
اس سب سے بڑھ کر لوگ ناکام ہونے اور نااہل ہونے کا خوف بھی رکھتے تھے۔ یہ اس حقیقت میں ظاہر ہوتا ہے کہ، سب سے پہلے، وہ کسی بھی حالت میں مدد کے لئے نہیں کہا. ہم نے کتنی بار ایک گروپ کے طور پر اور انفرادی طور پر بات کی ہے، اور میں نے کہا ہے، "اگر آپ کچھ کرنا نہیں جانتے ہیں تو ایک سوال پوچھیں۔" مجھے اپنے آپ پر اعتماد ہے اور میں جانتا ہوں کہ میں کسی بھی مسئلے کو حل کر سکتا ہوں، لیکن اس میں وقت لگے گا۔ لہذا، اگر میں کسی سے پوچھ سکتا ہوں جو جانتا ہے کہ اسے 10 منٹ میں کیسے حل کرنا ہے، تو میں پوچھوں گا۔ آپ کا تجربہ جتنا کم ہوگا، آپ پوچھنے سے اتنا ہی زیادہ ڈرتے ہیں کیونکہ آپ کو لگتا ہے کہ آپ کو نااہل سمجھا جائے گا۔
سوال پوچھنے کا یہ خوف خود کو دلچسپ طریقوں سے ظاہر کرتا ہے۔ مثال کے طور پر، آپ پوچھتے ہیں: "آپ اس کام کے ساتھ کیسے کر رہے ہیں؟" - "کچھ گھنٹے باقی ہیں، میں پہلے ہی ختم کر رہا ہوں۔" اگلے دن آپ دوبارہ پوچھتے ہیں، آپ کو جواب ملتا ہے کہ سب ٹھیک ہے، لیکن ایک مسئلہ تھا، وہ دن کے آخر تک ضرور تیار ہو جائے گا۔ ایک اور دن گزر جاتا ہے، اور جب تک آپ کو دیوار سے لگا کر کسی سے بات کرنے پر مجبور نہیں کیا جاتا، یہ سلسلہ جاری رہتا ہے۔ ایک شخص کسی مسئلے کو خود حل کرنا چاہتا ہے، اسے یقین ہے کہ اگر اس نے اسے خود حل نہیں کیا تو یہ بہت بڑی ناکامی ہوگی۔
لہذا ڈویلپرز نے تخمینوں کو بڑھا دیا۔. یہ وہی قصہ تھا، جب وہ کسی کام پر بحث کر رہے تھے، انہوں نے مجھے ایسی شخصیت دی کہ میں بہت حیران ہوا۔ جس پر مجھے بتایا گیا کہ ڈویلپر کے تخمینوں میں، ڈویلپر وہ وقت شامل کرتا ہے جب ٹکٹ QA سے واپس کیا جائے گا، کیونکہ انہیں وہاں غلطیاں نظر آئیں گی، اور PR کو جو وقت لگے گا، اور وہ وقت جو لوگ جائزہ لیں گے۔ یہ مصروف ہو جائے گا - یعنی، سب کچھ، جو بھی ممکن ہے۔
دوسرے وہ لوگ جو نااہل ہونے سے ڈرتے ہیں۔ overanalyse. جب آپ کہتے ہیں کہ بالکل کیا کرنے کی ضرورت ہے، تو یہ شروع ہوتا ہے: "نہیں، اگر ہم یہاں اس کے بارے میں سوچیں تو کیا ہوگا؟" اس لحاظ سے، ہماری کمپنی منفرد نہیں ہے؛ یہ نوجوانوں کے لیے ایک معیاری مسئلہ ہے۔
جواب میں، میں نے مندرجہ ذیل طریقوں کو متعارف کرایا:
- اصول 30 منٹ۔ اگر آپ آدھے گھنٹے میں مسئلہ حل نہیں کر سکتے تو کسی سے مدد کے لیے کہیں۔ یہ کامیابی کے مختلف درجات کے ساتھ کام کرتا ہے، کیونکہ لوگ اب بھی نہیں پوچھتے، لیکن کم از کم عمل شروع ہو چکا ہے۔
- جوہر کے علاوہ ہر چیز کو ختم کریں۔کسی کام کو مکمل کرنے کی آخری تاریخ کا تخمینہ لگاتے ہوئے، یعنی صرف اس بات پر غور کریں کہ کوڈ لکھنے میں کتنا وقت لگے گا۔
- زندگی بھر سیکھنا زیادہ تجزیہ کرنے والوں کے لیے۔ یہ صرف لوگوں کے ساتھ مستقل کام ہے۔
ساٹھواں دن
جب میں یہ سب کر رہا تھا، یہ بجٹ کا اندازہ لگانے کا وقت تھا۔ بلاشبہ، مجھے بہت سی دلچسپ چیزیں ملیں جہاں ہم نے اپنا پیسہ خرچ کیا۔ مثال کے طور پر، ہمارے پاس ایک FTP سرور کے ساتھ ایک علیحدہ ڈیٹا سینٹر میں ایک پورا ریک تھا، جسے ایک کلائنٹ استعمال کرتا تھا۔ یہ پتہ چلا کہ "... ہم چلے گئے، لیکن وہ ایسے ہی رہا، ہم نے اسے تبدیل نہیں کیا۔" یہ 2 سال پہلے تھا.
خاص دلچسپی کلاؤڈ سروسز کا بل تھا۔ مجھے یقین ہے کہ زیادہ کلاؤڈ بل کی بنیادی وجہ وہ ڈویلپرز ہیں جن کی زندگی میں پہلی بار سرورز تک لامحدود رسائی ہے۔ انہیں یہ پوچھنے کی ضرورت نہیں ہے: "براہ کرم مجھے ایک ٹیسٹ سرور دیں،" وہ خود اسے لے سکتے ہیں۔ اس کے علاوہ، ڈویلپرز ہمیشہ ایسا ٹھنڈا نظام بنانا چاہتے ہیں کہ فیس بک اور نیٹ فلکس کو رشک آئے۔
لیکن ڈویلپرز کے پاس سرورز خریدنے کا تجربہ اور سرورز کے مطلوبہ سائز کا تعین کرنے کا ہنر نہیں ہے، کیونکہ انہیں پہلے اس کی ضرورت نہیں تھی۔ اور وہ عام طور پر اسکیل ایبلٹی اور کارکردگی کے درمیان فرق کو نہیں سمجھتے ہیں۔
انوینٹری کے نتائج:
- ہم نے وہی ڈیٹا سینٹر چھوڑا۔
- ہم نے 3 لاگ سروسز کے ساتھ معاہدہ ختم کر دیا۔ کیونکہ ہمارے پاس ان میں سے 5 تھے - ہر ڈویلپر جس نے کسی چیز کے ساتھ کھیلنا شروع کیا ایک نیا لیا۔
- 7 AWS سسٹم کو بند کر دیا گیا۔ ایک بار پھر، کسی نے مردہ منصوبوں کو نہیں روکا، وہ سب کام کرتے رہے۔
- سافٹ ویئر کی قیمتوں میں 6 گنا کمی کی گئی۔
پچھتر دن
وقت گزرتا گیا اور ڈھائی ماہ میں مجھے بورڈ آف ڈائریکٹرز سے ملنا پڑا۔ ہمارا بورڈ آف ڈائریکٹرز دوسروں سے بہتر یا بدتر نہیں ہے؛ تمام بورڈ آف ڈائریکٹرز کی طرح، یہ سب کچھ جاننا چاہتا ہے۔ لوگ پیسہ لگاتے ہیں اور یہ سمجھنا چاہتے ہیں کہ ہم جو کچھ کرتے ہیں وہ KPIs میں کتنا فٹ بیٹھتا ہے۔
بورڈ آف ڈائریکٹرز ہر ماہ بہت ساری معلومات حاصل کرتا ہے: صارفین کی تعداد، ان کی ترقی، وہ کون سی خدمات استعمال کرتے ہیں اور کیسے، کارکردگی اور پیداواری صلاحیت، اور آخر میں، صفحہ لوڈ کرنے کی اوسط رفتار۔
صرف مسئلہ یہ ہے کہ میں مانتا ہوں کہ اوسط خالص برائی ہے۔ لیکن بورڈ آف ڈائریکٹرز کو اس کی وضاحت کرنا بہت مشکل ہے۔ وہ مجموعی نمبروں کے ساتھ کام کرنے کے عادی ہیں، اور مثال کے طور پر، فی سیکنڈ لوڈنگ اوقات کا پھیلاؤ نہیں۔
اس حوالے سے کچھ دلچسپ نکات تھے۔ مثال کے طور پر، میں نے کہا کہ ہمیں مواد کی قسم کے لحاظ سے ٹریفک کو الگ الگ ویب سرورز کے درمیان تقسیم کرنے کی ضرورت ہے۔
یعنی، ColdFusion Jetty اور nginx کے ذریعے جاتا ہے اور صفحات کو لانچ کرتا ہے۔ اور امیجز، جے ایس اور سی ایس ایس اپنی اپنی کنفیگریشنز کے ساتھ الگ الگ نگینکس سے گزرتے ہیں۔ یہ کافی معیاری پریکٹس ہے جس کے بارے میں میں بات کر رہا ہوں۔ چند سال پہلے نتیجتاً، تصاویر بہت تیزی سے لوڈ ہوتی ہیں، اور... لوڈنگ کی اوسط رفتار میں 200 ms کا اضافہ ہوا ہے۔
ایسا اس لیے ہوا کیونکہ گراف جیٹی کے ساتھ آنے والے ڈیٹا کی بنیاد پر بنایا گیا ہے۔ یعنی حساب میں تیز مواد شامل نہیں ہے - اوسط قدر بڑھ گئی ہے۔ یہ ہمارے لیے واضح تھا، ہم ہنسے، لیکن ہم بورڈ آف ڈائریکٹرز کو کیسے سمجھائیں کہ ہم نے کچھ کیوں کیا اور چیزیں 12 فیصد تک خراب ہوئیں؟
پچاسی دن
تیسرے مہینے کے اختتام پر، میں نے محسوس کیا کہ ایک چیز تھی جس پر میں نے بالکل بھی شمار نہیں کیا تھا: وقت۔ میں نے جس چیز کے بارے میں بات کی ہے اس میں وقت لگتا ہے۔
یہ میرا حقیقی ہفتہ وار کیلنڈر ہے - صرف کام کا ہفتہ، زیادہ مصروف نہیں۔ ہر چیز کے لیے کافی وقت نہیں ہوتا۔ لہذا، ایک بار پھر، آپ کو ایسے لوگوں کو بھرتی کرنے کی ضرورت ہے جو مسائل سے نمٹنے میں آپ کی مدد کریں گے۔
حاصل يہ ہوا
یہ سب کچھ نہیں ہے۔ اس کہانی میں، میں یہ بھی نہیں جان سکا کہ ہم نے پروڈکٹ کے ساتھ کس طرح کام کیا اور عام لہر سے ہم آہنگ ہونے کی کوشش کی، یا ہم نے تکنیکی مدد کو کیسے مربوط کیا، یا ہم نے دیگر تکنیکی مسائل کو کیسے حل کیا۔ مثال کے طور پر، میں نے اتفاقی طور پر سیکھا کہ ڈیٹا بیس میں سب سے بڑی میزوں پر ہم استعمال نہیں کرتے ہیں۔ SEQUENCE. ہمارے پاس خود تحریری فعل ہے۔ nextID، اور یہ کسی لین دین میں استعمال نہیں ہوتا ہے۔
اسی طرح کی مزید ایک ملین چیزیں تھیں جن کے بارے میں ہم طویل عرصے تک بات کر سکتے ہیں۔ لیکن سب سے اہم بات جو اب بھی کہنے کی ضرورت ہے وہ ثقافت ہے۔
یہ ثقافت ہے یا اس کی کمی باقی تمام مسائل کو جنم دیتی ہے۔ ہم ایک ایسی ثقافت بنانے کی کوشش کر رہے ہیں جہاں لوگ:
- ناکامیوں سے نہیں ڈرتے؛
- غلطیوں سے سیکھیں؛
- دیگر ٹیموں کے ساتھ تعاون؛
- پہل کرنا؛
- ذمہ داری لو؛
- نتیجہ کو ایک مقصد کے طور پر خوش آمدید؛
- کامیابی کا جشن
اس کے ساتھ باقی سب کچھ آجائے گا۔
لیون فائر , اور پر .
میراث کے حوالے سے دو حکمت عملی ہیں: ہر قیمت پر اس کے ساتھ کام کرنے سے گریز کریں، یا اس سے منسلک مشکلات پر بہادری سے قابو پالیں۔ ہم c ہم دوسرا راستہ اختیار کر رہے ہیں، عمل اور نقطہ نظر کو تبدیل کر رہے ہیں۔ ہمارے ساتھ شامل ہوں۔ , и ، اور ہم مل کر ایک DevOps کلچر نافذ کریں گے۔
ماخذ: www.habr.com