เหตุใดสิ่งที่ผิดพลาดจึงเกิดขึ้น: บันทึกจาก Alexandr Wang ซีอีโอของ Scale AI [บทความแปล]

ส่วนหนึ่งของบันทึกที่ Alexandr Wang ซีอีโอของ Scale AI ส่งถึงทีม Scale AI ในปี 2019

การบีบอัดข้อมูล: ทำไมงานจึงผิดพลาด?

1. การบีบอัดข้อมูลคืออะไร?

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

2. ทำไมการบีบอัดข้อมูลจึงก่อให้เกิดปัญหา?

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

3. ความสัมพันธ์ระหว่างขนาดองค์กรกับการบีบอัดข้อมูล

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

4. กรณีตัวอย่างของปัญหาการบีบอัดข้อมูล

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

5. วิธีแก้ปัญหาการบีบอัดข้อมูล

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

6. สรุปประเด็นสำคัญ

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

[ethanhur]

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

[ashbyash]

ขอบคุณสำหรับคำพูดดี ๆ ครับ!

[pmc7777]

ที่จริงแล้วนักพัฒนาจำนวนไม่น้อยก็น่าจะอยากเห็นและทำความเข้าใจปัญหาด้วยตัวเองหากเป็นไปได้

[beoks]

> ความอยากรู้อยากเห็นและการตั้งคำถามเพิ่มเติม: คนที่แก้ปัญหาต้องตั้งคำถามอย่างต่อเนื่อง และพยายามทำความเข้าใจบริบท

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

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

[ashbyash]

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

[laeyoung]

ขอบคุณสำหรับคำแปลดีๆ ครับ!

[ashbyash]

ขอบคุณที่ชื่นชอบบทความครับ!