एक गैर-तकनीकी व्यक्ति को कैसे समझा जाए कि यह कार्य जितना वे सोचते हैं, उससे अधिक समय क्यों लगेगा? [बन्द है]

60

लगभग हर डेवलपर को व्यावसायिक पक्ष से सवालों के जवाब देने होते हैं जैसे:
इस सरल संपर्क फ़ॉर्म को जोड़ने के लिए 2 दिन क्यों लगने वाले हैं?

जब कोई डेवलपर इस कार्य का अनुमान लगाता है, तो वे इसे चरणों में विभाजित कर सकते हैं:

डेटाबेस में कुछ बदलाव करें
गति के लिए DB परिवर्तनों का अनुकूलन करें
सामने अंत HTML जोड़ें
सर्वर साइड कोड लिखें
सत्यापन जोड़ें
क्लाइंट साइड जावास्क्रिप्ट जोड़ें
इकाई परीक्षण का उपयोग करें
सुनिश्चित करें कि एसईओ सेट-अप काम कर रहा है
ईमेल पुष्टिकरण लागू करें
रिफैक्टर और गति के लिए कोड का अनुकूलन
...

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

तो क्या यह समझाने का एक बेहतर तरीका है कि अनुमान गैर-डेवलपर के लिए अधिक क्यों है?

communication estimation

— Mag20
स्रोत

15

मैंने आपके सवाल को खारिज कर दिया क्योंकि यह अपने आप में सबसे अच्छा जवाब है।

— जॉन एफएक्स 13'11

3

ठीक ठीक। उन्हें एक समय बताएं और फिर शायद वे बारीकियों को समझेंगे ... क्या यह एक बार है और हो सकता है कि वे अगली बार विवरण के बारे में बताएंगे ...

— फुर्तीला स्काउट

1

के संभावित डुप्लिकेट के विकास की प्रक्रिया को समझने के लिए नान प्रोग्रामर्स हो रही है

— कुटकी

4

आपको लगता है कि गैर-तकनीकी लोगों को यह समझाना कठिन है? तकनीकी लोगों को भी नहीं मिलता है!

— कॉंगसबोंगस

1

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

— एरिक रिपेन

26

आपने इसे अपने प्रश्न में किया है।

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

यदि समयसीमा बहुत महान है, तो आप इस बात पर चर्चा कर सकते हैं कि इस मामले में ठोस डेटा के साथ किन भागों (जैसे ई-मेल की पुष्टि) की आवश्यकता नहीं है, बस पिंट पॉट में एक चौथाई गेलन रटना करने की कोशिश कर रहा है।

यह अक्सर पर्याप्त करें और आप उम्मीद करेंगे कि उन्हें सिखाएंगे कि पहली नज़र में मिलने की तुलना में आमतौर पर अधिक विकास होता है।

— क्रिसफ
स्रोत

3

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

— डैनियल नूडल

1

@ डैनियल - मुझे लगता है कि यह इस बात पर निर्भर करता है कि आपको "औपचारिक" कैसे प्राप्त करने की आवश्यकता है, लेकिन प्रोजेक्ट (या समतुल्य) अधिक पेशेवर दिखता है।

— ChrisF

वास्तव में मैं कुछ मामलों के लिए जरूरत से ज्यादा औपचारिकता पर सहमत हूं। यह सब के बारे में है कि किस विकल्प को कम धक्का मिलता है और सीढ़ी को कितनी दूर जाना पड़ता है। व्यक्तिगत रूप से मैं घर के काम को शेड्यूल करने के लिए प्रोजेक्ट का उपयोग करता हूं .. lol

— डैनियल नूडल

1

बेशक इसका नकारात्मक पक्ष यह है कि यह सूची एक प्रतिबद्धता बन जाती है और यदि कुछ भी हो जाता है तो आप हिट हो जाएंगे।

— एंडी

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

— पैंजरक्रिस

11

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

लेकिन हो सकता है कि आपने "DB" शब्द पर अपना प्रोजेक्ट प्रबंधन खो दिया हो, न कि "ऑप्टिमाइज़" शब्द।

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

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

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

सबसे महत्वपूर्ण निम्नलिखित बातें हैं:

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

— bethlakshmi
स्रोत

यह तब है जब पसंदीदा उत्तर देने में सक्षम होना अच्छा होगा।

— पैन्ज़रक्रिसिस

9

एक कहावत है, "आप पांच पाउंड के बैग में दस पाउंड (बकवास) फिट नहीं कर सकते।" आपका काम यह दिखाना है कि कार्य दस पाउंड का है और वे इसे पांच पाउंड के समय सीमा में रखने के लिए कह रहे हैं।

केवल एक चीज जो आप याद कर रहे हैं वह है समय अनुमान। प्रत्येक कार्य पर एक समय का अनुमान लगाएं, और दिखाएं कि ये सभी चीजें आपके द्वारा प्रदान किए गए अनुमान के साथ कैसे जुड़ती हैं। किसी भी अनुमान को 4 घंटे से बड़ा न होने दें। यदि आपके पास कोई कार्य है जहां आप "एक दिन" या "10 घंटे" कहते हैं, तो इसे छोटे उप-प्रकारों में तोड़ दें।

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

अब आपको लागतों का एक आइटमयुक्त बिल मिल गया है। सभी ने बताया, कि 27 घंटे तक काम करने का योग है।

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

यह भी सुनिश्चित करें कि आप समझाते हैं कि आपका समय / दिन वास्तविक रूप से क्या है। उदाहरण के लिए, यदि आपको तकनीकी सहायता करने के लिए बुलाया जाता है, या डेटाबेस को बनाए रखने के लिए, या जो भी हो, उसे अपने अनुमान में शामिल करें। मत कहो "ठीक है, मैं दिन में 7.5 घंटे अच्छी कोडिंग कर सकता हूं" क्योंकि आप शायद नहीं कर सकते। यह शायद 5 या 6 की तरह है।

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

मेरी बातों को रोकने के लिए मेरी स्लाइड देखें संकट: प्रोजेक्ट एस्टीमेशन एंड ट्रैकिंग दैट वर्क्स जो मैंने कुछ साल पहले OSCON में दिया था। स्लाइड 21 को देखें, "सप्ताह की योजना बनाना"। एक नमूना वेग चार्ट भी है ।

— एंडी लेस्टर
स्रोत

5

पांच या छह घंटे प्रति दिन अच्छा कोडिंग? अच्छा होना चाहिए!

— मेरे सही चुनाव

1

उनसे पूछों:

आपको इसे कैसे करना होगा? आप कौन से मॉड्यूल बदलेंगे? कोड की कितनी लाइनें? सुरक्षा निहितार्थ क्या हैं? डेटाबेस स्कीमा में कोई बदलाव? यदि आप DB में कोई बदलाव करते हैं, तो कितनी फाइलें प्रभावित होती हैं? अंतिम रूप को जोड़ने में कितना समय लगा? फॉर्म जोड़ने के लिए औसत (अंकगणितीय माध्य) क्या है? सबसे लंबी कौन सी थी? मुझे लगता है कि यह सबसे लंबे समय से एक मिनट कम लगेगा। यदि आप नहीं जानते हैं कि अंतिम N रूपों को जोड़ने में कितना समय लगा है, तो यह अनुमान केवल परिमाण के एक क्रम के सटीक होने की गारंटी है।

— SnoopDougieDoug
स्रोत

1

ये मेरे लिए निष्क्रिय-आक्रामक के रूप में सामने आते हैं।

— एंडी

नहीं, यह सोक्रेटिक विधि है।

— SnoopDougieDoug

-2

मैं आपको उन्हें समझाने के लिए कह सकता हूं कि उनका सॉफ्टवेयर 100 टन की मशीन की तरह है जिसमें 10,000 अलग-अलग हिस्से हैं, यह बहुत जटिल तरीकों से जुड़ा हुआ है। इस मशीन में 1 इंच का टुकड़ा भरने से कुछ इंजीनियरिंग होती है, जिससे यह मशीन नहीं टूटेगी, लेकिन बेहतर उत्तर है:

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

ठीक वैसे ही जैसे 20 वीं शताब्दी में अच्छी वास्तुकला और बड़ी इमारतों के निर्माण के लिए इंजीनियरिंग करने के लिए, सॉफ्टवेयर इंजीनियरिंग के लिए उपकरण अभी मुख्यधारा में नहीं आए हैं। उन्हें विकसित किया जा रहा है: यह एक नई मानसिकता लेता है। Wiki.hackerspaces.org/Hacking_with_the_Tao पर ज़ेन कोड देखें।

— चिकित्सक
स्रोत

ऐसा लगता है कि किए गए अंक से अधिक कुछ भी नहीं दिया जा रहा है और पहले 5 उत्तरों में समझाया गया है

— gnat