- สไลด์ที่สรุปหลักการเชิงปฏิบัติ 40 ข้อที่ใช้กับการออกแบบยานอวกาศและโครงการวิศวกรรม
- เน้น การวิเคราะห์บนฐานตัวเลข, การออกแบบแบบวนซ้ำ, และ การออกแบบที่ยอมรับความขัดข้องได้ เป็นหลักการสำคัญ
- มีคำเตือนตามความเป็นจริงว่า กำหนดการเดินหน้าได้เพียงทิศทางเดียว และการประเมินช่วงต้นมักจะ ต่ำกว่าความเป็นจริง เสมอ
- นำไปใช้ได้ตรงตัวไม่ใช่แค่วิศวกรรมอวกาศ แต่รวมถึง ซอฟต์แวร์·ระบบ·การออกแบบสตาร์ตอัปโดยรวม
- เช็กลิสต์ที่ใช้งานได้จริงเพื่อป้องกันข้อผิดพลาดที่เกิดซ้ำในการตัดสินใจทางวิศวกรรม
กฎข้อ 1 — วิศวกรรมที่พิสูจน์ได้ด้วยตัวเลข
- "Engineering is done with numbers. Analysis without numbers is only an opinion."
- วิศวกรรมทำด้วยตัวเลข การวิเคราะห์ที่ไม่มีตัวเลขก็เป็นเพียงความคิดเห็น
- เหตุผลที่นักวิศวกรรมต้องใช้เวลามากในการเรียนคณิตศาสตร์
- ความสำเร็จทางวิศวกรรมต้อง วัดเชิงปริมาณได้
- "ระบบของฉันเร็วกว่า" → เร็วกว่าเท่าไร?
- "ระบบของฉันถูกกว่า" → ต้นทุนเท่าไร?
- "ระบบของฉันเรียบง่ายกว่า" → จะวัดความเรียบง่ายอย่างไร?
กฎข้อ 2 — การออกแบบที่ยอมรับความขัดข้องได้
- "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%
- ตัวอย่างความล้มเหลว: Deep Water Horizon, ฟุกุชิมะ
- ตัวอย่างวิธี ตรวจสอบตรรกะแบบสามชุด (3 way logic checking) ในระบบควบคุมอากาศยาน
กฎข้อ 3 — กระบวนการออกแบบแบบวนซ้ำ
- "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."
- การออกแบบเป็นกระบวนการแบบวนซ้ำ และจำนวนรอบที่จำเป็นจะมากกว่าจำนวนรอบที่ทำไปแล้วอยู่หนึ่งเสมอ
- การออกแบบที่ดีไม่มีวันเสร็จสมบูรณ์
กฎข้อ 4 — การรับมือกับความผิดหวัง
- "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
- ความพยายามในการออกแบบที่ดีที่สุดของคุณอาจลงเอยด้วยการไร้ประโยชน์ในแบบสุดท้ายอย่างหลีกเลี่ยงไม่ได้ จงเรียนรู้ที่จะอยู่กับความผิดหวัง
- กฎของ Bhargava: โครงการวิจัย 10 โครงการ มีเพียง 1 โครงการที่นำไปใช้ในงานอุตสาหกรรมจริง
- ความสำเร็จเชิงพาณิชย์สูงสุดไม่ได้หมายความว่าเป็นการออกแบบทางเทคนิคที่ดีที่สุด
- ตัวอย่าง: Nokia N95 เทียบกับ iPhone รุ่นแรก
กฎข้อ 5 (กฎของ Miller) — สามจุดกำหนดเส้นโค้ง
- "Three points determine a curve."
- เรามักจะ มองหารูปแบบ ในชุดข้อมูลเสมอ
- ต้องตรวจสอบว่ารูปแบบนั้นเกิดจาก ปรากฏการณ์จริงที่ศึกษาอยู่ ไม่ใช่สัญญาณรบกวนจากการวัด
- วงวิชาการและนักศึกษาบัณฑิตศึกษามีแนวโน้มจะละเลยกฎข้อนี้เป็นพิเศษ
กฎข้อ 6 (กฎของ Mar) — ระวังการฟิตข้อมูลเกิน
- "Everything is linear if plotted log-log with a fat magic marker."
- ทุกอย่างดูเป็นเส้นตรงได้ ถ้าวาดกราฟ log-log ด้วยปากกาเมจิกหัวหนา
- กฎของ Bigg: "อย่าไปหลงรักเครื่องมือทางคณิตศาสตร์ เพราะมันไม่รักตอบ"
- ห้ามทำข้อมูลฟิตเกิน (over-fit)
กฎข้อ 7 — ภาวะผู้นำและการสร้างทีม
- "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
- เมื่อเริ่มโครงการออกแบบ คนที่อยากเป็นหัวหน้าทีมมากที่สุดมักมีโอกาสน้อยที่สุดที่จะเหมาะกับบทบาทนั้น
- การ์ตูน Dilbert อ้างอิงจากประสบการณ์จริงในบริษัทวิศวกรรม เพียงแต่ขยายให้เกินจริงเล็กน้อย
- ภาวะผู้นำบางส่วนเป็นพรสวรรค์ แต่ส่วนสำคัญนั้น ต้องเรียนรู้
- มีผู้จัดการที่ไม่สามารถ 'เคารพพื้นฐาน (respect the basics)' ได้
- ลองถามวิศวกรอุตสาหการเกี่ยวกับ MBA
กฎข้อ 8 — จุดเหมาะสมที่สุดอยู่ตรงกลาง
- "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
- ในธรรมชาติ จุดที่เหมาะสมที่สุดมักอยู่แถวกลาง ๆ เสมอ จงระวังคำกล่าวอ้างว่าจุดเหมาะสมที่สุดอยู่ที่ปลายสุดด้านใดด้านหนึ่ง
- ตัวอย่างมาตรฐาน: การส่งผ่านกำลังไฟฟ้าที่เหมาะสมที่สุด (Optimal power transfer)
- ตัวอย่างภาคปฏิบัติ: ความต้านทานของเซนเซอร์ที่เหมาะสมที่สุด (optimal sensor resistance)
กฎข้อ 9 — การมีข้อมูลไม่พอไม่ใช่ข้ออ้าง
- "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
- การไม่มีข้อมูลครบทั้งหมดที่ต้องใช้ ไม่เคยเป็นข้ออ้างที่ดีพอสำหรับการไม่เริ่มวิเคราะห์
- ต้องระบุให้ได้ว่า ต้องใช้ค่าอะไรบ้าง เพื่อให้วิเคราะห์ได้ครบถ้วนยิ่งขึ้น
กฎข้อ 10 — การประมาณกับการเดา
- "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."
- เมื่อไม่แน่ใจให้ประมาณการ ในภาวะฉุกเฉินให้เดาได้ แต่เมื่อมีตัวเลขจริงแล้วต้องกลับมาเก็บกวาดให้เรียบร้อยเสมอ
- คุณถูกฝึกมาให้เป็นวิศวกร ไม่ใช่ หมอดู
- ในอาชีพนี้ การคิดอย่างมีคุณภาพสำคัญกว่าการคิดให้เร็ว
กฎข้อ 11 — เริ่มใหม่ตั้งแต่ต้น
- "Sometimes, the fastest way to get to the end is to throw everything out and start over."
- บางครั้งวิธีที่เร็วที่สุดในการไปถึงจุดจบ คือทิ้งทุกอย่างแล้วเริ่มต้นใหม่
- การเรียนรู้ว่าเมื่อไรควรทำแบบนี้ ต้องใช้เวลา
- หลายอุตสาหกรรมมีกรณีที่ควรทำแบบนี้แต่ไม่ได้ทำ
- สถานีอวกาศลาดตระเวนมีมนุษย์ประจำการ Almaz ของรัสเซีย: เป็นการออกแบบทางเทคนิคที่ยอดเยี่ยม แต่หลังปล่อยขึ้นไปก็ล้าสมัยเพราะดาวเทียมลาดตระเวนที่ควบคุมด้วยคอมพิวเตอร์
- 'รถยนต์' ยุคแรก ๆ
กฎข้อ 12 — ไม่มีคำตอบที่ถูกเพียงหนึ่งเดียว
- "There is never a single right solution. There are always multiple wrong ones, though."
- ไม่มีทางมีคำตอบที่ถูกเพียงแบบเดียว แต่มีคำตอบที่ผิดได้หลายแบบเสมอ
- เปิดใจกว้างไว้
- วิศวกรรมไม่ใช่ศาสนา
- การนอกรีตทางเทคนิค (Technical apostasy) เป็นสิ่งที่ยอมรับได้อย่างเต็มที่
- ตัวอย่าง: การคำนวณอัตโนมัติแบบกลไก
- เป็นแนวทางหลักในสงครามโลกครั้งที่ 2
- ต้องรอถึงทศวรรษ 1960 กว่าฮาร์ดแวร์ดิจิทัลจะครองพื้นที่นี้ได้
กฎข้อ 13 — การออกแบบบนฐานข้อกำหนด
- "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
- การออกแบบตั้งอยู่บนข้อกำหนด ไม่มีเหตุผลใดที่ชอบธรรมในการออกแบบอะไรให้ 'ดีกว่า' ที่ข้อกำหนดระบุแม้แต่น้อย
- ลูกค้า ไม่ชอบจ่ายเงินให้ฟีเจอร์ที่ไม่จำเป็น
- ต้องหาความเชื่อถือได้ที่แอปพลิเคชันนั้นต้องการ และออกแบบให้สอดคล้องกับระดับความเชื่อถือได้นั้น
กฎข้อ 14 (กฎของ Edison) — 'ดีกว่า' คือศัตรูของ 'ดี'
- "'ดีกว่า' คือศัตรูของ 'ดี'."
- 'ดีกว่า' คือศัตรูของ 'ดี'
- ที่จริงแล้วเป็น คำคมของ 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."
- ความสามารถในการปรับปรุงแบบออกแบบมักเกิดขึ้นที่อินเทอร์เฟซเป็นหลัก และที่นี่ก็เป็นจุดหลักที่ทำให้พังได้เช่นกัน
- มีวิศวกร/ช่างเทคนิคจำนวนมากที่เข้าใจระบบหนึ่งระบบได้อย่างลึกซึ้งจริง ๆ
- แต่คนที่เข้าใจหลายระบบที่แตกต่างกันได้อย่างลึกซึ้งจริง ๆ นั้นหายาก
- ตัวอย่าง: ระบบที่มีปฏิสัมพันธ์ซับซ้อนระหว่างฮาร์ดแวร์กับซอฟต์แวร์ มักเกิดปัญหาที่อินเทอร์เฟซ
กฎข้อ 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 น่าจะเป็นความเร็วสูงสุดที่โทรศัพท์โมเด็มจะไปถึงได้"
- เป็นที่รู้จักจากคำพูด "Coding is dead"
- Trellis coded modulation ดันความเร็วนี้ขึ้นไปถึง 50kbps ภายในยุค 1990
กฎข้อ 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."
- โอกาสที่คุณจะฉลาดกว่าทุกคนในสาขานี้อย่างมหาศาลนั้นต่ำมาก หากผลวิเคราะห์ของคุณบอกว่าความเร็วปลายทางของคุณเป็นสองเท่าของความเร็วแสง คุณอาจประดิษฐ์ 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 — เครื่องบินโดยสารเจ็ตเชิงพาณิชย์ลำที่สองของโลก (ห่างกัน 13 วัน)
- ถูกยกเลิกเพื่อสนับสนุนการพัฒนา Avro Arrow
กฎข้อ 21 — แก่นแท้ของการศึกษา
- "Half of everything you hear in a classroom is crap. Education is figuring out which half is which."
- ครึ่งหนึ่งของทุกสิ่งที่คุณได้ยินในห้องเรียนเป็นเรื่องไร้สาระ การศึกษาคือการแยกให้ออกว่าครึ่งไหนเป็นครึ่งไหน
- ไม่ใช่ว่าอาจารย์ตั้งใจจะทำให้เสียเวลา 50%
- แต่เป็นการ คาดเดาว่าทักษะใดจะจำเป็น ในสาขาที่เปลี่ยนแปลงและวิวัฒน์อย่างรวดเร็ว
- ตัวอย่าง: ควอนตัมคอมพิวติ้ง
- มันอาจเป็นความรู้จำเป็นสำหรับการทำงานเป็นวิศวกรในอีก 20 ปีข้างหน้า หรืออาจยังเป็นเพียงเรื่องที่วงวิชาการสนใจไปจนถึงช่วงทศวรรษ 2030
กฎข้อ 22 — ความสำคัญของการทำเอกสาร
- "When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a 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 — โครงสร้างการแบ่งงาน
- "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' ก็เพราะถ้าคุณไม่บังคับให้มันมีโครงสร้าง งานที่เหลือจะเพิ่มขึ้นเรื่อย ๆ จนคุณ Breakdown
กฎข้อ 25 (กฎของ Bowden) — วิเคราะห์หลังการทดสอบล้มเหลว
- "Following a testing failure, it's always possible to refine the analysis to show that you had negative margins all along."
- หลังการทดสอบล้มเหลว เราสามารถปรับการวิเคราะห์ให้แสดงได้เสมอว่าที่จริงแล้วคุณมีค่ามาร์จินติดลบมาตั้งแต่แรก
- ตัวอย่าง: คณะกรรมการความปลอดภัยในการสอบสวนอุบัติเหตุการขนส่งของแคนาดา และรายงานอุบัติเหตุของ Federal Aviation Administration (FAA)
- ความล้มเหลวบางอย่างเกิดจาก การขาดจินตนาการ (ถอดความจาก Frank Borman)
- วิศวกรอาจได้รับการให้อภัยเมื่อทำผิดพลาด แต่ จะไม่ได้รับการให้อภัยเมื่อปกปิดความผิดพลาด
กฎข้อ 26 (กฎของ Montemerlo) — อย่าทำอะไรโง่ ๆ
- "Don't do nuthin' dumb."
- เป็นกฎที่ ทำตามได้ยากอย่างน่าประหลาดใจ ในงานวิศวกรรมจริง
- อย่าลืมพื้นฐาน
- จัดลำดับความสำคัญให้ตัวเองอย่างชัดเจน
กฎข้อ 27 (กฎของ Varsi) — ตารางเวลาขยับได้ทางเดียว
- "Schedules only move in one direction."
- ตารางเวลาขยับได้เพียงทิศทางเดียว
- ควรเผื่อ เวลา buffer ไว้สำหรับปัญหาและความยากลำบาก
- การทดสอบล้มเหลว
- หรือภายหลังอาจมีเหตุฉุกเฉินในครอบครัว
- คนอื่นอาจ ส่งมอบผลิตภัณฑ์ที่จำเป็นล่าช้า ทั้งที่ไม่ใช่ความผิดของคุณ
- จงเผื่อ ช่องว่างของตารางเวลา ไว้ให้ตัวเองและทีมเสมอ
กฎข้อ 28 (กฎของ Ranger) — ไม่มีการปล่อยจรวดฟรี
- "There ain't no such thing as a free launch."
- ไม่มีอะไรอย่างการปล่อยจรวดฟรี
กฎข้อ 29 (กฎการบริหารโปรแกรมของ von Tiesenhausen) — การประเมินต้นทุนและเวลา
- "หากต้องการประมาณข้อกำหนดสุดท้ายของโครงการให้แม่นยำ ให้นำค่าประมาณเวลาเริ่มต้นคูณด้วย pi แล้วเลื่อนจุดทศนิยมของค่าประมาณต้นทุนไปทางขวาหนึ่งตำแหน่ง"
- หากต้องการได้ค่าประมาณข้อกำหนดสุดท้ายของโครงการอย่างแม่นยำ ให้นำค่าประมาณเวลาเริ่มต้น คูณด้วย π และเลื่อนจุดทศนิยมของค่าประมาณต้นทุน ไปทางขวาหนึ่งตำแหน่ง
กฎข้อ 30 (กฎการออกแบบทางวิศวกรรมของ von Tiesenhausen) — อิทธิพลของ artist's concept
- "If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept."
- หากคุณต้องการมีอิทธิพลสูงสุดต่อการออกแบบระบบวิศวกรรมใหม่ จงเรียนการวาดรูป เพราะท้ายที่สุดแล้ววิศวกรมักลงเอยด้วยการออกแบบยานพาหนะให้มีหน้าตาเหมือนคอนเซปต์ของศิลปินตั้งแต่แรก
กฎข้อ 31 (กฎการพัฒนาเชิงวิวัฒนาการของ Mo) — ข้อจำกัดพื้นฐานของเทคโนโลยี
- "You can't get to the moon by climbing successively taller trees."
- คุณไม่สามารถไปถึงดวงจันทร์ได้ด้วยการปีนต้นไม้ที่สูงขึ้นเรื่อย ๆ
- การเข้าใจ ข้อจำกัดพื้นฐานของเทคโนโลยี/แนวทาง เป็นสิ่งที่มีประโยชน์
กฎข้อ 32 (กฎการเดโมของ Atkin) — กฎของเมอร์ฟี
- "When the hardware is working perfectly, the really important visitors don't show up."
- เมื่อฮาร์ดแวร์ทำงานได้อย่างสมบูรณ์แบบ แขกคนสำคัญจริง ๆ กลับไม่ปรากฏตัว
กฎข้อ 33 (กฎการวางแผนโปรแกรมของ Patton) — ความสำคัญของการลงมือทำ
- "A good plan violently executed now is better than a perfect plan next week."
- แผนที่ดีและถูกดำเนินการอย่างเด็ดขาดในตอนนี้ ดีกว่าแผนที่สมบูรณ์แบบในสัปดาห์หน้า
- ความผิดพลาดในอุตสาหกรรม: การรอเทคโนโลยีที่ 'สมบูรณ์แบบ'
- ระหว่างที่รอ คู่แข่งก็ยึดครองตลาดไปแล้ว
กฎข้อ 34 (กฎการวางแผนภารกิจของ Roosevelt) — การลงมือทำอย่างสมจริง
- "Do what you can, where you are, with what you have."
- จงทำในสิ่งที่คุณทำได้ ณ ที่ที่คุณอยู่ ด้วยสิ่งที่คุณมี
- เว้นแต่คุณจะเป็นนักเขียน SF การออกแบบเพื่อเทคโนโลยีที่ ยังไม่มีอยู่จริง ก็ไม่มีความหมาย
กฎข้อ 35 (กฎการออกแบบของ de Saint-Exupéry) — การออกแบบที่สมบูรณ์แบบ
- "A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
- นักออกแบบจะรู้ว่าตนบรรลุความสมบูรณ์แบบแล้ว ไม่ใช่เมื่อไม่มีอะไรให้เพิ่มอีก แต่คือเมื่อ ไม่มีอะไรให้ตัดออกอีกต่อไป
กฎข้อ 36 — ความสง่างาม ประสิทธิภาพ และประสิทธิผล
- "Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective."
- วิศวกรทั่วไปสามารถออกแบบสิ่งที่ดูสง่างามได้ วิศวกรที่ดีออกแบบระบบให้มีประสิทธิภาพ และวิศวกรที่ยอดเยี่ยมออกแบบให้เกิดประสิทธิผล
- การออกแบบที่สง่างาม (Elegant design): ระบบประปาเทศบาลมาตรฐาน
- การออกแบบที่มีประสิทธิภาพ (Efficient design): ระบบประปาของนิวยอร์ก
- การออกแบบที่มีประสิทธิผล (Effective design): ระบบชลประทานของอารยธรรมชนพื้นเมืองในอเมริกาเหนือ/อเมริกาใต้ (บางส่วนยังทำงานมาแล้วกว่า 1,000 ปี)
กฎข้อ 37 (กฎของ Henshaw) — เส้นแบ่งความรับผิดชอบที่ชัดเจน
- "One key to success in a mission is establishing clear lines of blame."
- กุญแจข้อหนึ่งของความสำเร็จในภารกิจ คือการกำหนดเส้นแบ่งความรับผิดชอบให้ชัดเจน
- ต้อง รับผิดชอบ ต่อการกระทำและการตัดสินใจของตนเอง
- อย่า ไว้วางใจ วิศวกรที่ปฏิเสธจะรับผิดชอบ (หรือใครก็ตาม)
กฎข้อ 38 — ขีดความสามารถเป็นตัวกำหนดข้อกำหนด
- "Capabilities drive requirements, regardless of what the systems engineering textbooks say."
- ไม่ว่าตำราวิศวกรรมระบบจะว่าอย่างไร ขีดความสามารถต่างหากที่เป็นตัวกำหนดข้อกำหนด
- ประเด็นสำคัญคือการรับรู้ว่ากำลังมีการพัฒนา ขีดความสามารถใหม่อะไรบ้าง:
- ทศวรรษ 1950: ทรานซิสเตอร์
- ทศวรรษ 1960: วงจรรวม
- ทศวรรษ 1970: ไมโครโปรเซสเซอร์
- ทศวรรษ 1980: คอมพิวเตอร์ภายในบ้าน
- ทศวรรษ 1990: อินเทอร์เน็ต
- ทศวรรษ 2000: การประมวลผลแบบไร้สาย/โมบายล์
กฎข้อ 39 — ห้ามพัฒนาจรวดส่งใหม่
- กุญแจสำคัญ 3 ข้อในการทำให้โครงการอวกาศแบบมีมนุษย์โดยสารใหม่มีต้นทุนต่ำและเป็นไปตามกำหนดการ:
- ไม่มีจรวดส่งแบบใหม่
- ไม่มีจรวดส่งแบบใหม่
- ไม่ว่าจะเกิดอะไรขึ้น ก็อย่าตัดสินใจพัฒนาจรวดส่งแบบใหม่
- ต้องหลีกเลี่ยง สิ่งยั่วยวน ที่ทำให้เชื่อว่าผลิตภัณฑ์ใหม่ทั้งหมดจะดีกว่าวิวัฒนาการต่อยอดจากของเดิมเสมอ
กฎข้อ 40 — อวกาศไม่ให้อภัย
- "Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...)"
- อวกาศเป็นสภาพแวดล้อมที่ไม่ให้อภัยอย่างสิ้นเชิง หากคุณทำงานวิศวกรรมพลาด ใครบางคนต้องตาย (และไม่มีคะแนนปลอบใจเพียงเพราะการวิเคราะห์ส่วนใหญ่ถูกต้อง...)
- ตัวอย่างหายนะจากการควบคุมทางวิศวกรรมขนาดใหญ่:
- Fukushima, Chernobyl
- De Havilland Comet (เหตุผลที่หน้าต่างเครื่องบินโดยสารเชิงพาณิชย์มีมุมโค้งมน)
- Eastern Airline Flight 401 (ระบบอัตโนมัติพาเครื่องบินพาณิชย์มุ่งสู่ Everglades)
- Therac-25 (อุปกรณ์รังสีบำบัดของแคนาดา)
- ถอดความคำพูดของ Richard Feynman: "Nature cannot be fooled"
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
คำกล่าวที่ว่าในยุค 1990 สามารถดันความเร็วขึ้นไปถึง 50 กิโลบอด ด้วย Trellis coded modulation นั้นไม่ค่อยตรงนัก
Shannon capacity ที่คำนวณจากแบนด์วิดท์และคุณสมบัติ SNR ของสายโทรศัพท์อยู่ราว ๆ 30kb/s และโมเด็ม V.34 ก็เข้าใกล้ขีดจำกัดนั้นจนไปได้ถึง 33.6kb/s
แต่หลังยุค 80 เครือข่ายโทรศัพท์ก็กลายเป็นดิจิทัลไปแล้วเกือบทั้งหมด ยกเว้นช่วง ‘last mile’
ถ้าโมเด็มฝั่ง ISP ส่งสัญญาณเสียงดิจิทัลออกโดยตรง ก็จะเป็นไปได้ในทางทฤษฎีที่จะไปถึง 64kb/s แต่ในทางปฏิบัติถูกจำกัดโดยข้อกำหนดกำลังส่งของ FCC จึงได้ราว 53kb/s
ตอนนั้นฉันทำงานในทีมวิจัยการมอดูเลตของโมเด็ม และต้องใช้เวลาพอสมควรกว่าที่วิศวกรซึ่งคุ้นกับแนวคิดแบบอนาล็อกจะตระหนักถึงศักยภาพของช่องสัญญาณดิจิทัล
หลังจากนั้นพวกเขาก็ย้ายไปทำเคเบิลโมเด็มและกลับเข้าสู่โลกอนาล็อกอีกครั้ง
ถ้าช่วงถึงบ้านยังเป็นอนาล็อกอยู่ มันก็ยังติด ขีดจำกัด Shannon-Nyquist ไม่ใช่หรือ?
ถ้าระหว่างโมเด็ม ISP กับโมเด็มที่บ้านเป็นสายทองแดงแบบไม่มีฟิลเตอร์ แบบนั้นก็น่าจะ ส่งด้วย UART ได้ระดับหลาย Mbps ไม่ใช่หรือ?
อยากให้ช่วยอธิบายส่วนนี้ให้ชัดขึ้นอีกหน่อย
เป็นผลจากเทคนิคการเข้ารหัสและบีบอัดหลายอย่างรวมถึง Trellis coding และทุกวันนี้ก็ยังซื้อ โมเด็ม 56k ของ US Robotics ได้
Law 20 สะท้อนความจริงของสตาร์ทอัพยุคนี้ได้แม่นมาก
อย่างคำว่า “ดีไซน์ที่ดีถ้าเจอกับการนำเสนอที่แย่ก็พังทันที” แสดงให้เห็นว่า ความสำคัญของการสื่อสารนำเสนอ นั้นเป็นเรื่องเด็ดขาด
การอธิบายได้ดีคือหลักฐานว่าคุณเข้าใจมันจริง
ทำให้นึกถึงคำพูดที่ว่า “ถ้าอธิบายให้เด็ก 5 ขวบฟังไม่ได้ แปลว่าคุณเองก็ยังไม่เข้าใจ”
สำหรับคำพูดที่ว่า “ความสำเร็จทางการค้าที่ใหญ่ที่สุดไม่ใช่ดีไซน์ทางเทคนิคที่ดีที่สุด”
การเปรียบเทียบ Nokia N95 กับ iPhone รุ่นแรกนั้นไม่ค่อยเหมาะนัก ฉันขอเสนอ Canyon’s Law of Design Optimization แทน — ตัวชี้วัดที่ลูกค้าต้องการกับตัวชี้วัดที่นักพัฒนาพยายาม optimize นั้นต่างกัน และอย่าพยายามโน้มน้าวว่าลูกค้าผิด
iPhone รุ่นแรกนั้น รูปทรงและอินเทอร์เฟซ ยอดเยี่ยม แต่ฟีเจอร์ยังขาดอยู่มาก ทั้ง 3G, GPS, แอปจากบุคคลที่สาม และกล้องก็ยังอ่อน
ต้องรอจน iPhone 3G ออกมาจึงประสบความสำเร็จทางการค้าอย่างแท้จริง
สไลด์สุดท้ายหายไป
ข้อความว่า “จงเพิกเฉยต่อคำแนะนำทั้งหมดข้างต้น แล้วทำสิ่งที่ถูกต้อง” คือแก่นสำคัญ
การ รักษาสมดุล ท่ามกลางคำแนะนำที่ขัดกันต่างหากคือวิศวกรรมที่แท้จริง และเป็นเป้าหมายที่ยากที่สุดทั้งในเชิงเทคนิคและเชิงสังคม
ใจความคือ “การวิเคราะห์ก่อนหน้านี้ไม่ใช่ความจริงสัมบูรณ์ และ ต้องเชื่อในการตัดสินใจของตัวเอง”
PDF นี้อาจดูใหม่ แต่ Akin’s Laws of Spacecraft Design มีมาตั้งแต่ปี 2003 แล้ว
ตรวจสอบได้จาก ลิงก์ Web Archive
แค่ดูข้อแรกก็เข้าใจได้ว่าทำไม “วิศวกรรม” ซอฟต์แวร์จึงยากจะเรียกว่าเป็นวิศวกรรมจริง ๆ
ฉันอ้าง กฎของ von Tiesenhausen มานานแล้ว
มันคือคำพูดที่ว่า “สุดท้ายวิศวกรจะออกแบบตามคอนเซปต์ของศิลปินคนแรก” ซึ่งฉันรู้สึกว่าใช้ได้เหมือนกันกับโปรเจกต์เว็บ
บ่อยครั้งคนที่เขียนเอกสารฉบับแรก หรือคนที่ ทิ้งโน้ตไว้ในการประชุม กลับเป็นคนกำหนดทิศทางของผลิตภัณฑ์
ต่อให้เรียกว่า ‘agile’ ในทางปฏิบัติก็ยัง ขึ้นกับเส้นทางที่เดินมาแล้ว
ฉันเคยเรียนวิชา capstone การออกแบบยานอวกาศ ที่ MIT ในปี 2003 แต่ไม่เคยเห็นลิสต์นี้
ตอนนั้นโปรเจกต์เน้นดาวเทียมเป็นหลัก และดูเหมือนว่าปรัชญาของ Akin จะซึมอยู่แบบไม่เป็นทางการ
วิศวกรรมอวกาศมี วัฒนธรรมการออกแบบแบบอนุรักษนิยม สูงมาก จึงพัฒนาได้ช้า และก่อนยุค Elon Musk การเปลี่ยนแปลงก็ยิ่งช้ากว่านี้
โดยเฉพาะประโยคที่ว่า “อวกาศเป็นสภาพแวดล้อมที่ไม่ให้อภัย และ ความล้มเหลวทางวิศวกรรมหมายถึงการสูญเสียชีวิต” นั้นน่าประทับใจมาก
และยังตรงกับช่วงเหตุการณ์โศกนาฏกรรม Columbia ในปี 2003 ด้วย
บางที Law 31 (จงเข้าใจข้อจำกัดของเทคโนโลยีเดิม) อาจเป็นตัวกระตุ้นให้เกิด Law 11 (ทิ้งทุกอย่างแล้วเริ่มใหม่) และมี Law 16 (อย่าเชื่อการวิเคราะห์เดิมแบบงมงาย) คอยสนับสนุน
ฉันชอบ ระบบที่ไม่ต้องบำรุงรักษาและเปลี่ยนแทนได้ง่าย
เทคโนโลยีซอฟต์แวร์สุดท้ายก็หายไปอยู่ดี จึงควรมีโครงสร้างที่ เปลี่ยนแทนได้ทุกเมื่อ แบบเดียวกับฮาร์ดแวร์
คำแนะนำที่ว่า “จงหลีกเลี่ยงสิ่งยั่วยวนให้เชื่อว่าผลิตภัณฑ์ใหม่หมดจดจะดีกว่าวิวัฒนาการของผลิตภัณฑ์เดิมเสมอ” นั้นโดนใจเป็นพิเศษ