اس آرٹیکل میں، میں اپنی مصنوعات کی فعالیت کو بڑھانے کے لیے آئیڈیاز کے انتخاب میں اپنے تجربے کا اشتراک کروں گا اور آپ کو بتاؤں گا کہ ترقی کے اہم ویکٹرز کو کیسے برقرار رکھا جائے۔
ہم ایک خودکار سیٹلمنٹ سسٹم (ACP) - بلنگ تیار کر رہے ہیں۔ مدت
ہماری مصنوعات کی زندگی 14 سال ہے. اس وقت کے دوران، یہ نظام صنعتی ٹیرف سسٹم کے پہلے ورژن سے ایک ماڈیولر کمپلیکس میں تبدیل ہوا ہے جس میں 18 مصنوعات شامل ہیں جو ایک دوسرے کی تکمیل کرتی ہیں۔ پروگراموں کی لمبی عمر کا سب سے اہم پہلو مسلسل ترقی ہے۔ اور ترقی کے لیے خیالات کی ضرورت ہوتی ہے۔
Идеи
ذرائع
5 ذرائع ہیں:
- کارپوریٹ انفارمیشن سسٹم ڈویلپر کا اہم دوست ہے۔ مؤکل. اور کلائنٹ فیصلہ سازوں، پراجیکٹ کے اسپانسرز، مالکان اور عمل کو انجام دینے والوں، اندرون ملک آئی ٹی ماہرین، عام صارفین اور مختلف درجات تک دلچسپی رکھنے والے افراد کی ایک بڑی تعداد کی اجتماعی تصویر ہے۔ ہمارے لیے یہ اہم ہے کہ کلائنٹ کے نمائندوں میں سے ہر ایک ممکنہ طور پر خیالات کا فراہم کنندہ ہے۔ بدترین صورت میں، ہمیں سسٹم میں موجود مسائل کے بارے میں صرف منفی تاثرات موصول ہوتے ہیں۔ بہترین صورت میں، کلائنٹ کی طرف ایک ایسا شخص ہے جو بہتری کے لیے خیالات کا مستقل ذریعہ ہے، جو کلائنٹ کی ضروریات کے بارے میں منظم معلومات فراہم کرتا ہے۔
- ہمارا۔ سیلز لوگ اور اکاؤنٹ مینیجرز بہتری کے لیے خیالات کا دوسرا اہم ترین ذریعہ ہیں۔ وہ صنعت کے نمائندوں کے ساتھ فعال اور وسیع پیمانے پر بات چیت کرتے ہیں اور ممکنہ گاہکوں سے بلنگ کی فعالیت کے بارے میں پہلے ہاتھ سے پوچھ گچھ حاصل کرتے ہیں۔ فروخت کنندگان اور اکاؤنٹس کو اپنی فعالیت میں تمام اہم تبدیلیوں اور حریفوں کے سافٹ ویئر کی تازہ ترین اپ ڈیٹس سے آگاہ ہونا چاہیے، اور مختلف حلوں کے فوائد اور نقصانات کا جواز پیش کرنے کے قابل ہونا چاہیے۔ یہ ہمارے ملازمین ہیں جو سب سے پہلے اس بات کا احساس کرتے ہیں کہ آیا کچھ بلنگ کی صلاحیتیں ایک حقیقی معیار بن جاتی ہیں، جس کے بغیر سافٹ ویئر کو مکمل نہیں سمجھا جا سکتا۔
- پروڈکٹ کا مالک - ہمارے اعلی مینیجرز میں سے ایک یا بہت تجربہ کار پروجیکٹ مینیجر۔ کمپنی کے اسٹریٹجک اہداف کو ذہن میں رکھتا ہے اور ان کے مطابق مصنوعات کی ترقی کے منصوبوں کو ایڈجسٹ کرتا ہے۔
- آرکیٹیکچر، ایک ایسا شخص جو منتخب کردہ / استعمال شدہ ٹیکنالوجی کے حل کی صلاحیتوں اور حدود اور مصنوعات کی ترقی پر ان کے اثرات کو سمجھتا ہے۔
ترقی اور جانچ ٹیمیں۔ وہ لوگ جو مصنوعات کی ترقی میں براہ راست ملوث ہیں۔
درخواستوں کی درجہ بندی
ہمیں ذرائع سے خام ڈیٹا موصول ہوتا ہے - خطوط، ٹکٹ، زبانی درخواستیں۔ تمام
اپیلوں کی درجہ بندی کی گئی ہے:
- مشاورت معنی کے ساتھ "یہ کیسے کریں؟"، "یہ کیسے کام کرتا ہے؟"، "یہ کیوں کام نہیں کرتا؟"، "میں نہیں سمجھتا..."۔ اس قسم کی درخواستیں لیول 1 سپورٹ لائن پر جاتی ہیں۔ دیگر قسم کی درخواستوں میں مشاورت کو دوبارہ تربیت دینا ممکن ہے۔
- واقعات "کام نہیں کرتا" اور "خرابی" کے معنی کے ساتھ۔ 2 اور 3 سپورٹ لائنز کے ذریعے کارروائی کی جاتی ہے۔ اگر فوری تصحیح اور پیچ کی رہائی ضروری ہے، تو انہیں سپورٹ سے براہ راست ترقی میں منتقل کیا جا سکتا ہے۔ اسے تبدیلی کی درخواست کے طور پر دوبارہ درجہ بندی کرنا اور اسے بیک لاگ پر بھیجنا ممکن ہے۔
- تبدیلیوں اور ترقی کی درخواستیں۔. وہ سپورٹ لائنز کو نظرانداز کرتے ہوئے پروڈکٹ بیک لاگ میں داخل ہو جاتے ہیں۔ لیکن ان کے لیے الگ پروسیسنگ کا طریقہ کار ہے۔
درخواستوں کے اعداد و شمار موجود ہیں: رہائی کے فوراً بعد، درخواستوں کی تعداد میں 10-15 فیصد اضافہ ہوتا ہے۔ درخواستوں میں اضافہ بھی ہوتا ہے جب صارفین کی ایک بڑی تعداد کے ساتھ ایک نیا کلائنٹ ہماری کلاؤڈ سروسز پر آتا ہے۔ لوگ سافٹ ویئر کی نئی صلاحیتوں کو استعمال کرنا سیکھ رہے ہیں، انہیں مشورہ کی ضرورت ہے۔ یہاں تک کہ ایک چھوٹا سا کلائنٹ، جب سسٹم میں کام کرنا شروع کرتا ہے، ہر ماہ 100 گھنٹے سے زیادہ مشورے آسانی سے جلا دیتا ہے۔ لہذا، جب کسی نئے کلائنٹ کو جوڑتے ہیں، تو ہم ہمیشہ ابتدائی مشاورت کے لیے وقت محفوظ رکھتے ہیں۔ اکثر ہم ایک مخصوص ماہر کا انتخاب بھی کرتے ہیں۔ کرائے کی قیمت، یقیناً، مزدوری کے ان اخراجات کو پورا نہیں کرتی، لیکن وقت گزرنے کے ساتھ ساتھ صورت حال یکسر بدل جاتی ہے۔ موافقت کی مدت عام طور پر 1 سے 3 ماہ تک ہوتی ہے، جس کے بعد مشاورت کی ضرورت نمایاں طور پر کم ہو جاتی ہے۔
پہلے، ہم درخواستوں کو ذخیرہ کرنے کے لیے خود تحریری حل استعمال کرتے تھے۔ لیکن ہم آہستہ آہستہ Atlassian مصنوعات میں تبدیل ہو گئے۔ سب سے پہلے، ہم نے ترقی کو منتقل کیا تاکہ Agile کے مطابق کام کرنا آسان ہو، پھر سپورٹ۔ اب تمام اہم عمل جیرا ایس ڈی میں رہتے ہیں، نیز ان کو جیرا کے علاوہ سنگم کے لیے مختلف پلگ انز کی مدد حاصل ہے۔ خود تحریری حل صرف ان عملوں کے لیے رہے جو کمپنی کی سرگرمیوں کے لیے اہم نہیں تھے۔ یہ پتہ چلتا ہے کہ ہمارے کام اب کراس کٹنگ کر رہے ہیں اور ایک سسٹم سے دوسرے میں کودنے کے بغیر مدد اور ترقی کے درمیان منتقل ہو سکتے ہیں۔
اس لنک سے ہم تمام کاموں، منصوبہ بند اور حقیقی مزدوری کے اخراجات کا ڈیٹا حاصل کر سکتے ہیں، کلائنٹس کے لیے قیمتوں کے مختلف اختیارات استعمال کر سکتے ہیں اور اندرونی ضروریات کے لیے دستاویزات تیار کر سکتے ہیں اور کلائنٹس کو رپورٹ کر سکتے ہیں۔
تبدیلی کی درخواستوں پر کارروائی ہو رہی ہے۔
عام طور پر، ایسی درخواستیں فعالیت کی ضروریات کی شکل میں آتی ہیں۔ ہمارا تجزیہ کار درخواست کا مطالعہ کرتا ہے، ایک تصریح اور اعلیٰ سطحی تکنیکی وضاحتیں تخلیق کرتا ہے۔ تصریحات اور تکنیکی وضاحتیں اس شخص کو منتقل کرتا ہے جس نے یہ درخواست منظوری کے لیے پیش کی تھی - ہمیں اس بات کا یقین ہونا چاہیے کہ ہم گاہک کے ساتھ وہی زبان بولتے ہیں۔
گاہک سے تصدیق موصول ہونے کے بعد کہ ہم ایک دوسرے کو صحیح طریقے سے سمجھتے ہیں، تجزیہ کار درخواست کو پروڈکٹ کے بیک لاگ میں داخل کرتا ہے۔
مصنوعات کی فعالیت کا انتظام
بیک لاگ تبدیلی اور ترقی کے لیے آنے والی درخواستوں کو جمع کرتا ہے۔ تکنیکی کونسل، جس میں ڈائریکٹر، سپورٹ، ڈیولپمنٹ، سیلز اور سسٹم آرکیٹیکٹ کے سربراہ ہوتے ہیں، ہر چھ ماہ بعد میٹنگ کرتے ہیں۔ بحث کی شکل میں، کونسل بیک لاگ سے درخواستوں کا تجزیہ اور ترجیح دیتی ہے اور اگلی ریلیز میں عمل درآمد کے لیے 5 ترقیاتی کاموں پر اتفاق کرتی ہے۔
درحقیقت، تکنیکی کونسل درخواستوں میں ظاہر کی گئی ضروریات کا جائزہ لے کر صنعت اور مارکیٹ کے مطالبات کا جواب دیتی ہے۔ ہر وہ چیز جو بہت کم اہمیت کی حامل ہے وہ بیک لاگ میں رہتی ہے اور ترقی تک نہیں پہنچتی۔
تبدیلی کی درخواستوں اور مالیات کی درجہ بندی
ترقی مہنگی ہے۔ لہذا، ہم فوری طور پر آپ کو بتائیں گے کہ اگر تبدیلی کی درخواست کسی ملازم کی طرف سے نہیں بلکہ کسی کلائنٹ کی طرف سے آئی ہے تو ہمارے پاس کیا اختیارات ہو سکتے ہیں۔
ہم تبدیلی کی درخواستوں کو درج ذیل درجہ بندی کرتے ہیں: صنعت کی ضرورت یا انٹرپرائز کی انفرادی خصوصیت؛ نئی فعالیت کی ایک اہم مقدار یا معمولی اصلاح۔ معمولی اصلاحات اور انفرادی درخواستوں پر بغیر کسی جھنجٹ کے کارروائی کی جاتی ہے۔ کسی مخصوص کلائنٹ کے ساتھ پروجیکٹ کے کام کے حصے کے طور پر انفرادی درخواستوں کا حساب لگایا جاتا ہے اور اس پر عمل درآمد کیا جاتا ہے۔
اگر یہ بڑے پیمانے پر صنعت کی ضرورت نہیں ہے اور فعالیت کا حجم بڑا ہے، تو ایک نیا الگ ماڈیول تیار کرنے کا فیصلہ کیا جا سکتا ہے جو مرکزی فعالیت کے علاوہ فروخت کیا جائے گا۔ اگر کسی کلائنٹ کی طرف سے ایسی درخواست موصول ہوتی ہے، تو ہم ماڈیول تیار کرنے کے اخراجات پورے کر سکتے ہیں، کلائنٹ کو ماڈیول مفت یا جزوی ادائیگی کے ساتھ فراہم کر سکتے ہیں، اور ماڈیول کو خود فروخت کے لیے پیش کر سکتے ہیں۔ ایسی صورت حال میں، کلائنٹ طریقہ کار کے بوجھ کا حصہ لیتا ہے اور بنیادی طور پر خود پر ماڈیول کا پائلٹ نفاذ کرتا ہے۔
اگر یہ بڑے پیمانے پر صنعت کی ضرورت ہے، تو بنیادی مصنوعات میں نئی فعالیت کو شامل کرنے کا فیصلہ کیا جا سکتا ہے۔ اس معاملے میں اخراجات مکمل طور پر ہم پر آتے ہیں، اور نئی فعالیت پروگراموں کے موجودہ ورژن میں ظاہر ہوتی ہے۔
پرانے صارفین کو اپ ڈیٹ فراہم کیا جاتا ہے۔
یہ بھی ہو سکتا ہے کہ کئی صارفین کو ایک جیسی ضرورت ہو، لیکن یہ بڑے پیمانے پر پروڈکٹ کے لیے اہل نہیں ہے۔ اس صورت میں، ہم ان صارفین کو تفصیلات بھیج سکتے ہیں اور ان کے درمیان ترقیاتی اخراجات کو تقسیم کرنے کی پیشکش کر سکتے ہیں۔ آخر میں، ہر کوئی جیتتا ہے: صارفین کو کم قیمت پر فعالیت ملتی ہے، ہم پروڈکٹ کو بہتر بناتے ہیں، اور کچھ وقت کے بعد، دیگر مارکیٹ کے شرکاء بھی اپنے استعمال کے لیے فعالیت حاصل کر سکتے ہیں۔
DevOps
ترقی ایک سال میں دو بڑی ریلیز تیار کرتی ہے۔ ہر ریلیز میں، تکنیکی کونسل سے موصول ہونے والے 5 کاموں کے نفاذ کے لیے وقت مختص ہے۔ اس طرح، معمول کے درمیان، ہم مصنوعات کی ترقی کو کبھی نہیں بھولتے ہیں۔
ہر ریلیز جانچ اور دستاویزات کے ایک مناسب سیٹ سے گزرتی ہے۔ اس کے بعد، اس ریلیز کو متعلقہ کسٹمر کے ٹیسٹ ماحول میں انسٹال کیا جاتا ہے، جو بدلے میں، ہر چیز کو احتیاط سے چیک کرتا ہے اور اس کے بعد ہی ریلیز کو پروڈکشن میں منتقل کیا جاتا ہے۔
ریلیز سسٹم کے علاوہ، فوری بگ فکسز کے لیے ایک فارمیٹ ہے تاکہ کلائنٹ چھ ماہ تک غلطیوں کے ساتھ نہ رہیں۔ یہ انٹرمیڈیٹ فارمیٹ آپ کو پہلی ترجیحی واقعات کا فوری جواب دینے اور بیان کردہ SLAs کو پورا کرنے کی اجازت دے گا۔
مندرجہ بالا سبھی بنیادی طور پر کارپوریٹ سیکٹر اور آن پریمائس حل کے لیے درست ہیں۔ کلاؤڈ سروسز کے لیے جن کا مقصد SMB طبقہ ہے، کلائنٹس کے لیے مصنوعات کی ترقی میں حصہ لینے کے اتنے وسیع مواقع نہیں ہیں۔ ایس ایم بی رینٹل فارمیٹ اس کو فرض بھی نہیں کرتا ہے۔ کارپوریٹ پارٹی کی جانب سے واضح تقاضوں کی صورت میں تبدیلی کی درخواست کے بجائے، یہاں خدمت کے لیے صرف عام تاثرات اور خواہشات ہیں۔ ہم سننے کی کوشش کرتے ہیں، لیکن پروڈکٹ بہت زیادہ ہے اور ایک کلائنٹ کی اپنے پرانے تاریخی نظام سے کچھ واقف لانے کی خواہش مجموعی طور پر نظام کی ترقی کی حکمت عملی سے متصادم ہو سکتی ہے۔
ماخذ: www.habr.com