मैं, टीम लीडर, परियोजनाओं का मूल्यांकन कैसे करूँ?

टाइमलाइड अक्सर परियोजनाओं को महत्व देते हैं, और हर कोई इसे अच्छी तरह से नहीं करता है। यहां बहुत कुछ टीम के नेता के व्यक्तित्व पर निर्भर करता है, साथ ही टीम की उनकी समझ पर भी। PERT की “सादृश्य” पद्धति से परियोजनाओं के मूल्यांकन के लिए कई तकनीकें हैं। लेकिन आज मैं इस बारे में बात करूंगा कि कैसे मैं अधिक सटीक और अधिक लाभ के साथ मूल्यांकन करने के लिए नियोजन पोकर और अन्य तकनीकों का उपयोग करता हूं।




विशिष्ट दृष्टिकोणों के बारे में बात करने से पहले, प्रक्रिया की मुख्य कठिनाइयों पर ध्यान देना उचित है।

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

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

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

तथाकथित नियोजन पोकर इस समस्या को दरकिनार करने में मदद करता है, जब पूरी टीम मूल्यांकन में भाग लेती है, न कि यह जानने के लिए कि कार्य कौन होगा, और वे इसे आँख बंद करके मूल्यांकन करते हैं, यह देखते हुए कि सहकर्मी क्या पेशकश कर रहे हैं।


लेखक: इंग्लिश विकिपीडिया से Hkniberg - en.wikipedia से विकिमीडिया कॉमन्स पर स्थानांतरित। सार्वजनिक डोमेन हर कोई

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

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

गलतियों से बचने के कुछ उपाय

मूल्यांकन में त्रुटि को कम करने के लिए, मैं कुछ सरल नियमों का पालन करता हूं।

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

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

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

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

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

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

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


चित्र: माइकल डबकोव @ मध्यम

कार्य के लिए कोई 40 घंटे का मूल्यांकन नहीं हो सकता है।यह पिछले नियम का एक और बदलाव है। एजाइल एक परियोजना को 20 घंटे से अधिक नहीं के कार्यों में विघटित करने की सिफारिश करता है। एक सप्ताह के काम के लिए अविभाज्य कार्य नहीं होने चाहिए। छोटे हिस्से में, अनुमान बहुत अधिक सटीक है।

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

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

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

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

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

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

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

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

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

मैं केवल घंटों में तारीखों को नाम देता हूं - दिनों या महीनों में नहीं।बहुत से लोग सोचते हैं कि यदि परियोजना 96 घंटे का अनुमानित है, तो यह 8 दिनों के लिए 12 दिनों में पूरा हो जाएगा, बशर्ते कि केवल एक व्यक्ति इसके लिए काम करता है। 6 दिनों की रेटिंग का नामकरण करते हुए, स्थिति को दो डेवलपर्स के लिए आसानी से एक्सट्रपलेशन किया जाता है। पर ये सच नहीं है। ऐसे कई कार्य हैं जो एक दूसरे पर निर्भर हैं। सबसे पहले, डेवलपर्स तब तक काम करना शुरू नहीं कर सकते हैं जब तक कि सभी विधानसभा प्रणालियों और स्टैंडों के साथ एक प्रोजेक्ट टेम्पलेट नहीं बनाया गया है (और यह क्लाइंट की इच्छाओं को ध्यान में रखते हुए 2-3 दिन बनाया गया है)। दूसरे, नियोजन के लिए कॉल आने पर सब कुछ बंद हो जाता है। तीसरा, अवरुद्ध अवरोधक हैं जो आपको आगे बढ़ने से रोकते हैं। दूसरे शब्दों में, कार्यस्थल पर 96 घंटे का मतलब यह बिल्कुल नहीं है कि 100% समय (दिन में 8 घंटे) विशेष रूप से इन कार्यों के लिए समर्पित होगा। दिनों में मूल्यांकन के लिए, हम मान सकते हैं कि डेवलपर के पास 8 नहीं हैं, लेकिन, आइए हम बताते हैं,प्रति दिन 6 घंटे काम (अभ्यास से सटीक आंकड़ा निर्धारित किया जाना चाहिए)।

मैं हमेशा डेवलपर्स से पूछता हूं कि कंप्यूटर से कितने घंटे का काम लगेगा (और "कितने समय बाद यह तैयार होगा")। यह पिछले पैराग्राफ का परिणाम है। मूल्यांकन के भाग के रूप में टीम के साथ बातचीत करना, प्रश्न को सही ढंग से तैयार करना महत्वपूर्ण है।

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

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

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

मैं इस प्रक्रिया में अन्य प्रतिभागियों को भ्रमित न करने के लिए अतिरिक्त कारकों का परिचय नहीं देता।मैं अक्सर लोगों को देखता हूं, टीम के स्तर पर एक आकलन करता हूं, इसमें सौदेबाजी के लिए समय देता हूं। लेकिन मूल्यांकन इकाई को यह स्टॉक नहीं रखना चाहिए या अन्य बाहरी चीजों को ध्यान में नहीं रखना चाहिए। और यह पता चलता है कि डेवलपर ने 8 बजे काम का मूल्यांकन किया, लेकिन फिदेल के लिए 2 से गुणा किया। टीम के लिए अनुकूल करते हुए टिमलीड ने अपनी रेटिंग को फिर से दोगुना कर दिया। और 32 घंटों के प्रबंधक ने ग्राहक के लिए 40 (यहां तक ​​कि खाते के लिए या सिर्फ सौदेबाजी के लक्ष्य के साथ 30 घंटे के लिए) बनाया। यह कॉफी के मैदानों पर बताने जैसा सौभाग्य है। हां, और क्लाइंट, 8-घंटे के कार्य के लिए 40 घंटे का अनुमान देखकर तय करेगा कि टीम को पता नहीं है कि कैसे।

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

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

इस सबके बावजूद, मैं बदलाव के लिए मूल्यांकन के लिए तैयार हूं। यह सामान्य है - परियोजनाएं जीना, विकास करना। किसी भी मूल्यांकन का गठन, मैं समझता हूं कि यह इस विशेष समय में परियोजना की एक विशेषता है।

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

लेख के लेखक: यूजीन वेटज़ेल ( @imater )

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