प्रोजेक्ट डायरी के बारे में कुछ शब्द

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

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

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

मुझे "प्रोजेक्ट डायरी" से क्या मतलब है

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

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

सामान्य तौर पर, यह देखा जा सकता है कि अधिकांश प्रविष्टियां उनके प्रभावों के बारे में टिप्पणियों के साथ मेरे निर्णयों का विवरण हैं। और यह स्पष्ट है कि अधिकांश निर्णय गलत हैं।

रिकॉर्ड संरचना

प्रत्येक प्रविष्टि में चार कॉलम होते हैं: तिथि, विवरण, श्रेणी और निष्कर्ष।

विवरण - यह एक विस्तारित पाठ है, जहां कई वाक्य इस तथ्य का वर्णन करते हैं कि परियोजना के दौरान उत्पन्न हुई। पिछले अनुभाग में विवरण के उदाहरण दिए गए हैं।

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

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

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

निष्कर्ष - मेरी राय में, सबसे महत्वपूर्ण स्तंभ। यहाँ मैं इस बात का पूरा-पूरा वर्णन करने की कोशिश कर रहा हूँ कि इस घटना के परिणाम क्या हो सकते हैं, और इससे मुझे क्या निष्कर्ष निकालने की जरूरत है। यह, ज़ाहिर है, सबसे मुश्किल है।

सामान्य तौर पर, निष्कर्ष सबसे सरल और स्पष्ट हो सकता है, उदाहरण के लिए, "आपको संस्करण नियंत्रण प्रणाली में दस्तावेजों को संग्रहीत करने की आवश्यकता है"

लेखक का ध्यान दें: यह प्रविष्टि गलती से फ़ाइल को पुनरावृत्ति के अनुमान के साथ ओवरराइट करने के बाद दिखाई दी और उन्हें आधे दिन के लिए पुनर्स्थापित करना पड़ा ।

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

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

निष्कर्ष में कुछ शब्द

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

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