यदि वास्तुकारों को प्रोग्रामरों की तरह काम करना पड़े (1995)

यदि वास्तुकारों को प्रोग्रामरों की तरह काम करना पड़े (1995)

• आर्किटेक्ट से यह जाने बिना कि वास्तविक ज़रूरतें क्या हैं, घर डिज़ाइन करके बनाने का काम करने को कहा जाता है।

• घर में 2 से 45 शयनकक्ष हो सकें, और शयनकक्षों को आसानी से जोड़ा या हटाया जा सके।

• अंतिम निर्णय भवन के ब्लूप्रिंट को देखने के बाद किया जाएगा।

• चुना गया घर वर्तमान घर की तुलना में कम खर्चीला होना चाहिए।

• वर्तमान घर की सभी खामियाँ (रसोई के फर्श का कंपन, दीवारों की खराब इंसुलेशन) ठीक करनी होंगी।

• वार्षिक रख-रखाव खर्च को न्यूनतम रखते हुए नवीनतम डिजाइन प्रैक्टिस और सामग्री का उपयोग करना चाहिए।

• रसोई का ऐसा डिजाइन चाहिए जो 1952 मॉडल Gibson फ्रिज को समाहित कर सके।

• पूरे परिवार और ससुर की राय सुनकर सभी को संतुष्ट करने वाला घर डिज़ाइन करना है।

• छोटे-छोटे विवरणों पर मत अटको, व्यापक योजना बनाओ।

• संसाधन जुटाने से ज़्यादा महत्वपूर्ण है विस्तृत योजना और स्पेसिफिकेशन विकसित करना।

• योजना स्वीकृत होने के 48 घंटे के भीतर छत पूरी हो जानी चाहिए।

• बाद में किसी और को बेचने के लिए अलग-अलग संभावित खरीदारों की पसंद को ध्यान में रखना होगा।

• अंतिम प्लान तय करने से पहले समुदाय की सहमति ज़रूरी होगी।

• निर्माण ड्रॉइंग तैयार करनी होगी, हालांकि वास्तविक डिजाइन बाद में बदल सकती है।

• बाद में डिजाइन बदलने से निर्माण लागत बढ़ने का जिम्मा उठाना पड़ेगा।

• यह एक दिलचस्प परियोजना है जिसमें आधुनिक तकनीक और मुक्त डिजाइन इस्तेमाल करने की आज़ादी मिलती है।

• पत्नी का मानना है कि शायद घर नहीं, बल्कि एक ट्रैवल ट्रेलर चाहिए; उसने इसके लिए सलाह मांगी है।

GN⁺ की राय

• यह लेख एक ऐसे ग्राहक का व्यंग्य है जो आर्किटेक्ट से तर्कहीन व विरोधाभासी अपेक्षाएँ रखता है, और इससे अक्सर प्रोग्रामरों को मिलने वाली अवास्तविक अपेक्षाओं की चतुर तुलना मिलती है।
• इसे परियोजना की स्पष्ट आवश्यकताओं, अपेक्षाओं और परिवर्तन प्रबंधन के महत्व को रेखांकित करने वाले उदाहरण के रूप में देखा जा सकता है।
• यह लेख निर्माण और प्रोग्रामिंग जैसे दो अलग क्षेत्रों के विशेषज्ञों द्वारा साझा की जाने वाली सामान्य समस्याओं को समझने और महसूस करने में मदद करता है, तथा परियोजना प्रबंधन की चुनौतियों को हास्यपूर्ण तरीके से रखकर पाठकों में रुचि जगाता है।

[GN⁺]

Hacker News टिप्पणी

• पहली टिप्पणी का सारांश:

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

• दूसरी टिप्पणी का सारांश:

  घर बनाना अक्सर कठिन क्लाइंटों या बदसूरत डिजाइन चाहने वाले लोगों से बात करने को भी शामिल करता है, जो कि सॉफ़्टवेयर इंजीनियर की जिम्मेदारियों का भी हिस्सा है। कभी-कभी ब्लूप्रिंट गलत या गलत-सटीक हो सकता है, लेकिन लोग फिर भी घर बनाते हैं।

• तीसरी टिप्पणी का सारांश:

  यह 'कॉकटेल-पार्टी आइडिया' का क्लासिक उदाहरण है कि किसी को लगता है कि प्रोग्रामर किसी और क्षेत्र को कैसे रन करते हैं। एक वास्तुकार भी प्रोग्रामरों के बारे में वही प्रकार की धारणाएँ और गलतफहमियाँ लिख सकता है।

• चौथी टिप्पणी का सारांश:

  वास्तुकार को फुल-साइज़ मॉडल पहले से बनाकर चेक करने को कहो, और अगर उसे पसंद न आए तो शुरुआत से दोबारा बनाओ। एक बार ऐसा बना लेने का अनुभव हो तो बदलावों को शामिल करके फिर से बनाना उतना कठिन नहीं होगा।

• पाँचवीं टिप्पणी का सारांश:

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

• छठी टिप्पणी का सारांश:

  मैं पहले पुल निर्माण टीम वाला वर्ज़न पसंद करूँगा। इसे समय को 'पॉइंट' में मापने की मांग और सॉफ़्टवेयर इंडस्ट्री पर की गई आलोचना के रूप में पढ़ता हूँ। IT वाले आमतौर पर अवास्तविक अपेक्षाओं को मान लेते हैं, इसलिए ग्राहकों को यह हक़ीकत समझाना बहुत ज़रूरी है।

• सातवीं टिप्पणी का सारांश:

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

• आठवीं टिप्पणी का सारांश:

  यह मानना कि प्रोग्रामिंग निर्माण जैसी है, गलत है। एक नया उत्पाद बनाना दो चरणों में होता है: product design और manufacturing। वास्तुकार और सॉफ़्टवेयर इंजीनियर दोनों product design चरण में आते हैं। सॉफ़्टवेयर इंजीनियरिंग केवल डिज़ाइन का हिस्सा है, और यह अंतिम डिज़ाइन के बाद निर्माण नहीं करती।

• नौवीं टिप्पणी का सारांश:

  ज्यादातर काम लोगों की ज़रूरतों को सुनने का होता है। लोग अक्सर यह ठीक-ठीक नहीं जानते कि उन्हें क्या चाहिए, लेकिन वे चाहते हैं कि आप उनकी समस्या सुनें और मदद करने के लिए पूरी कोशिश करें.