मैं एक परियोजना में शामिल होऊंगा, जहां सभी सॉफ्टवेयर डिजाइन एक स्थानीय टीम द्वारा बनाए जाते हैं और इन डिजाइनों को कोडिंग के लिए एक अपतटीय टीम को भेजा जाता है।
यह पहली बार है जब मैं इस विशेषताओं के साथ किसी परियोजना का सामना कर रहा हूं और मेरे लिए यह अजीब तरह का लगता है: प्रबंधक हमसे बहुत विस्तृत डिजाइन दस्तावेज बनाने की अपेक्षा करते हैं, ताकि अपतटीय टीम के लिए त्रुटि के लिए कोई स्थान न हो; मेरे नजरिए से वे हमें कागज़ में कोडिंग करवा रहे हैं जबकि हम इसे एक आईडीई में कर सकते हैं।
तो, मेरा सवाल यह है कि क्या यह दृष्टिकोण अच्छा है, या सही साबित हुआ है? हमारी परियोजना में सफल होने के लिए हमारी सॉफ्टवेयर प्रक्रिया के मुख्य विचार क्या हैं?
11
अपोलो 11 सॉफ्टवेयर के लिए आवश्यकताओं का 500 पेज 150MB पीडीएफ दस्तावेज़ ।
—
माइक
@ माइक: स्पेसक्राफ्ट सॉफ्टवेयर अधिकांश सॉफ्टवेयरों की तुलना में थोड़ा अलग है। इसमें हर समय पूरी तरह से काम करना पड़ता है, या जीवन की हानि और अत्यधिक महंगी संपत्ति हो सकती है। देखें fastcompany.com/28121/they-write-right-stuff
—
रॉबर्ट हार्वे
मुझे लगता है कि अपतटीय टीम सस्ती है, क्या यह डिजाइन टीम के आकार से दोगुना है? क्या इन-हाउस टीम पर इसके कुछ वास्तविक फायदे हैं? उदाहरण के लिए जब वे नहीं करते तो वे अंतिम उपयोगकर्ताओं की प्राकृतिक भाषा बोलते हैं? क्या उनके पास कुछ प्रकार की प्रतिभा है जो आपके पास घर में नहीं है? यदि नहीं, तो मुझे लगता है कि आपकी कंपनी पर PHB विषाक्तता का बुरा मामला है ।
—
ZJR
@ माइक: मुझे लगता है कि यह कहना अधिक सटीक होगा कि अधिकांश सॉफ़्टवेयर में बग की एक छोटी संख्या स्वीकार्य मानी जाती है, क्योंकि बग-मुक्त सॉफ़्टवेयर एक स्पर्शोन्मुख है और उन शेष बग्स को प्राप्त करना बहुत महंगा है।
—
रॉबर्ट हार्वे
मेरा सुझाव है कि आप तुरंत दूसरी नौकरी की तलाश शुरू करें। प्रोग्रामर विनिमेय cogs नहीं हैं, जो इस तरह की व्यवस्था की अंतर्निहित धारणा है। इस तरह से विकास से डिजाइन को अलग करना - तटवर्ती या अपतटीय - ग्राहक और डेवलपर्स के बीच एक डिस्कनेक्ट की गारंटी देता है जो विफलता को अत्यधिक संभावना बनाता है।
—
स्टीवन ए। लोव