我喜歡我現在的職業，不只是因為網際網路是我的興趣所在，也是因為我很喜歡這種在沒有明確管理職權下卻要切實參與到管理工作的挑戰感。
年輕固然喜歡挑戰，但我老了應該也一樣會喜歡這種感覺，這應該是性格所致。
產品經理的產品設計能力是核心技能，但在很多團隊中產品經理充當的角色都是複合性的，產品經理對需求的把控能力可以決定專案的品相，而專案管理的能力則是決定整個專案能否完成甚至整個團隊能否穩定輸出的關鍵。
剛巧最近的工作主要圍繞的也是專案管理相關的內容，拿來做下個人的總結。
主要有兩個方面：
- 專案流程的管理優化。
- 專案資訊的溝通同步。
敏捷開發大行其道，scrum等方法都在業內盛行，理論之上一切美好，落入到實際執行之中就有很多不可控的問題。
我所理解到的原因三點如下：
1. 團隊人員的意外變動：
Feature不同，開發人員也不同，專案組內不同成員的溝通門檻高度不一致，需要磨合，實際工作中，經常性的會有人員變動：新成員的加入、老成員的離開都會帶來問題。
2.共性的激勵策略建立困難：
職務不同，績效考核的標準、負責考核的管理者的不同都會帶來阻礙。沒有共性的激勵策略會導致協作過程中不同職務的人只會專注於減少自己的工作量。
3.跨部門協作、跨公司協作時存在的多方面不同步
合作性質的專案都存在工作時間同步困難，資訊同步困難，工作計劃同步困難，考核標準同步困難。
問題主要針對兩個層面：團隊內部的協作流程和 跨團隊的協作標準。
好的工作流程建立之後，標準自然生成，通過效率工具可以很好地解決以上兩個層面的問題。
下面就講下關於流程建立我的理解和效率工具的對比。
團隊內部的協作流程:
包括需求管理（產品主導）、版本或分支管理（開發主導）、Bug管理（測試主導）
需求管理：
- 1. 需求策劃階段：需求功能點的優先順序劃分明確,需求版本管理需有總表。迭代規劃清晰，便於及時調整以及後續規劃，防止出現空閒時段。也避免開發架構出現問題。需求策劃階段就需要開發工程師介入。
- 2. 立項階段：需求工作量的準確評估，時間容錯度提前訂好，以免陷入無限期延期。
- 評估知會Leader，輔助定位時間，明確問題責任，如果評估有誤是評估者的問題，如果評估過長，Leader未能指出，則是Leader責任。
- 3. 開發、測試階段：靈活應變，每有變動必重新敲定時間點，開發工程師無法確定時間點的情況可以先給出一個時間範圍，講明無法確定時間的原因，提供候能夠確定工作量的時間點並在該點再次評估確認。。
- 4. 上線後既下版本開發階段，迴圈以上3個步驟。週期可以適當延長。
- 5. 文件管理最好提供統一的日期或效率工具，可以使用SVN管理需求文件，也可以通過自己維護文件版本號來管理，總之要第一時間納入需求變更，第一時間通知專案組成員更新文件。
Trello：
優點：便於專案全部流程管理，跨終端訪問便捷，對於協同工作效率提升明顯。
缺點：對其他系統的接入協作相對而言不太友好。
Office：
優點：通過Excel自建需求池，我之前一直使用的是這種方式，文件版本定義更自主。
缺點：版本管理、協同工作在國內當前環境下是需要藉助其他工具實現。資訊傳遞不夠順暢。
SVN:
優點：之前的專案中使用過SVN來管理文件，狀態回滾、協作編輯、資訊記錄都非常便捷。
缺點：是SVN的更新邏輯在增量更新時節省空間且便捷，但對於文件這種需要頻繁撰寫修改模式的文件管理，非常浪費伺服器儲存資源。
開發版本或分支管理
也是最近專案中同開發工程師討論中收穫的。感謝同事WXP。
- 1. 分支管理清晰，開發分支、測試分支、線上分支、程式碼總庫。
- 2. 不同分支許可權需明確，開發分支進入測試分支需要知會測試人員，測試人員與開發Leader共同決定可否併入線上分支。
- 3. 記錄資訊：版本通過分支管理需做到可以回滾到變更前的狀態啊。改動記錄：修改人、修改時間、測試人、測試時間都需明確，這樣明確事故責任，使開發工程師形成自我程式碼管理驗收的意識。
- 4. 程式碼總庫，每次提測前的版本打點儲存，需要時可以查詢到任何版本的程式碼記錄，定位具體問題評估影響。
- 5. 專案組內一定要形成固定得程式碼結構標準，方便工作交接，也利於程式碼管理。
SVN:
優點：
- 1）資料儲存方式：檔案，管理更加直觀，形式直觀，應用面更廣。
- 2）擁有全域性版本號，對應任意時間點原始碼的變動。
- 1） 分支合併時比較麻煩，對於分支合併時出現的衝突處理不夠便捷，無法快速定位到具體問題。
- 2） 非分散式系統工作依賴網路，對於協作專案來講效率會被降低。
Git：
優點：
- 1）資料存數方式：後設資料，分散式的版本控制系統，”.git”檔案是一個克隆的版本庫，擁有中心版本庫上的所有內容：如分支、版本記錄、標籤等。
- 2）處理分支簡單快捷，工作目錄下可以快速在多個分支間切換。相對於SVN在合併分支時出現的衝突處理更加便捷，可以快速定位。
- 3）儲存方式採用SHA-1雜湊演算法，確保程式碼內容完整性。
缺點：
檢視不如SVN檔案檢視的形式直觀便捷，入手門檻相對於高於SVN。
CVS:
優點：
- 1)通用性更加好，相對於SVN專案支援更加友好。
- 2)程式碼提交對應每個檔案，對於獨立分支管理更加靈活。
缺點：
- 1） 速度相對與SVN與Git要慢很多，是由於實現原理導致。
- 2） 不支援離線工作。
Bug管理
看似簡單卻浪費了我們這段最多的時間，也讓我們吃夠了苦頭。
我理解最重要的一點也是前提：Bug一切的出口需要掌握在測試人員的手中，原因三點：
- 1. 明確責任,分工明確，避免出現工作混亂的狀態。
- 2. 簡化資訊傳遞流程，資訊出口只有一個。
- 3. 便於總結日報，出口單一，總結資訊渠道也只有一個，整理彙報更容易，也更便於後續計劃。
效率工具：
這裡說下我在工作中接觸過Bug管理系統
JIRA（我接觸到最全面、功能最強大的）
優點：
- 1）JIRA是集專案計劃、任務分配、需求管理、錯誤跟蹤於一體，可以實現需求管理、流程管理、缺陷管理的全面軟體。
- 2）對接功能全面，可以同論壇或其他需要的地方自定義介面無縫接入。
- 3）商業軟體，自定義功能豐富，提供豐富的服務型別。
- 4）跨終端協作支援完善，移動端、郵箱等自定義配置豐富。
- 5）開源，購買之後同時購置了原始碼，方便做二次開發。
- 1） 商業軟體，收費且價格不菲。創業團隊選擇其價效比不高。
- 2） 配置項過多，後臺管理操作較複雜。
- 3） 概念過多，使用前的學習成本較大。
Bugfree
優點：
- 1）同CVS對接，系統可以自動把程式碼的Check-in結合起來，方便高效。
- 2）介面簡單，學習成本低。
- 3）免費且開源，價效比高。
- 1）主要針對web端管理，沒有多段協同的解決方案。
- 2）功能只針對Bug管理，略單一，橫向對比其擴充套件支援性較差。
禪道
優點：
- 1） 功能完備，無需再整合其他多個系統，降低實施成本。可以做全流程管理，或者只做測試管理，也可以只做專案管理任務管理，也可以只用來做需求管理。
- 2） 安裝非常方便，只需要下載十幾兆的綠色包，解壓縮即可執行。
- 3） 國產軟體，中文支援，操作習慣更符合國人。
- 4） 多職能視角的快捷切換，方便快捷。
- 5） 免費專案管理軟體。價效比高。
- 1） 介面佈局相對於Jira過於混亂。
- 2） 跨終端支援差，無移動端解決方案。
Bugzilla
優點：
- 1）免費。
- 2）強大的檢索功能，快速定位管理。
- 3）強大的後端資料庫支援,豐富多樣的配置設定等
- 4）桌面版提供截圖捕捉和編輯工具。
- 1） 部署需配置Perl和MYSQL資料庫，配置過程過於繁瑣。（不過可以通過XAMPP實現快捷部署）
- 2） 自定義功能相對較少。
總結：
搭建管理系統越來越容易，XAMPP可以實現快捷部署（Apache+MySQL+PHP+PERL）,線上的協同工具也非常多，web版本、移動客戶端等等，高效且出色.
任何效率工具都不會是最簡單的處理方案，會增加不同職務處理單一問題的時間和工作量。
但是對於團隊而言提升效率是非常明顯的，初期的適應成本都是後期效率提升的基礎。
只有團隊達成共識，重視流程管理，注重效率工具的使用，才能真正的推動效率的提升。
產品經理在跨團隊協作時需要注意的：
- 1. 建立自動化獲取常規資料流程很重要。
- 2. 推動本方Leader同時推動對方Leader，獲取部分必要許可權，實現常規需求的自動化。
- 3. 統一資訊溝通工具，明確責任。
- 4. 需要推動對方工作的內容及時郵件記錄，並明確時間點。
- 5. 產品需收集所有相關成員的聯絡方式，且有效地聯絡方式，及時瞭解其工作時間與節奏，在需要時第一時間聯絡。
- 6. 產品也要做公關，就是產品處於協調的中心點，組織雙方一起吃飯聊天還是可以很有效的提高協作效率的。
個人理解，最重要的是雙方在利益目標不同時需要有一個共性的執行標準。
資訊同步上總結了幾點可以提升效率的方法：
- 1.形成日報機制，通過郵件記錄。
- 2.日報內容抄送協作方相關成員。
- 3.日報內容包括雙發協作專案工作內容與規劃、需要對方配合的專案與工作內容與規劃、專案進度與事故處理方案進度與規劃。
- 4.專案組內部日報機制需要全面提供工作內容與細節，知會Leader，出現意外及時變更。
- 5.溝通協調後及時郵件幫助合作方記錄備忘。無法明確責任時主動記錄就是推動專案最好的辦法。
來自：人人都是產品經理
相關閱讀
評論(1)