"इसका जवाब कब दिया जाएगा?"

9

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

सवाल पूछने पर "कोई जवाब कब दिया जाएगा?", खासकर जब क्लाइंट सॉफ्टवेयर विकास की अंतर्निहित जटिलताओं को नहीं समझ सकता है तो कोई कैसे जवाब देता है?

management client-relations estimation

— मैट स्लैनी
स्रोत

3

बर्फ़ीला तूफ़ान या वाल्व दृष्टिकोण: जब यह किया जाता है।

— डेडएमजी

5

"यह इस बात पर निर्भर करता है कि मैं ऐसे लोगों से कितनी बार विचलित होऊंगा जो पूछते हैं कि यह कब किया जाता है।"

— इंगो

"जब यह हो गया। आप बढ़िया खाना पकाने और बढ़िया कोडिंग नहीं कर सकते।"

— गिल्बर्ट ले ब्लैंक

इस बात का अनुमान लगाने में मैं क्या बेहतर कर सकता हूं कि परियोजनाएं कितनी लंबी होने जा रही हैं?

— गनत

24

आप सवाल का जवाब ईमानदारी से दें।

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

— MattBelanger
स्रोत

1

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

— रॉबिंस

7

@ S.Robins: इस तरह का सबसे अच्छा अनुमान देने का खतरा यह है कि यह बिना चेतावनी के ऊपर की ओर जाता है।

— माइकल बोर्गवर्ड

1

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

— जेम्स स्नेल

10

डेवलपर्स एक जटिल समस्या को छोटे लोगों में विघटित करके और उन्हें अलग से हल करके देखते हैं।

एक आदर्श दुनिया में , एक मुद्दा सुलझाने के लिए एक जटिल समस्या होगी एक और आप, सक्षम हो जाएगा एक निश्चित समय में, छोटे समस्याओं की एक छोटी सूची में विघटित करने के लिए एक ₁ के लिए एक _n , हर बार के मूल्यांकन के लिए सरल है, यह देखते हुए प्रारंभिक जटिल समस्या को हल करने के लिए आवश्यक समय होगा:

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

डी के साथ ही अपघटन की प्रक्रिया है।

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

तुम अभी भी:

दिए गए कार्य (समस्या को हल करते हुए) को छोटे टुकड़ों में अलग करें, प्रत्येक हिस्सा अभी भी एक जटिल समस्या है,
प्रत्येक ठग और इसी जोखिम के लिए अपेक्षित समय का मूल्यांकन करें।

उदाहरण के लिए, कार्य 1 के लिए लगभग आवश्यक है। 5 घंटे, लेकिन ऐसा करने से अवरुद्ध होने का जोखिम अधिक है, इसलिए ग्राहक को अपनी अपेक्षा के अनुसार 12 घंटे दें।
निर्भरता का मूल्यांकन करें और वे समय को कैसे प्रभावित करते हैं।

उदाहरण के लिए, कार्य 19 के लिए 2 घंटे की आवश्यकता होती है, और जोखिम इतना कम होता है कि आप कह सकते हैं कि यह सुनिश्चित करने के लिए 2 घंटे हैं। नहीं 1. नहीं 3. लेकिन टास्क 19 टास्क 24 पर निर्भर करता है: टास्क 24 इस तरह से टास्क 19 को प्रभावित कर सकता है कि आपको एक अलग दृष्टिकोण का उपयोग करके टास्क 19 के कोड को पूरी तरह से फिर से लिखना होगा।
उन सभी विवरणों को अपने ग्राहक को दें। राशि न दें।

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

यदि, इसके बजाय, आप विवरण देते हैं,

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

— आर्सेनी मूरज़ेंको
स्रोत

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

— जियोर्जियो

यह न तो 192 घंटे है, न ही यह 238 घंटे या 85 घंटे है। यह इन मूल्यों के सभी है, प्रत्येक एक निश्चित संभावना के साथ।

— 16

4

आप जो भी अनुमान लगाते हैं वह हॉफस्टैटर के नियम को शामिल करना नहीं भूलता है : यह हमेशा आपकी अपेक्षा से अधिक समय लेता है, यहां तक कि जब आप हॉफस्टैटर के कानून को ध्यान में रखते हैं।

— bdecaf
स्रोत

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

— JensG

1

आमतौर पर मैं CPM / PERT से संशोधित सूत्र का उपयोग करता हूं। यह कुछ इस तरह है:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(मुझे यकीन नहीं है कि सभी फैंसी गणित प्रारूपण कैसे करें? यदि कोई इसके लिए इसे संपादित करना चाहता है, तो स्वतंत्र महसूस करें।)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

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

— गैब विलार्ड
स्रोत

0

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

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

— MathAttack
स्रोत

0

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

एक सीमा आज़माएं - "मुझे यकीन है कि इसमें कम से कम N दिन (जैसे 3) लगेंगे , लेकिन इसमें 4N तक लग सकते हैं।"
अनुमान लगाने और अनुमान लगाने में अधिक वरिष्ठ इंजीनियरों के समर्थन की तलाश करें।
कम से कम कोड बनाने के लिए कम पुनरावृत्तियों (एजाइल / स्क्रम शैली) में काम करें जो व्यावसायिक मूल्य (आत्मविश्वास और विश्वास प्राप्त करता है) जोड़ता है, फिर दोहराएं।
क्लासिक गेटिंग टू यस (http://www.amazon.com/gp/aw/d/0143118757) जैसी पुस्तक से बातचीत कौशल सीखें।

— codingoutloud
स्रोत

0

नए विकास के लिए, विशेष रूप से चुस्त विकास:

"पूर्णता हासिल की जाती है, न कि जब जोड़ने के लिए और कुछ नहीं होता है, लेकिन जब लेने के लिए कुछ भी नहीं बचता है।" - एंटोनी डी सेंट-एक्सुपर

यदि आप सिस्टम के अंतरंग डोमेन ज्ञान के साथ बहुत कम कुछ डेवलपर्स के साथ एक छिपकर अत्यधिक जटिल प्रणाली में त्रुटि (ओं) को पुन: उत्पन्न करने के लिए लगभग कुछ असंभव को ठीक करने के प्रयास और समय का अनुमान लगा रहे हैं, तो एकमात्र सही उत्तर है "जब यह तय हो गया है।"

0

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

— natman3400
स्रोत

0

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

— तमसे सजेले
स्रोत