🥇 हम अपने उत्पादों के विकास के लिए विचारों का चयन कैसे करते हैं: एक विक्रेता को सुनने में सक्षम होना चाहिए...

इस लेख में, मैं हमारे उत्पादों की कार्यक्षमता के विकास के लिए विचारों के चयन में अपने अनुभव को साझा करूँगा और आपको बताऊंगा कि मुख्य विकास वैक्टर को कैसे रखा जाए।

हम एक स्वचालित निपटान प्रणाली (ACS) - बिलिंग विकसित कर रहे हैं। अवधि
हमारे उत्पाद का जीवन 14 वर्ष है। इस समय के दौरान, सिस्टम एक औद्योगिक रैटर के पहले संस्करणों से एक मॉड्यूलर कॉम्प्लेक्स में चला गया है जिसमें 18 उत्पाद शामिल हैं जो एक दूसरे के पूरक हैं। कार्यक्रमों के लिए दीर्घायु के सबसे महत्वपूर्ण पहलुओं में से एक निरंतर विकास है। और विकास के लिए विचारों की जरूरत होती है।

विचारों

सूत्रों का कहना है

5 स्रोत हैं:

कॉर्पोरेट सूचना प्रणाली के विकासकर्ता का मुख्य मित्र है ग्राहक. और ग्राहक निर्णय निर्माताओं, परियोजना प्रायोजकों, प्रक्रियाओं के मालिकों और निष्पादकों, इन-हाउस आईटी विशेषज्ञों, सामान्य उपयोगकर्ताओं और बड़ी संख्या में ऐसे लोगों की एक सामूहिक छवि है जो अलग-अलग डिग्री में रुचि रखते हैं। हमारे लिए यह महत्वपूर्ण है कि क्लाइंट का प्रत्येक प्रतिनिधि संभावित रूप से विचारों का आपूर्तिकर्ता हो। सबसे खराब स्थिति में, हमें सिस्टम में समस्याओं के बारे में केवल नकारात्मक प्रतिक्रिया मिलती है। अधिक से अधिक, ग्राहक पक्ष में एक व्यक्ति होता है जो सुधार के लिए विचारों का एक निरंतर स्रोत होता है, जो ग्राहक की आवश्यकताओं के बारे में संरचित जानकारी प्रदान करता है।
हमारे विक्रेता और खाता प्रबंधक सुधार के लिए विचारों का दूसरा सबसे महत्वपूर्ण स्रोत हैं। वे उद्योग के प्रतिनिधियों के साथ बहुत सक्रिय रूप से संवाद करते हैं, संभावित ग्राहकों से बिलिंग कार्यक्षमता के लिए प्रथम-हाथ अनुरोध प्राप्त करते हैं। व्यापारियों और खातों को उनकी कार्यक्षमता में सभी महत्वपूर्ण परिवर्तनों और प्रतिस्पर्धियों के नवीनतम सॉफ़्टवेयर अपडेट के बारे में पता होना चाहिए, विभिन्न समाधानों के पेशेवरों और विपक्षों को सही ठहराने में सक्षम होना चाहिए। यह हमारे कर्मचारी हैं जो सबसे पहले महसूस करते हैं कि कुछ बिलिंग सुविधाएँ वास्तविक मानक बन जाती हैं, जिसके बिना सॉफ़्टवेयर को पूर्ण नहीं माना जा सकता है।
उत्पाद स्वामी हमारे शीर्ष प्रबंधकों में से एक या बहुत अनुभवी परियोजना प्रबंधक हैं। कंपनी के रणनीतिक लक्ष्यों को ध्यान में रखता है और उनके अनुसार उत्पाद विकास योजनाओं को समायोजित करता है।
वास्तुकार, एक व्यक्ति जो चयनित/उपयोग किए गए तकनीकी समाधानों की संभावनाओं और सीमाओं और उत्पाद विकास पर उनके प्रभाव को समझता है।
विकास और परीक्षण दल। जो लोग सीधे उत्पाद विकास में शामिल हैं।

हिट्स का वर्गीकरण

हम स्रोतों से कच्चा डेटा प्राप्त करते हैं - पत्र, टिकट, मौखिक अनुरोध। सभी
अपील वर्गीकृत हैं:

परामर्श अर्थ के साथ "यह कैसे करें?", "यह कैसे काम करता है?", "यह काम क्यों नहीं करता?", "मुझे समझ नहीं आता ..."। इस प्रकार की कॉल लेवल 1 सपोर्ट लाइन पर जाती हैं। अन्य प्रकार की अपीलों में परामर्श को फिर से प्रशिक्षित करना संभव है।
घटनाएं अर्थ "काम नहीं कर रहा" और "त्रुटि" के साथ। 2 और 3 समर्थन लाइनों द्वारा नियंत्रित। यदि किसी पैच को जल्दी से ठीक करना और जारी करना आवश्यक है, तो इसे समर्थन से सीधे विकास में स्थानांतरित किया जा सकता है। इसे परिवर्तन अनुरोध में पुनर्वर्गीकृत करना और इसे बैकलॉग में भेजना संभव है।
परिवर्तन और विकास के लिए अनुरोध. सपोर्ट लाइन्स को दरकिनार करते हुए उत्पाद बैकलॉग में प्रवेश करें। लेकिन उनके लिए एक अलग प्रसंस्करण प्रक्रिया है।

हिट पर ऐसे आंकड़े हैं - रिलीज के तुरंत बाद हिट की संख्या थोड़े समय के लिए 10-15% बढ़ जाती है। जब हमारी क्लाउड सेवाओं में बड़ी संख्या में उपयोगकर्ताओं के साथ एक नया ग्राहक आता है तो कॉल की बौछार भी होती है। लोग नई सॉफ्टवेयर सुविधाओं का उपयोग करना सीख रहे हैं, उन्हें सलाह की जरूरत है। यहां तक कि एक छोटा ग्राहक, जब सिस्टम में काम करना शुरू करता है, आसानी से प्रति माह 100 घंटे से अधिक परामर्श खर्च करता है। इसलिए, किसी नए क्लाइंट को कनेक्ट करते समय, हम हमेशा प्रारंभिक परामर्श के लिए समय आरक्षित रखते हैं। अक्सर हम एक विशिष्ट विशेषज्ञ को भी बाहर कर देते हैं। किराए की लागत, बेशक, इन श्रम लागतों का भुगतान नहीं करती है, लेकिन समय के साथ स्थिति का स्तर कम हो जाता है। अनुकूलन की अवधि, एक नियम के रूप में, 1 से 3 महीने तक होती है, जिसके बाद परामर्श की आवश्यकता काफी कम हो जाती है।

पहले, हम कॉल स्टोर करने के लिए स्व-लिखित समाधान का उपयोग करते थे। लेकिन धीरे-धीरे एटलसियन उत्पादों पर स्विच किया गया। सबसे पहले, एजाइल पर काम करना आसान बनाने के लिए विकास को स्थानांतरित किया गया, फिर समर्थन। अब सभी महत्वपूर्ण प्रक्रियाएं जीरा एसडी में रहती हैं, साथ ही उन्हें जीरा, प्लस कॉन्फ्लुएंस के लिए विभिन्न प्लगइन्स प्रदान किए जाते हैं। कंपनी की गतिविधियों के लिए गैर-महत्वपूर्ण प्रक्रियाओं पर ही स्व-लिखित समाधान बने रहे। यह पता चला कि हमारे कार्य अब एंड-टू-एंड हैं, उन्हें एक सिस्टम से दूसरे सिस्टम में कूदे बिना समर्थन और विकास के बीच स्थानांतरित किया जा सकता है।

इस बंडल से, हम सभी कार्यों, नियोजित और वास्तविक श्रम लागतों पर डेटा प्राप्त कर सकते हैं, ग्राहकों के लिए विभिन्न बिलिंग विकल्पों का उपयोग कर सकते हैं और आंतरिक जरूरतों के लिए दस्तावेज तैयार कर सकते हैं और ग्राहकों को एक रिपोर्ट दे सकते हैं।

प्रसंस्करण परिवर्तन अनुरोध

आमतौर पर, ये अनुरोध सुविधा आवश्यकताओं के रूप में आते हैं। हमारे विश्लेषक अनुरोध का अध्ययन करते हैं, एक विनिर्देश और एक शीर्ष-स्तरीय टीओआर उत्पन्न करते हैं। विनिर्देश और टीओआर को उस व्यक्ति को स्थानांतरित करता है जिसने अनुमोदन के लिए यह अनुरोध प्रस्तुत किया है - हमें सुनिश्चित होना चाहिए कि हम ग्राहक के साथ एक ही भाषा बोलते हैं।

ग्राहक से पुष्टि प्राप्त करने के बाद कि हम एक दूसरे को सही ढंग से समझते हैं, विश्लेषक उत्पाद बैकलॉग में अनुरोध दर्ज करता है।

उत्पाद सुविधा प्रबंधन

बैकलॉग परिवर्तन और विकास के लिए प्राप्त अनुरोधों को संचित करता है। हर छह महीने में एक बार, तकनीकी परिषद, जिसमें निदेशक, रखरखाव, विकास, बिक्री और सिस्टम आर्किटेक्ट के प्रमुख शामिल होते हैं, मिलते हैं। चर्चा प्रारूप में, परिषद बैकलॉग से आवेदनों का विश्लेषण और प्राथमिकता देती है और अगली रिलीज में कार्यान्वयन के लिए 5 विकास कार्यों पर सहमत होती है।

वास्तव में, तकनीकी परिषद अनुप्रयोगों में दर्ज की गई जरूरतों पर विचार करते हुए उद्योग और बाजार की आवश्यकताओं का जवाब देती है। कम प्रासंगिकता वाली हर चीज बैकलॉग में बनी रहती है और विकास तक नहीं पहुंच पाती है।

परिवर्तन अनुरोधों और वित्त का वर्गीकरण

विकास महंगा है। इसलिए, हम आपको तुरंत बताएंगे कि हमारे पास कौन से विकल्प हो सकते हैं यदि बदलाव का अनुरोध किसी ग्राहक से आया है, न कि किसी कर्मचारी से।

परिवर्तन अनुरोधों को निम्नानुसार वर्गीकृत किया गया है: उद्योग-विशिष्ट आवश्यकताएं या उद्यम की व्यक्तिगत विशेषताएं; नई कार्यक्षमता की एक महत्वपूर्ण राशि या एक छोटा सुधार। छोटे सुधार और व्यक्तिगत अनुरोध बिना किसी तामझाम के संसाधित किए जाते हैं। व्यक्तिगत अनुरोधों की गणना और उनके साथ परियोजना कार्य के हिस्से के रूप में एक विशिष्ट ग्राहक के लिए कार्यान्वित की जाती है।

यदि यह बड़े पैमाने पर उद्योग की आवश्यकता नहीं है और कार्यक्षमता की मात्रा बड़ी है, तो एक नया अलग मॉड्यूल विकसित करने का निर्णय लिया जा सकता है जिसे मुख्य कार्यक्षमता के अतिरिक्त बेचा जाएगा। यदि क्लाइंट से ऐसा अनुरोध प्राप्त होता है, तो हम मॉड्यूल को विकसित करने की लागत को कवर कर सकते हैं, क्लाइंट को मुफ्त में या आंशिक भुगतान के साथ मॉड्यूल प्रदान कर सकते हैं और मॉड्यूल को बिक्री के लिए सार्वजनिक डोमेन में रख सकते हैं। ऐसी स्थिति में, क्लाइंट पद्धति संबंधी बोझ का हिस्सा लेता है और वास्तव में, मॉड्यूल के एक पायलट कार्यान्वयन का संचालन करता है।

यदि यह एक बड़े पैमाने पर उद्योग की जरूरत है, तो आधार उत्पाद में नई कार्यक्षमता शामिल करने का निर्णय लिया जा सकता है। इस मामले में लागत पूरी तरह से हमारे द्वारा वहन की जाती है, और कार्यक्रमों के वर्तमान संस्करण में नई कार्यक्षमता दिखाई देती है।
पुराने ग्राहकों को एक अद्यतन प्रदान किया जाता है।

यह भी हो सकता है कि कई ग्राहकों की समान आवश्यकता हो, लेकिन यह बड़े पैमाने पर उत्पाद को नहीं खींचता है। इस मामले में, हम इन ग्राहकों को विनिर्देश भेज सकते हैं और उनके बीच विकास लागत साझा करने की पेशकश कर सकते हैं। अंत में, हर कोई जीतता है: ग्राहकों को कम लागत पर कार्यक्षमता का कार्यान्वयन मिलता है, हम उत्पाद को समृद्ध करते हैं, थोड़ी देर बाद अन्य बाजार सहभागियों को भी उनके उपयोग के लिए कार्यक्षमता मिल सकती है।

DevOps

विकास प्रति वर्ष दो प्रमुख रिलीज तैयार करता है। प्रत्येक रिलीज में तकनीकी परिषद से प्राप्त 5 कार्यों के कार्यान्वयन के लिए समय आरक्षित है। इस प्रकार, टर्नओवर के पीछे, हम उत्पाद के विकास के बारे में कभी नहीं भूलते।

प्रत्येक रिलीज परीक्षण और दस्तावेज़ीकरण के उपयुक्त सेट के माध्यम से जाती है। इसके अलावा, यह रिलीज़ संबंधित ग्राहक के परीक्षण वातावरण में स्थापित किया गया है, जो बदले में, सब कुछ सावधानीपूर्वक जाँचता है, और उसके बाद ही रिलीज़ को उत्पादन में स्थानांतरित किया जाता है।

रिलीज सिस्टम के अलावा, त्वरित बग फिक्स का एक प्रारूप है ताकि ग्राहक छह महीने तक त्रुटियों के साथ न रहें। यह मध्यवर्ती प्रारूप आपको पहली प्राथमिकताओं की घटनाओं पर तुरंत प्रतिक्रिया देने और बताए गए SLA को पूरा करने की अनुमति देगा।

उपरोक्त सभी मुख्य रूप से कॉर्पोरेट क्षेत्र और ऑन-प्रिमाइसेस समाधानों के लिए सत्य हैं। एसएमबी खंड पर केंद्रित क्लाउड सेवाओं के लिए, ग्राहकों के लिए उत्पाद विकास में भाग लेने के इतने व्यापक अवसर नहीं हैं। एसएमबी के लिए पट्टे का प्रारूप भी इसका सुझाव नहीं देता है। कॉर्पोरेट पार्टी से स्पष्ट आवश्यकताओं के रूप में परिवर्तन अनुरोध के बजाय, सेवा के लिए केवल सामान्य प्रतिक्रिया और इच्छाएँ होती हैं। हम सुनने की कोशिश करते हैं, लेकिन उत्पाद बड़े पैमाने पर है और एक ग्राहक की अपनी पुरानी ऐतिहासिक प्रणाली से परिचित कुछ लाने की इच्छा पूरे सिस्टम की विकास रणनीति का खंडन कर सकती है।

स्रोत: www.habr.com

हम अपने उत्पादों के विकास के लिए विचारों का चयन कैसे करते हैं: विक्रेता को सुनने में सक्षम होना चाहिए...

एक टिप्पणी जोड़ें उत्तर रद्द