文檔編號：ZD-190507-RMJC（1）
目錄
一、前言
本文檔的編寫主要用于對產(chǎn)品專員/助理及產(chǎn)品工作相關(guān)小伙伴入門時实檀，對產(chǎn)品經(jīng)理崗位進行了解辆童，并牢記崗位相關(guān)背景、職責(zé)及技巧幌绍，較快上手相關(guān)工作，早日成為一名優(yōu)秀的產(chǎn)品經(jīng)理故响。
二傀广、基礎(chǔ)認識
1. 關(guān)于產(chǎn)品經(jīng)理
產(chǎn)品經(jīng)理(Product Manager)是一個特別寬泛的詞匯，在不同的行業(yè)被去，產(chǎn)品經(jīng)理的指代意義完全不同主儡。比如旅游行業(yè)奖唯，產(chǎn)品經(jīng)理往往指的是負責(zé)開發(fā)旅游線路惨缆。而在金融行業(yè)，產(chǎn)品經(jīng)理的職能通常都是負責(zé)設(shè)計理財產(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)理等不同領(lǐng)域停巷，而且各個領(lǐng)域有著不同的側(cè)重點與工作內(nèi)容耍攘。主要是負責(zé)管理、規(guī)劃畔勤、設(shè)計乃至于負責(zé)實施工作的一個崗位蕾各。
2. 認識崗位工作
中國傳統(tǒng)的產(chǎn)品經(jīng)理的工作情景是這樣的：
? 沒完沒了的開會，根據(jù)會議中得出的需求開始制作方案
??畫流程圖吝羞、畫原型兰伤、寫文檔，方案完成后開評審會
??和項目組的人侃大山钧排，定下方案就開始項目溝通跟進
??最終測試驗收完成上線
真正有價值的產(chǎn)品經(jīng)理應(yīng)該是這樣的：
1) 不做需求的執(zhí)行者敦腔，而是需求的制定者。如果你現(xiàn)在只是被動接受需求恨溜，而不是主動提出需求会烙，那么這就是差距。
2) 為項目負責(zé)筒捺，確保做的事情有意義柏腻，是正確的。項目做成怎么樣系吭、要做到什么樣的程度五嫂、怎么樣做才有效果都是產(chǎn)品經(jīng)理要決定的。
3) 幫助項目取得成功肯尺。光做出一個項目還不行沃缘，你還要確保這個項目是成功的，成功的定義可以是你的項目廣為所知则吟、你的項目賺了很多錢槐臀、你的項目改變了人們的生活方式等等。
3. 你的協(xié)作團隊
三氓仲、工作內(nèi)容
（一）基本流程
主要流程包含以下關(guān)鍵環(huán)節(jié)：
1.?需求預(yù)受理：需求采集水慨、調(diào)研分析、整理匯總并歸檔需求池
2.?項目立項：制定項目方案敬扛、評估風(fēng)險及可執(zhí)行性晰洒、進行需求評審會議
3.?產(chǎn)品方案設(shè)計：原型制作、輸出需求說明啥箭、進行產(chǎn)品方案評審會議
4.?產(chǎn)品研發(fā)：開發(fā)谍珊、測試
5.?項目上線：驗收、部署上線
（二）詳細流程
1) 產(chǎn)品團隊通過向需求方采集及溝通業(yè)務(wù)需求急侥，記錄需求后整理匯總討論分析砌滞，期間著重探討業(yè)務(wù)需求的合理性、完整性和前瞻性坏怪，充分考慮各種流程贝润、各個環(huán)節(jié)以及異常流程的處理，并保證正確理解需求陕悬。
2) 產(chǎn)品團隊向需求方反饋預(yù)受理結(jié)果题暖，受理結(jié)果包括轉(zhuǎn)為正式受理和拒絕受理。拒絕受理的原因可能會很多，上邊提到的需求受理原則是考慮的主要方面胧卤，拒絕受理必須提供原因唯绍，必要時可與需求方溝通改進業(yè)務(wù)需求以達到正式受理的結(jié)果。
1) 正式受理后枝誊，開始執(zhí)行調(diào)研報告况芒、數(shù)據(jù)報告等。早期需求分析叶撒，需要保證需求點是清晰的绝骚、明確的、有意義的祠够、可測量的压汪，并且存在技術(shù)可實現(xiàn)性，同時符合市場運作要求古瓤。
2) 需求分析后止剖，調(diào)研人進行需求及評估文檔的編寫歸檔，文檔需要反饋用戶調(diào)研的結(jié)果報告及需求模型落君，以供技術(shù)評審討論使用穿香。
3) 邀請主要研發(fā)人員參與需求分析，初建立需求與技術(shù)實現(xiàn)之間的聯(lián)系绎速，確認需求的可實施性和難易程度皮获。主要與研發(fā)人員確認需求中重要部分的可執(zhí)行性，包括影響因素纹冤、實現(xiàn)關(guān)鍵因素洒宝、時間節(jié)點等，保證技術(shù)實現(xiàn)可在需求方預(yù)定的發(fā)布時間內(nèi)研發(fā)完成并上線赵哲，避免對項目進度及需求方滿意度的影響待德。
4) 如果確認技術(shù)可實施性，再組織產(chǎn)品會議討論并輸出解決需求的初步思路方案枫夺。
5) 邀請需求方進行初案審核，具體驗證每一個需求的定義绘闷、實現(xiàn)方式等橡庞，保證方案每一點都經(jīng)過需求方「批準的」。
6) 產(chǎn)品團隊實時跟蹤需求方需求變動印蔗，并對每次變更及時進行溝通確認扒最。并反復(fù)上述規(guī)范流程，直到需求方案最終確認华嘹。
??需求方案確認后吧趣，由我方指導(dǎo)需求方填寫并提交項目立項說明書，最終由全部負責(zé)人簽名確認工作任務(wù)后，項目方可啟動强挫。
??項目立項說明書（或業(yè)務(wù)需求單）主要體現(xiàn)需求點可執(zhí)行性岔霸、業(yè)務(wù)需求詳細說明等，可附帶附件俯渤、附圖呆细、附表等文檔，需求描述的粒度應(yīng)盡量細小八匠，并說明業(yè)務(wù)需求的重要程度和緊急程度絮爷。
??與需求方明確未提出的業(yè)務(wù)需求，在我方項目啟動前可以提出需求補充梨树，若已啟動項目開發(fā)執(zhí)行坑夯，后續(xù)產(chǎn)生的一切需求變動，可能導(dǎo)致的時間抡四、人工等成本是隨之變動渊涝，屆時酌情商討需求變動的具體執(zhí)行方案，或納入下一版本執(zhí)行床嫌。
1) 根據(jù)需求方案跨释，從需求實現(xiàn)的角度將業(yè)務(wù)需求拆分成系統(tǒng)功能點進行分析，并設(shè)計產(chǎn)品框架厌处。（建議先與需求方溝通確認基礎(chǔ)產(chǎn)品框架）
2) 制作并輸出原型圖（線框圖）鳖谈，并與需求方溝通確認原型設(shè)計稿，根據(jù)立項說明書/業(yè)務(wù)需求單檢查確保產(chǎn)品設(shè)計已對需求文檔的所有需求都進行了設(shè)計阔涉。（可將需求點標記為“已設(shè)計”狀態(tài)缆娃，方便需求設(shè)計管理）
3) 協(xié)調(diào)UI進行界面設(shè)計，并與需求方溝通確認界面設(shè)計稿瑰排，保證所有交互邏輯都是經(jīng)過需求方「批準的」贯要。
4) 撰寫需求研發(fā)說明（產(chǎn)品設(shè)計說明），根據(jù)產(chǎn)品功能點椭住、界面設(shè)計和邏輯實現(xiàn)崇渗，撰寫研發(fā)說明，幫助研發(fā)人員更好的理解和執(zhí)行所有工作細節(jié)京郑。（文檔形式自定）
??根據(jù)原型圖/界面圖/設(shè)計說明宅广，評審業(yè)務(wù)邏輯、交互邏輯等產(chǎn)品細節(jié)些举，提出異議并討論解決方案跟狱，根據(jù)修改意見進行方案細節(jié)優(yōu)化修訂。
??如遇重大邏輯問題駁回户魏，則返工與需求方重新溝通討論產(chǎn)品設(shè)計方案驶臊，并重新修訂產(chǎn)品設(shè)計方案挪挤，重新制作輸出相關(guān)需求設(shè)計說明等。
??評審?fù)ㄟ^后关翎，產(chǎn)品團隊將所有需求文檔提交研發(fā)團隊扛门，由研發(fā)團隊進行任務(wù)拆分指派，確定相關(guān)負責(zé)人笤休，并由各負責(zé)人對后續(xù)研發(fā)工作負責(zé)尖飞，包括統(tǒng)籌規(guī)劃、協(xié)調(diào)溝通等店雅。
??與研發(fā)團隊溝通并制定“功能計劃”政基、“時間進度計劃”等，其中包括開發(fā)闹啦、測試沮明、上線的工作內(nèi)容，項目計劃要與需求方達成共識并簽批同意執(zhí)行窍奋。
??研發(fā)團隊要嚴格按照計劃和需求文檔進行研發(fā)工作荐健，在出現(xiàn)問題時及時與產(chǎn)品團隊溝通。
??測試團隊同時編寫測試用例琳袄，并對存在疑問的地方及時與產(chǎn)品團隊溝通確認江场。
??完成后將每一個已研發(fā)完成的任務(wù)標記為“已完成”狀態(tài)。
??產(chǎn)品團隊審核測試團隊提交的測試用例窖逗，保證已滿足所有需求場景并符合產(chǎn)品設(shè)計方案址否。
??測試團隊（質(zhì)量保證組）測試產(chǎn)品研發(fā)工作并報告結(jié)果。
??測試合格通過后將每一個需求點標記為“測試通過”狀態(tài)碎紊。
??當完成內(nèi)部測試和用戶測試并保證結(jié)果無誤后佑附，提供用戶公開測試版本以供核收需求結(jié)果，核收無誤后與需求方確認上線時間仗考。
??需求上線由我方運維人員統(tǒng)一部署到實際生產(chǎn)線音同，工作完成后通知產(chǎn)品團隊和需求方最終驗收，并由運維人員監(jiān)控服務(wù)器穩(wěn)定器秃嗜，測試人員同時進行生產(chǎn)線最后檢測权均。
??上線前由產(chǎn)品團隊編寫好《產(chǎn)品使用說明手冊》以供需求方學(xué)習(xí)使用。
??必要時痪寻，由我方產(chǎn)品團隊為需求方講解項目實現(xiàn)情況和產(chǎn)品操作流程螺句，具體視需求方要求，但不負責(zé)對需求方的客戶進行培訓(xùn)等后續(xù)工作橡类。
四、其他指導(dǎo)
（一）業(yè)務(wù)相關(guān)
任何業(yè)務(wù)需求都必須了解其業(yè)務(wù)出發(fā)點芽唇，特別在需求方跳過業(yè)務(wù)背景的描述顾画，直接提出功能點時取劫，尤其需要追溯根源訴求。通過了解業(yè)務(wù)背景研侣，可以優(yōu)化需求實現(xiàn)方式谱邪，甚至有可能改變功能點。在需求文檔中可通過增加備注或描述業(yè)務(wù)背景章節(jié)幫助需求閱讀人員更深入了解需求的產(chǎn)生過程庶诡。
需求方往往從局部角度提出需求惦银，該需求可能沒有聯(lián)系其他模塊進行推敲，甚至?xí)凶韵嗝苣┦摹⒙┒窗俪龅默F(xiàn)象扯俱，我們在受理需求時可先通過詢問問題來了解該需求是否準確、清晰喇澡，是否與其他功能點和主題有沖突等迅栅，如果需求方仍存在模棱兩可的現(xiàn)象而導(dǎo)致無法清楚地闡述需求，我們可以不予受理晴玖。
??重復(fù)現(xiàn)象：有些需求可能以前提出過，只是尚未解決呕屎，或者已經(jīng)被否決让簿，總之是重復(fù)需求，對于該類重復(fù)需求秀睛，可研究原有需求與新需求是否有差異尔当，如果確認重復(fù)則不予受理。
??雜糅現(xiàn)象：有些需求中包含了多個子需求琅催，其中的某些子需求在其他需求中已經(jīng)包括居凶，即需求間存在交叉現(xiàn)象，這種情況下應(yīng)梳理子需求藤抡，確保沒有雜糅現(xiàn)象侠碧。
需求提出者有時可能只代表個人意見或一個小團隊的意見，或者提出者可能并不是業(yè)務(wù)主管部門缠黍，因此業(yè)務(wù)需求的提出必須首先在該業(yè)務(wù)部門內(nèi)部有權(quán)限人員得到認可后才能代表整個部門意見弄兜，否則為無效需求。
有些業(yè)務(wù)需求的提出可能涉及其他部門的業(yè)務(wù)操作流程瓷式，如果該需求的提出沒有征得相關(guān)部門的同意替饿，則在后期實現(xiàn)過程中會遇到阻礙，導(dǎo)致該需求無效贸典，因此如果涉及多部門的需求视卢，需求提出者應(yīng)與其他部門溝通，在合理的解決方案下征得他們同意廊驼。
有些業(yè)務(wù)需求的提出是為了解決一些特殊情況的發(fā)生据过，即小概率事件惋砂，但該需求的實現(xiàn)卻需要投入很大的工作量，該類需求可征求業(yè)務(wù)主管部門意見绳锅，必要時可讓業(yè)務(wù)部門出具小概率事件發(fā)生頻率報表西饵，從投入產(chǎn)出比的角度謹慎受理需求。
（二）需求相關(guān)
針對原有需求中尚未完善的規(guī)則鳞芙、表單眷柔、流程等進一步維護需求，此類維護不是需求變更原朝，而是在前期需求分析過程中驯嘱，需要等待業(yè)務(wù)部門提供的資料進行完善后，才能明確需求方案竿拆。這種情況下宙拉，應(yīng)在需求研發(fā)進程中，與各方人員明確提出存在的地方丙笋，并盡快維護和更新需求方案谢澈。
在評審后的需求如果有變動，如果確認接受該變更御板，則應(yīng)根據(jù)最新的需求要求重新修訂研發(fā)說明锥忿，并記錄變更歷史。需求變更必須有一定的流程怠肋，并征得業(yè)務(wù)部門和技術(shù)部門的同意敬鬓。關(guān)于需求變更，必須明確幾個方面：變更原因笙各、變更程度钉答、變更解決方案。
??因我方技術(shù)等原因發(fā)生滯后進度時杈抢，研發(fā)團隊及時向產(chǎn)品團隊提出数尿，產(chǎn)品團隊根據(jù)情況，制定解決方案及可行性計劃惶楼，并向需求方提出需求變更申請右蹦，經(jīng)需求方審批同意后，完成需求計劃變更并同步文檔更新歼捐。
??因需求方在當期業(yè)務(wù)需求范圍之外發(fā)生需求內(nèi)容強制變更時何陆，可通過向我方提出需求變更說明，詳細填寫項目問題豹储、需求變更內(nèi)容等信息贷盲，并由我方評估后，協(xié)商溝通項目時間及人工成本影響剥扣。雙方一致通過后晃洒，由產(chǎn)品團隊即時調(diào)整項目工作及同步文檔更新慨灭。
??明確雙方提出業(yè)務(wù)需求變更時朦乏，應(yīng)說明業(yè)務(wù)需求的重要程度和緊急程度球及。若為重大變化，則需要最高領(lǐng)導(dǎo)審批決定呻疹。
??新增的需求必須是有效的吃引、經(jīng)過分析的并且劃分了優(yōu)先級，更新并簽批需求確認書刽锤，在項目計劃和產(chǎn)品交付期間反映需求變更狀態(tài)镊尺，該需求的狀態(tài)是“已批準”。
??刪除并思、放棄需求庐氮，需更新并簽批需求確認書，并在項目計劃和產(chǎn)品交付期間反映需求變更狀態(tài)
??該需求的狀態(tài)保持為“已批準”宋彼，并在項目計劃和產(chǎn)品交付期間反映需求延遲狀態(tài)弄砍。
（三）項目相關(guān)
業(yè)務(wù)需求部門所需業(yè)務(wù)功能對整體業(yè)務(wù)系統(tǒng)影響程度，可分為非常重要输涕、重要和一般三個級別音婶，非常重要為最高級別。
??非常重要：需求實現(xiàn)對整體業(yè)務(wù)系統(tǒng)影響非常大莱坎，如該需求為關(guān)鍵流程的關(guān)鍵環(huán)節(jié)說明等衣式。
??重要：需求實現(xiàn)對整體業(yè)務(wù)系統(tǒng)影響大。
??一般：需求實現(xiàn)對整體業(yè)務(wù)系統(tǒng)影響一般檐什，如頁面顯示文字碴卧、字體、顏色等乃正。
可分為非常緊急住册、緊急和一般三個級別，非常緊急為最高級別烫葬。
??非常緊急：關(guān)鍵業(yè)務(wù)流程不能被正確執(zhí)行界弧、且無可替代措施。
??緊急：業(yè)務(wù)流程不能被正確執(zhí)行搭综，但存在可替代措施或方法垢箕。
??一般：不會對業(yè)務(wù)流程存在較大影響。
有些需求的實現(xiàn)依賴于另一需求的實現(xiàn)情況兑巾，即業(yè)務(wù)需求是有順序条获、按步驟進行的，在這種情況下我們建議需求可分期完成蒋歌，如果在一期尚未完成的情況下就提出新需求帅掘，可稱為“跳躍性需求”委煤，此類需求我們建議等基礎(chǔ)需求實現(xiàn)后再完善。
系統(tǒng)建設(shè)需制度先行修档，適當放寬要求也需制度并行碧绞，有些需求的提出是先行于制度，該類需求實現(xiàn)后的問題在于沒有配套制度或崗位作為運行的保障吱窝，可能導(dǎo)致系統(tǒng)與制度脫節(jié)讥邻，反而影響業(yè)務(wù)的發(fā)展。在制度并行的情況下院峡，需求提出者需給出制度下發(fā)的計劃表兴使，才能保證該需求的有效性。
不論是新需求還是需求變更照激，如果涉及層面比較廣发魄，可能影響到系統(tǒng)的上線時間，需謹慎受理俩垃，必須征得領(lǐng)導(dǎo)意見励幼，給出可行的方案供領(lǐng)導(dǎo)決策選擇，一般方案有三種：
研發(fā)中心對業(yè)務(wù)需求以時間為基線實行版本化吆寨，并統(tǒng)一規(guī)范管理：
1) 定義文檔命名赏淌、文檔編號及版本號信息：
??統(tǒng)一文檔命名格式：日期+文檔名+版本號，例190507產(chǎn)品設(shè)計研發(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版毛萌，不存在導(dǎo)致錯誤的Bug苟弛，與正式版相差無幾；④Release版阁将，“最終版本”膏秫、“上線版本”、“正式版本”冀痕、“標準版”荔睹，軟件封面上取而代之的是符號(R)。
??產(chǎn)品團隊須維護文檔時言蛇，需保證在項目所有人員手中版本一致性且為最新文檔。
??所有文檔版本更新管理時宵距，需明確記錄“修訂記錄”和“簽批記錄”腊尚，方便追溯管理。
