शक्तिशाली उपयोगकर्ता कहानियां कैसे तैयार करें और अपनी टीम के कौशल का लाभ उठाएं?

May 06 2023
अल्टीमेट कम्युनिकेशन टूल आपको यह बताने की अनुमति देता है कि सही समाधान के निर्माण में स्वायत्तता और आत्मविश्वास को बढ़ावा देने के लिए वास्तव में क्या मायने रखता है।
सही ढंग से उपयोग किए जाने पर उपयोगकर्ता कहानियां सबसे शक्तिशाली संचार उपकरणों में से एक हो सकती हैं। यह टीम के भीतर एकता की भावना को भी बढ़ावा देता है।

सही ढंग से उपयोग किए जाने पर उपयोगकर्ता कहानियां सबसे शक्तिशाली संचार उपकरणों में से एक हो सकती हैं। यह टीम के भीतर एकता की भावना को भी बढ़ावा देता है।

फिर भी, सिद्धांत में फंस जाना और कुछ सार्थक नहीं बनाना आसान है।

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

मैंने यह पहली बार अनुभव किया है!

उपयोगकर्ता कहानियों को तैयार करने में चुनौतियाँ

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

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

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

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

मैंने हमेशा खेलों का आनंद लिया है और समस्याओं का सबसे अच्छा समाधान खोजा है। मुझे जीवन के माध्यम से अपना रास्ता हैक करना भी पसंद है। यह चुनौती कुछ ऐसी थी जिससे मैं निपट सकता था।

वर्षों से, मैंने उपयोगकर्ता कहानियां बनाने के लिए अपना दृष्टिकोण विकसित किया है।

एक व्यावहारिक दृष्टिकोण

मैं उन टीमों के साथ प्रयोग करना पसंद करता हूं जिनके साथ मैं काम करता हूं।

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

हम एक साथ जीतते हैं, और हम एक साथ हारते हैं।

मैं लगातार आकलन कर रहा हूं, जुड़ाव का आकलन कर रहा हूं, फीडबैक मांग रहा हूं और अपने काम में सुधार कर रहा हूं।

एक टीम के रूप में, हमारा लक्ष्य हमारी विकास प्रक्रिया में हताशा के क्षेत्रों की पहचान करना और उन्हें समाप्त करना है।

मेरा व्यक्तिगत लक्ष्य अपनी टीम की उत्पादकता को बढ़ाना है। मैं काम का बोझ बढ़ाकर या तानाशाह बनकर ऐसा नहीं करता। मैं इसे खुशियों को बढ़ावा देकर और यह सुनिश्चित करके करता हूं कि हर कोई पूरा महसूस करे।

अन्यथा करने की कोशिश करना थका देने वाला हो सकता है और हमारी टीम के साथ एक निरंतर लड़ाई की तरह महसूस होता है - आगे और पीछे कभी न खत्म होने वाला।

इसलिए मैंने उपयोगकर्ता कहानियों के लिए अधिक व्यावहारिक दृष्टिकोण विकसित किया है। प्रणाली टीम के सदस्यों के बीच सहयोग और साझा समझ को प्रोत्साहित करती है।

सिस्टम बनाने का सबसे अच्छा तरीका मैंने सबसे कुशल पाया है। ये ऐसी प्रक्रियाएँ और उपकरण हैं जिन पर मैं भरोसा कर सकता हूँ और आवश्यकतानुसार परिष्कृत कर सकता हूँ।

सिस्टम भी वह है जिसके बारे में मैं भावुक हूं। वे उस अनुभव का हिस्सा हैं जो हम अपने लिए और अपने आसपास के लोगों के लिए बनाते हैं।

गेम डिज़ाइन-आधारित प्रणाली

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

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

"एक खेल हमारी ऊर्जा को निरंतर आशावाद के साथ केंद्रित करने का एक अवसर है, जिसमें हम अच्छे हैं (या बेहतर हो रहे हैं) और आनंद लें। दूसरे शब्दों में, गेमप्ले अवसाद के प्रत्यक्ष भावनात्मक विपरीत है।
-
जेन मैकगोनिगल - वास्तविकता टूट गई है: क्यों खेल हमें बेहतर बनाते हैं और वे दुनिया को कैसे बदल सकते हैं

चार पहलू मेरे दृष्टिकोण का निर्माण करते हैं:

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

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

मैं इन सिद्धांतों को उस उत्पाद पर लागू करता हूं जिस पर मैं काम करता हूं, मेरी नेतृत्व शैली या मेरे द्वारा लिखी जाने वाली उपयोगकर्ता कहानियां।

याद रखें, सब कुछ एक उत्पाद है!

प्रभावी उपयोगकर्ता कहानियां तैयार करने के लिए महत्वपूर्ण कदम

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

उत्तर देने वाला पहला प्रश्न है: उपयोगकर्ता कहानी के माध्यम से मैं क्या मूल्य प्रदान करना चाहता हूं? उस कहानी का लक्षित ग्राहक कौन है?

उनके उत्पाद के ग्राहक उपयोगकर्ता कहानियों के लक्षित ग्राहक हो सकते हैं।

यह सही नहीं है।

ग्राहक हमारी कहानियां नहीं देखते हैं; वे केवल परिणामों का अनुभव करते हैं।

हमारी कहानियों के वास्तविक ग्राहक इंजीनियर हैं। वे इस उत्पाद का उपयोग हमारे ग्राहकों के लिए मूल्य बनाने और वितरित करने के लिए करते हैं।

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

मंत्र का पालन - लोग, उत्पाद, लाभ!

तो, हम उपयोगकर्ता कहानियां कैसे बना सकते हैं जो इंजीनियरों के साथ प्रतिध्वनित होती हैं? हम उपयोगकर्ता कहानियां कैसे बना सकते हैं जो एक अधिक कुशल विकास प्रक्रिया को बढ़ावा देती हैं?

अंत में, मैं इसे अपना बनाना चाहता हूं। उपयोगकर्ता कहानियों को तैयार करते समय मैं क्या अद्वितीय मूल्य ला सकता हूं?

सबसे पहले, उपयोगकर्ता कहानियां उपयोग के मामले से उत्पन्न होती हैं: कोई उपयोग मामला नहीं, कोई कहानी नहीं। परिदृश्य चाहे जो भी हो, इंजीनियरों को कहानी के संदर्भ को समझने की जरूरत है।

यहाँ कुछ महत्वपूर्ण कदमों पर विचार किया गया है:

1. सरल शीर्षक

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

2. पृष्ठभूमि और "क्यों" शामिल करें।

उपयोगकर्ता कहानियों के पीछे संदर्भ और कारण प्रदान करें। समझाएं कि हम इस पर क्यों काम कर रहे हैं, यह क्या मूल्य लाता है, और हम किसके लिए समाधान बना रहे हैं। सब कुछ प्रासंगिक है। इंजीनियरों को उस समस्या का सबसे अच्छा समाधान मिल सकता है जिसे हम हल करने का प्रयास कर रहे हैं और यदि हम उन्हें उचित संदर्भ देते हैं तो हम जिस मूल्य को प्राप्त करने का प्रयास कर रहे हैं।

इंजीनियरों को काम देने और जानकारी के आवश्यक हिस्से को रोक देने से किसी का भला नहीं होगा। ऐसा इसलिए नहीं है कि प्रधान मंत्री के रूप में हम अपना ज्ञान हस्तांतरित करते हैं जिससे हम सत्ता खो देते हैं। यह दूसरा तरीका है।

3. निम्न प्रारूप का प्रयोग करें

"जब [व्यक्ति] कर रहा है [मामले का प्रयोग करें], [समस्या] होती है, जो [भावनाओं] की ओर ले जाती है। इसके बजाय, उन्हें [नया अनुभव] करने में सक्षम होना चाहिए, जो उन्हें [मूल्य/लक्ष्य/लाभ] हासिल करने में मदद करेगा।"

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

4. दृश्य/वर्कफ़्लो जोड़ें

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

5. सुनिश्चित करें कि कहानियां स्मार्ट हैं

SMART एक चेकलिस्ट है जिसका उपयोग मैं अपनी कहानियाँ लिखते समय करता हूँ। यदि मैं संक्षिप्ताक्षरों में से किसी एक अक्षर का पता नहीं लगा सकता, तो इससे मुझे अपनी उपयोगकर्ता कहानियों पर अधिक सटीक रूप से काम करने में मदद मिलती है। स्मार्ट का अर्थ है:

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

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

7. रोलआउट की पहचान करें

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

8. प्रक्रिया के अंत से कार्य करें

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

9. इंजीनियरों को स्वायत्तता दें

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

10. पुनरावृति और सुधार करें

इस प्रक्रिया का सबसे महत्वपूर्ण हिस्सा महानता की कभी न खत्म होने वाली यात्रा है। हमें एक टीम के रूप में लगातार प्रतिक्रिया एकत्र करनी चाहिए और उपयोगकर्ता कहानियों के प्रति अपने दृष्टिकोण को परिष्कृत करना चाहिए।

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

सुनिश्चित करें कि इंजीनियर समझें। उनकी जरूरतों को समझने के लिए समय निकालें और हम एक मजबूत टीम बना सकते हैं।

यह देखने की कोशिश करें कि यह आपकी टीम के साथ आपकी मदद कैसे कर सकता है। मुझे जानने दो जो आप सोचते हो।

अभी के लिए बस इतना ही।

आपसे अगली बार मिलेंगे।

अगर आपको यह लेख अच्छा लगा हो तो कृपया इसे शेयर या लाइक करके मेरा समर्थन करें।

आज ही मीडियम का सदस्य बनकर मेरे लेखन का समर्थन करें । असीमित संख्या में लेखों तक पहुंच प्राप्त करें।

यहां मेरा अनुसरण करें , और मेरे लिए यहां एक कॉफी खरीदें - ताकि मैं उनमें से और अधिक लिख सकूं!