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

0. ปฏิเสธงานนี้เมื่อคุณยังมีโอกาส!!!

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

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

1. รู้และเข้าใจในหน้าที่ของ Project Manager

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

1. ต้องคุยกับ Project Sponsor ให้รู้เรื่อง ความหมายคือต้องคุยกันได้อะ ไม่ใช่ว่าเริ่มประโยคแรกก็จะตีกันแล้วแบบนี้ไม่รอดแน่นอน สถานการณ์ส่วนใหญ่เรามักจะเป็นผู้น้อย นั้นก็หมายความว่าเราต้องอ่อนน้อมถ่อมตนพอสมควรในขณะเดียวกันก็ต้องกล้าพูดและแสดงออกในสิ่งที่เราคิดว่าถูกหรือผิด
2. หา Key Stakeholder ของ Project ให้เจอ หาอย่างเดียวไม่พอต้องเตรียมการดูแลเอาใจใส่เค้าเหล่านั้นอย่างเป็นระบบด้วย เค้าเหล่านั้นอาจจะเป็น Project Sponsor (เจ้าของบริษัท), Product Manager หรือ Sales Team ที่ไปเก็บ Requirement มาจากลูกค้า, Resource Manager ที่เป็นคนดูแล Developer/Tester ของเรา, Vice President จากบริษัทลูกค้า, Department Manager จากบริษัทลูกค้าที่เราเค้าไปทำ Project ให้เค้า และ End Users ซึ่งเป็นคนใช้งานระบบของเรา เป็นต้น
3. จัดการรวบรวมทีมงานของเราขึ้นมา ก็หน้าที่ของ Project Manager เหมือนกันนะครับ เราต้องเลือกคนให้เหมาะกับงาน (แน่นอน เราต้องรู้ก่อนว่าเราต้องทำอะไรบ้าง) แต่บางครั้งอะไรๆมันก็ไม่ง่ายแบบนั้น บางครั้งคนไม่พอ บางครั้งคนที่มีประสบการณ์ไม่ว่าง แต่ทำไงได้สุดท้ายก็ต้องเปิด Project อยู่ดี สิ่งที่เราทำได้ดีที่สุดตอนนี้คือแจ้งความเสี่ยงเรื่องคนที่ว่านี้ให้ Project Sponsor รับทราบ ถ้างานของเราสำคัญจริง Project Sponsor ควรจะช่วยจัดการหาคนอย่างที่เราต้องการมาให้ (หวังไว้ก่อน) อีกส่วนที่จะช่วยลดผลกระทบจากความเสี่ยงนี้ได้คือตอนทำ Project Plan ครับ บวกความเสี่ยงเรื่องนี้เข้าไปใน Project Plan ด้วยก็ไม่เสียหลาย
4. ทำ Project Plan แล้วอย่าลืมคอย Update หละ ไม่ใช่ว่าทำเสร็จแล้วก็ปล่อยไว้อย่างงั้นแล้วเอาเวลาไปนั่งหวังว่าอะไรๆมันจะเป็นไปอย่างที่ Plan ไว้ แล้วก็อย่ามองข้ามเรื่องเล็กๆน้อยๆในการทำ Project Plan ที่ดีด้วยนะครับ
5. เรื่องของ Estimation ก็เป็นเรื่องสำคัญที่ Project Manager ต้องดูแล จริงๆแล้วคนที่ต้องรับผิดชอบตัวเลข Estimation ที่ออกมาคือ Line Manager นะ แต่เราก็มีหน้าที่รีวิวและตั้งคำถามกับตัวเลขเหล่านั้นด้วยครับ เฮ้ย Task นี้ไม่น่าจะใช้เวลาตั้ง 2 สัปดาห์นะ หรือว่า เอ๋ … เขียนเอกสารแค่ 5 วันเองหรอ? จะพอมั้ยแล้วนี่รวมส่วนของการรีวิวเอกสารด้วยรึเปล่าเนี่ยะ? และเพื่อความปลอดภัย บวก Buffer เพื่อเข้าไปหน่อยด้วยนะครับ
6. หา Risk ของ Project ให้ได้มากที่สุดและเตรียมการป้องกันหรือแนวทางแก้ไขปัญหาไว้ด้วย ส่วนตัวผมเองผมทำจริงๆจังๆเลยนะเรื่อง Risk Management เนี่ยะ มีประโยชน์มากครับ มันช่วยให้เราทำ Project Plan ได้ถูกต้องมากขึ้น มันทำให้เราได้เตรียมทางหนีทีไล่ไว้แต่เนิ่นๆ และมันยังทำให้เรามีเรื่องไปคุยกับ Project Sponsor ได้เรื่อยๆ เช่น “พี่ครับ จำได้มั้ยเมื่อเดือนที่แล้วผมแจ้งว่าตอนนี้เรามี Risk ตัวใหญ่อยู่หนึ่งตัวคือเรื่องที่ Project ผมยังหา Database Expert ไม่ได้เลย ถ้าปล่อยไปถึงสิ้นเดือนนี้จะทำให้งานไปต่อไม่ได้แล้วนะครับ” … หวังว่า Project Sponsor จะช่วยได้ แต่เอ้า ต่อให้ช่วยไม่ได้อย่างน้อยเราก็ไม่ผิดคนเดียวหละวะก็ในเมื่อเราไม่มีอำนาจจะไปสั่งให้ใครคนไหนมาทำงานให้เรานี่ เนอะ ฮ่าๆ
7. บางครั้ง Communication Plan ก็เป็นส่วนสำคัญของ Project นะครับ ยิ่งกับ Project ใหญ่ๆที่มีคนสนใจเยอะๆ ไหนจะทั้งคนทำงานจริง ไหนจะ Stakeholder อีกมากมายก่ายกอง การสื่อสารเป็นเรื่องสำคัญมาก (มากๆ) ที่จะทำไหน Project เดินหน้าไปได้ เราในฐานะ Project Manager ต้องวางหลักการที่ชัดเจนว่า (1) ใคร (2) จะได้ข้อมูลประเภทไหน (3) เมื่อไร และ (4) อย่างไร
8. จัดให้มี Project Tracking Meeting จะเป็นทุกวัน ทุกสัปดาห์ สัปดาห์เว้นสัปดาห์ หรือทุกเดือนก็แล้วแต่ความเหมาะสม ที่สำคัญคือควรทำอย่างสม่ำเสมอและกำหนดหัวข้อในการพูดคุย (Meeting Agenda) ให้ชัดเจน ทั่วๆไปก็จะมี (1) Current Status ว่าตอนนี้ Project ทำไปถึงไหนแล้ว (2) Future Tasks ที่กำลังจะทำต่อไป (3) Risks/Issues ที่มี (4) Changes ที่เข้ามา (5) Action Items (6) อื่นๆ
   
9. ต่อจากข้อที่แล้ว เมื่อจบการประชุมแล้วเราก็ควรจะทำสรุปผลการประชุม (Meeting Minutes) ด้วยเพื่อยืนยันความเข้าใจและเพื่อใช้เป็นหัวข้อในการประชุมครั้งต่อไป เคล็ดลับของผมคือจะใส่ งานที่ต้องทำ + คนรับผิดชอบ + วันที่ต้องเสร็จ ไว้ด้วยเสมอ … จะได้เอาไว้ตามจิก จึ๊กๆๆ วันหลัง ฮ่าๆ
10. ทำหน้าที่บริหารจัดการ Change ที่เข้ามาใน Project อย่างสม่ำเสมอ ขั้นตอนก็เริ่มจากเก็บข้อมูลว่าตอนนี้มี Change อะไรเกิดขึ้นใน Project บ้าง ถ้าเราตัดสินใจรับ/ไม่รับ Change ตัวนี้ได้เองก็ทำไปเลย แต่ถ้ามันเป็นอะไรที่ใหญ่กว่านั้น เราก็ควรจะเอาไปคุยกับ Project Sponsor และ Stakeholder เพื่อให้ท่านๆเค้าตัดสินใจมาครับ เพื่อนๆอาจจะสงสัยว่ามีด้วยหรอ Change ที่เราจัดการเองไม่ได้ มีครับ (บ่อยด้วย) เช่น ลูกค้าขอให้ทำ Requirement เพิ่มโดยไม่มีระบุในสัญญา แถมจะทำให้ Project ต้อง Delay ไปอีก 2 เดือน … ใหญ่ขนาดนี้ เกี่ยวกับเงินทองและกฎหมายแบบนี้ ปล่อยให้ผู้มีอำนาจเค้าจัดการจะดีกว่านะ
11. ต้องควบคุมดูแลคุณภาพของงานที่ออกมาด้วยนะครับ จะทำแค่ Track Project ว่างานไหนเสร็จ/ไม่เสร็จมันไม่พอครับ ต้องเข้าไปดูในรายละเอียดด้วยว่างานที่เสร็จออกมามีคุณภาพมากน้อยแค่ไหน บางครั้งเราอาจจะดีใจที่งาน Coding เสร็จเร็วกว่ากำหนด แต่ขอโทษนะ บั๊กกระจายแบบนี้ก็ไม่ไหวครับ แล้วถ้าเจอปัญหาเรื่องคุณภาพก็ต้องหาทางแก้ไขด้วยนะ อย่าปล่อยไว้แบบนั้นเพราะว่าสุดท้ายแล้วมันจะทำให้ Project Delay อยู่ดีเพราะลูกค้าไม่รับผล User Acceptance Test (UAT) แถมเสียเชื่อบริษัทด้วย แต่ชีวิตไม่ง่ายเสมอไป หลายครั้งที่งาน Coding เสร็จช้ากว่ากำหนดจนทำให้เวลาที่เตรียมไว้สำหรับ Testing มันเหลือน้อยลงกว่าเดิม เราก็ต้องหาทางออกที่ดีที่สุดที่จะสร้างสมดุลของคุณภาพงานและเวลาที่เหลืออยู่ด้วยครับ
12. หมั่นตรวจสอบงานอื่นๆที่นอกเหนือจาก Software Development ด้วย หลายครั้งความสนใจของ Stakeholders และเราจะอยู่กับแค่เรื่อง Software Development แต่ Project เรามีมากกว่านั้นครับ เช่น Documents ต่างๆ หรือการทำ Training ให้ลูกค้า งานพวกนี้มีอยู่ใน Project Plan รึยัง? มีคนรับผิดชอบรึยัง? แล้วมีการติดตามความคืบหน้าและปัญหาของงานเหล่านี้รึยัง? สำคัญนะครับ
13. หาเวลาพูดคุยกับน้องๆในทีมเป็นการส่วนตัวบ้าง มันเป็นเรื่องของการบริหารคนครับ การที่จะสร้างทีมที่เข้มแข็งมันต้องเริ่มมาจากการไว้ใจซึ่งกันและกันก่อนซึ่งการที่เราเปิดโอกาสให้น้องๆได้แสดงออกถึงสิ่งที่เค้าคิดสิ่งที่เค้าเห็นกับการทำงานใน Project นี้จะช่วยให้เราสร้างความสัมพันธ์ที่ดีได้และที่สำคัญไปกว่านั้นคือเราจะได้รู้ข้อมูลวงในมากขึ้นด้วย
14. อย่าทำงานแบบ Micro-Management นั่นคืออย่าจู้จี้ อย่าจุกจิก อย่าชี้นิ้วสั่ง อย่าไปเกาะหลังเก้าอี้ใครแล้วก็สั่งให้ทำนู่นทำนี่ ไม่มีใครชอบหรอกครับ เราต้องมีความเชื่อมั่นในทีมงานที่เราเลือกหรือเรามี (ในกรณีที่ไม่ได้เลือกเอง) เมื่อเรามอบหมายงานแล้วควรปล่อยให้เค้าใช้ความรู้ความสามารถของเค้าในการจัดการงานนั้นเองโดยมีเราช่วยเป็นคนติดตามดูแลและสนับสนุนอยู่ห่างๆ ถ้าเห็นว่าเริ่มมีปัญหาค่อยยื่นมือเข้าไปช่วยครับ
15. พยายามสร้างทีมงานที่จะทำงานได้เองแม้จะไม่มีเราอยู่ด้วย ไม่รู้สิ ผมชอบถ่ายทอดความรู้และประสบการณ์ให้กับใครก็ตามที่สนใจเรื่องพวกนี้ ด้วยความหวังว่าวันหนึ่งเค้าจะทำงานกันได้เองโดยไม่ต้องพึ่งผม มันเป็นการช่วยพัฒนาคนให้กับบริษัทด้วย เวลาผมทำ Project Plan หรือพวก Risk เนี่ยะ ผมจะไม่ทำคนเดียวครับ แต่จะเชิญหัวหน้าทีมหรือใครที่สนใจเข้ามามีส่วนร่วมด้วยเสมอ เพื่อให้เค้าได้ออกความคิดเห็นในเรื่องที่ผมมองข้ามไปซึ่งช่วยให้งานผมรอบคอบมากขึ้น รวมถึงเป็นโอกาสให้คนอื่นๆในทีมได้เรียนรู้กระบวนการ Project Management ไปด้วยครับ

ตอนแรกว่าจะเขียนหลายข้อแต่ไปๆมาๆ ข้อเดียวก็ยาวปรี๊ดแล้ว … ที่เหลือเก็บไปต่อภาคหน้าแล้วกันนะครับ

ไม่แน่ใจเหมือนกันว่าจะมีใครมีความฝันสมัยเด็กว่า “โตขึ้น ผม/หนู อยากเป็น Project Manager ครับ/ค่ะ” ตอนเด็กอาจจะไกลตัวไป เอาให้ใกล้เข้ามาอีกหน่อย ตอนเรียนจบใหม่ ใครบ้างอยากเป็น Project Manager ยกมือขึ้น … มีบ้างป่าว? ผมไม่ใช่คนหนึ่งหละ ฮ่าๆ

ไม่แน่ใจ (อีกครั้ง) ว่ามันจะเป็นเพราะหลักสูตรการศึกษาของเรารึเปล่าที่ทำให้ตำแหน่ง Project Manager ไม่ค่อยเป็นที่รู้จักมากนัก จำได้คลับคล้ายคลับคลาว่า … ผมไม่ได้เรียนวิชาที่เกี่ยวกับ Project Management ในหลักสูตรปริญญาตรีเลยด้วยมั้ง งั้นเด็กจบใหม่ส่วนใหญ่ฝันถึงอะไรกัน? เดาว่าคงหนีไม่พ้น Developer, Tester, Network Engineer, Database Administrator, Graphic Designer, และอาชีพอื่นๆที่เน้นความสามารถทางเทคนิค (Technical Skill) เมื่อเริ่มงานแล้วความสนใจทั้งหมดก็จะมุ่งไปที่การทำงานและการพัฒนาทักษะทางเทคนิคเหล่านั้น

แต่ชีวิตจะมาพลิกผันก็ตอนที่ตื่นเช้ามาแล้วกลายเป็น Project Manager แบบไม่ทันตั้งตัวนี่แหละ จริงอยู่ที่ตำแหน่ง Project Manager นั้นต้องอาศัยประสบการณ์การทำงานอยู่ซักหน่อย แต่หลายครั้งเวลาก็ไม่ค่อยท่าเมื่อหัวหน้ามองเห็นศักยภาพในตัวเรา (เร็วไป) และมอบหมายตำแหน่งนี้ให้อย่างปัจจุบันทันด่วนโดยที่เรายังไม่ได้เตรียมตัว จากคนที่เคยทำงานอยู่กับความรู้และความถนัดที่ได้ร่ำเรียนมาถึงตอนนี้ต้องเจอกับความเปลี่ยนแปลงครั้งใหญ่ในอาชีพซะแล้ว จะทำยังไงดี?

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

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

วันนี้มาว่ากันด้วยเรื่อง Knowledge Sharing ภายในทีม … สถานการณ์ที่เจอบ่อยก็คือความรู้ในงานไปกระจุกตัวอยู่แค่คนไม่กี่คน ถ้าโชคร้ายหน่อยก็มีคนรู้เรื่องอยู่คนเดียว แบบนี้ปัญหาจะตามมาเมื่อคนนั้นไม่อยู่ (ลาป่วย ลากิจ ลาออก) หรือไม่ว่าง งานทั้งหมดก็ต้องหยุดไปด้วย ไม่ดีแน่นอนครับ … หาทางแก้ปัญหานี้กันดีกว่า

สาเหตุ

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

1. เพราะคนในทีมไม่คุยกัน
2. เพราะไม่มีเวลา
3. เพราะงานอื่น (เช่น Requirement, Design, Code, Test) สำคัญกว่าการทำ Knowledge Sharing
4. เพราะว่า Scope กับ Schedule ถูกกำหนดไว้แล้ว
5. เพราะไม่รู้จะ Share อะไรนี่
6. เพราไม่รู้ต้องทำอะไรบ้าง
7. เพราะวางแผนมาไม่ดีเลยไม่มีเวลาให้กับเรื่องนี้
8. เพราะบรรยากาศไม่เอื้ออำนวย
9. เพราะปัญหาการเมือง
10. เพราะมีอะไรหัวหน้าทำเองหมด
11. และอีกมากมาย

แนวทางแก้ไข

ในความคิดของผมเองนะครับ ถ้าสถานการเป็นแบบนี้หมายความว่าเรามีลักษณะการทำงานใน Project อยู่สามแบบ หนึ่งคืองานที่ทำโดยคนๆเดียวมาตั้งแต่ต้นแล้วก็คิดว่าจะให้คนๆเดียวทำต่อไป (ด้วยความจำเป็นบางประการ) สองคืองานที่ทำโดยคนๆเดียวมาตั้งแต่ต้นแต่จากนี้ไปไม่เอาแล้ว ต้องมีคนอื่นเข้าไปช่วยเพื่อเป็นการเรียนรู้ไปด้วยกัน และสามคืองานที่ทำโดยกลุ่มคนกลุ่มหนึ่งแล้วเราต้องการจะขยายฐานความรู้ให้คนในกลุ่มอื่นด้วย เช่น จาก Dev – Dev, จาก Dev – QA, จาก QA – Dev, และจาก QA – QA

ผมจะตั้งวัตถุประสงค์ไว้ว่า

1. งานประเภทแรกจะต้องมีให้น้อยที่สุดด้วยการสร้างรูปแบบการทำงานที่เป็นแบบที่สองให้มากขึ้น
2. เมื่อถึงเวลาที่เหมาะสมก็จะขยายฐานความรู้ให้กว้างออกไปจนเป็นการทำงานแบบที่สาม
3. สร้างแนวทางการทำ Knowledge Sharing ให้ชัดเจนเพื่อประโยชน์ในระยะยาว
4. พยายามหาทางที่จะทำให้ Knowledge Sharing เกิดขึ้นไปพร้อมๆกับการทำงานหลัก

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

กดที่รูปเพื่อ Download PDF version

ขอบคุณที่ติดตามผลงานมาโดยตลอดครับ