อย่าตอบคำถามแรก

 (lalitm.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในเครื่องมือ ดีบักประสิทธิภาพ คำขอที่ดูแปลกควรถามหาบริบทก่อนแทนที่จะรีบตอบทันที เพราะจะช่วยให้เห็นทั้งปัญหาที่แท้จริงของผู้ใช้และช่องโหว่ของเครื่องมือ
  • แนวทางนี้ไปไกลกว่าการรับมือกับปัญหาแบบ XY problem ธรรมดา โดยใช้ความสับสนที่ทำให้เกิดคำถามผิดเป็นจุดเริ่มต้นเพื่อเพิ่มความเข้าใจทั้งฝั่งผู้ใช้และตัวผลิตภัณฑ์
  • ใน Perfetto แม้วิธีใช้ trace สำหรับคำนวณทุกเมตริกจะทำได้ แต่ก็ ไม่มีประสิทธิภาพ และระบบเก็บเมตริกเฉพาะทางอาจเหมาะสมกว่า
  • เมื่อคำตอบที่ดูเหมือนใช่กับสิ่งที่ต้องการจริงไม่ตรงกัน เช่น คำขอให้แยก trace ฟีเจอร์ที่มีอยู่แล้วอย่าง periodic trace snapshots อาจเป็นทางเลือกที่ดีกว่า
  • การเปลี่ยนผลิตภัณฑ์ควรตัดสินใจหลังจากเห็นความต้องการที่เกิดซ้ำชัดเจนเพียงพอแล้ว และการเพิ่มฟีเจอร์อย่างรีบร้อนอาจนำไปสู่ หนี้ทางเทคนิค ก้อนใหญ่

ทำไมจึงไม่ตอบคำถามแรกทันที

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

วิธีวิเคราะห์คำขอ

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

กรณีพลาดปรัชญาของเครื่องมือ

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

กรณีที่เส้นทางที่ถูกต้องถูกซ่อนไว้

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

กรณีที่ผลิตภัณฑ์ควรถูกเปลี่ยน

  • บางคำตอบอาจเผยให้เห็นความต้องการใหม่ที่ควรนำไปสู่การเปลี่ยนแปลงใหญ่ของผลิตภัณฑ์
    • กรณีแบบนี้จัดการยาก
    • ต่อให้คำขอนั้นใหม่จริง ผู้ขอก็อาจยังอธิบายสิ่งที่ตัวเองต้องการจริง ๆ ได้ไม่ชัด
  • ในซอฟต์แวร์ระดับฐานราก ต้นทุนของการตัดสินใจผิดนั้นสูงมาก
    • เพราะอย่างนั้นจึงมักเลือกที่จะยังไม่สร้างอะไร จนกว่าความเจ็บปวดจากการขาดมันจะชัดจริง
    • เมื่อหลายทีมเริ่มพูดถึงความต้องการแบบเดียวกัน จุดแกนกลางที่ควรสร้างจริงก็มักจะเริ่มปรากฏชัด
    • การหาแกนกลางนี้จากคำขอเพียงครั้งเดียวทำได้ยากมาก ดังนั้นการรอจึงทรงพลัง
  • การปรับแต่ง UI แบบเฉพาะกิจ ของ Perfetto เป็นตัวอย่างของการตัดสินใจที่ผิด
    • ผู้คนอยากแฮ็ก UI ให้เข้ากับ workflow ของตัวเอง และบ่นอยู่เรื่อย ๆ ว่าทำได้ยาก
    • ทันทีที่เปิดทางให้ทำเช่นนั้น ก็เกิดหนี้ทางเทคนิคมหาศาล
    • ทุกฟีเจอร์ใหม่ต้องโต้ตอบกับฟีเจอร์เดิมทั้งหมด และโครงสร้างโดยรวมก็ขยายต่อไม่ได้อย่างรวดเร็ว
    • ใช้เวลาประมาณ 1 ปีในการออกแบบ plugin API ที่เหมาะสมเพื่อหลุดออกจากปัญหานี้
  • ความต้องการที่แท้จริงคือ “วิธีทำให้ UI ปรับให้เหมาะกับทีมหรือ use case ได้ โดยไม่กระทบผู้ใช้ทุกคน”
    • ความต้องการนี้ไม่ได้ถูกอธิบายไว้อย่างชัดเจนตั้งแต่ต้น
    • การจับสัญญาณนี้ให้ได้ตั้งแต่เนิ่น ๆ ท่ามกลางกระแสคำขอเป็นหน้าที่ของฝ่ายสร้างผลิตภัณฑ์
  • ฟีเจอร์ที่ทำให้ Perfetto trace สามารถ “merge” กันได้ เป็นตัวอย่างของการจัดการที่ดี
    • มีคนขอกันมาเรื่อย ๆ แต่ไม่ได้รีบทำทันที
    • ทีมงานเลือกแนะนำวิธีอ้อมและเฝ้าดูต่อไป
    • พวกเขารู้ว่าถ้าจะทำให้ถูกต้อง ฟีเจอร์นี้ต้องใช้แรงมากและทำพลาดได้ง่าย
    • หลังจากเข้าใจพื้นที่ของปัญหามากพอแล้ว จึงค่อยทำออกมาในปีที่แล้วด้วยวิธีที่ดูแลรักษาได้

บทเรียนสำคัญ

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Lobste.rs

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

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

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

  • ระหว่างการปรับระบบให้ทันสมัยด้วยหลายเหตุผล เราได้เพิ่มหน้า 404 ให้กับ ingress router แล้วเกิดปัญหาขึ้น นักพัฒนาคนหนึ่งขอให้เอาพฤติกรรม 404 แบบเก่ากลับมา เพราะหน้าเดิมมีแถบนำทางและเมนู
    พอซักต่อก็พบว่าในการตั้งค่าของลูกค้าบางราย ตอนล็อกอินจะได้ 404 เสมอ และลูกค้าก็ใช้หน้า 404 แบบเก่าเพื่อไปยังที่ที่ควรไปจริง ๆ
    ฉันถึงกับอยากประดิษฐ์คำว่า lolcry ไว้ใช้กับช่วงเวลาแบบนี้ 🤣😭

    • > GET /hyrums-law HTTP/1.1  
> Host: ingress.customer.doctor_eval.work  
>  
< HTTP/1.1 404 Not Found  
< Content-Type: text/plain  
<  
< เมื่อมีผู้ใช้ API มากพอ,  
< สิ่งที่สัญญาไว้ในสัญญาไม่สำคัญอีกต่อไป:  
< พฤติกรรมทุกอย่างของระบบที่สังเกตได้  
< จะมีใครสักคนพึ่งพามัน.  
<

  • @lalitm ปัญหานี้เก่ากว่าอินเทอร์เน็ตเสียอีก และมีชื่อเรียกอยู่แล้ว นั่นคือ การวิเคราะห์ความต้องการ
    Ed Yourdon และคนอื่น ๆ แยก กระบวนการ ซึ่งเป็นผลลัพธ์ที่ผู้ใช้อยากได้ ออกจากขั้นตอนปฏิบัติซึ่งเป็นวิธีไปให้ถึงผลลัพธ์นั้น ตัวอย่างเช่น การแจ้งลูกค้าว่าส่งคำสั่งซื้อแล้วคือกระบวนการ ส่วนการส่งข้อมูลนั้นทางอีเมลคือขั้นตอนปฏิบัติ
    ผู้ใช้ระบบมักมีแนวโน้มจะนึกถึงวิธีแก้ในฐานะฟังก์ชันของระบบเอง โปรแกรมเมอร์ก็ไม่ได้เป็นข้อยกเว้น จึงมีคำถามแนว “แก้ Y ใน X” อยู่มาก หน้าที่ของนักวิเคราะห์คือดึงความต้องการออกมาจากรูปแบบการติดตั้งใช้งานเฉพาะ ส่วนในฐานะวิศวกร ค่อยนำวิธีแก้ไปทำต่อจากนั้น
    ไม่นานมานี้ฉันร่วมวงคุยเรื่องทำให้การล็อกเร็วขึ้น เพราะ syslog(3) ค้างคิวแล้วอีเวนต์หายไปจากล็อก แต่ปัญหาที่แท้จริงไม่ใช่การล็อกให้เร็วขึ้น ผู้ใช้ไม่ได้อยากได้การล็อกที่เร็วขึ้น เขาอยากแก้ปัญหา การให้ข้อมูลที่จำเป็นคือกระบวนการ ส่วนการเขียนทุกอย่างลงล็อกเป็นเพียงหนึ่งในวิธีทำเท่านั้น
    Yourdon เป็นหนึ่งในคนที่สนับสนุนเครื่องมือ CASE ถ้าฝ่ายบริหารวัดคุณภาพกับประสิทธิภาพการผลิตได้จริง มันอาจสำเร็จก็ได้ แต่เรื่องบ่นนั้นค่อยไว้วันหลัง

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

    • เห็นด้วย ยิ่งกว่านั้น บางครั้งการใช้เวลาไปทำความเข้าใจว่าความพิเศษเฉพาะขององค์กรแบบไหนที่ทำให้เกิดคำถาม “ผิด” เหล่านั้น ก็ไม่ได้เป็นประโยชน์กับใครเลย

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

    • ฉันชอบถ้อยคำนี้มาก เส้นทางที่ทำให้สารสับสนมีได้มากมายนับไม่ถ้วน และการช่วยกันหาต้นตอของปัญหาก็ต้องอาศัยหลายแนวทาง และแน่นอนว่า ฝ่ายที่สับสนก็ไม่ได้เป็นอีกฝ่ายเสมอไป