แต่ในโลกของความเป็นจริง การบริหารทีมแบบ "One size fits all" คือ ความผิดพลาดที่ร้ายแรงที่สุดอย่างหนึ่งของ Leader สิ่งที่คนส่วนใหญ่พลาด คือ การตีความคำว่ายุติธรรมผิดไป ความยุติธรรมที่แท้จริงไม่ใช่การปฏิบัติกับทุกคนเหมือนกัน แต่ คือ การปฏิบัติต่อบุคคลให้เหมาะสมกับ "ความพร้อม" ของเขาในแต่ละสถานการณ์ นี่ คือ หัวใจของ Situational Leadership ซึ่งไม่ใช่เรื่องของการรับมือวิกฤตน้ำท่วมไฟไหม้ แต่เป็นเรื่องการรับมือความพร้อมของ "คน" ที่มีต่อ "งาน" ที่เปลี่ยนไปในทุกๆ วัน

แกนวัดความพร้อม: แผนภูมิ Can vs. Want ที่คนทำงานมักมองข้าม

ในการประเมินลูกน้อง เราไม่ควรประเมินคนแบบเหมาเข่งว่า "คนนี้เก่ง" หรือ "คนนี้ไม่เก่ง" แต่ต้องประเมินเป็นรายชิ้นงาน (Task-based) โดยใช้ 2 แกนหลักตามระดับความพร้อม (Readiness)

1. แกนตั้ง - ความสามารถ (Ability/Can): วัดจากความรู้ ทักษะ และประสบการณ์ (ทำได้ไหม?)
2. แกนนอน - ความเต็มใจ (Willingness/Want): วัดจากพลังงาน ความกระตือรือร้น และใจที่อยากจะทำ (อยากทำไหม?)

ในฐานะ Manager คุณต้องมองคนให้เหมือนกับ Component ในระบบ คนหนึ่งคนไม่จำเป็นต้องมีระดับความพร้อมเดียวในทุกงาน วิศวกรระดับ Senior ของคุณอาจเป็น R4 ที่ไว้ใจได้ที่สุดในการเขียน Backend ด้วย Python (Can สูง, Want สูง) แต่เขาอาจกลายเป็น R1 ทันทีเมื่อต้องเขียนเอกสารเพื่อทำ SOC2 Compliance (Can ต่ำ, Want ต่ำ) หากคุณประเมินความพร้อมผิดและปล่อยให้เขาทำเอกสารโดยไม่กำกับดูแล ระบบการทำงานของคุณจะเกิดคอขวด (Bottleneck) ทันที

ถอดรหัสลูกน้อง 4 แบบ (R1 - R4) และ กลยุทธ์การบริหาร

เมื่อเรานำ 2 แกนมาพล็อต เราจะพบความพร้อม 4 ระดับที่ต้องการสไตล์การนำที่ต่างกันอย่างสิ้นเชิง

• R4 (Can สูง, Want สูง): กลุ่มดาวเด่นไฟแรง
  • สไตล์: Empower (ให้อำนาจ) บอกเป้าหมายที่ชัดเจนแล้วถอยออกมา อย่าเป็นคอขวดในกระบวนการ Pull Request (PR) ของเขา อย่าจุกจิก แต่ต้องคอยซัพพอร์ตห่างๆ การเข้าไปวุ่นวายกับ R4 มากเกินไปจะทำให้เขาเบื่อและรู้สึกว่าคุณไม่ไว้วางใจ
• R3 (Can สูง, Want ต่ำ): กลุ่มมือเก่าไฟตก
  • สไตล์: Ask (ใช้การตั้งคำถาม) เขาเก่งอยู่แล้ว อย่าไปสอนงานเขา แต่ต้องตั้งคำถามเพื่อหาต้นตอของปัญหาใจ เช่น ผิดหวังเรื่องผลประเมิน หรือเบื่อ Legacy Code เดิมๆ
• R2 (Can ต่ำ, Want สูง): กลุ่มน้องใหม่ไฟแรง
  • สไตล์: Explain (ชี้แนะ) เช่น น้องใหม่ที่อยากลองทำ Vector Database แม้จะยังไม่มีประสบการณ์ คุณไม่ต้องกระตุ้นใจเขาเพราะเขามีเต็มเปี่ยม แต่คุณต้อง "สอน" ไกด์วิธีการทำงาน และอธิบาย "How" ให้ชัดเจน
• R1 (Can ต่ำ, Want ต่ำ): กลุ่มไม้ตายซาก (Deadwood)
  • สไตล์: Tell/Sell (สั่งการและจูงใจ) นี่ คือ กลุ่มที่น่าปวดหัวที่สุดเพราะทั้งทำไม่เป็นและไม่อยากทำ
  • กฎเหล็ก: สำหรับ R1 คุณต้อง เคลื่อนแกน "Want" ก่อนแกน "Can" เสมอ อย่าส่ง R1 ไปเรียนคอร์สเทคนิคราคาแพง (Can) ตราบใดที่เขายังไม่อยากทำ (Want) เพราะจะเสียเวลาเปล่า คุณต้องสื่อสารว่า "ทำไม" งานนี้ถึงสำคัญต่อเขาและทีม เพื่อดึงใจเขากลับมาให้ได้ก่อน

Deep Dive: เทคนิคการถามแบบ "ตัว T" (T-Question) สำหรับกลุ่ม R3

การจัดการกลุ่ม R3 คือ ความท้าทายที่สุด ผู้นำที่ดียังไม่ควรรีบ "รักษา" หรือ เสนอทางแก้ทันที แต่ต้องทำตัวเหมือน "คุณหมอ" ที่ถามอาการอย่างละเอียดก่อนจ่ายยา โดยใช้เทคนิคคำถามตัว T

• แนวราบ (Wide): ถามกว้างๆ เพื่อเปิดประเด็น
• แนวตั้ง (Deep): ถามลึกลงไปเมื่อเจอจุดที่น่าสงสัย

บริหารจัดการ vs. ปล่อยปละละเลย: Trade-off ที่เลี่ยงไม่ได้

คำว่า "บริหารจัดการ" (Management & Administration) มีสองด้านที่ต้องรักษาสมดุล:

1. การบริหาร (Manage): คือ การพยายามโค้ชและพัฒนาคนจาก R1 ไปสู่ R4 ตามกลยุทธ์ที่กล่าวไป
2. การจัดการ (Administer): เมื่อเราพยายาม "บริหาร" อย่างสุดความสามารถแล้วแต่ "ไม้ตายซาก" ยังไม่ยอมแตกกิ่งก้านใหม่ เราต้องกล้าตัดสินใจจัดการ เช่น การโยกย้ายตำแหน่ง หรือแม้แต่การให้เขาออกจากทีม

ในฐานะผู้นำ คุณต้องแบกรับความรับผิดชอบนี้ เพราะ "การปล่อยคนที่ไม่ทำงานไว้เฉยๆ คือ การให้รางวัลคนทำไม่ดี" และนี่ คือ Opportunity Cost ที่มหาศาล การปกป้อง R1 ที่ไม่ยอมโต คือ การลงโทษ R4 ที่ตั้งใจทำงาน เพราะสุดท้ายคนเก่งจะต้องแบกงานหนักขึ้นจนเกิดอาการ Burnout และลาออกไปในที่สุด

การสร้างความเข้าใจในทีม: ทำอย่างไรไม่ให้ถูกมองว่า "ลำเอียง"

เพื่อไม่ให้เกิดข้อครหาว่าคุณมี "เด็กเส้น" หรือ "รักลูกน้องไม่เท่ากัน" คุณควรเปิดเผยแนวคิด Situational Leadership นี้ให้ทีมรับทราบอย่างโปร่งใส:

• ใช้ภาษาเดียวกัน: สอนทีมให้เข้าใจ R1-R4 เพื่อให้เขารู้ว่าทำไมสไตล์การ Manage ของคุณถึงเปลี่ยนไปตามเนื้องาน
• Self-Assessment: ในช่วง Sprint Planning หรือการรับโปรเจกต์ใหม่ (เช่น การ Migrate จาก Monolith ไป Microservices) ลองถามน้องๆ ว่า "งานนี้คุณประเมิน R-level ของตัวเองไว้ที่เท่าไหร่?"
• สื่อสารเหตุผล: อธิบายว่า "ที่ผมต้องลงรายละเอียดกับคุณในงานนี้ เพราะมันเป็นเรื่องใหม่สำหรับคุณ (R2) แต่ในงาน Coding ผมปล่อยคุณเต็มที่เพราะคุณ คือ มืออาชีพ (R4)"

บทสรุป: ความเป็นผู้นำ คือ การออกแบบระบบที่ยืดหยุ่น

การบริหารคนก็เหมือนการทำ System Design ที่ไม่มี Parameter ตายตัว คุณไม่สามารถใช้ Configuration เดียวกันกับทุก Microservice ได้ คนก็เช่นกัน ความเป็นผู้นำที่มีประสิทธิภาพ คือ ความยืดหยุ่นที่จะปรับสไตล์ตามความพร้อมของงานในขณะนั้น

ลองกลับไปสำรวจทีมของคุณเสมือนการทำ System Audit: "วันนี้ Nodes ในระบบของคุณ (ลูกน้อง) กำลังล้มเหลวเพราะ Capacity (Can) หรือเพราะ Connectivity (Want)?"

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

นี่ คือ metric หลักที่ใช้กันจริงในทีม engineering

1. Cycle Time (เวลาทำงานจริง)

วัดตั้งแต่ engineer เริ่มลงมือทำ จนถึง deploy/done

Cycle Time = วันที่ Done − วันที่เริ่ม In Progress

ซึ่งข้อมูลนี้ เราสามารถดึงข้อมูลได้จาก Jira/Linear/GitHub ตรง ๆ เราดูที่ timestamp ตอน ticket เปลี่ยน status เป็น "In Progress" กับ ตอนเปลี่ยนเป็น "Done"/merged ได้เลย

2. Lead Time (เวลาทั้งหมดที่ลูกค้า/ฝั่งธุรกิจรอ)

วัดตั้งแต่ request เข้ามา จนถึง ของจริงไปอยู่ในมือ user

Lead Time = วันที่ Released − วันที่ Ticket ถูกสร้าง/Request เข้ามา

สิ่งนี้ คือ ตัวเลขที่ฝั่ง business รู้สึกจริงๆ ซึ่งต่างจาก Cycle Time เพราะรวมเวลาที่ ticket ค้างอยู่ใน backlog ก่อนมีคนหยิบขึ้นมาทำด้วย

3. Deployment Frequency

นับว่า deploy ขึ้น production บ่อยแค่ไหน (ต่อวัน/สัปดาห์) ยิ่งถี่ มักแปลว่า batch size เล็ก ความเสี่ยงต่อ release ต่ำ

4. Throughput / Velocity

• Throughput = จำนวน items ที่ทำเสร็จต่อ sprint/เดือน (นับจำนวนตรง ๆ ไม่สน point)
• Velocity = sum of story points ที่ทำเสร็จต่อ sprint (ใช้เทียบ trend ภายในทีมเดียวกันเท่านั้น ห้ามเอาไปเทียบข้ามทีม เพราะแต่ละทีม estimate point ไม่เหมือนกัน)

5. % Sprint Commitment Met

(จำนวน items ที่ทำเสร็จตามที่ commit) ÷ (จำนวน items ที่ commit ไว้ตอนต้น sprint) × 100

วัด "ความแม่นยำในการคาดการณ์" มากกว่าความเร็ว แต่สำคัญพอ ๆ กัน เพราะ predictability คือสิ่งที่ stakeholder ต้องการจริง ๆ

ข้อแนะนำการนำไปใช้งาน

• ใช้ Median (มัธยฐาน) หรือ p85 ไม่ใช่ average cycle time มัก skew จาก outlier (ticket ที่ค้าง 3 สัปดาห์) ทำให้ average หลอกตา
• แยกตาม squad ไม่รวมทั้งองค์กรเป็นตัวเลขเดียว เพราะแต่ละทีมงานต่างกัน เทียบรวมจะไม่มีความหมาย
• ถ้าอยากได้ framework ที่ครอบคลุมและเป็นมาตรฐานที่คนในอุตสาหกรรมรู้จัก ลองดู DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Restore) — มันคือ 4 ตัวที่ Google ใช้วัด elite vs low-performing team

p85 คืออะไร

มัน คือ เปอร์เซ็นไทล์ที่ 85 หมายความว่า ถ้าเอาข้อมูลทั้งหมดมาเรียงจากน้อยไปมาก แล้วดูว่าตัวเลขไหนที่ "85% ของข้อมูลทั้งหมดอยู่ต่ำกว่าหรือเท่ากับมัน"

ตัวอย่าง

สมมติเรามี cycle time ของ 20 tickets ที่ทำเสร็จในเดือนนี้ (หน่วย: วัน) เรียงจากน้อยไปมากแล้ว:

1,1,1,2,2,2,2,3,3,3,3,4,4,4,5,5,6,8,12,21

• Median (p50) = ตัวกลาง (อันดับที่ 10-11) = 3-4 วัน
• p85 = ตัวที่อยู่ตำแหน่งที่ 85% ของ 20 ตัว = ประมาณอันดับที่ 17 = 8 วัน

ความหมายคือ: 85% ของ ticket ทำเสร็จภายใน 8 วัน ส่วนอีก 15% (พวก outlier ที่ใช้เวลา 12, 21 วัน) คือตัวที่ฉุดค่าเฉลี่ยให้ผิดเพี้ยน

ทำไมต้องใช้ p85 แทน Average

ลองคิดดูจากตัวอย่างเดียวกัน:

• Average = รวมทั้งหมด ÷ 20 = ประมาณ 4.2 วัน → ดูดีเกินจริง เพราะถูกถ่วงด้วยตัวเลขกลาง ๆ ส่วนใหญ่
• p85 = 8 วัน → สะท้อนภาพ "เคสที่แย่แต่ไม่ใช่ outlier สุดขั้ว" ได้ตรงกว่า

Average จะโกหกเราได้ง่าย เพราะ ticket ส่วนใหญ่ (เช่น bug fix เล็ก ๆ) เสร็จเร็ว แต่มี ticket ไม่กี่ตัวที่ค้างนานมาก (ติด dependency, รอ review, scope บวม) ตัวพวกนี้จะถ่วง average ให้ดูแย่ลงแบบไม่สมเหตุสมผล หรือบางทีกลับกัน — ทำให้ average ดูดีเกินจริงถ้า outlier น้อย ในขณะที่ p85/p90 จะบอกเราตรง ๆ ว่า "เคสส่วนใหญ่ที่แย่กว่าค่ากลาง" หน้าตาเป็นยังไง

แต่... Digital Transformation ไม่ใช่เกมเสี่ยงดวงอะไรพวกนั้น มัน คือ การตัดสินใจครั้งใหญ่ท่ามกลาง ความไม่แน่นอน เพื่อ "พลิกโฉม" (reinvent) ธุรกิจ ไม่ใช่แค่ "ปรับปรุง" (improve) ให้ดีขึ้นนิดหน่อย

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

จากบทความของ McKinsey ได้สรุปประสบการณ์ทำ Digital Transformation หลายสิบโครงการออกมาให้พวกเราได้อ่านกัน

https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-seven-decisions-that-matter-in-a-digital-transformation

ผมอ่านบทความนี้ตั้งแต่ออกมาช่วงแรกๆ วันเลยเอาหยิบมาเขียนเป็นบทความเพื่อแชร์มุมมองทั้งของ McKinsey และผมเอง

McKinsey บอกว่า มี 7 การตัดสินใจ ที่สำคัญที่สุด กระจายอยู่ใน 4 เฟส คือ

Discover (ค้นหาเป้าหมาย) → Design (ออกแบบแผน) → Deliver (ลงมือทำ) → De-risk (ลดความเสี่ยง)

มาดูทีละข้อพร้อมตัวอย่างจริงกัน

Phase 1: DISCOVER การตั้งเป้าหมายให้ธุรกิจ

การตัดสินใจที่ 1: ธุรกิจควรไปในทิศทางไหน

การเลือกทิศทางของธุรกิจ เป็นการตัดสินใจที่สำคัญที่สุด เพราะมันเป็นเรื่องความอยู่รอดขององค์กร

สำหรับบริษัทที่พึ่งตั้งมาใหม่ไม่กี่ปี สิ่งนี้อาจฟังดูน่ากลัว หรือ รู้สึกถึงความไม่มั่นคง (ในมุมมองของพนักงาน)

แต่ความจริง คือ ทุกองค์กรทั้งใหม่และเก่าส่วนใหญ่ "ไม่มีทางเลือก" เพราะต้องเผชิญการ disrupt ที่คุกคามความอยู่รอด ในระยะยาวอยู่แล้วเป็นเรื่องปกติ

McKinsey แนะนำให้เริ่มจากการวิเคราะห์ตลาดด้วยหลักอุปสงค์-อุปทาน (demand-supply) แต่ย้ำว่า การวิเคราะห์อย่างเดียว ไม่พอ ต้องใช้จินตนาการด้วย

วิธีหนึ่ง คือ ลองจินตนาการว่า ถ้าอุตสาหกรรมของเรากลายเป็นดิจิทัล เต็มรูปแบบ มันจะหน้าตาเป็นอย่างไร (ถ้าเป็นสมัยนี้ก็เป็นเรื่องของ AI)

ตัวอย่าง

GE: ซีอีโอ Jeff Immelt มองเห็นว่า "15-20% ของมูลค่าหุ้นใน S&P 500 คือ หุ้น บริษัทอินเทอร์เน็ต ที่เมื่อ 15-20 ปีก่อนยังไม่มีอยู่เลย เขามองว่าในอีก 10-15 ปีข้างหน้า มูลค่า แบบเดียวกันนั้นจะเกิดขึ้นใน Industrial Internet

จากวิสัยทัศน์นี้ GE จึงตั้ง GE Digital กลุ่มงาน ซอฟต์แวร์ และ วิเคราะห์ข้อมูล พร้อมทั้งเปิดตัวแพลตฟอร์ม Predix ที่เชิญนักพัฒนามาสร้างแอปจากข้อมูลของ GE

เฟสที่ 2: DESIGN วางแผน Digital Transformation

การตัดสินใจที่ 2: ใครจะเป็นผู้นำการเปลี่ยนแปลง

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

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

ตัวอย่าง

Quicken Loans: Daniel Gilbert ผู้ร่วมก่อตั้ง ทำตัวเป็น "กระบอกเสียง" หลัก ของโครงการ Rocket Mortgage ถึงขั้นเรียกมันว่าเป็น "iPhone moment ของวงการสินเชื่อบ้าน"

Starbucks: Howard Schultz ให้ CIO และ CDO นำการทำดิจิทัลที่กินเวลาเป็นสิบปี จนทำให้การจ่ายเงินผ่านมือถือแพร่หลายในร้านทั่วอเมริกาเหนือ ผูกแน่นกับโปรแกรมสะสมแต้มลูกค้า

ส่วนบริษัทพลังงานในยุโรปแห่งหนึ่ง กลับให้ COO, CMO และ CSO (หัวหน้าฝ่ายขาย) เป็นผู้นำแทน

การตัดสินใจที่ 3: จะ "ขาย" วิสัยทัศน์ให้ผู้มีส่วนได้ส่วนเสียอย่างไร

ทุกการเปลี่ยนแปลงนั้น เราต้องสื่อสารวิสัยทัศน์อย่างจริงจัง พร้อมอธิบายว่าทำไมมันถึงจำเป็น

CEO ต้องตัดสินใจไม่ใช่แค่ว่า "จะพูดอะไร" แต่รวมถึง "พูดอย่างไร" และ "พูดนานแค่ไหน" วิธีหนึ่ง คือ มอง โครงการเปลี่ยนแปลงเป็น "ผลิตภัณฑ์" แล้วสร้างแบรนด์ให้มัน

ตัวอย่างจริง

Burberry: เมื่อ Angela Ahrendts ขึ้นเป็นซีอีโอ เธอเปิดตัวแคมเปญ Art of the Trench และรุกเข้าสู่ดิจิทัลอย่างกล้าหาญ ส่งสัญญาณถึงความทะเยอทะยานสูง และ ปลุกองค์กรให้ตื่นตัว

ตัวอย่างจริง

ING: ต้นปี 2014 ซีอีโอ Ralph Hamers ประกาศวิสัยทัศน์ Think Forward, Act Now เพื่อมอบประสบการณ์ลูกค้าที่แตกต่างผ่านนวัตกรรมที่เร็วขึ้น และ การใช้ข้อมูลที่ดีขึ้น ต่อมาปลายปี 2016 เขาอัปเดตเป็น Accelerating Think Forward ที่เน้นเรื่อง mobile banking

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

การตัดสินใจที่ 4: จะวางตำแหน่งบริษัทไว้ตรงไหนใน Digital Ecosystem

ทุกวันนี้บริษัทใหม่ๆ ท้าทายเจ้าตลาดได้เพราะมี ecosystem ของทรัพยากรราคาถูก และ หาง่าย

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

ตัวอย่าง

Thalia: Michael Busch ซีอีโอของร้านหนังสือชั้นนำของเยอรมนี ประเมินซัพพลายเชน ทั้งสาย ก่อนเปิดตัวหนังสือดิจิทัล เขาสร้างพันธมิตรกับร้านหนังสืออื่นๆ และ จับมือกับ Deutsche Telekom เพื่อใช้โครงสร้างพื้นฐานด้านเทคโนโลยี และ การกระจายสินค้าดิจิทัล

แต่เขา ไม่ยอมทำข้อตกลงใดๆ ที่จะ ตัดขาด Thalia ออกจากลูกค้า เพราะถือว่านั่น คือ คุณค่าหลักของบริษัท

ตัวอย่าง

BBVA Compass: ธนาคารสัญชาติสเปนแห่งนี้แปลงตัวเองเป็นองค์กรดิจิทัลอย่าง ดุดัน ในปี 2016 เปิดตัว API marketplace ให้สตาร์ตอัป fintech สร้างแอปที่เชื่อมกับระบบหลังบ้าน ของ BBVA ได้

วิธีนี้ดึงพลัง และ ความคิดสร้างสรรค์ของผู้ประกอบการมาใช้ ขณะที่ BBVA ยังรักษาความ เป็นผู้นำใน ecosystem ไว้ได้

การตัดสินใจที่ 5: จะตัดสินใจอย่างไร "ระหว่าง" การเปลี่ยนแปลง

Mike Tyson เคยพูด ว่า "ทุกคนมีแผน...จนกระทั่งโดนต่อยเข้าที่ปาก" ไม่ว่าจะออกแบบโครงการมาดีแค่ไหน ก็ต้องเจอเรื่องเซอร์ไพรส์เสมอ CEO และ ทีมจึงต้องตกลง กฎการกำกับดูแล และ การส่งต่อปัญหา (governance & escalation) ไว้ล่วงหน้า เพื่อให้ปรับเส้นทาง ได้ทันเมื่อจำเป็น

ควรมีการเช็กอินกับผู้บริหารระดับสูง อย่างน้อยสัปดาห์ละครั้ง ฟังดูเยอะสำหรับ CEO แต่แค่ชั่วโมงเดียวต่อสัปดาห์ คิดเป็นเพียง 1-2% ของเวลา CEO เท่านั้น และต้องมี dashboard ติดตามความคืบหน้า

โดยต้องระวังไว้ว่า ตัวชี้วัดระยะสั้นอย่าง ROI อาจหลอกตากันได้ ควรใช้ตัวชี้วัดแบบใหม่ เช่น ยอดสมัครใช้งานช่องทางดิจิทัล หรือระดับการมีส่วนร่วมบนดิจิทัล ซึ่งสะท้อนความคืบหน้าได้ดีกว่า

เฟสที่ 3: DELIVER ลงมือทำตามแผน พร้อมปรับระหว่างทาง

การตัดสินใจที่ 6: จะจัดสรรงบประมาณให้เร็วและยืดหยุ่นอย่างไร

คันโยกสำคัญที่สุดของ CEO ในการขับเคลื่อน Digital Transformation คือ การจัดสรรทรัพยากร ไม่ใช่แค่ส่งทรัพยากรไปให้ถูกที่ แต่ต้องตัดสินใจด้วยว่า "กระบวนการ" จัดสรรควรเป็นแบบไหน และ ควรเดินด้วยจังหวะเร็วแค่ไหน

McKinsey แนะนำให้ CEO และ ทีมทำตัวเหมือน Venture Capitalist ที่ติดตามความคืบหน้าของ แต่ละโครงการอย่างใกล้ชิด ถอดปลั๊กโครงการที่ทำได้ต่ำกว่าเป้า และ เติมเงินให้โครงการที่ไปได้ดี

สิ่งนี้ต้องอาศัยการเร่งกระบวนการงบประมาณ จากเดิมที่บริษัทใหญ่มักทำเป็นรอบปี ให้เปลี่ยนเป็น รายไตรมาส หรือ รายเดือน แทน

ตัวอย่าง

ธนาคารแห่งหนึ่ง: ช่วงกลางของการเปลี่ยนแปลง ธนาคารพบว่าแม้ลงทุนดิจิทัล ไปมหาศาลแล้ว แต่สาขายังกินค่าใช้จ่ายการดำเนินงานถึง 90% ทั้งที่ 70-80% ของธุรกรรมในสาขา สามารถทำผ่านดิจิทัลได้ ธนาคารจึงโยกงบลงทุนเกือบทั้งหมดไปที่ดิจิทัล โดยการปิดสาขาหลายไปแห่ง และ เปิดโครงการย้ายลูกค้าที่เคยพึ่งสาขาให้ไปใช้ตู้ ATM และ ช่องทางเว็บ/มือถือแทน

เฟสที่ 4: DE-RISK ลดความเสี่ยง เพิ่มโอกาสสำเร็จ

การตัดสินใจที่ 7: จะทำอะไร "เมื่อไหร่"

ความจริงที่น่ากลัว กว่า 70% ของโครงการ transformation มักล้มเหลว การตัดสินใจทั้ง 6 ข้อ ก่อนหน้าช่วยเพิ่มโอกาสรอดได้มาก แต่สิ่งที่ทำลายแม้แต่โครงการที่ดีที่สุด คือ "การสูญเสียโมเมนตัม"

ทางป้องกัน คือ CEO ต้องวาง ลำดับ (sequencing) การเปลี่ยนแปลงให้ดี อาจจะเลือกทำสิ่งที่ได้ผลเร็วก่อน (quick wins) ซึ่งสร้างรายได้และลดต้นทุน แล้วเอากำไรนั้นมาลงทุนต่อในลำดับต่อๆ ไป

ตัวอย่างจริง

ผู้ค้าปลีกออนไลน์รายหนึ่ง: ปลดล็อกมูลค่าได้ 300 ล้านดอลลาร์ ภายในแค่ 5 เดือน ด้วยการจัดลำดับทำโครงการที่คืนทุนเร็วที่สุดก่อน และ ด้วยโมเมนตัมจากชัยชนะในช่วงแรกนี้ พวกเขาได้เปลี่ยนมันให้กลายเป็น กว่า 800 ล้านดอลลาร์ภายในหนึ่งปี

การจัดลำดับที่ดีต้องมีเกณฑ์ประเมินผลตอบแทนชัดเจน ทั้งประโยชน์ที่คาดว่าจะได้ เวลาที่ต้องใช้ ความเกี่ยวเนื่องระหว่างโครงการ เงินลงทุน และ ผลต่อภาพรวม

ที่สำคัญต้องมองที่ "ผลสะสม" ด้วย เพื่อให้ธุรกิจค่อยๆ ประกอบกันเป็นภาพดิจิทัลที่กลมกลืน ไม่ใช่กองโครงการกระจัดกระจาย ที่ไร้พลังของการ scale

บทสรุป

ดิจิทัล คือ โจทย์ที่นิยามคนเป็น CEO ในยุคนี้ และ การตัดสินใจของพวกเขาจะเป็นตัวชี้ว่าธุรกิจจะ รุ่งเรือง หรือ เลือนหาย

ถ้าจะสรุป 7 การตัดสินใจให้จำง่าย:

1. ไปทางไหน: เลือกทิศทางธุรกิจจากจุดที่มูลค่ากำลังเคลื่อนไป
2. ใครนำ: ซีอีโอต้องนำเอง พร้อมทีมเล็กแต่ทักษะครบ
3. ขายวิสัยทัศน์อย่างไร: สื่อสารแบบทำแคมเปญ ปรับสารให้เหมาะแต่ละกลุ่ม
4. วางตำแหน่งใน ecosystem ตรงไหน: ใช้ทรัพยากรภายนอก แต่ปกป้องลูกค้าและข้อมูล
5. ตัดสินใจระหว่างทางอย่างไร: วาง governance, เช็กอินถี่, ใช้ตัวชี้วัดที่ใช่
6. จัดสรรงบอย่างไร: คิดแบบ VC ปรับงบเป็นรายไตรมาส/เดือน กล้าตัดงบของเก่า
7. ทำอะไรเมื่อไหร่: จัดลำดับเอา quick wins ก่อน เพื่อรักษาโมเมนตัม

หัวใจของทั้งหมดไม่ใช่ความ "กล้า" เฉย ๆ แต่ คือ การ "กล้าอย่างมีสติ" (thoughtfully bold) กล้าตัดสินใจเรื่องยากที่มี trade-off จริง โดยไม่หลีกเลี่ยง ไม่ผัดวันประกันพรุ่ง และไม่รีบร้อนจนพลาด

วิดีโอนี้อธิบายสาเหตุทางระบบประสาทที่ทำให้เรามักจะยอมแพ้ในการทำเป้าหมายใหม่ๆ พร้อมกับวิธีแก้เพื่อสร้างความสม่ำเสมอ

3 ระยะของการเริ่มต้นทำสิ่งใหม่

เมื่อเราเริ่มทำสิ่งใหม่ (เช่น งานอดิเรก ทักษะ หรือโปรเจกต์) สมองและร่างกายจะพาเราผ่าน 3 ช่วงเวลาดังนี้:

1. ช่วงฮันนีมูน (The Honeymoon Phase)

อาการ: ช่วงแรกของการเริ่มทำอะไรใหม่ๆ เราจะรู้สึกตื่นเต้น มีไฟ และมีแรงจูงใจมหาศาล

วิทยาศาสตร์เบื้องหลัง: สมองหลั่ง "โดปามีน" (Dopamine) ออกมาเยอะมากเพื่อตอบสนองต่อ "ความแปลกใหม่" (Novelty) ในอดีต สมองใช้วิธีนี้เพื่อกระตุ้นให้บรรพบุรุษของเราออกไปสำรวจสิ่งใหม่ๆ (เช่น แหล่งอาหารใหม่) เพื่อความอยู่รอด

2. ช่วงตกต่ำ (The Dip Phase)

อาการ: ความตื่นเต้นหายไป สิ่งที่เคยสนุกกลายเป็นเรื่องน่าเบื่อ หรือ เป็นภาระที่ต้องฝืนใจทำ

วิทยาศาสตร์เบื้องหลัง: เมื่อสมองคุ้นเคยกับกิจกรรมนั้นแล้ว (ไม่มีอะไรแปลกใหม่ให้ตื่นเต้น) โดปามีนก็จะหลั่งน้อยลง ทำให้แรงจูงใจตกวูบ นี่คือจุดที่คนส่วนใหญ่มักจะล้มเลิก

มุมมองใหม่: ผู้เชี่ยวชาญมองว่า "The Dip" ไม่ใช่ปัญหา แต่เป็น "ตัวกรอง" ที่คัดกรองคนที่พร้อมจะอดทนออกจากคนที่ยอมแพ้ง่ายๆ

3. ช่วงกลายเป็นกิจวัตร (The Routine Phase)

อาการ: หากคุณฝืนทำต่อไปจนผ่าน The Dip มาได้ กิจกรรมนั้นจะกลายเป็นส่วนหนึ่งของชีวิต คุณสามารถทำได้อัตโนมัติโดยไม่ต้องใช้ความพยายามหรือพลังใจมาผลักดันอีกต่อไป

3 วิธีรับมือเมื่อเจอกับช่วง "The Dip"
เมื่อคุณรู้ตัวว่าความตื่นเต้นเริ่มหายไป ลองใช้ 3 วิธีนี้:

1. คาดการณ์ล่วงหน้า (Expect the dip): ตั้งสติก่อนเริ่มว่า “เดี๋ยวความตื่นเต้นนี้ก็จะหายไป” เมื่อถึงวันที่ขี้เกียจ คุณจะได้รู้ทันและไม่ใช้มันเป็นข้ออ้างในการล้มเลิก
2. ลดขนาดของเป้าหมายลง (Shrink the commitment): ในช่วงที่แรงจูงใจต่ำสุดขีด อย่าฝืนทำเต็มร้อย ให้ลดสเกลลงมาให้เล็กที่สุดจนสมองไม่ต่อต้าน เช่น แทนที่จะออกกำลังกาย 2 ชั่วโมง ก็ลดเหลือแค่ 30 นาที - กฎสำคัญ: “ทำได้แย่แตกลงมือทำ ย่อมดีกว่าตั้งใจทำอย่างเพอร์เฟกต์แต่สุดท้ายก็ไม่ได้ทำ”
3. เติมความแปลกใหม่ (Introduce novelty): หลอกล่อสมองให้กลับมาหลั่งโดปามีนด้วยการใส่ความแปลกใหม่ลงไปในกิจวัตรเดิมๆ เช่น เปลี่ยนสถานที่ทำงาน ลองเปลี่ยนสไตล์การออกกำลังกาย หรือเปลี่ยนอุปกรณ์ใหม่ๆ

ระวัง! 3 คำโกหกที่สมองสร้างขึ้นเมื่อคุณอยากล้มเลิก
เมื่ออยู่ในช่วง The Dip สมองจะหาเหตุผลร้อยแปดมาให้คุณหยุดทำ:

• คำโกหกที่ 1: “ฉันมันเป็นคนขี้เกียจ”
  • ความจริง: คุณไม่ใช่คนขี้เกียจเลย (ตอนเริ่มสัปดาห์แรกคุณโคตรขยัน!) มันแค่ปฏิกิริยาทางเคมีในสมองที่โดปามีนลดลง อย่าเอาคำว่า "ขี้เกียจ" มาตีกรอบตัวเอง
• คำโกหกที่ 2: “สิ่งนี้คงไม่เหมาะกับฉันหรอก”
  • ความจริง: เรามักจะตัดสินว่าอะไร "ไม่เหมาะ" กับเรา ก็ต่อเมื่อมันเริ่ม "ยาก" หรือ "เหนื่อย" ลองถามตัวเองดีๆ ว่ามันไม่เหมาะจริงๆ หรือเราแค่อยากหนีความลำบาก
• คำโกหกที่ 3: “งั้นไปเริ่มทำอย่างอื่นแทนดีกว่า”
  • ความจริง: นี่คือการหลอกลวงที่แนบเนียนที่สุด สมองแค่อยากหลอกให้คุณไปเริ่มโปรเจกต์ใหม่ เพื่อที่จะได้รับโดปามีนจาก "ช่วงฮันนีมูน" อีกครั้ง (เหมือนคนชอบความตื่นเต้นของการจีบกันใหม่ๆ แต่ทนความสัมพันธ์ระยะยาวไม่ได้)

บทสรุป:

คนที่ทำอะไรสำเร็จเป็นชิ้นเป็นอัน ไม่ใช่คนที่ไม่เคยเจอกับ The Dip หรือ ไม่เคยหมดไฟ แต่พวกเขา คือ คนที่เรียนรู้ที่จะ "ก้าวเดินต่อไปแม้ในวันที่ไม่อยากทำ" ต่างหาก

ทีนี้มาในช่วงนี้ที่เป็น challenge ใหญ่จาก ai ที่ใครๆ ก็สามารถสร้าง product ของตัวเองใช้ได้แล้ว

มีหลายอย่างที่เราต้องดู แต่ของพูดแค่เรื่อง unfair advantage อย่างเดียวก่อน.คำถามที่ทุกๆ บริษัทต้องตอบให้ได้ คือ unfair advantage ที่เรามีอยู่ตอนนี้ยังใช้ได้อยู่ไหม?

บริษัทแพลตฟอร์มที่ไม่กระทบการถูก disrupt จาก AI ได้หลังจากนี้ คือ บริษัทที่มี unfair advantage จริงๆ

แต่ก็ไม่ใช่ทุก unfair advantage ที่เป็นกำแพงแข็งแกร่ง บางตัวอาจจะถูก challenge แล้ว

Unfair ตัวไหนที่อยู่รอด

ในมุมของผมนะ หนึ่งใน unfair advantage ที่ยังทรงพลังอยู่ตอนนี้ คือ deal ใครที่มี deal ดีกว่าคนอื่น ก็ถือว่าได้ดีกว่า

เพราะเราไม่สามารถสั่ง AI ให้ไป deal กับ partner/provider ได้ ส่วนนี้คนต้องทำเอง และบาง deal

คนๆ เดียว ไม่อาจเข้าไปขอ deal จาก partner/provider ได้ ยกเว้นเขาจะสร้าง volume ของ deal นั้นได้เยอะจริงๆ ซึ่งมีน้อยคนที่ทำได้

อีกทั้งบาง deal ต้องอาศัย unfair อีกตัว คือ Location & Luck (สถานที่ และ บุญบารมี) ถึงจะได้

อีกหนึ่ง unfair ที่ทำให้เราเหนือคู่แข่ง สำหรับ product ที่ทำมาแล้ว และ ใช้ถ่วงเวลา คือ เงิน (Money) ถ้ามีมากพอที่จะเปลี่ยน business ตัวเองให้ไปกับ wave ของ ai ได้

Unfair ตัวไหนเสี่ยง

ส่วน unfair advantage ที่เสี่ยง คือ

Education & Expertise ถ้าไม่มี deep expert จริง ก็ยากที่จะสู้กับคลื่น AI เพราะ expert domain นั้น ai ไม่สามารถเข้าถึงได้ เพราะเป็นข้อมูลเฉพาะจริงๆ

รองลงมา คือ Intelligent & Insight ในมุมของ Intelligent โดน ai รุกคืบเข้ามาแล้ว แต่ยังมีเรื่องของ Insight ที่ยังพอยื้อได้อยู่ ด้วยเหตุผลเดียวกันกับ Expertise

ดังนั้นถึงเวลาที่ต้องกลับมาพิจารณาดูว่า unfair advantage ของเรานั้น ป้องกันคลื่น ai ได้หรือเปล่า

ถ้าป้องกันได้ก็มองหา solution ที่จะเอา unfair advantage นั้นไปใช้ให้เหมาะกับ ai

แต่ถ้าไม่ ก็ได้เวลา มองหา หรือ สร้าง unfair advantage ใหม่ๆ ได้เลย

แต่ Architecture Characteristics จะเป็นตัวที่บอกว่าระบบจะทำงานได้ดีแค่ไหน (How Well)

เปรียบเทียบก็เหมือนกับเราจะซื้อรถยนต์ Functional คือ รถต้องวิ่งได้ มี 4 ล้อ แอร์เย็น (ทุกคันทำได้เหมือนกัน)

แต่ Characteristics คือ รถคันนี้ประหยัดน้ำมันไหม (Performance/Cost), ปลอดภัยชนแล้วถุงลมกางไหม (Security/Reliability), หรือซ่อมง่ายหาอะไหล่ตามอู่ทั่วไปได้ไหม (Maintainability)

Architecture Characteristics (บางทีเรียก Quality Attributes หรือ NFR in architecture level) คือ คุณสมบัติของระบบที่สถาปัตยกรรมต้องรองรับ เพื่อให้ระบบอยู่ได้จริงใน production

มันคือคำที่ “ลึกกว่า NFR ทั่วไป” เพราะใช้เป็นตัวตัดสิน architecture design เลย

Characteristics ที่นิยมใช้

เราสามารถแบ่งออกมาได้เป็น 2 กลุ่มใหญ่ๆ คือ

1.ฝั่ง Operational (ขณะระบบทำงาน)

• Performance: ระบบต้องตอบสนองไว (เช่น โหลดหน้าเว็บใน 1 วินาที)
• Scalability: รองรับคนใช้งานเพิ่มขึ้นจาก 1,000 เป็น 100,000 คนพร้อมกันได้
• Availability: ระบบต้องเปิดตลอดยี่สิบสี่ชั่วโมง ห้ามล่ม (เช่น ระบบธนาคาร)
• Security: ป้องกันข้อมูลรั่วไหล และควบคุมสิทธิ์คนใช้งาน

2.ฝั่ง Structural (โครงสร้างหลังบ้าน/การพัฒนา)

• Maintainability: โค้ดอ่านง่าย แก้ไขบั๊กหรือปรับปรุงได้เร็ว ไม่กระทบส่วนอื่น
• Testability: เขียนเทสอัตโนมัติได้ง่าย มั่นใจได้ว่าแก้โค้ดแล้วระบบไม่พัง
• Deployability: เอาโค้ดใหม่ขึ้นระบบได้บ่อยและปลอดภัย (ทำ CI/CD ง่าย)

ถ้าจะลงรายละเอียดทั้งหมดจะเป็นตามภาพนี้

• Creational (วงกลมตัว C สีชมพู): เกี่ยวกับการสร้างและการขยายทรัพยากรของระบบ
• Structural (วงกลมตัว S สีชมพู): เกี่ยวกับโครงสร้างโค้ดและการจัดวางคอมโพเนนต์
• Behavioral (วงกลมตัว B สีชมพู): เกี่ยวกับพฤติกรรมการทำงานและการรับส่งข้อมูลของระบบ

เราจะหา Characteristics เจอได้ยังไง

เรามีหลากหลายวิธีในการค้นหา บางตัวลูกค้าจะเดินมาบอกเราตรงๆ (Explicit) เช่น ขอระบบเร็วๆ ไม่ล่ม แต่บางครั้งลูกค้าจะไม่พูดออกมา แต่ถ้าเราไม่ทำระบบจะมีปัญหาแน่ (Implicit) เช่น ระบบห้ามโดนแฮก, ห้ามล้ม เป็นต้น

Explicit vs. Implicit Characteristics

Explicit Characteristics ถูกเขียนหรือระบุไว้อย่างเป็นลายลักษณ์อักษรในความต้องการทางธุรกิจ (Requirements) หรือ ได้มาจากการพูดคุยกับผู้มีส่วนได้ส่วนเสีย (Stakeholders) โดยตรง มันจะจับต้องได้ และ มักจะมีตัวเลขชี้วัด (Metrics) ที่ชัดเจน

ลักษณะเด่น: มีระบุในเอกสารชัดเจน

ตัวอย่าง:

• Performance: ระบบต้องรองรับการกดจ่ายเงินและตอบกลับภายใน 2 วินาที
• Scalability: ระบบต้องรองรับผู้ใช้งานพร้อมกัน 50,000 คนในช่วงแคมเปญ 11.11
• Availability: ระบบต้องเปิดใช้งานได้ 99.99% (ล่มได้ไม่เกิน 52 นาทีต่อปี)

Implicit Characteristics ไม่มีใครเขียนบอกไว้ในความต้องการ แต่ในฐานะ Engineer สิ่งนี้ "จำเป็นต้องทำ" เพราะมัน คือ มาตรฐานขั้นต่ำที่ระบบที่ดีต้องมี

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

ลักษณะเด่น: ลูกค้า หรือ ฝ่าย business มักจะไม่พูดถึง (เพราะเขาคิดว่าเราต้องทำให้อยู่แล้ว) Engineer ต้องเป็นคนดึงมันออกมาเอง

เลือกแต่ละตัวลง domain ยังไง

การเลือกว่าแต่ละ domain ควรจะให้ความสำคัญเรื่องไหนบ้างนั้น ขึ้นอยู่กับแต่ละ domain เลย เพราะแต่ละ domain อาจให้ความสำคัญแต่ละเรื่องไม่เท่ากัน

เช่น

• payments: ให้ความสำคัญเรื่อง Availability, Security

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

1. Value สูงสุดของ Domain นี้ ในเชิงธุรกิจ คือ อะไร?

• ความน่าเชื่อถือของตัวเลขเงิน เลือก Security / Reliability
• ความเร็วในการส่งของให้ลูกค้า เลือก Performance

2. ถ้าสิ่งนี้พังหรือไม่มี ธุรกิจจะเจ๊งทันทีใช่หรือไม่?

• ถ้าระบบล่มไป 5 นาทีแล้วโดนปรับเป็นล้าน เลือก Availability
• ถ้าหน้าตาเว็บเปลี่ยนบ่อยทุกสัปดาห์ตามโปรโมชั่น แต่ล่มบ้างไม่เป็นไร เลือก Extensibility / Deployability

3. เรากำลังแข่งกับอะไร?

• แข่งกับเวลาและการตลาด (ต้องออกฟีเจอร์ใหม่ทุกสัปดาห์) เลือก Deployability / Maintainability
• แข่งกับจำนวนผู้ใช้งาน (คนแห่มาถล่มพร้อมกันช่วงสิ้นเดือน) เลือก Scalability / Elasticity

นี่น่าจะพอ guild ให้ได้ในระดับหนึ่งแล้ว

เมื่อเราได้ Architecture Characteristic แล้ว ต่อไปเราสามารถเอาไปเลือก Architecture Styles ได้

สมการความเก่ง: Model + Harness = AI Agent

เพื่อให้เห็นภาพง่ายที่สุด เราลองมาดูสมการที่สรุปความเป็น Agent ในยุคนี้กันครับ: Model (เครื่องผลิตข้อความ) + Harness (กฎและการกระทำ) = AI Agent

• Model: เปรียบเสมือน "เครื่องยนต์" (Engine) หรือสมองที่ประมวลผลความน่าจะเป็น มันเก่งเรื่องการคิดและเดาคำตอบถัดไป แต่ถ้าสมองไม่มีแขนขา มันก็ทำอะไรไม่ได้มากไปกว่าการตอบคำถาม
• Harness: เปรียบเสมือน "ร่างกาย" และ "พวงมาลัย" ที่ควบคุมสมองนั้นอีกที สำหรับเราแล้ว Harness คือส่วนผสมของ Infrastructure (เครื่องมือ/Sandbox) และ Rules (กฎการใช้เครื่องมือ) ที่กำหนดว่า Agent จะหยิบอะไรมาใช้ตอนไหน และจะจัดการกับข้อมูลอย่างไรให้ปลอดภัย

ถ้า Model คือเครื่องยนต์ที่มีพลังมหาศาล Harness ก็คือตัวถัง เบรก และระบบนำทางที่ทำให้รถวิ่งไปถึงเป้าหมายได้โดยไม่หลุดโค้งนั่นเองครับ

ก่อนจะมี Harness เราต้องเหนื่อยขนาดไหน?

ถ้าเราย้อนกลับไปช่วงปี 2023-2024 ยุคเริ่มต้นของ AI Agent เรายังไม่มีระบบ Harness ที่เป็นมาตรฐาน สิ่งที่เราทำกันตอนนั้นคือ "Manual Training" หรือการที่ เราต้องทำหน้าที่เป็นตัวกลาง (Middleman) คอยรับคำตอบจาก AI แล้วเอาไปรันเอง พอผลออกมายังไงก็ต้องส่ง Feedback กลับไปให้โมเดลดูอีกรอบ วนไปมาแบบนี้ด้วยมือเราเอง

ต่อมาในยุคของ AutoGPT หรือ BabyAGI เราเริ่มเห็นความพยายามทำให้ Agent ทำงานเองเป็นลูป (Loop) แต่เนื่องจากยุคนั้น "กฎ" (Guardrails) ยังไม่ชัดเจน เราจึงได้บทเรียนราคาแพง เช่น:

1. Infinite Loop: Agent วนทำงานซ้ำๆ ไม่รู้จบจน Token บานปลาย
2. Diving too deep: ดำดิ่งไปดึงข้อมูลที่ไม่เกี่ยวข้องมาเต็มไปหมดเพราะไม่รู้ว่าควรหยุดตอนไหน
3. Security Risk: เสี่ยงต่อการสั่งรันคำสั่งที่อาจทำลายระบบเพราะไม่มีกำแพงกั้น

Harness จึงเกิดมาเพื่อเปลี่ยนความไม่แน่นอน (Probabilistic) ของโมเดล ให้กลายเป็นระบบที่คาดเดาผลได้และปลอดภัย (Deterministic) มากขึ้นครับ

Harness vs. MCP vs. Skill: ต่างกันตรงไหน?

หลายคนอาจจะสงสัยว่า แล้วมันต่างจาก Protocol อย่าง MCP หรือการสอน Skill ยังไง?

เราสรุปความต่างมาให้ดูชัดๆ ครับ

9 องค์ประกอบที่ Agent Harness ที่ดีควรมี

การที่ Harness จะเปลี่ยนโมเดลธรรมดาให้กลายเป็น Agent ระดับโปรได้ มันต้องประกอบด้วย 9 ส่วนสำคัญนี้ครับ:

1. Loop Condition: การจัดการเมื่อทำงานไม่สำเร็จ จะ Retry กี่ครั้ง ถ้า Error ต้องแก้ท่าไหน
2. Context Management: ระบบบีบอัดข้อมูล (Context Compression) เหมือนที่ใช้ใน Cosee (Kho-Code) เพื่อให้ Agent ยังจำใจความสำคัญได้แม้คุยกันยาวจน Ram แทบเต็ม
3. Skill & Tool Management: การเตรียมเครื่องมือพื้นฐาน โดย Harness ที่เก่งจะรู้จักเครื่องมือผ่านไฟล์อย่าง Agent.md หรือ Skill.md ได้ทันทีโดยที่เราไม่ต้องเสียเวลา Prompt บอกมันทุกรอบ
4. Sub-agent Management: การแบ่งงานให้ Agent ย่อยช่วยทำงานเฉพาะทาง
5. Build-in Skills: คำสั่งพื้นฐานที่ติดมากับตัว เช่น File Edit หรือ Shell Execution
6. Session Persistence: การเก็บ Log และประวัติเพื่อให้ "Resume" งานเดิมต่อได้จากจุดที่ค้างไว้
7. System Prompt & Caching: การวางกฎเหล็กผ่าน Prompt และการใช้ Caching เพื่อความรวดเร็วและประหยัด
8. Lifecycle Hooks: จุดตรวจสอบสำคัญอย่าง Pre-run (เช็คก่อนเริ่ม) และ Post-run (ตรวจผลลัพธ์) เพื่อความแม่นยำ
9. Permission & Safety: การคุมขอบเขต Workspace Boundary เพื่อไม่ให้ Agent แอบไปอ่านไฟล์นอกพื้นที่ที่กำหนด และมีโหมดเลือกได้ว่าจะให้ลุยเลย (Yolo) หรือต้องขออนุญาตก่อน (Approval)

ส่องของจริง: เบื้องหลังการทำงานของ Harness ในเครื่องมือชื่อดัง

เพื่อให้เห็นภาพลึกถึงระดับ Code เราลองมาดู 2 กรณีศึกษานี้ครับ:

1. Codex: การจัดการแบบเป็นลำดับชั้น

Codex ใช้โครงสร้างที่ชัดเจนมากเพื่อให้งานออกมา Deterministic:

• Thread: Session ถาวรที่เก็บประวัติทั้งหมด
• Turn: 1 รอบคำสั่ง (User สั่ง -> Agent ทำจนจบ)
• Item: เลเวลย่อยของการใช้เครื่องมือ ซึ่งมีสถานะกำกับชัดเจนคือ Item Start, Item Streaming, และ Item Complete ทำให้เราติดตามได้ทุก Step ว่าตอนนี้ Agent กำลังอ่านไฟล์ (Read), คิดวิธีแก้ (Fix), หรือกำลังโชว์ความต่างของโค้ด (Diff)

2. Cosee (Kho-Code): ลูปการทำงาน 3 ระยะ

เครื่องมือตัวนี้ใช้คอนเซปต์ React (Reasoning + Action) อย่างเข้มข้น โดยแบ่งเป็น 3 ระยะ:

• Get Context: อ่านไฟล์ ค้นหาโค้ดใน Codebase
• Take Action: แก้ไขไฟล์ หรือรันคำสั่ง Command Line
• Verify Resource: รัน Test เพื่อตรวจสอบความถูกต้อง
• ความเทพ: Harness ของ Cosee สามารถทำ "Rewind" (ย้อนเวลาก่อนแก้ไฟล์) หรือ "Fork" เพื่อแตก Session ไปลองไอเดียใหม่ๆ ได้เหมือนการใช้ Git เลยครับ

อยากเริ่มทำ Harness ต้องทำยังไง? (3 Levels of Implementation)

สำหรับใครที่อยากจะเริ่มสร้างหรือปรับแต่ง Harness ของตัวเอง เราแบ่งแนวทางไว้ 3 ระดับ:

• Level 1 (User/Prompt Level): ใช้ Harness สำเร็จรูปอย่าง Cursor, Codex หรือ Cosee แล้วควบคุมพฤติกรรมผ่านไฟล์ .md หรือ System Prompt
• Level 2 (Framework Level): ขยับขึ้นมาเขียนสคริปต์ควบคุมเส้นทาง (Flow) เองโดยใช้เฟรมเวิร์กอย่าง LangGraph หรือ CrewAI
• Level 3 (Engineering Level): เขียนขึ้นมาจาก Scratch โดยใช้ SDK ของโมเดลโดยตรง (เช่น Anthropic SDK) โดยจุดสำคัญคือการเขียนฟังก์ชัน run_loop ขึ้นมาเองเพื่อจัดการ Token, จัดการการเรียกใช้ Tool และควบคุม Logic ทุกอย่างด้วยโค้ด 100%

ก้าวต่อไปของ Agent Engineering

สุดท้ายนี้ เราอยากให้ทุกคนจำไว้ว่า "Harness คือเบื้องหลังความเทพ" ที่แท้จริงครับ แม้ในอนาคตโมเดลจะฉลาดขึ้นจนเราอาจอธิบายกฎน้อยลงได้ แต่โครงสร้างการควบคุม (Infrastructure) และความปลอดภัยก็ยังเป็นหัวใจสำคัญที่ทิ้งไม่ได้ เพื่อไม่ให้ Agent ของเราเกิดอาการหลอน (Hallucination) หรือทำงานนอกลู่นอกทาง

การคุยแบบไม่มีโปรโตคอลเปรียบเสมือนการพยายาม Debug ระบบที่ไม่มี Log ผลลัพธ์ที่ได้มักจะเป็นความคลุมเครือ (Ambiguity) และ ความอึดอัดใจทั้งสองฝ่าย

ดังนั้นมันจะดีกว่าถ้าเราทำให้สิ่งเหล่านี้เคลียและชัดเจนขึ้น เราจำต้องปรับการให้ feedback ที่เป็นระบบอย่าง Performance Improvement Plan (PIP) มาใช้ ในฐานะเครื่องมือเชิงระบบเพื่อปรับจูน Performance ให้กลับมาอยู่ในค่า Parameter ที่คาดหวัง

PIP ในฐานะ System Interface: ทำไมการวิจารณ์ลอยๆ ถึง ล้มเหลว

การให้ Feedback ทั่วไป มักล้มเหลวเพราะขาด "Interface" ที่ชัดเจน พนักงานมักรู้สึกว่าถูกจ้องจับผิด (Criticism) มากกว่าการได้รับทางออก (Solution)

เราจึงต้องมอง PIP ใหม่ว่ามันไม่ใช่บทลงโทษ (Punishment) แต่ คือ Structured Opportunity

นอกจากนี้ PIP ไม่ได้มีไว้สำหรับ "Failure State" เท่านั้น

ในมุมมองของการวางระบบที่ยืดหยุ่น PIP คือ กระบวนการจัดการ State Transition ที่มีประสิทธิภาพ ไม่ว่าจะเป็นช่วงทดลองงาน (Probation) หรือ แม้แต่การเตรียมความพร้อมเพื่อเลื่อนตำแหน่ง (Promotion) ซึ่งต้องการการวัดผลที่เข้มข้นขึ้นกว่าปกติ

7 ขั้นตอนสู่การปรับจูนประสิทธิภาพ

เพื่อให้กระบวนการปรับจูนนี้มี Insight Density สูงสุด เราควรปฏิบัติแบบ Engineering Workflow ดังนี้:

1. การกำหนด Specification (Clear Goals): ระบุวัตถุประสงค์ที่วัดผลได้ (Deterministic Goals) เช่น "ลดอัตรา Bug Density ในโมดูลที่รับผิดชอบลง 20%" แทนการพูดกว้างๆ ว่า "เขียนโค้ดให้ดีขึ้น"
2. Bi-directional Handshake (Collaboration): สื่อสารสองทางเพื่อให้แน่ใจว่าทั้ง Lead และ Engineer เข้าใจเงื่อนไขการผ่านแผน (Success Criteria) และผลลัพธ์หากไม่ผ่าน (Termination) ตรงกัน
3. High-frequency Sampling (Regular Check-ins): สร้าง Feedback Loop ที่สม่ำเสมอ แทนการรอจนจบโปรเจกต์ การเช็คอินบ่อยๆ ช่วยให้ตรวจพบ Deviation ได้เร็วและแก้ไขได้ทันที
4. Blameless Root Cause Analysis (RCA): ค้นหาต้นตอที่แท้จริง เช่น ปัญหาส่วนตัว (External Interrupts) หรือการขาดทักษะเฉพาะทาง (Technical Debt ในตัวบุคคล) เพื่อจะได้แก้ที่ต้นเหตุ ไม่ใช่แค่แก้อาการ
5. Signal Integrity (Positive Communication): รักษาคุณภาพของสัญญาณสื่อสาร ย้ำเตือนว่านี่คือ "โอกาสสุดท้าย" ในการรักษาตำแหน่ง และองค์กรยังเห็นคุณค่าในตัวเขา มิเช่นนั้นคงไม่ลงทุนในกระบวนการ PIP
6. Resource Allocation (Support/Training): หากปัญหาเกิดจาก Skill Gap ต้องจัดหา "Library" หรือทรัพยากรที่จำเป็น เช่น Mentor หรือคอร์สฝึกอบรม เพื่อช่วยให้เขาบรรลุ Performance Specs
7. System Termination/Exit Protocol (Clear Consequences): หาก Error Threshold ยังสูงเกินกว่าที่ตกลงกันไว้หลังจบแผน ต้องมีความโปร่งใสเรื่องผลที่ตามมา (เช่น ย้ายตำแหน่ง หรือเลิกจ้าง) อย่างตรงไปตรงมาตั้งแต่วันแรก

ตัวอย่างการประยุกต์ (Quality Assurance Example)

• เป้าหมาย: เพิ่ม Code Review Throughput และลด Re-work
• การดำเนินการ: กำหนดให้ Engineer ต้องตรวจเช็ค Checklist พื้นฐานก่อนส่ง Pull Request และเข้าร่วม Pairing Session กับ Senior สัปดาห์ละ 2 ครั้ง
• ตัวชี้วัด: อัตราการตีกลับของ PR ต้องลดลงเหลือไม่เกิน 15% ภายในระยะเวลา 30 วัน

Trade-offs: การรักษาคน (Retention) vs. การสร้างระบบใหม่ (Re-hiring)

ในมุมมอง Software Economics การใช้ PIP คือ การ "Refactor" ทรัพยากรมนุษย์ที่มีอยู่ ซึ่งมักจะคุ้มค่ากว่าการ "Re-write" หรือ รับคนใหม่เสมอ เพราะการเลิกจ้างมีต้นทุนแฝง (Hidden Costs) ที่สูงมาก

• Context Loss: ความรู้ใน Domain และ System Architecture ที่หายไปพร้อมกับคนเก่า
• Onboarding Latency: ระยะเวลาอย่างน้อย 3-6 เดือนกว่าคนใหม่จะเริ่มสร้าง Value ได้เต็มที่
• Recruitment Overhead: ค่าใช้จ่ายในการสัมภาษณ์ การประกาศงาน และค่าเสียโอกาสของทีมที่ต้องสละเวลามาเทรนคนใหม่

การลงทุนกับ PIP จึงเป็นการประหยัดทรัพยากรในระยะยาว หากพนักงานผ่าน PIP มาได้ พวกเขามักจะกลายเป็น "Robust Components" ที่เข้าใจความคาดหวังของระบบอย่างถ่องแท้

Risk Assessment: ข้อควรระวังและการจัดการ Compliance

ผู้นำทีมต้องตระหนักว่า PIP มีความเสี่ยง และ การจัดการที่ซับซ้อนไม่ต่างจากการรัน Migration สำคัญ

• System Pressure: กระบวนการนี้สร้างความกดดันสูง อาจส่งผลให้ Performance ส่วนอื่นๆ ตกต่ำลงชั่วคราว
• Resignation Risk: พนักงานอาจมองว่านี่ คือ Exit Sign และ ตัดสินใจ Terminate ตัวเองก่อนจบแผน
• Audit-Ready Documentation (Legal Compliance): การทำ PIP ต้องมีความละเอียดสูงเหมือนการเตรียมเอกสาร SOC2 หรือ ISO ทุกขั้นตอนต้องเป็นลายลักษณ์อักษร เพื่อป้องกันความเสี่ยงทางกฎหมาย หากต้องจบลงด้วยการเลิกจ้างจริง

บทสรุป: PIP ในฐานะเครื่องมือสร้าง System Reliability

เป้าหมายสูงสุดของ PIP คือการสร้าง Accountability Culture ที่พนักงานทุกคนตระหนักถึงมาตรฐานที่ระบบต้องการ ผู้นำที่มีวุฒิภาวะจะมองว่างานของเขาไม่ใช่แค่การเขียน Code แต่คือการรักษาความเสถียรของ Human Infrastructure

จงมองพนักงานในทีมเป็นส่วนประกอบสำคัญของระบบที่ต้องการการซ่อมบำรุง (Maintenance) และการปรับจูน (Optimization) PIP คือ Maintenance Script ที่ถูกเขียนขึ้นมาเพื่อรักษาเสถียรภาพของทีม ไม่ใช่คำสั่ง Delete เพื่อกำจัดอะไหล่ทิ้งเมื่อเกิดปัญหา วัฒนธรรมที่กล้าเผชิญหน้ากับความจริงด้วยระบบที่ชัดเจน จะเป็นรากฐานของทีมวิศวกรรมที่แข็งแกร่งและยั่งยืนอย่างแท้จริง

จุดเริ่มต้นของยุค "Oh F***": เมื่อวิศวกรรมไม่ใช่แค่การเขียนโปรแกรม

โลกของการพัฒนาซอฟต์แวร์เปลี่ยนไปตั้งแต่วันที่ AI เริ่มเข้ามามีบทบาท แต่จุดเปลี่ยนที่แท้จริงคือสิ่งที่ Jeff เรียกว่า "Oh F*** moment" ซึ่งสำหรับเขา มันเกิดขึ้นเมื่อ 2 ปีที่แล้วผ่านงานวิจัย "Cursed" agent ที่ทำงานต่อเนื่องได้นานถึง 3 เดือน

เขาบอกว่าเราต้องสร้างความชัดเจนว่า เราต้องแยกให้ออกระหว่าง 'Software Development' และ 'Software Engineering'

การมี iPhone ไม่ได้ทำให้คุณเป็นช่างภาพงานแต่งมืออาชีพฉันใด การใช้ AI เขียนโค้ดได้ก็ไม่ได้ทำให้เราเป็นวิศวกรฉันนั้น

แต่มันกำลังทำให้ "ทุกคน" กลายเป็น Developer ได้ในชั่วข้ามคืน และสำหรับใครที่ยังไม่ตระหนักถึงความเปลี่ยนแปลงนี้ในปี 2024 เตรียมตัวพบกับ "Oh F*** moment" ของจริงในปี 2026 แล้วก็เราตามโลกไม่ทันอีกต่อไป

เศรษฐศาสตร์ที่พังทลาย: ซอฟต์แวร์ราคาถูกกว่าค่าแรงขั้นต่ำ

หัวใจสำคัญที่ผู้นำธุรกิจต้องตระหนัก คือ "Unit Economics" ของซอฟต์แวร์ได้เปลี่ยนไปตลอดกาล ปัจจุบันการรัน Agent เพื่อพัฒนาซอฟต์แวร์ผ่าน Frontier Model มีต้นทุนเพียง $10.42 ต่อชั่วโมง และมันทำงานในขณะที่เรากำลังหลับด้วย

แต่สิ่งที่น่าตกใจยิ่งกว่า คือ "รสนิยม" ในการเลือกใช้เครื่องมือ

Jeff ชี้ให้เห็นว่าเครื่องมืออย่าง Claude Code นั้นกิน Token มหาศาลราวเหมือนการดื่มรวดเดียวอึกใหญ่

ในขณะที่โมเดลอย่าง Pi นั้น มีประสิทธิภาพสูงกว่ามาก และหากเราใช้โมเดลอย่าง GLM ต้นทุนจะลดลงเหลือเพียง "ไม่กี่เซ็นต์ต่อชั่วโมง" (Cents to the hour)

Software development now costs less than minimum wage. It’s a provocative title. It’s meant to be.

นี่ คือ เหตุผลที่โครงสร้างธุรกิจแบบเดิมกำลังตายลง แม้แต่ในแวดวง Venture Capital

คำถาม คือ "เราจะระดมทุน Seed Capital ไปทำไม?" ในเมื่อยุคก่อนเราขอเงินเพื่อไปจ้างวิศวกรราคาแพง แต่ในวันนี้เราสามารถสร้างผลิตภัณฑ์ได้ด้วยตัวคนเดียวผ่าน Coding Agent ได้แล้ว

Knowledge Abundance และ "K-Shape Economy"

เรากำลังเปลี่ยนจากยุค "ความรู้ขาดแคลน" ไปสู่ยุค "ความรู้ล้นเหลือ" (Knowledge Abundance) ซึ่งทำให้โครงสร้างองค์กรแบบเดิมกลายเป็นภาระ

Jeff ยกตัวอย่าง SAP Concur แอปจัดการค่าใช้จ่ายที่ใช้คนถึง 6,800 คน เขาเรียกสิ่งนี้ว่าการสร้างองค์กรด้วย "Human Meat Bags" และ การประชุมที่ไร้ประสิทธิภาพ ซึ่งเป็นระบบปฏิบัติการที่ต่อต้าน AI (Anti-AI Operating System)

โลกกำลังแยกเป็น 2 ทางในแบบ K-Shape Economy:

• ด้านบนของ K: คือกลุ่ม "Shippers" ที่ใช้คนน้อยแต่สร้างผลลัพธ์มหาศาล
• ด้านล่างของ K: คือองค์กรที่ติดหล่มอยู่ใน "J-shaped people transformation" ที่พยายามเปลี่ยนคนแต่ช้าเกินไป

คำแนะนำของ Jeff ที่โคตรโหดและโคตรตรง คือ...

Yeet them. They are your token budget.

หากพนักงานคนไหนไม่ยอมขึ้นรถไฟขบวน AI หลังจากผ่านไป 2 ปี พวกเขา คือ ภาระต้นทุนที่เราควรตัดออก เพื่อนำงบประมาณไปลงกับ Token แทน

ทักษะวิศวกรรมที่แท้จริง คือ การ "สร้าง Agent"

วิศวกรซอฟต์แวร์ในอนาคตไม่ใช่คนที่มานั่งพิมพ์โค้ด แต่ คือ คนที่เข้าใจการสร้าง Agent Loop

Jeff เปรียบเทียบ การใช้ AI เปรียบเสมือนการเล่นเครื่องดนตรี ที่ต้องอาศัยการฝึกฝนอย่างหนัก (Deliberate Practice) เพื่อให้เกิด "Taste" ในการควบคุมผลลัพธ์

Jeff ยืนยันว่าการสร้าง Agent ไม่ใช่เรื่องไกลตัว เขามีเวิร์กชอปบน GitHub ที่มีคนกด Star ให้เขาเกือบ 6,000 star

ซึ่งพิสูจน์ว่า เราสามารถสร้าง Coding Agent เองได้ในโค้ดเพียง 300 บรรทัด โดยมีวงจรพื้นฐานคือ:

User input -> Array (Memory) -> Inferencing -> Tool execution

การที่ Bun ถูกพอร์ตจากภาษา Zig ไปเป็น Rust ได้ภายใน 6 วันด้วย Agent คือ เครื่องพิสูจน์ว่า ภาษาโปรแกรมกำลังกลายเป็นสิ่งทดแทนกันได้ (Fungible)

สิ่งที่สำคัญกว่า คือ ความสามารถของ ความเป็น Engineer ไม่ใช่จำนวนปีที่เขียน Java หรือ Ruby

The Lethal Trifecta: ภัยเงียบมูลค่าพันล้านเหรียญ

ในโลกของ Automation มีภัยคุกคามที่ยังไม่มีใครแก้ได้ ซึ่ง Jeff เรียกว่า "Lethal Trifecta" ของการทำ Prompt Injection

หากเราเชื่อมต่อสิ่งเหล่านี้...

• Untrusted Input (ข้อมูลจากภายนอกที่ไม่น่าเชื่อถือ)
• Private Data Source (ฐานข้อมูลส่วนตัวขององค์กร)
• Exfiltration Ability (ความสามารถในการส่งข้อมูลออก)

สิ่งนี่ คือ ช่องโหว่ร้ายแรงที่จะทำให้องค์กรถูกเจาะข้อมูลผ่าน AI Agent

Jeff กล่าวว่าใครก็ตามที่แก้ปัญหานี้ได้ จะถือครองขุมทรัพย์มูลค่านับพันล้านเหรียญเลยก็ว่าได้

จุดจบของ Open Source และ กลยุทธ์ "Crash Cart"

แนวคิดที่สวนทางกับความเชื่อเดิมที่สุด คือ "Open Source อาจไม่จำเป็นอีกต่อไป" ในยุค AI เราควรหันมาใช้ First-party Generation หรือ การสร้าง Dependency ขึ้นมาเองตามความต้องการ เพื่อหลีกเลี่ยง Supply Chain Attack และ เพื่อให้เราสามารถควบคุมการวิวัฒนาการของโค้ดได้ 100%

นอกจากนี้ วิศวกรต้องสร้าง "Back pressure" ให้กับการ generate โค้ดของ AI โดยการเลือกใช้ภาษาที่มีระบบ Type แข็งแกร่งอย่าง Rust หรือ Haskell

เขายกตัวอย่างเปรียบเทียบกับ Data Center ที่ไม่มีจอมอนิเตอร์

ถ้าเซิร์ฟเวอร์พัง เราต้องขับรถไปที่นั่น เพื่อเชื่อมต่อ Crash Cart (รถเข็นฉุกเฉิน) เข้ากับเครื่องเพื่อกู้คืนระบบ ซึ่งมันน่าเบื่อและเสียเวลา

ในโลกของ Software Factory หน้าที่ของ Engineer คือ การใช้ Compiler ที่เข้มงวด เพื่อปฏิเสธ "อาการหลอน" (Hallucination) ของ AI ให้ได้มากที่สุด เพื่อลดจำนวนครั้งที่เราต้องเข้าไปต่อ "Crash Cart" หรือ เข้าไปแก้ไขงานที่ Agent ทำพังด้วยมือนั่นเอง

บทสรุป: เมื่อ Ideas คือ Execution

ในอดีตเรามักพูดว่า...

ไอเดียนั้นไร้ค่า การลงมือทำสำคัญที่สุด

แต่ในวันนี้ เมื่อ AI ย่อระยะเวลาการลงมือทำ (Execution) ให้สั้นลงจนเกือบเป็นศูนย์

"ไอเดียที่ดี" จึงกลายเป็นสิ่งที่หายากและมีค่าที่สุด

คุณค่าที่แท้จริงของเราในฐานะวิศวกรไม่ได้อยู่ที่การจดจำ Syntax อีกต่อไป

แต่อยู่ที่ระดับความสามารถ (Caliber) ในการออกแบบระบบ และความกระหายที่จะเรียนรู้สิ่งใหม่ ภาษาโปรแกรมเป็นเพียงแค่เครื่องมือที่เปลี่ยนผ่านได้ แต่ "รสนิยมทางวิศวกรรม" คือสิ่งที่จะทำให้เราอยู่รอด

Reference:

https://ghuntley.com/