文檔編號：ZD-190507-RMJC（1）
目錄
一、前言
本文檔的編寫主要用于對產(chǎn)品專員/助理及產(chǎn)品工作相關小伙伴入門時，對產(chǎn)品經(jīng)理崗位進行了解，并牢記崗位相關背景、職責及技巧，較快上手相關工作，早日成為一名優(yōu)秀的產(chǎn)品經(jīng)理。
二、基礎認識
1. 關于產(chǎn)品經(jīng)理
產(chǎn)品經(jīng)理(Product Manager)是一個特別寬泛的詞匯，在不同的行業(yè)，產(chǎn)品經(jīng)理的指代意義完全不同。比如旅游行業(yè)，產(chǎn)品經(jīng)理往往指的是負責開發(fā)旅游線路。而在金融行業(yè)，產(chǎn)品經(jīng)理的職能通常都是負責設計理財產(chǎn)品和投資類項目。
產(chǎn)品經(jīng)理在互聯(lián)網(wǎng)/IT行業(yè)，是一類人群的統(tǒng)稱，細分下來，有所謂的：后臺產(chǎn)品經(jīng)理、數(shù)據(jù)產(chǎn)品經(jīng)理、商業(yè)產(chǎn)品經(jīng)理等不同領域，而且各個領域有著不同的側重點與工作內(nèi)容。主要是負責管理、規(guī)劃、設計乃至于負責實施工作的一個崗位。
2. 認識崗位工作
中國傳統(tǒng)的產(chǎn)品經(jīng)理的工作情景是這樣的：
? 沒完沒了的開會，根據(jù)會議中得出的需求開始制作方案
??畫流程圖、畫原型、寫文檔，方案完成后開評審會
??和項目組的人侃大山，定下方案就開始項目溝通跟進
??最終測試驗收完成上線
真正有價值的產(chǎn)品經(jīng)理應該是這樣的：
1) 不做需求的執(zhí)行者，而是需求的制定者。如果你現(xiàn)在只是被動接受需求，而不是主動提出需求，那么這就是差距。
2) 為項目負責，確保做的事情有意義，是正確的。項目做成怎么樣、要做到什么樣的程度、怎么樣做才有效果都是產(chǎn)品經(jīng)理要決定的。
3) 幫助項目取得成功。光做出一個項目還不行，你還要確保這個項目是成功的，成功的定義可以是你的項目廣為所知、你的項目賺了很多錢、你的項目改變了人們的生活方式等等。
3. 你的協(xié)作團隊
三、工作內(nèi)容
（一）基本流程
主要流程包含以下關鍵環(huán)節(jié)：
1.?需求預受理：需求采集、調研分析、整理匯總并歸檔需求池
2.?項目立項：制定項目方案、評估風險及可執(zhí)行性、進行需求評審會議
3.?產(chǎn)品方案設計：原型制作、輸出需求說明、進行產(chǎn)品方案評審會議
4.?產(chǎn)品研發(fā)：開發(fā)、測試
5.?項目上線：驗收、部署上線
（二）詳細流程
1) 產(chǎn)品團隊通過向需求方采集及溝通業(yè)務需求，記錄需求后整理匯總討論分析，期間著重探討業(yè)務需求的合理性、完整性和前瞻性，充分考慮各種流程、各個環(huán)節(jié)以及異常流程的處理，并保證正確理解需求。
2) 產(chǎn)品團隊向需求方反饋預受理結果，受理結果包括轉為正式受理和拒絕受理。拒絕受理的原因可能會很多，上邊提到的需求受理原則是考慮的主要方面，拒絕受理必須提供原因，必要時可與需求方溝通改進業(yè)務需求以達到正式受理的結果。
1) 正式受理后，開始執(zhí)行調研報告、數(shù)據(jù)報告等。早期需求分析，需要保證需求點是清晰的、明確的、有意義的、可測量的，并且存在技術可實現(xiàn)性，同時符合市場運作要求。
2) 需求分析后，調研人進行需求及評估文檔的編寫歸檔，文檔需要反饋用戶調研的結果報告及需求模型，以供技術評審討論使用。
3) 邀請主要研發(fā)人員參與需求分析，初建立需求與技術實現(xiàn)之間的聯(lián)系，確認需求的可實施性和難易程度。主要與研發(fā)人員確認需求中重要部分的可執(zhí)行性，包括影響因素、實現(xiàn)關鍵因素、時間節(jié)點等，保證技術實現(xiàn)可在需求方預定的發(fā)布時間內(nèi)研發(fā)完成并上線，避免對項目進度及需求方滿意度的影響。
4) 如果確認技術可實施性，再組織產(chǎn)品會議討論并輸出解決需求的初步思路方案。
5) 邀請需求方進行初案審核，具體驗證每一個需求的定義、實現(xiàn)方式等，保證方案每一點都經(jīng)過需求方「批準的」。
6) 產(chǎn)品團隊實時跟蹤需求方需求變動，并對每次變更及時進行溝通確認。并反復上述規(guī)范流程，直到需求方案最終確認。
??需求方案確認后，由我方指導需求方填寫并提交項目立項說明書，最終由全部負責人簽名確認工作任務后，項目方可啟動。
??項目立項說明書（或業(yè)務需求單）主要體現(xiàn)需求點可執(zhí)行性、業(yè)務需求詳細說明等，可附帶附件、附圖、附表等文檔，需求描述的粒度應盡量細小，并說明業(yè)務需求的重要程度和緊急程度。
??與需求方明確未提出的業(yè)務需求，在我方項目啟動前可以提出需求補充，若已啟動項目開發(fā)執(zhí)行，后續(xù)產(chǎn)生的一切需求變動，可能導致的時間、人工等成本是隨之變動，屆時酌情商討需求變動的具體執(zhí)行方案，或納入下一版本執(zhí)行。
1) 根據(jù)需求方案，從需求實現(xiàn)的角度將業(yè)務需求拆分成系統(tǒng)功能點進行分析，并設計產(chǎn)品框架。（建議先與需求方溝通確認基礎產(chǎn)品框架）
2) 制作并輸出原型圖（線框圖），并與需求方溝通確認原型設計稿，根據(jù)立項說明書/業(yè)務需求單檢查確保產(chǎn)品設計已對需求文檔的所有需求都進行了設計。（可將需求點標記為“已設計”狀態(tài)，方便需求設計管理）
3) 協(xié)調UI進行界面設計，并與需求方溝通確認界面設計稿，保證所有交互邏輯都是經(jīng)過需求方「批準的」。
4) 撰寫需求研發(fā)說明（產(chǎn)品設計說明），根據(jù)產(chǎn)品功能點、界面設計和邏輯實現(xiàn)，撰寫研發(fā)說明，幫助研發(fā)人員更好的理解和執(zhí)行所有工作細節(jié)。（文檔形式自定）
??根據(jù)原型圖/界面圖/設計說明，評審業(yè)務邏輯、交互邏輯等產(chǎn)品細節(jié)，提出異議并討論解決方案，根據(jù)修改意見進行方案細節(jié)優(yōu)化修訂。
??如遇重大邏輯問題駁回，則返工與需求方重新溝通討論產(chǎn)品設計方案，并重新修訂產(chǎn)品設計方案，重新制作輸出相關需求設計說明等。
??評審通過后，產(chǎn)品團隊將所有需求文檔提交研發(fā)團隊，由研發(fā)團隊進行任務拆分指派，確定相關負責人，并由各負責人對后續(xù)研發(fā)工作負責，包括統(tǒng)籌規(guī)劃、協(xié)調溝通等。
??與研發(fā)團隊溝通并制定“功能計劃”、“時間進度計劃”等，其中包括開發(fā)、測試、上線的工作內(nèi)容，項目計劃要與需求方達成共識并簽批同意執(zhí)行。
??研發(fā)團隊要嚴格按照計劃和需求文檔進行研發(fā)工作，在出現(xiàn)問題時及時與產(chǎn)品團隊溝通。
??測試團隊同時編寫測試用例，并對存在疑問的地方及時與產(chǎn)品團隊溝通確認。
??完成后將每一個已研發(fā)完成的任務標記為“已完成”狀態(tài)。
??產(chǎn)品團隊審核測試團隊提交的測試用例，保證已滿足所有需求場景并符合產(chǎn)品設計方案。
??測試團隊（質量保證組）測試產(chǎn)品研發(fā)工作并報告結果。
??測試合格通過后將每一個需求點標記為“測試通過”狀態(tài)。
??當完成內(nèi)部測試和用戶測試并保證結果無誤后，提供用戶公開測試版本以供核收需求結果，核收無誤后與需求方確認上線時間。
??需求上線由我方運維人員統(tǒng)一部署到實際生產(chǎn)線，工作完成后通知產(chǎn)品團隊和需求方最終驗收，并由運維人員監(jiān)控服務器穩(wěn)定器，測試人員同時進行生產(chǎn)線最后檢測。
??上線前由產(chǎn)品團隊編寫好《產(chǎn)品使用說明手冊》以供需求方學習使用。
??必要時，由我方產(chǎn)品團隊為需求方講解項目實現(xiàn)情況和產(chǎn)品操作流程，具體視需求方要求，但不負責對需求方的客戶進行培訓等后續(xù)工作。
四、其他指導
（一）業(yè)務相關
任何業(yè)務需求都必須了解其業(yè)務出發(fā)點，特別在需求方跳過業(yè)務背景的描述，直接提出功能點時，尤其需要追溯根源訴求。通過了解業(yè)務背景，可以優(yōu)化需求實現(xiàn)方式，甚至有可能改變功能點。在需求文檔中可通過增加備注或描述業(yè)務背景章節(jié)幫助需求閱讀人員更深入了解需求的產(chǎn)生過程。
需求方往往從局部角度提出需求，該需求可能沒有聯(lián)系其他模塊進行推敲，甚至會有自相矛盾、漏洞百出的現(xiàn)象，我們在受理需求時可先通過詢問問題來了解該需求是否準確、清晰，是否與其他功能點和主題有沖突等，如果需求方仍存在模棱兩可的現(xiàn)象而導致無法清楚地闡述需求，我們可以不予受理。
??重復現(xiàn)象：有些需求可能以前提出過，只是尚未解決，或者已經(jīng)被否決，總之是重復需求，對于該類重復需求，可研究原有需求與新需求是否有差異，如果確認重復則不予受理。
??雜糅現(xiàn)象：有些需求中包含了多個子需求，其中的某些子需求在其他需求中已經(jīng)包括，即需求間存在交叉現(xiàn)象，這種情況下應梳理子需求，確保沒有雜糅現(xiàn)象。
需求提出者有時可能只代表個人意見或一個小團隊的意見，或者提出者可能并不是業(yè)務主管部門，因此業(yè)務需求的提出必須首先在該業(yè)務部門內(nèi)部有權限人員得到認可后才能代表整個部門意見，否則為無效需求。
有些業(yè)務需求的提出可能涉及其他部門的業(yè)務操作流程，如果該需求的提出沒有征得相關部門的同意，則在后期實現(xiàn)過程中會遇到阻礙，導致該需求無效，因此如果涉及多部門的需求，需求提出者應與其他部門溝通，在合理的解決方案下征得他們同意。
有些業(yè)務需求的提出是為了解決一些特殊情況的發(fā)生，即小概率事件，但該需求的實現(xiàn)卻需要投入很大的工作量，該類需求可征求業(yè)務主管部門意見，必要時可讓業(yè)務部門出具小概率事件發(fā)生頻率報表，從投入產(chǎn)出比的角度謹慎受理需求。
（二）需求相關
針對原有需求中尚未完善的規(guī)則、表單、流程等進一步維護需求，此類維護不是需求變更，而是在前期需求分析過程中，需要等待業(yè)務部門提供的資料進行完善后，才能明確需求方案。這種情況下，應在需求研發(fā)進程中，與各方人員明確提出存在的地方，并盡快維護和更新需求方案。
在評審后的需求如果有變動，如果確認接受該變更，則應根據(jù)最新的需求要求重新修訂研發(fā)說明，并記錄變更歷史。需求變更必須有一定的流程，并征得業(yè)務部門和技術部門的同意。關于需求變更，必須明確幾個方面：變更原因、變更程度、變更解決方案。
??因我方技術等原因發(fā)生滯后進度時，研發(fā)團隊及時向產(chǎn)品團隊提出，產(chǎn)品團隊根據(jù)情況，制定解決方案及可行性計劃，并向需求方提出需求變更申請，經(jīng)需求方審批同意后，完成需求計劃變更并同步文檔更新。
??因需求方在當期業(yè)務需求范圍之外發(fā)生需求內(nèi)容強制變更時，可通過向我方提出需求變更說明，詳細填寫項目問題、需求變更內(nèi)容等信息，并由我方評估后，協(xié)商溝通項目時間及人工成本影響。雙方一致通過后，由產(chǎn)品團隊即時調整項目工作及同步文檔更新。
??明確雙方提出業(yè)務需求變更時，應說明業(yè)務需求的重要程度和緊急程度。若為重大變化，則需要最高領導審批決定。
??新增的需求必須是有效的、經(jīng)過分析的并且劃分了優(yōu)先級，更新并簽批需求確認書，在項目計劃和產(chǎn)品交付期間反映需求變更狀態(tài)，該需求的狀態(tài)是“已批準”。
??刪除、放棄需求，需更新并簽批需求確認書，并在項目計劃和產(chǎn)品交付期間反映需求變更狀態(tài)
??該需求的狀態(tài)保持為“已批準”，并在項目計劃和產(chǎn)品交付期間反映需求延遲狀態(tài)。
（三）項目相關
業(yè)務需求部門所需業(yè)務功能對整體業(yè)務系統(tǒng)影響程度，可分為非常重要、重要和一般三個級別，非常重要為最高級別。
??非常重要：需求實現(xiàn)對整體業(yè)務系統(tǒng)影響非常大，如該需求為關鍵流程的關鍵環(huán)節(jié)說明等。
??重要：需求實現(xiàn)對整體業(yè)務系統(tǒng)影響大。
??一般：需求實現(xiàn)對整體業(yè)務系統(tǒng)影響一般，如頁面顯示文字、字體、顏色等。
可分為非常緊急、緊急和一般三個級別，非常緊急為最高級別。
??非常緊急：關鍵業(yè)務流程不能被正確執(zhí)行、且無可替代措施。
??緊急：業(yè)務流程不能被正確執(zhí)行，但存在可替代措施或方法。
??一般：不會對業(yè)務流程存在較大影響。
有些需求的實現(xiàn)依賴于另一需求的實現(xiàn)情況，即業(yè)務需求是有順序、按步驟進行的，在這種情況下我們建議需求可分期完成，如果在一期尚未完成的情況下就提出新需求，可稱為“跳躍性需求”，此類需求我們建議等基礎需求實現(xiàn)后再完善。
系統(tǒng)建設需制度先行，適當放寬要求也需制度并行，有些需求的提出是先行于制度，該類需求實現(xiàn)后的問題在于沒有配套制度或崗位作為運行的保障，可能導致系統(tǒng)與制度脫節(jié)，反而影響業(yè)務的發(fā)展。在制度并行的情況下，需求提出者需給出制度下發(fā)的計劃表，才能保證該需求的有效性。
不論是新需求還是需求變更，如果涉及層面比較廣，可能影響到系統(tǒng)的上線時間，需謹慎受理，必須征得領導意見，給出可行的方案供領導決策選擇，一般方案有三種：
研發(fā)中心對業(yè)務需求以時間為基線實行版本化，并統(tǒng)一規(guī)范管理：
1) 定義文檔命名、文檔編號及版本號信息：
??統(tǒng)一文檔命名格式：日期+文檔名+版本號，例190507產(chǎn)品設計研發(fā)說明V1；
??統(tǒng)一文檔編號格式：類型-日期-文檔名縮寫（版本數(shù)字），例ZD-190507-GZXX（1）；
??統(tǒng)一文檔版本號格式：V1、V2、V3…V10…V20，以此類推。
2) 定義軟件系統(tǒng)版本號：
??統(tǒng)一軟件系統(tǒng)版本號格式：產(chǎn)品名_主版本號.次版本號.修訂號.版本日期_希臘字母版本號，例iShuidi_1.0.0.190507_beta；
??主版本號：當你做了不兼容的 API 修改；
??次版本號：當你做了向下兼容的功能性新增；
??修訂號：當你做了向下兼容的問題修正；
??希臘字母版本號：①Alpha版，Bug較多，需要繼續(xù)修改；②Beta版，已經(jīng)消除了嚴重的錯誤，存在部分缺陷，需要測試消除Bug；③RC版，不存在導致錯誤的Bug，與正式版相差無幾；④Release版，“最終版本”、“上線版本”、“正式版本”、“標準版”，軟件封面上取而代之的是符號(R)。
??產(chǎn)品團隊須維護文檔時，需保證在項目所有人員手中版本一致性且為最新文檔。
??所有文檔版本更新管理時，需明確記錄“修訂記錄”和“簽批記錄”，方便追溯管理。
