แผนที่ ทองคำ และเครื่องเทศ: เหตุใดการละเลยการจัดทำเอกสารจึงอาจทำให้โครงการของคุณพังทลายได้

ทรัพย์สินที่มีค่าที่สุดที่นักสำรวจในสมัยก่อนนำกลับบ้านจากการเดินทางคืออะไร? ทองคำและเครื่องเทศ? ไม่ใช่ แผนที่

คริสโตเฟอร์ โคลัมบัสคงไม่มีวันเดินทางอันโด่งดังของเขาในปี ค.ศ. 1492 ได้เลยหากไม่มี แผนที่ ออกแบบโดยบรรพบุรุษของเขา เกมจารกรรมเพื่อให้ได้แผนที่โปรตุเกสเป็นรากฐานของบริษัท Dutch East India ซึ่งถือได้ว่าเป็นบริษัทที่มีราคาแพงที่สุดในประวัติศาสตร์มนุษย์ ในช่วงรุ่งเรืองในปี ค.ศ. 1637 บริษัทนี้มีมูลค่า 78 ล้านกิลเดนของเนเธอร์แลนด์ ซึ่งเทียบเท่ากับ 7.9 ล้านล้านเหรียญสหรัฐ ในปี 2017 เป็นเงินมากกว่า 10 ล้านล้านดอลลาร์ในปี 2024 มากกว่า Microsoft , Nvidia และ Apple รวมกัน สมบัติที่จับต้องได้จากดินแดนใหม่นั้นมีความสำคัญในระยะสั้น แต่จากมุมมองในระยะยาวแล้ว ความรู้คือสิ่งที่สร้างโชคลาภที่แท้จริง

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

โค้ดประหลาดๆ

“คุณคงจำได้ดีอยู่แล้วว่าการหยุดชะงักแบบสะกดจิตของรูปแบบเซลล์ประสาทในสมองสามารถสแกนได้ด้วยลำแสงแม่เหล็กไฟฟ้าพิเศษซึ่ง—” “หยุดซะ!” อาร์ด วาร์กพูดอย่างใจร้อน “คุณหมายถึงอะไร – อย่างที่เราจำได้ดีอยู่แล้ว” เราจะจำมันได้อย่างไรในเมื่อเราไม่เคยรู้จักมันเลย? – คำพูดนี้จาก Wacky World เรื่องราวของเอ็ดมอนด์ แฮมิลตัน นักเขียนนิยายวิทยาศาสตร์ชื่อดัง กล่าวถึงมนุษย์ต่างดาว ไม่ใช่โปรแกรมเมอร์ อย่างไรก็ตาม หลายคนมองว่านักพัฒนาซอฟต์แวร์ราวกับว่าพวกเขามาจากอีกโลกหนึ่ง โดยเฉพาะผู้ที่มีความคิดคลุมเครือเกี่ยวกับการพัฒนาซอฟต์แวร์และความซับซ้อนของมัน ความจริงก็คือ นักพัฒนาซอฟต์แวร์มักจะคิดว่าคนอื่นรู้โค้ดดีพอๆ กับพวกเขา และมักจะคิดว่าเอกสารทางเทคนิคไม่จำเป็น ความคิดแบบนี้เสี่ยงที่จะทำให้โครงการมีความซับซ้อนและไม่สามารถเข้าใจได้สำหรับคนนอกเหมือนกับ “การหยุดชะงักแบบสะกดจิต” ซึ่งท้ายที่สุดแล้วอาจส่งผลให้โครงการประสบความสำเร็จได้

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

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

ปัจจัยรถบัส, Burnout และสัตว์ประหลาดมหัศจรรย์อื่นๆ

ทฤษฎีเป็นสิ่งที่ดี แต่การปฏิบัติจริงนั้นน่าเชื่อถือกว่า ต่อไปนี้เป็นตัวอย่างบางส่วนที่อิงจากเรื่องจริง โดยมีเพียงชื่อของบุคคลและบริษัทที่สมมติขึ้น กรณีศึกษาสั้นๆ เหล่านี้ครอบคลุมถึงปัญหาทั่วไปที่สุดที่เกิดจากแนวทางปฏิบัติด้านเอกสารทางเทคนิคที่ไม่ดี

เรื่องที่ 1: ไม่สามารถปรับขนาดได้

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

เรื่องที่ 2: ปัญหาการบำรุงรักษา

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

เรื่องที่ 3: นักพัฒนาหมดไฟ

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

เรื่องที่ 4: ปัจจัยรถบัส

ในบริษัท "NoDocsNeeded" ผลิตภัณฑ์ซอฟต์แวร์ที่น่าสนใจกำลังได้รับการพัฒนาโดย John ซึ่งเป็นนักพัฒนาคนสำคัญที่มีความรู้มากมายแต่ไม่ได้สนใจที่จะบันทึกข้อมูลไว้ ผู้จัดการของเขาก็ไม่ได้สนใจที่จะโน้มน้าวใจเขาเช่นกัน มีอยู่วันหนึ่งที่ John เดินทางไปทำธุรกิจและไม่ได้กลับมาอีกเลย หากไม่มีเอกสารหรือความเข้าใจเกี่ยวกับสถาปัตยกรรมและตรรกะของผลิตภัณฑ์ สมาชิกในทีมที่เหลือก็แทบจะทำอะไรไม่ได้เลย โปรเจ็กต์นั้นถูกระงับ และเงินที่ลงทุนไปก็สูญเปล่า บทเรียนนั้นง่ายมาก: การจัดทำเอกสารและการกระจายความรู้ภายในทีมเป็นสิ่งสำคัญเพื่อหลีกเลี่ยงการพึ่งพาบุคคลเพียงคนเดียว อย่างไรก็ตาม พวกเขายังคงมองหา John...

เรื่องที่ 5: ไม่มีศาสดาที่ได้รับการต้อนรับที่โอเพ่นซอร์ส

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

จากเด็กเรือสู่กัปตัน

โอเค เรามีทฤษฎีและการปฏิบัติมาบ้างแล้ว ตอนนี้มาเจาะลึกการวิจัยและสถิติกันเลย แบบสำรวจนักพัฒนา Stack Overflow ปี 2024 รัฐ ผู้ตอบแบบสอบถามร้อยละ 84 ใช้เอกสารทางเทคนิคเพื่อทำความเข้าใจฟังก์ชันการทำงานของเทคโนโลยี อย่างไรก็ตาม แม้จะมีเอกสารประกอบแล้ว พวกเขาก็ยังไม่สามารถค้นหาคำตอบที่ต้องการได้ ดังจะเห็นได้จากแหล่งข้อมูลยอดนิยมลำดับถัดมา ได้แก่ Stack Overflow (ร้อยละ 80) บทช่วยสอนแบบเขียน (ร้อยละ 68) บล็อก (ร้อยละ 61) และวิดีโอแนะนำการใช้งาน (ร้อยละ 54) การวิจัยของ Microsoft: ชีวิตประจำวันของนักพัฒนาซอฟต์แวร์ พบ โดยเฉลี่ยแล้ว นักพัฒนาใช้เวลา 1-2% ของวัน (8-10 นาที) ไปกับเอกสาร และนักพัฒนา 10.3% กล่าวว่าเอกสารที่ล้าสมัยทำให้พวกเขาต้องใช้เวลามากเกินไปในการค้นหาคำตอบด้วยตัวเอง ความจำเป็นของเอกสารเป็นปัญหาสำคัญสำหรับชุมชนวิชาการเช่นกัน การค้นหา <"เอกสารประกอบ" และ "ซอฟต์แวร์"> ใน Google Scholar ง่ายๆ ผลผลิต ผลลัพธ์มากกว่า 4 ล้านรายการ แสดงให้เห็นชัดเจนว่ามีสิ่งพิมพ์ทางวิทยาศาสตร์จำนวนมากที่กล่าวถึงประเด็นนี้

ข้อสรุปหลักๆ นั้นเรียบง่ายอย่างน่าประหลาดใจ: #1 – ทุกคนจำเป็นต้องมีเอกสารประกอบเมื่อต้องทำความเข้าใจเกี่ยวกับเทคโนโลยีและ/หรือผลงานของผู้อื่น แต่ #2 – แทบไม่มีใครสนใจที่จะเขียนและดูแลเอกสารประกอบ และด้วยเหตุนี้ #3 – เอกสารประกอบจำนวนมากจึงเขียนได้ไม่ดี ล้าสมัย และไร้ประโยชน์โดยทั่วไป แล้วจะต้องทำอย่างไร? เปลี่ยนแรงจูงใจของคุณในทุกระดับ

กลุ่มนักวิจัยจากมหาวิทยาลัยวิทยาศาสตร์ประยุกต์ฮันและมหาวิทยาลัยโกรนิงเกน (ทั้งสองแห่งในเนเธอร์แลนด์) ระบุตัวตน ปัญหาทั่วไปที่สุดเกี่ยวกับเอกสารทางเทคนิค:

• เอกสารประกอบที่ไม่เป็นทางการซึ่งมักใช้โดยนักพัฒนานั้นเข้าใจได้ยาก

• เอกสารถือเป็นความสิ้นเปลืองเมื่อไม่ได้มีส่วนช่วยในผลิตภัณฑ์ขั้นสุดท้ายทันที

• ประสิทธิภาพการทำงานของนักพัฒนาจะวัดจากปริมาณซอฟต์แวร์ที่ทำงานอยู่เท่านั้น

• เอกสารมักจะไม่ซิงค์กับซอฟต์แวร์จริง

• นักพัฒนาส่วนใหญ่มักจะมุ่งเน้นแค่ระยะสั้น โดยเฉพาะในสภาพแวดล้อมการพัฒนาซอฟต์แวร์อย่างต่อเนื่อง

  
  

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