2009-10-01 20 views
6

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

मुझे लगता है कि सबसे अच्छा सवाल यह है कि हम कैसे आकलन करते हैं कि दिन-दर-दिन, एक परियोजना प्रबंधक कितना व्यस्त है?

+2

क्या आपके पास वर्तमान में एक प्रोग्रामर कितना व्यस्त है यह आकलन करने के लिए एक पद्धति है? – ChrisW

+0

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

+0

यह एक मीट्रिक है जो प्रोग्रामर के डिलिवरेबल्स को प्रमाणित करता है, वह "व्यस्त" कैसे है (यानी उसके समय का किस प्रतिशत पर कब्जा कर लिया जाता है) के लिए एक मीट्रिक नहीं है। – ChrisW

उत्तर

5

याद रखें कि ANY metrics you can come up with is most likely going to be gamed

[क्या मुझे जोएल ऑन सॉफ्टवेयर पर विषय-वस्तु लिंक के लिए बैज मिलता है? :)]

कहा करने के बाद, आप निम्न तरीकों में से एक संघ की कोशिश कर सकते हैं:

  • डेवलपर प्रतिक्रिया !!! (उदाहरण के लिए एक अच्छा पीएम का फीडबैक होगा "मुझे एक्स, वाई और जेड की समस्या थी और उन्होंने उन्हें गायब कर दिया")। पीएम कितना व्यस्त है, यह मापने के लिए इतना अच्छा नहीं है कि यह मापने के लिए वास्तव में अच्छा है कि वह कितना प्रभावी है।

  • मात्रा और परियोजना की योजना (आसानी से gamed) प्रोजेक्ट प्लान (आसानी से gamed) बैठकों के

  • राशि के परिवर्तन की

  • दर/समय (आसानी से gamed) बैठक

  • का दर्जा दिया स्पष्टता

    परियोजनाओं की सफलता दर (समयबद्धता बनाम सुविधाओं की बनाम% ग्राहक संतुष्टि बनाम)। परियोजनाओं में इसे सामान्य बनाने के लिए आसानी से तैयार नहीं किया गया लेकिन शैतान का अपना काम।

+0

आप "प्राचीन ट्राइफल" से जुड़ने के लिए कम से कम एक टिप्पणी के लायक हैं, जो "इसकी समाप्ति तिथि अच्छी तरह से" है। – ChrisW

+1

दोनों लेख और रॉबर्ट डी। ऑस्टिन पुस्तक आज के दिन जितनी दिन लिखी गई थी उतनी प्रासंगिक हैं। – richj

2

Timesheets एक अर्थ में काम के राशि मापेंगे (जैसा कि आप देख सकते हैं कि कैसे अपने दिन नीचे और इतने पर टूट जाता है), लेकिन मैं समझ आप चाहते हैं में सोच भी नहीं।

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

मुझे लगता है कि आखिरकार आपको "व्यस्त-नस्ल" की बजाय परियोजना की सफलता को मापना चाहिए। आखिरकार, आप परवाह क्यों करते हैं कि पीएम कितनी व्यस्त है अगर वे सफल परियोजनाएं प्रदान करते हैं?

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

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

आखिरकार, क्या आप मापते हैं कि सीईओ "व्यस्त" कैसे है? या क्या उसने सिर्फ कंपनी के लाभ पर फैसला किया है?

ऐसा करने के लिए:

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

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

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

लेकिन यह बहुत से कंपनी संस्कृति पर निर्भर करता है। कुछ संगठनों के लिए महत्वपूर्ण बात बिलकुल घंटे होगी, अन्य डेवलपर संतुष्टि मिश्रण का हिस्सा होगी।

1

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

  • टीम समान नहीं है ( शिक्षण नए आदमी रस्सियों लेता है समय)
  • कल्पना सिर्फ एक छोटा सा भिन्न हो सकता है (और है कि छोटा सा काम का बोझ दोगुना हो सकता है)
  • यहां तक ​​कि मौसम परिणाम
  • और इतने पर और आगे
को प्रभावित कर सकते हैं

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

+1

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

0

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

0

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

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

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

प्रबंधक राजनीतिक और मनोवैज्ञानिक जानवर होते हैं। किसी भी पद्धति जो इसे ध्यान में नहीं लेती है वह वास्तविकता को अनदेखा कर रही है, इसलिए इस समस्या के लिए एक अच्छी पद्धति कठिन संख्याओं के मुकाबले मनाए गए व्यवहारों पर अधिक आधारित होने की संभावना है।

0

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

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

उदाहरण के लिए, एक स्क्रम मास्टर "The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent" है। असल में एक कोच और एक सुविधा है। स्क्रैम प्रथाओं का पालन करने के लिए वार्ता या दृढ़ संकल्प द्वारा प्रबंधन के उच्च स्तर द्वारा बनाए गए विघटनकारी अनुरोध या विचलन को अवरुद्ध करना आमतौर पर स्क्रम मास्टर्स द्वारा उपयोग किए जाने वाले कौशल में से एक है। इन सॉफ्ट सॉफ्ट कौशलों में से कई को "काम" के रूप में मापना मुश्किल होता है क्योंकि उनमें कंप्यूटर पर काम करने या रिपोर्ट बनाने में शामिल नहीं है।

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