ไม่แน่ใจเหมือนกันว่าจะมีใครมีความฝันสมัยเด็กว่า “โตขึ้น ผม/หนู อยากเป็น Project Manager ครับ/ค่ะ” ตอนเด็กอาจจะไกลตัวไป เอาให้ใกล้เข้ามาอีกหน่อย ตอนเรียนจบใหม่ ใครบ้างอยากเป็น Project Manager ยกมือขึ้น … มีบ้างป่าว?
ไม่แน่ใจ (อีกครั้ง) ว่ามันจะเป็นเพราะหลักสูตรการศึกษาของเรารึเปล่าที่ทำให้ตำแหน่ง Project Manager ไม่ค่อยเป็นที่รู้จักมากนัก จำได้คลับคล้ายคลับคลาว่า … ผมไม่ได้เรียนวิชาที่เกี่ยวกับ Project Management ในหลักสูตรปริญญาตรีเลยด้วยมั้ง งั้นเด็กจบใหม่ส่วนใหญ่ฝันถึงอะไรกัน? เดาว่าหนีไม่พ้น Developer, Tester, Network Engineer, Database Administrator, Graphic Designer, และอาชีพอื่นๆที่เน้นความสามารถทางเทคนิค (Technical Skill) เมื่อเริ่มงานแล้วความสนใจทั้งหมดก็จะมุ่งไปที่การทำงานและการพัฒนาทักษะทางเทคนิคเหล่านั้น
แต่ชีวิตจะมาพลิกผันก็ตอนที่ตื่นเช้ามาแล้วกลายเป็น Project Manager แบบไม่ทันตั้งตัวนี่แหละ จริงอยู่ที่ตำแหน่ง Project Manager นั้นต้องอาศัยประสบการณ์การทำงานอยู่ซักหน่อย แต่หลายครั้งเวลาก็ไม่ค่อยท่าเมื่อหัวหน้ามองเห็นศักยภาพในตัวเรา (เร็วไป) และมอบหมายตำแหน่งนี้ให้อย่างปัจจุบันทันด่วนโดยที่เรายังไม่ได้เตรียมตัว จากคนที่เคยทำงานอยู่กับความรู้และความถนัดที่ได้ร่ำเรียนมาถึงตอนนี้ต้องเจอกับความเปลี่ยนแปลงครั้งใหญ่ในอาชีพซะแล้ว จะทำยังไงดี?
ข้อมูล 15 ข้อด้านล่างเป็นสิ่งที่ Project Manager ควรรู้และปฎิบัติ … ไม่อยากจะบอกว่าเพื่อทำให้โปรเจกต์สำเร็จเลย มันดูเกินจริงไปนิดนึง เอาแค่ว่าเพื่อการทำงานอย่างมั่นใจและเพิ่มโอกาสที่โปรเจกต์เราจะสำเร็จแล้วกันนะ ทั้งหมดนี้มาจากความคิดและหลักการทำงานของตัวผมเอง เริ่มต้นที่ข้อ 0
0. ปฏิเสธงานนี้เมื่อคุณยังมีโอกาส!!!
ฮ่าๆ ถ้าใจไม่รักจริง อย่ามาทำเล้ยยย เหนื่อยนะ โดยเฉพาะ “เหนื่อยใจ” … จริงๆแล้วงานมันไม่ยากหรอก คนต่างหากที่ทำให้มันยาก แล้ว Project Manager นี่เหมือนเป็นกระโถนรองรับเรื่องแย่ๆทั้งหลายที่เกิดขึ้นจากคนในทีมและนอกทีมเลยหละ
แต่ก็ไม่ได้ว่าอะไรถ้าจะตัดสินใจท้าทายตัวเอง อยากขยับออกจาก Comfort Zone อยากเข้าใจว่าโดนจริงเจ็บจริงเป็นยังไง ฮ่าๆ … ผมก็รับรองได้อีกเหมือนกันว่าเราจะได้ประสบการณ์ที่แปลกใหม่ (ไม่ได้การันตีว่ามันจะดีเสมอไป) ได้เรียนรู้และพัฒนาทักษะใหม่ๆ … ลองทุ่มเทกับมันดู คุ้มค่าแน่นอน
ยินดีต้อนรับ Project Manager น้องใหม่ทุกคน หน้าที่ของพวกคุณมีข้อเดียวคือ
ทำให้โปรเจกต์ประสบความสำเร็จ
อันนั้นมันคำพูดกว้างๆหละนะ แต่ผมอยากให้เราคิดลึกไปกว่านั้น เพราะการที่จะได้มาซึ่งความสำเร็จ คนที่เป็น Project Manager (ในแบบของผม) มีหน้าที่ที่ต้องทำเพียบเลย
- ต้องคุยกับ Project Sponsor ให้รู้เรื่อง ความหมายคือต้องคุยกันได้อะ ไม่ใช่ว่าเริ่มประโยคแรกก็จะตีกันแล้วแบบนี้ไม่รอดแน่นอน สถานการณ์ส่วนใหญ่เรามักจะเป็นผู้น้อย นั้นก็หมายความว่าเราต้องอ่อนน้อมถ่อมตนพอสมควรในขณะเดียวกันก็ต้องกล้าพูดและแสดงออกในสิ่งที่เราคิดว่าถูกหรือผิด
- หา Key Stakeholder ของ Project ให้เจอ หาอย่างเดียวไม่พอต้องเตรียมการดูแลเอาใจใส่เค้าเหล่านั้นอย่างเป็นระบบด้วย เค้าเหล่านั้นอาจจะเป็น Project Sponsor (เจ้าของบริษัท), Product Manager หรือ Sales Team ที่ไปเก็บ Requirement มาจากลูกค้า, Resource Manager ที่เป็นคนดูแล Developer และ Tester ของเรา, Vice President จากบริษัทลูกค้า, Department Manager จากบริษัทลูกค้าที่เราเค้าไปทำงานให้เค้า และ End Users ซึ่งเป็นคนใช้งานระบบของเรา เป็นต้น
- จัดการรวบรวมทีมงานของเราขึ้นมา ก็หน้าที่ของ Project Manager เหมือนกันนะ เราต้องเลือกคนให้เหมาะกับงาน (แน่นอน เราต้องรู้ก่อนว่าเราต้องทำอะไรบ้าง) แต่บางครั้งอะไรๆมันก็ไม่ง่ายแบบนั้น บางครั้งคนไม่พอ บางครั้งคนที่มีประสบการณ์ไม่ว่าง แต่ทำไงได้สุดท้ายก็ต้องเปิดโปรเจกต์อยู่ดี สิ่งที่เราทำได้ดีที่สุดตอนนี้คือแจ้งความเสี่ยงเรื่องคนที่ว่านี้ให้ Project Sponsor รับทราบ ถ้างานของเราสำคัญจริง Project Sponsor ควรจะช่วยจัดการหาคนอย่างที่เราต้องการมาให้ (หวังไว้ก่อน) อีกส่วนที่จะช่วยลดผลกระทบจากความเสี่ยงนี้ได้คือตอนทำ Project Plan บวกความเสี่ยงเรื่องนี้เข้าไปด้วยก็ไม่เสียหลาย
- ทำ Project Plan แล้วอย่าลืมคอย Update หละ ไม่ใช่ว่าทำเสร็จแล้วก็ปล่อยไว้อย่างงั้นแล้วเอาเวลาไปนั่งหวังว่าอะไรๆมันจะเป็นไปอย่างที่ Plan ไว้ แล้วก็อย่ามองข้ามเรื่องเล็กๆน้อยๆในการทำ Project Plan ที่ดีด้วยนะ เช่น รวมเรื่อง Riskเข้ามา, กำหนด Milestone ให้ชัดเจน, คิดเรื่อง Buffer ไว้บ้างแต่อย่าปล่อยให้มี Student Syndrome จนน่าเกลียด, มีเรื่องวันหยุดวันลาของน้องในทีมด้วยนะ
- เรื่องของ Estimation ก็เป็นเรื่องสำคัญที่ Project Manager ต้องดูแล จริงๆแล้วคนที่ต้องรับผิดชอบตัวเลข Estimation ไม่ใช่เราโดยตรง อาจจะเป็น Line Manager หรือเป็นคนในทีมเอง อย่างน้อยเรามีหน้าที่รีวิวและตั้งคำถามกับตัวเลขเหล่านั้นด้วย เฮ้ย Task นี้ไม่น่าจะใช้เวลาตั้ง 2 สัปดาห์นะ หรือว่า เอ๋ … เขียนเอกสารแค่ 5 วันเองหรอ? จะพอมั้ยแล้วนี่รวมส่วนของการรีวิวเอกสารด้วยรึเปล่าเนี่ยะ?
- หา Risk ของโปรเจกต์ให้ได้มากที่สุดและเตรียมการป้องกันหรือแนวทางแก้ไขปัญหาไว้ด้วย ตัวผมเองผมทำจริงจังเลยนะเรื่อง Risk Management มีประโยชน์มาก มันช่วยให้เราทำ Project Plan ได้ถูกต้องมากขึ้น มันทำให้เราได้เตรียมทางหนีทีไล่ไว้แต่เนิ่นๆ และมันยังทำให้เรามีเรื่องไปคุยกับ Project Sponsor ได้เรื่อยๆ เช่น “พี่ครับ จำได้มั้ยเมื่อเดือนที่แล้วผมแจ้งว่าตอนนี้เรามี Risk ตัวใหญ่อยู่หนึ่งตัวคือเรื่องที่โปรเจกต์ผมยังหา Database Expert ไม่ได้เลย ถ้าปล่อยไปถึงสิ้นเดือนนี้จะทำให้งานไปต่อไม่ได้แล้วนะครับ” … หวังว่า Project Sponsor จะช่วยได้ แต่เอ้า ต่อให้ช่วยไม่ได้อย่างน้อยเราก็ไม่ผิดคนเดียวหละวะก็ในเมื่อเราไม่มีอำนาจจะไปสั่งให้ใครคนไหนมาทำงานให้เรานี่ เนอะ
- บางครั้ง Communication Plan ก็เป็นส่วนสำคัญของโปรเจกต์นะ ยิ่งกับโปรเจกต์ใหญ่ๆที่มีคนสนใจเยอะๆ ไหนจะทั้งคนทำงานจริง ไหนจะ Stakeholder อีกมากมายก่ายกอง การสื่อสารเป็นเรื่องสำคัญมาก (มากๆ) ที่จะทำให้โปรเจกต์เดินหน้าไปได้ เราในฐานะ Project Manager ต้องวางหลักการที่ชัดเจนว่า (1) ใคร (2) จะได้ข้อมูลประเภทไหน (3) เมื่อไร และ (4) อย่างไร
- จัดให้มี Project Tracking Meeting จะเป็นทุกวัน ทุกสัปดาห์ สัปดาห์เว้นสัปดาห์ หรือทุกเดือนก็แล้วแต่ความเหมาะสม ที่สำคัญคือควรทำอย่างสม่ำเสมอและกำหนดหัวข้อในการพูดคุย (Meeting Agenda) ให้ชัดเจน ทั่วๆไปก็จะมี (1) Current Status ว่าตอนนี้ Project ทำไปถึงไหนแล้ว (2) Future Tasks ที่กำลังจะทำต่อไป (3) Risks/Issues ที่มี (4) Changes ที่เข้ามา (5) Action Items (6) อื่นๆ … ป.ล. ต่อให้มี Daily Scrum แล้วก็ไม่พอหรอก Project Tracking นี้เอาไว้สำหรับ Key Stakeholder ไม่ใช่ Scrum Team
- ต่อจากข้อที่แล้ว เมื่อจบการประชุมแล้วเราก็ควรจะทำสรุปผลการประชุม(Meeting Minutes) ด้วยเพื่อยืนยันความเข้าใจและเพื่อใช้เป็นหัวข้อในการประชุมครั้งต่อไป เคล็ดลับของผมคือจะใส่ งานที่ต้องทำ + คนรับผิดชอบ + วันที่ต้องเสร็จไว้ด้วยเสมอ … จะได้เอาไว้ติดตามผลงานต่อไป
- ทำหน้าที่บริหารจัดการ Change ที่เข้ามาในโปรเจกต์อย่างสม่ำเสมอ ขั้นตอนก็เริ่มจากเก็บข้อมูลว่าตอนนี้มี Change อะไรเกิดขึ้นใน Project บ้าง ถ้าเราตัดสินใจรับ/ไม่รับ Change ตัวนี้ได้เองก็ทำไปเลย แต่ถ้ามันเป็นอะไรที่ใหญ่กว่านั้น เราก็ควรจะเอาไปคุยกับ Project Sponsor และ Stakeholder เพื่อให้ท่านๆเค้าตัดสินใจมา ตรงนี้อาจจะสงสัยว่ามีด้วยหรอ Change ที่เราจัดการเองไม่ได้ มีครับ (บ่อยด้วย) เช่น ลูกค้าขอให้ทำ Requirement เพิ่มโดยไม่มีระบุในสัญญา แถมจะทำให้โปรเจกต์ต้อง Delay ไปอีก 2 เดือน … ใหญ่ขนาดนี้ เกี่ยวกับเงินทองและกฎหมายแบบนี้ ปล่อยให้ผู้มีอำนาจเค้าจัดการจะดีกว่านะ
- ต้องควบคุมดูแลคุณภาพของงานที่ออกมาด้วย จะทำแค่ Track Project ว่างานไหนเสร็จ/ไม่เสร็จมันไม่พอ ต้องเข้าไปดูในรายละเอียดด้วยว่างานที่เสร็จออกมามีคุณภาพมากน้อยแค่ไหน บางครั้งเราอาจจะดีใจที่งาน Coding เสร็จเร็วกว่ากำหนด แต่ขอโทษนะ บั๊กกระจายแบบนี้ก็ไม่ไหว แล้วถ้าเจอปัญหาเรื่องคุณภาพก็ต้องหาทางแก้ไขด้วย อย่าปล่อยไว้แบบนั้นเพราะว่าสุดท้ายแล้วมันจะทำให้โปรเจกต์ดีเลย์อยู่ดีเพราะลูกค้าไม่รับผล User Acceptance Test (UAT) แถมเสียเชื่อบริษัทด้วย แต่ชีวิตไม่ง่ายเสมอไป หลายครั้งที่งาน Coding เสร็จช้ากว่ากำหนดจนทำให้เวลาที่เตรียมไว้สำหรับ Testing มันเหลือน้อยลงกว่าเดิม เราก็ต้องหาทางออกที่ดีที่สุดที่จะสร้างสมดุลของคุณภาพงานและเวลาที่เหลืออยู่
- หมั่นตรวจสอบงานอื่นๆที่นอกเหนือจาก Software Development ด้วย หลายครั้งความสนใจของ Stakeholders และเราจะอยู่กับแค่เรื่อง Software Development แต่โปรเจกต์เรามีมากกว่านั้นครับ เช่น Document ต่างๆ หรือการทำ Training ให้ลูกค้า งานพวกนี้มีอยู่ใน Project Plan รึยัง มีคนรับผิดชอบรึยัง แล้วมีการติดตามความคืบหน้าและปัญหาของงานเหล่านี้รึยัง สำคัญนะครับ
- หาเวลาพูดคุยกับน้องๆในทีมเป็นการส่วนตัวบ้าง มันเป็นเรื่องของการบริหารคนการที่จะสร้างทีมที่เข้มแข็งมันต้องเริ่มมาจากการไว้ใจซึ่งกันและกันก่อนซึ่งการที่เราเปิดโอกาสให้น้องๆได้แสดงออกถึงสิ่งที่เค้าคิดสิ่งที่เค้าเห็นกับการทำงานในโปรเจกต์นี้จะช่วยให้เราสร้างความสัมพันธ์ที่ดีได้และที่สำคัญไปกว่านั้นคือเราจะได้รู้ข้อมูลวงในมากขึ้นด้วย
- อย่าทำงานแบบ Micro-Management นั่นคืออย่าจู้จี้ อย่าจุกจิก อย่าชี้นิ้วสั่ง อย่าไปเกาะหลังเก้าอี้ใครแล้วก็สั่งให้ทำนู่นทำนี่ ไม่มีใครชอบหรอก เราต้องมีความเชื่อมั่นในทีมงานที่เราเลือกหรือเรามี (ในกรณีที่ไม่ได้เลือกเอง) เมื่อเรามอบหมายงานแล้วควรปล่อยให้เค้าใช้ความรู้ความสามารถของเค้าในการจัดการงานนั้นเองโดยมีเราช่วยเป็นคนติดตามดูแลและสนับสนุนอยู่ห่างๆ ถ้าเห็นว่าเริ่มมีปัญหาค่อยยื่นมือเข้าไปช่วย
- พยายามสร้างทีมงานที่จะทำงานได้เองแม้จะไม่มีเราอยู่ด้วย ไม่รู้สิ ผมชอบถ่ายทอดความรู้และประสบการณ์ให้กับใครก็ตามที่สนใจเรื่องพวกนี้ ด้วยความหวังว่าวันหนึ่งเค้าจะทำงานกันได้เองโดยไม่ต้องพึ่งผม มันเป็นการช่วยพัฒนาคนให้กับบริษัทด้วย เวลาผมทำ Project Plan หรือพวก Risk เนี่ยะ ผมจะไม่ทำคนเดียว แต่จะเชิญหัวหน้าทีมหรือใครที่สนใจเข้ามามีส่วนร่วมด้วยเสมอ เพื่อให้เค้าได้ออกความคิดเห็นในเรื่องที่ผมมองข้ามไปซึ่งช่วยให้งานผมรอบคอบมากขึ้น รวมถึงเป็นโอกาสให้คนอื่นๆในทีมได้เรียนรู้กระบวนการ Project Management ไปด้วย
ไม่ว่าวันเวลาจะผ่านไปนานแค่ไหน (จริงๆก็ประมาณ 5–6 ปีล่ะ) หรือไม่ว่ากระบวนการในการทำซอฟต์แวร์ของเราจะเปลี่ยนไปกี่แบบ ผมยังคิดว่าแนวทางนี้ก็ยังประยุกต์ใช้ได้อยู่เสมอ … หวังว่าจะเป็นประโยชน์กับ Project Manager น้องใหม่ทุกคนครับ โชคดีๆ ☺