ยุค 1: Henry Gantt (1910s) — กำเนิดของแผนภูมิ#

Henry Gantt เป็น mechanical engineer ชาวอเมริกัน ลูกศิษย์ของ Frederick Taylor (พ่อของ scientific management) เขาออกแบบ Gantt chart ตั้งแต่ปี 1910s เพื่อใช้ใน:

• งาน ordnance (อาวุธ) ของ US Army ตอน WW1
• โปรเจค Hoover Dam (1931-1936)

Gantt chart คืออะไร? แผนภูมิแท่งแนวนอน — แกนนอน = เวลา, แกนตั้ง = งาน, ความยาวแท่ง = ระยะเวลา

ฟังเหมือนง่าย แต่ก่อนหน้านั้น ไม่มีใครคิดว่าจะ visualize เวลาแบบนี้ — โครงการใหญ่ใช้ตารางตัวเลขล้วน อ่านยาก เห็นภาพยาก

เกร็ด: จริงๆ Karol Adamiecki ชาวโปแลนด์ออกแบบ “harmonogram” คล้าย Gantt chart ตั้งแต่ 1896 แต่เผยแพร่เป็นภาษาโปแลนด์/รัสเซีย — ฝั่งตะวันตกเลยให้เครดิต Gantt

ยุค 2: Manhattan Project (1942-1945) — กำเนิดของ “program management”#

Manhattan Project — โปรเจคพัฒนาระเบิดปรมาณูช่วงสงครามโลกครั้งที่ 2

ตัวเลข:

• คน 130,000 คน
• งบ $2 พันล้าน (เงินยุค 1940s — ถ้าคิดเป็นปัจจุบัน หลายแสนล้าน)
• 3 technology track ขนานกัน (uranium enrichment, plutonium, weapon design)
• Site หลัก 3 ที่ (Los Alamos, Oak Ridge, Hanford)

นี่คือ โปรเจคใหญ่ที่สุดในประวัติศาสตร์มนุษย์ ณ เวลานั้น ขนาดที่ไม่มีใครเคยจัดการมาก่อน

ผลลัพธ์: ระเบิด Hiroshima/Nagasaki ใช้งานได้จริงในเวลาแค่ 3 ปี

สิ่งที่ Manhattan Project ทิ้งไว้ให้โลก: แนวคิด “program of projects” — โปรเจคใหญ่เกินที่จะจัดการเป็นโปรเจคเดียว ต้องแยกเป็น sub-projects ขนานกัน + มี program manager ดูภาพรวม

ยุค 3: 1957-1958 — กำเนิดของ CPM และ PERT#

ปี 1957-1958 เกิดเครื่องมือ 2 อันที่เปลี่ยนวงการ PM ตลอดกาล

ยุค 4: 1970 — Royce paper + กำเนิด “Waterfall” (โดยไม่ตั้งใจ)#

Winston Royce เผยแพร่ paper ชื่อ “Managing the Development of Large Software Systems” ในปี 1970

ใน paper เขาวาด diagram ที่แสดง software development เป็นขั้นตอน sequential:

1. System Requirements
2. Software Requirements
3. Analysis
4. Program Design
5. Coding
6. Testing
7. Operations

ขั้นถัดไปทำหลังขั้นก่อนเสร็จ — เหมือนน้ำตกไหลลงเขา เลยถูกเรียกว่า “Waterfall”

Twist ที่ตำราไม่ค่อยเล่า: Royce ไม่ได้บอกว่าทำงี้ดี เขาบอกในประโยคถัดมาว่า:

“I believe in this concept, but the implementation described above is risky and invites failure.”

แล้วเขา recommend ให้ทำ iterative + early prototyping — แต่ DoD (กระทรวงกลาโหมสหรัฐ) เอาแค่ diagram ไปใช้ ลืม caveat

1985 — DoD-STD-2167 บังคับใช้ Waterfall ในโปรเจค defense ทั้งหมด → กลายเป็น industry standard ทั่วโลกเป็นทศวรรษ

ยุค 5: 1975 — Mythical Man-Month + Brooks’ Law#

Fred Brooks เคยเป็น manager ของ IBM OS/360 (operating system ใหญ่ของ mainframe ยุค 60s)

หลังจัดการโปรเจคนี้แล้ว Brooks เขียนหนังสือ The Mythical Man-Month (1975) เป็นหนังสือเล่มสำคัญที่สุดในประวัติศาสตร์ PM ของ software

Brooks’ Law (กฎเหล็กของ PM):

“Adding manpower to a late software project makes it later.”

แปลว่า: โปรเจคที่ช้าอยู่แล้ว ถ้าเพิ่มคน → ช้าลงอีก

ทำไม?

1. Onboarding time — คนใหม่ต้องใช้เวลาเรียนรู้ก่อนทำงานได้ — คนเก่าต้องสอน
2. Communication overhead — n คน มี n×(n-1)/2 channels ของการคุย — เพิ่มคน 1 = เพิ่ม channel หลายเส้น
3. Sequential constraint — บางงาน split ไม่ได้

Quote ที่ Brooks ทิ้งไว้:

“The bearing of a child takes nine months, no matter how many women are assigned.”

(การคลอดลูกใช้ 9 เดือน ไม่ว่าจะใส่ผู้หญิงกี่คน — บางอย่าง parallel ไม่ได้)

ยุค 6: 1986-1995 — Iterative methods เริ่มโผล่#

ก่อน Agile จะกำเนิด มีคนพยายามแก้ Waterfall มาเรื่อยๆ:

1986 — Spiral Model โดย Barry Boehm — ทำ iteration ตามรอบ risk-driven

1986 — “The New New Product Development Game” ใน Harvard Business Review โดย Takeuchi + Nonaka — ใช้ metaphor “rugby scrum” อธิบายว่าทีม cross-functional ที่วิ่งไปด้วยกันเร็วกว่า

1989 — PRINCE2 ของรัฐบาล UK

1993 — Jeff Sutherland รัน Scrum ทีมแรกที่ Easel Corp

1995 — Schwaber + Sutherland present Scrum ที่ OOPSLA conference

แต่ทั้งหมดนี้ยังเป็น niche — software ส่วนใหญ่ยังเป็น Waterfall

ยุค 7: 2001 — Agile Manifesto#

กุมภาพันธ์ 2001 — 17 software practitioners ไปประชุมที่ skiing resort ชื่อ Snowbird, Utah

ใครบ้าง: Kent Beck, Martin Fowler, Jeff Sutherland, Ken Schwaber, Ward Cunningham, Jim Highsmith, Andrew Hunt, Robert Martin (Uncle Bob), Dave Thomas, ฯลฯ

ทำไมเจอกัน: ทุกคนเบื่อ Waterfall + DoD-STD-2167 ที่ทำให้ software project ใหญ่ๆ ล้มเหลวทศวรรษแล้วทศวรรษเล่า

ผลลัพธ์: Agile Manifesto — เอกสารแค่ 4 ประโยค + 12 หลักการ

4 ค่านิยมหลัก:

1. Individuals and interactions > processes and tools
2. Working software > comprehensive documentation
3. Customer collaboration > contract negotiation
4. Responding to change > following a plan

(ฝั่งซ้ายมาก่อน แต่ฝั่งขวาก็มีค่า — ไม่ได้ทิ้ง)

นี่คือ moment ที่ software industry แตกเป็นสอง — Waterfall vs Agile

ยุค 8: 2010s — Scaled Agile + DevOps#

หลัง 2001 Agile กระจายไปทั่ว — แต่ปัญหาใหม่เกิด: Agile scale ขึ้นยังไงในบริษัท 1,000 คน?

ตอบ: เกิด framework สำหรับ scale Agile ขึ้นมา

• 2011 — SAFe (Scaled Agile Framework) โดย Dean Leffingwell
• 2014 — LeSS (Large-Scale Scrum) โดย Larman + Vodde
• 2012 — Spotify Model (squads, tribes, chapters, guilds — แม้แต่ Spotify เองก็ไม่ใช้แล้ว แต่บริษัทอื่นเอาไปใช้)

2009-2014 — DevOps — Patrick Debois ตั้งคำว่า DevOps ปี 2009, Gene Kim เขียน The Phoenix Project ปี 2013 — รวมงาน Dev + Ops เข้าด้วยกัน เน้น automation + frequent deployment

2018 — DORA metrics (Forsgren/Humble/Kim ใน Accelerate) — 4 metrics ที่บอกว่าทีม software performant แค่ไหน:

1. Deployment Frequency
2. Lead Time for Changes
3. Change Failure Rate
4. Mean Time to Restore (MTTR)

Timeline สรุป#

Pattern ที่เห็นในประวัติศาสตร์#

ลองดู — เครื่องมือ PM ใหม่ๆ เกิดเมื่อ:

1. โปรเจคใหญ่ขึ้นเกินที่เครื่องมือเดิมรับมือ (Manhattan, Polaris)
2. ราคาของการพลาดสูงเกินยอม (defense, healthcare, aerospace)
3. เครื่องมือเดิมล้มเหลวซ้ำๆ (Waterfall ล้มเหลวในศ. Software → Agile)
4. Tech ใหม่เปลี่ยน playing field (cloud → DevOps)

นี่คือเหตุผลที่ EP ถัดๆ ไป จะเล่าเครื่องมือต่างๆ ตาม ขนาดทีม — เพราะปัญหาที่ขนาดต่างกันเรียกร้องเครื่องมือต่างกัน