Part 6 · กระบวนการ Oracle V4 ตั้งแต่โจทย์จนตัดสินใจ

บทที่ 49: เริ่มจากผลลัพธ์ ไม่ใช่เริ่มจากชื่อเครื่องมือ

บทสั้นสำหรับมือใหม่ใน Part 6: กระบวนการ Oracle V4 ตั้งแต่โจทย์จนตัดสินใจ

แฟ้มงานเดินเป็นเส้นตรงผ่านโต๊ะร่าง โต๊ะตรวจ จุดที่ต้องให้คนอนุมัติ และกล่องงานสำเร็จ
งานที่ดีมีขั้นทำ ตรวจ รอคนอนุมัติ และส่งมอบให้เห็นชัดเจน
เห็นภาพก่อนอ่าน

สามเรื่องที่ควรจำ

  1. ถามก่อนว่า “เมื่อจบงาน ผู้ใช้จะทำอะไรได้”

    ประเด็นจากหัวข้อ “สามเรื่องที่ควรจำ”

  2. แยกผลลัพธ์ทางธุรกิจออกจากไฟล์ที่ส่งมอบ

    ประเด็นจากหัวข้อ “สามเรื่องที่ควรจำ”

  3. ระบุสิ่งไม่รวมและผู้อนุมัติตั้งแต่ก่อนเริ่ม

    ประเด็นจากหัวข้อ “สามเรื่องที่ควรจำ”

สรุปแก่นของบทที่ 49 เป็นจุดสังเกตที่กลับมาทบทวนได้รวดเร็ว

ผลลัพธ์ของบทนี้

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

สถานการณ์ใกล้ตัว

เจ้าของร้านพูดว่า “อยากใช้ AI ช่วยยอดขาย” ทีมหนึ่งเปิดเครื่องมือทำภาพ อีกทีมทำข้อความโฆษณา อีกคนทำตารางลูกค้า ผ่านไปสองวันมีไฟล์หลายสิบไฟล์ แต่เจ้าของยังตอบไม่ได้ว่าควรเปลี่ยนอะไรในสัปดาห์หน้า

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

ลองหยุดก่อนหนึ่งจังหวะ ถ้าเราปิดชื่อเครื่องมือทั้งหมดออกจากโต๊ะ เหลือเพียงเจ้าของธุรกิจกับปัญหา เขาอยากถืออะไรอยู่ในมือเมื่อจบงาน

ศัพท์ใหม่ในบทนี้

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

ภาพเปรียบเทียบและขอบเขตของภาพ

การสั่งงานเหมือนสั่งอาหารจัดเลี้ยง ถ้าบอกเพียง “ทำอาหารให้อร่อย” ครัวต้องเดาจำนวนคน งบ อาหารแพ้ และเวลาเสิร์ฟ แต่ถ้าบอกว่า “อาหารกลางวันสำหรับ 20 คน มีมังสวิรัติ 4 คน ส่งก่อนเที่ยง และเจ้าภาพชิมเมนูหลักก่อนยืนยัน” ครัวจึงวางงานได้

ภาพครัวช่วยให้เห็นว่าเป้าหมายและข้อจำกัดต้องมาก่อนการลงมือ แต่มีขอบเขต: งานความรู้ไม่ใช่สูตรตายตัว ข้อมูลอาจขัดกัน และ AI ไม่ได้มีประสบการณ์รับผิดชอบผลลัพธ์เหมือนพ่อครัวมนุษย์ จึงยังต้องมีหลักฐานและคนอนุมัติ

แก่นของเรื่องแบบเป็นชั้น

ชั้นแรกคือแยก ผลลัพธ์ ออกจาก ผลงาน ผลลัพธ์อาจเป็น “ผู้จัดการเลือกสินค้าที่ควรเติมได้ภายใน 15 นาที” ส่วนผลงานคือ “รายงานสินค้าคงเหลือหนึ่งหน้า พร้อมรายการผิดปกติ” รายงานเป็นของที่ส่งมอบ การตัดสินใจเร็วขึ้นคือผลที่อยากให้เกิด

ชั้นที่สองคือเขียนบัตรผลลัพธ์ให้ครบหกช่อง:

  1. ใครใช้: ระบุบทบาท ไม่จำเป็นต้องใส่ชื่อจริง
  2. ต้องตัดสินใจหรือทำอะไรต่อ: เขียนเป็นการกระทำที่สังเกตได้
  3. ต้องได้รับผลงานอะไร: ระบุชนิดไฟล์ ความยาว หรือรูปแบบ
  4. อะไรคือหลักฐานว่าเสร็จ: เช่น ครบ 10 รายการ มีแหล่งข้อมูล และผ่านรายการตรวจ 7 ข้อ
  5. อะไรไม่รวมในรอบนี้: เช่น ไม่เชื่อมระบบขาย ไม่ส่งหาลูกค้า และไม่เผยแพร่
  6. ใครอนุมัติขั้นสุดท้าย: ระบุเจ้าของงานหรือผู้เชี่ยวชาญที่รับผิดชอบ

ชั้นที่สามคือใช้บัตรนี้เป็นเข็มทิศของทั้งระบบ เมื่อคำขอผ่าน Earth AI ไปหา Jan และ House ทุกฝ่ายควรย้อนกลับมาตรวจได้ว่า งานที่กำลังทำยังพาไปสู่ผลลัพธ์เดิมหรือไม่ หากต้องเปลี่ยนผลลัพธ์ ต้องบันทึกเป็นการเปลี่ยนขอบเขต ไม่ใช่ค่อย ๆ เพิ่มงานเงียบ ๆ

หยุดก่อน

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

กรณีศึกษาหรือตัวอย่างจำลองที่ปลอดภัย

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

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

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

กิจกรรมทดลองอย่างปลอดภัย

เลือกงานสมมติหนึ่งอย่าง เช่น “ทำคู่มือปิดร้าน” หรือ “สรุปเสียงลูกค้า” แล้วเติมบัตรนี้:

ผู้ใช้ปลายทางคือ ______
เมื่อได้รับงานแล้ว เขาจะ ______
ผลงานที่ต้องได้รับคือ ______
เราจะรู้ว่างานเสร็จเมื่อ ______
รอบนี้ไม่รวม ______
ผู้อนุมัติคือ ______

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

ระวังความเข้าใจผิด

  • “เริ่มจากผลลัพธ์” ไม่ได้แปลว่ารับรองผลธุรกิจล่วงหน้า เรากำหนดสิ่งที่ต้องการทดสอบ ไม่ได้สัญญาว่าจะเกิดแน่นอน
  • ผลงานที่สวยไม่ใช่หลักฐานว่าเนื้อหาถูกหรือเหมาะจะเผยแพร่
  • บัตรผลลัพธ์ไม่ใช่ใบอนุญาตให้ระบบเลือก House หรือทำงานเสี่ยงเอง มันเป็นข้อมูลให้ Jan และมนุษย์ใช้จัดงาน

สามเรื่องที่ควรจำ

  1. ถามก่อนว่า “เมื่อจบงาน ผู้ใช้จะทำอะไรได้”
  2. แยกผลลัพธ์ทางธุรกิจออกจากไฟล์ที่ส่งมอบ
  3. ระบุสิ่งไม่รวมและผู้อนุมัติตั้งแต่ก่อนเริ่ม

คำถามชวนคิด

งานใดในธุรกิจของคุณมีไฟล์ออกมามาก แต่ยังไม่มีใครรู้ว่าต้องตัดสินใจอะไรต่อ

สะพานไปบทถัดไป

เมื่อรู้แล้วว่าอยากได้อะไร เราจะย่อความต้องการนั้นเป็นรายละเอียดงานห้าบรรทัดที่ส่งต่อได้โดยไม่ทำให้คนถัดไปต้องเดา

ค้นทั้งเล่ม

อยากรู้เรื่องอะไร

พิมพ์อย่างน้อย 2 ตัวอักษร