วัฒนธรรมการเขียนเอกสาร Design Docs ของ Google (2020)

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

---

บทบาทของ Design Doc

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

โครงสร้างพื้นฐานของ Design Doc

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

• บริบทและขอบเขต

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

• เป้าหมายและสิ่งที่ไม่ใช่เป้าหมาย

  • สรุปเป้าหมายของระบบ และบางครั้งสิ่งที่สำคัญยิ่งกว่าคือ สิ่งที่ไม่ใช่เป้าหมาย เป็นรายการ bullet สั้น ๆ
  • สิ่งที่ไม่ใช่เป้าหมายไม่ใช่การปฏิเสธเป้าหมายแบบง่าย ๆ เช่น “ระบบต้องไม่ crash” แต่คือรายการที่อาจเป็นเป้าหมายได้ ทว่าถูกระบุชัดว่าไม่รวมไว้
  • ในการออกแบบฐานข้อมูล การรองรับ ACID เป็นตัวอย่างที่ดีของสิ่งที่ต้องรู้ว่าเป็นเป้าหมายหรือไม่ใช่เป้าหมาย
  • แม้จะเป็นสิ่งที่ไม่ใช่เป้าหมาย หากไม่มี trade-off ที่ขัดขวางการบรรลุเป้าหมาย ก็อาจเลือกโซลูชันที่ให้คุณสมบัตินั้นได้

วิธีเขียนแบบออกแบบจริง

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

• System context diagram

  • ในเอกสารจำนวนมาก system-context-diagram อาจมีประโยชน์
  • แผนภาพนี้แสดงระบบในฐานะส่วนหนึ่งของสภาพแวดล้อมทางเทคนิคที่ใหญ่กว่า ทำให้ผู้อ่านเข้าใจการออกแบบใหม่ภายในสภาพแวดล้อมที่ตนรู้อยู่แล้ว

• API และการจัดเก็บข้อมูล

  • หากระบบที่ออกแบบเปิดเผย API โดยทั่วไปควร ร่างภาพรวม ของ API
  • ควรหลีกเลี่ยงการคัดลอกและวางนิยาม interface หรือข้อมูลแบบเป็นทางการมาตรง ๆ
  • นิยามเหล่านี้มักยืดยาว มีรายละเอียดที่ไม่จำเป็น และล้าสมัยได้เร็ว
  • ควรมุ่งเน้นส่วนที่เกี่ยวข้องกับการออกแบบและ trade-off
  • ระบบที่จัดเก็บข้อมูลควรอธิบายว่าข้อมูลถูกจัดเก็บอย่างไร และมีรูปแบบโดยประมาณแบบใด
  • แทนที่จะวางนิยาม schema ทั้งหมด ควรอธิบายส่วนที่เกี่ยวข้องกับการตัดสินใจด้านการออกแบบ

• โค้ดและ pseudocode

  • โดยทั่วไป Design Doc ควรมีโค้ดให้น้อยมาก
  • ยกเว้นกรณีอธิบายอัลกอริทึมใหม่ pseudocode ก็ควรใช้ให้น้อยเช่นกัน
  • หากมี prototype ที่แสดงว่าการออกแบบ implement ได้จริง ก็สามารถลิงก์ไว้อย่างเหมาะสม

ระดับข้อจำกัดเปลี่ยนรูปแบบของเอกสาร

• หนึ่งในปัจจัยหลักที่ส่งผลต่อรูปแบบของการออกแบบซอฟต์แวร์และ Design Doc คือ ระดับข้อจำกัด ของพื้นที่โซลูชัน
• ปลายด้านหนึ่งคือโปรเจกต์ซอฟต์แวร์แบบ greenfield ที่มีเพียงเป้าหมาย ส่วนแนวทางแก้สามารถเป็นอะไรก็ได้
  • เอกสารลักษณะนี้อาจครอบคลุมขอบเขตกว้าง แต่ต้องนิยามกฎเพื่อจำกัดให้เหลือชุดโซลูชันที่จัดการได้อย่างรวดเร็ว
• อีกปลายด้านหนึ่งคือระบบที่แนวทางแก้ที่เป็นไปได้ถูกนิยามไว้อย่างดีแล้ว แต่ยังไม่ชัดว่าจะผสมผสานแนวทางเหล่านั้นอย่างไรเพื่อบรรลุเป้าหมาย
  • อาจเป็นระบบ legacy ที่เปลี่ยนแปลงได้ยาก
  • อาจเป็นการออกแบบไลบรารีที่ต้องทำงานภายใต้ข้อจำกัดของภาษาโปรแกรมมิงที่เป็น host
• ในกรณีเช่นนี้ อาจลิสต์งานที่ทำได้ค่อนข้างง่าย แต่ต้องผสมผสานอย่างสร้างสรรค์เพื่อให้บรรลุเป้าหมาย
• หากหลายแนวทางไม่มีแนวทางใดสมบูรณ์แบบ เอกสารควรมุ่งเน้นการเลือกวิธีที่ดีที่สุดโดยอิงจาก trade-off ที่ระบุได้

ทางเลือกและประเด็นข้ามส่วน

• ทางเลือกที่พิจารณาแล้ว

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

• ประเด็นข้ามส่วน

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

ความยาวและกรณีที่ไม่จำเป็นต้องเขียน

• ความยาวที่เหมาะสม

  • Design Doc ควรมีรายละเอียดเพียงพอ แต่ก็ต้องสั้นพอให้คนที่ยุ่งสามารถอ่านได้จริง
  • สำหรับโปรเจกต์ขนาดใหญ่ ประมาณ 10~20 หน้า ดูจะเป็นจุดที่เหมาะสม
  • หากยาวกว่านั้นมาก อาจดีกว่าที่จะแบ่งปัญหาออกเป็นปัญหาย่อยที่จัดการได้มากขึ้น
  • Design Doc ขนาดย่อม 1~3 หน้า ก็เป็นไปได้
  • มีประโยชน์เป็นพิเศษกับการปรับปรุงแบบค่อยเป็นค่อยไปหรือ sub-task ในโปรเจกต์ agile
  • ทำขั้นตอนเดียวกับเอกสารยาว แต่กระชับกว่าและมุ่งเน้นชุดปัญหาที่จำกัดกว่า

• กรณีที่ไม่จำเป็นต้องเขียน

  • การเขียน Design Doc มี overhead
  • จะเขียนหรือไม่ขึ้นอยู่กับว่าประโยชน์ เช่น ฉันทามติด้านการออกแบบ การทำเอกสาร และการรีวิวโดยวิศวกรอาวุโส มีมากกว่าต้นทุนการสร้างเอกสารหรือไม่
  • เกณฑ์ตัดสินหลักคือปัญหาด้านการออกแบบมีความคลุมเครือหรือไม่
  • ความคลุมเครืออาจมาจากความซับซ้อนของปัญหา ความซับซ้อนของโซลูชัน หรือทั้งสองอย่าง
  • หากไม่คลุมเครือ คุณค่าของกระบวนการเขียนเอกสารก็มีน้อย
  • หากเอกสารแทบจะเป็น คู่มือการ implement ก็อาจไม่จำเป็นต้องมี Design Doc
  • หากบอกเพียงว่า “จะ implement แบบนี้” โดยไม่มี trade-off ทางเลือก หรือคำอธิบายการตัดสินใจ การลงมือเขียนโปรแกรมเลยอาจเป็นทางเลือกที่ดีกว่า
  • หากโซลูชันชัดเจนมากจนไม่มี trade-off คุณค่าของเอกสารก็ต่ำ
  • overhead จากการเขียนและรีวิว Design Doc อาจไม่เข้ากับการทำ prototype และการ iterate อย่างรวดเร็ว
  • การใช้วิธี agile ไม่ได้หมายความว่าไม่ต้องคิดให้รอบคอบเกี่ยวกับโซลูชันของปัญหาที่รู้อยู่แล้ว
  • การทำ prototype เองอาจเป็นส่วนหนึ่งของการเขียน Design Doc ได้ และ “ลองทำแล้ว ใช้งานได้” อาจเป็นหลักฐานที่หนักแน่นสำหรับตัวเลือกด้านการออกแบบ

วงจรชีวิตของ Design Doc

• วงจรชีวิตของ Design Doc ประกอบด้วยสี่ขั้นตอน
  1. การเขียนและ iterate อย่างรวดเร็ว
  2. การรีวิว
  3. การ implement และ iterate
  4. การบำรุงรักษาและการเรียนรู้

• การเขียนและ iterate อย่างรวดเร็ว

  • เอกสารเขียนโดยผู้เขียนคนเดียวหรือร่วมกับผู้เขียนร่วม
  • จากนั้นแชร์กับเพื่อนร่วมงานที่รู้พื้นที่ปัญหาดีที่สุด และ iterate อย่างรวดเร็ว
  • คำถามเพื่อความชัดเจนและข้อเสนอแนะจากเพื่อนร่วมงานจะนำเอกสารไปสู่เวอร์ชันแรกที่ค่อนข้างเสถียร
  • ที่ Google มีวิศวกรและทีมบางส่วนที่ชอบสร้างเอกสารด้วยเครื่องมือ version control และ code review แต่ Design Doc ส่วนใหญ่เขียนใน Google Docs และใช้ฟีเจอร์การทำงานร่วมกันอย่างมาก

• การรีวิว

  • ในขั้นรีวิว เอกสารจะถูกแชร์ให้ผู้อ่านที่กว้างกว่าผู้เขียนเดิมและผู้ร่วมงานใกล้ชิด
  • การรีวิวสามารถเพิ่มคุณค่าได้มาก แต่ก็อาจกลายเป็นกับดักของ overhead จึงต้องจัดการอย่างระมัดระวัง
  • วิธีที่เบาคือส่งเอกสารไปยัง mailing list ของทีมที่กว้างขึ้น เพื่อให้ผู้คนมีโอกาสตรวจดู
  • การอภิปรายส่วนใหญ่เกิดขึ้นใน thread ความคิดเห็นของเอกสาร
  • วิธีที่หนักคือการประชุมรีวิวการออกแบบอย่างเป็นทางการ ซึ่งผู้เขียนนำเสนอเอกสารต่อหน้าผู้อ่านที่เป็นวิศวกรอาวุโส
  • หลายทีมใน Google มีการประชุมประจำสำหรับการรีวิวลักษณะนี้
  • การรอการประชุมเหล่านี้อาจทำให้กระบวนการพัฒนาช้าลงอย่างมาก
  • สามารถบรรเทาได้ด้วยการขอ feedback ที่สำคัญที่สุดโดยตรง และไม่ทำให้การรีวิวที่กว้างขึ้นกลายเป็นตัวบล็อกความคืบหน้า
  • ตอนที่ Google ยังเป็นบริษัทขนาดเล็กกว่า แนวปฏิบัติคือส่งแบบออกแบบไปยัง mailing list กลางรายการเดียว แล้วให้วิศวกรอาวุโสรีวิวเมื่อมีเวลา
  • วิธีนี้มีข้อดีคือสร้างวัฒนธรรมการออกแบบซอฟต์แวร์ที่ค่อนข้างสม่ำเสมอทั่วทั้งบริษัท
  • เมื่อองค์กรวิศวกรรมใหญ่ขึ้นมาก แนวทางรวมศูนย์เช่นนี้จึงรักษาไว้ได้ยาก
  • คุณค่าหลักของการรีวิวคือการเปิดโอกาสให้ประสบการณ์รวมขององค์กรสะท้อนอยู่ในการออกแบบ
  • โดยเฉพาะอย่างยิ่ง ขั้นรีวิวช่วยอย่างสม่ำเสมอให้การออกแบบคำนึงถึงประเด็นข้ามส่วน เช่น ความสามารถในการสังเกตการณ์ ความปลอดภัย และความเป็นส่วนตัว
  • คุณค่าหลักของการรีวิวไม่ได้อยู่ที่การพบประเด็นเท่านั้น แต่อยู่ที่ประเด็นถูกพบในช่วงต้นของวงจรชีวิตการพัฒนา ซึ่งต้นทุนการเปลี่ยนแปลงยังต่ำ

• การ implement และ iterate

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

• การบำรุงรักษาและการเรียนรู้

  • เมื่อวิศวกร Google เจอระบบที่แตะเป็นครั้งแรก คำถามแรกที่มักถามคือ “Design Doc อยู่ที่ไหน?”
  • Design Doc ก็เหมือนเอกสารอื่น ๆ ที่มีแนวโน้มจะไม่ตรงกับความจริงเมื่อเวลาผ่านไป แต่บ่อยครั้งเป็นจุดเริ่มต้นที่เข้าถึงง่ายที่สุดในการเรียนรู้กระบวนการคิดที่สร้างระบบขึ้นมา
  • ผู้เขียนควรกลับมาอ่าน Design Doc ของตนเองอีกครั้งหลังผ่านไป 1~2 ปี
  • ตรวจสอบว่าสิ่งใดที่คาดถูก
  • ตรวจสอบว่าสิ่งใดที่คาดผิด
  • คิดว่าวันนี้จะตัดสินใจอะไรแตกต่างออกไป
  • กระบวนการตอบคำถามเหล่านี้ช่วยให้เติบโตเป็นวิศวกร และพัฒนาความสามารถด้านการออกแบบซอฟต์แวร์เมื่อเวลาผ่านไป

การตัดสินใจว่าเมื่อใดควรเริ่มด้วย Design Doc

• Design Doc เป็นวิธีที่ดีในการได้ความชัดเจนและสร้างฉันทามติเมื่อแก้ปัญหายากในโปรเจกต์ซอฟต์แวร์
• ช่วยประหยัดต้นทุนด้วยการลดทางตันในการเขียนโค้ดที่สามารถหลีกเลี่ยงได้ด้วยการสำรวจล่วงหน้า
• ขณะเดียวกันก็มีต้นทุน เพราะการเขียนและรีวิวใช้เวลา
• สามารถพิจารณาคำถามต่อไปนี้
  • การออกแบบซอฟต์แวร์ที่ถูกต้องยังไม่แน่นอน และการใช้เวลาล่วงหน้าเพื่อให้มั่นใจนั้นสมเหตุสมผลหรือไม่?
  • การให้วิศวกรอาวุโสที่อาจไม่สามารถรีวิวการเปลี่ยนแปลงโค้ดทั้งหมดเข้ามามีส่วนร่วมในขั้นออกแบบจะเป็นประโยชน์หรือไม่?
  • การออกแบบซอฟต์แวร์คลุมเครือหรือเป็นที่ถกเถียง จนฉันทามติระดับองค์กรมีคุณค่าหรือไม่?
  • ทีมลืมความเป็นส่วนตัว ความปลอดภัย logging หรือประเด็นข้ามส่วนอื่น ๆ ในการออกแบบเป็นครั้งคราวหรือไม่?
  • มีความจำเป็นอย่างมากต่อเอกสารที่ให้ insight ระดับสูงเกี่ยวกับการออกแบบระบบ legacy ภายในองค์กรหรือไม่?
• หากตอบ “ใช่” ต่อคำถามเหล่านี้ 3 ข้อขึ้นไป Design Doc ก็มีแนวโน้มสูงที่จะเป็นวิธีที่ดีในการเริ่มโปรเจกต์ซอฟต์แวร์ถัดไป

[GN⁺]

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

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

  • พฤติกรรมที่ให้รางวัลจะกลายเป็นพฤติกรรมที่เกิดขึ้นจริง เอกสารออกแบบในยุคแรกเป็นเครื่องมือเพื่อให้ตกลงทิศทางร่วมกันและให้บริบทแก่เพื่อนร่วมงาน แต่ภายหลังเมื่อจำนวนคนเพิ่มขึ้นแบบทวีคูณ ผู้จัดการที่มีเจตนาดีก็สั่งให้เขียนเอกสารเพื่อใช้ประเมินผลงาน แล้วสถานการณ์ก็เริ่มยุ่งเหยิง
    วัฒนธรรมของ Google กลายเป็น ลัทธิบูชาสินค้าแบบเลียนแบบตัวเอง
    บริษัทบางแห่งที่ผมไปทำงานหลังออกจาก Google ไม่ค่อยอยากคุยรายละเอียดขั้นตอนการเลื่อนตำแหน่ง เพราะพวกเขาเคยเห็นแล้วว่าจะเกิดอะไรขึ้นเมื่อผู้คนปรับจูนตัวเองอย่างละเอียดเพื่อให้เข้ากับขั้นตอนนั้น
  • น่าจะเป็นเพราะวัฒนธรรมที่ทีมซึ่งดูแลผลิตภัณฑ์เก่าและ成熟แล้วสร้างขึ้น ในที่แบบนั้น แม้แต่การปล่อยโปรเจกต์เล็ก ๆ ก็ต้องร่วมงานกับคนอย่างน้อย 10 คน และในกรณีของผมมักเป็น 20–30 คน โดยขอบเขตผลกระทบอาจไปถึง 100–500 คน
    ทุกคนยุ่งกันหมด จึงไม่สามารถคุย 1:1 แบบสั้น ๆ กับทุกคนได้ และถ้าไม่ได้รับการทบทวนจากผู้มีส่วนได้ส่วนเสียอย่างเหมาะสม ก็มีโอกาสที่คนที่ไม่พอใจจะมาหาและทำให้ต้อง rollback การเปิดตัว
    ในบริบทนี้ เอกสารออกแบบคือ เครื่องมือสื่อสารแบบอะซิงโครนัส สำหรับหัวข้อที่มีข้อมูลจำนวนมาก หากผลิตภัณฑ์ประสบความสำเร็จ อีก 10 ปีต่อมา คนที่เข้ามาร่วมงานก็จะสนทนากับคุณผ่านเอกสารนี้
    ผมเคยรอดมาได้หลายครั้งเพราะเอกสารออกแบบแบบสุ่ม ๆ จากปี 2010 ที่อธิบายการตัดสินใจประหลาดซึ่งยังคอยขัดขาเราอยู่จนถึงตอนนี้ มันอาจไม่เหมาะกับทีมเล็กที่คล่องตัวหรืองานที่ซับซ้อนน้อยกว่า แต่ถึงวัฒนธรรมวิศวกรรมจะกลายเป็นลัทธิบูชาสินค้าไปแล้ว โดยรวมก็ยังมีเหตุผลและบริบทของมันอยู่
  • ถ้าวิธีที่เรียบง่ายและชัดเจนมีอยู่จริงเพียงวิธีเดียว ก็เขียน เอกสาร 1 หน้า ได้ แต่ในส่วนนี้ผมอยากเข้าข้าง Google
    ถ้ากำลังออกแบบอะไรสักอย่างแล้วมีแนวทางแก้ปัญหาที่พิจารณาอยู่เพียงทางเดียว นั่นแปลว่าไม่มีการออกแบบ หรือไม่ก็ยังไม่รอบคอบพอ ตัวเลือกและการประนีประนอมคือสิ่งที่ประกอบกันเป็นการออกแบบ
  • ที่ที่ผมทำงานอยู่มีปัญหาตรงกันข้าม เมื่อขอให้เขียนเอกสารออกแบบในระดับสูงสำหรับงานค่อนข้างเล็กน้อย ก็จะบอกว่า “มีวิธีทำได้หลายแบบ เอกสารแบบนี้จึงไม่มีประโยชน์ และงานก็เล็กน้อย วิศวกรเลือกสักวิธีมาทำก็พอ”
    คนเหล่านี้จำนวนมากเป็นที่ปรึกษาภายนอกที่ทำงานกับบริษัทมานานกว่า 15 ปี ดังนั้นเพราะคนกลุ่มเดิมทำงานแบบเดิมมานาน จึงมีมาตรฐานอยู่แล้วในระดับหนึ่ง แต่ถึงอย่างนั้นก็ยังพยายามสร้างหุ่นฟางว่า “ถ้าคนไม่ทำตามมาตรฐานจะเกิดอะไรขึ้น”
    ผลลัพธ์คือแทบไม่มีเอกสารออกแบบ หรือไม่ก็ล้าสมัยอย่างหนัก และบริษัทก็ยังต้องจ้างที่ปรึกษากลุ่มเดิมต่อไปทุกปีด้วย ค่าใช้จ่ายที่ถูกปั่นให้สูงเกินจริง
  • ตอนอยู่ทีมอื่น ผมรู้สึกแบบนั้นจริง ๆ เหมือนถูกคาดหวังให้เขียนเอกสารเพื่อให้มีเอกสาร คล้ายกับ วิศวกรรมแบบลัทธิบูชาสินค้า
    ตอนนี้ผมอยู่ในทีมที่มี Googler รุ่นเก่าซึ่งทำงานมานานกว่า 15 ปีอยู่มาก เอกสารออกแบบจะมีเฉพาะเมื่อจำเป็นเท่านั้น เช่น กรณีที่เกี่ยวข้องกับหลายระบบ หรือซับซ้อนอย่างชัดเจนเพราะมีจุดแลกเปลี่ยนเยอะ เป็นต้น นอกเหนือจากนั้นก็แค่ “เขียน CLs” เท่านั้น

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

  • ทุกบริษัทที่เคยทำมาก็เป็นแบบนั้นทั้งหมด อาชีพการงานขึ้นอยู่กับ การถูกมองเห็น มากกว่าชื่อเสียงหรือความสามารถ เอกสารออกแบบเป็นสิ่งที่ผู้บริหารมองเห็นได้ชัดมาก
    ทุกครั้งที่เข้าบริษัทใหม่ ผมจะเสนอให้เริ่มเขียนเอกสารออกแบบ แล้วก็สร้างความประทับใจที่ดีกับฝ่ายบริหารได้ทันที :)
  • เพราะแบบนั้น เอกสารจำนวนมากจึงทำตามรูปแบบการออกแบบที่ซับซ้อนขึ้น ทั้งที่ไม่จำเป็น เป้าหมายคือเพื่อให้ได้ คะแนนผลงาน มากขึ้นจากคนที่มีเวลาแค่กวาดตาอ่านเอกสาร
    เอกสารจำนวนมากที่ผมอ่านดูเหมือนว่ามีคำตัดสินที่ต้องการไว้แล้ว จากนั้นตอนเริ่มเอกสารก็แปะทางเลือกที่แต่งขึ้นมาอย่างน้อย 2 ทางเพื่อโชว์คำตัดสินนั้น ทางหนึ่งง่ายเกินไป อีกทางเป็นการออกแบบเกินจำเป็น แล้วค่อยเลือกข้อที่ดูสมเหตุสมผล
  • นักพัฒนาพูดกันตรง ๆ ว่าเขียนเอกสารออกแบบเพื่อ คณะกรรมการเลื่อนตำแหน่ง นั่นคือเป้าหมาย ส่วนอย่างอื่นเป็นเรื่องรอง
    เพราะไม่รู้ว่าเอกสารออกแบบฉบับไหนจะถูกใช้ในแพ็กเกจเลื่อนตำแหน่ง งานเล็กแค่ไหนก็เลยถูกบันทึกเป็นเอกสารออกแบบทั้งหมด แม้จะมีแนวคิดเอกสารออกแบบ 1 หน้า แต่โดยปกติมันจะขยายจากหนึ่งหน้าเป็นหลายหน้า
    แม้แต่โปรเจกต์หนึ่งสัปดาห์ก็มีการเขียนเอกสารออกแบบ และผมเคยต้องรีวิวเอกสารออกแบบยาว 20, 30, 40 หน้า สำหรับเรื่องที่ถ้าเป็นบริษัทอื่นคงจบด้วย JIRA ticket ใบเดียว
    หลายคนถูกสอนมาว่าคณะกรรมการเลื่อนตำแหน่งอยากเห็น “เอกสารที่ผู้เขียนเขียนเองคนเดียว” และไม่ว่าความเชื่อนี้จะถูกหรือไม่ มันก็ทำให้ทุกอย่างช้าลงและยับยั้งการเรียนรู้ข้ามกัน ผมเคยเห็นวิศวกรซอฟต์แวร์ที่แยกตัวอยู่เกินหนึ่งไตรมาสเพื่อเขียนแต่เอกสารออกแบบ
    ในเอกสารออกแบบ ตัวการออกแบบจริงควรเป็นแกนหลัก แต่ส่วนที่เหลือ 99% คือการนิยามปัญหา หลายครั้งเกินไปที่ระหว่างรีวิว เราปรับปรุงการนิยามปัญหาแล้วต้องทิ้งการออกแบบและเขียนเอกสารส่วนใหญ่ใหม่
    กรณีแย่ที่สุดคือเมื่อปรับปรุงการนิยามปัญหาแล้วกลับเห็นวิธีแก้ง่าย ๆ ที่ไม่ต้องใช้การออกแบบซับซ้อน ผู้เขียนลงทุนเวลากับการออกแบบซับซ้อนไปมาก และในอดีตคณะกรรมการจำนวนมากก็เคยมองความซับซ้อนแบบนั้นเป็นหลักฐานในการเลื่อนตำแหน่ง จึงเกิดการต่อต้านวิธีแก้แบบง่าย
    ผมเคยเห็นเอกสารออกแบบที่ไม่มีทางเลือกอื่นเลยด้วย เป็นเพียงการเขียนแบบใช้แรงงานมาก ๆ ว่าต้องทำอะไร หรือมีใครอยากทำอะไรเท่านั้น
    พอเป็นแบบนี้ เอกสารออกแบบเมื่อมองแบบพร่ามัวก็กลายเป็นเหมือนระบบติดตามบั๊ก ทุกคนกำลังทำเอกสารออกแบบของตัวเอง และไม่ทำบั๊ก เพราะบั๊กไม่ช่วยให้เลื่อนตำแหน่งได้
    เวลาเข้าทีมใหม่ มักพูดกันเหมือนว่าแค่อ่านเอกสารออกแบบก็พอ แต่จริง ๆ แล้วหลายครั้งไม่ได้มีการติดตามจากศูนย์กลาง ในหลายทีม เอกสารออกแบบไม่ได้เป็นของทีมหรือโปรเจกต์ แต่เป็นของบุคคล เพราะจะรับประกันได้ว่าคนอื่นไม่ได้มีส่วนร่วม และนี่ก็เพราะคณะกรรมการเลื่อนตำแหน่งอีกเช่นกัน
    ยังมีเอกสารออกแบบจำนวนมากที่ไม่มีสิทธิ์เข้าถึง ไม่ใช่เพราะเป็นความลับสุดยอด แต่แค่มันเป็นอย่างนั้นเอง ในทีมไม่ได้มีเอกสารออกแบบแค่สองสามฉบับ แต่มีเป็นภูเขาที่ต้องอ่าน ในสถานการณ์ที่รอบการย้ายงานภายใน/ออกจาก Google อยู่ราว 2 ปี เอกสารจำนวนมากจึงเลือนหายไปตามกาลเวลา
    ถ้าเป็นบริษัทอื่น ก็คงคล้ายกับการบอกคนที่เพิ่งเข้าทีมใหม่ว่า “สิ่งที่ต้องรู้ก็แค่อ่านบั๊กที่ปิดไปแล้วทั้งหมด หรืออ่านข้อความ commit ทั้งหมดใน branch หลัก”
    ถ้าเป็นที่อื่น หลังมื้อกลางวันคงถูกดึงไปคุยกับทีมหน้ากระดานไวท์บอร์ดสักหลายชั่วโมงเพื่อช่วยกันนิยามปัญหา รุ่นพี่จะสอนรุ่นน้องแบบเรียลไทม์ว่าควรคิดกับปัญหาแบบนี้อย่างไร และวนปรับอย่างรวดเร็ว
    ส่วนใหญ่คงถูกเขียนไว้ในระบบติดตามบั๊ก หรือถ้าเป็นงานใหญ่ ก็เขียนไว้ในวิกิหรือโฟลเดอร์ของโปรเจกต์ให้เป็นของทุกคน
    ปัญหาข้างต้นทั้งหมดปรับปรุงได้ และจริง ๆ ก็เคยพยายามปรับปรุงแล้ว แต่วัฒนธรรมเปลี่ยนช้า แนวคิดเรื่องเอกสารออกแบบเองนั้นดี แต่มีหลุมพราง และวิธีที่คนจำนวนมากใน Google ใช้กันไม่ใช่คำตอบ
  • ไม่เพียงเท่านั้น ยังทำไปเพื่อตอบสนองข้อกำหนดเชิงราชการด้วย เช่น การคอมเมนต์ในเอกสารของคนอื่นเพื่อแสดง ภาวะผู้นำ
    คิดถึงเอกสารออกแบบที่มีคุณค่ามากกว่าต้นทุน
  • ผมไม่ค่อยแน่ใจว่าความต่างคืออะไร อาจเป็นแค่การให้บริบทมากกว่าที่สมาชิกทีมต้องการ หรือทำให้ปัญหาดูซับซ้อนกว่าความเป็นจริง
    โดยรวมแล้วผมไม่ค่อยเห็นว่ากลยุทธ์นั้นได้ผล
    ในทางกลับกัน มีเอกสารยาว ๆ สำหรับให้บริบท เช่น ทีมทำอะไรไปแล้ว กำลังทำอะไรอยู่ และปัญหาคืออะไร เป็นต้น และเอกสารพวกนั้นมักจะยาวและเกินจริง

• ผมทำงานอยู่ที่บริษัทที่ถูกพูดถึง แต่ประสบการณ์ของผมไม่เหมือนกับผู้เขียน
  เอกสารออกแบบมีหลายประเภท แต่ในบรรดานั้นไม่มีแบบไหนที่มีประโยชน์เลย ผมแทบไม่เคยเห็นเอกสารออกแบบที่มีประโยชน์ที่ Google เอกสารออกแบบให้ความรู้สึกเหมือนทำมาเพื่อวิศวกรที่ยึดติดกับกระบวนการมากเกินไป
  ประเภทที่ผมเคยเห็นก็ประมาณนี้: เอกสารออกแบบเพื่อเลื่อนตำแหน่ง ไม่ได้อธิบายว่าพยายามแก้ปัญหาอะไร แต่พูดแค่ว่าโปรเจกต์นี้ยอดเยี่ยมแค่ไหนและทำให้บริษัทดีขึ้นอย่างไร ข้อสรุปเชิงตรรกะคือผู้เขียนควรได้เลื่อนตำแหน่ง
  เอกสารออกแบบแบบ Turbo Encabulator เป็นเอกสารคุยเรื่องเทคนิคที่เต็มไปด้วยศัพท์ที่เห็นครั้งแรก จนถ้าไม่ใช่ซีเนียร์ของทีมก็อ่านไม่เข้าใจ บางครั้งผมก็ยังไม่แน่ใจว่าพวกซีเนียร์เองเข้าใจหรือเปล่า
  เอกสารออกแบบของบัณฑิตจบใหม่เป็นเอกสารที่ไม่มีเนื้อหา แต่ทำให้ยาวที่สุดเท่าที่คนเพิ่งจบมหาวิทยาลัยจะพยายามพิสูจน์อะไรบางอย่างได้ มันไม่ได้ถ่ายทอดข้อมูล และมักจะคัดลอกโค้ดที่เขียนไว้แล้วมาแปะยาว ๆ จนได้ราว 70 หน้า
  เอกสารออกแบบแบบข้อเท็จจริงแต่งขึ้นเต็มไปด้วยคำว่า “ทุกคนรู้กันอยู่แล้ว”, “ใคร ๆ ก็พูดแบบนั้น” แม้จะไม่โจ่งแจ้งเหมือนนักการเมือง แต่ก็ดันแบบของตัวเองด้วยถ้อยคำทำนองว่า “สิ่งนี้ทำตามแนวปฏิบัติที่ดี”, “ซอฟต์แวร์นี้ช้า ดังนั้น…” โดยไม่มีบอกว่าใครเป็นคนกำหนดแนวปฏิบัติที่ดี ทำไมถึงดี อะไรช้า วัดแล้วหรือยัง หรือเป็นความรู้สึกของผู้ใช้ปลายทางหรือไม่
  99% ของเอกสารออกแบบที่ผมเคยเห็นเป็นแบบนี้ มีข้อยกเว้น แต่จากประสบการณ์พบได้น้อยมาก น่าแปลกใจที่ผู้เขียนผลักดันแนวปฏิบัตินี้ แต่เขาไม่ได้เป็นวิศวกร เป็น director ดังนั้นในตำแหน่งนั้นเอกสารออกแบบอาจสมเหตุสมผลก็ได้ และผมก็ยังไม่รู้ว่าคนแบบนั้นสร้างคุณค่าอะไร
  [1] https://en.wikipedia.org/wiki/Turbo_encabulator

  • ดูเหมือนว่าเรื่องนั้นจะเปลี่ยนไปแล้ว ผมทำงานที่นั่นช่วงปี 2006~2014 ตอนนั้นเอกสารออกแบบส่วนใหญ่มีประโยชน์ และทำตามโครงสร้างพื้นฐานที่อธิบายไว้ในบทความ แม้จะไม่มี system context diagram ก็ตาม
    สิ่งที่สังเกตได้ตั้งแต่ช่วงแรกคือเอกสารออกแบบที่เก็บไว้ใน Google Docs มักมีคุณภาพต่ำกว่าเอกสารที่อยู่ใน version control repository ผมไม่รู้ว่านั่นเป็นตัวชี้วัดแทนช่วงเวลาที่เขียนหรือเปล่า หรือเพราะกระบวนการ code review เข้มงวดกว่าการแก้ไข Docs
    ตอนที่ผมเขียนเอกสารออกแบบขนาดใหญ่ น่าจะประมาณ 40 หน้า ผมเขียนด้วย HTML แบบทำมือ ตามธรรมเนียม และให้ผ่านระบบ code review ผมยังเอาไปลง mailing list กลางกับเว็บเซิร์ฟเวอร์ด้วย และการได้ feedback จากพนักงานหมายเลข 3 ก็เป็นเรื่องที่ดี มันถูกจัดเรียงตามหมวดหมู่ไว้ในตำแหน่งกลาง ทำให้ค้นหาได้ง่าย
    ผมจำไม่ได้ว่าในตอนนั้นเอกสารออกแบบเพียงชิ้นเดียวจะมีน้ำหนักมากพอจนสำคัญต่อการเลื่อนตำแหน่ง การเลื่อนตำแหน่งควรเกี่ยวกับผลกระทบโดยรวม ไม่ใช่ผลงานชิ้นใดชิ้นหนึ่ง แน่นอนว่าระบบมีข้อบกพร่องใหญ่ ๆ และมักมีการตัดสินใจที่น่าประหลาดใจในทางไม่ดีออกมา แต่ตอนนั้นผมไม่จำได้ว่าเคยอ่านเอกสารออกแบบที่ปรับแต่งมาเพื่อการประเมินผลงาน
    ถ้าหาเว็บไซต์ที่รวบรวมเอกสารออกแบบ HTML แบบทำมือยุคแรก ๆ ได้ ผมแนะนำให้ลองไล่อ่านดู ถ้าเป็นตอนที่ระบบเหล่านั้นยังใช้งานจริงอยู่ อาจรู้สึกว่ามันมีประโยชน์มากกว่านี้
    เอกสารเก่าบางส่วนอย่าง SmartASS เต็มไปด้วยคำอธิบายละเอียดเกี่ยวกับสมการและโมเดลพื้นฐาน และช่วยได้มากในการทำความเข้าใจว่ามันทำงานอย่างไรและทำไมถึงเลือกแนวทางนั้น ต่อมายังมีอิทธิพลต่อการออกแบบของผมด้วย ผมไม่ใช่ director เป็นแค่วิศวกรธรรมดา และมันช่วยได้จริง
    ในบรรดาเอกสารออกแบบของ Chrome ที่ลิงก์อยู่บนเว็บไซต์ chromium.org ก็มีบางชิ้นที่เคยช่วยให้เข้าใจโครงสร้างในอดีตได้
  • ผมเคยเห็นว่าเอกสารออกแบบทำงานได้ดีในกรณีที่บทบาทจูเนียร์มีจำนวนค่อนข้างมากเมื่อเทียบกับซีเนียร์
    มันทำให้นักพัฒนาจูเนียร์คิดวิธีแก้ไว้ล่วงหน้าและให้เหตุผลรองรับการตัดสินใจได้ และทำให้นักพัฒนาซีเนียร์ตรวจสอบการตัดสินใจนั้นและให้ feedback แบบ asynchronous ได้
    แต่ผมทำงานกับสตาร์ตอัปมาตลอด เลยไม่เคยอยู่ในองค์กรวิศวกรที่มีมากกว่า 30~40 คน Big Tech คงต่างออกไป แต่ประสบการณ์ของผมเป็นบวก
  • เหมือนจะขาดไปอย่างหนึ่ง มีเอกสารแบบ ขอร้องล่ะ ให้ฉันเริ่มเขียนโค้ดสักที
  • ผมมองว่าจุดประสงค์ของเอกสารเทคนิค ไม่ว่าจะเป็นเอกสารออกแบบหรือเอกสารที่สั้นกว่านั้น เรียบง่ายมาก เมื่อคุณมาถึงจุดที่ไม่สามารถเก็บรายละเอียดทั้งหมดของโปรเจกต์ไว้ในหัวได้พร้อมกัน คุณก็ควรเขียนเอกสาร
    ในทำนองเดียวกัน ถ้าการอธิบายให้วิศวกรคนอื่นฟังใช้เวลานาน อย่างน้อยสัก 30 นาที ก็ควรเขียนเอกสารเพื่อประหยัดเวลา
    ผมไม่เข้าใจว่าจะคิดได้อย่างไรว่าไม่จำเป็นต้องเขียนเอกสารเลย
  • จากประสบการณ์ของผม ประเภทที่สองหมายถึง “ผมต้องสื่อสารกับทีมหรือ technical leader ว่าผมกำลังทำอะไร และแก้ปัญหานี้อย่างไร”
    ต่อมาเมื่อเตรียมเลื่อนตำแหน่ง ก็จะเติมบริบทให้เอกสารในหมวดที่ 2 มากพอจนกลายเป็นหมวดที่ 1

• โดยทั่วไป documentation เป็นเรื่องดี แต่แนวทางนี้ดูมีข้อบกพร่อง
  มีการบอกว่า “ก่อนเริ่มโปรเจกต์เขียนโค้ด” ผู้เขียนหลักของระบบซอฟต์แวร์หรือแอปพลิเคชันจะสร้างเอกสารที่ค่อนข้างไม่เป็นทางการ แต่ การออกแบบเองก็คือโปรเจกต์เขียนโค้ด และทั้งสองอย่างเป็นงานเดียวกัน
  ความคิดที่ว่าสามารถคิดการออกแบบให้ครบหมดบนกระดาษก่อน commit โค้ดนั้นผิด แนวทางเอกสารออกแบบเองก็ยอมรับจริง ๆ ว่าช่วงต้นต้องเขียนโค้ดบ้าง แต่พยายามแบ่งเขตมันอย่างเข้มงวดว่าเป็น “prototype ที่แสดงว่าแบบสามารถนำไปทำได้”
  ลักษณะเด่นอย่างหนึ่งของเอกสารออกแบบล่วงหน้าคือมันเปิดทางให้ผู้คนจับผิด หรือก็คือรีวิว ก่อนเริ่มเขียนโค้ดจริง จากประสบการณ์ของผม แบบนั้นทำให้เอกสารค่อย ๆ พองขึ้นด้วย caveat และการถกเถียงทางเลือกที่ไร้ความหมายมากขึ้นเรื่อย ๆ และกลายเป็นเอกสาร “ขอร้องล่ะ ให้ฉันสร้างสิ่งนี้สักที” มากกว่าเอกสารออกแบบ
  ถ้ามีประเด็นสถาปัตยกรรมสำคัญที่จำเป็นต้องเปลี่ยนทิศทาง คุยและร่วมงานกับคนที่เหมาะสมล่วงหน้าย่อมดีกว่าทำเอกสารออกแบบละเอียดแล้วถูกยิงตก
  ถ้ารักษาให้ใกล้เคียงกับแนวคิด “เอกสารที่ค่อนข้างไม่เป็นทางการ” มากกว่า และอัปเดตเอกสารไปพร้อมกับการดำเนินงาน มันอาจมีประโยชน์จริง เพราะสามารถสร้างทั้งระบบที่ทำงานได้และเอกสารที่มีประโยชน์ไปพร้อมกันได้ แต่สิ่งนั้นใกล้เคียงกับ การทำ documentation ในฐานะส่วนหนึ่งของกระบวนการต่อเนื่องและร่วมมือกัน มากกว่าเอกสารออกแบบ

  • ถ้าโปรเจกต์ใหญ่พอและคิดมาดีพอ ก็สามารถสะท้อนการเปลี่ยนแปลงสถาปัตยกรรมได้โดยไม่เพิ่มต้นทุนมากนักเมื่อเทียบกับปริมาณงานทั้งหมด

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

  • ผมก็เหมือนกัน ผู้ได้ประโยชน์มากที่สุดจากเอกสารออกแบบคือ กระบวนการคิดของผมเอง อดีต Googler

• มันได้ผลจริงไหม? ดีกว่าทางเลือกอื่นหรือเปล่า? การถกเถียงเรื่องนั้นอยู่ตรงไหน?
  ตอนทำงานที่ Amazon วัฒนธรรมเอกสารออกแบบยอดเยี่ยมมาก งานถัดมาดูเหมือนยืมวัฒนธรรมวิศวกรรมของ Google หรือวัฒนธรรมสตาร์ทอัพทั่วไปใน SF มา แต่กระบวนการเอกสารออกแบบเหมือนมุกตลกที่ไร้ประโยชน์

  • เอกสารออกแบบคือ เครื่องมือสำหรับการถกเถียง แนวคิดคือมันเป็นวิธีที่มีประสิทธิภาพที่สุดในการสื่อสารเจตนา แรงจูงใจ และเหตุผลว่าทำไมถึงไม่เลือกทางเลือกอื่น
    มันเป็นกลไกหนึ่งที่เชื่อมกับวัฒนธรรมการทำงานที่กว้างกว่า ถ้าทำงานคนเดียวก็เป็นแบบฝึกหัดฟุ่มเฟือย แต่ถ้าเป็นทีมขนาดใหญ่ มันช่วยดึงความเชี่ยวชาญที่มากขึ้นของทั้งทีมมาใช้ และทำหน้าที่เป็นเอกสารด้วย
    รูปแบบความล้มเหลวมีอยู่หลายแบบ การให้ความสำคัญกับผลผลิตมากกว่าผลลัพธ์คือความไม่สอดคล้องแบบคลาสสิก เช่น เขียนเอกสาร 40 หน้าเพื่อเลื่อนตำแหน่ง ซึ่งมักไม่ได้ผล เว้นแต่ว่าเป็นกรณีระดับจูเนียร์มาก ๆ ที่พิสูจน์แค่ว่าสามารถร้อยเรียงประโยคได้มากกว่าวิศวกรรมเชิงลึก
    อีกอย่างคือมันเกินจำเป็นสำหรับทีมที่ทำงานคนเดียว ทีมเล็กอื่น ๆ อาจสื่อสารกันได้พอแล้วด้วย issue เช่น Jira และเซสชันแยกเพื่อเทียบไอเดียกัน
    วิศวกรก็ต้องได้รับการ onboarding เรื่องวิธีเขียนเอกสารออกแบบให้มีประสิทธิภาพด้วย คอมเมนต์บน ๆ ที่ท้อใจเพราะความพยายามครั้งแรกไม่ได้รับคำชมทันทีอาจเป็นสัญญาณหนึ่ง
    การเขียนเกี่ยวกับโค้ดเป็นเรื่องยาก และปกติ HN ก็ชื่นชมการฝึกแบบนี้ ถ้าทำงานเป็นทีม ก็ควรระวังเมื่อรู้สึกว่างานของตัวเองมีแต่สิ่งที่ไม่จำเป็นต้องอธิบายและคิดให้ลึกผ่านเอกสารที่แชร์ได้เสมอ
  • อยากรู้ว่าวัฒนธรรมเอกสารออกแบบของ Amazon มีจุดไหนดีที่สุด

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

  • ผมคิดว่าคนประเมินความพยายามที่ใช้กับเอกสารออกแบบส่วนใหญ่สูงเกินไปมาก
    งานพัฒนาส่วนใหญ่ก็เดินหน้าไปตามปกติ และบางครั้งก็รีบเขียนเอกสารขึ้นมาเพื่อให้หาเหตุผลรองรับ CL ได้ง่ายขึ้น
    ใน 10 ครั้งอาจมีสักครั้งที่เห็นใครทำเกินเหตุ แต่สำหรับวิศวกรซอฟต์แวร์ทั่วไป มันไม่ใช่ การเสียเวลา ครั้งใหญ่
  • Carl Icahn เหมาะกับงานแบบนั้นพอดี https://www.bloomberglinea.com/english/i-fired-12-floors-of-...
  • สมมติฐานของผมคือ Google ยุคหลังถูกออกแบบมาเพื่อซ่อน กำไรจากการผูกขาด
    ถ้าอยากเผาเงินให้มากที่สุดเท่าที่เป็นไปได้ ก็คงออกแบบบริษัทแบบนี้เป๊ะ ๆ

• วัฒนธรรมเอกสารออกแบบมีแนวโน้มจะผลักทุกคนเข้าไปอยู่ใน ชั้นของการหาเหตุผลรองรับ งานของตัวเอง วัฒนธรรมการหาเหตุผลรองรับเป็นรูปแบบที่กดทับนักนวัตกรรมอย่างมาก แม้เพื่อนร่วมงานจะเสริมแรงมันในฐานะวัฒนธรรมก็ตาม
  ระบบนี้มีแนวโน้มจะขัดขวางความพยายามที่มีวิสัยทัศน์และโปรเจกต์ที่ทะเยอทะยาน ความพยายามที่ไม่ได้ยึดฉันทามติเป็นศูนย์กลางจะถูกกดไว้ และถ้าคิด “นอกบรรทัดฐานที่ได้รับอนุญาต” ก็จะถูกกลุ่มลงโทษ
  ระบบแบบนี้ก่อให้เกิด groupthink และลักษณะที่ยึดธรรมเนียมว่า “วิธีที่เราทำงานกัน” โดยเนื้อแท้แล้วบังคับให้การทำงานด้วยวิธีอื่นกลายเป็นความเสี่ยงต่ออาชีพ
  ใน Silicon Valley มีวัฒนธรรมบริษัทสารพัดรูปแบบที่อาศัยคำพูดซ้ำซากซึ่งห่อด้วยคำว่า ‘Agile’ และ ‘Design Thinking’ ส่วนใหญ่มักใกล้เคียงกับการทำให้เป็นสถาบันที่แสร้งว่าเป็น ‘วิธีที่ถูกต้อง’ พร้อมองค์ประกอบเสริมที่บังคับทางสังคมให้เข้ากับรูปแบบหนึ่งของ วัฒนธรรมลัทธิทางวิศวกรรม ที่แคมปัสนั้นไปถึง
  ผมเจอคนที่ลาออกเพราะมองว่ามันจำกัดอาชีพ ทั้งที่การทำงานที่ Google สบายมาก จนนับไม่ถ้วน และไม่ใช่จำนวนน้อย ๆ

  • นั่นแหละเหตุผลที่เขาจ่ายค่าตอบแทนสูงขนาดนั้น มันคือกับดัก และเคยมี สถานะ ภายนอกจากการทำงานที่นั่นด้วย แต่ตอนนี้ส่วนใหญ่จางไปแล้ว
    คุณบรรยายความหงุดหงิดที่ผมเจอที่นั่นได้ตรงมาก ถึงอย่างนั้นผมก็ยังอยากได้ค่าตอบแทนนั้นอีก
    เรื่อง Agile ผมได้รู้จัก Agile เมื่อราว 20 ปีก่อนในรูปแบบ eXtreme Programming ซึ่งต่างจากลัทธิ cargo cult ที่เป็น SCRUM หรือของเลียนแบบทุกวันนี้โดยสิ้นเชิง
    สุดท้ายแล้วมันเป็นชุดหลักการที่ให้อำนาจเชิงสร้างสรรค์แก่ดีเวลลอปเปอร์ ไม่ให้ผู้จัดการเข้ามายุ่งกับวิธีการ และทำให้งานสำเร็จ แลกกับการให้ลูกค้ามีอำนาจบอกว่าจะทำอะไร เมื่อไร และมากแค่ไหน
    ดีเวลลอปเปอร์ประเมินเอง และหลักการคือ “ไม่สร้างสิ่งที่ไม่จำเป็น” ไม่มีการออกแบบล่วงหน้าขนาดใหญ่ ส่วน refactoring, testing, architecture และ design ถูกรวมไว้ใน overhead ต่อเนื่องในฐานะแนวปฏิบัติมาตรฐานที่ดี ไม่ใช่ story หรืองานแยกต่างหาก
    การประชุมวางแผนคือเพื่อนร่วมงานมาปรับความเข้าใจกันในห้อง และ story ถูกเขียนเป็นโพสต์อิทบนไวต์บอร์ดด้วยถ้อยคำที่ไม่ใช่เทคนิคให้น้อยที่สุด Standup คือการที่ผู้คนยืนเป็นวงจริง ๆ แล้วอัปเดตสั้นมากเท่าที่คนอื่นอาจสนใจ ไม่ใช่พิธีกรรมเพื่อพิสูจน์ว่าวันนี้มาทำงานแล้วหรือเพื่อโชว์ผลงาน
    ในระบบนี้ การออกแบบเป็นคุณสมบัติที่เกิดขึ้นจากกลุ่มผู้เชี่ยวชาญที่สร้างสรรค์ทำงานร่วมกัน มันไม่ได้排除เอกสารออกแบบ และยังมีการคุยเรื่องสถาปัตยกรรมอยู่ แต่ไม่ได้เรียกร้องกระบวนการ PRD/เอกสารออกแบบอย่างชัดเจน
    อยากกลับไปทำงานในที่แบบนั้นอีก Google ตรงกันข้ามโดยสิ้นเชิง และทุกอย่างใช้เวลานานเกินไป
  • นั่นแหละเหตุผลที่ Google ทำผลิตภัณฑ์อะไรไม่ได้เลย เมื่อวาน Pixel 7 เครื่องใหม่ของผมพัง
    พฤติกรรมปลอม ๆ แบบ “พวกเราฉลาดมาก” นี้ก็เป็นรูปแบบหนึ่งของ งานสูญเปล่า บริษัทควรโฟกัสกับผลิตภัณฑ์ที่ใช้งานได้จริง และประเมินตัวเองจากสิ่งนั้น

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

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

  • Chromium: https://www.chromium.org/developers/design-documents/
    Kubernetes: https://github.com/kubernetes/enhancements/tree/master/keps
  • สิ่งที่ใกล้เคียงที่สุดเท่าที่ผมเคยเห็นคือ เอกสาร RFD ของ Oxide Computer Company และหลายฉบับในนั้นเปิดเผยต่อสาธารณะ
    ตัวอย่าง: https://rfd.shared.oxide.computer/rfd/0177
    ดัชนีหลัก: https://rfd.shared.oxide.computer
  • ถ้าเป็นฝั่งโอเพนซอร์ส ก็คงต้องพูดถึงโปรเจกต์ GitHub ที่มี README ยอดเยี่ยมที่สุด