ผู้จัดการโครงการมีประโยชน์ในการต่อสู้หรือไม่

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

ตัวอย่างเช่น

• Scrum Master:รับผิดชอบกระบวนการ ขจัดอุปสรรค
• เจ้าของผลิตภัณฑ์:จัดการและจัดลำดับความสำคัญของรายการงานที่ต้องดำเนินการเพื่อเพิ่ม ROI ให้สูงสุด แสดงถึงผู้มีส่วนได้เสียทั้งหมด (ลูกค้าผู้มีส่วนได้เสีย)
• ทีม:จัดการงานของตัวเองโดยการประเมินและกระจายงานกันเอง รับผิดชอบในการปฏิบัติตามภาระผูกพันของตนเอง

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

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

คุณเห็นด้วยกับการต่อสู้ที่ไม่จำเป็นต้องมีผู้จัดการโครงการหรือไม่? คุณคิดว่าบทบาทดังกล่าวยังจำเป็นหรือไม่ ทำไม?

บางทีคุณควรนำเสนอสิ่งนี้:

ผู้จัดการโครงการไม่ได้หายไปในการต่อสู้ เขายังอยู่ที่นั่น ตอนนี้มีสามคนแล้ว!

• The Scrum Master : เขาจัดการกระบวนการและแก้ไขอุปสรรค นั่นเป็นความรับผิดชอบของผู้จัดการโครงการมาก่อน

• เจ้าของผลิตภัณฑ์ : เขาจัดการงานในมือ นั่นเป็นความรับผิดชอบของผู้จัดการโครงการก่อนเมื่อเขาคาดการณ์ทุกอย่างในโครงการ Microsoft

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

สำหรับฉันสิ่งนี้มาจากการขาดความเข้าใจในสิ่งที่ผู้จัดการโครงการทำและลักษณะทั่วไปของชื่อ PM ฉันไม่ใช่ผู้เชี่ยวชาญเกี่ยวกับ SCRUM แต่ฉันเคยเห็น SCRUM Master แทนการเป็นผู้จัดการฝ่ายพัฒนา / ผู้นำทีมแทนที่จะเป็นผู้จัดการโครงการ

ผู้จัดการโครงการ (ตามที่กำหนดโดยระเบียบวิธีเช่น PRINCE2 - ซึ่งค่อนข้างเข้ากันได้กับวิธีการ Agile) ไม่ได้เกี่ยวอะไรกับกระบวนการพัฒนาพวกเขาดูแลโครงการจากมุมมองการนำเสนอที่ครอบคลุมมากกว่าไอที สร้าง. มีหลายสิ่งหลายอย่างที่อยู่ในบทบาทผู้จัดการโครงการที่ไม่ได้กล่าวถึงในที่อื่นใน Scrum (การจัดการและการตรวจสอบกรณีธุรกิจการจัดการผู้มีส่วนได้เสียทางธุรกิจองค์ประกอบของโครงการที่อยู่นอกไอทีเช่นกระบวนการทางธุรกิจการสนับสนุน การฝึกอบรมและอื่น ๆ )

หาก PM ของคุณเป็นคนที่ดูแลนักพัฒนาและไม่ได้ทำอะไรมากไปกว่านั้น (ตัวอย่างเช่นในโครงการที่ส่วนใหญ่เป็นเพียงแค่ขอบเขตที่กำหนดไว้ค่อนข้างดี) ก็อาจเป็นไปได้ว่าเขาไม่ต้องการ ในโครงการ SCRUM

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

อาจเป็นไปได้ว่า PM จบลงด้วยการนั่งทางด้านธุรกิจของโครงการมากขึ้น - เจ้าของผลิตภัณฑ์อาจรับบทบาทของ PM ได้ดีกว่า Scrum Master แต่ฉันคิดว่ามันไม่น่าเป็นไปได้เลยที่เขาจะหมดไป

มีบางสิ่งที่ผู้จัดการโครงการสามารถทำได้เช่นการแย่งชิงหลักหรือเจ้าของผลิตภัณฑ์อาจไม่สามารถทำได้

• ผู้จัดการโครงการมักจะมีประสบการณ์ในการดำเนินโครงการ (ประหลาดใจ!)
• พวกเขาตระหนักถึงข้อผิดพลาดทั่วไปและสามารถสังเกตเห็นและช่วยให้พวกเขาออกไปก่อนที่จะเกิดขึ้น
• พวกเขามักจะมีประสบการณ์การเจรจาต่อรองและสามารถสนับสนุนสมาชิกในทีมอื่น ๆ ในการอภิปรายเกี่ยวกับกำหนดเวลาขอบเขตและความต้องการที่ขัดแย้งกัน (สำคัญมากถ้า PO ค่อนข้างใหม่ในบทบาท)
• พวกเขาสามารถจัดการเงิน พวกเขามีอำนาจในการจ้างและยิงและสามารถช่วยได้หากมีคนในทีมไม่สามารถแสดงในบทบาทของพวกเขา (ผ่านการฝึกอบรมการให้คำปรึกษา ฯลฯ )
• พวกเขาสามารถช่วยให้มั่นใจว่าโครงการเหมาะสมกับโปรแกรมการทำงานที่มีขนาดใหญ่ขึ้น
• พวกเขาสามารถกำจัดสิ่งต่าง ๆ ออกจากทางของทีม
• พวกเขาสามารถช่วยแนะนำนโยบายของ บริษัท ให้มีประสิทธิภาพควบคู่ไปกับ Scrum (ตัวอย่างเช่นหากผู้ทดสอบยังคงถูกวัดโดยจำนวนข้อบกพร่องที่พบ)
• พวกเขาสามารถจัดการธรรมาภิบาล
• พวกเขาสามารถเคลื่อนย้ายเฟอร์นิเจอร์
• คำศัพท์ของพวกเขาคือขององค์กรขนาดใหญ่และพวกเขาสามารถหารือเกี่ยวกับโครงการ - และวิธีการต่อสู้ - ในแง่ของความเสี่ยงผลกระทบผลตอบแทนการลงทุนตัวเลือกและความแตกต่าง
• พวกเขาสามารถอธิบายให้คณะกรรมการทราบว่าเหตุใดความโปร่งใสอย่างฉับพลันและข่าวความล้มเหลวเป็นครั้งคราวโดยผ่านรายงานทะเลสีเขียวเป็นสิ่งที่ดีและมีประโยชน์ที่จะรู้
• PM ที่ดีสามารถช่วยให้คุณรู้สึกปลอดภัยฟังดูดีและดูดี

การต่อสู้ไม่ได้บังคับให้มี PM แต่คุณอาจต้องการมีอยู่ดี

ในหนึ่งในโครงการที่ฉันทำงานเมื่อเปลี่ยนเป็น Scrum ผู้จัดการโครงการก่อนหน้าของเราหรือเลือกใช้บทบาทของเจ้าของผลิตภัณฑ์และ Scrum Master มันใช้งานได้ 6 เดือนที่ฉันใช้กับทีมนั้นแม้ว่ามันจะไม่เหมาะ (สำหรับฉัน) เขาเป็นคนประเภทที่ต้องการให้สิ่งต่าง ๆ อยู่ภายใต้การควบคุมอย่างเข้มงวด แต่ทำได้ดีพอสมควร (เช่นให้ทีมทำงานและตัดสินใจตามความเหมาะสม)

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

ฉันยุติธรรมและพูดว่าในมุมมองของฉันสิ่งที่ใช้ได้ผลสำหรับฉันก็คืออาจารย์ Scrum ที่ทำหน้าที่เป็นผู้จัดการโครงการด้วย การเป็นอาจารย์การต่อสู้ไม่ใช่งานเต็มเวลา - เมื่อทีมครบกำหนดแล้วทีมการต่อสู้ไม่จำเป็นต้องเข้าร่วมการยืนประจำวัน
มีตำแหน่งงานว่างมากขึ้นเรื่อย ๆ ที่ฉันเห็นสำหรับ Project Manager / Scrum Master ที่ บริษัท ไม่ต้องการแยกแยะบทบาทเหล่านี้ - แทนที่จะให้บุคคลเดียวกันจัดการกับทั้งสองบทบาทเช่นผู้จัดการโครงการ Agile

ผู้จัดการโครงการ:บทบาทภายในองค์กรหรือองค์กรแบบดั้งเดิม

การต่อสู้หลัก:บทบาทภายในทีมพัฒนาซอฟต์แวร์โดยใช้วิธีการการแย่งชิงกัน

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

สิ่งที่ผู้จัดการโครงการทำหน้าที่และบทบาทของเขา / เธอทับซ้อนกับนายหลักหรือเจ้าของโครงการขึ้นอยู่กับขนาดและลักษณะของโครงการมากนัก แต่มีงานตามปกติที่เกี่ยวข้องกับผู้จัดการโครงการที่ไม่เฉพาะเจาะจง ส่วนหนึ่งของบทบาทการต่อสู้หลักหรือเจ้าของโครงการ ในโครงการขนาดเล็กอาจเป็นไปได้ที่จะขยายหน้าที่ของอาจารย์การต่อสู้หรือบทบาทของเจ้าของโครงการเพื่อรวมงานเหล่านั้น (การจ้างการยิงการจัดซื้อการจัดการสัญญาการประสานงานกับผู้บริหารระดับสูงเป็นต้น) ในโครงการขนาดใหญ่การพัฒนาซอฟต์แวร์เป็นเพียงส่วนหนึ่งของการจัดการโครงการและหน้าที่ของผู้จัดการโครงการและของ Scrum master นั้นไม่น่าจะทับซ้อนกันมากนัก

ผู้จัดการโครงการควรเป็นส่วนต่อประสานหลักของ Scrum กับองค์กร Scrum master ควรเป็นส่วนต่อประสานของผู้จัดการโครงการกับทีม

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

คำถามนี้กลิ่นของScrumbut

Scrum เป็นส่วนย่อยของสิ่งที่มีอยู่ในวิธีการจัดการโครงการ (Prince2 / PMP ฯลฯ ) ในความเป็นจริงหากคุณดูที่กระบวนการ Prince2 MP (การจัดการการส่งมอบผลิตภัณฑ์) องค์ประกอบทั้งหมดของ Scrum สามารถอยู่ที่นั่นได้

Scrum Master ไม่ต้องการถูกจมอยู่ในการพบปะกับผู้ขายบุคลากรกฎหมายการเงินผู้จัดหาผู้บริหารหรือกิจกรรมBAU พวกเขาจำเป็นต้องมีสมาธิในการขจัดอุปสรรคจากทีมในการวิ่งปัจจุบันไม่ใช่การเจรจาว่าหน่วยงานการจ้างงานสามารถ จำกัด อัตราผู้รับเหมาในปีงบประมาณ 2554-2555 หรือตรวจสอบข้อตกลงสัญญากับผู้ขาย x

หาก Scrum Master ของคุณกำลังทำงานด้านบนแสดงว่าคุณไม่ได้ใช้งาน Scrum คุณกำลังใช้งาน Scrumbut

จากประสบการณ์การรวมกันที่ดีที่สุดคือการมี Scrum Master สำหรับแต่ละหัวหน้าทีมและผู้จัดการโครงการเพื่อประสานโทต่อสู้ใน Scrum of scrums fashion การมีผู้จัดการโครงการในบทบาทนี้มีประสิทธิภาพมากขึ้นเนื่องจากเหตุผลที่ระบุไว้ข้างต้นและประสบการณ์เชิงลึก ในทางกลับกันผู้จัดการโครงการเหล่านี้รายงานผลงาน / ผู้จัดการโครงการ ฯลฯ และทั้งหมดในห่วงโซ่ของคำสั่งอย่างน้อยอาจารย์ได้รับการรับรองการแย่งชิง

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

หนึ่งในปัญหาหลักที่มีบทบาทผู้จัดการโครงการแบบดั้งเดิมคือการแยกอำนาจออกจากความรับผิดชอบ PM มีอำนาจที่สมบูรณ์เหนือองค์กรโครงการ - (s) เขาตัดสินใจว่างานที่ต้องทำโดยใครในลำดับใด ฯลฯ แต่ (s) เขาไม่รับผิดชอบต่อความสำเร็จของงานเหล่านี้หรือคุณภาพของซอฟต์แวร์ ที่ผลิต สมาชิกในทีมเป็นคนเดียวที่รับผิดชอบ สิ่งนี้ทำให้เกิดค่าใช้จ่ายในการติดต่อสื่อสารขนาดใหญ่เพื่อนำสิทธิ์กลับมาใช้และการตัดสินใจที่สอดคล้องกับการปฏิบัติงานสมาชิกในทีมจะต้องรายงานทุกสิ่งที่ทำกับ PM นอกเหนือจากที่เหลือของทีม นอกจากนี้ยังสร้างความรู้สึกของการสูญเสียอำนาจและสูญเสียจุดประสงค์กับสมาชิกในทีมซึ่งเป็นแหล่งใหญ่ของความยุ่งยากและความท้อแท้

Agile นำแนวคิดเหล่านี้กลับมารวมกัน - ทีมงานมีอำนาจเหนือองค์กรโดยรวม (ผ่านการเปิดตัวการทำซ้ำและการประชุมประจำวัน) เพื่อให้ทุกคนรู้สึกว่าพวกเขาสามารถพูดในเรื่องนี้ได้ สมาชิกในทีมจะต้องรับผิดชอบในการผลิตซอฟต์แวร์คุณภาพที่ใช้งานได้และมุ่งมั่นอย่างหนักแน่นต่อเป้าหมายนั้น ในทางทฤษฎีคุณสามารถกำจัดผู้จัดการโครงการได้

เมื่อคุณบอกว่ายังมีหน้าที่ตามธรรมเนียมที่ได้รับมอบหมายให้ PM ซึ่งยังคงต้องได้รับการดูแล - lunivore อธิบายพวกเขาค่อนข้างแม่นยำ

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

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

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

อย่างไรก็ตามในการทำงานของฉันผู้จัดการโครงการไม่ค่อยมีส่วนเกี่ยวข้องกับ "Scrumming" ที่แท้จริง พวกเขาไม่ได้รับอนุญาตให้เป็นอาจารย์ Scrum (กฎความขัดแย้งเรื่องผลประโยชน์ในท้องถิ่นที่เราทุกคนมีความสุขมาก) และพวกเขาเป็นเจ้าของผลิตภัณฑ์เท่านั้นในกรณีพิเศษ

ดังนั้นที่ฉันทำงานผู้จัดการโครงการยังอยู่ที่นั่นทำสิ่งที่พวกเขาทำมาตลอด หมายความว่าพวกเขาติดตามโครงการทำหน้าที่เป็นตัวกรองจากแนวโน้มของความหวาดระแวงและการจัดการไมโครจาก "เหนือ" มากเกินไปการแก้ปัญหาที่ต้องใช้อิทธิพลมากกว่าที่เรามีเพื่อแก้ปัญหาและอื่น ๆ

ฉันแน่ใจว่านี่ค่อนข้างแตกต่างจากที่อื่น แต่สำหรับเรามันใช้งานได้ดี

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