Tại sao một PM không thể là một QA thành công?

Một PM có thể là một QA về mặt lý thuyết. Bởi vì một PM hiểu rõ về dự án và có thể đảm bảo mọi thứ hoạt động theo cách nó nên làm. Nhưng không thực tế. Tại sao?

Trong một số tổ chức nhỏ, người quản lý Dự án cũng đội mũ của người quản lý QA. Đó là một vai trò mâu thuẫn vì hai vai trò này đối lập nhau. Trên thực tế, người quản lý QA tuân theo một số SOP để đánh giá đúng chức năng của phần mềm hoạt động như dự kiến ​​và ngang bằng với trải nghiệm người dùng tổng thể. Bất kỳ vấn đề nào được tìm thấy đều được ghi lại đúng cách và gửi đến nhóm phát triển để giải quyết. Điều này được lặp lại cho đến khi sản phẩm sẵn sàng cho người dùng cuối. Các vai trò khác của người quản lý QA là duy trì hồ sơ về các lỗi đã biết và kiểm tra chúng.

Trong khi một PM quen thuộc hơn với phạm vi của sản phẩm. Một PM biết rõ các yêu cầu của sản phẩm hơn ai hết. PM phải đánh giá rủi ro phù hợp và cơ sở chi phí, quản lý tài nguyên sản phẩm, giao tiếp với các bên liên quan và tuân thủ lịch trình. Và cuối cùng là lãnh đạo nhóm QA. Bởi vì chu kỳ càng lặp lại thì càng có khả năng vượt quá chi phí cơ bản.

Sự khác biệt chính giữa Người quản lý dự án/sản phẩm hoặc Người quản lý QA nằm ở việc người quản lý dự án áp dụng tư duy đúng đắn. Người quản lý dự án đội mũ quản lý QA luôn tập trung vào việc dự án của anh ấy/cô ấy trông thông minh hơn ngay cả khi các kết quả QA trái ngược nhau được quan sát thấy trong quy trình.

Tôi chắc chắn rằng nhiều nhà quản lý dự án thực hiện loại vai trò kép này sẽ chứng minh sự thật này trong sâu thẳm trái tim họ mặc dù họ có thể không thể hiện ra bên ngoài. Điều này là do Người quản lý dự án muốn trở thành Người quản lý dự án chứ không phải người quản lý QA. Khi một Người quản lý dự án được chỉ định đóng vai trò là người quản lý QA, về mặt tâm lý, họ có xu hướng trở thành Người quản lý dự án hơn là người quản lý QA.

Khi quan sát thấy có một chức năng bị lỗi trong hệ thống, người quản lý QA có thể dễ dàng đánh giá bằng tài liệu và báo cáo phù hợp giúp tăng tốc công việc cho nhà phát triển trong trường hợp điều này có thể không xảy ra với người quản lý Dự án. Người quản lý dự án có thể chịu nhiều áp lực từ các bên liên quan, thời hạn dự án và chi phí phát triển có thể vượt quá mức này.

Điều này gây tác động tiêu cực và có thể gây ra một số vấn đề bao gồm nhưng không giới hạn ở việc làm mất tinh thần nhà phát triển chịu trách nhiệm. Những vấn đề này có thể được xử lý khác nhau theo cách phù hợp hơn.

Các nhà quản lý dự án có thể không đồng ý với tôi nhưng nó không được viết rõ ràng rằng mọi trường hợp của dự án sẽ giống nhau và có thể áp dụng các nguyên tắc giống nhau. Tốt hơn là nên tuân theo các quy trình chung khi có người quản lý QA xử lý những việc này và PM có thể tập trung vào mối quan tâm của anh ấy/cô ấy để giảm thiểu hoặc giảm nhẹ các vấn đề có thể xuất hiện sau này trong dự án.

Đây là cách các thành viên trong nhóm được hưởng lợi từ QA thành công - “Tinh thần tốt hơn, nhiệt tình hơn và ít thất vọng hơn”.