參與公司級專案，我發現了職能管理中存在的很多問題
近半年多時間，我作為主產品經理，參與到一個公司級專案中。該專案涉及系統多，涉及業務範圍廣，涉及相關人員多，專案實施過程中也出現了很多很多的問題，而從這些問題中，我也發現了一些專案管理解決不了的問題，而這些問題恰恰是職能經理管理工作沒做好導致的（本人也擔任產品部門經理，負責產品組日常管理工作）。
首先，產品經理在整個專案實施中參與度太深，具體如下圖所示，在開發、內測、聯測和全流程測試階段，產品經理還需要花費大量時間和精力參與進來，解答開發或測試同學對流程、資料準確性、甚至介面對接欄位等問題。並且，開發和測試同學遇到稍微複雜的問題，都一定要產品經理參與才能最終確認這個問題是不是bug，是不是需要調整功能，是不是滿足需求等。開發和測試對產品經理的需求文件依賴性很高，並且開發根據需求文件寫程式碼，測試根據需求文件寫測試用例，兩者都對產品經理的需求文件負責。而實際中，需求文件可能存在部分細節遺漏或表述不是特別恰當（作為產品經理，誰也沒辦法百分百保證不遺漏），遺漏部分則永遠都發現不了。另外，開發和測試都對需求文件負責，但測試如果不熟悉功能要滿足的需求場景，不熟悉功能調整可能影響的系統流程，不瞭解開發實現的大概邏輯，那就沒辦法完全測試出開發可能出現的bug，那麼，測試質量從何保證。
產品經理在專案中各節點參與度
其次，專案實施中，開發和測試也因為工作問題吵過幾次架。主要原因在於開發同學完成功能後，沒有充分自測，甚至和其他系統對接的介面都跑不通，非常影響測試整體進度。這種情況導致了專案進度的壓力全部轉移到測試身上，測試又不能容忍大量阻塞性bug出現的問題，吵架自然不可避免。同時，開發階段的一些不規範，無標準，也導致了開發質量比較差，比如：兩個系統介面對接，出現了介面欄位缺失，介面資料結構對不上等問題，而這些問題都是在聯測階段才暴露出來，也說明了開發要求太低，也沒有相應標準。
最後，說說測試同學吧，內測，聯測，全流程測試，其實是一步步掃雷的過程，也是一步步加深對系統和功能熟悉的過程，內測階段對產品經理的依賴性還可以理解為需求理解不一致，需要部分內容再次澄清，但聯測和全流程測試階段，過渡依賴產品經理則只能說明我們的測試同學不夠專業，並且每一輪測試應該達到什麼效果，也沒有明確的標準，導致整體測試周期比較長，但效果也沒辦法完全保證。
上述的問題，我一度認為是專案管理的問題，也一度認為是人員能力和態度的問題，也因此和開發、測試吵過架。但經過仔細分析和思考，我發現這些問題專案經理都沒辦法解決，他也不會花費大力氣在解決這些問題上，專案運作的核心還在於通過計劃、控制、協調、平衡等手段達到專案目標。同時，我們也不能過度依賴人員能力和態度，否則，以後我們都沒有能力做好一個大專案，而人的問題始終能夠轉化為流程、標準、規範等管理手段，通過職能經理對產品、開發、測試人員工作的管理來減少專案運作中存在的問題。
作為主產品經理和產品組負責人，最值得我思考的還是如何減少產品經理在開發和測試階段參與度。
那麼，就需要釐清這幾個問題：
1）產品經理在需求交給開發和測試同學時，到底應該達到哪種效果才算通過，才能減少後續開發和測試同學對產品的高度依賴。
2）產品經理的需求文件到底應該細化到哪種顆粒度，哪些問題是開發應該自主設計並做決策的。
3）各階段測試的標準是什麼，開發提測的標準是什麼，產品，開發，測試怎麼高效配合等等。
專案制管理的目的在於產品快速交付，並保證質量。而專案實施中會出現各種各樣想不到的問題，比如：開發工程師不會寫概要設計，那麼，專案經理可能會考慮其他方式來規避不寫概要設計的風險，但不會找人教會開發寫概要設計，因為時間成本太高。這種類似問題在專案管理中可能還不止一個，而專案經理也只能通過協調資源，合理安排任務，尋找快速可替代方案，風險平衡等方式來達到專案目標。因此，專案組和職能組之間的關係則顯而易見。
最後的最後，我想說的是，產品，開發，測試部門的經理，一定要對每個人有高標準、高要求，才能讓每個人都能參與到專案中，也能輸出更高質量的產品。公司的發展中，切忌出現產品、開發、測試要求相差甚遠的情況，否則輕則出現某個崗位累個半死，員工大量離職，重則專案失敗的情況。