پدې مقاله کې، زه به د خپلو محصولاتو د فعالیت د پراختیا لپاره د نظریاتو په ټاکلو کې خپله تجربه شریکه کړم او تاسو ته به ووایم چې څنګه د پراختیا اصلي ویکتورونه ساتل کیږي.
موږ د تصفیې یو اتومات سیسټم (ACP) - بلینګ ته وده ورکوو. اصطلاح
زموږ د محصول ژوند 14 کاله دی. د دې وخت په جریان کې، سیسټم د صنعتي تعرفو سیسټم له لومړیو نسخو څخه یو ماډلر کمپلیکس ته وده کړې چې د 18 محصولاتو څخه جوړه ده چې یو بل بشپړوي. د برنامو لپاره د اوږد عمر یو له خورا مهم اړخونو څخه دوامداره پرمختګ دی. او پرمختګ فکرونو ته اړتیا لري.
نظرونه
سرچینې
دلته 5 سرچینې شتون لري:
- د کارپوریټ معلوماتو سیسټمونو پراختیا کونکي اصلي ملګری دی پیرودونکی. او پیرودونکی د تصمیم نیونکو، د پروژې سپانسرانو، مالکینو او د پروسو اجرا کونکو، په کور کې د معلوماتي ټکنالوجۍ متخصصینو، عادي کاروونکو او په مختلفو درجو کې د ډیرو لیوالتیا اشخاصو ډله ایز انځور دی. دا زموږ لپاره مهمه ده چې د پیرودونکي هر استازی په احتمالي توګه د نظرونو عرضه کونکی وي. په بدترین حالت کې، موږ یوازې په سیسټم کې د ستونزو په اړه منفي نظرونه ترلاسه کوو. په غوره حالت کې، د پیرودونکي اړخ کې یو کس شتون لري چې د پرمختګ لپاره د نظرونو دوامداره سرچینه ده، د پیرودونکي اړتیاو په اړه منظم معلومات چمتو کوي.
- زموږ پلورونکي او د حساب مدیران د پرمختګ لپاره د نظرونو دوهمه مهمه سرچینه ده. دوی په فعاله او پراخه توګه د صنعت استازو سره اړیکه نیسي او د احتمالي پیرودونکو څخه د بلینګ فعالیت په اړه د لومړي لاس پوښتنې ترلاسه کوي. پلورونکي او حسابونه باید د دوی په فعالیت کې د ټولو پام وړ بدلونونو او د سیالانو سافټویر ته وروستي تازه معلوماتو څخه خبر وي ، او د دې وړتیا ولري چې د مختلف حلونو ګټې او زیانونه توجیه کړي. دا زموږ کارمندان دي چې لومړی یې احساس کوي که چیرې د بل کولو ځینې وړتیاوې په حقیقت کې معیاري شي، پرته له دې چې سافټویر بشپړ نه ګڼل کیږي.
- د محصول مالک - زموږ یو له لوړ پوړو مدیرانو یا خورا تجربه لرونکي پروژې مدیر. د شرکت ستراتیژیک اهداف په ذهن کې ساتي او د دوی سره سم د محصول پراختیا پلانونه تنظیموي.
- معمار، یو څوک چې د غوره شوي / کارول شوي ټیکنالوژۍ حلونو وړتیاوې او محدودیتونه درک کوي او د محصول پراختیا باندې د دوی اغیزې.
د پراختیا او ازموینې ټیمونه. هغه خلک چې په مستقیم ډول د محصول په پراختیا کې ښکیل دي.
د غوښتنو طبقه بندي
موږ د سرچینو څخه خام معلومات ترلاسه کوو - لیکونه، ټکټونه، لفظي غوښتنې. ټول
اپیلونه طبقه بندي شوي دي:
- مشوره د معنی سره "دا څنګه وکړو؟"، "دا څنګه کار کوي؟"، "ولې دا کار نه کوي؟"، "زه نه پوهیږم ...". د دې ډول غوښتنې کچې 1 ملاتړ کرښې ته ځي. دا ممکنه ده چې مشوره د نورو ډولونو غوښتنو ته وروزل شي.
- پیښې د "کار نه کوي" او "غلطۍ" معنی سره. د 2 او 3 ملاتړ لینونو لخوا پروسس شوی. که سمدستي اصالحات او د پیچ خوشې کول اړین وي، دوی د ملاتړ څخه مستقیم پراختیا ته لیږدول کیدی شي. دا ممکنه ده چې دا د بدلون غوښتنې په توګه بیا طبقه بندي کړئ او بیکلاګ ته یې واستوئ.
- د بدلون او پرمختګ غوښتنه. دوی د ملاتړ لینونو په تیریدو سره د محصول بیکلاګ ته ننوځي. مګر د دوی لپاره جلا پروسس کړنلاره شتون لري.
د غوښتنو په اړه احصایې شتون لري: د خوشې کیدو سمدستي وروسته، د لنډ وخت لپاره د غوښتنو شمیر 10-15٪ زیاتیږي. په غوښتنو کې زیاتوالی هم شتون لري کله چې یو نوی پیرودونکي د لوی شمیر کاروونکو سره زموږ کلاوډ خدماتو ته راځي. خلک د نوي سافټویر وړتیاو کارولو زده کوي، دوی مشورې ته اړتیا لري. حتی یو کوچنی پیرودونکی، کله چې په سیسټم کې کار پیل کوي، په هره میاشت کې د 100 ساعتونو څخه زیات مشورې په اسانۍ سره سوځوي. له همدې امله، کله چې د نوي پیرودونکي سره نښلول، موږ تل د لومړنیو مشورو لپاره وخت خوندي کوو. ډیری وختونه موږ حتی یو ځانګړی متخصص غوره کوو. د کرایې نرخ، البته، د دې کار لګښتونه نه پوښي، مګر د وخت په تیریدو سره وضعیت همغږي کیږي. د موافقت موده معمولا له 1 څخه تر 3 میاشتو پورې وخت نیسي، وروسته له دې چې د مشورې اړتیا د پام وړ کمه شوې.
مخکې، موږ د غوښتنو ذخیره کولو لپاره پخپله لیکل شوي حلونه کارول. مګر موږ په تدریجي ډول د اتلسیا محصولاتو ته مخه کړه. لومړی، موږ پراختیا لیږدوله ترڅو د Agile سره سم کار کول اسانه کړو، بیا ملاتړ. اوس ټولې مهمې پروسې په جیرا SD کې ژوند کوي ، سربیره پردې دوی د جیرا ، پلس کنفلونس لپاره د مختلف پلگ انونو لخوا ملاتړ کیږي. پخپله لیکل شوي حلونه یوازې د پروسو لپاره پاتې دي چې د شرکت فعالیتونو لپاره مهم ندي. دا معلومه شوه چې زموږ دندې اوس کراس پرې کیږي او د ملاتړ او پراختیا ترمینځ لیږدول کیدی شي پرته لدې چې له یو سیسټم څخه بل ته کود شي.
د دې لینک څخه موږ کولی شو د ټولو دندو، پلان شوي او حقیقي کار لګښتونو ډاټا ترلاسه کړو، د پیرودونکو لپاره د قیمت مختلف انتخابونه وکاروو او د داخلي اړتیاوو لپاره اسناد چمتو کړو او پیرودونکو ته راپور ورکړو.
د بدلون غوښتنې پروسس کول
عموما، دا ډول غوښتنې د فعالیت اړتیاو په بڼه راځي. زموږ شنونکی غوښتنه مطالعه کوي، یو مشخصات او د لوړې کچې تخنیکي مشخصات رامینځته کوي. مشخصات او تخنیکي مشخصات هغه کس ته لیږدوي چې دا غوښتنه یې د تصویب لپاره وړاندې کړې - موږ باید ډاډه شو چې موږ د پیرودونکي سره ورته ژبه خبرې کوو.
د پیرودونکي څخه تایید ترلاسه کولو سره چې موږ یو بل په سمه توګه پوهیږو، شنونکی غوښتنه د محصول بیکلاګ ته ننوځي.
د محصول فعالیت مدیریت
بیکلاګ د بدلون او پراختیا لپاره راتلونکي غوښتنې راټولوي. تخنیکي شورا چې د رییسانو، د ملاتړ، پراختیا، پلور او سیسټم معمارانو څخه جوړه ده، په هرو شپږو میاشتو کې غونډه کوي. د خبرو اترو په بڼه کې، شورا د بیکلاګ څخه غوښتنلیکونه تحلیل او لومړیتوب ورکوي او په راتلونکي خپرونه کې د پلي کولو لپاره د 5 پرمختیایي دندو سره موافقه کوي.
په حقیقت کې، تخنیکي شورا په غوښتنلیکونو کې څرګند شوي اړتیاو بیاکتنې سره د صنعت او بازار غوښتنو ته ځواب ووایی. هر څه چې لږ تړاو لري په شا کې پاتې کیږي او پراختیا ته نه رسیږي.
د بدلون غوښتنې او مالیې طبقه بندي
پرمختګ ګران دی. له همدې امله، موږ به سمدلاسه تاسو ته ووایو چې موږ ممکن کوم اختیارونه ولرو که چیرې د بدلون غوښتنه د پیرودونکي څخه وي نه د کارمند څخه.
موږ د بدلون غوښتنې په لاندې ډول طبقه بندي کوو: د صنعت اړتیا یا د تصدۍ انفرادي ځانګړتیا؛ د پام وړ اندازه د نوي فعالیت یا یو کوچني اصلاح. کوچني اصلاحات او انفرادي غوښتنې پرته له کوم ځنډ پرته پروسس کیږي. انفرادي غوښتنې د هغه سره د پروژې کار د یوې برخې په توګه د ځانګړي پیرودونکي لپاره محاسبه کیږي او پلي کیږي.
که دا د لوی صنعت اړتیا نه وي او د فعالیت حجم لوی وي ، نو بیا د نوي جلا ماډل رامینځته کولو لپاره پریکړه کیدی شي چې د اصلي فعالیت سربیره به وپلورل شي. که چیرې دا ډول غوښتنه د پیرودونکي څخه ترلاسه شي ، موږ کولی شو د ماډل رامینځته کولو لګښتونه پوښو ، پیرودونکي ته ماډل وړیا یا جزوي تادیه چمتو کړو ، او ماډل پخپله د پلور لپاره وسپارو. په داسې حالت کې، پیرودونکي د میتودولوژیکي بار یوه برخه اخلي او په اصل کې په خپل ځان د ماډل پیلوټ پلي کول ترسره کوي.
که دا د لوی صنعت اړتیا وي، نو بیا پریکړه کیدی شي چې په اساس محصول کې نوي فعالیت شامل کړي. پدې حالت کې لګښتونه په بشپړ ډول زموږ په غاړه دي، او نوي فعالیت د برنامو په اوسني نسخه کې ښکاري.
زاړه پیرودونکي د تازه معلوماتو سره چمتو شوي.
دا هم کیدی شي چې ډیری پیرودونکي ورته اړتیا ولري، مګر دا د ډله ایز محصول لپاره وړ نه وي. پدې حالت کې ، موږ کولی شو دې پیرودونکو ته توضیحات واستوو او د دوی ترمینځ پراختیایی لګښتونو ویشلو وړاندیز وکړو. په پای کې، هرڅوک وګټي: پیرودونکي په ټیټ لګښت کې فعالیت ترلاسه کوي، موږ محصول بډایه کوو، او یو څه وخت وروسته، د بازار نور ګډون کونکي هم کولی شي د دوی کارولو لپاره فعالیت ترلاسه کړي.
DevOps
پراختیا په کال کې دوه لوی ریلیزونه چمتو کوي. په هره خپرونه کې، د تخنیکي شورا څخه ترلاسه شوي د 5 دندو پلي کولو لپاره وخت ځانګړی شوی. پدې توګه ، د معمول په مینځ کې ، موږ هیڅکله د محصول پراختیا په اړه هیر نکړو.
هر ریلیز د ازموینې او اسنادو مناسب سیټ څخه تیریږي. بیا ، دا خوشې کول د اړوند پیرودونکي ازموینې چاپیریال کې نصب شوی ، څوک چې په پایله کې هرڅه په دقت سره ګوري او یوازې له هغې وروسته خوشې کول تولید ته لیږدول کیږي.
د خوشې کولو سیسټم سربیره، د چټک بګ فکسونو لپاره بڼه شتون لري ترڅو پیرودونکي د شپږو میاشتو لپاره د غلطیو سره ژوند ونه کړي. دا منځمهاله بڼه به تاسو ته اجازه درکړي چې ژر تر ژره د لومړي لومړیتوب پیښو ته ځواب ووایي او بیان شوي SLAs پوره کړي.
پورتني ټول په ابتدايي توګه د کارپوریټ سکټور او پر بنسټ حلونو لپاره ریښتیا دي. د بادل خدماتو لپاره چې هدف یې د SMB برخې دي، د پیرودونکو لپاره د محصول پراختیا کې د ګډون لپاره دومره پراخه فرصتونه شتون نلري. د SMB کرایه کولو بڼه حتی دا فرض نه کوي. د کارپوریټ ګوند څخه د روښانه غوښتنو په بڼه د بدلون غوښتنې پرځای، دلته یوازې عادي نظرونه او د خدمت لپاره هیلې شتون لري. موږ هڅه کوو چې واورو، مګر محصول خورا لوی دی او د یو پیرودونکي هیله چې د دوی د زاړه تاریخي سیسټم څخه یو څه پیژندل کیدی شي د سیسټم پراختیایي ستراتیژۍ سره په بشپړ ډول مخالفت وکړي.
سرچینه: www.habr.com