เครื่องมือหรือเทคนิคใดที่ใช้ถ่ายทอด mental model?

 (lobste.rs)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นคำถามเกี่ยวกับเครื่องมือและเทคนิคที่มีประสิทธิภาพในการถ่ายทอด mental model เพื่อทำความเข้าใจระบบหรือผลิตภัณฑ์ให้ผู้อื่น และช่วยกันพัฒนามันต่อไป
  • วิธีพัฒนา mental model ที่ถูกยกขึ้นมาคือประสบการณ์ในการ สร้างและบำรุงรักษาระบบด้วยตนเอง
  • วิธีถ่ายทอดนั้นใกล้เคียงกับ การอธิบายแบบไม่เป็นทางการ เช่น ขีดเขียนบนกระดาษเช็ดปาก อธิบายด้วยท่าทางข้าง ๆ กัน หรือช่วยกันคิดและอธิบายออกมาเป็นคำพูด
  • เอกสารที่รวบรวมรายการฟีเจอร์หรือขอบเขตผิวเผินไว้อย่างครบถ้วนอาจครอบคลุมได้มาก แต่ก็อาจยังไม่เพียงพอสำหรับการสร้างหรือถ่ายทอด mental model ของหัวข้อนั้น
  • ประสบการณ์ในการได้ใช้งานเครื่องมือหรือผลิตภัณฑ์ที่ออกแบบมาอย่างดีด้วยตนเอง อาจช่วยทั้ง กระบวนการพัฒนาและถ่ายทอด mental model ไปพร้อมกัน

จุดเน้นของคำถาม

  • ประเด็นหลักคือ เครื่องมือหรือเทคนิค ใดมีประสิทธิภาพในการถ่ายทอดและพัฒนา mental model
  • คำถามนี้ครอบคลุมสองทิศทางไปพร้อมกัน
    • วิธี พัฒนา mental model
    • วิธี ถ่ายทอด mental model ให้ผู้อื่น

ตัวอย่างและประเด็นปัญหา

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

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

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

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

  • Olog เป็นรูปแบบเชิงทางการที่ดีสำหรับถ่ายทอดออนโทโลยี
    ถ้าเป็นโปรเซสที่รันระยะยาวและมีสถานะภายในจำนวนมาก state diagram และ state chart ก็มีประโยชน์ต่อการทำเอกสารระบบ
    โดยทั่วไปผู้ใช้ระบบมักรับรู้ โครงสร้างของระบบ จริงไม่ได้ เหตุผลหนึ่งคือ Nakatomi space จะมองเห็นได้เฉพาะกับผู้ใช้ที่ ใช้ระบบผิดวัตถุประสงค์ เท่านั้น และยังมีพื้นที่สถานะแยกต่างหากสำหรับพฤติกรรมที่ไม่ได้ตั้งใจอย่าง weird machines
    อีกเหตุผลหนึ่งคือ ตามมุมมองอย่าง the purpose of a system is what it does ผู้ใช้อาจเห็นเพียงสิ่งที่ระบบทำให้ตน แล้วสร้างเหตุผลการมีอยู่ส่วนตัวขึ้นมาเองได้ แต่ไม่อาจสังเกตเห็นวัตถุประสงค์ทั้งหมดที่ผู้ออกแบบและผู้ดูแลรักษาตั้งใจไว้

  • เขียนหนังสือ แล้วจ้างบรรณาธิการก็พอ

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

    • เห็นด้วย สาขาที่ว่าด้วยการถ่ายทอด mental model ของตนให้ผู้อื่นอย่างมีประสิทธิภาพ หรือช่วยให้ผู้อื่นสร้างโมเดลของตนเองขึ้นมา เราเรียกว่า “การศึกษา”
      ในเรื่องนี้ The Programmer's Brain ของ Felienne Hermans น่าสนใจ สิ่งที่ประทับใจคือ วิธีแบบ “ดูนะ ฉันจะแก้โจทย์ตัวอย่างหลาย ๆ ข้อให้ดู” ที่ใช้สอนคณิตศาสตร์ ฯลฯ ให้เด็กเล็ก ก็ค่อนข้างใช้ได้ดีกับการสอนเขียนโปรแกรมด้วย
      ถ้าเป็นการ onboarding ในที่ทำงาน ก็น่าจะอยู่ในรูปแบบอย่าง “ดูนะว่าฉันสืบหาบั๊กนี้อย่างไร” หรือ “ดูนะว่าฉันกลับมาทำความเข้าใจ subsystem นี้ที่ไม่ได้แตะมานานอย่างไร”

  • ในวิศวกรรมซอฟต์แวร์ การมอง mental model โดยแบ่งเป็น user story กับ การนำไปใช้เชิงเทคนิค จะช่วยได้
    โดยทั่วไป user story คือความต้องการลำดับแรก หรือคุณค่าที่ต้องการบรรลุ ส่วนการนำไปใช้เชิงเทคนิคคือองค์ประกอบลำดับรองที่จำเป็นเพื่อไปให้ถึงเป้าหมายนั้น
    user story อธิบายคุณค่าที่ส่งมอบให้ลูกค้า ส่วนการนำไปใช้เชิงเทคนิคอธิบายว่าข้อจำกัดของระบบที่สร้างขึ้นจำกัด user story อย่างไร
    บางครั้งทั้งสองอย่างซ้อนทับกันจน user story ถูกจำกัดโดยการนำไปใช้เชิงเทคนิค หรือในทางกลับกัน มีการเลือกการนำไปใช้เชิงเทคนิคเพื่อให้บรรลุ user story แต่พฤติกรรมของระบบจำนวนมากสามารถวางกรอบให้อยู่ในอย่างใดอย่างหนึ่งได้
    จากนั้นก็เลือกเครื่องมือที่เหมาะที่สุด UML เหมาะสำหรับวาดแผนที่ของ entity, flowchart เหมาะสำหรับอธิบาย flow, state diagram เหมาะสำหรับอธิบายสถานะที่อนุญาต/ไม่อนุญาตและ transition ส่วนตารางตัวแปรและสถานะเหมาะสำหรับไล่ค่าที่เป็นไปได้ทั้งหมด
    วิธีที่ดีที่สุดในการเรียนรู้การวาดระบบคือให้คนสามคนที่ต่างกันลองวาดภาพตามที่แต่ละคนคิด ความคิดเดียวกันก็มีรูปแบบการนำเสนอที่หลากหลายอย่างน่าทึ่ง และส่วนใหญ่ก็ถูกต้องพอ ๆ กัน แต่เผยให้เห็นคนละแง่มุมของหัวข้อ คล้ายกับศิลปะ

  • ส่วนใหญ่ใช้ การทำแผนภาพ ที่เป็นทางการมากขึ้น แต่เวลาขีดเขียนแบบเรียลไทม์ระหว่างแชร์หน้าจอ บางครั้งก็เปิด jspaint และถ้าเป็นเนื้อหาที่คนอื่นน่าจะกลับมาดูภายหลัง ก็ใช้พวก Figjam
    เหตุผลที่การทำแผนภาพและการชี้ใช้ได้ผลดี คือมันเป็น เครื่องมือชี้นำความสนใจ ที่เก่าแก่ที่สุดและยังมีประโยชน์อยู่ เราชี้และร้องไห้ตั้งแต่ก่อนพูดได้ และในเรื่องตำแหน่งกับการนำทาง การชี้ให้ความฉับไวมากกว่าภาษามาก ตลาดเลเซอร์พอยน์เตอร์จึงยังคงอยู่
    The Geometry of Meaning: Semantics of Conceptual Spaces ของ Peter Gårdenfors พูดถึงหัวข้อนี้ค่อนข้างละเอียด Barbara Tversky ก็มีงานวิจัยมากมายด้านการทำแผนภาพและการจัดโครงสร้างพื้นที่ทางปัญญา ส่วน “What Constitutes an Effective Representation?” ของ Peter Cheng เสนอเกณฑ์ของการแทนความหมายที่มีประสิทธิภาพไว้ค่อนข้างเป็นเชิงปริมาณ

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

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

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

  • การเขียนคือคำตอบ

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