यदि वास्तुकारों को प्रोग्रामरों की तरह काम करना पड़ता (1995)
1995 का एक हास्य-लेख, जिसमें कल्पना की गई है कि वास्तुकारों को सॉफ्टवेयर-उद्योग जैसी परिस्थितियों में काम करना पड़े, आधुनिक तकनीकी परियोजनाओं के संचालन पर व्यापक आलोचना को जन्म देता है: अस्पष्ट और बदलती आवश्यकताएँ, अवास्तविक समय-सीमाएँ, भारी प्रक्रिया, और “ज़िम्मेदारी बिना अधिकार।” टिप्पणीकर्ता सॉफ्टवेयर की तुलना निर्माण और अन्य इंजीनियरिंग क्षेत्रों से करते हैं, और बहस करते हैं कि क्या प्रोग्रामिंग को अधिक विनियमित, दायित्व-भारी भौतिक डिज़ाइन जैसा होना चाहिए या क्या उसकी लचीलेपन से पुनरावृत्त अराजकता उचित ठहरती है। कई लोग कॉर्पोरेट प्रोत्साहनों, MBA संस्कृति, और दिखावटी “Agile” को अव्यवस्था के लिए दोषी मानते हैं, जबकि अन्य कहते हैं कि ग्राहक, खराब विनिर्देश, और राजनीतिक बाधाएँ सभी पेशों में सार्वभौमिक हैं.
व्यंग्य पर कुल मिलाकर प्रतिक्रिया
- कई लोगों को यह लेख आधुनिक सॉफ्टवेयर काम के लिए दर्दनाक रूप से सटीक लगता है, खासकर अस्पष्ट आवश्यकताओं, बदलती मांगों, और मनमाने प्रतिबंधों के संदर्भ में।
- अन्य इसे बढ़ा-चढ़ाकर पेश की गई “प्रोग्रामर पीड़ित-भावना” मानते हैं, जो अन्य परियोजना-आधारित क्षेत्रों में समान अव्यवस्था को अनदेखा करती है।
- कई लोग नोट करते हैं कि लेख स्पष्ट रूप से हास्य है, लेकिन यह इसलिए गूंजता है क्योंकि यह उद्योग की आम समस्याओं को दर्शाता है।
वास्तविक दुनिया के निर्माण और वास्तुकला से समानताएँ
- निर्माण/वास्तुकला का अनुभव रखने वाले लोग आश्चर्यजनक रूप से मिलती-जुलती समस्याएँ बताते हैं: दुविधाग्रस्त या प्रतिष्ठा-प्रेमी ग्राहक, आख़िरी समय के बदलाव, अवास्तविक विचार (जैसे, देर से जोड़े गए रूफटॉप या पोडियम पूल), और ऐसे विनिर्देश जो अधूरे या गलत होते हैं।
- उच्च-स्तरीय आवासीय और “अमीर ग्राहक” वाला काम कथित तौर पर व्यंग्य जैसा ही दिखता है: लगातार पुनः-डिज़ाइन, पत्रिकाओं से आई प्रवृत्तियाँ, और मनमानी संरचनात्मक माँगें।
- अन्य लोग अंतर पर ज़ोर देते हैं: वास्तुकारों और इंजीनियरों पर कड़े नियम लागू होते हैं, व्यक्तिगत कानूनी दायित्व, सुरक्षा संबंधी चिंताएँ, और बदलाव की धीमी, अधिक महँगी चक्र-प्रक्रिया होती है।
सॉफ्टवेयर विकास में मुख्य दर्द-बिंदु
- अनिश्चितता के तहत अनुमान: बहुत छोटे विनिर्देश, काम को “पॉइंट्स” में कृत्रिम रूप से बाँटना, और अनुमान की सटीकता चाहे जैसी हो, दंडित होना।
- “ज़िम्मेदारी बिना अधिकार”: ऐसी समस्याओं के लिए दोषी ठहराया जाना जिन्हें ठीक करने की आपको अनुमति या साधन नहीं हैं।
- निरंतर बाधा: आपात स्थितियाँ, संदर्भ-परिवर्तन, और अनिवार्य स्थिति-मीटिंग्स जो समय-सीमा नहीं बदलतीं।
- “कॉर्पोरेट Agile” की व्यापक आलोचना होती है: यह रस्मों से भरा, सूक्ष्म-प्रबंधनकारी, और मूल Agile विचारों से कटा हुआ माना जाता है।
प्रबंधकों, PMs, और ग्राहकों की भूमिका
- कुछ लोग तर्क देते हैं कि अच्छे प्रोडक्ट/प्रोजेक्ट मैनेजरों को इंजीनियरों को अव्यवस्थित ग्राहकों से बचाना चाहिए; अन्य कहते हैं कि PMs अक्सर अव्यवस्था और सूक्ष्म-प्रबंधन का एक और स्रोत बन जाते हैं।
- इस पर असहमति है कि डेवलपरों को सीधे ग्राहकों से बात करनी चाहिए या नहीं: कुछ इसे समस्याएँ समझने के लिए आवश्यक मानते हैं; अन्य वादे करने और अपेक्षाएँ सँभालने के जोखिम की चेतावनी देते हैं।
समानताओं पर बहस: सॉफ्टवेयर बनाम भौतिक इंजीनियरिंग
- एक पक्ष: निर्माण और सॉफ्टवेयर मूलतः अलग हैं (बाइट्स बनाम ईंटें, उलटने की क्षमता, फीडबैक की गति, भूमिका-विखंडन), इसलिए यह उपमा “गलत” है।
- दूसरा पक्ष: फिर भी ऐसी उपमाएँ उपयोगी हैं, क्योंकि वे दिखाती हैं कि कुछ सॉफ्टवेयर अपेक्षाएँ भौतिक क्षेत्र में मैप करने पर कितनी बेतुकी लगती हैं।
व्यापक संगठनात्मक/प्रबंधन आलोचना
- कई टिप्पणियाँ “MBA-करण,” स्प्रेडशीट-आधारित निर्णय-निर्माण, तिमाही-केंद्रित सोच, और काम से कटे पेशेवर प्रबंधकों को दोष देती हैं।
- अन्य लोग नोट करते हैं कि लगभग सभी बड़े संगठन अव्यवस्थित होते हैं, चाहे वे सॉफ्टवेयर में हों या पारंपरिक इंजीनियरिंग में।