हेलो, हेब्र!
हाल ही में एक नई सुविधा शुरू की है - ग्राहकों के लिए साप्ताहिक रिपोर्ट। लब्बोलुआब यह है: परियोजना प्रबंधक प्रत्येक सोमवार को एक रिपोर्ट पत्र तैयार करता है जो परियोजना की वर्तमान स्थिति का वर्णन करता है। और क्लाइंट को भेजता है। ख़ासियत यह है कि रिपोर्ट के लिए हम एक विशेष रूप के साथ आए। अब क्रम से बताऊंगा।
तो, पत्र की संरचना। क्लाइंट के लिए पहली दो लाइनें सबसे महत्वपूर्ण हैं। पहली परियोजना की वर्तमान स्थिति है, वैश्विक सवाल का जवाब "क्या सब कुछ ठीक है?" दूसरा पूर्वानुमान है: "क्या सब ठीक
हो जाएगा ?"
प्रत्येक पंक्ति के आगे हम एक रंगीन तारांकन करते हैं। हरा - कोई समस्या नहीं, पीला - समस्याएं हैं, लाल - समस्याएं गंभीर हैं।
इस प्रकार, ग्राहक को पत्र की शुरुआत में दो सितारों को देखने के लिए पर्याप्त है (बिना कुछ पढ़े) और आधे से एक सेकंड में यह समझने के लिए कि परियोजना पर चीजें कैसे चल रही हैं। उदाहरण के लिए, एक संयोजन
इसका मतलब है "अब यह परियोजना अच्छा काम कर रही है, लेकिन भविष्य में यह और खराब हो सकती है।" और फिर एक विस्तृत संरचित रिपोर्ट (स्पष्टीकरण के साथ क्यों खराब हो सकती है) आती है।
विवरण निम्नलिखित क्रम में दिए गए हैं:
- तिथियाँ, बजट, रिलीज़ की तारीखें (परियोजना और व्यक्तिगत चरण), योजनाएँ।
- फिर समस्याओं, विचारों, जोखिमों, ग्राहक के सवालों का पालन करें।
- हम नोट करने के बाद "सूचनात्मक" क्षण जो ग्राहक के लिए उपयोगी हो सकते हैं। उदाहरण के लिए, एक प्रतियोगी सेवा का शुभारंभ।
आप इस पर कैसे आए?
ग्राहक की परियोजना की स्थिति पर नजर रखने की जरूरत हमेशा मौजूद रही है। सबसे पहले, हमने "मुक्त" रूप में रिपोर्ट, पाठ भी भेजे। तब हम इस निष्कर्ष पर पहुंचे कि हम स्वयं कुछ संकेतकों (हमारे लिए महत्वपूर्ण) के लिए परियोजना की स्थिति की साप्ताहिक निगरानी करना चाहेंगे। हमने यह सूची लिखी है:
तब उन्होंने यह सब "दृश्यता" देने की कोशिश की, ताकि धारणा आसान हो सके। हमने टिंटेड क्षेत्रों के साथ एक फॉर्म बनाया (जहां हरा सब कुछ अच्छा है, जहां लाल महत्वपूर्ण समस्याएं हैं जिन्हें तत्काल समाधान की आवश्यकता है)। तालिका स्वयं बेतहाशा समझ में आ गई, लेकिन हमें फूलों का विचार पसंद आया।
तो रंग चित्रलेखों के साथ एक रिपोर्ट थी।
रिपोर्टों की एकरूपता के लिए, विशिष्ट आवश्यकताओं को उनके सामने प्रस्तुत किया गया था:
पहली बार रिपोर्ट को "पढ़ा" जाना चाहिए:- रिपोर्ट का "पिरामिड" संरचना: पहला, मुख्य बात, फिर विस्तार।
- पिक्टोग्राम और कलर कोड का सक्रिय उपयोग।
- कोई अटैचमेंट नहीं! केवल पत्र ही! (कभी-कभी वे केवल अनुप्रयोगों पर ध्यान नहीं देते हैं)
समूहों में रिपोर्ट में संकेतक का अंतर:- प्राथमिक (इसमें पहली दो पंक्तियाँ (स्थिति और पूर्वानुमान), परियोजना की रिलीज़ दिनांक और वर्तमान चरण, बजट, ग्राहक के लिए महत्वपूर्ण क्षण शामिल हैं)।
- माइनर (योजनाएं, उभरती समस्याएं, विचार, जोखिम और ग्राहक के लिए स्पष्ट प्रश्न)।
सारांश भाग की उपस्थिति, जिसमें शामिल हैं:- हमसे संपर्क करें।
- उन घटनाओं की जानकारी जो ग्राहक के व्यवसाय को प्रभावित कर सकती हैं।
उसी रिपोर्ट में, हम न केवल उन समस्याओं का संकेत देते हैं जो उत्पन्न हुई हैं (या उत्पन्न हो सकती हैं), लेकिन संभव समाधान भी सुझाती हैं। ग्राहक को पत्र का जवाब देना होगा।
मुझे साप्ताहिक रिपोर्ट की आवश्यकता क्यों है?
वह कई लक्ष्यों का पीछा करता है - दोनों बहुत स्पष्ट और बहुत स्पष्ट नहीं।
सबसे पहले, यह
विकास प्रक्रिया की पारदर्शिता प्रदान करता है। लक्ष्य रणनीतिक है। यह ग्राहक (व्यवसाय के मालिक) और उनके प्रतिनिधि के लिए सुविधाजनक है, औपचारिक रूप से बजट के उपयोग के लिए "जिम्मेदार" है। जब आपके पास काम करने की प्रक्रिया का पूरा इतिहास होता है, तो उस पर रिपोर्ट करना आसान होता है।
दूसरे, यह रिपोर्ट
ग्राहकों की उम्मीदों का प्रबंधन करती है। रिपोर्ट में न केवल परियोजना की वर्तमान स्थितियां हैं, बल्कि यथार्थवादी पूर्वानुमान भी हैं। और वे पर्याप्त उम्मीदें बनाते हैं और जोखिम कम करते हैं कि एक दिन हितों का टकराव होगा।
तीसरा, रिपोर्ट
समस्याओं, संभावित परिवर्तनों और जोखिमों
के ग्राहक को सूचित करती है। प्रत्येक सप्ताह की शुरुआत में एक रिपोर्ट लिखी जाती है, जिसका अर्थ है कि ग्राहक के पास समस्या पर निर्णय लेने का समय है, और हमें जल्दी से ठीक करना होगा।
चौथा, रिपोर्ट
आपको क्लाइंट से
प्रतिक्रिया प्राप्त करने की अनुमति देती है । जब ग्राहक सक्रिय और नियमित रूप से परियोजना के जीवन में भाग लेता है, तो यह अधिक संभावना है कि तैयार उत्पाद "उम्मीदों में गिर जाएगा।"
पाँचवें, रिपोर्ट एक
“कवर-अप पेपर” है । हम जानबूझकर उन विशिष्ट लोगों के संदर्भ के बिना रिपोर्ट लिखते हैं जिनके कारण कुछ गलत हुआ (भले ही परियोजना ने वास्तव में उनकी गलती के कारण समस्याएं पैदा की हों)। केवल वर्तमान समस्याएं, संभावित समस्याएं (पूर्वानुमान में) और इन समस्याओं के संभावित समाधान। इस प्रकार, ग्राहक का प्रतिनिधित्व करने वाले प्रबंधक के हाथों में एक दस्तावेज होता है जिसे हमेशा संघर्ष के मामले में संदर्भित किया जा सकता है और ग्राहक को स्वयं समझाया जा सकता है कि समस्या इन विशिष्ट कारणों से उत्पन्न हुई थी।
वैसे, इस तरह के एक अगोचर, लेकिन सुपर-उपयोगी मानव गुणवत्ता है, "समस्याओं की रिपोर्ट करने की क्षमता।" इतना समय नहीं है जब मैंने सहयोगियों के बीच भी इस विषय पर एक सर्वेक्षण किया था। यदि कोई प्रबंधक आपके साथ क्लाइंट की तरफ से काम कर रहा है और बाद में समस्याओं को दूर करने के लिए प्रवृत्त है, तो एक रिपोर्ट उसे इस तरह के विशेषाधिकार से वंचित करने का सबसे खराब तरीका नहीं है।
हम समस्या को निरूपित करते हैं, समाधान पेश करते हैं, ग्राहक पक्ष का जिम्मेदार व्यक्ति रिपोर्ट पर प्रतिक्रिया देता है, समस्या समाप्त हो जाती है। पूरी प्रक्रिया प्रलेखित है, इसलिए जिस स्थिति में रिपोर्ट हमें और ग्राहक के प्रतिनिधि को सुरक्षित करती है।
तो हमारे पास क्या है:
क्या: परियोजना की वर्तमान और भविष्य की स्थिति पर रिपोर्ट।
कौन लिखता है: परियोजना प्रबंधक
कितनी बार: प्रत्येक सोमवार सुबह
यह किसको भेजता है: ग्राहक प्रबंधक के ईमेल पर + मेरे मेल पर कॉपी करें।
बेशक, कुछ समस्याएं थीं। मुख्य कठिनाई रिपोर्ट लिखने के लिए लोगों की कुल नापसंद है। यहां आपको लड़ना है:
- परियोजना प्रबंधक बाद में इस तरह के एक नियमित कार्य को लगातार स्थगित करेंगे।
- हमें केवल अपने ही नहीं, बल्कि क्लाइंट के प्रबंधकों को भी समय पर ढंग से रिपोर्ट पढ़नी होगी और उन्हें जवाब देना होगा।
यदि आप प्रबंधकों की रिपोर्टों के बारे में व्यक्तिगत रूप से सब कुछ "भूलने" के लिए तैयार हैं, तो आप इसे अपने में लागू करने का प्रयास कर सकते हैं। लेकिन मैं छोटी कंपनियों को सलाह नहीं दूंगा।
मैं आपसे ऐसी रिपोर्टों पर अपनी राय व्यक्त करने के लिए कहता हूं। आपकी राय में, वे सामान्य प्रक्रिया के लिए उपयोगी / हानिकारक हैं और क्यों।