आम्ही आमच्या उत्पादनांच्या विकासासाठी कल्पना कशा निवडतो: विक्रेता ऐकण्यास सक्षम असणे आवश्यक आहे…

या लेखात, मी आमच्या उत्पादनांची कार्यक्षमता विकसित करण्यासाठी कल्पना निवडण्याचा माझा अनुभव सामायिक करेन आणि विकासाचे मुख्य वेक्टर कसे राखायचे ते सांगेन.

आम्ही स्वयंचलित सेटलमेंट सिस्टम (ACP) - बिलिंग विकसित करत आहोत. मुदत
आमच्या उत्पादनाचे आयुष्य 14 वर्षे आहे. या काळात, प्रणाली औद्योगिक दर प्रणालीच्या पहिल्या आवृत्त्यांपासून एकमेकांना पूरक असलेल्या 18 उत्पादनांचा समावेश असलेल्या मॉड्यूलर कॉम्प्लेक्समध्ये विकसित झाली आहे. कार्यक्रमांसाठी दीर्घायुष्याची सर्वात महत्वाची बाब म्हणजे सतत विकास. आणि विकासासाठी विचारांची गरज असते.

कल्पना

स्त्रोत

5 स्त्रोत आहेत:

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

विनंत्यांचे वर्गीकरण

आम्हाला स्त्रोतांकडून कच्चा डेटा प्राप्त होतो - पत्रे, तिकिटे, तोंडी विनंत्या. सर्व
अपील वर्गीकृत आहेत:

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

विनंत्यांची आकडेवारी आहे: रिलीझ झाल्यानंतर लगेच, थोड्या काळासाठी विनंत्यांची संख्या 10-15% वाढते. जेव्हा मोठ्या संख्येने वापरकर्ते असलेला नवीन क्लायंट आमच्या क्लाउड सेवांवर येतो तेव्हा विनंत्यांमध्ये वाढ होते. लोक नवीन सॉफ्टवेअर क्षमता वापरण्यास शिकत आहेत, त्यांना सल्ला आवश्यक आहे. अगदी लहान क्लायंट, जेव्हा सिस्टममध्ये काम करण्यास प्रारंभ करतो तेव्हा दरमहा 100 तासांपेक्षा जास्त सल्लामसलत सहजपणे बर्न करतो. म्हणून, नवीन क्लायंट कनेक्ट करताना, आम्ही नेहमी प्रारंभिक सल्लामसलत करण्यासाठी वेळ राखून ठेवतो. अनेकदा आम्ही विशिष्ट तज्ञ देखील निवडतो. भाड्याची किंमत, अर्थातच, या श्रमिक खर्चांना कव्हर करत नाही, परंतु कालांतराने परिस्थिती आणखी एकसारखी होते. अनुकूलन कालावधी सहसा 1 ते 3 महिन्यांपर्यंत लागतो, त्यानंतर समुपदेशनाची आवश्यकता लक्षणीयरीत्या कमी होते.

पूर्वी, आम्ही विनंत्या संचयित करण्यासाठी स्वयं-लिखित उपाय वापरत होतो. पण आम्ही हळूहळू ॲटलासियन उत्पादनांकडे वळलो. प्रथम, आम्ही चपळतेनुसार कार्य करणे सोपे करण्यासाठी विकास हस्तांतरित केला, नंतर समर्थन. आता सर्व गंभीर प्रक्रिया जिरा एसडीमध्ये राहतात, तसेच त्यांना जिरा, तसेच कॉन्फ्लुएंससाठी विविध प्लगइन्सद्वारे समर्थन दिले जाते. कंपनीच्या क्रियाकलापांसाठी गंभीर नसलेल्या प्रक्रियांसाठीच स्वयं-लिखित उपाय राहिले. हे निष्पन्न झाले की आमची कार्ये आता क्रॉस-कटिंग आहेत आणि एका सिस्टममधून दुसऱ्या प्रणालीवर न जाता समर्थन आणि विकास दरम्यान हस्तांतरित केली जाऊ शकतात.

या लिंकवरून आम्ही सर्व कामांचा डेटा, नियोजित आणि प्रत्यक्ष श्रम खर्च, ग्राहकांसाठी विविध किंमती पर्याय वापरू शकतो आणि अंतर्गत गरजांसाठी दस्तऐवज तयार करू शकतो आणि ग्राहकांना अहवाल देऊ शकतो.

बदल विनंत्यांवर प्रक्रिया करत आहे

सामान्यतः, अशा विनंत्या कार्यक्षमता आवश्यकतांच्या स्वरूपात येतात. आमचे विश्लेषक विनंतीचा अभ्यास करतात, एक तपशील आणि उच्च-स्तरीय तांत्रिक वैशिष्ट्ये तयार करतात. ज्या व्यक्तीने मंजूरीसाठी ही विनंती सबमिट केली आहे त्या व्यक्तीकडे तपशील आणि तांत्रिक वैशिष्ट्ये हस्तांतरित करते - आम्हाला खात्री असणे आवश्यक आहे की आम्ही ग्राहकाशी समान भाषा बोलतो.

आम्ही एकमेकांना योग्यरित्या समजून घेतल्याचे ग्राहकाकडून पुष्टीकरण मिळाल्यानंतर, विश्लेषक उत्पादनाच्या अनुशेषामध्ये विनंती प्रविष्ट करतो.

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

अनुशेष बदल आणि विकासासाठी येणाऱ्या विनंत्या जमा करतो. संचालक, सहाय्य, विकास, विक्री प्रमुख आणि सिस्टम आर्किटेक्ट यांचा समावेश असलेली तांत्रिक परिषद दर सहा महिन्यांनी भेटते. चर्चेच्या स्वरूपात, परिषद अनुशेषातील अर्जांचे विश्लेषण करते आणि प्राधान्य देते आणि पुढील प्रकाशनात अंमलबजावणीसाठी 5 विकास कार्यांवर सहमत होते.

प्रत्यक्षात, तांत्रिक परिषद अनुप्रयोगांमध्ये व्यक्त केलेल्या गरजांचे पुनरावलोकन करून उद्योग आणि बाजाराच्या मागणीला प्रतिसाद देते. जे काही थोडेसे प्रासंगिक आहे ते अनुशेषात राहते आणि विकासापर्यंत पोहोचत नाही.

बदल विनंत्या आणि वित्त वर्गीकरण

विकास खर्चिक आहे. म्हणून, बदलाची विनंती कर्मचाऱ्याने नव्हे तर ग्राहकाकडून आली असल्यास आमच्याकडे कोणते पर्याय असू शकतात हे आम्ही लगेच सांगू.

आम्ही खालीलप्रमाणे बदल विनंत्यांचे वर्गीकरण करतो: उद्योगाची गरज किंवा एंटरप्राइझचे वैयक्तिक वैशिष्ट्य; नवीन कार्यक्षमतेची महत्त्वपूर्ण रक्कम किंवा किरकोळ निराकरण. किरकोळ निराकरणे आणि वैयक्तिक विनंत्या कोणत्याही फ्रिलशिवाय प्रक्रिया केल्या जातात. एखाद्या विशिष्ट क्लायंटसाठी त्याच्यासोबतच्या प्रकल्पाच्या कामाचा भाग म्हणून वैयक्तिक विनंत्या मोजल्या जातात आणि अंमलात आणल्या जातात.

जर ही मोठ्या उद्योगाची गरज नसेल आणि कार्यक्षमतेचे प्रमाण मोठे असेल, तर नवीन स्वतंत्र मॉड्यूल विकसित करण्याचा निर्णय घेतला जाऊ शकतो जो मुख्य कार्यक्षमतेव्यतिरिक्त विकला जाईल. अशी विनंती एखाद्या क्लायंटकडून प्राप्त झाल्यास, आम्ही मॉड्यूल विकसित करण्यासाठी लागणारा खर्च भागवू शकतो, क्लायंटला मॉड्यूल विनामूल्य किंवा आंशिक पेमेंटसह प्रदान करू शकतो आणि मॉड्यूल स्वतःच विक्रीसाठी ठेवू शकतो. अशा परिस्थितीत, क्लायंट पद्धतशीर भाराचा एक भाग घेतो आणि मूलत: स्वतःवर मॉड्यूलची पायलट अंमलबजावणी करतो.

जर ही मोठ्या प्रमाणात उद्योगाची गरज असेल, तर मूळ उत्पादनामध्ये नवीन कार्यक्षमता समाविष्ट करण्याचा निर्णय घेतला जाऊ शकतो. या प्रकरणातील खर्च पूर्णपणे आमच्यावर पडतो आणि नवीन कार्यक्षमता प्रोग्रामच्या वर्तमान आवृत्तीमध्ये दिसून येते.
जुन्या ग्राहकांना अपडेट दिले जातात.

हे देखील असू शकते की अनेक ग्राहकांना समान गरज आहे, परंतु ते मोठ्या प्रमाणात उत्पादनासाठी पात्र नाही. या प्रकरणात, आम्ही या ग्राहकांना तपशील पाठवू शकतो आणि त्यांच्यामध्ये विकास खर्च विभाजित करण्याची ऑफर देऊ शकतो. सरतेशेवटी, प्रत्येकजण जिंकतो: ग्राहकांना कमी खर्चात कार्यक्षमता मिळते, आम्ही उत्पादन समृद्ध करतो आणि काही काळानंतर, इतर बाजारातील सहभागींना त्यांच्या वापरासाठी कार्यक्षमता देखील मिळू शकते.

DevOps

विकास वर्षातून दोन प्रमुख प्रकाशन तयार करतो. प्रत्येक प्रकाशनात, तांत्रिक परिषदेकडून प्राप्त झालेल्या 5 कार्यांच्या अंमलबजावणीसाठी वेळ राखून ठेवला आहे. अशा प्रकारे, नित्यक्रमाच्या दरम्यान, आम्ही उत्पादनाच्या विकासाबद्दल कधीही विसरत नाही.

प्रत्येक प्रकाशन चाचणी आणि दस्तऐवजीकरणाच्या योग्य संचातून जातो. पुढे, हे रिलीझ संबंधित ग्राहकाच्या चाचणी वातावरणात स्थापित केले जाते, जे यामधून, सर्वकाही काळजीपूर्वक तपासतात आणि त्यानंतरच प्रकाशन उत्पादनात हस्तांतरित केले जाते.

रिलीझ सिस्टीम व्यतिरिक्त, द्रुत दोष निराकरणासाठी एक स्वरूप आहे जेणेकरून क्लायंट सहा महिने त्रुटींसह जगू नये. हे इंटरमीडिएट फॉरमॅट तुम्हाला प्रथम-प्राधान्य घटनांना झटपट प्रतिसाद देण्यास आणि सांगितलेल्या SLAs पूर्ण करण्यास अनुमती देईल.

वरील सर्व गोष्टी प्रामुख्याने कॉर्पोरेट क्षेत्रासाठी आणि ऑन-प्रिमाइस सोल्यूशन्ससाठी खरे आहेत. SMB सेगमेंटला उद्देशून क्लाउड सेवांसाठी, ग्राहकांना उत्पादन विकासामध्ये सहभागी होण्याच्या अशा कोणत्याही व्यापक संधी नाहीत. SMB भाडे स्वरूप हे गृहीतही धरत नाही. कॉर्पोरेट पक्षाकडून स्पष्ट आवश्यकतांच्या स्वरूपात बदल विनंतीऐवजी, येथे फक्त सामान्य अभिप्राय आणि सेवेसाठी शुभेच्छा आहेत. आम्ही ऐकण्याचा प्रयत्न करतो, परंतु उत्पादन खूप मोठे आहे आणि एका क्लायंटची त्यांच्या जुन्या ऐतिहासिक प्रणालीतून काहीतरी परिचित आणण्याची इच्छा संपूर्णपणे सिस्टमच्या विकास रणनीतीला विरोध करू शकते.

स्त्रोत: www.habr.com