คำตอบสั้น: ตัวเลข leverage ของเราเป็นเลขคณิตที่ทำซ้ำได้จาก script ที่เปิดสูตรไว้ครบ แต่ input ของมันเป็นการประเมิน ไม่ใช่การวัด ขนาดงานฝั่งทีมมนุษย์มาจากการที่คนติดป้าย S/M/L/XL เอง และกว่าครึ่งของ commit ถูกคิดด้วยค่าคงที่ที่ hardcode ไว้ที่ 20 เท่า บทความนี้เปิดสูตรทั้งหมดให้ดู เพื่อให้คุณตัดสินเองได้ว่าจะเชื่อแค่ไหน
ทำไมต้องเขียน รัฐธรรมนูญของเราข้อ 18 กำหนดว่า AI ของเรา "ห้ามคาดเดาตัวเลข" และต้อง "แยก Fact, Inference และ Suggestion" — ถ้าเราบังคับกับ AI ของตัวเอง เราก็ต้องบังคับกับการตลาดของตัวเองด้วย
ตัวเลขทุกตัวมาจาก script เดียวชื่อ fte_model.py ค่าคงที่ทั้งหมดคือ:
TIER_WEEKS = {'S': 2.5, 'M': 5.0, 'L': 10.0, 'XL': 20.0} # สัปดาห์ที่ทีมมนุษย์ "น่าจะ" ใช้
ROLE_SPLIT = {'PM': 0.10, 'Arch': 0.12, 'BA': 0.13,
'SA': 0.10, 'Dev': 0.40, 'QA': 0.15}
WEEKS_PER_MONTH = 4.33
HOURS_PER_FTE_MONTH = 160
OTHER_MULTIPLIER = 20.0 # ← ค่าคงที่สำหรับ commit ที่ไม่ได้จัดหมวดวิธีคิดคือ: แต่ละฟีเจอร์ถูกติดป้ายขนาด S/M/L/XL → แปลงเป็น "เดือนคนของทีมมนุษย์" ตาม TIER_WEEKS → เทียบกับชั่วโมงจริงของเราที่ประมาณจากระยะห่างระหว่าง commit ใน git → ได้ multiplier ต่อฟีเจอร์ → รวมทั้งแอป → รวมทั้ง portfolio
ผลลัพธ์รอบล่าสุด (16 ก.ค. 2026): 338.78 person-month ของทีมมนุษย์ (ประเมิน) ÷ 7.957 FTE-month จริง = 42.6 เท่า
ใหม่ในรอบ 16 ก.ค. ทุกแถวของตารางต้นทางถูกสร้างใหม่จากสคริปต์ gen_activity.py ในการรันครั้งเดียว วันเดียว และใช้ ref เดียวกันทั้ง 16 แอป รอบก่อนหน้านี้ตัวเลขถูกรีเฟรชทีละคอลัมน์คนละวัน จึงทำซ้ำไม่ได้ รายละเอียดอยู่ในหัวข้อที่ 4
"ทีมมนุษย์จะใช้ 10 สัปดาห์กับฟีเจอร์ขนาด L" — ตัวเลขนี้ เรากำหนดเอง ไม่มีทีมมนุษย์จริงมาจับเวลาเทียบ เอกสารต้นทางของเราเขียนไว้ตรง ๆ ว่า "ผู้เขียนกำหนดเองจากหลักฐาน endpoint/test/complexity-notes ที่ agent รายงาน ไม่ใช่มาตรฐานอุตสาหกรรมที่ตายตัว"
commit ที่ไม่ได้จัดเข้าฟีเจอร์ใดถูกเหมาว่ามี leverage 20 เท่า ตายตัว และก้อนนี้ใหญ่มาก — สำหรับ SmeDNA คือ 225 จาก 374 commit (60%) สำหรับ AppForge คือ 265 จาก 460 (58%) แปลว่า กว่าครึ่งของตัวเลขหัวข่าวคือสมมติฐาน ไม่ใช่การวัด
ROLE_SPLIT ใช้สัดส่วนเดียวกัน 10/12/13/10/40/15 กับทุกฟีเจอร์ มันแบ่งตัวเลขที่เดามาแล้วให้ดูละเอียดขึ้นเท่านั้น ไม่ได้เพิ่มข้อมูลใหม่ ใครที่เห็นกราฟแยก 6 role แล้วรู้สึกว่ามันแม่นยำ — นั่นคือภาพลวง
"ชั่วโมงจริง" ของเราไม่ได้มาจากการจับเวลา แต่ประมาณจากระยะห่างระหว่าง commit ฟีเจอร์ที่ คิดนานแต่ commit น้อย จะได้ชั่วโมงต่ำเกินจริง → multiplier พุ่งสูงเกินจริง
ตัวอย่างที่ชัดที่สุด ฟีเจอร์ที่ได้ multiplier สูงลิ่วระดับ 1,000 เท่าขึ้นไปในรายงานของเรา ทุกกรณีคือฟีเจอร์ที่ port มาจาก kit ที่มีอยู่แล้วครั้งเดียว — ควรอ่านว่า "ต้นทุนที่ประหยัดได้จากการใช้ซ้ำ" ไม่ใช่ "งานนี้ยาก 1,000 เท่า" ตัวเลขพวกนี้ไม่ใช่ตัวชี้วัดความซับซ้อน
เรามีวิธีประมาณสองแบบที่ทำแยกกันคนละเวลาและคนละตรรกะ:
ประเมินหยาบว่าทั้ง portfolio เทียบเท่างานทีมมนุษย์ 200–400 person-month → เทียบกับ ~7.96 FTE-month จริง → ได้ ประมาณ 25–50 เท่า
ไล่ติดป้ายขนาดทีละฟีเจอร์แล้วรวมขึ้นมา → ได้ 338.78 person-month → 42.6 เท่า
42.6 ตกอยู่กลางช่วง 25–50 พอดี และ 338.78 ตกอยู่ในช่วง 200–400 พอดี — สองวิธีที่ตรรกะต่างกันชี้ไปทางเดียวกัน นี่คือเหตุผลเดียวที่เรายังกล้าเผยแพร่ตัวเลขนี้ ไม่ใช่เพราะวิธีใดวิธีหนึ่งแม่น แต่เพราะมันไม่ขัดกันเอง
คำแนะนำจากเราเอง ถ้าคุณจะอ้างอิงเรา ให้ใช้ช่วง ~25–50 เท่า ตัวเลขจุดเดียวอย่าง 42.6 มีประโยชน์เฉพาะตอนเทียบสัดส่วนระหว่างแอปด้วยวิธีคิดเดียวกัน — ไม่ใช่ตอนอ้างความแม่นยำ
ในรายงานฉบับ 4 ก.ค. 2026 SmeDNA บังเอิญได้ 45.3× เท่ากับตัวเลขของทั้ง portfolio ในรอบ 11 ก.ค. พอดี ซึ่งเป็นความบังเอิญล้วน ๆ และเกือบทำให้ทีมเราเองสรุปผิดว่าเว็บอ้างตัวเลขสลับกัน · หลังรันใหม่ทั้งตารางเมื่อ 16 ก.ค. 2026 ตัวเลขแยกกันชัดแล้ว: portfolio = 42.6× · SmeDNA = 41.0× — ถ้าเห็นตัวเลข leverage ที่ไหน ให้ตรวจก่อนเสมอว่ากำลังพูดถึง portfolio หรือรายแอป และเป็นของรอบวัดไหน
ตัวเลข leverage ของเราขยับลงเรื่อย ๆ ตามเวลา:
| รอบวัด | งานทีมมนุษย์ (ประเมิน) | FTE จริง | Leverage |
|---|---|---|---|
| 4 ก.ค. 2026 | 330.65 person-mo | 7.05 | 46.9× |
| 11 ก.ค. 2026 | 332.58 person-mo | 7.339 | 45.3× |
| 16 ก.ค. 2026 | 338.78 person-mo | 7.957 | 42.6× |
เหตุผลตรงไปตรงมา: ยิ่งทำงานสะสมมาก FTE จริงยิ่งเพิ่ม ตัวหารโต multiplier จึงลด ตัวเลขที่ลดลงแปลว่าโมเดลกำลังตอบสนองต่อความจริง ถ้าเราอยากได้เลขสวย เราแค่หยุดวัดใหม่ก็ได้ — ตัวเลขที่ตรึงอยู่กับที่ตลอดปีคือสัญญาณอันตราย ไม่ใช่สัญญาณความสำเร็จ
สองรอบแรกลดลงเพราะงานสะสมเพิ่มตามปกติ แต่รอบ 16 ก.ค. เราไปเจอปัญหาที่ลึกกว่านั้น ตอนพยายามอัปเดตตัวเลขให้ทันวันที่
ตารางต้นทางของรอบก่อน ๆ ถูกประกอบขึ้นทีละคอลัมน์คนละรอบ จำนวน commit ถูกรีเฟรชวันหนึ่ง แต่ตัวเลขชั่วโมงยังค้างจากการรันครั้งก่อน ผลคือไม่มีใครรันสูตรแล้วได้เลขชั่วโมงชุดเดิมกลับมาได้อีก เราตรวจด้วยการไล่ทุก ref คูณทุกวันย้อนหลัง รวม 57 ชุดต่อแอป บนเครื่องสองเครื่องแยกกัน และผลตรงกันทั้งสองฝั่ง หลักฐานที่ชัดที่สุดคือ SmeDNA ซึ่งเลขชั่วโมงตรงกับ snapshot ของวันที่ 9 ก.ค. แต่จำนวน commit ในแถวเดียวกันเป็นของวันที่ 11 ก.ค.
เราจึงทิ้งตารางเดิมทั้งตาราง แล้วสร้างใหม่จากการรันครั้งเดียว วันเดียว ref เดียว ทั้ง 16 แอป ตัวเลขที่ได้คือ 42.6 เท่า ต่ำกว่าเดิม แต่เป็นครั้งแรกที่ทุกแถวรันซ้ำได้ด้วยคำสั่งเดียว ซึ่งเป็นสิ่งที่ตัวเลข 45.3 เท่าไม่เคยมี
ตรวจเองได้ สคริปต์ที่ใช้อยู่ใน repo ทั้งคู่ คือ gen_activity.py สำหรับ commit และชั่วโมง และ gen_loc.py สำหรับ LOC ตารางต้นทางระบุวันที่และ ref กำกับไว้ในไฟล์แล้ว ถ้าคุณรันแล้วได้เลขไม่ตรงกับที่เราเผยแพร่ นั่นคือบั๊กของเรา และเราอยากรู้
ยังค้างอยู่ DataDNA เป็นแถวเดียวที่ยังขัดกันเอง ตารางเดิมระบุ 204 commit แต่ทุก ref ใน repo รวมกันได้ 66 และรายการฟีเจอร์ของมันอ้างถึง commit มากกว่าที่ repo มีอยู่จริง เราจึงยังไม่แก้จนกว่าจะรู้ที่มา ผลกระทบถูกตีกรอบไว้แล้วและแคบ ไม่ว่าจะสรุปทางไหน ตัวเลขรวมอยู่ระหว่าง 42.0 ถึง 43.4 เท่า
นี่คือส่วนสำคัญที่สุดของบทความ รายงานต้นทางของเราเขียนไว้เองว่า "รายงานนี้วัด efficiency การสร้าง ไม่ใช่ traction หรือ user จริง"
การประเมินอิสระ 16 ก.ค. 2026 ด้วย AI 3 ตัวให้คะแนน Traction = 1 จาก 5 กับทุกแอปทั้ง 16 ตัว ทุกโมเดล เราไม่มีผู้ใช้ภายนอก การสร้างเร็วไม่ได้แปลว่าขายได้ — อย่างที่ผู้ประเมินรายหนึ่งสรุปไว้สั้น ๆ ว่า "HTTP 200 ไม่ใช่ traction"
โมเดลนี้นับปริมาณงานเทียบเวลา ไม่ได้ประเมินคุณภาพ ความปลอดภัย หรือความเหมาะกับตลาด คะแนนคุณภาพเป็นคนละชุดและก็เป็น self-assessment เช่นกัน
เอกสารของเราระบุว่า "git log ไม่ tag ผู้เขียนเป็นรายโมเดล" — เราแยกไม่ออกว่าส่วนไหนมาจากโมเดลใด ใครที่อ้างสัดส่วนแบบนั้นได้ ควรถูกถามว่าวัดยังไง
ตัวเลข person-month ของ "ทีมตลาด" คือการประเมินเพื่อเทียบ scope ไม่ใช่ข้อมูลจริงของบริษัทใด เราไม่มีสิทธิ์เข้าถึงข้อมูลภายในของคู่แข่ง และไม่แสร้งว่ามี
เพราะพาร์ทเนอร์ที่เราอยากได้คือคนที่ตรวจสอบเป็น และคนแบบนั้นจะเจอ OTHER_MULTIPLIER = 20.0 ภายในสิบนาที ถ้าเขาเจอมันเองหลังจากเราขายตัวเลข 42.6 เท่าไปแล้ว เขาจะสรุปว่าที่เหลือทั้งหมดก็ปั้นเหมือนกัน — และเขาก็ควรสรุปแบบนั้น
เราเลือกเปิดก่อน เพราะ ข้อจำกัดที่เราเขียนเองน่าเชื่อถือกว่าตัวเลขหัวข่าวของเราเอง และตัวเลขที่ผ่านการเปิดจุดอ่อนแล้วยังยืนอยู่ได้ คือตัวเลขที่ใช้คุยธุรกิจกันได้จริง
และเพื่อไม่ให้ความตั้งใจนี้เป็นแค่คำพูด เราบังคับมันด้วยเครื่อง — ทุกตัวเลขบนเว็บนี้ถูกประกาศไว้ในไฟล์เดียวและตรวจใน CI ทุกครั้งที่ push ถ้าหน้าไหนพูดตัวเลขที่ถูกแทนที่ไปแล้ว หรือสองหน้าพูดตัวเลขเดียวกันไม่ตรงกัน build จะพัง ตัวตรวจเป็น open source อ่านได้เลยว่ามันบังคับอะไรบ้างและมองไม่เห็นอะไรบ้าง: github.com/ai9tui/site-facts
ดู Partner Program ดูรายงานประเมินฉบับเต็ม
อัปเดต เผยแพร่ 16 ก.ค. 2026 · แก้ไขล่าสุด 17 ก.ค. 2026 · ตัวเลขหัวข่าวอ้างอิงรอบวัด 16 ก.ค. 2026 (รอบ 4 และ 11 ก.ค. เก็บไว้ในตารางประวัติเพื่อการเทียบ) · หากตัวเลขบนหน้าอื่นของเว็บนี้ขัดกับหน้านี้ ให้ถือหน้านี้เป็นหลัก และโปรดแจ้งเราที่ contact@dnafinity.com
มันคือเลขคณิตที่ทำซ้ำได้จริงจาก script ที่เปิดสูตรไว้ แต่ input เป็นการประเมินไม่ใช่การวัด ขนาดงานของทีมมนุษย์มาจากการที่คนติดป้าย S M L XL ให้แต่ละฟีเจอร์เอง ไม่ใช่ benchmark จากทีมมนุษย์จริง และกว่าครึ่งของ commit ถูกคิดด้วยค่าคงที่ 20 เท่าที่กำหนดไว้ล่วงหน้า จึงควรอ่านเป็น directional estimate ไม่ใช่ผลการตรวจสอบ
เพราะมันเป็นอัตราส่วนที่ตัวหารโตขึ้นเรื่อย ๆ เมื่อทีมทำงานสะสมมากขึ้น FTE จริงก็เพิ่ม ทำให้ multiplier ลดลง เช่นรอบ 4 ก.ค. 2026 ได้ 46.9 เท่า จาก 330.65 person-month หารด้วย 7.05 FTE-month พอถึงรอบ 11 ก.ค. เป็น 45.3 เท่า จาก 332.58 หารด้วย 7.339 และรอบ 16 ก.ค. เป็น 42.6 เท่า จาก 338.78 หารด้วย 7.957 ตัวเลขที่ลดลงคือสัญญาณว่าโมเดลกำลังทำงานตามความจริง ไม่ใช่ตัวเลขการตลาดที่ถูกตรึงไว้ นอกจากนี้รอบ 16 ก.ค. ยังเป็นรอบแรกที่ทุกแถวถูกสร้างจากการรันครั้งเดียววันเดียว จึงตรวจซ้ำได้ทั้งตาราง
แนะนำให้ใช้ช่วงประมาณ 25 ถึง 50 เท่า เทียบกับงานทีมมนุษย์ราว 200 ถึง 400 person-month มากกว่าจะใช้ตัวเลขจุดเดียวอย่าง 42.6 เท่า เพราะช่วงสะท้อนความไม่แน่นอนของสมมติฐานได้ตรงกว่า ส่วนตัวเลขจุดเดียวมีประโยชน์เมื่อต้องการเทียบสัดส่วนระหว่างแอปด้วยวิธีคิดเดียวกันเท่านั้น