ความมั่นใจที่สูญหายไป (Lost confidence)

• เฟรมเวิร์กการจัดลำดับความสำคัญแบบ อิงความมั่นใจ อย่าง RICE ส่วนใหญ่เป็นเพียงสัญญาณรบกวน และเราจำเป็นต้องมีวิธีตัดสินใจโดยไม่แสร้งทำเป็นรู้อนาคตที่ยังไม่อาจรู้ได้
• คะแนนความมั่นใจมักถูกให้ สูงกับโปรเจ็กต์เล็ก (small) และต่ำกับโปรเจ็กต์ใหญ่ (large) จึงบิดเบือนลำดับความสำคัญด้วยการผลักโปรเจ็กต์มูลค่าสูงออกไปอย่างเป็นระบบ
• คะแนนความมั่นใจนั้น เชื่อถือไม่ได้ เพราะนิยามก็คลุมเครือ ข้อมูลสำหรับตรวจสอบก็มีไม่พอ อีกทั้งโปรเจ็กต์ก็มักล่าช้าเสมอและมีอิมแพ็กต์ต่ำกว่าที่คาด
• ทางออกคือไม่ถามในกรอบของความน่าจะเป็น (probability) แต่ถามในพื้นที่ของ ความไม่แน่นอน (uncertainty) ว่า "ไม่ว่าการกระจายความน่าจะเป็นจะเป็นแบบใด การกระทำที่ฉลาดคืออะไร"
• แทนที่จะใช้ความมั่นใจ สิ่งสำคัญคือการจัดลำดับความสำคัญด้วยแนวทางอย่าง สิ่งที่เป็นจริงเสมอ, อิมแพ็กต์ต่อลูกค้า, การรักษาทางเลือก, การเดิมพันแบบอสมมาตร

---

เกมแห่งความมั่นใจ (Confidence games)

• เฟรมเวิร์กการจัดลำดับความสำคัญจำนวนมากรวม ความมั่นใจว่าจะสร้างอิมแพ็กต์ตามที่คาดไว้ได้ด้วยแรงที่ประเมินไว้ เข้าไปในคะแนนด้วย
  • ถ้ามีสองโปรเจ็กต์ที่มีมูลค่าเท่ากันและใช้แรงเท่ากัน การเลือกตัวที่มั่นใจว่าจะทำสำเร็จได้มากกว่าย่อมสมเหตุสมผล
  • แต่การใช้งานจริงไม่ใช่แบบ "1) ให้คะแนน → 2) ลงมือทำตัวที่ชนะชัดเจน → 3) ถ้าเสมอกันค่อยเลือกตัวที่มั่นใจมากกว่า"
• RICE ใส่ความมั่นใจเข้าไปคูณตรง ๆ ในสูตรคำนวณคะแนนตั้งแต่ขั้นแรก
  • สูตร RICE: Score = (Reach × Impact × Confidence) / Effort
  • สูตร RPS: Score = Reach × Potential × Solution Confidence
• วิธีนี้ทำให้สองสถานการณ์ที่ต่างกันถูกมองว่าเทียบเท่ากัน จนเกิด ความเท่าเทียมลวง
  • ฟีเจอร์แบบค่อยเป็นค่อยไปที่เล็ก แต่ทำได้แน่นอน
  • ฟีเจอร์ขนาดใหญ่ที่มีอิมแพ็กต์สูง แต่มีความเสี่ยงตามมา
• โดยทั่วไปโปรเจ็กต์เล็กมักได้คะแนนความมั่นใจสูง ส่วนโปรเจ็กต์ใหญ่มักได้ต่ำ ดังนั้นเมื่อเอาความมั่นใจไปคูณ จึง พาเราออกห่างจากทิศทางที่ส่งมอบคุณค่าสูงสุดอย่างเป็นระบบ
  • แรงจูงใจหลักของขบวนการ Agile เองก็คือข้อสังเกตที่ว่า "ความสำเร็จของโปรเจ็กต์ใหญ่ควรมีความมั่นใจต่ำอยู่เสมอ"
• เหตุผลที่ไม่ควรเชื่อคะแนนความมั่นใจ
  • นิยามคลุมเครือ: ไม่ชัดว่า "30%" หมายถึงอะไร ตามหลักแล้วควรบันทึกคะแนนความมั่นใจของทุกโปรเจ็กต์ แล้วเทียบกับผลลัพธ์จริงเพื่อคำนวณความแม่นยำ แต่ในทางปฏิบัติแทบไม่ทำกัน
  • ถ้าปีหนึ่งปล่อยฟีเจอร์ใหญ่เพียงไม่กี่ตัว หลังจบงานก็ ไม่มีข้อมูลมากพอ ให้ตรวจสอบอยู่ดี
  • โปรเจ็กต์แทบจะล่าช้าเสมอ และอิมแพ็กต์ก็มักต่ำและช้ากว่าที่คาด แม้แต่โปรเจ็กต์ 9 เดือน 6 ทีมก็ยังเริ่มต้นเพราะคิดว่า "ค่อนข้างมั่นใจ" อยู่แล้ว
• อ้างถึง Hofstadter's Law: "มันใช้เวลานานกว่าที่คุณคาดเสมอ แม้จะเผื่อ Hofstadter's Law ไว้แล้วก็ตาม"
• ถ้าถาม PM ที่มีประสบการณ์ว่า "มีฟีเจอร์ไหนที่เคยมั่นใจมากว่าจะได้รับการต้อนรับ แต่สุดท้ายไม่ใช่บ้าง" ทุกคนยกตัวอย่างได้หลายกรณี
  • แม้จะมีหลักฐานอย่างบทสนทนากับลูกค้า คำขอชัดเจน หรือคำมั่นว่าจะซื้อ แต่พอสร้างจริง แม้แต่คนที่สัญญาไว้ก็แทบไม่ใช้
  • เทคนิคช่วยปรับการคาดการณ์คือ ให้ลูกค้า อธิบายทีละขั้นว่าพวกเขาจะใช้มันอย่างไรใน workflow จริง พอไล่ทีละขั้น ลูกค้ามักจะรู้เองว่า "แบบนี้ต้องกลับไปเขียนโค้ดใหม่ งั้นคงไม่ทำ"
• แม้แต่ครีเอเตอร์คอนเทนต์ก็เป็นแบบเดียวกัน บทความที่รีบเขียนโดยแทบไม่คาดหวังอาจกลายเป็นงานที่มีคนอ่านและตอบสนองมากที่สุดของปี ขณะที่งานชิ้นเอกที่ใช้เวลาหลายสิบชั่วโมงกลับเงียบหาย
  • ในตาราง 2×2 ของ "มั่นใจ/ไม่มั่นใจ × คนชอบ/คนเมิน" ทั้งสี่ช่องต่างก็มีตัวอย่างเต็มไปหมด

จะใช้อะไรแทนความมั่นใจและความเสี่ยง (What to use in place of confidence and risk)

• คำตอบอยู่ในพื้นที่ของ ความไม่แน่นอน (uncertainty) ไม่ใช่ความน่าจะเป็น
  • ความน่าจะเป็น ตั้งอยู่บนสมมติฐานว่าเรารู้การกระจาย ถ้าโยนเหรียญที่ยุติธรรม 100 ครั้ง เราพอคาดได้อย่างมีน้ำหนักว่าจะออกหัวราว 40–60 ครั้ง
  • แต่แทบทุกอย่างในสตาร์ตอัปไม่เป็นแบบนั้น ความสำเร็จ กลยุทธ์ และฟีเจอร์จำนวนมากไม่เคยมีมาก่อน ซับซ้อนเกินไป หรือไม่มีความแม่นยำของตัวแปรนำเข้า จึง ไม่อาจให้ค่าความน่าจะเป็นที่มีความหมายได้
  • นี่คือแนวคิด "Knightian Uncertainty" ที่มาจากงานของนักเศรษฐศาสตร์ Frank Knight ในปี 1921
  • วิธีแบบ Bayesian ก็ต้องอาศัย prior probability และ conditional probability ในเชิงตัวเลข ซึ่งทั้งสองอย่างเราไม่รู้และนิยามไม่ได้
• คำถามในโลกของความไม่แน่นอนคือ "ไม่ว่าการกระจายความน่าจะเป็นจะเป็นอย่างไร การกระทำใดจึงถือว่าฉลาด"

• สิ่งที่เป็นจริงเสมอ (True always)

  • โฟกัสกับสิ่งที่เป็นจริงเสมอไม่ว่าสถานการณ์ไหน — หลัก long-term constants ของ Bezos
    • ผู้ใช้โดยทั่วไปชอบซอฟต์แวร์ที่เร็วและตอบสนองไว พวกเขาให้ค่ากับการซิงก์เบื้องหลัง การโต้ตอบทันที และการทำงานได้บนทุกอุปกรณ์
    • แม้ในกรณีแย่ที่สุด (คือผู้ใช้ไม่สนใจเรื่องความเร็ว) พวกเขาก็ไม่ได้มองความเร็วในแง่ลบ และในกรณีดีที่สุด ความเร็วกลายเป็น ตัวสร้างความแตกต่างหลัก แบบ Notion, Figma, Miro, Gmail, Google Docs
  • ไม่ใช่ทุกฟีเจอร์จะมีเสน่ห์แบบสากล แทนที่จะพยายามแตกตัวเลขละเอียดเกินไป ให้ระบุ ฟีเจอร์ที่ลูกค้าแทบทุกคนเห็นว่ามีคุณค่าหรืออย่างน้อยก็ชอบ
    • บางครั้งความแน่นอนมาจากการเป็นข้อบังคับ เช่นข้อกำหนดระดับองค์กรอย่าง SOC 2 compliance แม้จะไม่น่าตื่นเต้น แต่ก็มีคุณค่าแน่นอนหากขายให้ลูกค้า enterprise
    • ความแน่นอนลักษณะนี้ช่วย ชดเชยการขาดความแตกต่าง ได้
  • แต่ไอเดียที่นวัตกรรมและแตกต่างที่สุด มักแทบไม่อยู่ในหมวด "มั่นใจได้แบบเด็ดขาด"
    • สิ่งที่แน่นอนมีคุณค่า แต่ยากจะเป็นตัวสร้างความแตกต่างเชิงกลยุทธ์
    • ผลิตภัณฑ์ที่ยอดเยี่ยมต้องมีทั้ง การปรับปรุงที่เชื่อถือได้ และ การกระโดดเชิงนวัตกรรม

• ค้นพบเร็ว ฟื้นตัวเร็ว (Quick discovery, quick recovery)

  • ผู้เขียนสนับสนุนมานานให้สัมภาษณ์ลูกค้าที่เป็นไปได้อย่างเป็นระบบก่อนลงมือสร้างเพื่อทดสอบไอเดีย แต่สิ่งนี้เองก็ยังตกหลุมพรางของ "ความมั่นใจ"
    • ก่อนจะสร้างจริง เราไม่มีทางรู้ได้แน่ชัด
    • อย่างไรก็ตาม ก่อนสร้างเรายัง พิสูจน์ว่าไม่เวิร์ก (invalidate) ได้ ซึ่งช่วยป้องกันการเสียเวลาเป็นเดือนหรือเป็นปี จึงยังเป็นจุดเริ่มต้นที่ถูกต้อง
  • วิธีแก้แบบทั่วไปคือสร้าง SLC (แนวคิดที่อัปเกรดจาก MVP) — เป็นผลิตภัณฑ์ที่เรียบง่ายแต่สมบูรณ์พอจะได้ feedback จริง จากประสบการณ์จริงไม่ใช่การคาดเดา
    • ผลิตภัณฑ์ที่มีอยู่แล้วควรรักษาพอร์ตที่สมดุลระหว่าง ชัยชนะที่ค่อนข้างแน่นอน กับ การเดิมพันเชิงนวัตกรรม และใช้วิธีตรวจสอบคนละแบบกับแต่ละประเภท
  • ตัวอย่าง "dummy features": ปุ่มที่พอกดแล้วขึ้นว่า "ฟีเจอร์นี้ยังไม่มี คุณช่วยบอกได้ไหมว่าจะใช้มันอย่างไร"
    • สิ่งนี้ให้สัญญาณจริงผ่าน พฤติกรรม ทั้งจำนวนผู้ใช้ที่สนใจและรายชื่อผู้ที่อาจสัมภาษณ์ต่อได้
    • เป็นสัญญาณที่ ดีกว่าแบบสอบถาม 100 เท่า เพราะในแบบสอบถามคนตอบ "ใช่" ได้ง่าย แต่การกดปุ่มคือการลงแรงแสดงความสนใจจริง พฤติกรรมที่สังเกตได้ชนะเจตนาที่พูดออกมา

• โฟกัสที่อิมแพ็กต์ต่อลูกค้าแทนความมั่นใจ (Focus instead on customer impact)

  • แทนที่ความมั่นใจด้วยอิมแพ็กต์ โดยนิยามอิมแพ็กต์ไว้สองแบบ
    • เสียงข้างมาก (Majority rule): ฟีเจอร์ที่ผู้ใช้ส่วนใหญ่ใช้เป็นประจำย่อมสำคัญชัดเจน และน่าจะเป็นเหตุผลหลักของการยอมรับและการคงอยู่
    • ผู้สนับสนุนอย่างแรงกล้า (Passionate advocates): ฟีเจอร์ที่ทำให้คนส่วนน้อยกลายเป็นแฟนพันธุ์แท้ คนที่พูดว่า "ซื้อเพราะสิ่งนี้อย่างเดียว" แม้จะไม่เป็นสากล แต่สร้างความภักดีอย่างลึกซึ้งในบางเซกเมนต์ ("magnificent delighters")
  • เมื่อผู้ใช้รักบางส่วนของผลิตภัณฑ์อย่างจริงใจ พวกเขาจะยอมทนข้อบกพร่องอื่นได้
    • เสน่ห์ของ iPod ทำให้ ผู้คนนับพันล้านยอมทน iTunes ซึ่งเป็นซอฟต์แวร์ที่แย่มาก
    • ซอฟต์แวร์ที่ออกแบบสวยงามก็อาจถูกยอมรับได้แม้ฟีเจอร์จะขาดหรือรองรับแพลตฟอร์มจำกัด เพียงเพราะประสบการณ์ด้านดีไซน์
  • นิยามเชิงปริมาณของฟีเจอร์อิมแพ็กต์สูง
    • (1) มีลูกค้า อย่างน้อย 51% ใช้งานเป็นประจำ หรือ
    • (2) มีลูกค้า อย่างน้อย 15% กล่าวถึงว่าเป็น 1 ใน 3 เหตุผลหลักที่เลือกใช้หรือใช้งานต่อ
    • เกณฑ์นี้สูง แต่ฟีเจอร์ที่มีนวัตกรรมและมีความเสี่ยงก็ควรเจอมาตรฐานสูง เพราะขนาดของผลตอบแทนต้องมากพอจะคุ้มความเสี่ยง

• ลงทุนกับ leverage (Invest in leverage)

  • มีบางพื้นที่ที่การเปลี่ยนแปลงเล็กน้อยแบบค่อยเป็นค่อยไปสามารถสร้างผลลัพธ์ใหญ่ได้
  • มีพื้นที่ของ leverage ที่ แทบจะเป็นจริงเสมอในเชิงคณิตศาสตร์และเชิงโครงสร้าง
    • (ตัดส่วนโปรโมตหนังสือที่เกี่ยวข้องออกเพราะเป็นโฆษณา)

• เพิ่ม optionality ให้สูงสุด (Maximize optionality)

  • ถ้าเราไม่อาจรู้อนาคต ก็จงเลือกสิ่งที่ เพิ่มจำนวนทางเลือกที่เราจะมีเมื่อไปถึงอนาคตนั้นให้มากที่สุด
    • ไม่ใช่แค่ความยืดหยุ่นหรือการหลีกเลี่ยง lock-in อย่างผิวเผิน แต่คือการออกแบบให้รับมือได้ไม่ว่าอะไรจะเกิดขึ้น
  • ตัวอย่าง
    • รักษาต้นทุนให้ต่ำ → คงความสามารถในการทำกำไรไว้ พร้อมเปิดทางให้ทดลองเรื่องราคาและแพ็กเกจได้หลากหลาย รวมถึงเพิ่มความทนทานในอนาคต
    • เลือก ไลบรารีหรือเฟรมเวิร์ก UI แบบ cross-platform ที่ผ่านการพิสูจน์แล้วและยังพัฒนาอย่างคึกคัก → รับมือวิวัฒนาการของแพลตฟอร์มและอุปกรณ์ได้
    • สถาปัตยกรรมแบบปลั๊กอิน → เปิดทางให้ทั้งทีมเองและชุมชนสร้างสิ่งที่วันนี้เรายังนึกไม่ออก
    • สถาปัตยกรรมแบบ API-first → แยกทีมออกจากกันได้ดี และเชื่อมฝั่ง frontend, backend และการเชื่อมต่อของลูกค้าเข้าด้วยกัน
    • wrapper ครอบบริการของ vendor → ทำให้เปลี่ยน vendor ที่ไม่เสถียร แพงเกินไป หรือพัฒนาช้าได้
  • การรักษาทางเลือกในอนาคตต้องแลกกับ งานเพิ่มในวันนี้
    • API ที่ใช้ครอบ vendor ไม่ได้เพิ่มคุณค่าในทันที
    • สิ่งนี้เหมาะกับ บริษัทที่เติบโตเต็มที่ ซึ่งความเสถียรและความคาดเดาได้มีความสำคัญ แต่สำหรับระยะเริ่มต้นที่ต้องชนะเจ้าตลาดด้วยความเร็ว มันอาจเป็นทางเลือกที่ผิด
  • วิธีเพิ่มทางเลือกของทั้งบริษัทให้สูงสุดคือ การสร้างบริษัทที่ยอดเยี่ยม
    • การเติบโตที่แข็งแรงและต่อเนื่อง, gross margin ที่ใหญ่และขยายตัวได้, ความรักจากลูกค้าที่พิสูจน์ด้วยการใช้งานต่อ การอัปเกรด และการบอกต่อ, ความรักจากพนักงานที่พิสูจน์ด้วยการอยู่กับบริษัทนานและเติบโตในสายอาชีพ
    • บริษัทที่ยอดเยี่ยมมี ทางเลือกมากมาย เช่น การถูกซื้อกิจการ การอยู่ต่อ การระดมทุน การ IPO หรือการส่งต่อกิจการ

• พอร์ตของการเดิมพัน (Portfolio of bets)

  • พอร์ตช่วยลดความผันผวน แต่ก็ ลดเพดานด้านบวกสูงสุด ไปด้วย
    • โอกาสที่จะแพ้ทั้งหมดลดลง จึงกัน downside ได้พอสมควร แต่เพราะชัยชนะต้องชดเชยความพ่ายแพ้ แม้แต่การชนะครั้งใหญ่เป็นครั้งคราวก็ยังไม่โตเท่าการลงเดิมพันเดี่ยว
    • เปรียบเทียบได้ว่า ถ้าซื้อ Amazon ตอน IPO แล้วถือไว้ตลอดคงดีที่สุด แต่ถ้าใช้วิธีเดียวกันกับ IPO อื่นในปีนั้นก็อาจเหลือ $0 ได้ พอร์ตจะไม่ลงไปถึงศูนย์ แต่การเติบโตสูงสุดก็ต่ำกว่าหุ้นที่ดีที่สุดมาก
  • เกร็ดคณิตศาสตร์: เหตุผลที่พอร์ตทำงานได้โดยไม่ขึ้นกับการกระจาย คือ ทฤษฎีบทขีดจำกัดส่วนกลาง (Central Limit Theorem)
    • หากสุ่มตัวอย่าง N ตัวอย่างซ้ำ ๆ จากประชากรที่มีการกระจายคงที่แต่เราไม่รู้ แล้ววาด histogram ของค่าเฉลี่ยตัวอย่าง การกระจายนั้นจะลู่เข้าเป็น Gaussian (การกระจายปกติ) โดยมีค่าเฉลี่ยเท่ากับค่าเฉลี่ยประชากร และมีความแปรปรวนเท่ากับความแปรปรวนประชากรหารด้วย 1/n
    • Lindeberg–Lévy CLT ยังแสดงว่าแนวคิดนี้ใช้ได้แม้แต่ละตัวอย่างจะมาจากคนละการกระจาย ตราบใดที่ยังมีความเป็นอิสระ ความแปรปรวนจำกัด และไม่มีตัวแปรเดี่ยวใดครอบงำทั้งหมด
    • อย่างไรก็ดี ในโลกสตาร์ตอัปมักมีการกระจายที่ทำให้เงื่อนไขนี้พัง เช่น Power Law บางแบบมีความแปรปรวนไม่สิ้นสุด
  • พอร์ตใช้ได้เมื่อคุณต้องการ ผลลัพธ์ที่คาดเดาได้แต่ธรรมดา และใช้ไม่ได้เมื่อคุณต้องการ outlier
    • ตัวอย่างพอร์ตของ VC/angel: 65% ขาดทุน และมีเพียงราว 10% เท่านั้นที่ให้ผลตอบแทนคุ้มกับความเสี่ยงและสภาพคล่องต่ำ
    • ถ้าต้องการ outlier ก็ต้องไม่ใช้พอร์ต แต่ใช้ การลงเต็มหน้าตัก แทน (เพราะการกระจายผลตอบแทนของสตาร์ตอัปเป็น Power Law ที่ผิดเงื่อนไขของ Lindeberg)
  • สรุปคือ ถ้ากำลังจัดลำดับความสำคัญเพื่อหาความแตกต่างในตลาดหรือแรงขับการเติบโต พอร์ตคือ เครื่องมือที่ผิด มันเหมาะกับผลลัพธ์เล็ก ๆ ที่เชื่อถือได้และค่อยเป็นค่อยไป ซึ่งในกรณีนั้นก็ไม่จำเป็นต้องเถียงกันเรื่องความมั่นใจอยู่แล้ว

• การเดิมพันแบบอสมมาตร (Asymmetric bets)

  • นี่คือขั้วตรงข้ามตามธรรมชาติของพอร์ต ถ้าพอร์ตมีไว้เพื่อความน่าเชื่อถือ การเดิมพันแบบอสมมาตรก็มีไว้เพื่อ outlier
    • ประเด็นไม่ใช่การทำนายว่าเดิมพันนั้นจะสำเร็จหรือล้มเหลว แต่คือการเลือกเดิมพันที่ ด้านล่างจำกัดและวัดได้ ส่วนด้านบนเปิดกว้างมาก
  • ถ้ากรณีแย่ที่สุดคือ "เสียเวลา 2 เดือน" แต่กรณีดีที่สุดคือ "สร้างความแตกต่างได้อย่างสมบูรณ์" ความน่าจะเป็นแทบไม่มีความหมาย
    • ขอเพียง downside ยังอยู่รอดได้ และ upside ใหญ่พอที่ชนะครั้งเดียวชดเชยการแพ้สิบครั้งได้ก็พอ
    • แม้เราไม่รู้ความน่าจะเป็นที่แม่นยำ แต่เรารู้ รูปทรง (shape) ของแต่ละเดิมพันได้
  • การเดิมพันแบบอสมมาตรในระดับกลยุทธ์มักมีรูปทรงที่กำหนดไว้ล่วงหน้าอยู่แล้ว (เช่น ตลาดใหม่ที่คำแนะนำแบบทบต้นสะสมขึ้นเรื่อย ๆ หรือ moat ที่ลึกขึ้นทุกครั้งที่ขายได้)
    • แต่ในระดับฟีเจอร์ เราต้อง ออกแบบความอสมมาตรขึ้นมาเอง เพราะรูปร่างพื้นฐานของโปรเจ็กต์ซอฟต์แวร์มักลื่นไหลจาก "2 สัปดาห์ → 2 เดือน → นานเกินจนจำใจต้องทำให้จบ"
    • กลไกคือ เขียนงบไว้ตั้งแต่ก่อนเริ่ม: "วิศวกร 2 คน, 3 สัปดาห์, จากนั้นหยุดแล้วทบทวน" — timebox คือ downside ที่ถูกจำกัดไว้
  • อีกทางหนึ่งคือแทนที่ความมั่นใจด้วยคำถามว่า "มันอสมมาตรแค่ไหน"
    • RICE บังคับให้คุณประมาณความน่าจะเป็นที่ยอมรับอยู่แล้วว่าไม่มีทางรู้จริง
    • แต่ความอสมมาตรถามถึงสองสิ่งที่พอประเมินได้จริง คือ กรณีแย่ที่สุดในแง่เวลาและต้นทุน กับ กรณีดีที่สุดในแง่คุณค่าต่อลูกค้า ทั้งคู่จับต้องได้ และถ้าจำกัดตัวเลขทั้งหมดให้อยู่ในกำลังของ 10 ก็มีแนวโน้มจะหาตัวเลขที่ตกลงกันได้ในที่ประชุม

บทสรุป

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

[hmmhmmhm]

"แทนที่จะทำเช่นนั้น ให้ใช้เทคนิคที่ใช้ได้ทุกครั้งที่อนาคตคาดเดาไม่ได้ เพราะอนาคตนั้นคาดเดาไม่ได้เสมอ" เยี่ยมเลยครับ

[spilist2]

เป็นบทความที่ยอดเยี่ยมมากครับ