為啥有這篇文章？

本來嘛，還沒上升到模型理論這個高度，更多的只是吐槽。加入了個創業公司，app剛起步，作為一個有經驗的測試(笑)，對所在團隊人員組成以及能力突然有了自己的看法，再結合以前剛畢業所在公司的非創業專案組的經驗，於是便有了這篇文章，人員只覆蓋了產品測試開發這三個最相關最核心的職能，其他的沒有深入瞭解也就不多說。
本文僅代表個人觀點，本人不負法律責任。

某千萬級產品的人員能力模型(塔頂是能力要求最高的)：

那麼產品是在最頂端的，其次是開發或者測試，最後是測試(一般是外包同學或者純功能測試同學)。這個模型的合理性應該毋庸置疑，畢竟成熟，我想如果在很成熟或者是非常重要的專案這個模型應該是最合理的。

先說產品，產品決定的是一個新功能的入口，是方向，也是一個專案興起還是衰敗的關鍵點，其重要程度可想而知。借用某個同樣的一句話：一個好的產品可以帶領一個公司走向巔峰，一個差的產品經理可以讓一個公司走向破產(差不多是這個意思吧…)。所以不妨可以搜尋一下，在前十的網際網路企業，他們所需要的產品要求，就可以看出來了。

再說測試，之所以放在一起，是因為最近幾年測試終於走上正軌了(創業公司除外，這是後話)，在真正重技術的公司，測試的地位已經逐漸和開發平齊了，從以前的只會介面的功能型驗證，演變成技術的解決能力，各種科學合理的測試方法被挖掘，被運用，印象最深的就是自動化、效能專項、介面、伺服器測試、sdk測試等等，所以對於測試也會要求越來越高，這是趨勢，也是好事。那麼最底下的呢，之所以備註外包，是因為這一層認為是功能測試，能力要求是最低的，剛畢業的計算機相關專業就可以入口，培訓一兩個月外行也可以入手，入門簡單，畢竟能力要求只需要會用會玩能溝通，懂一些測試理論就行了，這也是培訓機構敢虛構簡歷的原因，畢竟你剛畢業學了兩個月和工作幾年的功能測試掌握的都差不多，再借用同行的大話app一書作者的一個觀點—-測試的水平都是被培訓機構拉低的，不斷送一些混日子的人進入這個行業。這話其實說的有些難聽，不過也不能否認，而且功能測試要求雖然低，但是功能測試也是必不可少的。
最後是開發，其實開發的要求永遠只有兩個個，少bug，效能優。在我看來，就是開發在編碼的時候，多考慮編碼的嚴謹性，分支覆蓋要全，異常情況要處理，然後演算法合適，會做和做得好我想是區分初級和高階開發的原因之一了，可以看到很多開發會寫技術部落格，就是為什麼去做以及希望做得好的體現。一個好的開發可以給團隊節省時間，主要體現在轉測上，你說不出重要BUG，無嚴重效能問題，進度不就這麼上來了嗎？要知道，開發一個東西，改BUG的時間遠比實現的時間多，所以有單元測試，所以有成對開發。

有了上面的必要性，那麼這個模型就可以成立了，所以我個人看法，對於一個團隊的組成，工作年限最低的組成(真實年限)
產品工作年限：4年+
開發和測試開發：3年+
功能測試：1/2年+
咳咳，資料可不是亂說的，不信看招聘要求，市場說明一切。

創業公司：

相對於成熟的團隊，創業公司的人員可以說是無奈和心酸。我想每一個在創業公司的呆過都深有體會，尤其是是在流程規範公司出來的。
那麼大多數可能更多的是這樣的：

這是平級的關係，在這個團隊，人員配備可能是這樣的
產品：剛畢業或者1年+
開發：1~2年+
測試：剛畢業或者1年+，只有功能測試人員
這種平級的關係，在應付小規模的產品沒有任何問題，但是如果產品做大了，隨著需求和使用者數的增多，問題會逐漸顯示出來，流程的弊端也會暴露，於是變成，加班、加班、加班這個結果，我想你應該明白了為什麼大多數創業公司會一直加班了。那麼這裡個人理解列出幾個可能的問題：

產品越做越大，雖然使用者數多，但是每次更新都是不痛不癢，沒有實質改變，為了更新而更新—-缺乏真正看中使用者價值的產品
頻繁改需求，到釋出當天被老闆挑戰，甚至推倒重來，全組人員加班到通宵—-缺乏產品關鍵性細節
提測問題多，改了BUG又出現另外一個BUG，再牛的測試也hold不住—-開發缺乏自測能力，程式碼異常無考慮
開發時間越來越長，BUG越來越多—-一開始架構沒打好，留下隱患，沒有時間重構，急著上新需求
明明測試通過了，但是一上線，總是有人反饋問題，沒完沒了—-缺乏有效測試覆蓋和上線後質量監控體系
等等
所以在個人看來，這些根本原因是，相關人員的質量意識不夠高，流程意識不規範造成的，解決辦法是提高整體人員素質或者引入核心人才，包括技術的，包括管理的。我想流程的質量意識這塊，也是標示著一個公司是否具備長遠發展的基礎。

好了，以上是我作為一個測試看待一個專案組的人員能力問題，當然，只包括了測試、開發和產品，PM這個職業也是需要發展到一定程度才有的，同時以測試的角度看來，測試團隊的職能分工和公司地位，可以側面反映出公司對質量的追求，是追求有，還是追求優。