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

5. รู้จักความสัมพันธ์ของสามเหลี่ยมทองคำ

ไม่ว่า Project ไหนก็หนีเรื่องนี้ไม่พ้น Project Manager เค้าจ้างมาก็เพื่อจัดการสร้างความสมดุลให้เกิดขึ้นระหว่าง Scope, Schedule, และ Resources ครับ โดยความหมายแล้ว Scope คือสิ่งที่เราต้องทำใน Project เรียกง่ายๆว่า Requirement นั่นแหละ มันจะเป็นอะไรบ้างก็แตกต่างกันไปตามลักษณะงาน เช่น เขียน Software, จัดซื้อและติดตั้ง Hardware/Network, เขียนเอกสารต่างๆ, จัดเทรนนิ่งให้ลูกค้าก่อนส่งมอบงาน และอื่นๆ ส่วน Schedule ก็คือเวลาที่เรามีในการทำให้ Scope นั้นเป็นไปตามที่ได้ตกลงกันไว้ สุดท้าย Resources แปลตรงตัวก็คือทรัพยากรที่เรามีซึ่งประกอบด้วย คน, เงิน, และเครื่องไม้เครื่องมือ

ตามทฤษฎีนั้นเราจะให้คำจำกัดความของ Project ที่ประสบความสำเร็จว่า “ส่งมอบงานได้ตาม Scope ภายใน Schedule และ Resources ที่กำหนดไว้” ดังนั้นการสร้างความสมดุลนั้นมีความสำคัญเพราะถ้าขาดสิ่งใดสิ่งหนึ่งไปมันจะกลายเป็นว่า Project เราล้มเหลวไป เมื่อรู้แบบนี้แล้วเราลองมาดูกันครับว่าความสัมพันธ์ของปัจจัยทั้งสามนั้นเป็นอย่างไร

ด้วยสามัญสำนึกนะครับ ทุกคนคงคิดเหมือนกันว่า Scope ยิ่งน้อยยิ่งดี … Schedule ยิ่งยาวยิ่งดี … Resources ยิ่งมากยิ่งดี จริงปะ? เพราะถ้างานน้อยมีเวลาทำมากและช่วยกันหลายคนความเสี่ยงมันก็จะลดลงและโอกาสที่ Project นี้จะประสบความสำเร็จก็มากขึ้น … แต่ช้าก่อน โลกนี้ช่างโหดร้ายยิ่งนัก ความจริงแล้วสิ่งที่ Project Manager ต้องเจอมันจะตรงข้ามกับสิ่งที่หวังไว้หมดเลยครับ เพราะเมื่อทำงานไป Scope จะเพิ่มขึ้นเรื่อยๆ … Schedule อาจจะโดนตัดเพื่อเร่งให้ Project เสร็จเร็วขึ้น … แล้วปิดท้ายด้วย Resources หายไป ทั้งคนลาออกและโดนตัดงบประมาณ ฮ่าๆ แล้วจะทำยังไงกันหละเนี่ยะ

ตอบง่ายๆก็ด้วยสามัญสำนึกอีกเหมือนเดิมครับ

• ถ้า Scope เพิ่มขึ้น เราก็ต้องยืด Schedule ออกไปหรือไม่ก็เพิ่ม Resources เข้ามา หรือทั้งสองอย่าง — ระดับความเครียด 5/10
• ถ้า Schedule ถูกตัดออก เราก็ต้องลด Scope ลงหรือไม่ก็เพิ่ม Resources เข้ามา หรือทั้งสองอย่าง — ระดับความเครียด 5/10
• ถ้า Resources หายไป เราก็ต้องลด Scope ลงหรือไม่ก็ยืด Schedule ออกไป หรือทั้งสองอย่าง – ระดับความเครียด 5/10
• ถ้า Scope เพิ่มขึ้นและ Schedule ลดลง เราก็ต้องเพิ่ม Resources เข้ามา  – ระดับความเครียด 8/10
• ถ้า Scope เพิ่มขึ้นและ Resources ลดลง เราก็ต้องขอยืด Schedule ออกไป  – ระดับความเครียด 8/10
• ถ้า Schedule และ Resources ลดลง เราก็ต้องขอลด Scope ตามเช่นกัน  – ระดับความเครียด 8/10
• ถ้า Scope เพิ่มขึ้น บวกกับ Schedule ลดลง ปิดท้ายด้วย Resources หายไป เราก็ต้องขอลาป่วยหละครับเพราะระดับความเครียดจะพุ่งสูงถึงระดับ Infinity เฮ้อ

แต่ถ้าพิจารณาให้ลึกลงไปอีกนิดเราจะเห็นว่า … มันไม่ง่ายแบบนั้นหรอก


การเพิ่มคนเข้ามาใน Project

การเพิ่มคนเข้ามาตอนกลางหรือท้าย Project ด้วยความหวังที่ว่าจะทำให้งานเสร็จเร็วขึ้นนั้นไม่สำเร็จเสมอไปนะครับ ในมุมมองส่วนตัวแล้ว Software Development Project ไม่เหมือน Project ประเภทอื่นๆ เช่น Construction Project (โครงการก่อสร้าง) ที่ทุกอย่างค่อนข้างตายตัว มีกระบวนการทำงานที่เชื่อถือได้และมีปัจจัยภายนอกที่มีผลกระทบกับงานน้อยกว่า ในขณะที่ Software Development Project นั้นมีลักษณะที่เฉพาะตัวมากๆครับ เช่น การทำ Web Application จะแตกต่างจาก Mobile Application พอสมควร นั่นหมายความว่าเราต้องการคนที่มีทักษะ ความรู้และประสบการณ์ที่เหมาะสมกับงานจริงๆ (ส่วนใหญ่หายากมาก ภายในเวลาที่กำหนดนะ) ตรงนี้แหละครับที่จะเป็นปัญหา

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

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


การขยายเวลาของ Project ออกไป

ตัวเลือกถัดมาคือการขยายเวลาออกไปเพื่อทำงานให้เสร็จครบถ้วนก็อาจจะไม่เหมาะสมเหมือนกัน ผมพูดโดยอ้างอิงจากลักษณะธุรกิจแบบ Company C นะครับ ยุคนี้สมัยนี้ Time to Market สำคัญมาก สำคัญที่สุดด้วยซ้ำไป เคยอ่านหนังสือเล่มหนึ่งเค้าบอกไว้ว่า “ธุรกิจ Software นั้น ใคร Release ก่อนเป็นผู้ชนะ …” ประมาณว่าเอาเร็วเข้าว่า Feature ยังไม่ต้องครบ Quality เอาแค่รับได้ก็พอแล้วครับ บอกได้เลยครับว่าถ้าจะมัวมานั่งแก้บั๊กให้ครบทุกตัวก่อนถึงจะ Release ได้นั้นไม่ทันกินแน่นอน มันเป็นไปไมได้ในโลกปัจจุบันแล้วครับ

ทางออกที่ดีกว่าคือ

1. จัดลำดับความสำคัญของ Feature ต่างๆให้ดี ให้ตรงตามความต้องการของลูกค้าขณะนั้นให้มากที่สุด
2. เลือกทำเฉพาะสิ่งที่สำคัญที่สุดในแต่ละ Version
3. Release บ่อยๆ (บ่อยที่สุดเท่าที่จะทำได้) อย่าง Firefox เนี่ยะครับ เมื่อต้นปียัง Version 3 อยู่เลยมั้ง ถึงตอนนี้ Version 7 ใกล้คลอดแล้ว เร็วจริงๆ

การตัดลด Scope

จากประสบการณ์ที่ผ่านมานะครับ กับ Software Development Project เนี่ยะปัจจัยที่ยืดหยุ่นที่สุดจะเป็น Scope คือถึงเวลาจริงๆแล้วเราจะเลือกตัด Scope เพื่อคงไว้ซึ่ง Schedule เดิม (หรือลดลง) ด้วย Resources ที่มีเท่าเดิม (หรือลดลง) ความท้าทายอยู่ที่ว่าถ้าเรามีการเขียนและจัดการ Requirement (หรือ Scope) แบบเดิมๆแล้วหละก็ ยากครับที่การตัดลด Scope จะทำได้อย่างมีประสิทธิภาพ ลองดูตัวอย่างข้างล่างนี้ครับ

ถ้า Requirement เราใหญ่มากแล้วการตัดงานออกคือ … นู้น จัดเต็มไป ตัดระบบค้นหาหนังสือทิ้งทั้งก้อนมันจะทำให้ Software เราไม่สมประกอบอย่างน่าเกลียดไปเลยซึ่ง Product Manager และลูกค้าคงไม่ปลื้มแน่ๆ แต่ลองดู Project ที่สองครับ ถ้าเราแบ่งงานเป็นส่วนย่อยๆให้เหมาะสม เราจะสามารถเลือกตัดเฉพาะส่วนงานที่สำคัญน้อยกว่าออกไปโดยคงไว้ซึ่งสิ่งที่จำเป็นต่อ Software ของเราในเวลานั้นจริงๆ แบบนี้ Software ของเราจะดูดีขึ้นมาเยอะครับ อย่างน้อยก็มีระบบค้นหาด้วยชื่อหนังสือหละ … ทั้งหมดที่พูดมานี่มันเป็น Concept ของ Agile Development ชัดๆ

อย่างไรก็ตาม Project Manager ไม่มีอำนาจตัดสินใจตรงนี้หรอก มันเป็นเรื่องของ Project Sponsor เค้า สิ่งที่เราทำได้คือถามเค้าไว้ตั้งแต่เนิ่นๆว่าระดับความยืดหยุ่นของปัจจัยทั้งสามเป็นอย่างไร ตรงนี้เป็นที่มาของ Flexibility Matrix ครับ


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

จบแล้วครับสำหรับข้อห้าของ “Project Manager จำเป็น” ผมยังมีข้อมูลเหลืออีกเพียบเลย ต่อภาคหน้านะครับ

ต่อจากภาคที่แล้วอีกทีครับ บทความนี้จะพูดถึงเรื่องทั่วไปที่ไม่ใช่ทฤษฎีแต่สำคัญกับงานของ Project Manager ครับ

2. รู้จัก Process ของบริษัทตัวเอง

ทุกบริษัทมีกฎระเบียบของตัวเองซึ่งพนักงานทุกคนควรจะรู้และปฏิบัติตาม Project Manager ก็เช่นกันครับ เราจำเป็นจะต้องรู้และเข้าใจกระบวนการทำงานภายในบริษัทตัวเองเพื่อที่จะได้รู้ว่าต้องทำอะไร/ไม่ทำอะไร เมื่อไร และอย่างไร สิ่งสำคัญที่เกี่ยวกับงานโดยตรงของเราคือบริษัทมีกระบวนการหาเงินอย่างไร บางคนอาจจะคิดว่าก็ง่ายๆไง หาลูกค้าได้ก็หาเงินได้ มันก็จริงครับ แต่สิ่งที่เราต้องเข้าใจคือที่มาของลูกค้านั้นคืออะไร มันต่างกันมากในแง่ของกระบวนการทำงานในรายละเอียด เช่น บริษัทที่มีรายได้มาจากการรับเป็น Outsource ให้กับบริษัทอื่น กระบวนการที่ Project Manager ต้องรับผิดชอบก็จะไม่เหมือนกับบริษัทที่ทำ Software เพื่อขายเอง … ต่างอย่างไร?

บริษัท A รับเป็น Outsource ดังนั้นบริษัท A ต้องมีการเขียน Request For Proposal (RFP) ที่ใช่ยื่นประมูลโครงการ ต้องมีการเขียน Contract ที่รัดกุมเมื่อจะทำสัญญากับผู้ว่าจ้าง ทีมงานที่ต้องใช้ก็จะต้องมีคนที่รู้กฎหมายอยู่ด้วยซึ่ง Project Manager ก็มีหน้าที่ต้องเข้าไปดูแลงานในส่วนนี้ เมื่อประมูลงานชนะ ได้เริ่มทำงานจริงแล้ว Project Manager ก็ต้องทำงานร่วมกับลูกค้าจริง ไม่ว่าจะระดับหัวหน้าหรือจะระดับลูกน้อง (End users) ความท้าทายก็จะมีรูปแบบเฉพาะของมันเอง คร่าวๆแค่นี้

บริษัท B หารายได้ด้วยการเข้าไปเสนอขายระบบ (Product/Solution) ให้กับบริษัทต่างๆ ที่เหมือนบริษัท A ก็คือต้องมี RFP/Contract แต่ที่ต่างอาจจะเป็นที่ต้องมีทีมขาย (Sales Team) เข้าไปขายของโดยมี Project Manager เข้าไปมีส่วนร่วมตรงนี้ด้วย ยังไง? ก็เข้าไปให้คำแนะนำกับ Sales Team ว่าอย่าโม้กับลูกค้าให้มากเกินไป ของจริงมันทำไม่ได้นะ (โว้ย) ฮ่าๆ เสร็จแล้วก็ต้องทำงานกับ Development Team เพื่อส่งมอบงานให้ลูกค้าตามตกลง

บริษัท C มีกลุ่มลูกค้าเป็นของตัวเอง ทำระบบมาก็เอาไปขายลูกค้าพวกนี้แหละ ณ จุดนี้ RFP ไม่จำเป็น แต่สิ่งที่จำเป็นคือการทำงานร่วมกับทีมอื่นๆในบริษัท ส่วนมากแล้วบริษัทประเภทนี้จะเป็นบริษัทใหญ่ที่มีลูกค้าอยู่ทั่วโลก ดังนั้นการจะทำ Project ขึ้นมาซัก Project หนึ่งจะมีเรื่องให้ต้องคิดเยอะแยะหลายมุม เช่น เรื่อง Marketing เรื่อง Support and Training เรื่อง Commercials และอื่นๆ ความท้าทายที่สำคัญมันอยู่ตรงนี้ครับ มีโอกาสน้อยที่ Project Manager บริษัท C จะได้เจอกับลูกค้าจริงๆที่ใช้ระบบเรา ดังนั้นการทำงานร่วมกับ Product Manager ซึ่งเป็นคนที่กำหนดและจัดลำดับความสำคัญของ Requirement เป็นเรื่องสำคัญยิ่ง

3. รู้จักคนที่มีส่วนร่วมกับงานของเรา (Stakeholders)

ผลพลอยได้อย่างหนึ่งของความเข้าใจในข้อที่แล้วก็คือเราจะรู้ว่า … อืม มีใครที่เราต้องติดต่อทำงานด้วยตลอดระยะเวลาของ Project ครับ เช่น สมมติผมเป็น Project Manager ของบริษัท B ผมต้องตีซี๊ไว้กับ Sales Team ให้มากเลยเพราะว่าจะได้รู้ความเคลื่อนไหวของกลุ่มลูกค้าและของที่เค้าจะเอาไปขาย ออกแนวเตรียมตัวเตรียมใจไว้ว่า Project หน้าของเราจะเป็นอะไร และเมื่อ Sales Team จะเข้าไปนำเสนองานให้กับลูกค้าผมก็จะขอไปด้วยนะ คือกลัวว่าพี่ๆเค้าจะไปให้คำมั่นสัญญาที่เกินจริงกับลูกค้า แบบนี้เราจะซวยเองทีหลัง

เมื่อขายงานได้แล้ว ผมก็ต้องเข้าไปทำความรู้จักกับลูกค้าผมล่ะ ว่าแต่จะคนไหนดีหว่า? คนนี้เป็นคนใช้ระบบ คนนี้เป็นหัวหน้าที่ให้ Requirement ส่วนคนนี้เป็นรองประธานบริษัท คนที่ตัดสินใจสุดท้ายทุกอย่างเกี่ยวกับ Project (เรียกว่า Project Sponsor ละกัน) … ผมคงต้องคุยกับทุกคนแหละครับ แค่นี้พอมั้ย? อาจจะไม่หละ บ่อยครั้งที่เราจะเจอพวกมือไม่พายเอาเท้าราน้ำ กลุ่มคนที่ไม่อยากให้ Project นี้ประสบความสำเร็จเพราะเค้าอาจจะเสียผลประโยชน์อะไรบางอย่าง ผมต้องเก็บคนกลุ่มนี้เข้า Blacklist ด้วยเพื่อเตรียมการรับมือ

กลับมาที่บริษัทตัวเอง … คงไม่ขอพูดถึง Development Team แล้วกันนะครับ มันของตายอยู่แล้วที่ Project Manager ต้องคุยกับสมาชิกในทีมได้ … ถ้าไม่ได้ก็ตัวใครตัวมันแล้วกัน

ยอมรับตามตรง ผมห่วยแตกเรื่องความสัมพันธ์ประเภทนี้มากๆเลยครับ ไม่เก่งเรื่องเริ่มทักทายหรือพูดคุยกับคนที่ไม่รู้จัก ไม่เก่งเรื่องสร้าง Connection ไม่เก่งเรื่องหาเรื่องคุย ไม่เก่งเรื่อง … อีกมากมาย ด้วยความที่ผมเป็นคนเงียบๆ ไม่ค่อยสุงสิงกับใคร มันเป็นแบบนี้มาตั้งแต่เกิด ก็ไม่รู้จะทำยังไงเหมือนกันนะ พยายามจะแก้ไขปรับปรุงอยู่แต่มันยากเหลือเกิน

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

สอง … พยายามอย่าเอางานมาเป็นเครื่องมือในการสร้างความสัมพันธ์เพียงอย่างเดียว ประเภทที่เจอหน้ากันแล้วถามแต่เรื่องงาน เรื่องธุรกิจ … อย่าทำแบบนั้นเลย คนฟังเค้าจะเครียดแล้วไม่อยากจะเจอหน้าเราซะก่อน ประสบการณ์ส่วนตัวนะครับ สองเรื่องที่ช่วยได้มากเลยคือดนตรีและกีฬา หาโอกาสทำกิจกรรมพวกนี้กับ Stakeholder ของเราดู ผมว่าได้ผล ยิ่งกับกีฬานะ มันส์

4. รู้จัก Product ในบริษัทคุณให้มากที่สุด

ตามทฤษฎีแล้ว Project Manager จะไม่ยึดติดอยู่กับ Product ใด Product หนึ่ง แต่ต้องพร้อม (เต็มใจรึเปล่าอีกเรื่อง) ที่จะรับงานที่หลากหลายใน Product ที่แตกต่างกันออกไป เช่น ผมเป็น Project Manager ของ Microsoft เริ่มต้นด้วยการดูแล Project Microsoft Word 2010 ผ่านไปหนึ่งปี Project นี้เสร็จล่ะ หัวหน้าสั่งให้ไปช่วยทำ Project Microsoft Excel version 2012 (มีรึเปล่าไม่รู้นะ) … ผมตอบไปว่า “ไม่ได้หรอกครับ ผมไม่รู้เรื่อง Excel เลย ผมไม่ทำหรอกครับ” ถ้าเพื่อนๆเป็นหัวหน้าผมจะรู้สึกยังไง? …

มันเป็นหนึ่งในหน้าที่ที่สำคัญมากของ Project Manager ที่ต้องมีความรู้ในภาพกว้างของ Product ของบริษัทให้ได้มากที่สุด โอเคหละ ถ้าบริษัทมันใหญ่มาก มี Product เยอะมากการจะรู้ทั้งหมดคงเกินกำลัง เช่นจะให้ผมข้ามจาก Microsoft Word ไปดูแล Azure Cloud Services ก็เหมือนจะแกล้งกันไปหน่อย แต่กับ Microsoft Office ด้วยกัน ผมถือเป็นหน้าที่ที่ผมต้องรู้ภาพรวมของ Product ตระกูลนี้ … แล้วต้องรู้แค่ไหน?

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

• เมื่อมี Project เข้ามา เราจะทำความเข้าใจกับ Requirement ได้ง่ายและเร็วขึ้น
• เมื่อทำ Project Plan เราจะเข้าใจความสัมพันธ์ ความเชื่อมโยงของ Task ใน Work Breakdown Structure ได้อย่างชัดเจนซึ่งจะช่วยให้เราทำ Network Diagram ได้ถูกต้องมากขึ้น
• เมื่อทำ Project Plan เราจะมองเห็นถึงความขึ้นต่อกัน (Dependency) ของ Project เรากับ Project อื่นใน Product อื่นได้ชัดเจนขึ้น
• เมื่อได้ตัวเลข Estimation มา เราจะสามารถวิเคราะห์และตั้งคำถามกลับไปยังสมาชิกในทีมได้ว่า งานนี้มันใช้เวลาเยอะ/น้อยไปรึเปล่า? งานนี้ไม่ต้องทำก็ได้ไม่ใช่หรอ?
• เมื่อมี Change เข้ามา เราจะประเมินผลกระทบของมันได้อย่างรอบคอบและแม่นยำมากขึ้น ทั้งผลกระทบภายใน Project เองและผลกระทบกับ Project เพื่อนบ้านด้วย
• และอื่นๆ

ต่อจากภาคหนึ่งนะครับ เมื่อรู้แล้วว่าชีวิต 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

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