บทเรียนของ PM: พางานไปถึงเป้าหมาย โดยไม่ทิ้งคนไว้ข้างหลัง

โปรเจกต์หนึ่งอาจเริ่มต้นด้วยประโยคง่าย ๆ ว่า “ทำระบบนี้ให้เสร็จภายในไตรมาสหน้า”

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

สุดท้าย Project Manager กลายเป็นคนวิ่งถามทุกฝ่ายว่า

“งานถึงไหนแล้วคะ”
“อันนี้ใครทำต่อคะ”
“ทันไหมคะ”
“ช่วยอัปเดตในบอร์ดด้วยนะคะ”

ทั้งวันหมดไปกับการตามงาน แต่โปรเจกต์กลับไม่ได้ชัดขึ้นเท่าไร

สองหลักสูตรที่ชื่อดูเหมือนแยกจากกัน

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

เลยลองเรียนสองหลักสูตรที่ชื่อดูเหมือนจะแยกจากกัน เรื่องแรกคือ Foundations of Project Management ของ Google ซึ่งสอนเรื่องการตั้งเป้าหมาย วางแผน จัดการขอบเขต ประสานงาน และพาโปรเจกต์ไปให้ถึงปลายทาง อีกเรื่องคือ Create a High-Performing Team ซึ่งพูดถึงการสร้างทีม ตั้งเป้าหมายร่วมกัน และช่วยให้คนทำงานได้ดีขึ้น

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

เมื่อเอาสองเรื่องนี้มาวางข้างกัน เราเริ่มเห็นว่า งานของ Manager ไม่ได้มีสองโหมดแยกกันว่า ตอนนี้จัดการ “งาน” แล้วค่อยไปจัดการ “คน” เพราะทุกครั้งที่เราตั้งเป้าหมาย มอบหมายงาน เปลี่ยนไทม์ไลน์ หรือตามความคืบหน้า เรากำลังจัดการทั้งสองอย่างพร้อมกันอยู่แล้ว

Project Management ช่วยให้เรารู้ว่า ต้องพางานไปทางไหน ส่วน People Management ช่วยให้เราเข้าใจว่า จะพาคนไปถึงตรงนั้นด้วยกันอย่างไร

โปรเจกต์มักเริ่มมีปัญหา ก่อนที่ทีมจะเริ่มทำงานเสียอีก

หนึ่งในสิ่งแรกที่ได้เรียนจาก Google Project Management คือ วงจรของโปรเจกต์ 4 ช่วง

1. Initiateตกลงให้ชัดว่ากำลังแก้ปัญหาอะไร
2. Planวางขอบเขต เวลา คน และความเสี่ยง
3. Executeลงมือทำ ติดตาม และเอาอุปสรรคออก
4. Closeส่งมอบ ถอดบทเรียน และเก็บไปใช้ต่อ

ฟังดูเป็นเรื่องพื้นฐานมาก แต่หลายโปรเจกต์กลับกระโดดข้ามสองช่วงแรกไปอย่างรวดเร็ว ได้รับโจทย์วันจันทร์ เปิดบอร์ดวันอังคาร แบ่งงานวันพุธ แล้วค่อยพบวันศุกร์ว่าแต่ละคนเข้าใจโจทย์ไม่เหมือนกัน

ปัญหาจึงอาจไม่ได้เกิดจากทีมทำงานช้า แต่เกิดจากเรารีบลงมือทำ ก่อนจะตอบคำถามสำคัญให้ชัด

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

ในแบบฝึกหัดหนึ่ง เราได้ลองวางแผนโปรเจกต์แพลตฟอร์มสำหรับให้ครูกรอกเกรด และให้นักเรียนกับผู้ปกครองเข้ามาดูผลการเรียน ถ้าเขียนเป้าหมายแค่ว่า “สร้างแพลตฟอร์มจัดการเกรดให้เสร็จ” ทุกคนอาจตีความคำว่าเสร็จต่างกันได้หมด

แต่เมื่อใช้หลัก Project Initiation ภาพจะเริ่มชัดขึ้นว่า ขอบเขตของงานคือระบบจัดการเกรด ไม่ได้รวมทุกระบบของโรงเรียน สิ่งที่ต้องส่งมอบคือความสามารถในการกรอกและดูเกรดออนไลน์ ครูต้องใช้งานครบ 100% ภายใน 9 เดือน ภายใต้งบประมาณ 150,000 ดอลลาร์ และมีทีม IT สนับสนุนหนึ่งคน

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

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

เครื่องมือที่คุ้น ไม่ได้แปลว่าเหมาะกับทุกงาน

อีกเรื่องที่ได้เรียนคือวิธีบริหารโปรเจกต์หลายรูปแบบ ทั้ง Waterfall, Agile, Scrum, Kanban, Lean และ Six Sigma ชื่อเหล่านี้อาจทำให้ Project Management ดูเป็นวิชาใหญ่ แต่ใจความจริง ๆ ค่อนข้างเรียบง่าย คือไม่มีวิธีไหนดีที่สุดสำหรับทุกโปรเจกต์ เราต้องดูว่างานตรงหน้ามีธรรมชาติแบบไหน

สิ่งที่ควรถามจึงไม่ใช่ “บริษัทอื่นใช้วิธีไหน” แต่คือ ตอนนี้โปรเจกต์ของเราติดตรงไหน และวิธีทำงานแบบใดจะช่วยแก้ปัญหานั้นได้จริง

บางทีมมี Sprint มี Daily Meeting และมีบอร์ดครบทุกอย่าง แต่คนยังไม่รู้ว่าอะไรสำคัญที่สุด แบบนั้นปัญหาอาจไม่ได้อยู่ที่ขาดเครื่องมือ แต่อยู่ที่ขาดความชัดเจน

PM ไม่ควรเป็นเพียงคนที่จำเดดไลน์ได้ดีที่สุด

พอโปรเจกต์เริ่มเดิน ภาพจำของ PM มักกลายเป็นคนคอยอัปเดตสถานะ นัดประชุม และถามว่างานเสร็จหรือยัง แต่ถ้าถามเพียงว่า “งานถึงไหนแล้ว” เราอาจได้แค่เปอร์เซ็นต์กลับมา โดยยังไม่รู้เลยว่างานกำลังมีปัญหาอะไร

คำถามที่ช่วยทีมได้มากกว่า อาจเป็น

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

ตรงนี้ทำให้เห็นว่า PM ไม่ได้มีหน้าที่เพียง “ตามงาน” แต่ต้องช่วยเอาสิ่งที่ขวางทีมออกไปด้วย บางครั้งสิ่งที่ขวางไม่ใช่เรื่องเทคนิค แต่อาจเป็น Requirement ที่ยังไม่ชัด ผู้มีส่วนได้ส่วนเสียเห็นไม่ตรงกัน ไม่มีคนตัดสินใจ หรือทีมไม่กล้าบอกว่าไทม์ไลน์เดิมไปต่อไม่ได้แล้ว

Project Manager หลายคนต้องทำสิ่งเหล่านี้โดยไม่ได้มีอำนาจสั่งทุกฝ่ายโดยตรง จึงต้องใช้ทักษะที่เรียกว่า Influence without authority หรือการทำให้คนเห็นและร่วมตัดสินใจ โดยไม่ต้องใช้อำนาจสั่ง

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

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

เมื่อดูแลทีม ความสำเร็จไม่ได้วัดจากงานที่เราทำเองอีกแล้ว

จุดนี้เชื่อมเข้าสู่เรื่องที่สองพอดี Create a High-Performing Team เริ่มจากการเปลี่ยนวิธีคิด เมื่อเราขยับจากคนที่รับผิดชอบงานของตัวเอง ไปเป็นคนที่ต้องดูแลผลงานของทั้งทีม

ตอนเป็น Individual Contributor ถ้ามีงานยาก เราอาจลงมือทำเอง แล้ววัดความสำเร็จจากคุณภาพของสิ่งที่ส่งออกไป แต่เมื่อเป็น Manager ถ้าเรายังคอยรับงานยากทั้งหมดกลับมาทำเอง ทีมอาจส่งงานทันในครั้งนี้ แต่คนอื่นไม่ได้เรียนรู้ ส่วน Manager ก็กลายเป็นคอขวดของทุกเรื่อง

ความสำเร็จของ Manager จึงไม่ได้อยู่ที่ว่าเราทำแทนทุกคนได้เก่งแค่ไหน แต่อยู่ที่เราสร้างสภาพแวดล้อมให้ทีมทำงานได้ดีเพียงใด ในหลักสูตร หน้าที่ของ Manager ถูกแบ่งออกเป็น 3 ด้าน

• Build Community — ทำให้คนรู้สึกว่าเป็นส่วนหนึ่งของทีมและทำงานร่วมกันได้
• Deliver Results — ช่วยให้ทีมสร้างผลลัพธ์ที่ต้องการ
• Develop People — สนับสนุนให้แต่ละคนเรียนรู้และเติบโต

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

ทีมที่ทำงานได้ดีจึงต้องมีทั้ง Clarity, Meaning และ Impact ทุกคนต้องรู้ว่ากำลังทำอะไร เข้าใจว่าทำไมงานนี้จึงสำคัญ และมองเห็นว่าสิ่งที่ตัวเองทำส่งผลต่อทีม ผู้ใช้ หรือองค์กรอย่างไร

เพราะคนทำงานได้ยากมาก หากรู้เพียงว่า “ต้องส่งอะไรวันไหน” แต่ไม่รู้ว่าสิ่งนั้นกำลังช่วยใครหรือแก้ปัญหาอะไรอยู่

เป้าหมายที่ดีต้องเดินทางจากสไลด์มาถึงงานของแต่ละคน

เรื่องที่เชื่อมสองหลักสูตรเข้าด้วยกันชัดที่สุด คือการตั้งเป้าหมายของทีม

Project Management ถามว่า เป้าหมายของโปรเจกต์คืออะไร และจะวัดความสำเร็จอย่างไร
People Management ถามต่อว่า แล้วคนในทีมเข้าใจเป้าหมายนั้นเหมือนกันหรือยัง

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

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

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

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

เป้าหมายที่ดีไม่ได้บอกแค่ว่าจะไปไหน แต่ช่วยให้ทีมรู้ด้วยว่า ระหว่างทางควรตอบ “ใช่” หรือ “ไม่” กับอะไร

ทุกการเปลี่ยนแผน กระทบทั้งงานและคน

เมื่อเอา Project Management และ People Management มารวมกัน เราจะเริ่มมองเหตุการณ์เดิมได้ลึกขึ้น

ตอนกำหนด Scope เราไม่ได้จัดการเพียงรายการงาน แต่กำลังจัดการความคาดหวังของคนหลายฝ่าย ตอนเปลี่ยน Timeline เราไม่ได้ขยับแค่วันที่บนแผน แต่กำลังเปลี่ยนลำดับชีวิตการทำงานของทั้งทีม

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

ตอนปิดโปรเจกต์ เราไม่ได้มีเพียงไฟล์ที่ส่งมอบ แต่ยังมีบทเรียน ความสัมพันธ์ และวิธีทำงานที่ทีมจะพกไปยังโปรเจกต์ถัดไป

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

ถ้าต้องเริ่มเป็น PM พรุ่งนี้ ลองเริ่มจากสิ่งเหล่านี้

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

ก่อนเริ่มโปรเจกต์

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

ระหว่างทำงาน

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

เวลาคุยกับทีม

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

ตอนจบโปรเจกต์

• เราส่งมอบตามเป้าหมายหรือไม่
• อะไรทำให้ทีมทำงานได้ดี
• อะไรควรหยุดทำ ปรับ หรือทำต่อ
• คนในทีมได้เรียนรู้อะไรจากงานนี้
• โปรเจกต์ถัดไปควรเริ่มต่างจากเดิมตรงไหน

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

5 เรื่องที่อยากพกไปใช้กับทุกโปรเจกต์ต่อจากนี้

1. อย่ารีบเริ่ม จนลืมทำให้เป้าหมายชัด

   งานที่เริ่มช้ากว่าเล็กน้อย แต่เข้าใจตรงกัน อาจไปถึงปลายทางเร็วกว่างานที่รีบเปิดบอร์ดตั้งแต่วันแรก

2. PM ไม่ได้มีหน้าที่ตามงาน แต่ช่วยให้ทีมเดินต่อได้

   การรู้ว่างานช้าไม่พอ ต้องรู้ว่าอะไรทำให้ช้า และใครช่วยเอาสิ่งกีดขวางนั้นออกได้

3. ทุกครั้งที่รับงานเพิ่ม ต้องยอมรับผลกระทบที่ตามมา

   Scope เวลา และทรัพยากรเชื่อมกันเสมอ เราเพิ่มอย่างหนึ่งโดยไม่ขยับอีกอย่างไม่ได้

4. Manager ไม่จำเป็นต้องเป็นคนที่ทำทุกอย่างเก่งที่สุด

   แต่ต้องช่วยให้คนในทีมเข้าใจ รับผิดชอบ ตัดสินใจ และเติบโตได้มากขึ้น

5. ผลลัพธ์ที่ดีไม่ควรแลกมาด้วยการทำให้ทีมหมดแรง

   โปรเจกต์ไม่ได้จบแค่วันที่ส่งมอบ เพราะคนกลุ่มเดิมอาจต้องกลับมาทำงานร่วมกันอีกในวันถัดไป

สุดท้ายแล้ว Project Management ทำให้เราเห็นโครงของงาน ส่วน People Management ทำให้เราไม่ลืมว่า งานทั้งหมดนั้นกำลังเกิดขึ้นผ่านคนจริง ๆ