हामी कसरी हाम्रा उत्पादनहरूको विकासको लागि विचारहरू छनौट गर्छौं: विक्रेता सुन्न सक्षम हुनुपर्दछ ...

यस लेखमा, म हाम्रा उत्पादनहरूको कार्यक्षमता विकास गर्नका लागि विचारहरू छनौट गर्ने मेरो अनुभव साझा गर्नेछु र विकासका मुख्य भेक्टरहरूलाई कसरी कायम राख्ने भनेर तपाईंलाई बताउनेछु।

हामी एक स्वचालित सेटलमेन्ट प्रणाली (ACP) - बिलिङ विकास गर्दैछौं। अवधि
हाम्रो उत्पादन को जीवन 14 वर्ष छ। यस समयमा, प्रणाली औद्योगिक ट्यारिफ प्रणालीको पहिलो संस्करणबाट एकअर्काको पूरक हुने १८ उत्पादनहरू मिलेर मोड्युलर कम्प्लेक्समा विकसित भएको छ। कार्यक्रमहरूको लागि दीर्घायुको सबैभन्दा महत्त्वपूर्ण पक्षहरू मध्ये एक निरन्तर विकास हो। र विकासका लागि विचार चाहिन्छ।

विचारहरू

स्रोतहरू

त्यहाँ 5 स्रोतहरू छन्:

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

अनुरोधहरूको वर्गीकरण

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

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

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

पहिले, हामीले अनुरोधहरू भण्डारण गर्न स्व-लिखित समाधानहरू प्रयोग गर्यौं। तर हामीले बिस्तारै एटलासियन उत्पादनहरूमा स्विच गर्यौं। पहिले, हामीले Agile अनुसार काम गर्न सजिलो बनाउन विकास हस्तान्तरण गर्यौं, त्यसपछि समर्थन। अब सबै महत्वपूर्ण प्रक्रियाहरू Jira SD मा रहन्छन्, साथै तिनीहरू Jira को लागि विभिन्न प्लगइनहरू, र Confluence द्वारा समर्थित छन्। स्वयं-लिखित समाधानहरू प्रक्रियाहरूको लागि मात्र रह्यो जुन कम्पनीको गतिविधिहरूको लागि महत्वपूर्ण थिएन। यसले हाम्रो कार्यहरू अब क्रस-कटिङ भइरहेका छन् र एक प्रणालीबाट अर्को प्रणालीमा हामफाल नगरी समर्थन र विकासको बीचमा स्थानान्तरण गर्न सकिन्छ भन्ने कुरा पत्ता लाग्यो।

यस लिङ्कबाट हामी सबै कार्यहरू, योजनाबद्ध र वास्तविक श्रम लागतहरूमा डेटा प्राप्त गर्न सक्छौं, ग्राहकहरूको लागि विभिन्न मूल्य निर्धारण विकल्पहरू प्रयोग गर्न र आन्तरिक आवश्यकताहरूको लागि कागजातहरू उत्पन्न गर्न र ग्राहकहरूलाई रिपोर्टिङ गर्न सक्छौं।

परिवर्तन अनुरोधहरू प्रशोधन गर्दै

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

हामीले एकअर्कालाई सही रूपमा बुझेका छौं भनेर ग्राहकबाट पुष्टिकरण प्राप्त गरेपछि, विश्लेषकले उत्पादन ब्याकलगमा अनुरोध प्रविष्ट गर्दछ।

उत्पादन कार्यक्षमता व्यवस्थापन

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

प्रभावमा, प्राविधिक परिषदले अनुप्रयोगहरूमा व्यक्त गरिएका आवश्यकताहरूको समीक्षा गरेर उद्योग र बजार मागहरूको जवाफ दिन्छ। थोरै सान्दर्भिक सबै कुरा ब्याकलगमा रहन्छ र विकासमा पुग्न सक्दैन।

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

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

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

यदि यो ठूलो उद्योगको आवश्यकता होइन र कार्यक्षमताको मात्रा ठूलो छ भने, मुख्य कार्यक्षमताको अतिरिक्त बेचिने नयाँ छुट्टै मोड्युल विकास गर्ने निर्णय गर्न सकिन्छ। यदि ग्राहकबाट यस्तो अनुरोध प्राप्त भयो भने, हामी मोड्युल विकासको लागतहरू कभर गर्न सक्छौं, ग्राहकलाई मोड्युल निःशुल्क वा आंशिक भुक्तानीको साथ प्रदान गर्न सक्छौं, र मोड्युल आफैं बिक्रीको लागि राख्न सक्छौं। यस्तो अवस्थामा, ग्राहकले पद्धतिगत भारको अंश लिन्छ र अनिवार्य रूपमा आफैंमा मोड्युलको पायलट कार्यान्वयन सञ्चालन गर्दछ।

यदि यो ठूलो उद्योगको आवश्यकता हो भने, आधार उत्पादनमा नयाँ कार्यक्षमता समावेश गर्ने निर्णय गर्न सकिन्छ। यस मामला मा लागत हामी मा पूरै गिर, र नयाँ कार्यक्षमता कार्यक्रम को हालको संस्करण मा देखिन्छ।
पुराना ग्राहकहरूलाई अपडेट प्रदान गरिएको छ।

यो पनि हुन सक्छ कि धेरै ग्राहकहरु लाई समान आवश्यकता छ, तर यो ठूलो उत्पादन को लागी योग्य छैन। यस अवस्थामा, हामी यी ग्राहकहरूलाई स्पेसिफिकेशन पठाउन सक्छौं र तिनीहरू बीचको विकास लागतहरू विभाजन गर्न प्रस्ताव गर्न सक्छौं। अन्तमा, सबैले जित्छन्: ग्राहकहरूले कम लागतमा कार्यक्षमता प्राप्त गर्छन्, हामी उत्पादनलाई समृद्ध बनाउँछौं, र केहि समय पछि, अन्य बजार सहभागीहरूले पनि उनीहरूको प्रयोगको लागि कार्यक्षमता प्राप्त गर्न सक्छन्।

DevOps

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

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

रिलिज प्रणालीको अतिरिक्त, त्यहाँ द्रुत बग फिक्सहरूको लागि ढाँचा छ ताकि ग्राहकहरू छ महिनासम्म त्रुटिहरूसँग बाँच्न नपरोस्। यो मध्यवर्ती ढाँचाले तपाईंलाई पहिलो प्राथमिकताका घटनाहरूमा छिटो प्रतिक्रिया दिन र बताएको SLA हरू पूरा गर्न अनुमति दिनेछ।

माथिका सबै मुख्य रूपमा कर्पोरेट क्षेत्र र अन-प्रिमाइस समाधानहरूको लागि सत्य हो। SMB खण्डमा लक्षित क्लाउड सेवाहरूका लागि, उत्पादन विकासमा सहभागी हुने ग्राहकहरूको लागि कुनै त्यस्तो व्यापक अवसरहरू छैनन्। SMB भाडा ढाँचाले यसलाई मान्दैन। कर्पोरेट पार्टीबाट स्पष्ट आवश्यकताहरूको रूपमा परिवर्तन अनुरोधको सट्टा, यहाँ सेवाको लागि सामान्य प्रतिक्रिया र इच्छाहरू मात्र छन्। हामी सुन्न कोसिस गर्छौं, तर उत्पादन ठूलो छ र एक ग्राहकको पुरानो ऐतिहासिक प्रणालीबाट परिचित केहि ल्याउने इच्छाले समग्र प्रणालीको विकास रणनीतिको विरोधाभास हुन सक्छ।

स्रोत: www.habr.com