2008-10-25 10 views
9

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

उत्तर

9

प्रथम प्रशिक्षण से बचने की कोशिश:

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

जितनी बार आप कर सकते हैं प्रासंगिक सहायता भी जोड़ें। उदाहरण के लिए जब मैं स्टैक ओवरफ़्लो में एक टैग पर होवर करता हूं, तो मुझे पता है कि यह वास्तव में क्या क्लिक करेगा, क्योंकि यह मुझे बताता है।

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

प्रशिक्षण प्रलेखन के बारे में:

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

समर्थन आपके मदद दस्तावेज़ में यादृच्छिक पढ़ता है। अगर उनके पास आपके वेब ऐप में कोई काम है, तो उन्हें असंबंधित सामग्री का एक समूह पढ़ने के बिना उस पर सहायता प्राप्त करने में सक्षम होना चाहिए।

सुनिश्चित करें कि आपका दस्तावेज़ खोजे जा सकें।

वास्तविक प्रशिक्षण सत्र के बारे में:

आप वास्तव में प्रशिक्षण सत्र प्रदर्शन कर रहे हैं, तो सब पर अपने कोड से संबंधित कुछ समझा से दूर रहना। आपको कार चलाने के लिए इंजन के बारे में जानने की आवश्यकता नहीं है।

अपने प्रशिक्षण सत्रों को अपने सिस्टम के बहुत केंद्रित पहलुओं में विभाजित करने का प्रयास करें। यदि आपके पास केवल 1 प्रशिक्षण सत्र उपलब्ध है तो बस अपने सिस्टम का एक विशेष उपयोग केस + सिस्टम का समग्र वर्णन करें। दस्तावेज़ीकरण के विभिन्न हिस्सों का संदर्भ लें जहां वे सहायता प्राप्त कर सकते हैं।

चाहे कितना व्यापक आपके दस्तावेज है, तो आप हमेशा मामलों है कि आप को कवर नहीं किया होगा:

समुदाय मदद ही दे। यही कारण है कि सिस्टम के सभी उपयोगकर्ताओं के लिए एक मंच उपलब्ध होना अच्छा विचार है। उन्हें एक-दूसरे के प्रश्न पूछने दें।

आप इस मंच की समीक्षा कर सकते हैं और आवश्यकतानुसार अपने दस्तावेज़ में सामग्री जोड़ सकते हैं।

आप दस्तावेज़ीकरण के लिए भी विकी खोल सकते हैं, लेकिन संभवतः यह संभव नहीं है कि आपका उपयोगकर्ता आधार बहुत बड़ा न हो।

+0

"प्रशिक्षण से बचें" +1! अगर लोगों को पता है कि कैसे अपना काम करना है और ऐप यूआई जानबूझकर और अच्छी तरह से डिजाइन किया गया है, तो उन्हें नौकरी करने में मदद करने के लिए, व्यापक प्रशिक्षण आवश्यक नहीं होना चाहिए। –

+0

"प्रासंगिक सहायता भी जोड़ें" +1 - यह जोर से रोने के लिए वेब पेज है। पेज पर सभी स्पष्टीकरण जोड़ें! –

3

कुछ विचार:

क्या आपके पास कुछ डिब्बाबंद चलने वाले परिदृश्य हैं? पता नहीं है कि यह आपके उत्पाद के लिए लागू है, लेकिन मैंने कुछ साल पहले एक बहुत ही महत्वपूर्ण उत्पाद बनाया था और कुछ प्रशिक्षण मॉड्यूल विकसित किए थे जो वे काम करेंगे - कुछ भी नहीं, शायद प्रत्येक के लिए 15 मिनट सबसे ऊपर।

मैंने एक स्लाइड प्रेजेंटेशन एक साथ रखा जो हाइलाइट्स को इसके बारे में बात करने के लिए हिट करता है। हाथों पर सामान करने से पहले मैं इसे परिचित करने के लिए ऐप की हाइलाइट्स के माध्यम से लगभग 10 मिनट खर्च करता हूं।

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

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

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

लागू होने पर, उनके लिए ऑनलाइन सहायता/विकी/faq प्रदान करें। कभी-कभी यह सहायक होता है।

शुभकामनाएँ!

1

मैं अगले कुछ महीनों में इस तरह कुछ भी देख रहा हूं।

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

मेरे लिए मुख्य बात तर्क और स्थिरता होगी। यदि ऐप का वर्कफ़्लो कार्य को तर्कसंगत रूप से संबंधित करता है तो इसे पूरा करने के लिए डिज़ाइन किया गया है और यूआई सुसंगत है तो आपको ठीक होना चाहिए।

1

अपने सिस्टम के उपयोग का वर्णन करने के लिए विकी पेज बनाएं। आपके सिस्टम के उपयोगकर्ताओं के लिए संपादित करने के अधिकारों देते देता उपयोगकर्ताओं:

  • अद्यतन प्रलेखन प्रलेखन के आरंभिक रिलीज में किसी भी त्रुटि को दूर करने के,
  • शेयर उन्होंने पाया हो सकता है के उपयोग पर कोई सुझाव।
  • सिस्टम के लिए असामान्य उपयोग साझा करें जिन्हें आपने नहीं सोचा था।
  • अनुरोध विशेषताएं।
  • नई कार्यक्षमता को कार्यान्वित करने की प्रतीक्षा करते हुए उन्हें मिले किसी भी कामकाज प्रदान करते हैं।
2

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

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

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

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

जैसा कि आप कहां हैं, आप इस सब को लागू करने में बहुत देर हो चुकी हैं, लेकिन यदि आप कुछ उत्सुक, महत्वपूर्ण, उपयोगकर्ताओं की पहचान कर सकते हैं और अपने स्वयं के दस्तावेज़ लिखने के लिए समय निकाल सकते हैं तो यह अच्छा होगा चलते हैं। यदि आप इसे भी प्राप्त नहीं कर सकते हैं तो आपको एक ऐसे प्रचारक की पहचान करने की आवश्यकता है जिसे आप 'विभागीय' विशेषज्ञ बनने के लिए प्रशिक्षित कर सकते हैं और उन्हें समर्थन देने के लिए अपनी ऊर्जा का 110% दे सकते हैं।

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

0

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

अपने दस्तावेज़ों के लिए हाउटो/वॉकथ्रू में कोर आवश्यकताएं/केस/स्टोरीकार्ड का उपयोग करें।

एक सार्वजनिक प्रशिक्षण के लिए, एक 10..15 मिनट की प्रस्तुति (सिर्फ इतना है कि, नहीं अधिक!) कि महत्वपूर्ण अवधारणाओं कि उपयोगकर्ताओं बिल्कुल समझ लेना चाहिए, की तुलना में अपने मूल walkthroughs दिखाने को शामिल किया गया तैयार करते हैं। विभिन्न कार्यों को हल करने के तरीके के बारे में प्रश्नों के लिए अतिरिक्त समय आरक्षित करें।

एक उपयोगकर्ता के रूप में सोचें, तकनीकी के रूप में नहीं: - कोई भी परवाह नहीं करता है कि यह एक SQL डेटाबेस है और आपने लॉकिंग तंत्र को सही करने के लिए बहुत समय बिताया है। वे "मुझे धीमा कर देते हैं" के बारे में परवाह करते हैं और "कुछ बुरा होता है जब दो लोग एक ही समय में ऐसा करते हैं"। हमारा काम जटिल चीजों को आसान बनाना है।

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

0

इसके बजाय उन सभी लोगों को प्रशिक्षित करें जिन्हें मैंने कुछ सुपरसर्स (प्रत्येक विभाग से कम से कम एक व्यक्ति) चुना है और बाकी कर्मचारियों को सिखाने के लिए प्रशिक्षित किया है। यह महत्वपूर्ण निश्चित रूप से है कि उन सुपर उपयोगकर्ताओं

  • अच्छी तरह से उनके विभागों में सम्मान किया जाता है
  • आवेदन की तरह

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

संबंधित मुद्दे