[สรุป] คอร์ส Google Project Management: Professional Certificate ตอนที่ 3: Project Planning

Nut P
5 min readOct 17, 2021

มาถึงตอนที่ 3 ของคอร์ส Google PM ครับ ก็ตอนนี้เขาจะสอนเกี่ยวกับเรื่อง Project Planning นะฮะ ก็หลังจากที่เราเริ่มต้น Kick Off Project ว่าจะทำอะไรแล้ว ต่อไปก็จะเป็นขั้นตอนวางแผนว่าเราจะทำ Project นั้นให้สำเร็จได้อย่างไร โดยส่วนตัวหลังจากที่ผู้เขียนเรียนบทนี้จบมีความรู้สึกว่าคนสอนกับการจัดเรียงเนื้อหาอาจไม่ดีเท่า 2 บทแรกฮะ อย่างส่วนที่เราเรียนบางครั้งอาจจะต้องพยายามจดเองหน่อย เพราะว่าในส่วนที่เป็น Reading Material ไม่ค่อยทำสรุปเนื้อหาที่สรุปเป็น VDO มาให้ และ Quiz ก็ชอบยกประเด็นจุดนั้นเอามาสอบมากฮะ ซึ่งเอาเข้าจริงในภาพรวม เนื้อหาจะค่อนข้าง Abstract พวกทฤษฏีหรือ Template ที่เขาเอามาให้ใช้ตอนเรียน อาจจะใช้เพื่อพอเป็นแนวทางประยุกต์ใช้ในชีวิตทำงานจริงครับผม ก็ใครพร้อมแล้ว ก็ไปดูสรุปได้เลยว่าบทนี้เรียนอะไรบ้าง!!

สำหรับบทที่แล้วฮะ เผื่อใครอยากย้อน

“คิดให้รอบด้าน วางแผนให้ครบ Loop งานเอกสารต้องมา”

Week 1

คนสอนหลักรอบนี้ก็จะเป็นผู้หญิง ที่มาจากตำแหน่ง PM ของ Google เหมือนตอนที่ผ่านๆมานะครับ โดยเริ่มแรกเธอก็เน้นก็ว่าการ Planning ก็เป็นอีกขั้นตอนหนึ่งที่เราต้องให้ความสำคัญเป็นอยากมาก เหมือนๆกับขั้นตอน Initiating Project ซึ่งขั้นตอนนี้จะเป็นขั้นตอนที่ต้องลง Detail มากขึ้น เรากับทีมต้องทำอะไรบ้างจนกว่าจะไปถึงเป้าหมาย โดยเอาจริงการวิธีการ Planning ของ PM จะไม่มีสูตรตายตัว และแต่ละ Project ก็ต้องใช้แผนที่แตกต่างกัน แต่หลักๆมุมมองของการ Planning เขาจะชอบมองเป็น 3 ส่วนใหญ่หลักๆด้วยกัน ได้แก่

  • Schedule >> การวางเวลาในการทำ Project
  • Budget >> การจัดการเรื่องทุนทีมีใน Project
  • Risk Management Plan >> การบริหารความเสี่ยงที่อาจเกิดขึ้นและเกิดขี้นแล้ว

การวางแผนนี้พวกนี้บอกได้เลยว่า ครั้งแรกไม่มีทาง Perfect แน่นอน ยังไงก็จะต้องมีการเปลี่ยนเปลี่ยนระหว่างทาง ไม่ว่าจะมาเกิดมาจากความผิดพลาดของตัวเราเอง หรือสิ่งที่ไม่คาดคิดที่เกิดมาจากภายนอกก็ตาม

โดย Keyword แรก ที่เราต้องรู้จักของการ Planning คือคำว่า “Milestone” หลายคนจะชอบสับสนว่า Milestone เหมือนกับ Task ซึ่งมันไม่เหมือนกันนะครับ

  • Milestone >> จุด Checkpoint ที่เกิดจากการทำ Task หลายอันๆเสร็จ ที่มี Delivery ใหญ่ๆส่งมอบ เช่น Design เว็บไซต์, Dev เว็บไซต์, Test เว็บไซต์
  • Task >> งานหรือสิ่งที่คนในทีมต้องทำให้เสร็จใน Project โดยจะอยู่เป็นข้อย่อยๆของ Milestone เช่น งานย่อยที่ต้องทำใน การ Design เว็บไซต์, Dev เว็บไซต์, Test เว็บไซต์ ที่เป็น Milestone

ต่อไป Keyword ที่สอง ที่ต้องรู้จักคือคำว่า “WBS” หรือในชื่อเต็มว่า “Work Breakdown Structure” เป็นแผนผัง Tree Diagram แตกงานย่อยไปเรื่อยๆที่ทำให้รู้ว่าเรากับคนในทีมต้องทำ Task อะไรใน Project บ้าง

Work Breakdown Structure (WBS)

Week 2

อาทิตย์ที่สองนี้ ผู้สอนก็จะสอนวิธีการเขียน Planing ลงลึกไปอีกครับ โดยหลักๆหลังจากเราเรียนรู้เรื่อง Task และเรื่อง Milestone อาทิตย์นี้เราก็จะมาเจาะเรื่อง Time กับ Documentation ต่อฮะ

  • Task
  • Millstone
  • Time (เวลา)
  • Documentation (เอกสาร)

เรื่อง Time PM มีหน้าที่ในการประเมินระยะเวลาในแต่ละงานให้สมจริงมากที่สุดเท่าที่เป็นไปได้ ไม่ว่าจะเป็นจากการถามคนทำงานโดยตรง หรือจากประสบการณ์ตัวเองก็ตาม โดยในเรื่อง Time นี้ Keyword แรกที่ต้องรู้จักคือคำว่า “Buffer” ครับ หรือเวลาที่เราใช้ตีประเมินเผื่อเวลาที่จะทำงานเสร็จอะไรในแต่ละอย่างใน Project เพราะอย่าลืมว่าในโลกจริงตอนทำงานมันอาจมีสิ่งที่ไม่คาดคิดเกิดขึ้น หรือที่เราเรียกกันว่าความเสี่ยง (Risk) ซึ่ง PM ก็มีหน้าที่ต้องตีเวลาพวกนี้เผื่อไปด้วยครับ เช่น มีน้อง Dev ในทีม บอกว่าจะทำเว็บเสร็จภายใน 5 วัน แต่หาไม่รู้ว่าในช่วงที่เขาต้อง Dev นั้น ทางบริษัทอาจมีสุ่ม Audit เข้า ที่ทำให้ทุกคนต้องหยุดทำงานไป เราจึงต้องตี Buffer เพิ่มไปอีก 1 วัน เป็น 5+1 = 6 วันแทน เป็นต้น

Keyword ที่ 2 คือ Network Diagram ซึ่งในคอร์สนี้เอาเข้าจริงไม่ได้ลงลึกในเรื่องนี้เท่าไร แค่อธิบายภาพรวมเป็นผิวเผิน สำหรับใครที่อยากรู้ลงลึกเพิ่มเติม สามารถไปหาความรู้ใน Google ทั่วไปได้ฮะ โดย Concept คร่าวๆการนำไปใช้ของ Diagram นี้คือ การเปรียบเทียบภาพรวมของการทำงานในแต่ละงาน ว่างานใดต้องทำเมื่อไร ทำก่อนทำหลัง มีเวลานานเท่าไรที่เรายังไม่ต้องทำงานนี้ เป็นต้น บางคงอาจถามว่าจะทำไปทำไม อันนี้ก็บอกได้เลยครับว่าชีวิตจริงงานที่ต้องทำมันเยอะ และส่วนใหญ่ไปแบบคู่ขนานกันครับ แบบตามรูป ซึ่งพอใช้ Diagram นี้มาดูชีวิตก็จะง่ายขึ้นครับ

Network Diagram Example : Mcgraw-Hill-Project Management

ปกติ Network Diagram นี้ก็จะเราจะเขียนมือเอง หรือใช้ Tool เขียนก็ได้ครับ โดยส่วนตัวผมก็เคยลองใช้ MS Project เขียนขึ้นมา ก็ได้อยู่ครับ โดยจากภาพที่เราดูไวๆจุดเริ่มต้นจนถึงเส้นชัยของแต่ละงาน จะมี 3 ทางเนอะ โดยเส้นทางที่ใช้เวลาเยอะที่สุดจะเป็นเส้นที่ผมวงแดงนะครับ เป็น Keyword ที่ 3 ที่เราต้องรู้จักเรียกว่า “Critical Path” หรือเส้นทางที่เราไม่สามารถอู้งานได้เลย จะเห็นได้ว่าเส้น Built & Test Hardware มีเวลาที่ใช้ตั้งแต่เริ่มต้นถึง จุดนี้ 85 วัน ในขณะที่อีก 2 ทาง ใช้เวลาแค่ 50 วันและ 70 วัน ตามลำดับ ซึ่งอีก 2 ทางก็จะมีเวลาหายใจอู้งานจนกว่าจะเริ่มทำงานสุดท้ายหน่อย นั่นจะ Keyword ที่ 4 ของเราที่เขาเรียกกันว่า “Slack” ครับ หรือ Gap เวลาที่เหลือในการทำงานของแต่ละส่วนงาน

เรื่อง Time ก็จบไปครับ เอาเข้าจริงพวก Diagram พวกนี้ อาจเป็นแค่ส่วนเสริมนะครับ ชีวิตจริง อาจไม่ใช้เลยก็ได้ สิ่งที่ต้องใช้จริงๆในการประเมินพวกเวลาจะเป็นเรื่องศาสตร์เรื่องศิลป์ ที่เราต้องประเมินมาจากการเก็บข้อมูลมาจากคนทำงาน และประสบการณ์ในการประเมินครับผม ตัวหลักๆที่สำคัญจริงๆ คือพวก Documentation ครับ ที่เราจะทำอะไรควรมีเอกสารสื่อสารกับทีมได้อย่างชัดเจน รวมถึง Tool ที่ใช้ในการทำ Project Schedule เพื่อใช้ในการจัดการทีม และทำให้ทีมมองเห็น Task การทำงานไปในทางเดียวกัน

ตัว Project Schedule นี่แหละ จะเป็นสิ่งที่เราเอาทุกอย่างที่เรียนก่อนหน้าเอามายัดรวมในนี้ครับ โดยปกติตัวที่นิยมเขาใช้กันก็จะเป็น Gantt Chat ไม่ก็ Kanban ครับ แล้วแต่สไตล์การทำงานของทีม โดยอาจใช้เป็นใน Jira, Treallo, Asana, Google Sheet หรือทำมือก็แล้วแต่ว่ากันไปครับ

  • Gantt Chart : ตัว Project Schedule แบบ Classic ของ PM ที่ใช้กันครับ ซึ่งถ้าเป็นแบบ Waterfall ตัวนี้ขาดไม่ได้เลยครับ ตัวอย่างก็ตามรูป
  • Kanban : ทำเป็นคล้ายๆเป็น Post It มาแปะ ให้เห็น Tracking ของแต่ละขั้นตอน ลองไปดูตัวอย่างใน Trello ที่มีบทความเคยเขียนตามลิงก์ด้านล่างนี้ก็ได้ครับผม
Photo by airfocus on Unsplash

Week 3

อาทิตย์เป็นเรื่อง Budgeting กับ Procurement ครับ หรือที่เราเรียกง่ายกันว่าเรื่อง “เรื่องจัดซื้อ” เอาจริงเรื่องนี้มีหลักการสั้นๆแค่นี้เลยครับ คือ ทำยังไงก็ได้ให้การจัดซื้อโปร่งใส่ที่สุด และไม่ Over-budget หรือไม่ก็ Under-budget ครับ

ใครอยากได้ตัวอย่าง Template Budget ของ Microsoft อันนี้เขาก็มีให้ไปใช้ฟรีครับ

แล้วเรื่องการประเมิน Budget ก็จะเหมือนเรื่องประเมินเวลา Scope ที่ทำงานครับ ก็อย่าลืมประเมินเผื่อขาด Budget ในยามฉุกเฉินด้วยนะครับ ซึ่งเขาใช้คำว่า Contingency Reserves กันครับ

ส่วนที่วิธีทำ Budget ก็บอกได้เลยครับว่าไม่มีทางลัดครับ เก็บข้อมูลให้เยอะ คุยกับผู้เชี่ยวชาญทุกๆฝ่ายที่เกี่ยวข้อง ไม่ว่าจะเป็นคนภายใน, Vendor หรือผู้มีส่วนเกี่ยวข้องอื่นก็ตาม แล้วก็ต้องละเอียดครับ เพราะเป็นเรื่องเงิน ซึ่งแต่ละ Project ก็มีโครงสร้างการทำ Budget ไม่เหมือนกันครับก็ต้องประยุกต์กันไป

หลังจากที่เราทำ Budget เสร็จ ต่อไปก็เป็นขั้นตอนจัดซื้อครับ ซึ่งชื่อเอกสารที่ควรรู้จักก็มีตามนี้ครับ

  • Nondisclosure Agreement (NDA) >> สัญญาห้ามเปิดเผยข้อมูล
  • Request for Proposal (RFP) >> เอกสารให้ Vendor ส่ง Proposal ประมูลแข่งรับ Project กัน
  • Statement of Work (SOW) >> รายละเอียดงานที่แจงให้ Vendor จ้าวที่ถูกเลือกต้องทำ

ก็อย่างที่บอกตอนแรกเลยครับขั้นตอนการจัดซื้อนี้เราควรโปร่งใสและเป็นกลางมากที่สุดครับ

Week 4

จบจากเรื่อง Schedule และ Budget ไปแล้ว ต่อไปก็จะเป็นเรื่อง Risk Management Plan ครับผม จะจัดการให้ความเสี่ยงใน Project ยังไงให้มันเหลือน้อยที่สุด โดยในเรื่องนี้เรามีสิ่งที่ต้องจัดการ 2 อย่าง

  • Risk >> ความเสี่ยงที่อาจจะเกิดได้ในอนาคต ที่ส่งผลเสียต่อ Project โดยเราต้องหาวิธีรับมือ เพื่อบรรเทาให้โอกาสพวกนี้เกิดน้อยที่สุด
  • Issue >> สิ่งแย่ๆที่เกิดขึ้นกับ Project แล้ว และเราต้องมารับมือแก้ไข

ซึ่งแน่นอนว่าโจทย์ของ PM ของเรา คือ ทำอย่างไรก็ได้ไม่ให้ตัว Risk นี้ ไป Convert เป็น Issue ได้เนอะ แต่ในโลกแห่งความเป็นจริงเราคงหลีกเลี่ยงและรับมือพวกนี้ได้ไม่ทั้งหมดหรอก เราจะต้องมานั่งเลือก และจัด Priority ว่าจะรับมือกับความเสี่ยงไหนก่อน ความเสี่ยงนี้มี Impact เยอะไหม และโอกาสจะเกิดมากเพียงไร ไม่ใช่ว่า Impact นี้เยอะจริงอาจทำให้ Project ล่มเลย แต่โอกาสเกิดไม่ถึง 0.001% ความเสี่ยงนี้เราก็ไม่ควร Focus เนอะ นั่นเป็นที่มาทำให้เกิดศาสตร์ Risk Management Plan ขึ้นมา

อันนี้ก็จะเป็น Diagram ที่สอนใน Course ที่บางครั้งเขาไปเอาใช้จัดการ Risk นี้นะครับ

  • Fishbone Diagram >> หรือบางครั้งเขาก็ใช้ชื่อว่า Ishikawa diagrams หรือ cause-and-effect diagrams เอาไว้ใช้ List พวกดูปัญหาต้นตอความเสี่ยง List ต้นตอมาให้หมด แล้วค่อยมานั่งตัดสิ่งที่ไม่ค่อยเกี่ยวออก แล้วสุดท้ายหาสาเหตุที่เป็นต้นตอเกิดความเสี่ยงนั้นจริงๆดังตามรูป
  • Risk Type Model >> ต่อไปเป็นเรื่องของ ประเภทของ Risk ในโลกความเป็นจริง เอาจริงประเภทของ Risk เราจะเป็นยังไงก็ได้ตามความเหมาะสมของ Project แต่ในคอร์สนี้ เขาใช้การมอง Concept คล้ายๆกับ Triple Constraint Model ในบทที่แล้วที่ถ้าเรายังจำได้ แค่เปลี่ยนตรงกลางจาก Quality เป็น Risk และคำว่า Cost ก็คือ Budget ครับ เราก็มาแบ่งดูดีๆว่า Risk ที่เราเห็นมันอยู่ส่วนไหนของสามเหลี่ยมครับ

ส่วนนี้ก็เป็นตัวอย่างการเขียน Risk Management Plan ในคอร์สเบื้องต้นนะครับ วิธีทำครับก็เริ่มจาก List ประเภทความเสี่ยงที่เป็นหัวข้อใหญ่ๆขึ้นมา เช่น ความเสี่ยงที่งบเกิน หรือความเสี่ยงที่ส่งงานไม่ได้ตรงตามเวลา เป็นต้น แล้วก็ List Scenario ย่อยๆในประเภทความเสี่ยงนั้นๆ เช่น เรื่องไม่ทันเวลา ก็อาจเขียนไปความเสี่ยงที่หัวหน้าจะป่วย ซึ่งอันนี้โอกาสน่าจะเกิดขึ้นน้อยและไม่ค่อยมีผลอะไรเราก็อาจไปตีไปเป็น Low ไป หรือถ้ามี Matrix ที่ใช้ชี้วัดแบบด้านล่างก็ดีเลยครับผม สุดท้ายก็เขียน Mitigation Plan (วิธีการบรรเทาความเสี่ยง) ซึ่งใน Case นี้เราตีเป็น Low เราอาจยอมรับความเสี่ยงไม่แก้ปัญหานั้นก็ได้ครับ หรือหาวิธีบรรเทาอะไรอย่างก็ได้ แต่เคสนี้มันสำคัญน้อย เราก็ควรไปแก้ปัญหาที่เราตีเป็น High ในข้ออื่นก่อน อย่างถ้าไม่แก้ปัญหาความเสี่ยงภายในอาทิตย์นี้ หุ้นบริษัทจะตกลง 50% เป็นต้น

Week 5

เรื่องสุดท้ายของคอร์สย่อยนี้ครับ เรื่อง Communication ครับ เนื่องจากการ Planning เราต้องเป็นคน Kick Off Meeting Lead Project เอง ซึ่งถ้าเราสื่อสารไม่ดี Project ก็คงไปได้ไม่ราบรื่นแน่นอนครับ เหมือนอารมณ์ว่าเราจะนัดเพื่อนกินข้าวเที่ยงนี้ แต่เอาจริงกว่าทุกคนจะมาถึงก็ห้าโมงกินข้าวเย็นพอดี XD

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

เบื้องต้นตอนเริ่ม Project เราอาจจะเริ่มจากการเขียน Communication Plan ก่อนก็ได้ครับ ว่าใครเป็นคนที่เราควรคุยบ้าง ถี่เท่าไร ด้วยวิธีอะไร เป็นต้น ลองใช้ตัว RACI Chart กับ Stakeholder Power Grid ในตอน 2 มาประกอบช่วยก็ได้ครับ เพื่อให้เห็นภาพรวม ซึ่งในคอร์สนี้ก็มีตัวอย่าง Template สอนให้ใช้อยู่ครับ ซึ่งอย่าลืมนะครับตลอดทั้ง Project เรื่องพวกนี้อาจเปลี่ยนแปลงได้เสมอ เราควรมีความ Flexible ตามสถานการณ์ครับ

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

สุดท้ายในอาทิตย์นี้เขาก็ได้มีแถมสอนวิธีการสมัครงานตำแหน่ง PM คล้ายๆในตอนแรก แต่ก็เป็นอีกในแง่มุมนึง ก็ลองไปติดตามกันในบทเรียนได้ฮะ :)

สรุปส่งท้าย

เป็นอย่างไรบ้างครับกับเรื่อง Planning จากที่คิดว่าบทที่แล้วเนื้อหาแน่นแล้ว แต่เรื่องนี้เนื้อหาดันแน่นกว่า ซึ่งเอาเข้าจริงอันนี้ผมคัดมาแค่บางส่วนของเนื้อหาเองนะครับ และในคอร์ส Google นี้ ก็คัดมาสอนเนื้อหาแค่บางส่วนอีก ซึ่งเรื่องนี้มีอะไรให้เรียนรู้อีกเยอะมากเลยครับ แต่ถึงอย่างไรก็ตาม ผมคิดว่ามันก็เป็นแค่แบบทฤษฎีที่ค่อนข้าง Abstract เอาไปใช้ในการทำงานจริงไม่ได้ทันทีอยู่แล้ว ต้องมีไปประยุกต์ใช้หน่อย ซึ่งเรื่องนี้บอกได้เลยว่าถ้าเราอยากเก่งเรื่อง Planning จริง ต้องไปเก็บชั่วโมงทำงานเองครับผม โอเครครับ ตอนต่อไปก็จะเป็นเรื่อง การดำเนินการ Project และการปิด Project เนอะที่เราทำหลังจากวางแผนการทำ Project จากขั้นตอนนี้เรียบร้อยแล้ว ซึ่งถ้าใครพร้อมแล้ว สามารถไปติดตามต่อในลิงก์ด้านล่างได้เลยครับ ^^

--

--

Nut P

มาคุยกันได้ครับ สนใจด้าน Tech & Business fb.com/inut.panpp