एक परियोजना को प्रबंधित करने के लिए कैसे करें जब यह अनिश्चित अवधि के लिए जमे हुए/देरी हो जाती है

Question

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

अच्छा, कठिन!

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

इसलिए मुझे सलाह है कि मेरे डिज़ाइन को सर्वोत्तम रूप से कैसे याद रखें। अब से 4 महीने। या शायद अब से एक साल भी ... लिखना सबसे महत्वपूर्ण होगा? या दस्तावेज? (मेरे पास थोड़ी सी मात्रा को ध्यान में रखते हुए ...) कोई सुझाव?

क्यों? अन्यथा मैं अब से चार महीने फिर निराश हो जाऊंगा। :-)

Answer 1

यह निर्भर करता है कि आपके लिए क्या काम करता है - और आप कैसे सीखना पसंद करते हैं। मुझे आरेखों का उपयोग करना पसंद है, इसलिए ऐसी परिस्थिति में जहां मैंने एक कूल एल्गोरिदम बनाया है (यद्यपि इसके रूप में जटिल नहीं है!) मैं निम्नलिखित करता हूं:

1) पेपर पर एल्गोरिदम निकालें, या इसे जो कुछ भी लिखें ।

2) इसमें एनोटेशन जोड़ें ताकि यह पूर्ण आपको समझ सके।

3) केवल आपके द्वारा खींचे गए किसी भी चीज़ से एल्गोरिदम का वर्णन करें। यह आपको एल्गोरिदम के अपने ज्ञान से रिक्त स्थान भरने से रोकता है।

4) यदि आपके विवरण में अंतर हैं, तो अतिरिक्त विवरण जोड़ें जैसे कि आप जाते हैं, ताकि दस्तावेज़ आपके विवरण का व्यापक रिकॉर्ड बन जाए।

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

चाहे यह एक वर्ष के समय में पर्याप्त स्पष्ट होगा - या आप इसका उपयोग भी करना चाहते हैं - देखा जाना बाकी है।

आशा है कि मदद करता है!

Answer 2

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

विशिष्ट परियोजनाओं से निराश न हों, डेवलपर के रूप में सुधारने पर अपनी ऊर्जा पर ध्यान केंद्रित करें। और उस अनुभव को अपने साथ ले जाएं।

Answer 3

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

[Meta Object] 

    [Return String(string param1, string param2)] 

     Return param1 + " " + param2 

    [Return Integer(integer param1, integer param2, integer param3)] 

     Return (param1 + param3)/param2 

[End Meta Object] 

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

Answer 4

निराशा के मामले में - आमतौर पर किसी गंतव्य के बजाय एक यात्रा के रूप में एक परियोजना को देखने का प्रयास करें।

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

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

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

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

(कुछ योएल या जेफ के लिए अनिवार्य लिंक लिखा है: http://www.codinghorror.com/blog/archives/001297.html)

Answer 5

आप मिला है, तो समाधान एक बार, संभावना है कि आप बाहर भी 4 महीने एक ही समस्या के लिए लाइन नीचे समाधान मिल जाएगा रहे हैं। आपको जो याद नहीं करना चाहिए वह वास्तविक समस्या है।

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

अब, अगली बार [कहना 4 महीने लाइन नीचे] क्या आप फिर से वापस इस पर आने के लिए चाहते हैं। आपको बस अपने नोट्स से समस्या के मुद्दों को पढ़ने की जरूरत है, और आपका दिमाग सीधे दिशा में काम करना शुरू कर देगा जैसा कि पहले किया गया था।

इसे और भी बेहतर बनाने के लिए, आप एक या दो महीने में एक बार समस्या नोट्स के माध्यम से जाने का प्रयास कर सकते हैं। यह आपके मस्तिष्क को समाधान की ओर प्रशिक्षित करेगा क्योंकि आप समाधान के साथ हर बार समाप्त होंगे जैसे आपने पहली बार किया था।

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