EP 89: 1 ปีกับงาน Project Manager ฝั่ง BU แต่ก็ทำ IT

สวัสดีครับ วันนี้ก็จะมาขออนุญาต รีวิว ประสบการณ์การทำงานอีกครั้ง โดยรอบนี้ก็จะเป็นตำแหน่ง PM หรือที่เราเรียกกันว่า ผู้บริหารโครงการ ก็ครั้งที่แล้ว Review งาน BA ไปแล้ว คราวนี้ก็ตำแหน่ง Project Manager งานสุดฮ๊อต ที่ผมเชื่อว่าใครหลายๆคนก็อยากลอง แล้วยิ่งเป็น PM ฝั่ง BU (Business Unit) ด้วยที่ไม่ค่อยมีใครเล่าถึงกัน ดูน่าสนใจไหมครับ ใครสนใจก็ติดตามกันต่อได้เลย 😄

“การทำ Project ก็เหมือนกับการวิ่งมาราธอน ที่เราต้องคอยบริหารทีมไปเรื่อยๆจนถึงจุดหมาย”

งาน PM ปกติเขาทำอะไรกันบ้าง.?

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

แล้วงาน PM ฝั่ง BU แต่ทำ IT ของ ผมคืออะไร.?

ก่อนจะตอบคำถามนี้ ขออนุญาตเล่าประวัติของผมคร่าวๆนะครับ ก่อนผมมาทำสาย Project Manager ในกลุ่ม Fintech นี้ ผมก็ได้มีโอกาสทำงานสาย IT มาก่อน โดยตำแหน่งก่อนหน้าเป็นตำแหน่ง Business Analyst ที่มีโอกาสได้จับงานตำแหน่ง Project Manager อยู่เหมือนกัน และหลังจากนั้นก็ย้ายมาทำงาน PM ครับ

บอกตามตรงผ่านมา 1 ปี ผมก็ยังงงๆว่า สรุปงาน PM ของผมทำอะไรกันแน่ เพราะแต่ละ Project พอเจอทีมต่างกัน Scope ที่ทำงานของ PM ก็ต่างกัน ผมเลยตัดปัญหา แทนที่ต้องมาปวดหัวหาคำตอบในการ Define scope ว่า Role ของ PM ฝั่ง BU แต่ทำ IT ของผม จริงๆคือทำอะไรกัน ก็หันมาใช้แนวคิดง่ายๆแทนว่าหน้าที่ของ Project Manager ของผม คือ

คือการ Manage Project และทำทุกอย่างที่ไม่มีคนใน Project ทำ ที่ทำแล้วทำให้ Project success และขึ้น Product ได้สำเร็จ

โดยส่วนใหญ่งาน Project จะเป็นงานขึ้นระบบใหม่ที่ทำจบแล้วก็จบไป แล้วก็จะส่งมอบ BAU ให้คนอื่นสานงานต่อ ก็จะเหมาะกับคนที่ชอบเจออะไรใหม่ๆ แต่ข้อเสียคือก็ต้องเจอการเปลี่ยนแปลงบ่อย โดยงานมันก็จะต่างกับงานแนว Product ที่ต่อให้ทำเสร็จแล้ว ก็ยังคงต้องเป็น Owner ต่อไป ก็ลองดูว่าชอบแบบไหน

ซึ่งที่ทำงานผ่านมา 1 ปี ผมก็มีโอกาสได้ทำ Project ใหญ่ๆประมาน 3 Project และก็ Project ย่อยๆอีกนิดหน่อย โดยงาน PM ของผมก็คืออยู่ภายใต้แผนกของ BU (Business Unit) เลย หรือให้เข้าใจง่ายๆว่าคือเป็น PM ที่ไม่ได้อยู่ภายใต้แผนก IT

แต่ด้วยที่ Project ในปัจจุบันยังไงก็ล้วนแล้วมีเกี่ยวข้องกับการ Implement ระบบ IT ทั้งสิ้น ดังนั้นงาน Project Management จึงแทบหลีกเลี่ยงที่ไม่เกี่ยวข้องกับ IT ได้เลย ซึ่งเราก็ต้อง Manage ส่วนนั้นด้วย แต่ก็จะมี PM หรือ DM (Delivery Manager) ฝั่ง IT มาช่วย Support ซึ่งงาน PM ของ BU เรา มันจะต่างกับ DM ฝั่ง IT คือ เราไม่ต้องเขาไปดูเรื่องพวก Technical, IT Security รวมถึง IT Resource มากนัก หลักๆจะเป็น DM ฝั่ง IT เป็นคน lead แทน ส่วนเราจะเป็นคนดูภาพรวมทั้ง Project ที่มีพาร์ท IT และ Business เป็นหนึ่งในนั้น ซึ่งถ้าอยากรู้เยอะกว่านี้ว่างานผมทำอะไรก็ไปอ่านพาร์ทด้านล่างผมต่อได้ฮะ

งาน PM เหมาะกับใคร.?

1. คนที่มีความเป็น Ownership สูง
2. คนที่มีความเป็น Generalist สามารถเข้าใจภาพรวม และเรื่องใหม่ๆได้เร็ว
3. คนที่มีความสามารถเรื่องคน ทั้งเรื่อง Communication, การหา Keyman ในการคุย, บริหาร Stakeholder รวมถึงการ Delegate งานคนใน Project ดั่งคำที่ว่า Put the right man on the right job
4. คนที่มีความสามารถในการเป็น Facilitator ได้
5. คนที่มีความสามารถ Work smart สามารถแบ่ง Priority คัดเลือกงานที่สำคัญใน Project จริงๆมาทำก่อนได้

สิ่งที่ได้จากงาน PM

1. คนรู้จักเยอะ เพราะ ทุกคนใน Project ต้องรู้จักเรา
2. มีโอกาสได้เจอผู้บริหาร หรือผู้ใหญ่บ่อย
3. ได้เห็นงานภาพรวมตั้งแต่ต้นจนจบ
4. ได้ความภาคภูมิใจ และค่อนข้างได้ผลงานเมื่อทำ Project สำเร็จ
5. ได้ประสบการณ์แบบแนวนอน T-Shape เยอะ เพราะ ได้ทำหลาย Project

ข้อเสียของงาน PM

1. งานค่อนข้างหนัก และกดดัน เพราะ PM เหมือนเป็นศูนย์กลางที่ต้องรู้ภาพรวมแทบทุกอย่าง
2. เจอการเปลี่ยนแปลงบ่อย
3. เจอปัญหาเกี่ยวกับกับคนเยอะ
4. Scope งานคลุมเคลือ และมักต้องทำงานใน Scope งานที่มากกว่า Role ตัวเอง
5. PM ไม่ใช่คน Make Decision แต่เป็นเพียงแค่ Facilitator

ด้านล่างจะเป็น Detail แล้ว อาจจะยาวหน่อย แต่ลองอ่านได้จะได้เห็นภาพการทำงานจริงๆ อันนี้ผมก็เล่าตามทฤษฎีของ Project life cycle ที่เขาสอนจากตำราเทียบกับประสบการณ์การทำงานจริงๆที่ผ่านมาของผมเลยนะครับ ก็ลองดูกัน

1)Project Initiation

เฟสเริ่มต้นว่าอยากจะทำ Project เรื่องอะไร ซึ่งที่มาการเริ่มต้นของแต่ละ Project ก็อาจจะไม่เหมือนกัน โดยผมขอเล่าอันที่เจอมาใหญ่ๆนะครับ

1. Project ที่เพิ่มฟีเจอร์มาจาก Product เดิม >> หลักๆ Product Manager จะเป็นคนที่กำหนด Roadmap ในช่วงปลายปี ว่าในปีถัดไปในปีหน้าทำอะไรบ้าง และก็จะมี Delivery Manager ฝั่ง IT และ Project Manager เราๆมาคุม Project ย่อยอีกที เพื่อให้ Delivery ฟีเจอร์ Product ให้ได้ตรงตาม Roadmap ซึ่งตัว Project Manager ก็อาจจะลงไปช่วยแค่ Project ย่อยๆที่มันดูใหญ่ ตามที่ Product Manager request มา
2. Project ที่ทำ Product ใหม่ >> จะแตกต่างจาก Project ที่ทำ Product เดิม ตรงที่ Direction หลักๆจะมาจากผู้บริหาร และทีม Strategy ขององค์กร หรือมาจากบริษัท Consult ข้างนอกก็ว่ากันไป โดยตอนทำนี้ก็ต้องมีการฟอร์มทีม Product Manager ทั้งทีมเป็น Squad ใหม่ รวมถึงต้องหา Sponsor ผู้ที่จะมาให้ทุน ความซับซ้อนและ Effort ที่ต้องใช้ก็จะมีมากกว่า

ในเฟสนี้ก็อาจเป็นเฟสที่ทีม Project Manager ยังไม่ได้เข้าไป Involve มากนัก หรือยังไม่ได้เข้าไปเลย ซึ่งถ้าเข้าไปก็อาจเป็นการเข้าไปช่วยบริหาร Roadmap กับทีม Strategy, Product Manager และ DM ของฝั่ง IT

ถ้าเป็นตามตำราในขั้นตอนนี้เราต้องทำ Project Charter และ Proposal ให้ผู้บริหาร และ Sponsor อนุมัติใช่ไหมครับ แต่อย่างที่ผมเจองานพวกนี้มักจะไปอยู่ช่วงจบ Planning ก่อนเริ่มเฟส Execution แทนครับ (เพราะมีปัญหาลง Detail เรื่องการอนุมัติ Budget อะไรหลายๆอย่าง) โดยหลักๆแต่นี้ไป ผมจะขอเล่าเป็นไปทาง Project ขึ้น Product ใหม่เป็นหลักนะครับ เพราะ จะมีรายละเอียดอะไรที่น่าสนใจให้เพื่อนๆเห็นภาพรวมการทำงานของ PM มากกว่า

2) Project Plan

เป็นเฟสที่ Project Manager เริ่มเข้ามา Involve จริงๆ ส่วนตัวคิดว่าเป็นพาร์ทที่ Challenging และหนักสุดของ PM ล่ะครับ เพราะ เป็นพาร์ทที่เรียกว่าเป็นช่วงตั้งไข่จริงๆ เพราะ

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

Resource คนมาทำงานใน Project เรื่องแรกที่ผมคิดว่าสำคัญมากๆ เหมือนเป็นการฟอร์มทีม Avenger เราจะหาคนที่เป็น Iron man กับ The Hulk มาเข้าทีมได้อย่างไร

ในชีวิตจริง Resource ไม่เคยพอ และต่อให้ได้ดึง Iron man เข้ามาร่วมทีมได้ ก็ใช่ว่า Iron man จะมาโฟกัสทำ Project เราอันเดียว ส่วนใหญ่เขาก็จะมีงานเก่าอื่นที่ยังต้องทำด้วย เพราะ เป็น Iron man ใครๆก็อยากขอความช่วยเหลือ (สุดท้ายขอแค่มีพนักงาน Stark มาช่วยแทนก็พอใจละ 55) ดังนั้นพวกสกิลการ Lobby และบริหารคนให้มาโฟกัสทำงาน Project เราก็ค่อนข้างสำคัญเลย

อันนี้แค่หมายถึงการ Recruit คนภายในนะ ถ้าไม่มีพอ เราก็ต้องจ้างประจำ หรือ Outsource คนเพิ่ม ซึ่งอันนี้ก็มีเรื่อง Lead time onboard โดยตั้งแต่ผมทำมายอมรับเลยส่วนใหญ่ก็คือหาคนไม่ทัน สุดท้ายก็คือต้องใช้คนในนี่แหละมาทำก่อนแทน เป็นปัญหาโลกแตกของ Project จริงๆ

โดยหลังจากได้คนแล้ว ก็ต้อง Set Org chart และแบ่ง Role & Responsibility ดีๆ อันนี้ก็เป็นอีกหนึ่งกึ่งๆหน้าที่ PM อีกทีนึงครับ เพราะ มันมักจะมีงานที่ก้ำกึ่งระหว่าง 2 ตำแหน่งเสมอ และจะมีงานเล็กๆน้อยๆที่มันไม่ได้ประจำอยู่ตำแหน่งใดๆ แต่ก็ต้องทำ เพื่อให้ Project run ได้ เช่น หาห้องประชุม, นัดหมาย, ทำเรื่องขออนุมัติ, งานที่หาคนลงยังไม่ได้ ซึ่งหลักๆงานอันไหนไม่มีคนทำ PM ก็ต้องทำหมด โดยสิ่งๆเล็กๆพวกน้อยนี่แหละ จะเป็นตัวขัดขวางการทำงานของ PM ที่ทำให้ไม่ได้ทำสิ่งที่ควรจะทำ โดยผมขอยกตัวอย่างกราฟนี้ ช่วงยังหาคนลงไม่ได้ ในช่วง Planning งานมันมักจะกองไปอยู่แกนขวา ที่เป็นงานด่วน แบบทำงานเอาแค่ตัวรอด ซึ่งเป็น Sign ไม่ดี ยิ่งเป็นงานขวาล่าง เราควรให้คนอื่นทำแทน หลักๆสิ่งที่เราควรทำเป็นเป็นสิ่งที่อยู่แกนซ้ายบน ที่เป็นงานสำคัญ แต่ไม่เร่งด่วน และเป็นงานที่สร้าง Impact ใน Long term ครับ สรุปสั้นๆคือ

เราควร Work smart ครับ ไม่ใช่แค่ Work hard เพียงอย่างเดียว ที่ทำแล้วได้แต่ความเหนื่อย แถมไม่ค่อยได้อะไรกลับมาดีๆเป็นรูปธรรมด้วย เหมือนกับการทำ Project ที่เราควรทำแบบวิ่งมาราธอน ไม่ใช่แบบวิ่งสปีดที่แปปเดียวก็หมดแรง

ต่อไปวิธีเซต Way of work ใน Project ก็สำคัญเช่นกัน ทุกคนใน Project ควรเห็น Vision ไปในทางเดียวกัน และทำตาม Ground rule วิธีการทำงาน Governance ที่เราเซตไว้ เช่น การทำงานจะเป็นแบบ Agile หรือ Waterfall การทำงานจะเป็น WFO หรือ WFH จะใช้ Tool อะไรช่วยทำงาน อันนี้ก็เป็นอีกอันที่ Challenge เช่นกัน ยิ่งเป็น Project ที่เปลี่ยน Way of work จาก Culture เดิม และมีคนใน Project เยอะ เช่น ผมเคยเจอ Mega project ที่ต้องเปลี่ยนวิธีการทำงานตาม Consult และมีคนในโครงการท้ายสุดร่วมเกือบ 200 คน แบ่งเป็นทีมยิบย่อยอีกเยอะแยะ ซึ่งเป็น Project ที่เรียกได้ว่าหินมาก

อีก Challenge นึงคือปกติคนที่มาทำใน Project ไม่ได้เริ่มมาพร้อมกันหมดทุกคนตั้งแต่ Day 1 ในโครงการจริงๆคือคนจะค่อยทยอยเข้ามาเรื่อยๆ และก็จะมีออกไประหว่างทาง เราจะ Handle ปัญหาพวกนี้ให้คนใหม่มาเริ่มทำงานใน Project ให้ได้เร็วสุดอย่างไร ยิ่งส่วนที่เป็น Head และปัญหาอีกมากมายหลายอย่างใน Project ซึ่งส่วนตัวคิดว่าวิธีแก้สิ่งที่เจอพวกนี้ใน Project ใหญ่ คือ พยายามเซต Governance ให้ดี และ Decentralize หา Owner ออกให้เร็วที่สุด และควรเตรียม Facility ที่ช่วยการทำงานให้เร็วที่สุดเท่าที่เป็นไปได้ เพราะ พวกนี้ดูเหมือนเป็นเรื่องเล็ก แต่มันสำคัญต่อการทำงานจริง เช่น ถ้าจะทำ Agile แบบ Garage ที่ทุกคนต้องมา WFO ก็ควรมีที่นั้ง ห้องประชุม จอทีวีพร้อม คนนอกต้องมาใช้ Tool ร่วมทำงานได้ไม่ติดขัด ไม่ใช่แบบสุดท้ายจะทำแบบ Garage แต่มีคนมาผสมทำ WFH ด้วยเพราะที่นั่งไม่พอ แบบนี้มันก็ไม่ Success แถมยังทำให้คนทำงานที่ไม่ WFH เหนื่อยขึ้นเป็นทวีคูณอีก เป็นต้น

เล่าซะยาว พวกงาน Planning ด้านบน เป็นงาน Optional สำหรับ PM ซึ่งถามว่าทำผ่านๆไปได้ไหม ก็พอได้ แต่ก็ต้องมารับชะตามกรรมการทำงานที่เหนื่อยขึ้นต่อไป

เรามาดูงานหลวงที่เราต้องทำกันดีกว่า มันก็คืองานที่เราต้องได้ Project approval ที่เราย้ายมาจากเฟส Initiation ซึ่งข้อมูลหลักๆที่ต้องได้ คือ Timeline, Budget, Feasibility ของโครงการไปให้ผู้ใหญ่ Approve

ที่ทำมาทั้งหมดของผมเป็น Project ที่ต้อง Implement ระบบ IT นะครับ โดยของผมก็คือจะมีใช้ Vendor ที่เป็น In-house บริษัทในเครือเอง กับ Vendor ที่ดีลข้างนอก มาช่วยประเมิน Timeline กับ Budget ซึ่งความยาวนาน ขึ้นอยู่กับความโชคดี โชคร้ายของ Vendor เลย ว่าต้องการ Scope ลึกขนาดไหนถึงจะประเมินได้ และท่าที่เราจะไป จะไปอย่างไร โดยเรามีหน้าที่ต้องดึง Product Manager มาให้ Requirement กับฝั่ง Vendor เพื่อให้ได้ Timeline, Budget โดยหลังจากที่เราได้ Timeline, Budget จาก Vendor ทุกเจ้า ครบทุก Impact App ก็เอาข้อมูลไปให้ทีมทำเรื่อง Feasibility หรือพวก Revenue projection ต่อ แล้วเอาไปเสนอกับผู้บริหาร กับ Sponsor ให้ Approve เป็นอันจบให้เริ่มเฟส Execution ได้

ลึกๆจะมีรายละเอียดมากกว่านี้นะครับ เช่น IT Vendor บริษัทในเครือเอง ก่อนจะส่ง Solution มาให้เราได้ ก็ต้องมีผ่านพวกคณะ EA, IT security ก่อน หรือถ้าเป็นการจ้าง Vendor ภายนอก ก็ต้องมี Process พวก Vendor selection ซึ่งเราก็ต้องช่วย Manage อะไรก็ว่ากันไป

3) Project Execution

เฟสนี้ก็จะเป็นเฟสที่เราเริ่ม Kick-off ทำงานจริงๆ และเรียกได้ว่าเป็นพาร์ทที่ยาวที่สุด ผลบุญของเฟส Planning ก็จะงอกให้เห็นชัดๆในเฟสนี้แหละ ซึ่งความจริงมันก็คงไม่ Perfect หมดหรอก ก็คงต้องมีปรับระหว่างทางให้การทำงานทุกวันมันดีขึ้น โดยหน้าที่ Project Manager คือพยายามคุมภาพรวมให้ได้งานตามแผน มีอะไรขาดก็ต้องช่วย Support

โดย Key Factor หลักๆที่ทำให้เฟสนี้สำเร็จเลย คือ การ Communication ในฐานะที่เราเป็น PM เราจะสื่อสารให้คนจำนวนมากๆใน Project ให้เข้าใจตรงกัน และรู้หน้าที่ตัวเองได้อย่างไร

ต้องคุยเช็กทั้ง Product Manager ทั้ง DM ที่ต้องดูฝั่ง IT รวมถึง PM ของฝั่ง Vendor โดยเนื่องจากเราเป็น Project Manager ฝั่ง BU ไม่ใช่ IT จริงๆ Scope งานของที่เราต้องไปคุม BA, Dev, Tester ก็ขึ้นอยู่กับ DM ฝั่ง IT ที่ตกลงกันในแต่ละ Project เลยที่เป็นคนดูหลัก โดยผมขอยกตัวอย่างแบบ Waterfall แต่ละ Stage ที่ทำในเฟสนี้ก็มีประมานนี้ครับ ซึ่งถ้าเป็น Agile ก็อาจแบ่งหลาย Iteration อะไรก็ว่ากันไป

ในแต่ละ Stage ตามรูป มันก็จะมี Task ย่อยๆที่แต่ละส่วนงานต้องทำ เริ่มตั้งแต่

1. Requirement >> เป็นพาร์ทที่ลง Detail ลึกขึ้น ตำแหน่งหลักที่มีส่วนร่วมก็จะเป็น Product Manager ผู้ให้ Requirement กับ Business Analyst ผู้เจียระไน Requirement และถ้าเป็นบริษัทใหญ่หน่อยก็อาจต้องมีทีม Risk เข้ามาเกี่ยว
2. Design >> เป็นพาร์ท UX/UI designer เริ่มเข้ามาทำหน้าจาก Requirement เริ่มตั้งแต่ Wireframe ไปจนถึง Hi-fi โดยก็จะมี Product Manager และ Business Analyst ที่คอยช่วยรีวิว และฝั่ง System Analyst ก็ช่วย Design database อะไรก็ว่ากันไป
3. Build >> ก็จะเป็นส่วนที่ Dev ทั้ง Frontend และ Backend พัฒนาแอป ในส่วนนี้ PM ฝั่ง BU เราก็อาจจะไม่ได้ยุ่งเกี่ยวมากนัก ซึ่งในช่วงนี้ PM เราก็อาจใช้เวลาไปในการเก็บงานยิบย่อยในโครงการ
4. SIT >> พาร์ทนี้ก็จะเป็นพาร์ทที่ Tester ทำกันเทสภายใน IT กันเอง ซึ่งฝั่ง PM ฝั่ง BU เราก็อาจไม่ค่อยต้องยุ่งเกี่ยวมากกันเช่นกัน โดยช่วงนี้มักจะเป็นช่วงที่ Support Product Manager ให้มี Test Case พร้อมกับการทำส่วนใน UAT ซะมากกว่า แต่ในฐานะ PM เราก็ต้อง Make sure ว่าการ SIT มีคุณภาพนะครับ เพราะ ถ้ายิ่ง SIT แย่ ก็จะยิ่งเป็นการส่ง Defect ต่อ UAT และอาจทำให้เวลาในการ UAT น้อยลง
5. UAT >> พาร์ทนี้ก็จะเป็นที่ Project Manager ฝั่ง BU เรา เริ่มเข้ามามีส่วนร่วมมากขึ้นอีกครั้ง ก็คือจะเป็นพาร์ทที่เราคอยคุม Product Manager ให้เทสเสร็จตามแผนครับ โดยก็จะมี Tester จาก SIT มาช่วย Support ให้อีกที
6. Pentest/NFT >> สำหรับบริษัทใหญ่หน่อย ก็อาจต้องมีการยิง Pentest ทดสอบป้องกันการเจาะระบบด้วย ซึ่งพาร์ทนี้ส่วนใหญ๋ก็เป็นส่วนของ IT จัดการ ส่วน PM ฝั่ง BU เราไม่ได้ Involve มากนัก ในช่วงนี้ฝั่ง BU ก็จะไปเน้นเรื่องจัดการเรื่องฝั่งทีม Operation ที่มาใช้ระบบ ทั้งเรื่อง Training และการทำงานเพื่อ Support อื่น
7. Regression Test >> พาร์ทที่กลับมาเทส UAT หลังทำ Pentest อีกที เพื่อให้ Make sure ว่าหลัง Pentest เปลี่ยนแปลงไป ระบบไม่ได้ Defect อะไรเพิ่มนะ
8. PVT/Pilot Test >> ทำการ Deploy และเทสระบบใน Production ที่จะเอาไปให้ลูกค้าใช้จริงในกลุ่มภายในเล็กๆเทส ซึ่งก็เป็นช่วงก่อนจบที่ทาง PM เข้าไปช่วยจัดการและช่วยลุ้นให้ขึ้นระบบได้
9. Go Live >> ระบบพร้อมให้ลูกค้าใช้บริบูรณ์

ดูเหมือน PM จะไม่ค่อยทำอะไร แต่ในโลกการดำเนิน Project จริง มันจะไม่ค่อยราบลื่นสักเท่าไร มันมักจะมีคำว่า Delay เข้ามาเสมอ

ซึ่งนั่นแหละครับเป็นหน้าที่หลักของ PM ในเฟสนี้คือการตบสิ่งเหล่านั้นให้เข้าที่เข้าทาง ทำทุกอย่างให้ขึ้น Product ตามที่วางแพรนได้

โดย Task ที่ผมยกตัวอย่างมานี้เป็นเพียงพาร์ทของ IT เท่านั้น ในความเป็นจริง มันยังมี Detail พาร์ทของ Business อื่นๆ ที่ PM ต้องไปช่วยจัดการอีกเยอะ เช่น พาร์ท Go to market ว่าจะเปิดตัว Product ต้องสื่อสารอย่างไร ทำ Marketing อย่างไร รวมถึงเรื่อง Onboard คนเข้า Project ที่จะมีการเข้าออกเรื่อยๆ และทำให้เกิด Gap เป็นต้น ซึ่งการที่เราต้อง Involve เยอะมากน้อยแต่ละพาร์ท ก็คือกลับไปที่ เราสามารถหา Resource มาช่วยเติมเต็ม ตอนในเฟส Planning ได้ขนาดไหน 😏

4) Project Closing

เฟสนี้ก็ไม่มีอะไรมาก หลักๆก็จะเป็นเฉลิมฉลองปิด Project และอาจมีการทำ Retrospective ดู Feedback เพื่อใช้การบริหาร Project หน้าให้ดีขึ้น การประเมิน KPI/OKR อันนี้ขึ้นอยู่กับแต่ละองค์กรเลยนะครับ แต่ส่วนตัวถ้าให้ประเมินการทำงานในฐานะ PM เอง ที่นอกจากที่เรา Deliver Product ให้ Go Live ได้สำเร็จแล้ว ผมก็จะไปดูกราฟสามเหลี่ยมเมอร์มิวด้าของ PM นี้ครับ ว่าเราสามารถใช้ Cost, Time และส่งมอบ Product feature ได้ดีขนาดไหนเทียบกับตอน Planning ถ้าเราสามารถทำได้ดีกว่ามาก ก็ขอชมว่า คุณเก่งมากครับ 👍👍

สรุปส่งท้าย

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

ส่วนนี้ก็เป็นสรุปบทเรียนได้ผมได้จากงาน PM ที่ผ่านมา 1 ปีนี้นะฮะ

1. ยอมเหนื่อยหน่อย วางรากฐานช่วง Planning ให้แข็งแรงตั้งแต่ช่วงแรก แต่ผลลัพธ์ที่ได้กลับมารับรองว่าคุ้มค่า
2. ควรทำงาน Manage Project แบบวิ่งมาราธอน ไม่ใช่แบบวิ่งสปีด ควรเลือกทำงานสำคัญที่ไม่เร่งด่วนเป็นหลัก อย่าปล่อยให้ทุกงานเป็นงานสำคัญที่เร่งด่วน จนสุดท้ายเรา Manage ตัวเองไม่ได้
3. เราไม่ใช่ One man show ใน Project ควรมีการหา Resource และ Delegate งานให้เหมาะสม ดั่งคำที่ว่า You can’t save the world alone
4. การ Communication ยังคงเป็น Success Factor ใน Project
5. Manage project ได้แล้ว ก็อย่าลืมดูแลตัวเองด้วย เพราะ อย่าลืมว่างานก็ไม่ใช่ทุกอย่างในชีวิต การเฉลิมฉลอง และการพักผ่อนให้เพียงพอก็เป็นสิ่งสำคัญ

สำหรับเพื่อนๆที่สนใจทำงานหรืออัพสกิลสาย PM แต่ไม่รู้จะเริ่มต้นยังไง ผมแนะนำให้ลองเริ่มเรียนจากคอร์ส Project Managment ของ Google ครับ ซึ่งลองไปอ่านรีวิวในบทความที่ผมเคยเขียนด้านล่างได้

[Review] คอร์ส Google Project Management: Professional Certificate | by Nut P | Medium

[Review] คอร์ส Google Project Management: Professional Certificate

สุดท้ายนี้ ก็ขอขอบพระคุณเพื่อนๆที่ติดตามมาจนจบฮะ สำหรับใครที่อยากให้ผมได้แชร์บทความดีๆแบบนี้อีก ก็อย่าลืมกด Follow ผมกันนะ วันนี้ขอจบเพียงเท่านี้ ขอบคุณครับ🙌🙌