ทำไม PM ถึงไม่สามารถเป็น QA ที่ประสบความสำเร็จได้?

PM สามารถเป็น QA ได้ในทางทฤษฎี เนื่องจาก PM รู้จักโครงการอย่างถี่ถ้วนและสามารถรับประกันได้ว่าสิ่งต่างๆ จะเป็นไปตามที่ควรจะเป็น แต่ไม่ปฏิบัติ ทำไม

ในองค์กรขนาดเล็กไม่กี่แห่ง ผู้จัดการโครงการยังสวมหมวกของผู้จัดการ QA ซึ่งเป็นบทบาทที่ขัดแย้งกัน เนื่องจาก 2 บทบาทนี้อยู่ตรงข้ามกัน ในทางปฏิบัติ ผู้จัดการฝ่ายควบคุมคุณภาพจะปฏิบัติตาม SOP เพียงเล็กน้อยเพื่อประเมินการทำงานของซอฟต์แวร์อย่างถูกต้องตามที่ตั้งใจไว้ และเทียบเท่ากับประสบการณ์ของผู้ใช้โดยรวม ปัญหาใด ๆ ที่พบจะถูกจัดทำเป็นเอกสารอย่างถูกต้องและส่งไปยังทีมพัฒนาเพื่อดำเนินการต่อไป ทำซ้ำจนกว่าผลิตภัณฑ์จะพร้อมสำหรับผู้ใช้ปลายทาง บทบาทอื่นๆ ของผู้จัดการ QA คือการรักษาบันทึกข้อบกพร่องที่ทราบและทดสอบข้อบกพร่องเหล่านั้น

ในขณะที่ PM คุ้นเคยกับขอบเขตของผลิตภัณฑ์มากกว่า A PM รู้ความต้องการของผลิตภัณฑ์ที่ไม่มีใครเหมือน PM ต้องประเมินความเสี่ยงและต้นทุนพื้นฐานอย่างเหมาะสม จัดการทรัพยากรผลิตภัณฑ์ สื่อสารกับผู้มีส่วนได้ส่วนเสียและอยู่ในกำหนดเวลา และสุดท้ายนำทีม QA เนื่องจากยิ่งเกิดวงจรซ้ำมากเท่าไหร่ก็ยิ่งมีแนวโน้มที่จะเกินต้นทุนพื้นฐานมากขึ้นเท่านั้น

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

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

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

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

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

นี่คือวิธีที่สมาชิกในทีมได้รับประโยชน์จาก QA ที่ประสบความสำเร็จ — “ขวัญกำลังใจดีขึ้น มีความกระตือรือร้นมากขึ้น และหงุดหงิดน้อยลง”