🛫 🎑 💘 सॉफ्टवेयर विकास परियोजनाओं में मेट्रिक्स 🐎 🧦 🌁

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

मुख्य विचार

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

जोखिम कारक

जोखिम कारक स्वयं जोखिम नहीं हैं। जोखिम की घटना के पीछे ये कारण हैं।
अपनी परियोजना के लिए (एक बाहरी ग्राहक के लिए सूचना प्रणाली विकसित करना), आप निम्नलिखित मुख्य जोखिम कारकों को निर्धारित कर सकते हैं:

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

ये सभी कारक हमेशा संख्यात्मक मैट्रिक्स का आधार नहीं हो सकते हैं। हालाँकि, उन जोखिमों में एक प्रकार के "मामलों की स्थिति के संकेतक" डालना, जिन्हें आप अभी भी निर्धारित नहीं कर सकते हैं, लेकिन गुणात्मक रूप से आकलन कर सकते हैं ("सब कुछ अच्छा / बुरा / भयानक है"), मेरी राय में, चोट नहीं पहुंचेगी।

मुख्य प्रकार के मीट्रिक

सामान्य तौर पर, एक परियोजना के लिए, मुझे निम्न प्रकार के मैट्रिक्स को परिभाषित करना शुरू करना काफी उचित लगता है:

कर्मचारी की टर्नओवर दर
संसाधन उपयोग दर
परियोजना के समय और बजट से संबंधित संकेतक
विकसित उत्पाद की गुणवत्ता का आकलन करने के लिए संकेतक
एकीकृत परियोजना प्रगति संकेतक

सामान्य तौर पर, आप किसी प्रोजेक्ट के लिए मैट्रिक्स का चयन करने के लिए निम्नलिखित दृष्टिकोण का उपयोग कर सकते हैं:

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

परियोजना की स्थिति का विश्लेषण

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

प्रोएक्टिव विश्लेषण

यह समझने के लिए कि आगे क्या समस्याएँ होती हैं और अंत में क्या हो सकता है, हम विश्लेषण के लिए कई आंकड़े तैयार कर सकते हैं:

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

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

डायग्नोस्टिक मेट्रिक्स

मुख्य मीट्रिक इस बात की मदद करने के लिए कि आप क्या कर रहे हैं:

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

सूचीबद्ध मूल्यों में से प्रत्येक को नियमित आधार पर मापा जाता है। आप ग्राफ़ बना सकते हैं, या आप तालिका के रूप में नंबर प्रस्तुत कर सकते हैं।

पूर्वव्यापी मैट्रिक्स

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

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

शायद आज के लिए बस इतना ही।
क्या परियोजना प्रबंधन से सीधे संबंधित मैट्रिक्स पर किसी और के अपने विचार हैं?

सॉफ्टवेयर विकास परियोजनाओं में मेट्रिक्स