اسان پنهنجي پروڊڪٽس جي ترقي لاءِ خيال ڪيئن چونڊيندا آهيون: وينڊر ضرور ٻڌڻ جي قابل هوندو…

هن آرٽيڪل ۾، مان پنهنجي پروڊڪٽس جي ڪارڪردگي کي ترقي ڪرڻ لاء خيالن جي چونڊ ۾ منهنجو تجربو حصيداري ڪندس ۽ توهان کي ٻڌايان ٿو ته ڪيئن ترقي جي مکيه ویکٹر کي برقرار رکڻ لاء.

اسان ترقي ڪري رهيا آهيون هڪ خودڪار آبادي وارو نظام (ACP) - بلنگ. اصطلاح
اسان جي پيداوار جي زندگي 14 سال آهي. هن عرصي دوران، سسٽم هڪ صنعتي ٽريف سسٽم جي پهرين نسخن کان هڪ ماڊلر ڪمپليڪس تائين ترقي ڪئي آهي جنهن ۾ 18 مصنوعات شامل آهن جيڪي هڪ ٻئي کي پورو ڪن ٿيون. پروگرامن جي ڊگھي عمر جي سڀ کان اهم حصن مان هڪ مسلسل ترقي آهي. ۽ ترقي خيال جي ضرورت آهي.

Идеи

ذريعو

5 ذريعا آهن:

  1. هڪ ڪارپوريٽ انفارميشن سسٽم ڊولپر جو مکيه دوست آهي گراهڪ. ۽ ڪلائنٽ فيصلي سازن، پروجيڪٽ اسپانسرز، مالڪن ۽ عملن جي عملدار، اندروني IT ماهرن، عام استعمال ڪندڙن ۽ مختلف درجن تائين دلچسپي رکندڙ ماڻهن جي وڏي تعداد جي هڪ اجتماعي تصوير آهي. اهو اسان لاءِ اهم آهي ته ڪلائنٽ جي نمائندن مان هر هڪ ممڪن طور تي خيالن جو سپلائر آهي. بدترين حالت ۾، اسان صرف سسٽم ۾ مسئلن بابت منفي موٽ حاصل ڪندا آهيون. بهترين صورت ۾، ڪلائنٽ جي پاسي تي هڪ شخص آهي جيڪو بهتري لاء خيالن جو مسلسل ذريعو آهي، ڪلائنٽ جي ضرورتن بابت منظم معلومات مهيا ڪري ٿو.
  2. اسان جو وڪرو ڪندڙ ۽ اڪائونٽ مينيجرز بهتري لاءِ خيالن جو ٻيو اهم ذريعو آهن. اهي فعال طور تي ۽ وسيع طور تي صنعت جي نمائندن سان رابطو ڪن ٿا ۽ امڪاني گراهڪن کان بلنگ ڪارڪردگي بابت پهرين هٿ جي پڇا ڳاڇا حاصل ڪن ٿا. وڪرو ڪندڙ ۽ اڪائونٽس کي انهن جي ڪارڪردگي ۾ سڀني اهم تبديلين کان آگاهي ٿيڻ گهرجي ۽ مقابلي جي سافٽ ويئر جي تازي تازه ڪاريون، ۽ مختلف حلن جي فائدن ۽ نقصان کي درست ڪرڻ جي قابل ٿي. اهي اسان جا ملازم آهن جن کي سڀ کان پهريان احساس آهي ته جيڪڏهن ڪجهه بلنگ صلاحيتون هڪ حقيقي معيار بڻجي وڃن ٿيون، جنهن جي بغير سافٽ ويئر مڪمل سمجهي نه ٿو سگهجي.
  3. پيداوار جو مالڪ - اسان جي اعليٰ مينيجرز مان هڪ يا هڪ تمام تجربيڪار پروجيڪٽ مئنيجر. ڪمپني جي اسٽريٽجڪ مقصدن کي ذهن ۾ رکي ٿو ۽ انهن جي مطابق پيداوار جي ترقي جي منصوبن کي ترتيب ڏئي ٿو.
  4. معمار، هڪ شخص جيڪو سمجهي ٿو صلاحيتن ۽ حدن جي ٽيڪنالاجي حلن جي چونڊيل/استعمال ۽ پيداوار جي ترقي تي انهن جو اثر.
    ترقي ۽ جاچ ٽيمون. ماڻهو جيڪي سڌو سنئون پيداوار جي ترقي ۾ ملوث آهن.

درخواستن جي درجه بندي

اسان ذريعن کان خام ڊيٽا وصول ڪندا آهيون - خط، ٽڪيٽ، زباني درخواستون. سڀ
اپيلون ورهايل آهن:

  • صلاح مشورا معنى سان "اهو ڪيئن ڪجي؟"، "اهو ڪيئن ڪم ڪري ٿو؟"، "اهو ڇو نٿو ڪم ڪري؟"، "مان نه ٿو سمجهان ...". ھن قسم جون درخواستون ليول 1 سپورٽ لائن ڏانھن وڃو. اهو ممڪن آهي ته صلاح مشوري کي ٻين قسمن جي درخواستن ۾.
  • واقعا معنيٰ سان ”ڪم نٿو ڪري“ ۽ ”غلطي“. پروسيس ٿيل 2 ۽ 3 سپورٽ لائينون. جيڪڏهن تڪڙي اصلاح ۽ پيچ جي ڇڏڻ ضروري آهي، اهي منتقل ڪري سگھجن ٿيون سپورٽ کان سڌو ترقي ڏانهن. اهو ممڪن آهي ته ان کي تبديل ڪرڻ جي درخواست جي طور تي ٻيهر ورهايو وڃي ۽ ان کي بيڪ لاگ ڏانهن موڪليو.
  • تبديلين ۽ ترقي لاء درخواستون. اهي پراڊڪٽ جي پٺڀرائي ۾ داخل ٿين ٿا، سپورٽ لائنن کي پاس ڪندي. پر اتي انھن لاء هڪ الڳ پروسيسنگ طريقيڪار آهي.

درخواستن تي انگ اکر موجود آهن: فوري طور تي ڇڏڻ کان پوء، درخواستن جو تعداد 10-15٪ طرفان ٿورڙي وقت تائين وڌي ٿو. درخواستن ۾ اضافو پڻ آهن جڏهن هڪ نئون ڪلائنٽ وڏي تعداد ۾ صارفين سان گڏ اسان جي ڪلائوڊ سروسز تي اچي ٿو. ماڻهو نئين سافٽ ويئر جي صلاحيتن کي استعمال ڪرڻ سکندا آهن، انهن کي صلاح جي ضرورت آهي. جيتوڻيڪ هڪ ننڍڙو گراهڪ، جڏهن سسٽم ۾ ڪم ڪرڻ شروع ڪري، آساني سان هر مهيني 100 ڪلاڪن کان وڌيڪ مشوري کي ساڙي ٿو. تنهن ڪري، جڏهن هڪ نئين ڪلائنٽ کي ڳنڍيندي، اسان هميشه شروعاتي مشاورت لاء وقت محفوظ ڪندا آهيون. گهڻو ڪري اسان کي به هڪ خاص ماهر چونڊي. رينجر جي قيمت، يقينا، انهن مزدورن جي قيمتن کي پورو نٿو ڪري، پر وقت سان گڏ صورتحال به ختم ٿي ويندي آهي. موافقت وارو عرصو عام طور تي 1 کان 3 مهينن تائين وٺندو آهي، جنهن کان پوءِ صلاح مشوري جي ضرورت گهٽجي ويندي آهي.

اڳي، اسان درخواستن کي ذخيرو ڪرڻ لاءِ خود لکيل حل استعمال ڪندا هئاسين. پر اسان آهستي آهستي Atlassian شين ڏانهن رخ ڪيو. پهرين، اسان ترقي کي منتقل ڪيو ته جيئن ڪم ڪرڻ آسان بڻائي سگهجي Agile مطابق، پوءِ سپورٽ. ھاڻي سڀ نازڪ عمل Jira SD ۾ رھندا آھن، ان سان گڏ انھن جي مدد ڪئي ويندي آھي مختلف پلگ ان جي لاءِ Jira، plus Confluence. خود لکيل حل صرف عملن لاءِ رهي ٿو جيڪي ڪمپني جي سرگرمين لاءِ نازڪ نه هئا. اهو ظاهر ٿئي ٿو ته اسان جا ڪم هاڻي ڪراس ڪٽڻ وارا آهن ۽ هڪ سسٽم کان ٻئي کي ٽپو ڏيڻ کان سواء سپورٽ ۽ ترقي جي وچ ۾ منتقل ڪري سگهجي ٿو.

هن لنڪ مان اسان سڀني ڪمن، منصوبابندي ڪيل ۽ حقيقي مزدورن جي خرچن تي ڊيٽا حاصل ڪري سگهون ٿا، گراهڪن لاءِ مختلف قيمتن جا اختيار استعمال ڪري سگهون ٿا ۽ اندروني ضرورتن لاءِ دستاويز تيار ڪري سگهون ٿا ۽ گراهڪن کي رپورٽنگ ڪري سگهون ٿا.

تبديلي جي درخواستن تي عملدرآمد

عام طور تي، اهڙيون درخواستون ڪارڪردگي گهرجن جي صورت ۾ اچن ٿيون. اسان جو تجزيه نگار درخواست جو مطالعو ڪري ٿو، هڪ وضاحت ۽ اعليٰ سطحي ٽيڪنيڪل وضاحتون ٺاهي ٿو. وضاحتن ۽ ٽيڪنيڪل وضاحتن کي منتقل ڪري ٿو ان شخص ڏانهن جنهن هن درخواست کي منظوري لاءِ پيش ڪيو آهي - اسان کي پڪ ڪرڻ گهرجي ته اسان ڪسٽمر سان ساڳي ٻولي ڳالهايون ٿا.

ڪسٽمر کان تصديق حاصل ڪرڻ کان پوء اسان هڪ ٻئي کي صحيح طور تي سمجهي رهيا آهيون، تجزيه ڪندڙ درخواست کي پراڊڪٽ جي بيڪ لاگ ۾ داخل ڪري ٿو.

پيداوار جي ڪارڪردگي جو انتظام

پٺاڻ تبديلي ۽ ترقي لاءِ ايندڙ درخواستن کي گڏ ڪري ٿو. ٽيڪنيڪل ڪائونسل، جنهن ۾ ڊائريڪٽر، مدد، ترقي، سيلز ۽ سسٽم آرڪيٽيڪٽ جي سربراهن تي مشتمل آهي، هر ڇهن مهينن ۾ ملاقات ڪندو آهي. بحث جي شڪل ۾، ڪائونسل پٺاڻ مان ايپليڪيشنن جو تجزيو ۽ ترجيح ڏئي ٿي ۽ ايندڙ رليز ۾ عمل درآمد لاءِ 5 ترقياتي ڪمن تي اتفاق ڪري ٿي.

اثر ۾، ٽيڪنيڪل ڪائونسل ايپليڪيشنن ۾ بيان ڪيل ضرورتن جو جائزو وٺڻ سان صنعت ۽ مارڪيٽ جي مطالبن جو جواب ڏئي ٿو. هر شيءِ جيڪا ٿوري گهڻي لاڳاپي جي آهي، اها پٺتي پيل رهي ٿي ۽ ترقيءَ تائين نه پهچي ٿي.

تبديلي جي درخواستن ۽ ماليات جي درجه بندي

ترقي قيمتي آهي. تنهن ڪري، اسان توهان کي فوري طور تي ٻڌائينداسين ته اسان وٽ ڪهڙا اختيار هوندا جيڪڏهن تبديلي جي درخواست ڪنهن ڪلائنٽ کان آئي هجي ۽ نه ملازم کان.

اسان تبديلين جي درخواستن کي ھيٺئين طور تي درجه بندي ڪريون ٿا: صنعت جي ضرورت يا انٽرپرائز جي انفرادي خصوصيت؛ نئين ڪارڪردگي جو هڪ اهم مقدار يا هڪ معمولي اصلاح. نابالغ فيڪس ۽ انفرادي درخواستن تي عمل ڪيو وڃي ٿو بغير ڪنهن فريل جي. انفرادي درخواستون حساب ڪيون ويون آهن ۽ هڪ مخصوص ڪلائنٽ لاءِ ان سان گڏ منصوبي جي ڪم جي حصي جي طور تي لاڳو ڪيون ويون آهن.

جيڪڏهن اها وڏي صنعت جي ضرورت نه آهي ۽ ڪارڪردگي جو حجم وڏو آهي، ته هڪ نئون الڳ ماڊل ٺاهڻ جو فيصلو ٿي سگهي ٿو جيڪو مکيه ڪارڪردگي کان علاوه وڪرو ڪيو ويندو. جيڪڏهن اهڙي درخواست هڪ ڪلائنٽ کان ملي ٿي، اسان ماڊل کي ترقي ڪرڻ جي قيمت کي ڍڪي سگهون ٿا، ڪلائنٽ کي ماڊل سان مفت يا جزوي ادائيگي سان مهيا ڪري سگهون ٿا، ۽ ماڊل پاڻ کي وڪرو ڪرڻ لاء تيار ڪري سگهون ٿا. اهڙي صورتحال ۾، ڪلائنٽ طريقياتي لوڊ جو حصو وٺندو آهي ۽ لازمي طور تي پاڻ تي ماڊل جي پائلٽ عمل درآمد ڪري ٿو.

جيڪڏهن اها وڏي صنعت جي ضرورت آهي، ته پوءِ بنيادي پراڊڪٽ ۾ نئين ڪارڪردگي شامل ڪرڻ جو فيصلو ٿي سگهي ٿو. هن معاملي ۾ قيمت اسان تي مڪمل طور تي گر ٿي، ۽ نئين ڪارڪردگي پروگرامن جي موجوده ورزن ۾ ظاهر ٿئي ٿو.
پراڻن گراهڪن کي هڪ تازه ڪاري سان مهيا ڪيل آهن.

اهو پڻ ٿي سگهي ٿو ته ڪيترن ئي گراهڪن کي هڪجهڙائي جي ضرورت آهي، پر اهو هڪ وڏي پيداوار لاء قابل نه آهي. انهي صورت ۾، اسان انهن گراهڪن کي وضاحت موڪلي سگهون ٿا ۽ انهن جي وچ ۾ ترقياتي خرچن کي ورهائڻ جي آڇ ڪري سگهون ٿا. آخر ۾، هرڪو کٽي ٿو: گراهڪ گهٽ قيمت تي ڪارڪردگي حاصل ڪندا آهيون، اسان پيداوار کي بهتر بڻائي سگهون ٿا، ۽ ڪجهه وقت کان پوء، ٻين مارڪيٽ شرڪت پڻ انهن جي استعمال لاء ڪارڪردگي حاصل ڪري سگھن ٿا.

DevOps

ترقي هڪ سال ۾ ٻه اهم رليز تيار ڪري ٿي. هر رليز ۾، ٽيڪنيڪل ڪائونسل کان حاصل ڪيل 5 ڪمن تي عمل درآمد لاءِ وقت مخصوص ڪيو ويو آهي. اهڙيء طرح، معمولي جي وچ ۾، اسان ڪڏهن به پيداوار جي ترقي بابت نه وساريو.

هر رليز ٽيسٽ ۽ دستاويزن جي هڪ مناسب سيٽ مان گذري ٿو. اڳيون، هي رليز لاڳاپيل ڪسٽمر جي امتحان واري ماحول ۾ نصب ڪيو ويو آهي، جيڪو، موڙ ۾، احتياط سان هر شي کي جانچيندو آهي ۽ صرف ان کان پوء رليز پيداوار ڏانهن منتقل ڪيو ويندو آهي.

رليز سسٽم کان علاوه، تڪڙو بگ فڪسس لاءِ هڪ فارميٽ آهي ته جيئن گراهڪ ڇهن مهينن تائين غلطين سان نه رهن. هي وچولي فارميٽ توهان کي پهرين ترجيحي واقعن جو تڪڙو جواب ڏيڻ ۽ بيان ڪيل SLAs کي پورو ڪرڻ جي اجازت ڏيندو.

مٿين سڀني جو صحيح آهي بنيادي طور تي ڪارپوريٽ شعبي ۽ بنياد تي حل لاءِ. ڪلائوڊ سروسز لاءِ جن جو مقصد SMB ڀاڱي ۾ آهي، اتي ڪي به وسيع موقعا نه آهن گراهڪن لاءِ پراڊڪٽ ڊولپمينٽ ۾ حصو وٺڻ لاءِ. SMB رينجر فارميٽ به اهو فرض نٿو ڪري. ڪارپوريٽ پارٽي کان واضح گهرجن جي صورت ۾ تبديلي جي درخواست جي بدران، هتي صرف عام راء ۽ خدمت جي خواهش آهي. اسان ٻڌڻ جي ڪوشش ڪريون ٿا، پر پراڊڪٽ تمام وڏو آهي ۽ هڪ گراهڪ جي پنهنجي پراڻي تاريخي نظام مان ڪا واقفيت آڻڻ جي خواهش پوري نظام جي ترقي واري حڪمت عملي جي خلاف ٿي سگهي ٿي.

جو ذريعو: www.habr.com

تبصرو شامل ڪريو