我是以工作的觀點來看這個問題。

在專案裡做什麼事的人，應該就那賦予該角色的權責，而不是說什麼事情該由什麼人來做。採取「什麼事情由什麼人來做」的角度來看的話，會面臨專案彈性的問題，因為你實在不好拿捏要由什麼角色的人兼任何種角色會比較好，或許你認為可以將性質相同的工作丟給某一類人去執行比較好，其實像Albertchou所提到的「驗證與確認計畫」由「品質保證經理」來撰寫，這個好像很合理，但是從「品質保證」所要求的「客觀性」與「獨立性」而言，可能是有問題的，品質保證是要從客觀的角度去評估產品與過程對於規範、要求、計畫的符合性，因此，如果驗證與確認計畫是由品質保證經理撰寫，有關於「驗證與確認」的規劃與執行(產品與過程的)狀態，試問在專案之中，將由誰來稽核？這就發生「球員兼裁判」的問題，這是無法取信於人的。更何況軟體的驗證與確認，是一項產品全生命週期的活動，不只是專案層級而已。

在專案或者組織之中，做什麼事的人，就要賦予同等的角色與權責，例如，指派了某位人員撰寫專案管理計畫時，這個人就是專案經理。有些專案經理是由高階主管來兼任的，由他來寫計畫，可能是不可行的，因為，專案計畫可能永遠出不來！那麼，就不該讓那位「位高權重」的經理擔任專案經理的角色，因為如此進行，專案成功的機率是非常低的，主要原因是，那位經理根本無法掌握專案的全般狀況，經理人的職責本來就是規劃、組織、用人、指導、管制等等，如果那位經理不能投入到專案理進行前述的那些職責，他就不該是專案經理。

在專案裡，一個人做什麼事，不是因為其頭銜是什麼才去做什麼事，而是因為做了什麼事情，所以得到工作的頭銜，這樣的話，在專案當中，當你負責寫專案計畫統籌專案的所有事項時，你就是專案經理，當你又負責某個系統的需求發展時，你也是系統分析師，你負責執行測試的規劃時，你也是測試經理。

一個公司的流程可以訂得很廣泛，但是這個廣泛的流程，是要適應在很多不同型式的專案的，如果公司是什麼樣的人做什麼樣的事，那麼一個兩個星期的微型專案，可能會不敷成本的。因為你得有各種不同職類的人：專案經理、測試經理、測試工程師、品質保證工程師、專案助理、系統架構師、系統分析師、系統設計師、軟體分析師、軟體設計師............林林總總，這樣子的話，公司可能撐不了多久就掛了，因為營運成本過高。

所以在專案裡，資源的指派是看人員的「經驗」、「技能分類」及「技能水準」，而不是看頭銜指派的。要不然，就會發生有的人掛名不做事，其他的小小工程師，卻是忙到分身乏術。

----------------
引文: