#priwreadarticles Milestone-Kanban การจัดตารางเวลา และการจัดการโครงการแบบผสมผสาน โดย Alan Zucker

3 min readMar 1, 2023

เนื้อหาในบทความนี้แปลและสรุปจาก Milestone-Kanban: A hybrid project scheduling technique

Milestone-Kanban Schedule (MKS) คือ การจัดตารางเวลา และการจัดการโครงการแบบผสมผสาน ระหว่างแนวทางปฏิบัติแบบดั้งเดิม (Traditional) และแบบ Agile

มีวัตถุประสงค์เพื่อช่วยผู้จัดการโครงการ ทำงานในปัญหาที่ซับซ้อน หลีกเลี่ยงข้อผิดพลาดที่เกี่ยวข้องกับการจัดการแบบดั้งเดิม ช่วยสร้างแผนงานของการส่งมอบ จากนั้นใช้ Kanban/stand-up เพื่อจัดการการดำเนินการในโครงการ

เทคนิคนี้เหมาะสำหรับโครงการที่

ต้องการ การส่งมอบที่ชัดเจน (deliverables)
แต่ เวลา (time) และกำลัง/ความพยายามที่จะทำให้เสร็จ (effort) ในการสร้างสิ่งที่จะส่งมอบนั้นยังไม่ชัดเจน

ซึ่งใช้การทำงานเป็นรอบ โดยใช้ milestones ในการกำหนดแผนงานโครงการ (project roadmap) บอร์ดคัมบังเพื่อจัดการงาน และใช้ stand-up meetings เพื่อติดตามความคืบหน้า (track progress)

เทคนิคการจัดการโครงการแบบดั้งเดิม (Traditional)

ใช้การแบ่งงาน (WBS) แผนภูมิแกนต์ (Gantt charts) และเส้นทางวิกฤต (critical path) เพื่อสร้างกำหนดการของโครงการ
สมมติฐานว่า งานนี้มีการกำหนดไว้อย่างดี สามารถประเมินความพยายามที่จะทำให้เสร็จได้อย่างง่าย ถือเป็นข้อบกพร่องของแนวทางนี้
กระบวนการติดตามและการรายงาน (Monitoring and reporting) มีความซับซ้อนและกลายเป็นตัวชี้วัดที่ล้าหลัง

โครงการแบบอไจล์

ใช้การส่งงานเป็นรอบๆ และเพิ่มขึ้นในแต่ละรอบ (iterative and incremental) ช่วยให้มีความยืดหยุ่น
พวกเขาไม่ต้องการ (แต่อาจใช้) แผนงาน เพื่อสื่อสารและกำหนดความคาดหวังสำหรับงานในอนาคต
ทีมใช้เครื่องมือการรายงานด้วยภาพ (visual reporting tools) ที่เข้าถึงได้ง่ายและอัปเดตสถานะทุกวัน ซึ่งส่งเสริมความโปร่งใส

Milestone-Kanban

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

เทคนิคนี้ใช้กระบวนการง่ายๆ ห้าขั้นตอน ได้แก่

Step 1: Define the Deliverables กำหนดสิ่งที่ต้องส่งมอบ
Step 2: Create a Roadmap สร้างแผนงาน
Step 3: Build the Kanban สร้างคัมบังบอร์ด
Step 4: Monitor Progress ตรวจสอบความคืบหน้า
Step 5: Plan Iteratively วางแผนซ้ำๆ

Step 1: Define the deliverables

แนวทางการจัดการโครงการแบบดั้งเดิม เริ่มต้นด้วยการกำหนดขอบเขตของงานว่าจะส่งมอบอะไร ซึ่งจะสร้างความคาดหวังด้านประสิทธิภาพที่เฉพาะเจาะจงและสามารถวัดผลได้

ขั้นตอนที่ 1a: รวบรวมข้อกำหนด

ระบุผู้มีส่วนได้ส่วนเสียและเข้าใจความต้องการของพวกเขา
เป็นกระบวนการทำซ้ำ ที่ความต้องการระดับสูง (high-level) ได้รับการอธิบายอย่างละเอียดในขั้นต้น
ข้อกำหนดที่มีรายละเอียดมากขึ้น จะถูกกำหนดในภายหลัง
สามารถรวบรวมข้อกำหนดผ่านการประชุมระดมความคิด การสนทนากลุ่ม การสำรวจ การสังเกต และการวิเคราะห์กฎระเบียบและมาตรฐาน
สามารถบันทึกความต้องการไว้ในเอกสาร สเปรดชีต โพสต์อิทโน้ต หรือเครื่องมือ ที่ใช้จัดการ application lifecycle management (ALM)

ขั้นตอนที่ 1b: กำหนดขอบเขตสิ่งที่ทีมจะทำ

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

ขั้นตอนที่ 1c: กำหนดสิ่งที่จะส่งมอบ

สิ่งที่ทีมจะส่งมอบ เป็นสิ่งที่จับต้องได้ หรือจับต้องไม่ได้ก็ได้ ที่จะตอบความต้องการภายในโครงการ คือความต้องการของลูกค้าภายนอก
ขอบเขตโครงการ (project scope) เป็นสิ่งที่จับต้องไม่ได้ ส่งมอบภายใน
prototype เป็นสิ่งที่จับต้องได้ ส่งมอบภายนอก

work breakdown structure (WBS) ใช้แยกย่อยงานในโครงการและแสดงในรูปแบบแผนภูมิลำดับชั้นหรือโครงร่าง (outline)

รายละเอียดระดับต่ำสุดใน WBS คือ Work packages ที่มีขนาดเล็กพอที่จะประเมินและมอบหมายงานให้คนทำได้ ส่วน Planning packages คือรายการที่ใหญ่กว่า ซึ่งจะถูกแยกย่อยเป็น Work packages ในภายหลัง

Step 2: Create a roadmap

กำหนดการของโครงการแบบ Traditional ใช้ milestones ทำเครื่องหมายบอกความสำเร็จหรือเหตุการณ์สำคัญ

ส่วนทีม Agile มักจะสร้าง roadmaps เพื่อร่างแผนงานระดับสูง (high-level) ที่คล้ายคลึงกัน

Milestone-Kanban Schedule (MKS) สร้างแผนงานที่แสดง milestones สำคัญและสิ่งที่ส่งมอบ พร้อมวันที่เสร็จสิ้นโดยประมาณ วันที่เหล่านี้อาจเป็นข้อกำหนดภายนอก หรือขึ้นอยู่กับการประมาณการระยะเวลาแบบ high-level

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

roadmaps สามารถสื่อสารได้โดยใช้เครื่องมือและรูปแบบต่างๆ เช่น โพสต์อิทโน้ตบนผนังหรือใน virtual tool เช่น สเปรดชีต presentation หรือเครื่องมือจัดการกำหนดการโครงการ สามารถเพิ่มเส้นเชื่อมโยงเพื่อแสดงการพึ่งพาระหว่างกันได้ ใช้รหัสสี และ swim lanes เพื่อจัดระเบียบเหตุการณ์สำคัญและสิ่งที่ส่งมอบโดยเจ้าของ (owner), workstream, ผลิตภัณฑ์ ฯลฯ นอกจากนี้ยังสามารถระบุวันที่ส่งมอบ และข้อมูลอื่นๆ ลงไปได้ด้วย

Step 3: Build the Kanban board

Kanban เป็นเครื่องมือการจัดการสินค้าคงคลังแบบลีนที่พัฒนาโดย Toyota และนำไปใช้อย่างกว้างขวางโดยทีม Agile ส่วนใหญ่

Kanban ช่วยให้ทีมเห็นภาพการทำงาน

Step 3a: Identify tasks

ระบุกิจกรรม หรืองานจำเป็นที่จะต้องทำ เพื่อการส่งมอบที่จะเกิดขึ้น
ระดับของรายละเอียดจะขึ้นอยู่กับขนาดโครงการ ความซับซ้อน และวุฒิภาวะของทีม
งานบางอย่างอาจมีสิ่งที่ต้องทำก่อนหน้า

Step 3b: Build the Kanban board

Kanban board เป็นเครื่องมือการจัดการ เพื่อติดตามการไหลของงาน สามารถใช้เพื่อติดตามการส่งมอบงานได้
คอลัมน์โดยทั่วไปแสดงถึงขั้นตอนของกระบวนการทำงาน สามคอลัมน์พื้นฐานคือ To Do, Doing (กิจกรรมที่กำลังดำเนินการอยู่), Done (รายการที่เสร็จสมบูรณ์)
Backlog เป็นรายการ ที่ถูกเรียงลำดับความสำคัญของงานที่จะเกิดขึ้น
เป็นเครื่องมือที่ยืดหยุ่น สามารถปรับแต่งให้เหมาะกับความต้องการเฉพาะของโครงการได้
คอลัมน์ Doing สามารถแบ่งออกเป็นหลายขั้นตอน การ์ดงานสามารถใส่รหัสสีเพื่อระบุการมอบหมายงานหรือผลงานที่ส่งมอบได้ สามารถใช้แถวเพื่อจัดกลุ่มงานได้

Step 3c: Mature the practice

การจำกัดจำนวนรายการงานระหว่างดำเนินการ และการดึงงาน ช่วยลดการทำงานหลายอย่างพร้อมกัน ช่วยเพิ่มผลผลิต
การกำหนดความคาดหวังด้านคุณภาพ ที่ผ่านคำจำกัดความของ definition of done จะลดการทำงานซ้ำ

Step 4: Monitor progress

Kanban board และ stand-up meeting จะมีประสิทธิภาพ สำหรับการตรวจสอบและติดตามความคืบหน้า ส่งเสริมความโปร่งใส ความรับผิดชอบ และการทำงานร่วมกัน

stand-up มีกำหนดเวลาที่ 15 นาที ซึ่งทีมจะทบทวนความคืบหน้าของโครงการ ด้วยการยืนรอบกระดานคัมบัง สมาชิกในทีมแต่ละคนตอบคำถามสามข้อ

คุณทำอะไรเสร็จตั้งแต่การประชุมครั้งล่าสุด?
วันนี้คุณทำงานอะไร?
มีสิ่งกีดขวางหรือขัดขวางความก้าวหน้าของคุณหรือไม่?

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

การพูดคุยถึงงานที่กำลังจะเกิดขึ้น ช่วยส่งเสริมการทำงานร่วมกันและช่วยให้ทีมจัดลำดับความสำคัญได้

การแก้ไขอุปสรรค ช่วยให้สามารถแก้ไขปัญหาได้อย่างรวดเร็ว

Step 5: Plan iteratively

การจัดการโครงการทั้งแบบ Traditional และแบบ Agile ตระหนักถึงความสำคัญของการปรับปรุงและบำรุงรักษา project schedule อย่างสม่ำเสมอ

แนวทางปฏิบัติแบบ Traditional หมายถึงการวางแผนซ้ำๆ และทำอย่างละเอียดถี่ถ้วน
Agile ตระหนักดีว่า แผนจำเป็นต้องตอบสนองต่อการเปลี่ยนแปลง
MKS น้อมรับแนวทางปฏิบัติทั้งสองประการ

การวางแผนซ้ำสามารถทำได้ในสองระดับ

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

2) งานที่จำเป็นในการสร้างสิ่งที่ส่งมอบ ควรได้รับการระบุ ตรวจสอบ และอธิบายเพิ่มเติม

การกำหนด Milestones และแผนการส่งมอบ ควรเกิดขึ้นอย่างน้อยทุกเดือน และขอบเขตการวางแผนควรรวมถึง 1–3 เดือนถัดไป

การวางแผนงาน ควรเกิดขึ้นทุกสัปดาห์และควรวางแผนล่วงหน้าประมาณหนึ่งเดือน

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

จากบทความนี้จะเห็นว่าผู้เขียนไม่ได้ระบุ framework, medthodology อะไร ไม่ระบุ ceremonies, events, artifacts ใดๆ ด้วย แค่บอกว่าเป็น Agile แล้วก็หยิบคำศัพท์ (Daily) Stand Up Meeting มา ที่เป็นพิธีกรรมหนึ่งของ Extreme Programming (XP) ซึ่งในเว็บไซต์ของ XP เองก็ไม่ได้บอกกำหนดเวลา แต่คนเราถ้ายืนนานๆ มันก็จะเมื่อยไปเอง ส่วน timebox 15 นาที อันนี้น่าจะเอามาจาก Scrum (เอาเป็นว่าช่างมันอีกรอบแล้วกัน)

ด้าน Kanban Board น่าจะเป็นสิ่งที่ทุกคนคุ้นเคยกันอยู่แล้วถ้าใช้พวก Jira มันก็จะหน้าตาแบบนั้นแหละ แต่ที่ใช้มาก็คือ ลากหลายๆ การ์ดพร้อมกัน ซึ่งจริงๆ แล้วมันควรลากมาทำทีละ 1 การ์ด ทำให้เสร็จไปทีละการ์ด หรือไม่ก็มี WIP limits (work-in-process limits) กำหนดจำนวนงานสูงสุดที่สามารถมีได้ในแต่ละสถานะของคอลัมน์ พอมันเห็นเป็นภาพ ที่โดนแบ่งตามแถว ตามคอลัมน์ เราก็จะเข้าใจสถานะงานได้ชัดขึ้น ก็แค่นั้นเอง

ที่ชอบสุดของบทความนี้คือ ไม่ว่าจะใช้อะไรมาทำงาน จะ Traditional จะ Agile จะอะไรก็แล้วแต่ สิ่งสำคัญคือ “Plan to Replan” และ Update ให้มันเป็นปัจจุบันเสมอ