ผู้ใช้ไม่สนใจ — แต่คุณต้องใส่ใจ

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

---

วลีซ้ำซากที่ได้ยินบ่อย และข้อจำกัดของมัน

• ในอุตสาหกรรมซอฟต์แวร์ มักได้ยินคำพูดทำนองว่า
  • “ลูกค้าไม่สนใจการทดสอบ สนใจแค่ว่าผลิตภัณฑ์ใช้งานได้หรือไม่”
  • “ผู้ใช้ไม่สนใจเทคสแต็ก”
  • “ความงามเชิงวิศวกรรมไม่ได้เท่ากับมูลค่าทางตลาด”
  • “ผู้ใช้ไม่สนใจว่าเขียนโดย AI หรือมนุษย์ หรือใช้เฟรมเวิร์กอะไร สนใจแค่ว่าผลิตภัณฑ์ใช้งานได้”
    คำพูดเหล่านี้ถูกพูดซ้ำอยู่เรื่อย ๆ
• ทั้งหมดนี้เป็นเพียงรูปแบบต่าง ๆ ของธีมเดียวกันคือ “ลูกค้าไม่สนใจสิ่งนั้น”
• ราวกับเป็นท่าทีของ นักปฏิบัตินิยมผู้ช่ำชอง ที่กำลังบอกความจริงอันเย็นชาของโลกให้พวกอุดมคติหรือคนมองสั้นได้รับรู้
• แต่จริง ๆ แล้ว ทั้งหมดนี้คือ คำพูดเหลวไหล (horseshit) และเมื่อนำตรรกะเดียวกันไปใช้กับสาขาอื่น ก็จะเห็น ช่องโหว่ ทันที
  • คนใช้ถนนไม่สนใจว่าสะพานผ่าน การตรวจครั้งสุดท้าย หรือไม่ สนใจแค่ว่ามันรับน้ำหนักรถได้หรือเปล่า
  • ผู้โดยสารไม่สนใจว่านักบิน เมาหรือไม่ สนใจแค่ว่าเครื่องจะถึงตรงเวลาหรือเปล่า
  • พนักงานออฟฟิศไม่สนใจว่า ฐานรากของตึกสูงมั่นคงหรือไม่ สนใจแค่การหาเงิน
• อุปมาเหล่านี้อาจดูถูกต้องในระดับผิวเผิน แต่ละเลย ผลกระทบต่อเนื่องในปลายทาง (downstream effects) ที่ชัดเจน

ผลกระทบต่อเนื่องที่ถูกมองข้าม

• เป็นความจริงที่ลูกค้าไม่ได้สนใจคุณสมบัติภายในของโค้ดคอมพิวเตอร์โดยตรง แต่
  คุณภาพของโค้ดส่งผลต่อ ประสิทธิภาพ การมีหรือไม่มีบั๊ก เวลาที่ใช้แก้บั๊ก และเวลาที่ใช้เพิ่มฟีเจอร์
• ยิ่งโค้ดแย่ ก็ยิ่งแก้ปัญหาเหล่านี้ได้ยากและช้าลง
• บริษัทอย่าง AirBnB, OpenAI และ Meta อาจผลักปัญหาเหล่านี้ต่อไปได้ด้วยอำนาจเหนือตลาดมหาศาล เงินทุน VC จำนวนมาก และความชอบธรรมที่น่าสงสัย
  แต่ถ้าไม่ใช่บริษัทแบบนั้น ก็ยากที่จะ กลบปัญหาด้วยวิธีเดียวกัน

ความคงอยู่ของ ‘Folk Wisdom’ และความสนใจหลายด้านของซอฟต์แวร์

• ความคงทนอย่างดื้อรั้นของความเชื่อสามัญ (The Persistence of Folk Wisdom)

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

• เราอยู่ในสังคม (We Live in a Society)

  • งานซอฟต์แวร์ที่จริงจังคือ ส่วนผสมของความสนใจที่แตกต่างกันและมุมมองที่แตกต่างกัน
  • ตั้งแต่การขายด้านเทคนิค (tech sales) ไปจนถึงเทคสแต็ก (tech stack) ตั้งแต่ประสบการณ์ผู้ใช้ (UX) ไปจนถึงตัวระบุเฉพาะ (unique identifiers) มีองค์ประกอบมากมายที่รวมอยู่ในความพยายามด้านซอฟต์แวร์
  • องค์ประกอบทั้งหมดนี้ล้วนมีส่วนต่อ ความสำเร็จหรือความล้มเหลว

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• ประโยคแบบนี้อาจดีหรือแย่ได้ทั้งในแง่วิธีสื่อและวิธีที่คนอ่านตีความ
  ตัวอย่างเช่น คำพูดว่า “ลูกค้าไม่ได้สนใจการทดสอบเลย สนใจแค่ว่าผลิตภัณฑ์ใช้งานได้หรือไม่” อาจอ่านได้ว่าไม่ได้หมายถึง “ปล่อยบั๊กออกไปเถอะ” แต่หมายถึงให้โฟกัสที่ การที่ผลิตภัณฑ์ใช้งานได้จริง มากกว่า อุดมการณ์เรื่องการทดสอบ แบบใดแบบหนึ่ง
  การทดสอบเป็นเพียงหนึ่งในวิธีที่ทำให้โค้ดทำงานได้ ดังนั้นต่อให้ test coverage สูงและเทสต์ผ่านหมด แต่ตัวผลิตภัณฑ์ยังใช้ไม่ได้ก็ถือว่าล้มเหลว และถ้าทำให้ผลิตภัณฑ์ทำงานได้ดีด้วยวิธีอื่นนอกจากการทดสอบก็ไม่เป็นไร หรือแม้ไม่ยึดตามหลักคำสอนเชิงรูปแบบแต่จับบั๊กได้ดีก็ยังโอเค
  อีกทั้งจากมุมมองของผู้ใช้และธุรกิจ “การที่ไม่มีผลิตภัณฑ์/ฟีเจอร์นั้นอยู่เลย” ก็อาจนับเป็นบั๊กได้ ดังนั้นการแก้บั๊กเดิมกับการปล่อยฟีเจอร์ใหม่จึงไม่ได้แยกจากกันอย่างสวยงามเสมอไป
  แต่ในทางปฏิบัติก็เคยได้ยินเหมือนกันว่าประโยคแบบนี้ถูกใช้ในความหมายว่า “หาช่องทางลัดแล้วปล่อยของห่วยออกไป”

  • ในประเด็นที่ว่า “จากมุมมองของผู้ใช้และธุรกิจ การที่ไม่มีผลิตภัณฑ์/ฟีเจอร์อยู่เลยก็เป็นบั๊กได้” ในฐานะคนเขียน ผมยอมรับว่ามีส่วนที่ไม่ได้พูดให้ชัด
    ผมปฏิเสธอย่างสิ้นเชิงกับความคิดที่ว่า การเขียนโปรแกรมห่วยๆ จะยัง “ใช้ได้จริง” เมื่อมองในช่วงเวลาระดับหลายเดือน
    การสร้างฟีเจอร์ใหม่บนโค้ดเบสที่ออกแบบแย่และมีการทดสอบไม่พอนั้นทั้งช้าและแพง
  • ยังมีวิศวกรจำนวนมากที่เชื่อว่า “ยิ่งมี unit test มากยิ่งดี” หรือใช้เวลาหลายวันไปกับการ optimize โค้ดที่ไม่ได้เป็นคอขวดเลย ซึ่งในกรณีแบบนั้นการตีความข้างต้นก็ค่อนข้างเหมาะสม
    นักพัฒนาควรตระหนักว่าตนกำลัง ใช้เวลากับจุดที่สร้างคุณค่าหรือไม่ และถ้าฝ่ายบริหารเข้าใจด้วยว่าทำไมถึงทำงานแบบนั้นก็จะยิ่งดี
    เมื่อการไม่เข้าใจผสมกับโครงสร้างแรงจูงใจที่ผิด สุดท้ายก็จะลงเอยที่ “หาทางลัดแล้วปล่อยของห่วยออกไป”

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

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

• การใส่ใจภายในเป็นเรื่องสำคัญ และจริงๆ แล้วก็เป็นประโยชน์ต่อผู้ใช้ด้วย

• ผมชอบมุมมองนี้
  ผมไม่ได้อยากไปสุดโต่งอีกด้านอย่าง over-engineering แต่ก็อยากให้เราออกจากแนวคิดแบบ “move fast and break things” ได้แล้ว
  จากประสบการณ์ของผม ในโลกเว็บดีเวลอปเมนต์มันแทบเหมือนโรคระบาด
  ผมหวังว่าการไหลบ่าของซอฟต์แวร์คุณภาพต่ำที่ LLM ทำให้สร้างได้ง่ายขึ้น จะกลับกลายเป็นแรงผลักให้ผู้ใช้ตอบแทนซอฟต์แวร์ที่เชื่อถือได้
  ผมกำลังกลายเป็นนักพัฒนาแบบ grug brain มากขึ้นเรื่อยๆ เลยไม่แน่ใจว่านี่เป็นความรู้สึกที่แพร่หลายไหม แต่ผมเริ่มเบื่อกับคำว่า “มาเพิ่มอีกหนึ่งฟีเจอร์กันเถอะ” แล้ว
  เรามักทำพลาดด้วยการวัดต้นทุนของซอฟต์แวร์จากแค่ วันเปิดตัว และแทบไม่รวมต้นทุนการบำรุงรักษาตลอดอายุของมันเข้าไปเลย
  คนชอบพูดว่า “ไม่ยากหรอก ใช้เวลาไม่ถึงสัปดาห์!” แต่ไม่ได้พูดถึงเวลาที่จะต้องใช้ทุกปีอีก 2–4 สัปดาห์ไปกับการบำรุงรักษา แก้ไข ขยาย อัปเดต อินทิเกรต และทำเอกสาร

• ผมมักพูดอะไรในทำนองนี้อยู่บ่อยๆ
  “ผู้ใช้ปลายทางไม่ได้สนใจว่าซอฟต์แวร์มี test coverage 100% หรือเขียนด้วยแอสเซมบลีที่ไม่มีเอกสารพร้อมป้ายกำกับอย่าง lbl0 ครบ 100% หรือไม่ พวกเขาสนใจความถูกต้อง ประสิทธิภาพ และประสบการณ์ใช้งาน”
  แต่ software engineering นี่แหละที่ช่วยให้เราไปถึงเป้าหมายนั้นได้ง่ายขึ้น และรักษาคุณภาพให้อยู่ในระดับที่ดีได้
  ปัญหาคือเส้นทางนี้เองก็อาจกลายเป็น cargo cult และ over-engineering ได้ ซึ่งผมเองก็มีความผิดนี้แน่นอน
  ถึงอย่างนั้น สุดท้ายแล้วเราก็ต้องส่งมอบคุณค่าที่แท้จริงให้ผู้ใช้

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