站長資訊網當你升到管理崗，項目管理和團隊管理就成了你的“家常便飯”。關于項目管理與團隊管理，你或許會有一些疑問：如何制定產品計劃，才能合理有序地分配團隊工作，高效地完成項目呢？怎么做項目管理才能使開發更敏捷呢？那么，以下就由筆者來為大家一一解答這些問題吧！
團隊中的產品經理最近提了幾個問題，趁此機會做一下分享。
這是產品問答的第三篇：探討提升管理崗位后的團隊管理、項目管理。
問：在團隊管理時，如何制定產品策略及計劃？以及，如果我把原型制作工作交給別人做，但出來的效果是我不滿意的——他現在能力不夠，做不出我想要的效果，要怎么處理？（如何分配工作）？項目管理有沒有什么方法讓開發更敏捷？
答：
隨著產品逐漸成熟，產品團隊也會慢慢成型。產品團隊的存在，說明產品工作已經細化拆分。原來一、兩個人干的事，現在可以由不同分工的人來處理了。
因此，產品團隊的管理，得先從產品工作的拆分說起。
一般來說，產品工作的層面可以分為：產品戰略、產品結構、產品框架、產品設計和產品輔助等。
產品戰略工作
就是我們在第一篇問答（如何系統思考產品需求）中提高的產品戰略工作。
梳理和確認好產品戰略，讓未來產品工作建立在相同認知基礎上，是產品工作中最宏觀且最有價值的工作。
產品結構工作
當我們確定了產品戰略之后，從戰略到具體的產品規劃，需要進行信息的轉化。
這種轉化，就是將產品戰略落地，轉化為一條條產品線、一個個版本、一張張的功能清單，也就是產品的路線圖（roadmap）。
有了清晰的路線圖，接下來就可以進入正式的產品規劃設計工作階段了。
產品框架工作
有了實現的路徑，就需要按照優先級，分產品線分版本的逐步設計。
這時，我們首先把眼光聚焦在版本內部，我們對所有需要實現的功能進行分析，讓他們成為有機結合的整體，讓功能組成一個個相關的模塊。
同時，也把模塊內及模塊之間的各個功能，可能的實現流程明確出來。讓需要實現的目標功能，變成清晰的多維結構。我們需要使用UML、業務流程圖、數據流程圖、業務拓撲圖等講這些結構表達出來。
同時，當版本內的設計接近完成時，我們要把眼光切換到多版本上——考慮未來版本和功能的實現，需要當前產品結果預先作出哪些調整和伏筆。這些都完成之后，我們就可以開始按照版本來細化和設計產品了。
產品設計工作
單個版本的產品結構設計完成，并經過各相關團隊的評審和協調后，就要回歸到產品部門內部進行設計了。
我們需要按照產品的版本結果，設計出前、中、后各端的模塊、功能、流程、頁面等，這里我們需要畫原型、細化流程、設計頁面、輸出需求說明文檔甚至高保真的交互稿。
設計好的產品結果，要宣講并交付給開發團隊，同時也會接受開發團隊的各種挑戰。
另外建議：在宣講和交付產品結果的時候，最好能夠把對象目標擴展到測試團隊、運營團隊、業務團隊等各個相關業務團隊，這樣做的好處你試了就知道。
產品輔助工作
除了上述四個產品規劃層面的工作外，其他的如：競品調研、數據采集匯總、項目跟進、Bug處理跟進、產品相關宣傳說明配合等工作，都是產品輔助類工作。
這幾個層面的工作，并不是每個層面都需要不同的人來負責。本身是可以互相滲透，根據團隊的具體情況來身兼多職。
1-3 層面
一般由產品總監、產品團隊負責人或高級產品來負責。做到承上啟下，配合高層確定產品戰略并消化和轉化，指導具體的產品規劃工作。
4-5 層面
一般由產品經理、產品線經理或產品專員等負責。做好基于產品路徑的落地工作，保證產品設計的效率和質量。
拆分層面的意義在于：規范好的工作層面，可以讓大家在工作時，明白各自的職責范圍，更高效的互相承接和配合。
另外，你說團隊成員的產品不符合你的要求，不知該如何處理。
我的建議是：就算從執行層崗位開始轉變為管理崗位，也千萬不要做甩手掌柜，很多執行方面的工作還是要有目的性的參與。
有目的的參與，可以體現在如下兩個方面：
做為產品管理崗位，需要承擔產品信息的向下傳遞——即承上啟下的作用，你需要去處理產品戰略、產品范圍及產品框架等方面的設計工作。
同時，因為接下來要據此來進行具體的產品設計規劃，最理解且最能依據產品框架來設計產品的人一定是你。你需要對各端的關鍵模塊、關鍵頁面進行設計，建立從上到下、完整一致的信息傳遞。
尤其是新產品或新產品線的初期版本或產品迭代中的重大版本，以你為中心和起點的產品設計，才是最高效、最能保證質量的。
有一個詞叫“言傳身教”，要團隊產出符合標準的產品設計交付物，一定是以清晰合理的交付標準為前提的。
而對培訓交付標準最好的方法，就是你要自己做出表率。通過對關鍵功能和頁面的設計，以標準原型、標準文檔的方式來建立基礎，團隊才能迅速熟悉和以交付標準為標的完成工作。
最后，關于項目管理方面。
項目管理
我不是一個在項目管理方面，過度刻意進行控制和要求的人。
開發項目管理有很多方法論——瀑布開發、敏捷開發、螺旋開發等。
方法選擇的核心，應該交給開發團隊，讓他們選擇最熟悉最方便的就可以。同時，也不是所有的項目都適合敏捷開發，不同階段的產品非要去做敏捷開發也不一定合適，這里就不展開說了。
我想拋開項目管理的方法論，從個人認為的項目管理更核心的角度來講講。
項目管理，我認為有三個要素：任務、執行者和結果。
好的項目管理是處理好這三個要素之間的關系。簡單說就是，合適的任務量，有執行者運用合適的節奏，來產出滿足要求的結果。
任務量
合適的任務量，是決定項目成敗的前提條件——在產品規劃的交付物方面提高要求，不使交付物成為項目開發的障礙。
- 不在一個版本內規劃超過合理開發周期的任務量。
- 不把沒有思考清楚或不完整的功能放入產品規劃中。
- 做到“嚴于律己”，認真對待產品規劃輸出物，往往要比苛求開發團隊實現不可能完成的任務更重要。
執行者
執行者就是項目的開發團隊。
信任開發團隊，比懷疑和苛求開發團隊要來的劃算，良好合作一定建立在互相信任的基礎上。
相比去苛求開發團隊完成不能完成的任務，不如反過來思考：如何根據需求的優先級來縮減任務量？
給予項目合理的任務時間，是保證項目質量的重要條件。
這里我更推薦“晨會+周期性項目演示”的方式：
- 每天早上在開工前，拿出15分鐘左右，讓開發團隊對當前進度進行簡短說明。同時可以提出：目前出現可能影響原定進度的問題，在晨會后安排專門的時間，來進行專項討論或提供盡可能的協助。晨會可以天為標尺，發現目前實際進度與原定計劃的差距，也可以讓問題得到最及時的解決；
- 每1-2周，固定時間對項目目前的進度進行整體說明，并準備可演示物進行演示，判斷當前項目的進度和階段產物是否符合要求。
通過這樣的方式，能夠及早發現進度問題或影響進度的問題，從而提高對項目異常的反應速度。
結果項目最終的產出物，是驗證項目成敗的最終指標。僅僅在時間維度上去衡量項目成果，是沒有任何意義的。沒人愿意接受一個按時完成，但漏洞百出，無法提供使用的交付物。
所以，對結果交付物的驗收，是項目管理的最終關卡。
要驗證開發交付物，首先要做到，開發前提供的產品規劃交付物是清晰明確的。
其次，還需要對交付物進行如下兩個層面的檢驗：
- 功能層面：這部分工作可以交給專業的測試團隊完成，但產品團隊一定要在過程中積極參與及跟進；
- 實際使用層面：這部分則需要產品來獨立完成。使用層面的檢驗——即產品團隊模擬真實用戶的各種使用場景，使用時的行為，輸入信息要盡可能模擬真實情況。這種檢驗可以發現很多測試團隊不容易發現，但被用戶正式使用很快會遇到的問題。（這一點2B的業務類產品尤為重要）。
以上就是我對你提出的項目管理問題的解答。
作者：十八子殺，微信公眾號：產品狗的思考（Productdoggy）。10年產品人，射手座，愛自由，喜攝影，好讀書，涉獵廣泛，望與同路人勉勵前行。
