प्रोजेक्ट मैनेजर जो हस्ताक्षरित अनुबंध के साथ समय के अनुमान में लॉक करना चाहता है


113

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

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

हां, मैंने ज्यादातर डेडलाइन गायब कर दीं। और मैं कुछ बहुत नई तकनीकों पर काम कर रहा था जो पूरी विकास टीम पर कोई और नहीं कर सकता था क्योंकि वे इससे परिचित नहीं थे। कम से कम आसानी से तो नहीं।

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

मेरा मानना ​​है कि आगे जो हुआ वह यह था कि अन्य प्रोजेक्ट मैनेजर और / या प्रोजेक्ट लीड ने मेरा बचाव किया और ऐसा नहीं होने दिया।

मेरा सवाल यह है कि क्या इससे प्रबंधक के बारे में लाल झंडा उठ सकता है? क्या किसी प्रबंधक के लिए किसी हस्ताक्षरित अनुबंध के साथ सॉफ़्टवेयर डेवलपर के लॉक-इन टाइम अनुमानों के लिए यह आम बात है? या इस मामले में, प्रयास करें।

कृपया ध्यान दें, मैं एक पूर्णकालिक कर्मचारी था, स्वतंत्र सलाहकार नहीं।

अद्यतन : मैं जोड़ना चाहता हूं कि मैंने साप्ताहिक रूप से नए अनुमान दिए थे, लेकिन ऐसा लगता है कि मूल अनुमान और वितरण की तारीखें पीएम पर तय की गई थीं।


145
भाग जाओ! फ्ली
निफ़ले

36
एक सवाल पूछने के लिए +1 जो लगभग हर प्रोग्रामर के लिए प्रासंगिक होता है । हम में से अधिकांश इस स्थिति में लंबे समय से पहले पकड़े गए थे जब हम अनुभवी थे और इसे सही ढंग से संभालने के लिए पर्याप्त बुद्धिमान थे।
एडम क्रॉसलैंड

13
लगता है कि आपको अपने प्रारंभिक अनुमानों को गैर-तुच्छ संख्या के साथ गुणा करना होगा ताकि समय पर इसे सुनिश्चित किया जा सके।

18
आपको प्रोजेक्ट मैनेजमेंट के चेप्स लॉ की आवश्यकता है - अनुमान को दोगुना करें और समय की अगली इकाई तक गोल करें - 1 घंटा 2 दिन का हो जाता है।
जका

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

जवाबों:


109

मेरा सवाल यह है कि क्या इससे प्रबंधक के बारे में लाल झंडा उठ सकता है?

जी हां । इसका मतलब है कि यह आपके लिए अपना रिज्यूम / सीवी प्राप्त करने और नई नौकरी की तलाश करने का समय है। या इसका मतलब है कि आपका प्रबंधक आपके साथ कुछ बहुत ही बुरा खेल खेलना शुरू करने वाला है ।

क्या किसी प्रबंधक के लिए किसी हस्ताक्षरित अनुबंध के साथ सॉफ़्टवेयर डेवलपर के लॉक-इन टाइम अनुमानों के लिए यह आम बात है?

मैंने कभी इस बारे में नहीं सुना कि किसी कर्मचारी पर लागू किया जाए।

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

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


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

160

हाँ, कि पूरी तरह से अलार्म की घंटी बजनी चाहिए।

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


58
+1, मैं एक ही बात सोच रहा था कि अनुबंध में आवश्यकताओं को जमे हुए होना चाहिए। यह बेतुकेपन को दर्शाता है।
जेरेमी हेइलर

22
ध्यान दें कि जमे हुए आवश्यकता के साथ, अनुमान अभी भी एक अनुमानित संख्या है जो समय-समय पर बदल सकती है।
कोडिज्म

4
फ़ीचर रेंगना केवल एक संभावित जोखिम है जो शेड्यूल को प्रभावित करता है। मैं शर्त लगा सकता हूं कि 100% संभावना है कि एक कार्यक्रम की गारंटी देने के लिए लॉकिंग आवश्यकताएं पर्याप्त नहीं हैं।
पेमदास

7
@ पेमदास काउंटर-कॉन्ट्रैक्ट की बात वास्तव में युक्ति को लॉक करने के लिए नहीं है; यह पीएम को बैकफुट पर लाने के लिए है।
चिरसायकॉक

6
मैं सिर्फ यह कह रहा हूं ... आवश्यकताओं पर ताला लगाना पर्याप्त नहीं है।
पेमदास

59

वैसे यह सरल है। बस अपने प्रबंधक को बताएं कि जब आप लॉक-इन विनिर्देश पर हस्ताक्षर करेंगे, तो आप अपने समय के अनुमान में लॉक-इन पर हस्ताक्षर करेंगे। क्योंकि आप निश्चित रूप से किसी ऐसी चीज के लिए कोई अनुमान प्रदान नहीं कर सकते हैं जो अज्ञात है। पूर्ण परियोजना कल्पना शुरू होने से पहले, कोई बदलाव नहीं - और आप इसे समय में पूरा कर सकते हैं :)

युक्ति में एक परिवर्तन => अनुबंध शून्य है। संभवतः आपके पहले दिन 10 मिनट के बाद ही बात शून्य हो जाएगी :)


12
+1, लेकिन याद रखें कि लॉक किए गए विनिर्देश चरण 1 और लॉक किए गए अनुमान चरण 4 हैं। चरण 2 निश्चित रूप से प्रत्येक क्षेत्र और जोखिम का एक कार्यशील प्रोटोटाइप है, और चरण 3 एक पूर्ण और विस्तृत अनुमान प्रक्रिया (मान्यता प्राप्त तकनीकी और डोमेन विशेषज्ञों द्वारा बाहरी सहकर्मी समीक्षा सहित) बेशक)। "डी-रिस्किंग" महंगा है ...
रिचर्ड

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

समस्या यह है कि किसी भी (यहां तक ​​कि लॉक इन) युक्ति को दिए गए एक विस्तृत पर्याप्त अनुमान बनाने के लिए आवश्यक समय गैर-तुच्छ है। वास्तव में, वास्तव में सटीक होने के लिए आपको सबसे पहले काम करने की आवश्यकता होती है। सॉफ्टवेयर एक डिजाइन परियोजना है, न कि एक निर्माण परियोजना। आपको डिजाइन करने की आवश्यकता है क्योंकि आपने इसे पहले नहीं किया है। जब आप जानते हैं कि क्या करने की आवश्यकता है, तो डिजाइन किया जाता है। उस बिंदु पर हम सिर्फ प्रेस करते हैं Compile
स्कॉट व्हिटलॉक

7
+1 पानी पर चलना और कल्पना के आधार पर सॉफ्टवेयर लिखना संभव है, बशर्ते दोनों जमे हुए हों :)
जेस्क प्रुशिया

31

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

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


3
"मेरी राय में यह पर्याप्त नहीं है।" - मुझे नहीं लगता कि यह होना चाहिए था। मुझे लगता है कि हम सभी उम्मीद करते हैं कि कोई भी संन्यासी प्रबंधक इस तरह के अनुबंध पर हस्ताक्षर नहीं करेगा।
कोनराड रुडोल्फ

13
कोई भी प्रबंधक ऐसा प्रस्ताव नहीं देगा कि उनके डेवलपर शेड्यूल अनुबंध पर हस्ताक्षर करें।
पेमदास

1
हालांकि यह एक अलग तरह का पागलपन है। एक अनुबंध-बंद समय अनुमान की आवश्यकता बेवकूफी है, लेकिन एक बचत-मेरी-गधा प्रकार में। एक अनुबंध पर हस्ताक्षर करना जो किसी भी भविष्य के स्क्रू-अप के लिए प्रबंधक को जिम्मेदार ठहराता है, इसके विपरीत है।
कोनराड रुडोल्फ

1
+1 उत्तम उत्तर। जोखिम प्रबंधन प्रबंधक का काम है। उसे अक्सर जाँच करनी चाहिए कि चीजें कैसे चल रही हैं, और स्टिकिंग पॉइंट्स पर मदद की पेशकश की जा रही है, और उसे अंत में एक उदार बफर होना चाहिए जो वह आवश्यक रूप से खोले। (और अनुबंध की बात वैसे भी मूर्खतापूर्ण है; प्रबंधक दो या तीन प्रोग्रामर के माध्यम से चलता है जो अनुबंध पर डिब्बाबंद हो जाते हैं, यह स्पष्ट हो जाएगा कि प्रोग्रामर समस्या नहीं हैं।)
Kyralessa

27

यह लाल झंडा नहीं है, यह हथियार-श्रेणी की मूर्खता है।

यदि अनुमान और समय सीमा लगातार उड़ा दी जाती है, तो तर्कसंगत बात यह है कि कारणों की पहचान करें और प्रक्रियाओं में सुधार करें।

यदि आप घोड़े को दोष देते हैं और लात मारते हैं क्योंकि आपको नहीं पता कि आप कहां जा रहे हैं, तो आश्चर्य न करें यदि घोड़ा आपको काटता है और भाग जाता है!


19

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

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

एक और अभ्यास बड़े कार्य को छोटी और अधिक अनुमानित इकाइयों में तोड़ना है। यह अभ्यास आपको बेहतर तरीके से समझने में मदद करेगा कि आपको क्या करने की आवश्यकता है। स्टीव मैककॉनेल के सॉफ्टवेयर अनुमान और स्टीफन विठ्ठल की सॉफ़्टवेयर आवश्यकताएँ पैटर्न को क्रमशः कार्यों को तोड़ने और छिपी आवश्यकताओं की खोज करने के सुझावों के लिए देखें।

एक अनुमान पर कूल्हे से गोली मत चलाना। इसे तोड़ने के लिए समय निकालें। बड़ी संख्या में छोटे कार्यों का अनुमान लगाने से आपको एक बेहतर समग्र अनुमान मिलेगा (औसत के कानून के कारण आपके कुछ अनुमान नीचे होंगे लेकिन कुछ खत्म हो जाएंगे और वे बड़े कार्य के लिए एक दूसरे को तौलना करेंगे)।


5
मुझे "मुझे नहीं पता" कहने में कोई समस्या नहीं है। समस्या यह है कि यह एक संख्या नहीं है जिसे प्रोजेक्ट / संसाधन विश्लेषण के लिए पीएम की स्प्रेडशीट में रखा जा सकता है या वे स्प्रेडशीट के साथ जो कुछ भी करते हैं।
spong

मैंने कुछ और सुझाव देने के लिए अपने उत्तर को अपडेट किया।
माइकल ब्राउन

1
माइक ब्राउन के लिए +1। जब मैंने शुरू किया तो मुझे कहना है कि मैं बहुत आशावादी था, एक दिन मैंने असली सौदा प्रकट करने का फैसला किया है: मुझे नहीं पता। मेरे मामले में समस्या प्रौद्योगिकी नहीं बल्कि इसके पीछे की अवधारणा थी। (एक विशिष्ट एल्गोरिथ्म के लिए C ++ और जावा से प्रोलॉग तक)
dierre

14

अपने "प्रोजेक्ट मैनेजर" से पूछें: क्या हम सॉफ्टवेयर या डेडलाइन बेच रहे हैं?


3
हाय थॉमस, प्रोग्रामर में आपका स्वागत है। आपने इस प्रश्न के अन्य उत्तरों की लंबाई पर ध्यान दिया होगा: यहां, हम मानते हैं कि एक अच्छा प्रश्न उपयोगकर्ताओं को स्पष्टीकरण देने के लिए आमंत्रित करता है जो स्पष्टीकरण देते हैं ( अधिक जानकारी के लिए FAQ देखें)। क्या आप अधिक विवरण प्रदान कर सकते हैं?

7
यार शीर्ष उत्तर केवल 3 लाइनें लंबी है क्या समस्या है ... मुझे यह उत्तर पसंद आया।
कोई नहीं

खैर वास्तव में दोनों। सॉफ्टवेयर जो बेचा जाता है वह राजस्व में लाता है। अभी भी विकास के तहत सॉफ्टवेयर का कोई राजस्व नहीं है (# 1 मारा); अभी भी डेवलपर के लिए पैसे खर्च होते हैं (# 2 मारा); और अगली बात नहीं करने का अवसर लागत है (# 3 मारा)। तो यह एक समय पर s / w की कोशिश करने और वितरित करने के लिए उचित है। क्या अनुसूची वास्तविक है एक अलग मामला है!
जल्‍दी से जल्‍दी_जूल

10

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

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

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

बैठक में, आप जो काम कर रहे हैं, उसके तकनीकी विवरणों पर जाएं और इसके लिए समय क्यों लगता है। उन्हें यह जानना चाहिए (और वे इसे पूरा करने में आपकी मदद कैसे कर सकते हैं), लेकिन दुख की बात यह है कि आम तौर पर ऐसा नहीं होता है ... आपको शायद 10 मिनट मिलेंगे इससे पहले कि उनकी आंखें वापस उनके सिर में आती हैं। अब मैं यहाँ क्या करना चाहता हूँ शायद कानूनी नहीं है ... हाँ, मैंने जाँच की, यह वास्तव में बहुत अवैध है और आप उस समय तक जेल नहीं जाना चाहते हैं। बिंदु यह है कि आपने सक्रिय होने के लिए एक सर्वोत्तम प्रयास किया है और यदि आपको कुछ उच्च-अप मौजूद हैं, तो आपका दर्द अब उनका है ... जैसा कि यह होना चाहिए। आपको अपने निर्णय का उपयोग करना होगा कि कैसे चीजें खेलने की संभावना है, क्योंकि 'वृद्धि' क्या होती है। यदि आप जिस स्थान पर हैं, वहां नेतृत्व आधा सभ्य है तो वे सही काम करेंगे, और तुम्हारे द्वारा भी सही काम करो। यदि नहीं, तो आप बाजार में अपना रिज्यूमे पहले ही दे चुके होंगे ... आप वैसे भी पहले अवसर पर जाने वाले थे (और लगता है कि आपने अंततः ऐसा किया)। नेतृत्व दो समूहों में गिर जाएगा - या तो वे तकनीकी रूप से समझदार हैं और वे तुरंत आपकी बात देखेंगे; या वे नहीं हैं और वे मुस्कराहट के अलावा इसके बारे में क्या करने जा रहे हैं और इसे सहन कर रहे हैं? यदि वे ऐसा कर सकते हैं जो आप करते हैं, तो वे पहले से ही ऐसा कर रहे होंगे। t और वे मुस्कराहट के अलावा इसके बारे में क्या करने जा रहे हैं और इसे सहन कर रहे हैं? यदि वे ऐसा कर सकते हैं जो आप करते हैं, तो वे पहले से ही ऐसा कर रहे होंगे। t और वे मुस्कराहट के अलावा इसके बारे में क्या करने जा रहे हैं और इसे सहन कर रहे हैं? यदि वे ऐसा कर सकते हैं जो आप करते हैं, तो वे पहले से ही ऐसा कर रहे होंगे।

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

इससे पहले कि मैं साइन-ऑफ करूं: बदलते दायरे / आवश्यकताएं - फुर्तीली पद्धति को अपनाने का एक सबसे अच्छा कारण है, इसलिए ग्राहक / हितधारक अपने मन को बदलने के लिए ठीक से जवाबदेह हैं कि वे क्या चाहते हैं ...

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


2
आपको मुख्य विचारों को बोल्ड करने के लिए सीखने की जरूरत है, न कि जब आप स्क्रीन पर चिल्लाते हैं। पोस्ट को स्कैन करना और सामान्य विचार प्राप्त करना कठिन है।
नाम

1
+1 के लिए "पीएम सबसे अधिक संभावना है कि आप दु: ख दे रहे हैं, क्योंकि किसी और ने खाद्य श्रृंखला को आगे बढ़ाते हुए उन्हें दु: ख दिया है"। एक प्रबंधक की नौकरी का एक हिस्सा आपको उससे अलग करने के लिए एक छतरी होना है - लेकिन यहां तक ​​कि महान प्रबंधकों के पास भी छतरियां हैं यदि बारिश कठिन और पर्याप्त तेजी से गिरती है।
बॉब मर्फी

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

2
इसके अलावा, अधिक चरवाहे की जरूरत है।
ओसोडो

1
इस भड़काऊ टिप्पणी को अधिक क्यों नहीं उतारा गया? पढ़ते ही मेरी नाक से दूध निकल आया!
मगग

9

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

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


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

@sunpech: मैंने ऐसी पागल चीज के बारे में कभी नहीं सुना।
फ्रस्ट्रेटेडविथफॉर्म्सडिजेनर 20

8

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

उस ने कहा, मैं अन्य उत्तरों से सहमत हूं। इसके अलावा, यदि आप पहले से ही ऐसा नहीं करते हैं, तो आप अपना रिज्यूम अपडेट कर सकते हैं।


4

अन्य सभी उत्तरदाताओं की तरह, मैं इस बात पर अधिक सहमत नहीं हो सका कि यह एक लाल झंडा उठाए।

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

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

इसका कारण यह अहसास है, जो कि एजाइल और लीन सॉफ्टवेयर गुरुओं में से कई के बारे में बात करते हैं, यह सॉफ़्टवेयर एक निश्चित योग्य इकाई नहीं है, लेकिन यह ज्यादातर खोज की एक प्रक्रिया है।

कई लोगों को अभी भी इस धारणा से परेशानी है, और ऐसा लगता है कि आपके पीएम ने भी ऐसा किया है। यह ट्रेड-ऑफ की सरल समझ में आता है।

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

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

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

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

Agile Manifesto: http://agilemanifesto.org/ पर नज़र डालिए, यह आपके साथ प्रतिध्वनित हो सकता है। पढ़ने के लिए एक अच्छी किताब मैरी पॉप्पेंडिएक का "लीन सॉफ्टवेयर डेवलपमेंट" भी है

सौभाग्य।


4

लगता है जैसे प्रबंधक किसी को दोष देने की तलाश में है जब वह अपने श्रेष्ठ को रिपोर्ट करता है।

मुझे लगता है कि यदि आपके पास एक अनुचित प्रबंधक है जो सोचता है कि एक 'अनुमान' एक 'निश्चित अवधि' के समान है, तो सबसे अच्छी बात यह है कि एक बहुत ही उदार अनुमान अवधि के बारे में सोचें और फिर इसे दोगुना करें!

इसके अलावा, प्रबंधक को यह सुनिश्चित करने के लिए मजबूर करें कि आवश्यकताओं को पूरी तरह से विस्तृत और तय किया गया है। तब से कोई भी परिवर्तन नए पूर्ण समय के परियोजना प्रबंधक के साथ 'औपचारिक पुनर्निधारण' के बिना संबोधित नहीं किया जाएगा।

अंततः प्रोजेक्ट मैनेजर को विचार मिलता है और तदनुसार योजना बनाई जाती है।


2

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


1

चारों ओर अच्छे उत्तर, लेकिन मुझे अपने 2 सेंट जोड़ने चाहिए।

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

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

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

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

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


0

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

हां, अन्य उत्तर के रूप में, अधिकांश स्थितियों में आप उस समझौते पर हस्ताक्षर नहीं करना चाहेंगे। हालाँकि, मैं यह सुझाव देना चाहता हूं कि कुछ परिस्थितियाँ हो सकती हैं जहाँ आप इस पर हस्ताक्षर करने पर विचार कर सकते हैं।

अधिकांश डेवलपर्स और प्रबंधकों को कार्यक्षमता, समय सीमा और बजट के बीच निरंतर घर्षण के बारे में पता है। कई लोग चौथे आयाम के रूप में भी गुणवत्ता को नामांकित करेंगे ("जब तक आप कम बजट के लिए कल तक अपनी आवश्यकताओं के किसी भी सेट को वितरित कर सकते हैं, जब तक आप यह स्वीकार करने के लिए तैयार हैं कि यह काम नहीं करेगा!"

लेकिन अभी तक एक और आयाम है: जोखिम। अगर मुझे केवल 50% समय ही सफलतापूर्वक वितरित करने की आवश्यकता है, तो मैं अपने अनुमानों को बहुत कम कर सकता हूं; वे बहुत अधिक प्रसव दर को संभालने के लिए गद्देदार हैं।

हम कई तरीकों से जोखिम को संबोधित कर सकते हैं (और पैडिंग अनुमान उनमें से एक है)। प्रबंधक किसी भी जोखिम को स्वीकार करने के लिए तैयार नहीं है, और जोखिम को अपने कंधों पर रखना चाहता है। आम तौर पर, आपको इस तरह की हरकत को अस्वीकार कर देना चाहिए ... जब तक कि आपको अच्छी तरह से बहाल नहीं किया जा रहा है।

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


0

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

यदि आप यह दिखाना चाहते हैं कि इस तरह का अनुबंध कितना हास्यास्पद है, तो यहां दो सुझाव दिए जा सकते हैं:

a) उस बिंदु पर अत्यधिक निर्भर जहां परियोजना पांच या दस बार लेती है जब तक आप अनुबंध के बिना अनुमान लगाते हैं। यदि प्रोजेक्ट मैनेजर पूछता है कि अनुमान इतने अधिक क्यों हैं तो बस इतना कहें कि आप केवल यह सुनिश्चित कर रहे हैं कि आप अपना अनुबंध पूरा कर सकते हैं।

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

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

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


0

मैं यहां अनाज के खिलाफ जा रहा हूं।

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

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

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


मुझे लगता है कि यह "सब कुछ नया नहीं है और आवश्यकताओं को शुरू से लेकर समय सीमा तक 2-3 गुना बड़े पैमाने पर बदल जाता है, हालांकि?
वेटिन

रिलीज की शुरुआत से लेकर वास्तविक GA तक, निश्चित रूप से, सामग्री कुछ ही बार पूरी तरह से बदल सकती है। एक अच्छी प्रक्रिया है कि जल्दी बाहर है , जैसे विस्तृत डिजाइन या नीचे से पहले अनुमान लगाएगा।
TREE

++ सही है। एक अच्छी टीम में अच्छी प्रक्रियाएं होंगी और जोखिम स्वीकार करने के लिए तैयार रहना होगा। मुझे लगता है कि जब ग्राहक और ठेकेदार दोनों टीम का हिस्सा होते हैं और सभी मुद्दों को एक ही दृष्टिकोण से देखते हैं तो सबसे अच्छा काम करता है। मैं सॉफ्टवेयर विकास में अक्सर यह नहीं देखता हूं।
माइक डनलैवी

0

मैं कहता हूं कि अपने जूते में खुद को रखो और यह समझने की कोशिश करो कि क्या प्रेरित है। प्रबंधकों / लेखाकारों से संभावित रूप से उन्हें यह बताने के लिए एक नंबर की आवश्यकता है कि क्या हो रहा है और चीजें कैसे हो रही हैं।

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


++ के लिए "आप उसकी और उसकी मदद करने में सक्षम हो सकते हैं"।
माइक डनलैवी

0

"पानी पर चलना और एक विनिर्देश से सॉफ्टवेयर विकसित करना आसान है अगर दोनों जमे हुए हैं।"

-एडवर्ड वी। बार्ड

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


-2

क्या अनुबंध समय सीमा को पूरा नहीं करने के लिए जुर्माना निर्दिष्ट करता है? यदि ऐसा नहीं होता है, तो यह कोई समस्या नहीं है - आप उस समय केवल अपने ज्ञान के आधार पर एक अनुमान पर हस्ताक्षर कर रहे हैं।

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