Work Breakdown Structure

Work Breakdown Structure...มันคือ??

ก่อนอื่นเรามาทำความรู้จักกับเจ้า "Work Breakdown Structure" กันซะก่อน...Work Breakdown Structure หรือที่เรียกโดยย่อว่า "WBS" (อ่านว่าวะ-บึซ ก็ได้...แต่อย่าเลย) ประกอบไปด้วย 3 คำย่อย

• Work (งาน): ในที่นี้เราจะหมายถึงผลงานที่จะเกิดขึ้นจากโปรเจ็คของเรา หรือพูดง่าย ๆ ก็คือ Project Deliverables หรือสิ่งที่โปรเจ็คของเราจะส่งมอบนั่นเอง
• Breakdown (การแบ่งย่อย): เทคนิคหรือกระบวนการในการแบ่งซอยของชิ้นใหญ่ให้กลายป็นของชิ้นเล็กย่อยๆ หลาย ๆ ตัว เราอาจเรียกเทคนิคแบบนี้ว่า "Decomposition"
• Structure (โครงสร้าง): ขยายว่าการแบ่งย่อยของเรานั้น ต้องทำอย่างมีระบบเป็นโครงสร้างลำดับชั้น (Hierarchy)

ซึ่งทาง Project Management Institute (PMI) ได้ให้นิยามของ WBS อย่างเป็นทางการไว้ดังต่อไปนี้

“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables”
- Project Management Institute -

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

WBS จะเริ่มจากการเอา Project Deliverables ของเรามาตั้งต้น (Deliverable-oriented) ส่วนมากแล้ว Project Deliverables จะเป็นของชิ้นใหญ่ที่มีความซับซ้อน ซึ่งเราก็จะแบ่งย่อยมันให้ออกเป็นงานชิ้นเล็ก ๆ หลาย ๆ ตัวโดยใช้เทคนิคที่เรียกว่า "Decomposition" ซึ่งเราจะทำมันอย่างเป็นระบบมีโครงสร้างตามลำดับชั้น (Hierarchy) นั่นเอง

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

ตัวอย่างของ WBS: การสร้างต้นแบบเครื่องบินใหม่

เราลองมาดูตัวอย่างในชีวิตจริงกัน

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

‍

เริ่มจากการถามคำถามว่า "เครื่องบินต้นแบบของเราประกอบไปด้วยอะไรบ้างน้า" (ลองจินตนาการตามไปดูกันนะ) ... เครื่องบินต้องมี 1. ลำตัว 2. เครื่องยนต์ 3. ปีก 4. ล้อ ซึ่งพอแบ่งถึงตรงนี้เราก็จะได้ส่วนประกอบต่าง ๆ ของเครื่องบินที่น่าจะครบแล้ว แต่สิ่งที่เราต้องการคือ "สร้าง" เจ้าเครื่องบินลำนี้ขึ้นมาด้วย เลยต้องถามต่อไปว่า "แล้วสิ่งที่เราต้องทำเพื่อ "สร้าง" เจ้าเครื่องบินต้นเป็นลำขึ้นมามันมีอะไรบ้าง"...ก็คงต้องมี 5. การประกอบชิ้นส่วนต่าง ๆ เข้าด้วยกัน ต้องมี 6. การตรวจสอบเพื่อให้แน่ใจว่าเจ้าเครื่องบินต้นแบบปลอดภัย แล้วก็ต้องมี 7.การบริหารจัดการ Project ของเราในภาพรวม

นี่คือการแบ่ง WBS ลงไปในระดับแรก

ทีนี้คำถามคือ "สิ่งที่เราแบ่งย่อยมาระดับแรกนั้นเพียงพอรึยัง?" ส่วนมากสิ่งที่เราได้ในระดับแรกก็ยังเป็นงานชิ้นใหญ่อยู่นะ อย่างเช่น "1. ลำตัวเครื่องบิน" ก็ยังเป็นชิ้นส่วนบิ๊กเบิ้ม ข้างในมันมีอะไรบ้างหว่า? เพราะฉะนั้น เราก็ควรจะแบ่งย่อยมันลงไปอีก ให้เเป็น "1.1 ที่นั่ง" "1.2 หน้าต่าง" "1.3 ประตู" ฯลฯ พอมาถึง "1.5 ระบบควบคุม" ก็แลดูมีอะไรเยอะแยะซับซ้อน เราก็เลยแบ่งลงไปอีกระดับเป็น "1.5.1 คันบังคับ" "1.5.2 ที่เหยียบ" "1.5.3 หน้าจอ" ฯลฯ

สังเกตดูว่าเราจะมีการเขียนเลขกำกับไว้เสมอในแต่ละส่วนที่เราแบ่งย่อยลงไปในแต่ละระดับ เลขพวกนี้จะเป็นตัวบอกว่าของชิ้นนั้นอยู่ในระดับไหนของลำดับชั้น (Hierarchy) เช่น ในระดับแรก เราจะเป็นเลข "1."  "2." "3." ไปเรื่อย ๆ ส่วนในระดับถัดมาก็จะเป็น "1.1" "1.2" ... และระดับถัดมาก็จะเป็น "1.1.1" "1.1.2" ... ไปเรื่อย ๆ

จะเห็นได้ว่า มันมีโครงสร้างการแบ่งงานในรูปแบบเป็นลำดับชั้น (Hierarchy) นั่นเอง

‍

สิ่งที่ต้องคำนึงเวลาเราทำ WBS

กฎ 100%

เมื่อเราแบ่งงานของเราออกมาตามลำดับชั้น มันจะเกิดความสัมพันธ์แบบที่เรียกว่า Parent-Child หรือ พ่อแม่-ลูก นั่นเอง

ตัวที่อยู่ด้านบนก่อนที่เราจะแบ่งย่อยออกมากเรียกว่า "Parent Node" ส่วนตัวที่เราแบ่งย่อยออกมาหลาย ๆ ตัวคือ "Child Node" นั่นเอง

กฎ 100% กำหนดว่า "Child Node รวมกันทั้งหมดจะต้องเทียบเท่ากับ Parent Node ที่มันแตกตัวออกมาเสมอ" เช่นถ้าเราดูในระดับแรก "งานสร้างเครื่องบินต้นแบบ" เป็น Parent Node ส่วน "1. ลำตัวเครื่องบิน" "2. เครื่องยนต์" "3. ปีก" ... "7. บริหารโครงการ" ก็คือ Child Node นั่นเอง

สมมติว่าเราลืม ตอนแบ่งงานออกมาไม่ได้เขียน "4. ล้อ" ก็จะเห็นว่าพอ Child Node รวมกันแล้วจะไม่ได้กลับขึ้นไปเป็นภาพของ "การสร้างเครื่องต้นแบบ" ที่ครบถ้วน พูดง่าย ๆ ก็คือบวกกลับขึ้นไปจะได้เครื่องบินที่ไม่มีล้อนั่นเอง

‍

เมื่อไหร่ที่จะหยุดแบ่งย่อยลงไป

"เราหยุดแล้ว ฉไนเจ้าจึงยังไม่หยุด"...

บางทีเราแบ่ง WBS อย่างเมามันลงไปได้เป็น 10 - 20 ระดับ แต่คำถามคือเราจำเป็นต้องทำขนาดนั้นรึเปล่า เช่น "1.1 ที่นั่ง" เราจำเป็นต้องแบ่งลงไปถึงระดับน็อต ระดับฟองน้ำ ขนาดนั้นเลยรึเปล่า? แล้วเมื่อไหร่ที่เราควรจะพอแล้วล่ะ คำถามที่สำคัญคือเมื่อไหร่ที่เราไปถึงระดับของ Work Package ที่เราจะไม่แบ่งย่อยมันลงไปอีกแล้ว

ความจริงแล้วมันก็ไม่ได้มีกฎตายตัวหรอก แต่อาจจะลองยึดแนวทางประมาณนี้ก็ได้

• ถ้างานชิ้นนั้นมอบหมายให้สักคน ๆ เดียวรับผิดชอบได้ ก็อาจจะพอแล้ว
• ให้ลองดูว่าของชิ้นนั้นมีระยะเวลาในการทำเท่าไหร่ แล้วเปรียบเทียบกับรอบของการรายงานความก้าวหน้าของโปรเจ็คเรา สมมติว่าเรามีประชุมการรายงานความก้าวหน้าทุกสัปดาห์ ถ้าเรามีงานชิ้นนึงที่น่าจะใช้เวลาทำ 1 ปี (52 สัปดาห์) มันก็อาจจะเป็นงานชิ้นใหญ่เกินไป เพราะว่าเราคาดว่างานนี้จะมีสถานะเป็น 100% ใน 52 สัปดาห์ มันก็แปลว่าในแต่ละสัปดาห์ งานชิ้นนี้ควรจะต้องมีการมารายงานความก้าวหน้า 100%/52 = 1.92% ซึ่งใครจะประเมินงานของตัวเองได้ในระดับ 1.92% กัน มันน่าจะดีกว่าถ้าเราแบ่งมันออกมาเป็นงานที่ใช้เวลาสัก 4 สัปดาห์ ซึ่งในแต่ละสัปดาห์ก็แปลว่าเราคาดหวังความก้าวหน้า 25% คนเราน่าจะพอประมาณงานของตัวเองระดับ 25%, 50% และ 75% ได้ง่ายกว่า

‍

การลงมือทำ WBS

การทำ WBS เป็นการทำงานกลุ่ม (Group Work)

ถ้าเรามองเห็นภาพเราที่เป็น Project Leader / Project Manager นั่นอยู่หน้าจอคอมพิวเตอร์คนเดียว แล้วค่อย ๆ มานั่งแบ่งงาน ทำ WBS ทั้งโปรเจ็คด้วยตัวคนเดียว

นี่น่าจะเป็นภาพที่ผิด!

เพราะว่าเราในฐานะของ Project Leader ผู้มีความสามารถ ก็คงไม่ได้มีความรอบรู้ไปซะทุกเรื่องในสิ่งที่เราต้องทำทั้งหมดในโปรเจ็คของเรา ในส่วนที่เราไม่รู้ มันก็ยากที่เราจะไปแบ่งย่อยงานออกมาได้ด้วยตัวของเราเอง

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

‍

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

พูดง่าย ๆ คือใครถนัดอะไรก็ให้ไปทำ WBS ในส่วนนั้น

ส่วนเราในฐานะ Project Leader ก็คอยกำกับการทำ WBS ให้เป็นไปตามขั้นตอนที่ควรจะเป็น ให้การทำ WBS มีคุณภาพในระดับที่เหมาะสม (ลองขึ้นไปดูกฎ 100% และระดับที่เหมาะสมในการเรียก Work Package)

ซึ่งในกรณีที่โปรเจ็คของเราซับซ้อนจริง ๆ จนมีบางส่วนที่ไม่มีใครในทีมเรามีความเชี่ยวชาญเลย เราอาจจะต้องไปหาผู้เชี่ยวชาญเฉพาะทาง (Domain Expert) เข้ามาช่วยตอนที่เราทำ WBS ด้วย เช่น จ้างที่ปรึกษาเข้ามาช่วย เป็นต้น

‍

ประโยชน์ของการทำ WBS

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

แต่ถ้าเราแบ่งงานประกอบจานบินในรายละเอียดเป็น งานประกอบลำตัวจานบิน งานติดตั้งเครื่องยนต์ งานติดตั้งระบบควบคุม ฯลฯ เราก็สามารถกำหนดผู้รับผิดชอบงานแต่ละชิ้นไปได้เลย เช่น นาย A ไปประกอบลำตัวจานบิน นาย B ไปติดตั้งเครื่องยนต์ เป็นต้น แบบนี้ทำให้ทีมงานแต่ละคนเห็นบทบาทของตัวเองได้อย่างชัดเจน

การลดความคลุมเครือ การสร้างความชัดเจน นี่คือบทบาทหนึ่งของเราในฐานะของ Project Leader เพราะฉะนั้น เราจึงควรที่จะรู้ถึงหลักการของการทำ Work Breakdown Structure เพื่อที่จะไปใช้ตั้งต้นในการทำโปรเจ็คของเราต่อไป