ต่อจากภาคสามครับ บทความนี้จะกลับมาที่ทฤษฎีที่สำคัญที่ 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 เพื่อนบ้านด้วย
• และอื่นๆ