सटीक परिस्थितियां स्पष्ट रूप से आपकी परियोजना (जैसे विकास दल, प्रबंधन शैली, प्रक्रिया परिपक्वता, विषय वस्तु की कठिनाई, आदि) के लिए बहुत विशिष्ट हैं। इसे थोड़ा और बेहतर बनाने के लिए हम इसके बारे में कुछ भी बोल सकते हैं, लेकिन ओवरसिमलाइजेशन को पार करने के लिए, मैं आपके बारे में कुछ बताने जा रहा हूं:
किसी भी परिस्थिति में, यदि कोई हो, टीम के सदस्यों को एक सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट में जोड़ सकता है जो वास्तविक जहाज तारीख में कमी के साथ गुणवत्ता के स्तर के बराबर परिणाम में देर से चल रहा है अगर मौजूदा टीम को पूरा होने तक काम करने की अनुमति थी?
ऐसी कई चीजें हैं जो मुझे लगता है कि आवश्यक हैं , लेकिन पर्याप्त नहीं हैं, इसके लिए (कोई विशेष क्रम में नहीं):
- प्रस्तावित व्यक्तियों को परियोजना में जोड़ा जाना चाहिए:
- कम से कम परियोजना के समस्या डोमेन की एक उचित समझ
- परियोजना की भाषा और उन विशिष्ट तकनीकों के बारे में प्रवीण रहें जो वे दिए गए कार्यों के लिए उपयोग करेंगे
- उनकी दक्षता क्रमशः सबसे कमजोर या मजबूत मौजूदा सदस्य की तुलना में बहुत कम या ज्यादा होनी चाहिए। कमजोर सदस्य आपके मौजूदा कर्मचारियों को तृतीयक समस्याओं से निजात दिलाएंगे, जबकि एक नया व्यक्ति जो बहुत मजबूत है, वह टीम को बाधित करेगा कि उन्होंने जो कुछ भी किया है और जो कर रहे हैं वह गलत है।
- अच्छी कम्युनिकेशन स्किल हो
- अत्यधिक प्रेरित रहें (उदाहरण के बिना स्वतंत्र रूप से काम करने में सक्षम)
- मौजूदा टीम के सदस्यों के पास होना चाहिए:
- बेहतरीन कम्युनिकेशन स्किल्स
- उत्कृष्ट समय प्रबंधन कौशल
- परियोजना का नेतृत्व / प्रबंधन होना चाहिए:
- अच्छी प्राथमिकता और संसाधन आवंटन क्षमता
- मौजूदा टीम के सदस्यों से उच्च स्तर का सम्मान
- बेहतरीन कम्युनिकेशन स्किल्स
- परियोजना में होना चाहिए:
- एक अच्छा, पूर्ण और प्रलेखित सॉफ़्टवेयर डिज़ाइन विनिर्देश
- पहले से लागू चीजों का अच्छा प्रलेखन
- एक मॉड्यूलर डिजाइन जो जिम्मेदारी के स्पष्ट भाग को उकेरने की अनुमति देता है
- आवश्यक दोष स्तर के लिए गुणवत्ता आश्वासन के लिए पर्याप्त स्वचालित प्रक्रियाएं इनमें ऐसी चीजें शामिल हो सकती हैं: इकाई परीक्षण, प्रतिगमन परीक्षण, स्वचालित निर्माण तैनाती आदि।)
- एक बग / सुविधा ट्रैकिंग सिस्टम जो वर्तमान में टीम द्वारा (जैसे trac, SourceForge, FogBugz, आदि) में इन-प्लेस और इन-यूज़ होता है।
पहली चीजों में से एक पर चर्चा की जानी चाहिए कि क्या जहाज की तारीख हो सकती है खिसकाया सकता है, क्या सुविधाओं में कटौती की जा सकती है, और यदि दोनों के कुछ संयोजन आपको अपने मौजूदा कर्मचारियों के साथ रिलीज को संतुष्ट करने की अनुमति देंगे। कई बार इसके दो फीचर्स ऐसे होते हैं जो वास्तव में उस टीम के संसाधनों को रोक रहे हैं जो निवेश के बराबर मूल्य नहीं देगा। इसलिए अपनी परियोजना की प्राथमिकताओं को किसी अन्य चीज से पहले एक गंभीर समीक्षा दें।
यदि उपरोक्त पैराग्राफ का परिणाम पर्याप्त नहीं है, तो ऊपर दी गई सूची पर जाएं। यदि आपने शेड्यूल स्लिप को जल्दी पकड़ा है, तो सही समय पर सही टीम के सदस्यों का जुड़ाव रिलीज को बचा सकता है। दुर्भाग्य से, आप अपने अपेक्षित जहाज की तारीख के जितना करीब होंगे, लोगों को जोड़ने के साथ उतनी ही चीजें गलत हो सकती हैं। एक बिंदु पर, आप "पॉइंट ऑफ़ नो रिटर्न" को पार कर लेंगे जहाँ कोई भी परिवर्तन (वर्तमान विकास शाखा को शिपिंग के अलावा) आपकी रिहाई को नहीं बचा सकता है।
मैं आगे और आगे बढ़ सकता था लेकिन मुझे लगता है कि मैंने प्रमुख बिंदुओं को मारा। प्रोजेक्ट के बाहर और अपने करियर के संदर्भ में, कंपनी की भविष्य की सफलता, आदि में से एक चीज़ जो आपको निश्चित रूप से करनी चाहिए, यह पता लगाना चाहिए कि आपको देर क्यों हुई, अगर कुछ भी आपको पहले से सतर्क किया जा सकता था, और आपको किन उपायों की ज़रूरत है भविष्य में इसे रोकने के लिए। एक देर से परियोजना आमतौर पर होती है क्योंकि आप या तो थे:
- शुरू होने से पहले देर हो चुकी थी (और समय से अधिक सामान) और / या
- समय पर 1hr, 1day फिसल गया।
उम्मीद है की वो मदद करदे!