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

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

---

คลิเช่ที่ถูกพูดซ้ำและข้อจำกัดของมัน

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

ความคงอยู่ของ ‘ภูมิปัญญาแบบชาวบ้าน’ และความสนใจหลายด้านของซอฟต์แวร์

• ความคงอยู่ของภูมิปัญญาแบบชาวบ้าน

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

• เราอยู่ในสังคม

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

[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 ไม่เช่นนั้นก็จะถูกกินเรียบ
  ในสายงานของเราก็มีจุดที่เหมาะที่สุดอยู่ที่ไหนสักแห่งเช่นกัน และคำถามคือเรามีเครื่องมือ งบประมาณ และคนที่เหมาะสมพอจะไปถึงหรือไม่ และมีผู้ใช้มากพอจะทำให้เรารู้ได้ไหมว่าเราไปถึงจุดนั้นจริงหรือยัง