संस्करण 3.0: बेहतर करो

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

अस्पताल ऐप

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

क्लाइंट ने हमें निवेशकों के प्रदर्शन के लिए एप्लिकेशन के एक नए संस्करण को विकसित करने का काम दिया।

परियोजना का विवरण

ऑडियो

कैसे संस्करण 2.0 में ऑडियो रिकॉर्ड करने के लिए:

1. आवेदन खोला।
2. ऐड रिकॉर्ड बटन पर क्लिक किया।
3. दिखाई देने वाली खिड़की में, हमने रिकॉर्डिंग डिवाइस के वांछित संस्करण का चयन किया।
4. डिक्टेट की गई ऑडियो रिकॉर्डिंग।
5. रोगी संख्या, यात्रा की तारीख, यात्रा संख्या (यात्रा = डॉक्टर की नियुक्ति) दर्ज की गई थी।
6. उन्होंने ऑडियो अपलोड करने और सर्वर पर डेटा देखने के लिए पूरा बटन क्लिक किया।

अब संस्करण 3.0 में, लेखन के लिए कम प्रयास की आवश्यकता है:

1. डॉक्टर आवेदन खोलता है।
2. सूची से एक अपॉइंटमेंट (तिथि, समय, संख्या या रोगी का नाम) का चयन करता है और एक विज़िट कार्ड खोलने के लिए 1 बार क्लिक करता है।
3. रिकॉर्ड ऑडियो।
4. सर्वर पर ऑडियो भेजने के लिए पूरा बटन दबाता है।

संस्करण 3.0 में, डॉक्टर का काम जितना संभव हो उतना स्वचालित है। ऑपरेशन की संख्या कम हो गई है, जबकि कार्यक्रम खुद रोगियों के बारे में डेटा जोड़ता है।

पत्रों के साथ काम करें

पत्रों के साथ काम करना भी आसान हो गया है। संस्करण 2.0 में, उनके प्रसंस्करण के लिए एक कठिन कतार थी। डॉक्टर तुरंत पत्रों की पूरी सूची प्राप्त नहीं कर सका - केवल भागों में और एक निश्चित क्रम में। आरंभ करने के लिए, आपको यह करना होगा:

• अपने पत्रों की सूची प्राप्त करने के लिए एक क्लिक करें;
• दूसरी खिड़की पर जाएं;
• इसे खोलने के लिए पत्र पर डबल-क्लिक करें;
• सूची से पत्रों को संसाधित करने के बाद, सूची में निम्नलिखित पत्र प्राप्त करने के लिए फिर से क्लिक करें।

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

इंटरफ़ेस

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

हमारे विशेषज्ञों ने इंटरफ़ेस के साथ काम किया और ऑडियो बटन को सामने लाया ताकि उपयोगकर्ता कम से कम क्लिक में अपने कार्य को पूरा कर सकें।

अगला, हम इस बारे में विवरण देंगे कि हमने नया संस्करण कैसे विकसित किया है।

नई जरूरतें

जब एक क्लाइंट ने संस्करण 2.0 को अपग्रेड करने के लिए हमसे संपर्क किया, तो एप्लिकेशन लगभग तीन वर्षों से काम कर रहा है। यह उपयोगकर्ताओं के लिए परिचित था और इसके कुछ फायदे थे:

• जटिल व्यावसायिक तर्क प्रदर्शन के लिए कार्यों का एक सेट था, तीसरे पक्ष के सिस्टम के साथ एकीकरण;
• ग्राहक कार्यक्रम के आदी हैं और इसे छोड़ना नहीं चाहेंगे;
• तकनीकी सहायता कर्मचारी आवेदन जानते थे और जल्दी से उपयोगकर्ताओं की मदद करते थे;
• किसी भी व्यावसायिक इच्छाओं के लिए सिस्टम को कॉन्फ़िगर करने के लिए लचीली सेटिंग्स थीं;
• सिस्टम के सर्वर भागों में संभावित समस्याओं की ट्रैकिंग स्थापित की गई थी, उन्हें हल करने के लिए वर्कअराउंड ज्ञात थे।

हालांकि, जब आवेदन के संचालन का विश्लेषण करते हैं, तो हमें ऐसी समस्याएं मिलीं:

• नई सुविधाओं के विकास और परीक्षण में अधिक से अधिक समय लगा;
• नए कार्यों को जोड़ने पर, सिस्टम में त्रुटियां दिखाई दीं;
• नतीजतन, 30% तक जटिल सुधारों को बंद कर दिया गया, जिससे आवेदन को बाहर करने की धमकी दी गई। उदाहरण के लिए, अस्पतालों में, अधिक से अधिक जटिल टेम्पलेट दिखाई दिए, वर्कफ़्लो में नई भूमिकाएं जोड़ना आवश्यक था;
• एप्लिकेशन आर्किटेक्चर नए समाधानों का समर्थन नहीं कर सका;
• विकास के समय का 40% समर्थन पर खर्च किया गया था;
• डेस्कटॉप उत्पाद के नए संस्करण और अपडेट स्थापित करते समय कठिनाइयाँ थीं;
• 2000 के दशक के बोझिल इंटरफ़ेस ने नए ग्राहकों को डरा दिया;
• एक असुविधाजनक सेटिंग्स सिस्टम ने सिस्टम को जल्दी से शुरू करने से रोका, और त्रुटियों के जोखिम को भी बढ़ाया।

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

संस्करण आवश्यकताएँ

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

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

इसके अलावा, नए संस्करण को पुराने के "जटिल क्लोन" की अनुमति देना असंभव था। इसलिए, प्रमुख कार्यों को सहेजना पड़ा, लेकिन एप्लिकेशन को ओवरलोड किए बिना। हमने बेरहमी से बेमानी जटिल सेटिंग्स को छोड़ दिया।

संस्करण 2.0 के साथ काम करने वाले व्यापार विश्लेषकों ने तुरंत परिवर्तनों को स्वीकार नहीं किया। संदर्भ के संदर्भ में, वाक्यांश अक्सर पाए जाते थे: "यह यहां संस्करण 2.0 के रूप में होना चाहिए", "संस्करण 2.0 में काम करने की योजना को लें"। इस स्तर पर सबसे कठिन बात सब कुछ लेने के प्रलोभन का विरोध था, जैसा कि पिछले संस्करण में था।

प्रोजेक्ट टीम

एक नियम के रूप में, प्रत्येक परियोजना की शुरुआत में, हम SimbirSoft पर विभिन्न प्रोफाइल के विशेषज्ञों की एक टीम से जुड़ते हैं - विश्लेषक, गुणवत्ता आश्वासन विशेषज्ञ (क्यूए) और अन्य। मेडिकल एप्लिकेशन पर काम करते समय, हम निम्नलिखित टीम को एक साथ रखते हैं:

• डेवलपर्स जिन्होंने कोड 2.0 के संस्करण को अनुकूलित और अनुकूलित लिखा;
• गुणवत्ता आश्वासन विशेषज्ञ (QA)। वे, डेवलपर्स के साथ मिलकर, विरासत कोड, वास्तु समाधान और संस्करण 2.0 की त्रुटियों से परिचित थे, और नए कार्यों का परीक्षण भी किया;
• टेस्ट ऑटोमेशन इंजीनियर (SDET), जिन्होंने डेस्कटॉप और वेब संस्करणों में स्वत: परीक्षण मामले का सत्यापन स्थापित किया;
• बिजनेस इंटेलिजेंस। उन्होंने ग्राहक और डॉक्टरों के साथ बात की, पता चला कि व्यावसायिक प्रक्रियाएं कैसे बनाई गईं, आवेदन के लिए क्या आवश्यकताएं और इच्छाएं हैं। उसके बाद, उन्होंने व्यावसायिक प्रक्रिया आरेखों को तैयार किया जो पूरी टीम के लिए समझ में आता था;
• डिजाइनर और प्रयोज्य विशेषज्ञ। वे एक उपयोगकर्ता के अनुकूल इंटरफेस विकसित करने के लिए जिम्मेदार थे।
• प्रोजेक्ट मैनेजर जो प्रबंधन और समय निर्धारण में शामिल था।

इस प्रक्रिया में, हमने लगातार नए संस्करण में कथित जोखिमों की तालिकाएँ बनाए रखीं। उन्हें रोकने के लिए, हमने एप्लिकेशन सेटिंग की एक लचीली प्रणाली के बारे में सोचा और उपयोगकर्ताओं को त्रुटियों से बचाने के लिए इसके परीक्षण को स्वचालित कर दिया। विशेष रूप से, हमारे एसडीईटी विशेषज्ञ ने एक रूपरेखा लिखी जिससे कोड में सभी परिवर्तनों को जल्दी से जांचने और प्रतिगमन परीक्षण पर कम समय बिताने में मदद मिली।

चुनौतियां और समाधान

एप्लिकेशन को अपग्रेड करते समय, हमें कई कठिन चरणों का सामना करना पड़ा, जिसके बारे में हम नीचे चर्चा करेंगे।

ऐप डिजाइन

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

विभिन्न ब्राउज़रों के लिए प्लगइन विकास

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

अमान्य व्यावसायिक परिकल्पनाएँ

हमारा काम निवेशकों के सामने प्रस्तुति के लिए उत्पाद का सीमित संस्करण विकसित करना था। इस कारण से, हमने आवेदन को केवल सबसे आवश्यक कार्यों में लागू करने की मांग की। हमने ग्राहक की कुछ परिकल्पनाओं का विश्लेषण किया और उन्हें लागू करने से इनकार कर दिया।

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

बाहरी प्रणालियों के साथ एकीकरण

पत्रों को भेजने और संग्रहीत करने के लिए बाहरी प्रणालियों के साथ आवेदन को एकीकृत करने की प्रक्रिया पर हमारे साथी के साथ सहमत होने में बहुत समय लगा।

अनुप्रयोग facilities चिकित्सा सुविधाओं के उपयोगकर्ता, संस्करण 3.0 के लिए पुराने, परिचित एकीकरण प्रणालियों का उपयोग करना चाहते थे, उन्हें बदला नहीं जा सका। हमारे साथी ने मान लिया कि इस मामले में एकीकरण तेजी से होगा। हालांकि, वास्तव में, कई कार्य एकीकरण से जुड़े थे:

• मेल भेजने वाले सिस्टम कैसे काम करते हैं, इस पर सामान्य जानकारी इकट्ठा करें;
• 2.0 में थे कि महत्वपूर्ण कीड़े की एक सूची बनाओ;
• इन मामलों को विश्लेषणात्मक और विकास के स्तर पर विचार करें ताकि उन्हें ध्यान में रखा जाए और एक ही रेक पर कदम न उठाया जाए;
• विश्लेषण करें कि क्या संस्करण 2.0 के कार्य संस्करण 3.0 की प्रक्रियाओं के लिए उपयुक्त हैं या क्या कुछ बदलने की आवश्यकता है। परिवर्तनों के मामले में, हर बार निर्दिष्ट करें कि विशिष्ट कार्यों की आवश्यकता क्यों है और ग्राहक के तकनीकी विशेषज्ञों के साथ संवाद करना है, न कि केवल विश्लेषकों।

ग्राहक के साथ बातचीत की प्रक्रिया में, हम यह साबित करने में सक्षम थे कि एकीकरण के साथ काम करने में समय लगता है। हमारा साथी हमसे सहमत था: आप कोड को केवल एक संस्करण से दूसरे संस्करण में ले और स्थानांतरित नहीं कर सकते।

परीक्षण और विश्लेषण

विश्लेषकों की भागीदारी के बिना परियोजना का पिछला संस्करण बनाया गया था। डेवलपर्स और क्यूए विशेषज्ञों ने एप्लिकेशन बनाने की प्रक्रिया में आवश्यकताओं को निर्दिष्ट किया। तीसरा संस्करण पहले से ही विश्लेषकों की आवश्यकताओं पर आधारित था, हालांकि, परीक्षण के साथ अभी भी कठिनाइयाँ थीं:

• विभिन्न टीमों ने परियोजना पर काम किया;
• समानांतर कार्यों की एक बड़ी मात्रा थी;
• स्प्रिंट के दौरान, आवश्यकताओं और कार्यों को अक्सर बदल दिया जाता है;
• पहले से स्वीकृत लोगों के साथ नई सुविधाओं की बातचीत को ध्यान में रखना आवश्यक था।

उत्पाद के नए संस्करण पर काम करने के लिए, हमें व्यक्तिगत वर्कफ़्लोज़ को बदलने की ज़रूरत है, उदाहरण के लिए:

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

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

परिणाम

कार्य प्रक्रियाओं में लचीलापन और व्यवसाय की आवश्यकताओं पर ध्यान देने से हमें विकास प्रक्रिया के दौरान आने वाली सभी कठिनाइयों को दूर करने की अनुमति मिली। हमने यूरोप में चिकित्सा संस्थानों के लिए आवेदन का एक नया संस्करण सफलतापूर्वक बनाया और लॉन्च किया है।

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

उत्पाद के एक नए संस्करण को बनाते समय, डेवलपर्स, एक नियम के रूप में, उसी समस्याओं का सामना करते हैं जैसे हम करते हैं, उदाहरण के लिए:

• व्यवसाय की ओर से गलत परिकल्पना संभव है;
• उपयोगकर्ताओं की इच्छाओं में विरोधाभास हैं (सब कुछ छोड़ दें जैसा कि यह था या एक नए तरीके से रीमेक था);
• कभी-कभी बेहतर परिणाम प्राप्त करने के लिए टीम के काम का पुनर्गठन करना आवश्यक होता है।

मुख्य बात यह है कि आईटी उत्पाद के नए संस्करण की रिलीज पिछले संस्करण से "Ctrl + C", "Ctrl + V" कोड की प्रतिलिपि नहीं है, लेकिन एक पूर्ण विकसित, खरोंच से। ऐसा इसलिए है क्योंकि व्यावसायिक प्रक्रियाएं, उपयोगकर्ता आवश्यकताएं, साथ ही साथ आईटी समाधान बाजार की स्थिति बदल रही है।

आपका ध्यान के लिए धन्यवाद! हमें उम्मीद है कि आपको यह लेख मददगार लगेगा।