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

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

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

विचारों

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

5 स्रोत हैं:

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

अपीलों का वर्गीकरण

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

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

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

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

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

अनुरोध प्रसंस्करण बदलें

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

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

उत्पाद प्रबंधन

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

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

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

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

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

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

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

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

DevOps

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

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

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

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