วิธีเขียนเอกสารการออกแบบที่ดี

• เอกสารการออกแบบ คือรายงานทางเทคนิคที่สรุป กลยุทธ์การนำระบบไปใช้งานจริง ข้อจำกัด และ trade-off
• เอกสารการออกแบบมีหน้าที่โน้มน้าวให้ผู้อ่านเข้าใจว่า การออกแบบนี้ เหมาะสมกับบริบท
• โครงสร้าง ของเอกสารมีความสำคัญ และควรมีลำดับเชิงตรรกะเพื่อไม่ให้ผู้อ่าน สะดุดกับเนื้อหา
• ต้องอาศัยการ แก้ไขปรับปรุง เพื่อลดคำที่ไม่จำเป็น และ ประหยัดทรัพยากรด้านสมาธิ ของผู้อ่าน
• การใช้ ย่อหน้าสั้น และ ภาคผนวก รวมถึงการฝึกฝนเพื่อพัฒนา ทักษะการเขียนเอกสาร เป็นสิ่งสำคัญ

---

คำจำกัดความ

• เอกสารการออกแบบคือ รายงานทางเทคนิค ที่สรุป กลยุทธ์การนำระบบไปใช้งานจริง ภายใต้บริบทของ trade-off และข้อจำกัด

เป้าหมาย

• เอกสารการออกแบบมีจุดประสงค์เพื่อ โน้มน้าวผู้อ่าน ว่าการออกแบบนั้นเหมาะสมที่สุด เช่นเดียวกับที่ บทพิสูจน์ ในคณิตศาสตร์ทำให้ผู้อ่านยอมรับทฤษฎีบท
• ในกระบวนการออกแบบ การลงมือเขียนเองช่วยเพิ่มความเคร่งครัดของการคิด
• การเขียนเอกสารการออกแบบช่วยเปลี่ยนความคิดที่คลุมเครือให้กลายเป็นความคิดที่เป็นรูปธรรม

การจัดโครงสร้าง

• โครงสร้าง ของเอกสารการออกแบบที่ดีสำคัญพอ ๆ กับการจัดระเบียบโค้ด
• เช่นเดียวกับที่มือใหม่เขียนโค้ด หลายคนมักเขียน "เอกสารการออกแบบแบบสปาเก็ตตี้"
• หากเพียงเรียงประโยคโดยไม่มี ลำดับเชิงตรรกะ ผู้อ่านจะตามบริบทได้ยากและสับสน
• เอกสารที่ดีควรมีการไหลลื่นอย่างเป็นธรรมชาติ โดยไม่ทำให้ผู้อ่านแปลกใจ และแต่ละประโยคควรต่อยอดจากสิ่งที่มาก่อนหน้าอย่างสมเหตุสมผล
• เป้าหมายคือทำความเข้าใจ สถานะการคิด ของผู้อ่าน และค่อย ๆ พาไปสู่ความเข้าใจใหม่ทีละขั้น
• ควรคลี่คลาย ข้อโต้แย้งที่คาดการณ์ได้ ล่วงหน้า และอธิบายก่อนที่ผู้อ่านจะยกข้อคัดค้านขึ้นมา

การแก้ไขปรับปรุง

• หลังจากจัดโครงสร้างเนื้อหาอย่างดีแล้ว ขั้นตอนการ ลบคำที่ไม่จำเป็นออก (การแก้ไขปรับปรุง) เป็นสิ่งสำคัญ
• สมาธิของผู้อ่าน เป็นทรัพยากรที่มีจำกัด จึงควรตัดข้อมูลที่ไม่จำเป็นออกอย่างเด็ดขาด
• ในร่างแรก มักลดถ้อยคำที่ไม่มีความหมายลงได้ราว 30%
• การช่วยแก้ไขเอกสารของผู้อื่นและฝึก มุมมองเชิงวิพากษ์ จะช่วยให้ขัดเกลางานเขียนของตนเองได้อย่างมีประสิทธิภาพ
• การฝึกด้วย ทวีตสั้น ๆ (จำกัด 280 ตัวอักษร) ก็ช่วยพัฒนาความสามารถในการทำให้ความคิดเรียบง่ายและกระชับได้เช่นกัน

ประสบการณ์และการฝึกฝน

• ไม่มีทางลัดในการพัฒนาทักษะที่ดีไปกว่า การฝึกซ้ำ ๆ
• ประสบการณ์กับ วัฒนธรรมที่ให้เอกสารเป็นศูนย์กลาง ที่ Amazon ช่วยพัฒนาทักษะการเขียนเอกสารได้มาก
• ในการประชุมสำคัญ มีการแจกเอกสารการออกแบบขนาด 1–6 หน้า จากนั้นทุกคนจะ อ่านเงียบ ๆ และเขียนความเห็นลงในพื้นที่ว่าง
• การได้รับฟีดแบ็กช่วยพัฒนาทักษะการเขียนได้อย่างเป็นรูปธรรม

เคล็ดลับที่เป็นรูปธรรม

ใช้ย่อหน้าสั้น

• เอกสารการออกแบบควรสร้างการไหลของเนื้อหาด้วย bullet point ที่กระชับและต่อเนื่อง
• bullet point แต่ละข้อ (ข้อสังเกต แนวคิด ปัญหา การปรับปรุง ฯลฯ) ควรเป็น ย่อหน้าสั้น ที่โฟกัสกับ หนึ่งแนวคิด
• แต่ละย่อหน้าควรชัดเจนพอที่จะสรุปได้ด้วยหนึ่งประโยค ซึ่งจะช่วยประหยัด ทรัพยากรความจำระยะสั้น ของผู้อ่าน

ใช้ภาคผนวก

• ผลการคำนวณหรือผลการจำลองที่ซับซ้อน ควรจัดไว้อย่างละเอียดใน ภาคผนวก แทนที่จะอยู่ในเนื้อหาหลัก และกล่าวถึงในเนื้อหาหลักเพียงในลักษณะเชิงอรรถสั้น ๆ
• ภาคผนวกไม่จำเป็นต่อการเข้าใจข้อสรุปหลักของเนื้อหา แต่มีไว้ให้ผู้อ่านที่สนใจเปิดดูเพิ่มเติมได้

ตัวอย่างการแก้ไข

• (ก่อนแก้ไข, ย่อหน้าที่ยืดยาว):

  bullet point แต่ละข้อควรเป็นย่อหน้าแยกในเอกสาร แต่ละย่อหน้าควรสรุปได้ด้วยหนึ่งประโยค ไม่จำเป็นต้องเป็นหนึ่งประโยคจริง ๆ เพราะอาจต้องมีคำอธิบายเพิ่มเติมเพื่ออธิบายแนวคิด แต่หลังจากอ่านแล้ว ผู้อ่านควรสามารถสรุปเป็นหนึ่งประโยคได้

• (หลังแก้ไข, ย่อหน้าที่กระชับขึ้น):

  bullet point แต่ละข้อควรเป็นหนึ่งย่อหน้าและควรถูกสรุปได้ด้วยหนึ่งประโยค ไม่จำเป็นต้องมีเพียงหนึ่งประโยคจริง ๆ และหากจำเป็นก็สามารถเพิ่มคำอธิบายประกอบได้ แต่เมื่ออ่านจบแล้วควรถูกย่อเป็นหนึ่งประโยคได้

สรุปส่งท้าย

• เอกสารการออกแบบเป็น กระบวนการสำคัญ ที่ช่วยพัฒนาทักษะได้ผ่าน ความเคร่งครัดของการคิด การไหลเชิงตรรกะ การแก้ไขที่ยึดผู้อ่านเป็นศูนย์กลาง และการฝึกฝนซ้ำ ๆ

[GN⁺]

ความคิดเห็นจาก Hacker News

• มีคำพูดจากบทความอยู่ 2 ประโยคที่น่าประทับใจเป็นพิเศษ ประโยคแรกมาจากภาพแคปหน้าจอใน X ที่บอกว่า "ไอเดียจะดีขึ้น 10 เท่าระหว่างกระบวนการเขียน" ส่วนอีกประโยคอยู่ช่วงต้นบทความว่า "คนที่สำคัญที่สุดที่ต้องโน้มน้าวคือผู้เขียนเอง" น่าแปลกที่แม้หลายคนจะทำงานในวงการนี้มานานหลายปี ก็ยังมีคนที่คัดค้านความจำเป็นของเอกสารออกแบบอยู่เสมอ Leslie Lamport เคยพูดไว้ว่า "การเขียนคือวิธีที่ธรรมชาติใช้บอกเราว่าความคิดของเรายังเละเทะแค่ไหน" ถ้าอยากพัฒนาทักษะการเขียนเชิงเทคนิคเพิ่มเติม ขอแนะนำบทความ Write Like an Amazonian(https://medium.com/@apappascs/…)
  • ดูเหมือนว่าคำแนะนำแบบ "เปลี่ยนคำคุณศัพท์ให้เป็นข้อมูล" จะแพร่หลายไปทั่ววงการเทคมาก จนทุกวันนี้เรซูเม่ที่เห็นเต็มไปด้วยตัวเลขจนบางทีก็ไม่แน่ใจว่าหมายถึงอะไรกันแน่
• ในฐานะผู้รีวิวงานออกแบบ มีจุดหนึ่งที่คนเขียนเอกสารทุกคนควรซึมซับให้ขึ้นใจ นั่นคือ "เอกสารที่ดีทำให้ผู้อ่านเข้าใจปัญหาและแบบจำลองความคิด จนเมื่อเฉลยวิธีแก้ที่ผ่านการขบคิดมาหลายสัปดาห์ ผู้อ่านจะรู้สึกคล้อยตามอย่างเป็นธรรมชาติ" คำคมที่ผมชอบที่สุดคือ "ถ้ามีเวลามากกว่านี้ ฉันคงเขียนจดหมายให้สั้นกว่านี้" เอกสารออกแบบควรทำให้เรื่องซับซ้อนกลายเป็นเรื่องง่าย และไม่ใช่ที่สำหรับยัดทุกทางอ้อมและทุกความล้มเหลวที่นักพัฒนาเคยผ่านมาลงไปแบบไม่เลือก แน่นอนว่าเรื่องเหล่านั้นก็ควรบันทึกไว้ได้ แต่ควรแยกไปอยู่อีกเอกสารหนึ่งหรือภาคผนวกมากกว่า เราจำเป็นต้องแสดงเส้นทางข้างหน้าให้เรียบง่าย
  • ผมชอบสำนวน "มีเวลาเพิ่มอีกหน่อย จดหมายก็จะสั้นลงอีกหน่อย" มากกว่า
  • ผมมักถามตัวเองเสมอว่า "หัวข้อนี้จะก่อให้เกิดการถกเถียงที่ไม่จำเป็นไหม?" และ "มันคุ้มค่าจะถกเถียงไหม?" เป้าหมายของผมคือทำให้ผู้อ่านหน้าใหม่เข้าร่วมวงสนทนาได้ไม่ยาก และไม่ให้เกิดดราม่ากับประเด็นที่ไม่สำคัญ
• การประชุมที่ Amazon เริ่มต้นด้วยการที่ผู้นำเสนอแจกเอกสารที่เขียนเป็นร้อยแก้วให้ทุกคน จากนั้นทุกคนนั่งเงียบ ๆ อ่านเอกสาร และใช้ปากกาแดงจดโน้ตกับคำถามลงบนขอบกระดาษ ผมไม่เคยทำงานที่ Amazon จริง ๆ แต่แนวทางนี้มีประสิทธิภาพอย่างน่าทึ่ง และคนที่เคยเล่าประสบการณ์นี้ก็ดูจะชอบกันทุกคน ฟังดูเหมือนจะไม่มีประสิทธิภาพที่เอาเวลาประชุมอันมีค่าไปนั่งอ่านพร้อมกัน แต่จริง ๆ แล้วถ้าทุกคนอ่านและเตรียมตัวล่วงหน้าได้ การประชุมก็น่าจะสั้นกว่านี้ การอ่านพร้อมกันแบบเรียลไทม์ทำให้ต้องรอคนอ่านช้า หรือไม่ก็ทุกคนเข้าใจไม่เท่ากันเพราะบริบทไม่พอ จนเวลาผ่านไปอย่างคลุมเครือ ผมเคยเห็นบ่อยมากว่าเวลารีวิวงานออกแบบที่ Google ผู้เข้าร่วมส่วนใหญ่เพิ่งเห็นเอกสารครั้งแรกในห้องประชุมและเริ่มถกกันทันที ผมคิดว่านี่เป็นเพราะ Google ไม่มีวัฒนธรรมเอกสารที่แข็งแรงนัก และหัวหน้าทีมหรือผู้จัดการที่มาประชุมโดยไม่เตรียมตัวก็ถูกยอมรับโดยปริยาย ถ้าสร้างวัฒนธรรมให้คนอ่านมาให้แน่ชัดก่อนประชุมได้ เวลาประชุมก็น่าจะถูกใช้อย่างมีประสิทธิภาพกว่านี้มาก
  • หลายคนบอกว่าถ้าอ่านมาก่อน เวลาประชุมจะลดลง แต่แนวปฏิบัติของ Amazon คือการตอบสนองต่อความจริงที่ว่าคนส่วนใหญ่ไม่ได้อ่านมาก่อนจริง ๆ ในบทความที่เกี่ยวข้องก่อนหน้านี้ก็มีการเล่าว่า การสร้างวัฒนธรรมการอ่านและเตรียมตัวล่วงหน้าอย่างเข้มแข็งนั้นแทบเป็นไปไม่ได้ เพราะผู้เข้าร่วมทุกคนต่างก็ติดประชุมก่อนหน้า และก่อนหน้านั้นก็มีประชุมอีก แม้ในทางทฤษฎีจะวิจารณ์ได้ว่าทำไมไม่ลดจำนวนประชุมลง แต่ในทางปฏิบัติการประชุมเหล่านั้นก็มีคุณค่า และถึงรวมเวลาอ่านเข้าไปก็ยังเพียงพอสำหรับการตัดสินใจ สุดท้ายแล้วควรโฟกัสที่ผลลัพธ์ และดูเหมือนว่าใน Amazon ข้อดีของวิธีนี้มีมากกว่าข้อเสียจริง
  • สงสัยว่ามันสำคัญตรงไหนว่าจะอ่านเอกสารตอนไหน ถ้าต้องใช้เวลาเพิ่มก็แค่ขยายเวลาประชุมได้ ข้อเสียอย่างเดียวคือจัดตารางประชุมยากขึ้น แต่เวลารวมที่ใช้จริงไม่ได้เปลี่ยน
  • ผมคิดว่าการที่ทุกคนมีระดับความเข้าใจไม่เท่ากัน หรือกังวลว่าจะพลาด corner case ของใครบางคน เป็นสิ่งที่ทำให้เสียเวลามากกว่า
  • มีคนเล่าจากประสบการณ์จริงว่าถ้าเรื่องไหนไม่ถูกหยิบเข้าประชุม เรื่องนั้นก็มักจะไม่เกิดขึ้นเลย
• มีคำแนะนำดี ๆ มากมายเรื่องความชัดเจนและการแก้ไขต้นฉบับ จุดอ่อนคือหลังจากเอกสารถูกอนุมัติแล้วจะดูแลต่ออย่างไร ถ้าไม่มีการดูแล มันจะค่อย ๆ กลายเป็นสภาพแบบ 'โบราณคดีงานออกแบบ' เมื่อหลายปีก่อน Andrew Harmel-Law เคยเสนอให้ใช้ Architecture Decision Records (ADRs) เพื่อบันทึกการตัดสินใจด้านสถาปัตยกรรมภายในองค์กรอย่างมีประสิทธิภาพ ซึ่งอาจช่วยได้ ADRs อยู่ข้างโค้ด (เช่น adr/001-use-postgres.md) และบันทึกบริบท การตัดสินใจ และสถานะไว้แบบสั้น ๆ ข้อดีคือรีวิวได้ง่ายในทุก PR และถ้าสถานการณ์เปลี่ยนก็แทนที่ได้ง่าย อีกทั้งยังค้นหาเหตุผลของการตัดสินใจเดิมได้แม้เวลาจะผ่านไปหลายเดือนแล้ว [ลิงก์: https://martinfowler.com/articles/…]
  • ถ้าใช้แนวทางนี้ สงสัยว่าคณะกรรมการทั้งองค์กรอย่าง Security, Privacy, Compliance ฯลฯ จะต้องมาเป็นผู้รีวิวในทุก PR ที่แตะ ADR หรือไม่ และ PR แบบนั้นจะมีโอกาส merge ภายใน 90 วันไหม
  • ผมคงต้องอ่านลิงก์ MF.com(https://thoughtworks.com/radar/techniques/…) ให้จบก่อน แต่ "Advice Process" จบลงแค่ประโยคว่า 'คุยกับทุกคน' คนที่มีตำแหน่งชื่อว่า 'Managing' น่าจะหมดความสนใจตั้งแต่ตรงนั้น แก่นจริง ๆ คือ "องค์ประกอบสนับสนุนทั้งสี่" แต่พอกดเข้าไปที่ลิงก์นี้เพื่อจะศึกษา ADRs เพิ่ม สุดท้ายกลับโดนพาไปดาวน์โหลด PDF(https://thoughtworks.com/content/dam/…) ถ้ามีคำอธิบายที่ชัดเจนกว่านี้ว่า ADRs คืออะไรจริง ๆ ก็คงดี
  • Session messenger เป็นตัวอย่างที่ชัดมาก มีการเปลี่ยนแปลงด้านการออกแบบและสถาปัตยกรรมมามากมายจนไม่มีข้อมูลที่เป็นทางการและเชื่อถือได้อธิบายว่ามันทำงานอย่างไร และถ้าต้องการ secure messaging ก็ใช้ Signal ไปเลย
• จากประสบการณ์ของผม องค์กรและความชัดเจนคืออุปสรรคใหญ่ที่สุดที่ทำให้วิศวกร SW พัฒนาทักษะการเขียนเอกสารได้ยาก ผมคิดว่าอุปมาเรื่อง 'code spaghetti' ของผู้เขียนเป็นตัวอย่างที่ดีในการอธิบายว่าการจัดระเบียบไอเดียสำคัญแค่ไหน ผมเองก็เคยพยายามสื่อเรื่องคล้ายกันในอีกแบบหนึ่ง และตั้งใจว่าจะเอาอุปมานี้ไปใช้ ต่อให้เคยเขียนบล็อกแนวคล้ายกันไว้ก่อนหน้านี้(https://ryanmadden.net/things-i-learned-at-google-design-docs/) ก็ยังน่าสนใจที่จะเห็นทั้งจุดร่วมอย่างความหนาแน่นของข้อมูลกับความสำคัญของการฝึกปฏิบัติ และจุดต่างระหว่างแต่ละบริษัท สำหรับประเด็นเรื่อง 'ย่อหน้าสั้น' ผมเห็นต่างนิดหน่อย ย่อหน้าจะสั้นได้ก็เพราะข้อมูลถูกขัดเกลาอย่างดี ไม่ใช่แค่ตัดบรรทัดแล้วจะช่วยอะไรได้ และผมคิดว่าส่วน 'Editing' อธิบายแนวคิดพื้นฐานข้อนี้ได้ดีกว่า
• ผมมีกระบวนการหนึ่งที่ใช้ประจำ ขั้นที่ 1: เททุกอย่างที่นึกออกลงเอกสารแบบไม่ต้องเรียงลำดับก่อน (จะลองใช้การพิมพ์ตามเสียงก็ได้) ขั้นที่ 2: ให้ LLM (large language model) ช่วยลองจัดโครงสร้างและลำดับเรื่อง ซึ่งจริง ๆ แล้วผลลัพธ์จากขั้นนี้อาจถูกทิ้งไปเลยก็ได้ เพราะมันเป็นเพียงส่วนหนึ่งของกระบวนการขัดเกลาความคิด ขั้นที่ 3: เขียนร่างแรกโดยอ้างอิงผลจาก LLM หรือไม่ก็วางโครงใหม่ทั้งหมดด้วยตัวเอง ขั้นที่ 4: ตัดคำ เปลี่ยนเป็นคำที่ง่ายกว่า ฯลฯ เพื่อให้กระชับที่สุด ขั้นที่ 5: ทำขั้นที่ 4 ซ้ำ LLM ทำหน้าที่เป็นสะพานที่ช่วยจัดระเบียบร่างแบบกระจัดกระจาย ต้องพร้อมจะทิ้งสิ่งที่ LLM สร้างออกมาด้วย อย่างน้อย 30% มักจะตัดทิ้งได้เสมอ และผมยังทึ่งทุกครั้งที่เห็นว่าย่อมันลงได้โดยไม่เสียความหมาย
  • ผมรู้สึกว่ากระบวนการกลับมาแก้ไขงานเขียนของตัวเองสำคัญพอ ๆ กับการเขียนครั้งแรก เพราะมันทำให้เห็นว่าตัวเองสรุปเร็วเกินไปแค่ไหน และมีอะไรที่ยังไม่ได้พิจารณาบ้าง ดูเหมือนหลายคนยังประเมินค่าการเขียนในฐานะเครื่องมือช่วยโฟกัสความคิดต่ำเกินไป โค้ดก็เหมือนกัน ต่อให้แค่เขียน template ง่าย ๆ บางครั้งระหว่างเขียน test ก็ผุดไอเดียที่จะปรับปรุงโค้ดหลักขึ้นมาได้ แต่ LLM ไม่ได้ชี้โอกาสในการปรับปรุงเชิงคุณภาพแบบนี้ให้
  • มันคือการขยาย ย่อ บีบอัด แล้วขยายใหม่ จากนั้นก็บีบอัดอีก ถ้ามีคนถามคำถามเจาะจงก็ขยายใหม่อีก และตอนท้ายก็ใช้ LLM ทำสรุปแบบเบา ๆ เอาสนุก สรุปแล้วพวกเรากำลังนั่งรถไฟเหาะที่ไม่มีวันจบจริง ๆ
• รู้สึกว่าควรเขียนให้มากขึ้น โครงสร้างเอกสารแบบตัวแทนที่ผมนึกถึงคือ B.O.O. และ Good Strategy/Bad Strategy โดย B.O.O. ย่อมาจาก Background, Objective, Overview ใช้จัดว่าเรามาถึงจุดนี้ได้อย่างไร และกำลังจะเปลี่ยนอะไรอย่างไร ส่วน Good Strategy/Bad Strategy เป็นหนังสือที่ประกอบด้วย diagnosis, guiding policy/assumptions/requirements และ action ซึ่งในแง่การจัดโครงสร้างเอกสารก็คล้ายกับ B.O.O. B.O.O. เหมาะกับ Google หรือองค์กรที่มีองค์ประกอบขนาดเล็ก ส่วน Good Strategy/Bad Strategy ใช้ได้กับขนาดองค์กรที่หลากหลายกว่ามาก แต่ต้องอาศัยผู้เขียนที่มีฝีมือ
• ตอนเรียนวิชาการเขียนเชิงเทคนิค ผมพัฒนาความสามารถในการสรุปประเด็นสำคัญให้ชัดเจนได้มากขึ้นอย่างเห็นได้ชัด โดยโฟกัสกับวิธีแบบ 'ตัดด้วยปากกาแดง' (เขียน ขีดทิ้ง แล้วเขียนใหม่) ซึ่งเน้นการสื่อแนวคิดด้วยคำให้น้อยที่สุด กระบวนการนี้มีหลายขั้น และยิ่งฝึกก็ยิ่งง่ายขึ้น ผมพยายามถ่ายทอดทักษะนี้ให้เพื่อนร่วมทีมด้วย แต่ก็เตือนตัวเองเสมอว่านี่คือทักษะที่ต้องฝึกอย่างสม่ำเสมอ
• ผมชอบทั้งเอกสารที่เขียนแบบนี้และวัฒนธรรมการเขียนลักษณะนี้มาก แต่ก็เคยเห็นว่าบางครั้งแนวทางนี้ให้ผลย้อนกลับได้ การอธิบายเหตุผลและตรรกะที่นำไปสู่ข้อสรุปนั้นมีประสิทธิภาพมากสำหรับเอกสารเชิงโน้มน้าว แต่ก็ไม่ใช่ว่าทุกกรณีจำเป็นต้องโน้มน้าวแบบนั้นเสมอไป บางครั้งการเขียนข้อสรุปขึ้นมาก่อนตรง ๆ กลับดีกว่าสำหรับผู้อ่าน โดยเฉพาะผู้อ่านที่เชื่อใจผู้เขียนอยู่แล้ว หลายครั้งผู้อ่านแค่อยากรู้ประเด็นสำคัญก่อน มากกว่าจะเหนื่อยไปกับการไล่ตามตรรกะทั้งหมด และเมื่อรู้ข้อสรุปแล้ว ค่อยอยากตามอ่านรายละเอียดทีหลังก็ได้
  • การใส่สรุปไว้ด้านบน แล้วค่อยตามด้วยรายละเอียดและเหตุผลด้านล่าง ก็เป็นโครงสร้างที่ดีเพียงพอเหมือนกัน
• บางครั้งผมก็เขียนเอกสารออกแบบทั้งที่อาจมีแค่ผมคนเดียวที่ได้อ่าน แต่แค่การบันทึกมันออกมาเป็นลายลักษณ์อักษรก็ทรงพลังมากแล้ว ถ้ามีตัวอย่างเอกสารจริงให้ดูคงช่วยได้มาก เพราะผมอยากเปรียบเทียบโครงสร้างเอกสารของตัวเองกับโครงสร้างสุดท้ายของคนอื่น ๆ