- अंतरिक्षयान डिज़ाइन और engineering projects पर लागू होने वाले 40 व्यावहारिक सिद्धांतों को संकलित करने वाली स्लाइड
- संख्यात्मक विश्लेषण, iterative design, fault-tolerant design को मुख्य सिद्धांतों के रूप में रेखांकित किया गया है
- एक यथार्थवादी चेतावनी भी शामिल है कि schedule केवल एक दिशा में ही बढ़ता है, और शुरुआती estimates हमेशा कम आंके गए होते हैं
- aerospace engineering से आगे बढ़कर software·system·startup design के पूरे क्षेत्र में सीधे लागू
- engineering judgment में बार-बार होने वाली गलतियों को रोकने के लिए एक व्यावहारिक checklist
नियम 1 — संख्याओं से सिद्ध होने वाली engineering
- "Engineering is done with numbers. Analysis without numbers is only an opinion."
- engineering संख्याओं से की जाती है; संख्याओं के बिना analysis सिर्फ एक राय है
- यही कारण है कि engineering के छात्र गणित सीखने में बहुत समय लगाते हैं
- engineering में सफलता मापी जा सकने योग्य होनी चाहिए
- "मेरा system ज्यादा तेज़ है" → कितना ज्यादा तेज़?
- "मेरा system ज्यादा सस्ता है" → लागत कितनी है?
- "मेरा system ज्यादा सरल है" → सरलता को कैसे मापेंगे?
नियम 2 — fault-tolerant design
- "To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong."
- अंतरिक्षयान को सही तरह से डिज़ाइन करने में अनंत मेहनत लगती है, इसलिए उसे इस तरह डिज़ाइन करना चाहिए कि कुछ चीज़ें गलत होने पर भी वह काम करे
- 100% reliability मांगने वाले system design से बचें
- विफलता के उदाहरण: Deep Water Horizon, फुकुशिमा
- aircraft control systems में 3 way logic checking का उदाहरण
नियम 3 — iterative design process
- "Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time."
- design एक iterative process है, और आवश्यक iterations की संख्या हमेशा अब तक किए गए iterations से एक अधिक होती है
- अच्छा design कभी वास्तव में पूरा नहीं होता
नियम 4 — निराशा से निपटना
- "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
- आपकी सबसे अच्छी design मेहनत भी अंततः final design में बेकार हो सकती है; इस निराशा के साथ जीना सीखें
- Bhargava का नियम: 10 research projects में से केवल 1 ही industrial practice में लागू होता है
- सबसे बड़ी commercial success जरूरी नहीं कि सबसे बेहतरीन technical design हो
- उदाहरण: Nokia N95 vs 1st gen iPhone
नियम 5 (Miller का नियम) — तीन बिंदु एक वक्र तय करते हैं
- "Three points determine a curve."
- तीन बिंदु एक curve तय करते हैं
- data set में हमेशा कोई न कोई pattern दिखने लगता है
- यह जांचना ज़रूरी है कि वह pattern measurement noise की वजह से नहीं, बल्कि वास्तविक अध्ययन किए जा रहे phenomenon की वजह से है
- academia और graduate students खास तौर पर इस नियम को नज़रअंदाज़ करते हैं
नियम 6 (Mar का नियम) — data overfitting से सावधान
- "Everything is linear if plotted log-log with a fat magic marker."
- यदि log-log graph पर मोटे magic marker से प्लॉट करें, तो सब कुछ linear दिखता है
- Bigg का नियम: "गणितीय tools से प्यार में मत पड़ो; वे तुम्हें वापस प्यार नहीं करेंगे"
- data over-fit पर रोक
नियम 7 — leadership और team structure
- "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
- किसी भी design project की शुरुआत में, जो व्यक्ति सबसे अधिक team leader बनना चाहता है, उसके सक्षम होने की संभावना सबसे कम होती है
- Dilbert comic असली engineering companies के अनुभवों पर थोड़ी अतिशयोक्ति के साथ आधारित है
- leadership का कुछ हिस्सा जन्मजात होता है, लेकिन बड़ा हिस्सा सीखना पड़ता है
- कुछ managers 'basics का सम्मान करना' नहीं जानते
- इसके लिए किसी industrial engineer से MBA के बारे में पूछें
नियम 8 — optimum अक्सर बीच में होता है
- "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
- प्रकृति में optimum लगभग हमेशा कहीं बीच में होता है; यह दावा कि optimum किसी extreme point पर है, संदेह से देखना चाहिए
- मानक उदाहरण: optimal power transfer
- practical example: optimal sensor resistance
नियम 9 — जानकारी की कमी कोई बहाना नहीं
- "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
- आपके पास सारी जरूरी जानकारी न होना, analysis शुरू न करने का संतोषजनक बहाना कभी नहीं हो सकता
- अधिक complete analysis के लिए किन values की जरूरत है, यह पहचानना चाहिए
नियम 10 — estimate और guess
- "When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along."
- संदेह हो तो estimate करें; emergency में guess करें; लेकिन जब असली numbers मिल जाएँ, तो वापस जाकर स्थिति ज़रूर सुधारें
- आपको engineer बनने की training दी जाती है, ज्योतिषी बनने की नहीं
- इस पेशे में तेज़ सोच से ज्यादा अच्छी सोच महत्वपूर्ण है
नियम 11 — फिर से शुरुआत करना
- "Sometimes, the fastest way to get to the end is to throw everything out and start over."
- कभी-कभी अंत तक पहुँचने का सबसे तेज़ तरीका है सब कुछ छोड़कर फिर से शुरुआत करना
- यह समझने में समय लगता है कि ऐसा कब करना चाहिए
- कई industries में ऐसे बहुत से मामले हैं जहाँ ऐसा करना चाहिए था, लेकिन नहीं किया गया
- रूसी crewed reconnaissance space station Almaz: बेहतरीन technical design था, लेकिन launch के बाद computer-controlled reconnaissance satellites के कारण पुराना पड़ गया
- शुरुआती 'automobiles'
नियम 12 — एक ही सही जवाब नहीं होता
- "There is never a single right solution. There are always multiple wrong ones, though."
- एक ही सही solution कभी नहीं होता, लेकिन कई गलत solutions हमेशा होते हैं
- खुला दृष्टिकोण बनाए रखें
- engineering कोई धर्म नहीं है
- technical apostasy पूरी तरह स्वीकार्य है
- उदाहरण: mechanical automatic calculation
- द्वितीय विश्व युद्ध में यही मुख्यधारा का तरीका था
- digital hardware को इस क्षेत्र पर हावी होने में 1960s तक का समय लगा
नियम 13 — requirements-based design
- "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
- design requirements पर आधारित होता है; requirements जितना कहती हैं, उससे एक bit भी 'बेहतर' डिज़ाइन करने का कोई औचित्य नहीं है
- ग्राहक ऐसी features के लिए भुगतान करना पसंद नहीं करते जिनकी उन्हें जरूरत नहीं है
- application के लिए जरूरी reliability ढूँढें और उसी स्तर के अनुसार design करें
- कहना आसान है, करना मुश्किल
नियम 14 (Edison का नियम) — 'बेहतर' 'अच्छे' का दुश्मन है
- "'Better' is the enemy of 'good'."
- 'बेहतर' 'अच्छे' का दुश्मन है
- वास्तव में यह Voltaire का उद्धरण है
- यह पहचानना चाहिए कि सिस्टम कब पर्याप्त अच्छा (good enough) हो चुका है
- पूर्णता के लिए अनंत संसाधनों की ज़रूरत होती है, इसलिए सिस्टम को हमेशा और बेहतर बनाया जा सकता है
- नियम 13 देखें
नियम 15 (Shea का नियम) — इंटरफ़ेस ही कुंजी है
- "The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up."
- डिज़ाइन को बेहतर बनाने की क्षमता मुख्यतः इंटरफ़ेस पर पैदा होती है, और इसे बिगाड़ने की सबसे बड़ी जगह भी यही है
- ऐसे इंजीनियर/तकनीशियन बहुत हैं जो एक सिस्टम को वास्तव में अच्छी तरह समझते हैं
- लेकिन कई अलग-अलग सिस्टमों को वास्तव में अच्छी तरह समझने वाले लोग बहुत कम होते हैं
- उदाहरण: जटिल hardware और software interaction वाले सिस्टम में आमतौर पर समस्या इंटरफ़ेस पर होती है
नियम 16 — पिछले विश्लेषण पर अंधविश्वास न करें
- "The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours."
- पहले ऐसे ही विश्लेषण करने वाले लोगों के पास युगों की बुद्धिमत्ता तक कोई सीधी पहुँच नहीं थी, इसलिए उनके विश्लेषण को अपने विश्लेषण से अधिक सही मानने का कोई कारण नहीं है। और खास तौर पर उनके विश्लेषण को अपना बताकर पेश करने का तो बिल्कुल भी कारण नहीं है।
नियम 17 — प्रकाशनों की सटीकता
- "The fact that an analysis appears in print has no relationship to the likelihood of its being correct."
- किसी विश्लेषण का छप जाना इस बात से बिल्कुल असंबंधित है कि उसके सही होने की संभावना कितनी है
- 1970 के दशक की एक मशहूर राय:
- "1200 baud शायद वह अधिकतम गति है, जहाँ तक telephone modem पहुँच सकता है"
- "Coding is dead" वाले कथन के लिए प्रसिद्ध
- Trellis coded modulation ने 1990 के दशक तक इस गति को 50kbps तक पहुँचा दिया
नियम 18 — पिछले अनुभव का दोहरा पहलू
- "Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though."
- पिछला अनुभव वास्तविकता की जाँच के लिए बेहतरीन है, लेकिन बहुत ज़्यादा वास्तविकता किसी और तरह से मूल्यवान डिज़ाइन को भी बर्बाद कर सकती है
नियम 19 — विनम्रता का महत्व
- "The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up."
- इस बात की संभावना बहुत कम है कि आप अपने क्षेत्र के बाकी सभी लोगों से बहुत ज़्यादा बुद्धिमान हों। अगर आपका विश्लेषण कहता है कि आपकी terminal velocity प्रकाश की गति से दोगुनी है, तो हो सकता है आपने warp drive खोज लिया हो, लेकिन इसकी संभावना कहीं अधिक है कि आपसे कोई गलती हुई है।
नियम 20 — प्रेज़ेंटेशन का महत्व
- "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
- अच्छे प्रेज़ेंटेशन वाला खराब डिज़ाइन आखिरकार विफल होगा, और खराब प्रेज़ेंटेशन वाला अच्छा डिज़ाइन तुरंत विफल होगा
- उदाहरण: Avro C102 — दुनिया का दूसरा commercial jet airliner (13 दिन के अंतर से)
- Avro Arrow development को समर्थन देने के लिए इसे रद्द कर दिया गया
नियम 21 — शिक्षा का सार
- "Half of everything you hear in a classroom is crap. Education is figuring out which half is which."
- कक्षा में जो कुछ भी आप सुनते हैं, उसका आधा बेकार होता है; शिक्षा का अर्थ है समझना कि कौन-सा आधा कौन-सा है
- इसका मतलब यह नहीं कि प्रोफ़ेसर जानबूझकर 50% समय बर्बाद करना चाहते हैं
- तेज़ी से बदलते और विकसित होते क्षेत्रों में यह अनुमान लगाना कि कौन-सी skills ज़रूरी होंगी
- उदाहरण: quantum computing
- यह या तो अगले 20 वर्षों तक इंजीनियर के रूप में काम करने के लिए आवश्यक ज्ञान हो सकता है, या फिर 2030 के दशक तक सिर्फ़ शैक्षणिक रुचि का विषय रह सकता है
नियम 22 — दस्तावेज़ीकरण का महत्व
- "When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)"
- संदेह हो तो दस्तावेज़ बनाइए। (Documentation requirements किसी program के समाप्त होने के तुरंत बाद अपने चरम पर पहुँचती हैं।)
- अगर आप समस्या हल नहीं कर सकते, तो अपनी अज्ञानता छिपाइए मत
- समस्या के कारण को दस्तावेज़ित करें
- हो सकता है कोई दूसरा व्यक्ति उसे हल करने का तरीका ढूँढ़ ले
नियम 23 — शेड्यूल की काल्पनिकता
- "The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it."
- आपका बनाया हुआ शेड्यूल पूरी तरह काल्पनिक लगेगा, जब तक कि ग्राहक आपको उसे पूरा न कर पाने के लिए निकाल न दे
नियम 24 — Work Breakdown Structure
- "It's called a 'Work Breakdown Structure' because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it."
- इसे 'Work Breakdown Structure' इसलिए कहा जाता है, क्योंकि अगर आप उस पर कोई Structure लागू नहीं करते, तो बचा हुआ Work तब तक बढ़ता रहेगा जब तक आपका Breakdown न हो जाए
नियम 25 (Bowden का नियम) — टेस्ट विफलता के बाद विश्लेषण
- "Following a testing failure, it's always possible to refine the analysis to show that you had negative margins all along."
- किसी test failure के बाद विश्लेषण को इस तरह refine करना हमेशा संभव है कि यह दिखाया जा सके कि शुरू से ही margins negative थे
- उदाहरण: Canadian Transportation Accident Investigation and Safety Board तथा Federal Aviation Administration (FAA) की accident reports
- कुछ विफलताएँ कल्पनाशक्ति की कमी के कारण होती हैं (Frank Borman का परिभाषित कथन)
- इंजीनियर के लिए गलती करना माफ़ किया जा सकता है, लेकिन गलती छिपाना माफ़ नहीं किया जाता
नियम 26 (Montemerlo का नियम) — बेवकूफ़ी मत करो
- "Don't do nuthin' dumb."
- engineering practice में यह हैरान करने वाला कठिन नियम है
- बुनियादी बातों को मत भूलिए
- अपने लिए प्राथमिकताएँ स्पष्ट रखें
नियम 27 (Varsi का नियम) — शेड्यूल सिर्फ़ एक दिशा में चलता है
- "Schedules only move in one direction."
- शेड्यूल सिर्फ़ एक ही दिशा में आगे बढ़ता है
- समस्याओं और कठिनाइयों के लिए कुछ अतिरिक्त गुंजाइश छोड़ें
- test failure
- बाद में family emergency
- हो सकता है किसी और की गलती के बिना भी कोई दूसरा व्यक्ति ज़रूरी product देर से डिलीवर करे
- हमेशा अपने और अपनी टीम के लिए शेड्यूल में buffer रखें
नियम 28 (Ranger का नियम) — मुफ़्त launch जैसी कोई चीज़ नहीं
- "There ain't no such thing as a free launch."
- मुफ़्त launch जैसी कोई चीज़ नहीं होती
नियम 29 (von Tiesenhausen का program management नियम) — लागत और समय का अनुमान
- "अंतिम program requirements का सटीक अनुमान पाने के लिए, शुरुआती समय के अनुमानों को pi से गुणा करें, और cost estimates में decimal point को एक स्थान दाईं ओर खिसका दें।"
- अंतिम program requirements का सटीक अनुमान पाने के लिए, शुरुआती समय के अनुमानों को π से गुणा करें, और cost estimates में decimal point को दाईं ओर एक स्थान खिसका दें
नियम 30 (von Tiesenhausen का engineering design नियम) — artist concept का प्रभाव
- "अगर आप किसी नए engineering system के design पर अधिकतम प्रभाव डालना चाहते हैं, तो drawing करना सीखें। Engineers आखिरकार vehicle को हमेशा शुरुआती artist's concept जैसा दिखने वाला ही design कर देते हैं।"
- अगर आप किसी नए engineering system के design पर अधिकतम प्रभाव डालना चाहते हैं, तो drawing करना सीखें; engineers आखिरकार vehicle को हमेशा शुरुआती artist concept जैसा दिखने वाला ही design कर देते हैं
नियम 31 (Mo का evolutionary development नियम) — तकनीक की मूलभूत सीमाएँ
- "आप लगातार और ऊँचे पेड़ों पर चढ़कर चाँद तक नहीं पहुँच सकते।"
- लगातार और ऊँचे पेड़ों पर चढ़ने से चाँद तक नहीं पहुँचा जा सकता
- तकनीक/approach की मूलभूत सीमाओं को समझना उपयोगी है
नियम 32 (Atkin का demo नियम) — Murphy's Law
- "जब hardware बिल्कुल सही काम कर रहा होता है, तब सचमुच महत्वपूर्ण visitor आते ही नहीं हैं।"
- जब hardware पूरी तरह सही काम कर रहा होता है, तब सचमुच महत्वपूर्ण visitor दिखाई नहीं देते
नियम 33 (Patton का program planning नियम) — execution का महत्व
- "अगले हफ्ते की एक perfect plan से बेहतर है एक अच्छी plan, जिसे अभी ज़ोरदार तरीके से execute किया जाए।"
- अभी ज़ोरदार तरीके से execute की गई एक अच्छी plan, अगले हफ्ते की perfect plan से बेहतर है
- उद्योग में गलती: 'perfect' तकनीक का इंतज़ार करना
- इंतज़ार करते-करते competitor बाज़ार पर कब्ज़ा कर लेता है
नियम 34 (Roosevelt का task planning नियम) — व्यावहारिक execution
- "जो कर सकते हो, जहाँ हो, जो तुम्हारे पास है उसी के साथ करो।"
- जहाँ हो, जो तुम्हारे पास है, उसी से जो कर सकते हो वह करो
- जब तक आप SF writer नहीं हैं, ऐसी तकनीक के लिए design करना जो अस्तित्व में ही नहीं है, निरर्थक है
नियम 35 (de Saint-Exupéry का design नियम) — perfect design
- "एक designer जानता है कि उसने perfection तब हासिल की है जब जोड़ने के लिए कुछ नहीं बचा हो, बल्कि तब जब हटाने के लिए कुछ भी नहीं बचा हो।"
- designer जानता है कि perfection तब हासिल होती है जब हटाने के लिए कुछ भी नहीं बचता
नियम 36 — elegance, efficiency, effectiveness
- "कोई भी साधारण engineer कुछ ऐसा design कर सकता है जो elegant हो। एक अच्छा engineer systems को efficient बनाता है। एक महान engineer उन्हें effective बनाता है।"
- एक साधारण engineer elegant चीज़ design कर सकता है, एक अच्छा engineer efficient systems design करता है, और एक महान engineer effective systems design करता है
- उत्कृष्ट design (Elegant design): मानक शहरी जलापूर्ति प्रणाली
- कुशल design (Efficient design): New York जलापूर्ति प्रणाली
- प्रभावी design (Effective design): उत्तर/दक्षिण अमेरिका की indigenous civilizations की irrigation systems (कुछ 1000 साल से भी अधिक समय से काम कर रही हैं)
नियम 37 (Henshaw का नियम) — ज़िम्मेदारी की स्पष्ट रेखा
- "किसी mission में सफलता की एक कुंजी है blame की स्पष्ट lines स्थापित करना।"
- किसी mission की सफलता की एक कुंजी है ज़िम्मेदारी की स्पष्ट रेखाएँ स्थापित करना
- अपने actions और decisions की ज़िम्मेदारी लेनी चाहिए
- जो engineer (या कोई भी व्यक्ति) ज़िम्मेदारी लेने से इनकार करे, उस पर भरोसा न करें
नियम 38 — capabilities requirements को drive करती हैं
- "Systems engineering की textbooks चाहे जो कहें, capabilities ही requirements को drive करती हैं।"
- systems engineering textbooks चाहे जो कहें, capabilities ही requirements को drive करती हैं
- मुख्य बात यह पहचानना है कि कौन-सी नई capabilities विकसित हो रही हैं:
- 1950s: transistor
- 1960s: integrated circuits
- 1970s: microprocessor
- 1980s: home computer
- 1990s: internet
- 2000s: wireless/mobile computing
नियम 39 — नया launch vehicle विकसित मत करो
- किसी नए crewed space program को सस्ता और schedule पर बनाए रखने की तीन मुख्य बातें:
- नया launch vehicle नहीं
- नया launch vehicle नहीं
- चाहे कुछ भी हो जाए, नया launch vehicle विकसित करने का फैसला मत करो
- इस प्रलोभन से बचना चाहिए कि पूरी तरह नया product हमेशा मौजूदा product के evolution से बेहतर होगा
नियम 40 — अंतरिक्ष माफ़ नहीं करता
- "Space पूरी तरह unforgiving environment है। अगर आप engineering गड़बड़ कर देते हैं, तो कोई मरता है (और ज़्यादातर analysis सही होने पर भी कोई partial credit नहीं मिलता...)"
- अंतरिक्ष पूरी तरह unforgiving environment है; अगर engineering बिगड़ जाए, तो कोई मरता है (और ज़्यादातर analysis सही होने पर भी कोई partial credit नहीं मिलता)
- बड़े engineering control disasters:
- Fukushima, Chernobyl
- De Havilland Comet (इसी वजह से commercial airliner की windows में rounded corners होते हैं)
- Eastern Airline Flight 401 (autopilot ने commercial aircraft को Everglades की ओर मोड़ दिया)
- Therac-25 (कनाडाई radiation therapy device)
- Richard Feynman का आशय: "प्रकृति को धोखा नहीं दिया जा सकता (Nature cannot be fooled)"
अभी कोई टिप्पणी नहीं है.