फ़ील्ड समस्या रिपोर्टिंग ऐप: क्रू के लिए व्यावहारिक योजना

फ़ील्ड रिपोर्ट देर से या अधूरी क्यों पहुँचती हैं

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

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

क्रू को ऐसा फ़ील्ड समस्या रिपोर्टिंग ऐप चाहिए जो समस्या मिलते ही काम करे। कर्मचारी को फ़ोटो लेने, लोकेशन की पुष्टि करने, समस्या का प्रकार चुनने, ज़रूरत हो तो छोटा नोट जोड़ने और रिपोर्ट भेजने में सक्षम होना चाहिए। «नई», «काम चल रहा है» या «हल हो गई» जैसे स्टेटस बदलने में एक-दो टैप से ज़्यादा समय नहीं लगना चाहिए।

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

एक उपयोगी वर्कफ़्लो में केवल वही जानकारी माँगी जानी चाहिए जो अगले कदम को प्रभावित करती है: फ़ोटो, लोकेशन, समस्या का प्रकार, जहाँ ज़रूरी हो वहाँ तात्कालिकता, वैकल्पिक नोट और स्पष्ट स्टेटस। ऐप को रिपोर्ट करने वाले का नाम और जमा करने का समय अपने-आप दर्ज करना चाहिए। फ़ोन को पहले से पता जानकारी दोबारा लिखवाने से समय भी बर्बाद होता है और गलतियाँ भी बढ़ती हैं।

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

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

तय करें कि हर रिपोर्ट में क्या चाहिए

क्रू सदस्य को एक मिनट से कम समय में उपयोगी रिपोर्ट जमा कर पाने में सक्षम होना चाहिए। शुरुआत उन कम से कम विवरणों से करें जो किसी व्यक्ति को समस्या समझने, उसे ढूँढने और यह तय करने में मदद दें कि कार्रवाई कौन करेगा।

कई टीमों के लिए इसका मतलब है: फ़ोटो, समस्या का प्रकार, मौजूदा लोकेशन, स्टेटस और छोटा नोट। टूटी पाइप, बंद रास्ते या क्षतिग्रस्त साइन की तस्वीर लंबे विवरण से ज़्यादा जल्दी स्थिति समझा सकती है। नोट में वह संदर्भ होना चाहिए जो तस्वीर नहीं दिखा सकती, जैसे «पानी लोडिंग एरिया तक पहुँच रहा है» या «गेट लॉक नहीं हो रहा»।

पहली रिपोर्ट को उस जानकारी तक सीमित रखें जो साइट पर मौजूद व्यक्ति जानता है:

• जहाँ दृश्य प्रमाण उपयोगी हो वहाँ फ़ोटो या वीडियो
• परिचित और छोटी सूची में से समस्या का प्रकार
• फ़ोन से दर्ज की गई लोकेशन, जिसे सुधारने का विकल्प भी हो
• शुरुआती स्टेटस, जैसे «नई» या «समीक्षा ज़रूरी»
• वैकल्पिक नोट

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

किसी फ़ील्ड को तभी ज़रूरी बनाएँ जब उसके बिना रिपोर्ट आगे नहीं बढ़ सकती। समस्या का प्रकार आम तौर पर ज़रूरी होता है, क्योंकि इससे रिपोर्ट सही व्यक्ति तक भेजने में मदद मिलती है। क्षति के दावे के लिए फ़ोटो ज़रूरी हो सकती है, लेकिन कम रोशनी में सुरक्षा समस्या दर्ज करते समय यह रुकावट बन सकती है। नोट आम तौर पर वैकल्पिक रहना चाहिए।

एक आसान नियम मदद करता है: अगर क्रू सदस्य को रुककर जानकारी खोजनी पड़े या एक वाक्य से ज़्यादा लिखना पड़े, तो उस फ़ील्ड को बाद की समीक्षा में ले जाएँ।

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

तेज़ इस्तेमाल के लिए रिपोर्ट स्क्रीन डिज़ाइन करें

क्रू सदस्य के पास एक ही हाथ खाली हो सकता है, स्क्रीन पर तेज़ धूप पड़ सकती है और समस्या का तुरंत ध्यान रखना पड़ सकता है। पहली स्क्रीन ऑफिस फ़ॉर्म जैसी नहीं, कुछ टैप जैसी लगनी चाहिए।

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

पहली स्क्रीन को चार कामों पर केंद्रित रखें:

• फ़ोटो जोड़ना या लेना
• समस्या का प्रकार चुनना
• मौजूदा स्टेटस तय करना
• रिपोर्ट जमा करना या ड्राफ़्ट सहेजना

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

नोट ज़रूरी हैं, लेकिन उन्हें मुख्य कार्रवाइयों के नीचे रखें और वैकल्पिक बनाएँ। «ज़रूरत हो तो विवरण जोड़ें» जैसा संकेत बड़े ज़रूरी टेक्स्ट बॉक्स से बेहतर काम करता है। फ़ोटो को संदर्भ की ज़रूरत होने पर कोई व्यक्ति «गेट 3 के पास पानी लीक हो रहा है» लिख सकता है और आगे बढ़ सकता है।

हर टैप का संबंध किसी वास्तविक निर्णय से होना चाहिए। अगर कोई फ़ील्ड अगले कदम को प्रभावित नहीं करती, तो उसे पहली स्क्रीन से हटाकर बाद में लें।

AppMaster के विज़ुअल UI बिल्डर और बिज़नेस लॉजिक टूल इस तरह का मोबाइल इंटरफ़ेस बनाने में टीमों की मदद कर सकते हैं। टीम छोटा रिपोर्ट फ़ॉर्म बना सकती है, फ़ोटो और स्टेटस बदलावों को उसी समस्या रिकॉर्ड से जोड़ सकती है और वास्तविक परिस्थितियों में क्रू के इस्तेमाल के बाद स्क्रीन में बदलाव कर सकती है।

बिना अतिरिक्त मेहनत के लोकेशन दर्ज करें

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

जब रिपोर्ट में जगह ज़रूरी हो, तो ऐप को डिवाइस की अनुमति एक बार माँगने दें और क्रू सदस्य के रिपोर्ट शुरू करने या भेजने पर मौजूदा निर्देशांक दर्ज कर लें। एक आसान पुष्टि दिखाएँ: साइट का नाम, पता या छोटे नक्शे पर पिन। कर्मचारी को निर्देशांक टाइप करने या बाहर जाकर पता खोजने की ज़रूरत नहीं होनी चाहिए।

ऊँची इमारतों के पास, गोदाम के अंदर, भूमिगत जगहों पर या खराब मौसम में GPS गलत हो सकता है। कर्मचारियों को इसे आसानी से सुधारने दें। वे पिन को खिसका सकें, सेव की गई साइट खोज सकें या ज्ञात लोकेशन में से चुन सकें। स्वचालित रीडिंग को बदली हुई लोकेशन के साथ रखें, ताकि सुपरवाइज़र देख सके कि क्या बदला गया।

जहाँ उपयोगी हो वहाँ मैप पॉइंट से अधिक जानकारी सहेजें: लोकेशन का स्रोत, दर्ज करने का समय, चुनी गई साइट और छोटा लोकेशन नोट। «उत्तर की लोडिंग बे» बड़े परिसर के बीच में लगे पिन से अधिक उपयोगी है।

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

AppMaster में टीमें स्वीकृत साइटों को ऐप के डेटा मॉडल में रख सकती हैं और लोकेशन कैप्चर को फ़ोटो और समस्या वाले फ़ील्ड के पास रख सकती हैं। इससे बार-बार टाइप करने की ज़रूरत घटती है और गलत GPS रीडिंग सुधारने की गुंजाइश भी रहती है। गोदाम में पानी लीक होने पर क्रू सदस्य फ़ोटो ले सकता है, «बे 4» चुन सकता है, लोडिंग दरवाज़ों के पास पिन लगा सकता है और जल्दी से रिपोर्ट भेज सकता है।

ऑफ़लाइन ड्राफ़्ट को वर्कफ़्लो का हिस्सा बनाएँ

क्रू अक्सर ऐसी जगह काम करता है जहाँ सिग्नल चला जाता है: बेसमेंट, दूर की साइट और बड़े परिसर के दूर वाले हिस्से। रिपोर्टिंग वर्कफ़्लो को क्रू सदस्य के शुरू करते ही डिवाइस पर ड्राफ़्ट सहेज लेना चाहिए। किसी के «जमा करें» दबाने तक इंतज़ार करना जोखिम भरा है। कनेक्शन टूटने, ऐप बंद होने या बैटरी खत्म होने से उपयोगी रिपोर्ट के लिए दूसरी यात्रा करनी पड़ सकती है।

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

अपलोड स्टेटस आसानी से समझ आने वाला बनाएँ

ऐसे सरल लेबल इस्तेमाल करें जो हर रिपोर्ट की स्थिति बताएँ:

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

होम स्क्रीन पर छोटी गिनती भी मदद करती है। «अपलोड के लिए 3 रिपोर्ट प्रतीक्षा में» क्रू को भरोसेमंद नेटवर्क वाली साइट छोड़ने से पहले याद दिलाता है।

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

रिलीज़ से पहले वास्तविक परिस्थितियों में इसका परीक्षण करें। फ़ोन को एयरप्लेन मोड में रखें, कई फ़ोटो वाली रिपोर्ट बनाएँ, ऐप बंद करके फिर खोलें और कनेक्शन वापस चालू करें। रिपोर्ट पूरी रहनी चाहिए और फ़ोन के दोबारा कनेक्ट होते ही अपलोड हो जानी चाहिए।

समस्या के प्रकार और स्टेटस अपडेट सेट करें

समस्या के प्रकार उन चीज़ों से मेल खाने चाहिए जिनका सामना क्रू सामान्य शिफ्ट में करता है। «अन्य» या «समस्या» जैसे सामान्य विकल्प रिकॉर्ड को अव्यवस्थित बनाते हैं और सुपरवाइज़र को हर नोट पढ़ने पर मजबूर करते हैं। लोगों द्वारा सबसे ज़्यादा रिपोर्ट की जाने वाली घटनाओं से शुरुआत करें और कुछ हफ्तों के इस्तेमाल के बाद सूची में बदलाव करें।

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

बहुत लंबी सूची से बचें। अगर लोगों को 25 प्रकारों में स्क्रॉल करना पड़ेगा, तो वे सबसे नज़दीकी विकल्प चुनेंगे या रिपोर्ट टाल देंगे। शुरुआत में पाँच से दस प्रकार पर्याप्त संरचना देते हैं। «अन्य» शामिल करें, तो छोटा नोट माँगें, ताकि टीम सूची में मौजूद कमियों को पहचान सके।

हर नई रिपोर्ट का डिफ़ॉल्ट स्टेटस रखें, आम तौर पर «नई»। फ़ील्ड में मौजूद व्यक्ति को केवल वह दर्ज करना है जो उसने देखा। सुपरवाइज़र बाद में प्राथमिकता तय, काम असाइन और शेड्यूल कर सकता है।

स्टेटस मेन्यू छोटा रखें:

• नई: रिपोर्ट की समीक्षा बाकी है
• असाइन की गई: अगले कदम की ज़िम्मेदारी किसी व्यक्ति के पास है
• काम चल रहा है: काम शुरू हो चुका है
• हल हो गई: क्रू ने काम पूरा कर लिया है
• बंद: सुपरवाइज़र ने परिणाम जाँच लिया है

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

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

AppMaster समस्या के प्रकारों को नियंत्रित सूचियों में रख सकता है, जमा करते समय «नई» स्टेटस अपने-आप लगा सकता है और असाइनमेंट तथा अंतिम तारीखों के लिए सुपरवाइज़र को अलग व्यू दे सकता है। इससे क्रू का वर्कफ़्लो तेज़ रहता है और मैनेजर खुले काम की स्पष्ट कतार बनाए रख सकते हैं।

क्रू रिपोर्टिंग का एक आसान उदाहरण

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

कर्मचारी रिपोर्टिंग ऐप खोलकर नया रिकॉर्ड शुरू करता है। साइट विज़िट पहले से चुनी हुई है, इसलिए बहुत कम टाइप करना पड़ता है। वह «क्षतिग्रस्त गेट» चुनता है, पूरे गेट की एक फ़ोटो और मुड़ी हुई पट्टी की दूसरी फ़ोटो लेता है, फिर सुझाए गए मैप पिन की जाँच करता है। छोटा नोट होता है, «गेट बंद हो जाता है, लेकिन कुंडी अटकती नहीं है।»

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

फ़ोन दोबारा कनेक्ट होने पर रिपोर्ट अपलोड हो जाती है। सुपरवाइज़र फ़ोटो और लोकेशन देखकर मरम्मत असाइन करता है और स्टेटस «असाइन की गई» कर देता है। तकनीशियन गेट सीधा करने और कुंडी बदलने के बाद पूरी हुई मरम्मत की फ़ोटो जोड़ता है और स्टेटस «हल हो गई» कर देता है।

पूरा रिकॉर्ड एक ही जगह रहता है: समस्या किसने दर्ज की, कहाँ हुई, कब भेजी गई, किसने संभाली और अंतिम परिणाम क्या रहा। गेट पर किए गए कुछ टैप कई घंटे बाद दी जाने वाली लंबी व्याख्या की जगह ले लेते हैं।

ऐसी गलतियाँ जो क्रू का काम धीमा करती हैं

फ़ील्ड रिपोर्टिंग ऐप तब विफल होता है जब वह क्रू सदस्य से डेस्क पर बैठे व्यक्ति की तरह काम करने को कहता है। क्षतिग्रस्त साइन, लीक पाइप या बंद रास्ते के पास खड़े व्यक्ति को समस्या जल्दी दर्ज करनी होती है, अक्सर दस्ताने पहनकर और कमजोर सिग्नल में।

लंबे विवरण वाले फ़ील्ड आम गलती हैं। नोट को वैकल्पिक रखें और फ़ोटो, समस्या के प्रकार, लोकेशन और आसान स्टेटस कंट्रोल से तथ्य जुटाएँ। ज़रूरत होने पर कर्मचारी «वाल्व के पास पानी» लिख सकता है, लेकिन ऐप को सहेजने से पहले पैराग्राफ की माँग नहीं करनी चाहिए।

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

सेव होने की स्थिति साफ़ दिखाएँ

क्रू को पता होना चाहिए कि ऐप ने उनकी रिपोर्ट रख ली है या नहीं। फ़ोन ऑफ़लाइन हो तो स्पष्ट ड्राफ़्ट लेबल, दोबारा कनेक्ट होने पर अपलोड की प्रगति और रिपोर्ट भेजे जाने के बाद पुष्टि दिखाएँ।

स्टेटस कंट्रोल भी उतने ही तेज़ रखें। «नई», «काम चल रहा है» और «हल हो गई» जैसे बटन हर बार अपडेट टाइप करवाने वाली स्क्रीन से बेहतर हैं। विवरण तभी जोड़ने दें जब काम के लिए इसकी ज़रूरत हो।

वास्तविक फ़ील्ड परिस्थितियों में परीक्षण करें

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

रिलीज़ से पहले जाँचें कि फ़ोटो अपलोड के दौरान कनेक्शन टूटने पर ऐप पूरा ड्राफ़्ट सहेजता है या नहीं, कौन-सी रिपोर्ट अपलोड की प्रतीक्षा में है यह दिखाता है या नहीं, कोई व्यक्ति दो बार सेव दबाए तो डुप्लिकेट से बचता है या नहीं और क्रू एक हाथ से कैमरा, लोकेशन और स्टेटस कंट्रोल इस्तेमाल कर सकता है या नहीं।

पहला वर्ज़न सीमित रखें। वास्तविक क्रू किसी योजना बैठक से कहीं जल्दी बता देगा कि रुकावट कहाँ है।

रिलीज़ से पहले तेज़ जाँच

ऐप का परीक्षण वहीं करें जहाँ क्रू काम करता है, केवल भरोसेमंद Wi-Fi वाले डेस्क पर नहीं। एक या दो कर्मचारियों से किसी वास्तविक छोटी समस्या, जैसे क्षतिग्रस्त साइन या लीक वाल्व, की रिपोर्ट करने को कहें। देखें कि वे कहाँ रुकते हैं, गलत कंट्रोल दबाते हैं या मदद माँगते हैं।

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

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

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

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

एक छोटे काम करने वाले वर्ज़न से शुरुआत करें

पहला वर्ज़न एक क्रू और एक सामान्य काम के प्रकार के लिए बनाएँ। सामान्य इस्तेमाल का एक सप्ताह बताएगा कि किस चीज़ पर ध्यान देना है। कर्मचारियों से नियमित शिफ्ट के दौरान वास्तविक रिपोर्ट जमा करवाएँ, जिनमें फ़ोटो, लोकेशन और स्टेटस बदलाव शामिल हों।

केवल वही विवरण शामिल करें जिनसे कोई व्यक्ति समस्या समझकर कार्रवाई कर सके: समस्या का प्रकार, फ़ोटो, लोकेशन, वैकल्पिक नोट और मौजूदा स्टेटस। अगर सुपरवाइज़र किसी फ़ील्ड का इस्तेमाल निर्णय लेने के लिए नहीं कर सकता, तो फिलहाल उसे छोड़ दें।

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

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

AppMaster इस तरह के पहले निर्माण के लिए उपयोगी है, क्योंकि टीमें विज़ुअल Data Designer में रिपोर्ट की डेटा संरचना बना सकती हैं, Business Process Editor में रिपोर्ट के नियम तय कर सकती हैं और प्रोग्रामिंग के बिना मोबाइल स्क्रीन बना सकती हैं। यह फ़ोटो फ़ील्ड, निर्देशांक और «नई», «असाइन की गई» तथा «ठीक की गई» जैसे स्टेटस वाले केंद्रित ऐप को समर्थन दे सकता है।

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

परीक्षण के बाद पूछें कि किस स्क्रीन में सबसे अधिक समय लगा और ऑफिस को किन तथ्यों के लिए अब भी फ़ोन करना पड़ा। इन कमियों को ठीक करें, एक और छोटा परीक्षण चलाएँ और फिर ऐप को अधिक क्रू तक पहुँचाएँ।