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

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

सेलेस्टे समूह के प्रोग्रामर के पास कम से कम कुछ पूर्वानुमान बनाने के लिए पर्याप्त जानकारी नहीं थी, खासकर पूरे तिमाही के लिए।

सेलेस्टे ने बैरी को कबूल करने का फैसला किया और देखा कि वे क्या करने आते हैं। उसने अगले दिन एक नियुक्ति की और डेटा एकत्र किया।

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

वह अपनी मेज के सामने एक आगंतुक कुर्सी पर बैठ गया।

बैरी ने लटकाया और कहा: "ठीक है, चलो परियोजनाओं के समय पर चर्चा करते हैं, है ना?"

सेलेस्टे ने सिर हिलाया और कहा, “हां। ऐसा लगता है कि ऐसी स्थिति में क्या किया जा सकता है। ”

बैरी डूब गया। "ऐसा लगता है?" मुझे विशिष्ट प्रतिबद्धताओं की आवश्यकता है। नहीं "लगता है"! "

सेलेस्टे आराम से बैठे: "बैरी, क्या आपको इन तीन उत्पादों को जारी करने के लिए दबाव डाला जा रहा है?"

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

"लेकिन पिछले महीने, आपने परियोजनाओं के एक पोर्टफोलियो पर चर्चा की," सेलेस्टे ने याद किया। "मुझे लगा कि उत्पाद A सर्वोच्च प्राथमिकता है।"

"यह है," उन्होंने कहा। "और उत्पादों बी और सी भी सर्वोच्च प्राथमिकता है।"

सेलेस्टे ने अपनी आँखें घुमाई: "लेकिन आप जानते हैं कि केवल एक मुख्य प्राथमिकता हो सकती है, है ना?"

"मुझे पता है कि, और आप जानते हैं," उन्होंने कहा। "लेकिन मेरे साथियों को पता नहीं है।" मुझे एक पूर्वानुमान की आवश्यकता है कि आप क्या कर सकते हैं - अच्छी तरह से, दायित्वों - और फिर आप थोड़ी शांति से सांस ले सकते हैं। ”

"सबसे पहले हमें किस उत्पाद पर काम करना चाहिए?"

"उत्पाद ए, ज़ाहिर है," उन्होंने कहा। "वह सबसे अधिक भुगतान किया गया है।"

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

बैरी पीछे झुक गया: “रुको। मैंने डेमो के बारे में समझा। और अन्य दो महीनों के बारे में क्या? और आप उन्हें कोई जानकारी क्यों नहीं देते? "

सेलेस्टे ने कहा: “अगर हमने केवल एक उत्पाद पर काम किया, तो मैं हमारे विकास चक्र के आधार पर रेटिंग की गणना कर सकता हूं। उत्पाद ए के लिए, हम प्रति सप्ताह तीन से चार कहानियां [कस्टम कार्यों के लिए कोड] जारी करते हैं। लेकिन हम उत्पादों B और C के वास्तविक विकास चक्र को नहीं जानते हैं।

बैरी ने सिर हिलाया: "क्यों नहीं?"

"उत्पाद बी और सी की योजना दो और तीन महीनों में है," सेलेस्टे ने कहा। - यह विपणन के लिए बहुत दूर है। समस्या यह है कि काम के आगे, कम "समय" विपणन विभाग कहानियों को स्पष्ट करने के लिए उत्पाद के मालिक के साथ काम करता है। हमें पता नहीं है कि दो और तीन महीनों में किन कार्यों को लागू करने की आवश्यकता होगी। हमें वैज्ञानिक रूप से खरोंच (वैज्ञानिक जंगली गधा अनुमान, SWAG) से आधारित धारणाएं बनानी होंगी। यह सामान्य है, मुझे अपने दोस्तों के साथ ऐसा करना पसंद है, लेकिन हमें और बारीकियों की जरूरत है। जो नहीं है। ”

"तो आप उन्हें कुछ भी क्यों नहीं बताते अगर वे प्रदर्शन पर नहीं आते?" बैरी से पूछा।

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

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

क्या आप चीजों को अलग तरह से करने के लिए लुभाएंगे?

शर्तों का अनुमान - गैर-तुच्छ काम

समय सीमा का अनुमान भी काम है। कई टीमों ने अपने नियमित काम के कार्यक्रम में इस तरह की दिनचर्या रखी। हालांकि, एक सटीक त्रैमासिक अनुमान अक्सर एक घंटे या दो से अधिक काम की आवश्यकता होती है।

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

समस्या यह है कि सॉफ्टवेयर विकास की योजना बनाना सड़क यात्रा की योजना बनाने जैसा नहीं है। यदि आपके शहर में एक से अधिक ट्रैफ़िक लाइट हैं, तो आप ट्रैफ़िक के उतार-चढ़ाव से परिचित हैं। मैं बोस्टन के एक उपनगर में रहता हूं, जहां से हवाई अड्डे की यात्रा में 20 और 90 मिनट लग सकते हैं। सबसे अधिक बार 30 से 45 मिनट तक। 13 किमी की यात्रा के लिए यह एक महत्वपूर्ण बदलाव है।

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

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

एक उचित मूल्यांकन के लिए, हमारे पास कई विकल्प हैं। वास्तव में तीन:

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

प्रबंधक के लिए आपको किस पूर्वानुमान की आवश्यकता है?

मैंने देखा कि प्रबंधकों को अक्सर परिमाण के क्रम के अनुमान की आवश्यकता होती है। इस मामले में, टीम एक पूर्वानुमान बना सकती है और इसे निम्नानुसार रिपोर्ट कर सकती है:

“हम मानते हैं कि इस परियोजना को इस पूर्वानुमान की सटीकता में 50% विश्वास के साथ पांच महीने लगेंगे। हम आठ महीने के मूल्यांकन में 80% आश्वस्त हैं। दस महीने में 90% आत्मविश्वास है। ”

यह प्रबंधकों को यह समझने में मदद करता है कि विश्वास की एक सीमा है। यदि वे 100% निश्चितता चाहते हैं, तो इसमें 14 महीने से अधिक लग सकते हैं।

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

मैं तीन तारीखों की एक श्रृंखला की भी सिफारिश करूंगा: “आशावादी तारीख जनवरी है। सबसे यथार्थवादी फरवरी के अंत है। सबसे निराशावादी अप्रैल के अंत है। "

किसी भी मामले में, एक अस्पष्ट मूल्यांकन कभी न दें। यह सेंट मर्फी (मर्फी के कानून से) को आपकी परियोजना को लेने और गंदा काम करने के लिए प्रेरित करता है।

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

मूल्यांकन के बजाय चक्र समय का उपयोग करें

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

यदि आप शब्दावली से परिचित नहीं हैं:

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

यह विचार कुछ उपयोगी (इतिहास) का उत्पादन करने में लगने वाले औसत समय को समझने के लिए है।

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

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

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

गति का उपयोग क्यों नहीं करते?

आपने देखा है कि मैं प्रोजेक्ट समय का आकलन करने के लिए गति के बजाय चक्र समय और कहानी की गिनती की सलाह देता हूं। क्योंकि गति एक सरोगेट है।

उदाहरण के लिए, मैं फिट रहने के लिए रोज टहलता हूं। मैं अपने रिश्तेदार की गति को ट्रैक करते हुए, हर दिन उसी मार्ग का अनुसरण करता हूं। एक अच्छी धूप के दिन, मैं लगभग 5.6 किमी प्रति घंटे की रफ्तार से चलता हूं। एक बारिश या गर्म और आर्द्र दिन पर, गति 4 किमी / घंटा तक गिर जाती है। बर्फ या बर्फ में मैं बिल्कुल भी बाहर नहीं जा सकता, इस मामले में मेरी गति 0 है।

मैं उसी रास्ते से जा रहा हूं। (हाँ, यह उबाऊ है, लेकिन यह मेरी समस्या है)। हालाँकि मैं एक ही दूरी की यात्रा करता हूं, लेकिन स्थितियों के आधार पर यात्रा अलग-अलग समय लेती है। यहां स्थितियां आपकी टीम के कोड आधार और परीक्षणों के समान हैं।

यदि कहानियाँ काफी छोटी हैं, तो गति चक्र समय से मेल खाती है। लेकिन बहुत बार, प्रबंधक बहुत बड़ी कहानियों के साथ परियोजनाओं का मूल्यांकन करने की कोशिश करते हैं। गिनती आसान होगी: “हम एक चक्र में एक या दो कहानियाँ समाप्त कर सकते हैं। आप कौन सी एक या दो कहानियाँ चुनना चाहते हैं? ”

मूल्यांकन करने से इनकार करना एक धोखा नहीं है

जब बैरी ने सहयोगियों के साथ मुद्दों पर चर्चा की, तो उनमें से एक ने कहा: "समय सीमा का मूल्यांकन करने से इनकार करना एक घोटाला है!"

बैरी ने जवाब दिया: “सच नहीं। आप हमें एक उत्पाद जारी करना चाहते हैं, है ना? "

जवाब था “बेशक। B और C. दोनों ।

"समस्या यह है कि उन्हें बदले में करने की आवश्यकता है," बैरी ने उत्तर दिया। - यदि आपको वास्तव में उत्पाद ए की आवश्यकता है, तो बाकी के लिए पूर्वानुमान बनाने की क्या बात है? हम काम कर सकते हैं और अपनी प्रगति दिखा सकते हैं। जब हमने पर्याप्त काम किया है, हम बी और सी के लिए प्रक्रिया दोहराएंगे। इसके अलावा, आपके पास हमें कहानियां तैयार करने के लिए बी और सी के लिए आवश्यकताओं को स्पष्ट करने का समय होगा। "

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

जानिए आपके मैनेजर को किस ग्रेड की जरूरत है। उसकी जरूरत के अनुसार उसे प्रस्तुत करें। और अगर आपके पास समय कम है, तो काम पर लग जाएं।

आईटी परियोजनाओं का मूल्यांकन: पाठ

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