《妥協的完美主義：優秀産品經理的實踐指南（卷二）》一2.2 項目管理方法

本節書摘來自異步社群《妥協的完美主義：優秀産品經理的實踐指南（卷二）》一書中的第2章，第2.2節，作者 陳潔，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視

由于項目進度緊張的安排，要求項目經理必須具備緊迫感，善于捕捉工作中的問題和難點，思路清晰，掌握并靈活運用資料說話。在會議效率低下毫無建設性意見的溝通中，清楚要解決哪些問題，清楚難點在哪裡。優秀的項目經理善于安排時間和項目計劃，能夠掌握資料并靈活運用，善于溝通協調各方面資源，果斷做出判斷和決定。

除了不斷提高自身素養，在實踐中身經百戰外，使用項目管理工具也是必不可少的。一般說的項目管理工具是現成的軟體工具，常見的項目管理工具有sciforma公司的projectscheduler、primavera 公司的suretrak、microsoft 公司的project、imsi 公司的turboproject等軟體。但這些軟體适合大型的工程類項目，對于軟體開發項目有時候并不太實用，是以國内也有人根據具體情況自己開發小工具來使用。項目管理是對人員（people）、産品（product）、過程（process）和項目（project）進行分析和管理，但項目具體還是由人來執行的，說白了記錄管理的還是人的工作，解決協調的還是人的問題，就算是沒有工具，隻是利用文檔進行管理，隻要方式方法正确，也能夠做好項目管理的工作，是以産品經理如果掌握一定的項目管理辦法有助于管理能力的提升，對于非專業從事項目管理工作的産品設計人員來說，掌握一定的項目管理方法，對于版本疊代、文檔管理、項目進度也有一定的幫助。下面就對三種項目管理方法進行論述。

1．項目、版本和産品的關系

在移動網際網路行業，産品就是可以滿足外部使用者需求的軟體、硬體或者系統平台，對于外部使用者産品是可使用并獲得感覺的。對于普通手機使用者來說，某個公司提供的用戶端軟體安裝包和服務就是一個産品。

版本是産品在不同時間段的特性集合，包括産品的傳遞物、後續更新的傳遞物，一個産品可以有多個版本，版本是在産品的生命周期中，依據特性對産品做出的細分。

而項目是産品或版本的實作過程，反過來說，版本和産品是項目的輸出。例如，新浪公司推出的手機微部落格戶端就是一個産品，它包括了用戶端軟體，以及軟體内的内容服務。這個産品又分為v1.0版本和v2.0版本。為了實作和v1.0不同的功能需求，v2.0版本作為另外一個獨立的項目展開，在實作新功能完成上線後，發現一些缺陷，每個月再更新更新檔版本釋出v2.1、v2.2等新的版本。分為不同的版本是為了滿足不斷變化的需求。

2．項目周期

和産品有一定生命周期一樣，項目也是有周期的，但産品生命周期和項目周期是兩個不同的概念，産品生命周期是從産品概念産生到産品停止維護使用的過程，項目周期是産品生命周期的一部分，指項目從開始到收尾。産品生命周期開始于一個想法或者概念，結束于産品停止運維和使用。例如，市場部門在拜訪某營運商時，發現了一個新需求，市場部的客戶經理把這個需求回報給産品部，這個産品就算開始了；經過市場分析和産品分析，如果證明是有價值的，可以進行開發，完成後傳遞給營運商客戶使用，最後這個産品逐漸過時，公司決定不再支援這個産品，就表示這個産品的生命周期結束了。

有時候項目周期已經結束，但産品依然在被使用或維護，隻能說項目周期結束了，但産品生命還繼續存在，可見産品周期一般都長于項目周期。

3．項目階段

根據項目周期，将項目管理分為7個階段，如圖2.3所示。

（1）項目組織準備階段：從資源、技術群組織等多個方面進行評估和準備，完成項目立項計劃書。

（2）項目概念階段：制訂初步的項目計劃，完成設計需求和備選需求。

（3）項目計劃階段：制訂詳細的項目計劃，完成架構設計和概要設計。

（4）項目開發計劃：執行項目計劃，完成模型demo開發。

（5）項目驗證階段：執行項目計劃，完成可用性評估和beta測試。

（6）項目釋出階段：執行項目計劃，完成傳遞和維護支援。

（7）項目關閉階段：完成項目，總結項目，關閉項目。

在本書後續的章節中，大家可以看到産品設計團隊的項目流程，雖然和開發人員的工作内容不同，但項目流程也是7個階段，并正好和項目開發計劃一一對應。

項目的管理執行是否順利，取決于産品設計團隊的專業素養能力高低，也取決于團隊總體的工作方法，相比國内的團隊，國外的團隊做設計，非常注意方法和目标：輸入是什麼？輸出是什麼？采用什麼模型？相關影響分析？

輸入是什麼？輸入是要擷取各方面的資料，做到資訊全面，收集整理來自市場部、客戶、使用者、開發團隊以及其他相關團隊的資料，這種資料有文檔、照片、産品的應用場景記錄、開發技術評估等，擷取資料的過程，實際上是一個了解需求的過程，隻有先了解需求，産品設計人員才能根據确定的需求一步一步地進行需求整理、功能分解、子產品劃分、建立邏輯流程、模型驗證等。

設計輸出是設計團隊的設計成果，不僅僅是線框圖、設計圖稿、開發文檔、需求記錄等傳遞物，還應該包括設計團隊對會議、思維過程、資訊流的記錄、共享、傳達，輸出的不僅僅是文檔，還應該有設計思路、理由，隻有充分輸出，才能給相關團隊成員足夠多的資訊。同時，通過暴露設計思想，團隊成員之間才能發現問題，共享成果，及時糾正設計偏差。

文檔化包括文檔的歸類整理、上傳、更新、共享、廢棄等，為了減少返工，防止全盤推倒重來，前一步的輸入是後一步輸出的基礎，也就是進行下一階段工作之前，要求必須完成前一階段的工作并為下一階段工作提供高品質的輸入，以保證每一階段的工作都是連續的、正确的，才能保證一次性把設計工作做好。一般來說，通過營運專業的管理工具，或者最簡單地建立共享網絡空間等方式，做到輸出的充分共享，才能在項目變更，或者被摒棄的需求又重提時，回憶一下，當時為什麼我們不做這個功能，當時的理由和原因是什麼，幫助産品團隊結合現有情況重新評估需求。

要做到項目管理的文檔化并不簡單。首先項目成員日常工作繁忙，“手懶”不願意占用時間寫；其次很多急性子不耐于寫那些他們稱為形式化的東西。但事實是，文檔化正在潛移默化地改變我們的工作方式，并從一個側面優化産品的設計構造，使之不偏離最初的設計初衷，防止走歪路走冤枉路。

再者，要解決文檔細化程度的問題。有的公司對産品文檔怎麼記錄，有自己的一套規定，比如對設計團隊的輸出，可見部分的長寬高都做了嚴格的設計，代碼設計上更是細化到方法體。團隊成員可以在公司内部的管理工具上查到記錄，當然首先得根據團隊和項目的具體情況，确定符合項目的細化程度，然後作為制度和規範規定下來，團隊成員統一執行。

最後，項目的文檔化在改善人際關系方面有很好的作用。項目文檔無記錄、文檔記錄混亂，導緻團隊成員在接手時不容易看懂，或對某個需求了解不一緻，出現争執等，在項目中非常常見，小則影響心情，大則影響工作，影響團隊合作。

是以項目管理工作中，項目輸出中代碼管理、設計輸出、需求紀要等的文檔化非常重要。

在文檔化的過程中文檔如何記錄、記錄的格式是否統一，如果沒有明文規定，容易造成查無對證的隐患，造成的設計了解出現偏差、責任不明确，更是諸多問題的根源。被“冤假錯案”搞得一頭霧水的項目成員，可能會産生恐懼或排斥的心理，這種心理對于項目是不利的。那麼問題是誰造成的呢？都歸結為文檔輸出者，或者項目經理嗎？具體地說是項目管理政策的不嚴謹、不規範造成的。

在設計輸出中有一大堆的開發文檔、需求清單等，其中需求清單主要是用于審查系統的高層設計，比如系統設計上是否應該采取什麼措施或設計操作，滿足産品目标使用者中哪一類人的需求就算達标了呢？雖然目前設計行業沒有嚴格的标準，但至少各個系統平台釋出的開發設計功能實作應該作為基礎的标準，如果連這個基礎标準也無法滿足，那麼再好的設計也是不規範的。

雖然網絡上流傳着很多指導書和規範，但很多初級的項目執行人員沒有看規範要求再工作的習慣，而是通過自己的經驗或者模仿他人設計作品完成工作任務。作為産品設計人員，不論項目大小，都應該遵循設計指南，為自己的app産品制定gui規範、設計開發标準。越詳細标準的開發規範越利于項目，一方面有利于養成良好的工作習慣，對自身素養提高有幫助；另一方面，将來産品團隊擴大，項目規模擴大時，标準的開發和設計規範也有利于項目的延續性和規範化。