Discord ไม่ใช่เอกสารประกอบ
(shkspr.mobi)- Discord มีประโยชน์สำหรับการขอความช่วยเหลือแบบเรียลไทม์และการแชร์สิ่งที่กำลังทำอยู่ แต่ในเชิงโครงสร้างแล้วไม่เหมาะจะใช้แทน เอกสารประกอบที่ยั่งยืน ของโปรเจกต์
- เป็นเรื่องธรรมดาที่โปรเจกต์โอเพนซอร์สจะสื่อสารในที่ที่ผู้ใช้อยู่รวมกัน แต่ Discord โดยพื้นฐานแล้วเป็นเครื่องมือที่เหมาะกับ บทสนทนาชั่วคราว
- แพลตฟอร์มพัฒนา Watchy ชี้นำให้ผู้ใช้ไปถามข้อมูลนอกเหนือจากคู่มือการตั้งค่าพื้นฐานใน Discord ทำให้ผู้ใช้ต้องไล่อ่านข้อความเองโดยไม่มีเอกสาร API
- ต่อให้ค้นหาคำถามเจอ ก็ยังยากที่จะเข้าใจ บริบทและความเกี่ยวข้อง ของคำตอบ ทำให้คำสั่งหรือออปชันเดียวกันอาจถูกตีความผิดไปอย่างสิ้นเชิง
- หากไม่นำคำถามที่พบบ่อยและคำตอบมารวมไว้ในที่เดียว ผู้ใช้ก็จะยังต้องเจอกับแรงเสียดทานที่ไม่จำเป็นตลอดกระบวนการเรียนรู้และใช้งานผลิตภัณฑ์
สิ่งที่ Discord ช่วยได้ และสิ่งที่แทนไม่ได้
- Discord ช่วยให้ได้รับ ความช่วยเหลือแบบเรียลไทม์ กับปัญหา และเห็นได้ทันทีว่าคนอื่นกำลังสร้างอะไรหรือติดขัดตรงไหน
- ความยากในการเข้าร่วมก็ไม่ได้ต่างจากเครื่องมือสื่อสารอื่นอย่าง Slack, Matrix, Gitter, IRC มากนัก
- การที่โปรเจกต์โอเพนซอร์สยึดหลักว่า “ไปอยู่ในที่ที่มีผู้ใช้” ก็เป็นเรื่องธรรมชาติ
- มีการยกเปรียบเทียบว่า ถ้าทุกคนอยู่บน Facebook การโพสต์แค่บน MySpace ก็ไม่มีความหมาย
- แม้การที่ Discord ไม่ใช่โอเพนซอร์สจะชวนให้ติดใจอยู่บ้าง แต่ก็ยังใช้งานได้ดีแม้เปิดผ่าน Firefox
- ประเด็นสำคัญคือ Discord เหมาะกับ บทสนทนาชั่วคราว แต่ไม่ใช่สิ่งทดแทนเอกสารประกอบ
ช่องว่างด้านเอกสารที่เห็นชัดจาก Watchy
- ระหว่างเริ่มต้นใช้งานแพลตฟอร์มพัฒนา Watchy ผู้เขียนยิ่งใช้งานก็ยิ่งรู้สึกหงุดหงิดมากขึ้น
- วิธีที่ให้ข้อมูลนั้นใกล้เคียงกับ “นี่คือ คู่มือพื้นฐาน สำหรับการตั้งค่า ส่วนที่เหลือไปถามใน Discord เอา”
- เมื่อไม่มีเอกสาร API ผู้ใช้จึงต้องเลื่อนอ่านข้อความจำนวนมากด้วยตัวเองเพื่อหาข้อมูลที่ต้องการ
- เมื่อข้อมูลคงอยู่แค่ในบทสนทนา Discord ก็จะไม่มีจุดอ้างอิงที่มีโครงสร้างแบบเอกสารอีกต่อไป
ปัญหาเรื่องบริบทที่การค้นหาแก้ไม่ได้
- การค้นหาใน Discord แทบไม่ช่วยแก้ปัญหา หากผู้คนไม่ได้ใช้งานเธรดกันอย่างเป็นระบบ
- อาจหาคำถามเจอ แต่หาคำตอบที่มาคู่กันได้ยาก
- ต่อให้เจอคำตอบ ก็ยากที่จะตัดสินว่านั่นเป็นคำตอบของคำถามปัจจุบัน หรือเป็นคำตอบของอีกบทสนทนาหนึ่ง
- ในตัวอย่างบทสนทนา มีทั้งคำถามเรื่องคำสั่ง fullscreen คำถามเรื่องฟอร์แมตดิสก์ และคำตอบเรื่องแฟลก
-fปะปนกัน ทำให้ บริบทของเป้าหมายคำตอบ ไม่ชัดเจน - ในโครงสร้างแบบนี้ คำสั่งหรือออปชันเดียวกันอาจถูกอ่านไปคนละความหมายโดยสิ้นเชิง
แรงเสียดทานที่มือใหม่และคำถามซ้ำ ๆ ต้องเจอ
- เมื่อข้อมูลกระจัดกระจายอยู่ใน Discord ผู้เริ่มต้นก็มักจะถามคำถามที่มีคนถามบ่อยอยู่แล้วซ้ำอีก
- บางคนก็ตอบสนองต่อคำถามของมือใหม่เหล่านี้ด้วยความรำคาญ
- หากมีคำถามซ้ำจำนวนมาก วิธีแก้ที่ตรงจุดกว่าคือรวบรวมคำถามและคำตอบที่ใช้ร่วมกันไว้ในที่เดียว
- FAQ อาจไม่ใช่รูปแบบสุดท้ายที่ถูกต้องสำหรับเอกสารประกอบแบบครบถ้วน แต่ในฐานะการ จัดระเบียบข้อมูลขั้นต่ำ แล้ว มันเป็นสิ่งจำเป็น
เอกสารอย่างน้อยที่สุดที่ควรถูกรวบรวมไว้
- ไม่จำเป็นต้องยึดตาม Four-Document Model อย่างเคร่งครัด
- โมเดลนี้เองก็มี คำวิจารณ์ อยู่เช่นกัน
- ถึงอย่างนั้น การไม่รวบรวมคำถามที่พบบ่อยและคำตอบเอาไว้ก็ยังเป็นเรื่องที่เข้าใจได้ยาก
- FAQ เพียงอย่างเดียวอาจแก้ปัญหาเอกสารประกอบแบบครอบคลุมไม่ได้ แต่โปรเจกต์ที่ไม่ทำแม้แต่ FAQ ก็ควรทบทวนการเปิดตัวผลิตภัณฑ์เสียใหม่
1 ความคิดเห็น
ความเห็นจาก Hacker News
มีแนวโน้มที่สตาร์ตอัปจะยัดทุกอย่างรวมถึงงานซัพพอร์ตเข้าไปไว้ใน Discord แต่ด้วยเหตุผลที่บทความพูดถึง มันจึงเป็นประสบการณ์ที่แย่มากสำหรับผู้ใช้และลูกค้า
เสียเวลามากเกินไปกับการทำความเข้าใจโครงสร้างช่องและหาว่าควรโพสต์ที่ไหน แถมยังค้นหายากด้วยว่ามีคนโพสต์วิธีแก้ไว้แล้วหรือยัง และก็ไม่รู้ด้วยว่าในความเป็นจริงจะมีใครมาตอบหรือเปล่า ถ้าคุณกำลังทำสตาร์ตอัปแล้วคิดจะย้ายทุกอย่างไป Discord ก็ควรทบทวนอย่างจริงจัง
แทนที่จะปล่อยให้ข้อมูลสาธารณะที่หาได้จาก Google Search หรือจากพอร์ทัลช่วยเหลือและเว็บเอกสารทำหน้าที่ของมัน กลับกลายเป็นว่าทุกคนต้องเข้ามาถามคำถามเดิมในห้องแชต ทั้งที่มีโอกาสสูงว่าเคยมีคำตอบไปแล้ว แบบนี้ยิ่งเพิ่มงานให้ตัวเองด้วย รู้แหละว่ามีคนจำนวนมากที่ไม่อ่านคู่มือหรือเอกสารแล้วก็ถามเลย แต่ถ้า self-service support ช่วยแก้ปัญหาได้สัก 10% การดูแลเอกสารให้ทันสมัยก็คุ้มค่าแล้ว
เรื่องนี้เคยเป็นประเด็นใน Hacker News มาก่อนแล้ว: “Discord is a black hole for information”
https://knockout.chat/thread/33251/1
https://news.ycombinator.com/item?id=30311982
อย่างน้อยในกรณีของผม กลุ่มผู้ชมยังอายุน้อยมากและทุกคนก็อยากอยู่บน Discord ถ้ามีสมาชิกชุมชนที่ดีพอจะอาสามาช่วยดูแล ก็แทบจะเดินไปได้เองโดยไม่ต้องออกแรงมากนัก จากประสบการณ์ของผม Discord เป็นสิ่งที่ชุมชนดึงเข้ามาก่อน และการเริ่มใช้ก็ไม่ใช่ความคิดของผมเอง แพลตฟอร์มอื่นต่อให้ผมพยายามผลักดันก็ไม่มีใครอยากใช้ ไม่รู้ว่าทำไม แต่มันเวิร์กเฉย ๆ
รองรับเสียง วิดีโอ และข้อความ และยังรองรับทั้งการโต้ตอบแบบเรียลไทม์ แบบล่าช้า และแบบอัตโนมัติด้วย รวมถึงใช้งานได้บนเว็บ เดสก์ท็อป และมือถือ จึงเข้าใจได้ถ้าใครอยากทำมาตรฐานให้เหลือเครื่องมือเดียวเพื่อทำให้ขั้นตอนซัพพอร์ตและการอบรมง่ายขึ้น ถ้าปรับปรุงด้านการเข้าถึงและการใช้งานได้ Discord ก็อาจเป็นความก้าวหน้าครั้งใหญ่ในหลายด้าน การลดจำนวนช่องและตั้งชื่อให้ชัดเจนเป็นก้าวแรกที่ดี และข้อความต้อนรับสั้น ๆ พร้อมทิปเล็กน้อยก็น่าจะช่วยได้
การตั้งค่าการแจ้งเตือนเริ่มต้นเพี้ยนสุด ๆ ทำให้ทุกอย่างดูเหมือนยังไม่ได้อ่าน ทุกอย่างสำคัญไปหมด และมีป้ายแดงเต็มไปหมด ทุกครั้งที่เข้า “เซิร์ฟเวอร์” ใหม่ อย่างแรกที่ต้องทำคือคลิกขวาแล้วเลือก “ระงับ @everyone และ @here” กับ “ระงับการเมนชันบทบาท” ถึงอย่างนั้นข้อความ @everyone, @here, @role ก็ยังถูกไฮไลต์เป็นสีเหลืองเหมือนถูกเมนชันถึงตัวโดยตรงอยู่ดี ฟีเจอร์เมนชันแบบกระจายประกาศเป็นอะไรที่ยังไงก็ต้องถูกใช้เกินจำเป็น จนไม่ควรถูกสร้างมาตั้งแต่แรก
ช่องพิมพ์ข้อความก็พยายามฉลาดเกินไปแต่ในขณะเดียวกันก็งี่เง่าเกินไปด้วย มันทำให้ระบบแทนที่ข้อความพื้นฐานของ macOS พัง และถ้าข้อความขึ้นต้นด้วยอักขระบางตัว มันจะกินบางตัวอักษรไปด้วยเท่าที่จำได้ แต่ถ้าพิมพ์ @username เองแล้วไม่เลือกจากระบบ autocomplete ที่เด้งขึ้นมา การเมนชันก็จะไม่ทำงาน
UI สำหรับเพิ่มอีโมจิรีแอ็กชันก็แย่อย่างน่าขำ มันจะแสดงอีโมจิล่าสุดก่อน จากนั้นก็แสดงอีโมจิคัสตอมจากทุกเซิร์ฟเวอร์แบบไม่รู้จบ ทั้งที่ถ้าไม่ได้สมัครสมาชิกก็ใช้ไม่ได้อยู่แล้ว กว่าจะถึงอีโมจิยูนิโค้ด
ป๊อปอัป แบนเนอร์ และทูลทิปที่เอาไว้โปรโมตการสมัครแบบเสียเงินก็น่ารำคาญมาก รวมถึงป๊อปอัป “มีอะไรใหม่” ด้วย ถ้าใช้แพ็กเกจฟรีมาหลายปีแล้วและยังไม่จ่ายเงิน ก็น่าจะพอประเมินได้แล้วว่าโอกาสเปลี่ยนเป็นลูกค้าจ่ายเงินคงต่ำ อยากให้เลิกอัปเซลที่คอยทรมานสายตาโดยหวังว่าจะเปลี่ยนคนพวกนี้ให้เป็นลูกค้าเสียที
ไฟล์ก็โดนบล็อกบ่อยเกินไปว่า “too powerful” แถมก็ไม่มีตัวเลือกให้บีบอัดตามแบบที่เซิร์ฟเวอร์ต้องการด้วย ทั้งที่บ่อยครั้งก็ไม่จำเป็นต้องส่งภาพหรือวิดีโอแบบสมบูรณ์ระดับบิตต่อบิต สักวันหนึ่งผมตั้งใจว่าจะทำ เดสก์ท็อปเมสเซนเจอร์แบบหลายโปรโตคอล สมัยใหม่เป็นโปรเจกต์ถัดไป และ Discord จะอยู่บนสุดของรายการบริการที่ต้องรองรับ
เริ่มเหนื่อยกับปฏิกิริยาตอบสนองฉับพลันของ HN ต่อหัวข้อบางอย่างมากขึ้นเรื่อย ๆ
คนจำนวนมากที่กำลังคอมเมนต์อยู่ตอนนี้ดูเหมือนจะไม่ได้อ่านด้วยซ้ำว่าบทความพูดถึงอะไร แต่อยากระบายความคิดถึงต่อเมลลิงลิสต์ยุคก่อนกับเอกสารที่ทำค้าง ๆ ครึ่ง ๆ มากกว่า เอกสารพวกนั้นอย่างดีที่สุดก็มีแค่ตัวอย่างโค้ดสักชิ้น และโดยเฉลี่ยก็เป็นแค่ “สารบัญ” ของซอร์สโค้ดที่คุณต้องไปอ่านอยู่ดี สำหรับผมแล้ว ถ้าโปรเจกต์พวกนี้มี BBS ควบคู่ไปกับ Discord ก็คงดี แต่การได้คุยกับคนที่สร้างสิ่งที่ผมสนใจ และกลายเป็นเพื่อนกันไปในกระบวนการนั้น เป็นเรื่องที่ดีมากจริง ๆ
สำหรับ Watchy เอกสารถือเป็นจุดเริ่มต้นที่ดี: https://watchy.sqfmi.com/docs/getting-started
มีแผนภาพสถาปัตยกรรม มีตัวอย่างโค้ดสำหรับกรณีใช้งานที่พบบ่อยอยู่สองสามอย่าง และยังสื่อได้ค่อนข้างดีด้วยว่านี่เป็นโปรเจกต์แนว “ผจญภัย” ที่มีขอบเขตให้สำรวจค่อนข้างกว้าง วันหนึ่งอาจเพิ่มลิงก์ไปยังบทความหรือโปรเจกต์ที่คนอื่นทำไว้ก็ได้ แต่ก็ไม่แน่ใจว่าจะมีทรัพยากรแบบนั้นมากแค่ไหน มันเป็นผลิตภัณฑ์ที่ค่อนข้างเฉพาะกลุ่ม
มีประเด็นหลายอย่างที่กระตุ้นคนจำนวนมากในที่นี่ และไม่ว่าตัวบทความจริงจะเป็นอะไร พวกเขาก็จะโพสต์คอมเมนต์ที่เตรียมไว้ล่วงหน้าโดยไม่อ่านอยู่ดี แค่เห็นว่ามีคนสร้างบัญชีชั่วคราวชื่อประมาณ “discordsucks” มาคอมเมนต์ก็ชัดพอแล้ว
แถมพวกนั้นก็ไม่ใช่ “เซิร์ฟเวอร์” แต่เป็น ช่อง
เราก็เริ่มใช้ https://www.answeroverflow.com/ เพื่อมิเรอร์เนื้อหาจาก Discord ขึ้นเว็บเหมือนกัน
จะทำของคล้าย ๆ กันเองก็ได้ แต่ AnswerOverflow มีฟีเจอร์ที่ใช้ได้ดี และจัดการประเด็นเรื่องความยินยอมได้ดีด้วย ถ้าจะเริ่มใช้ Discord ใหม่ ขอแนะนำอย่างยิ่งให้ระบุไว้ตั้งแต่แรกว่าสามารถมิเรอร์เนื้อหาไปที่อื่นได้ แม้ว่าจะยังไม่ทำทันที เพราะถ้าค่อยมาทำทีหลังจะยากกว่ามาก
ทางออกที่ดีกว่าคือไม่ใช้ Discord เลย แต่ด้วยแรงเสียดทานของทางเลือกอื่น การคัดค้านจากเพื่อนร่วมงาน และความกลัวว่าชุมชนจะกระจัดกระจาย สำหรับพวกเราแล้วนี่คือทางออกที่ดีที่สุด การไม่ใช้ Discord ตั้งแต่แรกอาจดีที่สุดก็จริง แต่อย่างน้อยสำหรับบางชุมชน มันก็มีข้อดีตรงที่คนคุ้นเคยกันอยู่แล้ว แม้เราจะดูแลเอกสาร “ที่เป็นทางการ” อยู่ด้วย แต่ก็ยากจะใส่ทุกอย่างลงไปได้ และใน Discord ก็มีข้อมูลมีคุณค่าที่ไม่ได้ถูกบันทึกไว้ที่อื่น
คือให้การสื่อสารหลักอยู่บนแพลตฟอร์มแบบเปิดอย่าง XMPP MUC, Matrix Spaces, IRC หรือที่อย่าง Zulip, Mattermost ต่อให้เครื่องมือแชตยอดนิยมประจำสัปดาห์เปลี่ยนไป อย่างน้อยฐานหลักก็จะไม่ถูกดำเนินการโดยบริษัทยักษ์ใหญ่ที่อาจตัดบริการด้วยการแบนหรือกำแพงเก็บเงินแบบใหม่
ที่บริษัทก่อนเราใช้ Discord สำหรับซัพพอร์ต และมันยอดเยี่ยมมาก
การสร้างชุมชนช่วงแรกต้องใช้เวลา แต่พอสร้างได้แล้วจะกลายเป็นทรัพย์สินชิ้นใหญ่ ข้อดีที่สุดคือฟีดแบ็กจากผู้ใช้แบบเรียลไทม์ การรักษาผู้ใช้ไว้ การร่วมมือกันระหว่างผู้ใช้ และความช่วยเหลือจากชุมชน Discord เป็นการสนทนาแบบโต้ตอบ ดังนั้นเมื่อได้รับฟีดแบ็กเกี่ยวกับผลิตภัณฑ์ ก็สามารถคุยได้เร็วว่าผู้ใช้เจอปัญหาอะไรแน่ และเสนอวิธีแก้พร้อมดูปฏิกิริยาได้ทันที ถ้าผู้ใช้เข้าถึงผู้พัฒนาผลิตภัณฑ์ได้โดยตรง พวกเขาจะรู้สึกว่าความเห็นของตัวเองถูกนำไปใช้จริงและมีแนวโน้มจะอยู่ต่อมากขึ้น พอชุมชนใหญ่พอ ผู้ใช้ก็จะช่วยกันระดมความคิดเพื่อปรับปรุง หรือช่วยผู้ใช้ใหม่ ทำให้นักพัฒนาต้องใช้เวลากับงานซัพพอร์ตน้อยลง
ส่วนตัวผมคิดว่าคำวิจารณ์ว่า “มันไม่ถูกทำดัชนี” ค่อนข้างน่าขำ คุณเคยค้นหา error แปลก ๆ แล้วไปเจอเมลลิงลิสต์บ่อยแค่ไหน โดยมากเมลที่ถูกทำดัชนีมักไม่มีคำตอบ และถึงมีก็มักแก้ปัญหาไม่ได้อยู่ดี การไล่ดูบันทึกการสนทนาไม่ใช่วิธีทำเอกสารที่มีประสิทธิภาพ เราใช้ฟีดแบ็กจากชุมชนเป็นสัญญาณว่าตรงไหนในเอกสารยังขาดอยู่ แล้วก็อัปเดตเอกสารตามนั้น ถ้าสัปดาห์นี้มีผู้ใช้ 10 คนถามเรื่องฟีเจอร์ X นั่นก็แปลว่าต้องอัปเดตเอกสารแล้ว
ตอนนี้ถึงจะมีเธรด แต่ทุกคนก็ต้องใช้มันด้วย ถ้าคุณเจอคนที่ถามคำถามเดียวกันแต่ไม่มีคำตอบ ก็ไม่มีทางรู้ได้ว่ามันไม่มีคำตอบจริง ๆ หรือมีคนไปตอบไว้นอกเธรดใต้ข้อความลงไปอีก 1000 ข้อความ ถ้าไม่มีการทำเธรด มันคือหายนะ
ผมเคยค้นหา error แปลก ๆ แล้วไปเจอเมลลิงลิสต์หลายครั้งเหมือนกัน แต่ฟอรัมดีกว่า ใน Discord หรือ Slack แทบไม่เคยได้คำตอบเลย หรือถึงได้ก็มักไม่ใช่คำตอบที่ดี ถ้าคำถามถูกดันขึ้นไปจนหายจากสายตา ก็จะไม่มีใครเห็น และถึงมีคนตอบ ก็มักเป็นมือใหม่ไฟแรงที่ยังไม่เข้าใจปัญหาดีพอ
เมื่อก่อนผมโพสต์ในฟอรัมบ่อย และมักแสดงปัญหาอย่างแม่นยำด้วยตัวอย่างที่พิสูจน์ซ้ำได้และผ่านการตรวจสอบอย่างดี อีกอย่างคือผมจะไล่ดูคำถามที่ยังไม่มีคำตอบในหน้าหนึ่งหรือสองหน้าแรกแบบ “ถามหนึ่ง ตอบหนึ่ง” แล้วถ้ารู้อะไรก็จะตอบไว้
ช่อง “ซัพพอร์ต” ใน Discord หรือ Slack แทบทั้งหมดที่ผมเจอแย่มาก มันเป็นวิธีที่บริษัทลดงานซัพพอร์ตลงโดยขยับความคาดหวังไปในทางเพิกเฉยต่อผู้ใช้ Drone(CI) ก็เพิ่งทำแบบนั้นเหมือนกัน และในช่อง Slack ก็มีแต่คำถามจากผู้ใช้เต็มไปหมด
ผมคิดว่าเหตุผลจริง ๆ ที่ Discord และที่คล้ายกันได้รับความนิยมคือ ต้นทุนความพยายามต่ำ เขาไม่ได้คาดหวังให้คุณเอาตัวอย่างที่ทำเสร็จสมบูรณ์มาแสดง เพราะมันเป็นบทสนทนา คุณเลยโยนคำถามที่ยังครึ่ง ๆ กลาง ๆ ไว้ได้ แล้วรอให้ใครสักคนค่อย ๆ ชี้นำและจับมือพาไป ราคาที่ต้องจ่ายคือการสูญเสียคนที่อยากเข้าร่วมชุมชนที่ต้องลงแรงกันจริง ๆ แทนพื้นที่ที่เต็มไปด้วยอีโมจิกับมีม
ตัวเว็บเองกลายเป็น พื้นที่ที่แทบค้นหาอะไรไม่ได้ ไปแล้ว เพราะสแปม SEO คุณภาพการค้นหาของ Google ที่แย่ลง การที่ทุกอย่างถูกเอาเข้าไปไว้หลังรั้ว และแนวโน้มขึ้นราคา API กับกักข้อมูลไว้เพื่อต่อสู้กับ LLM
โดยทั่วไปผมคิดว่าการตายลงของเว็บที่ค้นหาได้เป็นตัวผลักให้คนย้ายไป Discord มากขึ้น ไม่ใช่ว่าจะโทษนักพัฒนาแต่ละคนได้ เพราะอย่างที่ว่า สำหรับพวกเขามันให้ผลตอบแทนสุทธิจริง ๆ สิ่งที่เราต้องการคือ “ozempic web” คือเว็บที่ยังคงขนาดระดับปี 2023 ไว้ แต่เบากว่า ทำดัชนีได้ ไม่มีรั้วกั้น และมีเนื้อหาถม ๆ กับการหารายได้แบบแย่งความสนใจน้อยกว่า ก่อนจะไปถึงจุดนั้น ต่อให้ด่าผู้เล่นมากแค่ไหน เกมเองก็บิดเบี้ยวอยู่ดี
แต่นั่นคือ อคติจากการเลือกตัวอย่าง บทสนทนาที่เจ้าของเข้าร่วมย่อมดำเนินไปได้ดีโดยธรรมชาติ แล้วบทสนทนาอื่นล่ะ ถ้ามีคำถามที่ไม่มีใครตอบแล้วสามชั่วโมงต่อมาถูกบทสนทนาอื่นกลบ บริษัทก็จะไม่เห็นคำถามนั้น บริษัทไม่มีทางเห็นสิ่งที่ตัวเองไม่เห็นได้ และตรงนั้นเองที่อคติจากการเลือกตัวอย่างเกิดขึ้น
Discord ดึงข้อมูลออกไปจากพื้นที่เปิดแบบนั้น บางครั้งผมถึงขั้นค้นพบโปรเจ็กต์จากคำตอบเหล่านั้นด้วยซ้ำ แต่ผมสนใจ FLOSS มากกว่าสตาร์ตอัปที่ใช้โค้ดปิด ดังนั้นจุดโฟกัสของลูกค้าหลักอาจเป็นคนละปัญหากัน
ข้อแรกคือที่นี่ทำสำเร็จในการผนวก Discord เข้ากับกระบวนการทำเอกสาร ถ้าได้รับฟีดแบ็กเกี่ยวกับ X ก็จะอัปเดตเอกสารให้ครอบคลุม X แต่ Eden บอกว่าหลายโปรเจ็กต์ตอบเรื่อง X ใน Discord แล้วก็ไม่อัปเดตเอกสารต่อ
ข้อที่สองคือทีมตอบข้อความใน Discord ได้เร็ว หลายทีมกลับยืดเยื้อหรือไม่ตอบเลย
แชตไม่ใช่เอกสาร
เวลาติดขัดขึ้นมา ผมมักจะลองไล่ดูการติดตั้งใช้งานแบบคร่าว ๆ ก่อน แต่ถ้าเป็นโค้ดเบสที่ไม่คุ้นเคยก็แทบไม่ช่วยอะไร พอไปดูเอกสารกลับมีแค่ลิงก์ว่า “เข้าร่วมชุมชน Discord” ก็เลยต้องเปิด Discord ติดตั้งอัปเดต ทำ 2FA แบบกำหนดเองผ่านอีเมล ยอมรับเงื่อนไขการใช้งานที่เปลี่ยนใหม่ ปิดแบนเนอร์ Nitro ยอมรับกฎของเซิร์ฟเวอร์ แล้วค่อยเข้าไปที่ #general ผมโพสต์คำถามโดยพยายามใส่บริบทให้มากที่สุด แต่ก็ไม่มีคำตอบ สุดท้ายเลยต้องเปิดดีบักเกอร์แล้วไล่ดูไลบรารีหรือเฟรมเวิร์กทีละบรรทัดเพื่อหาว่ามันเกิดอะไรขึ้น ทำสำเนาที่แก้ไขได้เพื่อเพิ่ม logging และลองแก้หลายอย่างอยู่หลายชั่วโมง กว่าจะพบว่า X ไม่รองรับ Y หรือไม่ก็ต้องเข้ารหัสค่าเป็น Base 47 หรือ Latin 1 แล้วส่งต่อไป แล้วอีก 3 วันต่อมาตอนตี 1 ก็มีคำตอบใน Discord แบบเหมือนจะเมิน ๆ ว่าให้ไปดูบทสนทนาที่เกิดขึ้นก่อนผมเข้าร่วม 2 สัปดาห์
แชตผลักภาระในการทำความเข้าใจปัญหาด้วยตัวเอง และการที่ผู้ใช้ต้องช่วยกันเอง ไปให้ผู้ใช้อย่างมาก โดยเฉพาะในโลกของงานแบบ asynchronous มันไม่สามารถทดแทนเอกสารได้ หลายคนคิดว่ามันเหมาะกับงาน asynchronous เพราะตอบแบบ asynchronous ได้ แต่จริง ๆ แล้วไม่ใช่ เพราะมันช่วย ปลดบล็อก แบบ asynchronous ไม่ได้
ตลอด 12 ปีที่ผ่านมา ผมทำงานกับ Django ราว 8 ปี และแทบมีแค่ตอนที่พบช่องโหว่ด้านความปลอดภัยและต้องยืนยันรายละเอียดระดับลึกมากเท่านั้นที่ผมใช้ดีบักเกอร์กับโค้ด Django ในทางกลับกัน ผมใช้เวลา 1 เดือนทำโปรเจกต์งานอดิเรกราว 5 วันกับโปรเจกต์ที่แนะนำให้ใช้ Discord แทนเอกสาร แล้วผมต้องใช้ดีบักเกอร์ถึง 3 ครั้งเพื่อให้รู้ว่ามันเกิดอะไรขึ้น
มีวิธีแก้เชิงวัฒนธรรมและกระบวนการที่ช่วยได้จริงอยู่ คือเปลี่ยนคำถามใน Discord ให้เป็น การอัปเดตเอกสาร อย่างละเอียด
ถ้าทำแบบนั้น Discord ก็อาจเป็นตัวเร่งชั้นยอดที่ช่วยยกระดับคุณภาพเอกสารของโปรเจกต์ได้ เพียงแต่มันต้องมีวินัยมากพอ
ถ้าผมต้องทำงานของตัวเอง แต่ก็ต้องเฝ้า Slack, Discord, Mattermost ทั้งวันด้วย แบบนั้นก็แปลว่าผมไม่ได้ทำงานของตัวเอง ถ้างานของผมคือ support ก็อีกเรื่องหนึ่ง นักพัฒนามักทั้งไร้เดียงสา มีความเห็นแรง และอยากทำให้คนอื่นพอใจ เลยกลายเป็นอีกตัวอย่างหนึ่งที่การพัฒนาซอฟต์แวร์ไปแบกรับงานธุรกิจอีกด้านอย่าง support ด้วย ตอนยุค Agile ก็ต้องแบกงานบริหารโปรเจกต์ ตอนยุค DevOps ก็ต้องแบกงานดูแลระบบ ทั้งนี้ก็ขึ้นอยู่กับบริบท
รู้สึกว่าน่าจะมีใครทำไปแล้ว แต่ครั้งล่าสุดที่ผมหาดูก็ยังไม่เจออะไรเลย
ในฐานะผู้ใช้ผลิตภัณฑ์ ผมไม่อยากเข้าไปอยู่ในคอมมูนิตี้ของคนแปลกหน้าแบบสุ่มแล้วโดนดึงเข้าไปในบทสนทนาที่ไม่ก่อให้เกิดผลผลิต
ผมก็ไม่อยากคอยรีเฟรชแชตที่เกือบจะ synchronous ตลอดเวลา และไม่อยากพลาดข้อมูลสำคัญเพียงเพราะหายไปวันเดียว ผมอยากให้บริษัทเคารพเวลาและความสนใจของผม
การค้นหา ของ Discord แย่อย่างน่าตกใจ ผู้ใช้บ่นกันมาหลายปีแล้วแต่ก็ยังไม่ดีขึ้น
แค่นี้อย่างเดียวก็ไม่คู่ควรจะใช้เป็นเอกสารแล้ว
ถ้าผู้ใช้ออกจากเซิร์ฟเวอร์ไปแล้ว คุณจะไม่สามารถค้นหาเนื้อหาที่คนนั้นโพสต์แบบระบุตัวได้อีก ต่อให้ผู้ใช้ยังอยู่ในเซิร์ฟเวอร์ การค้นหาของ Discord ก็ดูเหมือนไม่ได้รู้จักรายชื่อผู้ใช้ปัจจุบันทั้งหมดเสมอไป เลยอาจทำให้หาสิ่งที่คนนั้นโพสต์ได้ยาก ถ้าค้นหารายการที่มีผลลัพธ์จำนวนมาก แล้วพยายามกลับไปหน้าต้น ๆ ซึ่งก็คือผลลัพธ์แรกสุด มันจะพัง ตัวอย่างเช่น ในบางเซิร์ฟเวอร์ ผมกระโดดไปยังข้อความแรกของตัวเองไม่ได้ คุณยังค้นหาภายในเธรดหนึ่งโดยเฉพาะก็ไม่ได้ด้วย วิธีค้นหาข้อความเองก็เคยทำให้ผมหงุดหงิดมาก่อน แต่ตอนนี้นึกตัวอย่างชัด ๆ ไม่ออกแล้วว่าปัญหาคืออะไร
บริษัทแบบนี้มักมองการมีส่วนร่วม หรือพูดอีกอย่างคือการเสียเวลา ว่าเป็นคุณภาพที่พึงประสงค์
ด้วยเหตุผลเดียวกัน Slack ก็ไม่ใช่เอกสาร
ตอนนี้ผมกำลังทำงานเรื่องปรับปรุงการจัดทำเอกสารทั้งบริษัท เราเป็นสตาร์ตอัปเก่าที่อยู่ในสายงานซึ่งใช้เวลานานมากกว่าจะออกสู่ตลาด และในไตรมาสที่ผ่านมา ผมเป็นผู้นำ 2 โปรเจกต์ที่ใช้เวลาหลายสัปดาห์เพื่อตอบคำถามเกี่ยวกับโค้ดเก่า บางครั้งคนเขียนเดิมออกจากบริษัทไปแล้วและไม่มีเอกสารเลย บางครั้งคนเขียนเดิมยังอยู่ในบริษัท แต่จำไม่ได้อย่างแท้จริงด้วยซ้ำว่าตัวเองเคยเขียนโค้ดนั้น และแน่นอนว่าไม่มีเอกสารเหมือนกัน ทุกครั้งจะมีคนบอกว่ามันต้องมีบทสนทนาใน Slack ที่อธิบายทุกอย่างอยู่ที่ไหนสักแห่ง ไม่ ไม่มีหรอก ทุกโปรเจกต์และทุกแอปพลิเคชันต้องมีเอกสารออกแบบก่อนเริ่มงาน และหลังจากนั้นต้องมีคู่มือผู้ใช้ และต้องมีการดูแลรักษาเอกสารเหล่านั้นจริง ๆ
รู้สึกสับสนที่ชุมชนวงกว้างหลงใหล Discord กันอย่างผิดปกติ
อย่างที่มีคนอื่นพูดไว้ โดยเนื้อแท้แล้วมันก็คือ IRC ที่มีมัลติมีเดียเพิ่มเข้ามา ทำไมถึงโปรโมตกันหนักขนาดนั้น? ต่อให้ยอมรับแนวคิดที่ถกเถียงกันมากอย่าง “รับการซัพพอร์ตบน Discord” ตัวผลิตภัณฑ์เองก็ไม่ได้พิเศษอะไรนัก แค่ดีกว่าผลิตภัณฑ์คล้ายกันที่มีอยู่ก่อนหน้าเล็กน้อยเท่านั้น ยังไม่รวมถึงความกังวลที่สมเหตุสมผลมากเกี่ยวกับการที่ข้อมูลผู้ใช้จะถูกนำไปใช้อย่างไรในอนาคต
และผู้ใช้จำนวนมากไม่เคยใช้ IRC มาก่อน อีกอย่างหนึ่งคือมีแอปที่ใช้ชื่อเดียวกับตัวบริการด้วย เลยกลายเป็น “สิ่ง” เดียวแบบเดียวกับ Instagram หรือ TikTok พอนึกดูว่ามีคนมากแค่ไหนที่ไม่เคยคิดเลยว่าแอป reddit กับบริการ/เว็บไซต์ reddit เป็นคนละอย่าง ก็น่าประหลาดใจไม่น้อย ชุมชน IT วงกว้างเองก็ยังใกล้เคียงกับกลุ่มเฉพาะเล็ก ๆ อยู่ดี และเราก็มักลืมเรื่องนั้น
ถ้าไม่นับ Slack แล้ว Discord คือผลิตภัณฑ์ประเภท แชตและเสียง บนเบราว์เซอร์ที่มุ่งเป้าผู้บริโภคซึ่งมีคุณภาพสูงที่สุดตัวถัดมา ออกแบบมาดี เสถียร และมีอินเทอร์เฟซผู้ใช้ที่เรียบง่ายเป็นส่วนใหญ่
IRC และทางเลือกอื่น ๆ ที่มักถูกพูดถึงจำนวนมาก มักติดขัดตั้งแต่ขั้นแรกแม้แต่กับแชตข้อความล้วน ๆ ยังไม่ต้องพูดถึงมัลติมีเดียเลย คู่แข่งที่เข้าใจเรื่องนั้นก็ล้มเหลวในขั้นตอนการนำไปทำจริง หรือไม่ก็มาช้าเกินไป ความกังวลด้านความเป็นส่วนตัวมีลำดับความสำคัญต่ำเกินไปสำหรับผู้ใช้ จึงไม่น่าจะมากพอที่จะทำลาย first-mover advantage ของ Discord ได้
แค่นี้ก็เพียงพอแล้ว แต่ในหลายด้านมันก็ดีกว่า IRC มากด้วย แน่นอนว่าคุณสามารถรัน IRC bouncer สำหรับ Libera เองบน “shell account” หรือ AWS micro instance ที่เปิดทิ้งไว้ตลอดก็ได้ แต่ยกเว้นคนที่เนิร์ดสุด ๆ แล้ว ใครจะอยากทำแบบนั้นกัน ต่อให้ทำก็ยังดูข้อความเก่าไม่ได้เมื่อเพิ่งเข้าช่องใหม่ และถึงจะมีบอตเก็บประวัติหรือหน้า archive มันก็ยังเทอะทะ อย่าลืมด้วยว่าแต่ละเครือข่ายก็มีพิธีกรรม NickServ ของตัวเอง และตอนนี้ก็ยังไม่มีมัลติมีเดียที่ดีซึ่งผู้ใช้ส่วนใหญ่คาดหวังจากวัฒนธรรมการสื่อสารทั่วไป
เมื่อนำ UI ที่ใช้ได้ดี, ลิงก์พรีวิวที่ทำให้ผู้ส่งรู้ได้อย่างแม่นยำว่าผู้รับจะเห็นอะไร, การจัดรูปแบบข้อความแบบ Markdown, เมทาดาทามากพอที่จะเชื่อมโยงการตอบกลับ, อีโมจิรีแอ็กชันที่กระชับและไม่ทำให้ช่องกลายเป็นสแปม, รวมถึงการประชุมเสียง/วิดีโอที่ทำงานได้ดีโดยไม่ต้องตั้งค่าเพิ่มเข้ามา ยกเว้นเรื่องการค้นหาและ UI การค้นหาแล้ว ในบรรดาทางเลือกอื่น UI ก็ดีมากเช่นกัน เว้นแต่จะนับ Zulip เมื่อก่อนฉันใช้ IRC ทุกวัน เคยดูแล bouncer สำหรับเก็บ archive และจัดการช่องชุมชนด้วย แต่ตอนนี้ไม่สนใจมันอีกแล้ว ช่วงหนึ่งฉันทั้งยุ่งและป่วย ชื่อผู้ใช้ NickServ ที่ลงทะเบียนไว้หมดอายุจนการจัดการช่องพังไปด้วย และนั่นก็ทำให้หมดไฟ ตอนที่ทุกคนย้ายจาก Freenode ไป Libera ฉันก็เลิกใช้ IRC ไปเลย
ขณะเดียวกัน ฉันก็เห็นด้วยอย่างมากกับคำวิจารณ์ที่ว่าหลายโปรเจ็กต์ใช้ Discord ในลักษณะที่ทำให้เอกสารที่มีประโยชน์ซึ่งยังคงถูกสร้างขึ้นเรื่อย ๆ ถูกทำหายไปในทางปฏิบัติ เราควรยอมรับว่า Discord สร้างผลิตภัณฑ์ที่คุณภาพดี ขัดเกลาแล้ว และมี network effect ที่เข้าใจได้ แต่ก็น่าเสียดายที่ทำให้โปรเจ็กต์เปิด archive ของช่องแบบสาธารณะและทำให้ค้นหาได้ยาก อีกทั้งมันไม่ใช่ทั้งเครือข่ายแบบเปิดและไม่ใช่ผลิตภัณฑ์โอเพนซอร์ส เรื่องที่การค้นหาและ UI การค้นหาแย่มากก็เช่นกัน
เมื่อพิจารณาว่าโปรเจ็กต์ที่ฉันเห็นว่าใช้ Discord ส่วนใหญ่ รวมถึงโปรเจ็กต์เชิงพาณิชย์ด้วย เป็นโอเพนซอร์ส ก็ยังมีความเป็นไปได้ว่า Matrix จะเข้ามาแทนที่ได้สักวัน หาก Discord ไม่เปิดเครือข่ายของตัวเองในทางใดทางหนึ่ง อย่างไรก็ตาม โปรเจ็กต์ที่มีอยู่แล้วไม่สามารถย้ายประวัติแชตและผู้ใช้ไปได้ ส่วนโปรเจ็กต์ใหม่ก็มีแรงเสียดทานสูง เพราะต้องไปพบผู้ใช้ในเครือข่ายที่ผู้ใช้อยู่กันแล้ว เช่น Discord, Slack, Telegram