हम समर्थन मुद्दों के लिए लेखांकन करते समय वास्तविक रूप से परियोजनाओं की योजना कैसे बना सकते हैं?


13

हमें काम करने में समस्या हो रही है: हम काम को निर्धारित करने की कोशिश कर रहे हैं ताकि हम समय के तराजू का आकलन कर सकें और समय-सीमा प्राप्त कर सकें।

समस्या यह है कि एक परियोजना के लिए योजना बनाना मुश्किल है, बिना सब कुछ जाने।

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

समस्या 3 गुना है:

  1. जब हम प्रोजेक्ट्स को शेड्यूल करते हैं तो समय के पैमाने को अक्षरशः लिया जाता है। यदि हम तीन सप्ताह का अनुमान लगाते हैं, तो समय सीमा तीन सप्ताह के लिए निर्धारित की जाती है, ग्राहक को बताया जाता है, और विस्तार के लिए कोई जगह नहीं है।

  2. अंतरिम काम और इस तरह का मतलब है कि हम परियोजना पर काम करने का उत्पादक समय खो देते हैं।

  3. कभी-कभी क्लाइंट के पास वह समय नहीं होता है जिसे हमें काम करने के लिए लेने की आवश्यकता होती है, इसलिए वे कभी-कभी हमारे पास आते हैं और कहते हैं कि उन्हें महीने के अंत तक एक परियोजना की आवश्यकता होती है, जब हमें लगता है कि काम में दो महीने लगेंगे - उल्लेख नहीं करने के लिए हमारे पास पहले से ही काम है।

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

यह भी पेशेवर नहीं है कि हम ग्राहक को बताई गई डेडलाइन गायब रखें।

अन्य लोग इस प्रकार की स्थिति से कैसे निपटते हैं? आप परियोजनाओं की योजना कैसे प्रबंधित करते हैं? किसी प्रोजेक्ट के दौरान होने वाले गैर-प्रोजेक्ट कार्य के लिए एक प्रोजेक्ट में कितना "अतिरिक्त" समय निर्धारित करते हैं? आप समर्थन मुद्दों और बग और सामान से कैसे निपटते हैं? नियोजन के दौरान जिन चीजों का आप हिसाब नहीं लगा सकते हैं?

अपडेट करें

बहुत अच्छे जवाब के लिए धन्यवाद।


1
लिक्विड प्लानर ( liquidplanner.com ) पर एक नजर । यह आपको एक कार्य के लिए आशावादी और 'यथार्थवादी' कार्य घंटों में प्रवेश करने की अनुमति देता है और अनुमानित रिलीज की तारीख (50%, 90%, 98% सटीकता के साथ) की गणना करता है। और यह बहुत कुछ करता है, इसलिए अगर मैं होता तो मैं एक डेमो की कोशिश करता
jao

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

1
बिंदु 3 के बारे में: अपने ग्राहक को प्रोजेक्ट त्रिकोण समझाएँ : सस्ता, अच्छा, तेज़: कोई भी दो चुनें।
मौविसील

1
Mouviciel - यह सिद्धांत में अच्छा है, लेकिन दुर्भाग्य से व्यवहार में नहीं है। हमारे पास यह पहले से ही है।
थॉमस क्लैसन

3
@ThomasClayson इस तथ्य को नहीं बदलता है कि परियोजना त्रिकोण सत्य है। यदि आपकी कंपनी सरल परियोजना प्रबंधन को नहीं समझती है, तो उसे छोड़ने का समय हो सकता है।
थॉमस ओवेन्स

जवाबों:


14

हालांकि समस्या यह है कि किसी परियोजना के लिए योजना बनाना मुश्किल है, बिना सब कुछ जाने।

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

यह सब अच्छी तरह से और अच्छा कह रही है कि एक परियोजना में 3 सप्ताह लगेंगे,

ऐसा विशिष्ट अनुमान कभी न दें। एक सीमा दें या उस अनुमान से टकराने की संभावना की मात्रा निर्धारित करें। उदाहरण के लिए, मान लें कि "इस परियोजना में 2-5 सप्ताह लगेंगे" या "85% संभावना है कि यह परियोजना 3 सप्ताह में की जाएगी और 95% संभावना है कि यह 4 सप्ताह में किया जाएगा"।

यह भी ग्राहक को यह कहने के लिए पेशेवर नहीं है कि हम एक समय सीमा से चूक गए हैं।

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

कई बार ऐसा होता है कि किसी निर्धारित समय सीमा के भीतर काम पूरा करना संभव नहीं होता है और दुनिया के सभी अनुमानों और समय-निर्धारण से कोई फर्क नहीं पड़ता है।

तो मेरा सवाल ... दूसरे लोग ऐसा कैसे करते हैं? आप परियोजनाओं की योजना कैसे प्रबंधित करते हैं? कितने "अतिरिक्त" समय को आप किसी प्रोजेक्ट में शेड्यूल करते हैं जो कि उस समय के लिए कुछ भी होता है?

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


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

4

मैं सुझाव दूंगा कि स्क्रैम विकास प्रक्रिया विवरण में खुदाई करें। यह focus factorमीट्रिक द्वारा इस तरह की चौकी गतिविधियों को कवर करता है । मूल रूप से आप 2-3 स्प्रिंट / पुनरावृत्तियों पर काम करते हैं और फिर अपनी टीम के फोकस कारक को मापते हैं (और प्रत्येक सदस्य के लिए यह सहायक भी होगा)। इसके बाद आप अधिक सटीक अनुमान दे पाएंगे जो दैनिक गतिविधि को कवर करता है।

इस लेख पर नज़र डालें - "फोकस कारक"

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

यहाँ छवि विवरण दर्ज करें


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

@Thomas ओवेन्स: ओपी सिर्फ एक बार देख ले सकता है और शायद वह कैसे इस या किसी भी तरह कुछ एक दूसरे विचार को मापने के लिए के बारे में अंतर्दृष्टि मिल गया ...
SLL

धन्यवाद मैं निश्चित रूप से इस सब पर एक नज़र डालूंगा। हमें वास्तव में 3 की एक टीम मिली है, लेकिन व्यवहार में हम वैसे भी परियोजनाओं पर काम करते हैं। फोकस कारक तर्क दिलचस्प है। :) धन्यवाद।
थॉमस क्लेसन

1

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

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


हालांकि यह बात है, हमारा रुकावट ऐसा नहीं है। उदाहरण के लिए, इस हफ्ते मुझे एक्स करना चाहिए था लेकिन मैंने अपना 80% समय रुकावटों में बिताया। इस सप्ताह सामान्य से अधिक बैठकें हुई हैं और बहुत अधिक समर्थन मिला है। इसके अलावा, इस सप्ताह में कुछ वेबसाइटों को बनाने के लिए मुझे बनाया गया है और मुझे एक विकास सर्वर स्थापित करना है और बाकी कार्यालय के लिए तकनीकी सहायता प्रदान करनी है। अगले हफ्ते कोई बैठक और कोई समर्थन नहीं हो सकता है। या मुझे राउटर को अपग्रेड करना पड़ सकता है, या लैपटॉप या किसी चीज़ का बैकअप ले सकते हैं। यहां पर बड़ी संख्या में प्रोब हैं।
थॉमस क्लैसन

1
एक हफ्ते या एक दिन में, आप सही कह रहे हैं कि यह अप्रत्याशित है, लेकिन यदि आप महीने या महीने तक इसका ट्रैक रखते हैं, तो आप शायद पाएंगे कि यह विकसित हो गया है। यदि आप वास्तव में सामान्य से अधिक जंगली हैं, तो ईबीएस से विश्वास अंतराल विचार पर एक नज़र डालें। यह ऐतिहासिक संभावनाओं को ध्यान में रखता है जैसे "90% समय, मेरे पास निर्बाध काम का दिन 5 घंटे है, लेकिन अन्य 10% मुझे पूरे दिन कुछ भी नहीं मिलता है।" उस इतिहास से, कठिन तिथियों के बजाय, आपको आउटपुट मिलता है जैसे "हमें एक महीने में 85% मौका मिलेगा, लेकिन 99% संभावना हम 6 सप्ताह में करेंगे।"
कार्ल बेवेलफेल्ट

1

चारों तरफ अच्छी सलाह।

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

उदाहरण के लिए, यदि आपके पास 5 डेवलपर्स हैं, तो सप्ताह के प्रत्येक दिन एक असाइन करें। जब वह दिन आता है, तो असाइन किया गया डेवलपर उस दिन केवल समर्थन पर काम करता है। अगले दिन एक और डेवलपर समर्थन लेता है। इस तरह हर किसी को अपने "प्रवाह" में रहने का मौका मिलता है, हर किसी को डॉगफूड का स्वाद मिलता है।

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


0

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

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

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

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

यह एक फैंसी उपकरण नहीं है, और यह एक आदर्श तरीका नहीं हो सकता है, लेकिन यह आश्चर्यजनक रूप से अच्छी तरह से काम करता है।


0

लोगों आकलन की जरूरत को समझने के लिए कर रही है कि कोई टीम है कभी एक परियोजना पर 100%। आपके पास बीमार अवकाश, अवकाश, ज्यूरी ड्यूटी, शोक अवकाश, आवश्यक एचआर बैठकें (यह लाभ का समय है!), टीम की बैठकें जो परियोजना से संबंधित नहीं हैं, अपरिहार्य विलंब, बाथरूम टूटना, उत्पादन में पहले से मौजूद वस्तुओं पर समर्थन कार्य, ईमेल से निपटना, , पुराने कंप्यूटर के मरने के बाद नए कंप्यूटर को कॉन्फ़िगर करना, भविष्य के काम के बारे में सवालों का जवाब देना और उस काम के लिए अनुमान लगाना, कनिष्ठों का उल्लेख करना, इत्यादि, जिन्हें वास्तव में स्वीकार करना पड़ता है। एक अनुमान लगाने वाले के लिए 8 में से 6 घंटे से अधिक समय लगाना गैर-जिम्मेदाराना है। प्रति दिन उपलब्ध है। यह एक गारंटी है कि समय सीमा पूरी नहीं की जा सकती है। यदि आप गारंटी दे रहे हैं कि समय सीमा पूरी नहीं की जा सकती है, तो आप एक दुखी ग्राहक की गारंटी दे रहे हैं।


0

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

अधिक जानकारी के लिए आप http://www.microsoft.com/project/en/us/schedule-management.aspx पर जा सकते हैं।


-1

ऐसा लगता है कि आपकी परियोजना टीमों से बहुत कुछ छिपा हुआ प्रयास है जिसके माध्यम से आप ध्यान और वेग खो रहे हैं। यह वास्तव में से निपटने के लिए कार्य को अलग करने के लिए benneficial हो सकता है

.. समर्थन मुद्दों और कीड़े और सामान?

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

नियोजन भाग के लिए, मैं थॉमस ओवेन्स के जवाब से पूरी तरह सहमत हूं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.