प्रोजेक्ट को समय पर कैसे पूरा करें?

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

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

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

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

हम सभी जानते थे कि लोग मूल्यांकन करना नहीं जानते हैं। हम यह भी जानते थे कि पिछली परियोजनाओं पर हमारी विकास टीम के अधिकांश मूल्यांकन वास्तविकता से छह महीने तक के हैं।

हमने एक ऐसे वातावरण में एक बहुत बड़ी परियोजना पर प्रयास करने का फैसला किया, जहां झरने का पंथ शासन करता है, लचीला मूल्यांकन तकनीक, और देखें कि यह क्या हुआ। आखिरकार, परियोजना के समय में 14 महीने की भिन्नता से भी बदतर, अब नहीं हो सकता है।

गुणवत्ता मूल्यांकन में हमेशा बहुत समय लगता है

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

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

यही हमने किया। हमने टैल्मड को संदर्भ की शर्तों के साथ फेंक दिया, जिसने उत्पाद घटकों के परिदृश्यों का वर्णन किया, और आवश्यकताओं और उनके मूल्यांकन के डिजाइन के लिए टीम के साथ बैठ गए। हमने क्या प्रयास किया?

उपयोगकर्ता कहानी मानचित्रण

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

एक सिस्टम प्रशासक के रूप में, मैं संगठन के काम के घंटों को संपादित कर सकता हूं ताकि सिस्टम के उपयोगकर्ताओं को कंपनी की वर्तमान अनुसूची के बारे में पता चले

स्वीकृति मानदंड
मैं संगठन के कार्य दिवसों को इंगित कर सकता हूं।
मैं संगठन के प्रत्येक कार्य दिवस के कार्य समय का संकेत दे सकता हूं।
मैं प्रत्येक कार्य दिवस के अंदर विराम का संकेत दे सकता हूं।

परीक्षण
संगठन कार्य दिवसों का सफल संपादन
संगठन के व्यावसायिक घंटों का सफल संपादन
संगठन के व्यावसायिक घंटों का असफल संपादन
सफल ब्रेक संपादन

हैंडलिंग में त्रुटि
सर्वर को खाली फ़ील्ड भेजने का प्रयास करें
सर्वर पर डेटा भेजते समय नेटवर्क का अभाव
गुम प्रतिक्रिया या सर्वर त्रुटि

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

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

प्रभाव मानचित्रण

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

सापेक्ष अनुमान और फोकस कारक

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

शुरू करने के लिए, हमें एहसास हुआ कि सबसे अच्छी स्थिति में, हमारी टीम सप्ताह में 30 घंटे काम करती है - लगभग 10 घंटे बिताए जाते हैं मध्यवर्ती योजना, बैठकों, एक दूसरे के साथ संचार और किसी भी अनियोजित गतिविधियों पर।

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

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

पूर्वव्यापी मूल्यांकन

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

परिणाम

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

मूल्यांकन पर काम करने की प्रक्रिया में, हमने यह भी पाया कि हमारे संगठन में झरने के लिए हमें एक गंभीर झटका लगा था, और यह समझने के लिए एक अच्छा बोनस है कि हमारी परियोजना कब पूरी होगी।

सामग्री का इस्तेमाल किया

डॉ क्रिस्टोफ़ स्टिंडल, आईबीएम - एजाइल प्रोजेक्ट्स में अनुमान

टॉम डेमारको और टिमोथी लिस्टर - सभी बिना किसी अपवाद के काम करते हैं

मेरे शानदार सहयोगियों का सामूहिक ज्ञान

PS सबसे महत्वपूर्ण सलाह मूल्यांकन के दौरान अपने प्रतिभागियों से लैपटॉप लेने की है, वे समूह की गतिशीलता को मारते हैं। सभी को रंगीन पेपर, पेन और मार्कर सौंपें, बड़े बोर्ड के पास समूह दें, अपने उत्पाद से प्यार करें, और आप सफल होंगे।