學校體系模組產品覆盤
背景
自己以前的產品歷程基本都是被動的接受需求將產品需求視覺化，或者是在已有的功能模組上圍繞著使用者體驗或資料指標做優化，並未有過負責某個模組化功能從需求點到落地上線的經歷。去年12月底的某一天，老大突然找到我說明年2月底版本即新學期開學前（一款教育產品）要上線一個新模組功能以提高ugc內容量。從需求提出到最終上線時隔兩個月的需求終於上線了，作為該功能的主owner以下是我對該功能的覆盤，主要從需求分析到產品設計再到專案推動過程中的思考及採坑，試圖從第一視角復現並反思這個新功能前世今生。
需求分析階段
「time：12.22-12.27」
老大通知要做這個需求時只是提出了這個想法，讓我自己先思考兩天之後一起和運營同事來一場腦暴。腦暴的內容如下圖主要是以學校為維度建立一個類似於線下校學生會的體系，會上大家集中討論了建立這個體系的目的是什麼？這個體系裡的成員都有哪些？有哪些階層？每個階層對應的行為是什麼？我們能給予每個階層的成員什麼？其實在這個會上大家討論的顆粒度很粗，只是大概描繪了我們想要做個什麼樣的體系。會後大家又在原有基礎上去結合具體的業務去聊顆粒度更細的需求點，緊接著便有了第二次腦暴，如下圖這一次大家集中討論大的功能點有哪些？比如體系內對應的等級身份，這些不同身份享有的不同特權，學校這個體系又是如何運轉的等等。
第一次腦暴
第二次腦暴
「time：12.28-1.3」
會上大家天馬行空的討論著，提出自己的想法和觀點，兩次腦暴會後便由我作為這次需求的主owner去拆解需求分配需求點給到對應的人員並確定每個時間點。如下圖體系一期主要是以學校為維度將學生會體系的框架搭起來，主要的功能點是宣傳導流、學校主頁、任務體系、一系列特權等。帶著下面這張圖我們產品和運營的相關人員利用晚飯後的時間再對了一遍整體的功能點和各自負責的內容並在會上確定各自需求的產出時間。
需求點拆解
產品設計階段
「time：1.4-1.18」
確定完分工後便在幾天內需要給出第一版設計方案並和產品、運營相關同事討論設計方案。在落到具體的設計方案上並沒有著急去畫每個頁面的原型圖是什麼樣，還是先從平臺和使用者兩方面出發去思考使用者想要什麼而平臺方可以給到使用者什麼去拆解對應的需求點再落到具體的功能點上。以下便是該功能的使用者角色行為&權利：
角色行為&權利
功能點
當把每個角色的拆解後便開始正式的產品設計產出具體的原型圖，但在設計過程中發現雖然功能點上圖都羅列出來了，理論上按照需求的優先順序去設計具體頁面就可以了但在實際產出中想象和結果出入很大。當自己拿著第一版原型圖去和產品、運營去討論時別人會問你為什麼會這樣設計？為什麼沒有突出這個功能為什麼沒有突出那個功能？雖然聽了別人的意見我又修改了兩版，但大家對具體的設計方案仍然不滿意。下班後回到自己的住處我沒有再立即想著修改方案，而是思考問題點，最後我才意識到自己並沒有真正的從使用者的使用場景出發也就是站在使用者的視角去設計具體的頁面。在第一次討論後我便試著從使用者角度出發去思考使用者的使用路徑是什麼，接下來便有了下面這兩張圖：
核心模型
使用者路徑
使用該功能的主要是兩類使用者，一類是對名利特權感興趣的普通使用者，另一類是已經擁有身份的特權使用者。根據這兩類使用者的使用路徑我又重新改了一版設計稿，再次拿著新的設計稿和同事們去討論。這一次的討論最終通過了設計方案，是因為這一版的方案裡明確了都有哪些頁面，頁面裡的功能有哪些，每個功能這樣設計的目的是什麼都一目瞭然。
反思：
設計一個全新的功能和日常優化已有的功能有很大的一個區別點在於，優化功能就是在使用者已有的使用場景和需求下暴露出來的問題，不管是通過使用者反饋還是資料分析上都能直觀體現出來，比如上傳完成率很低，那通過去看從入口點選到上傳完成各環節的轉化率便可以有針對性的去做優化。在設計新功能時你很難以這種思維方式去設計功能，應該是站在巨集觀和微觀兩個角度去思考如何設計具體的功能。從巨集觀上抽象出使用者型別、使用者間的關係模型、使用者使用路徑等，站在全域性的視角去思考，再將這些抽象出來的模型去指導自己的具體功能設計上，而從微觀角度上更應該結合使用者的使用場景，使用者的需求出發，站在使用者的視角去設計功能點。只有從全域性和使用者兩個視角去設計功能才能真正讓某個功能完整且合理。
專案跟進階段
「1.23-2.22」
方案通過內部評審後便進入技術評審，評審後進入設計出圖環節。在這一環節遇到了我過往所有專案跟進過程中最大的挑戰：與UI設計師出現巨大的分歧（注：專案組暫時沒有真正的互動設計師而給這個功能出圖的UI設計師以前兼任過互動的工作但又並非互動出身，且設計師本人性格過於執拗和強勢）。設計師在出圖階段因不瞭解需求的背景單方面的從她自己所謂的使用者角度、運營視角對設計方案提出質疑並給出自己的方案，一開始給她解釋為什麼要設計這樣的功能時她便拿出自己多年大廠工作經驗來壓我，而且一直說應該這樣設計滿足使用者哪種哪種需求。當我試圖再進一步溝通時她完全表示拒絕溝通而且直言不能說服她就不出圖，這種情況下最後只能叫上我老大和設計負責人一起再和她溝通，最終才將UI圖設計出來給到開發。
反思：
1.在這次專案經歷中真的切身感受到 產品經理日常工作中分歧最大的不是總和自己撕逼的開發而是設計師。 因為於開發而言只要產品經理的需求文件業務邏輯完整就很少有爭執，具體的功能只有能實現和不能實現兩種，能實現的只要是排期給夠都能做，所以日常溝通中更多的是因為產品經理的需求不明確，邏輯混亂不完整導致的。但與設計溝通中他們總是站在自己的角度去認為該是怎樣的。或許正是那句人人都是產品經理火了以後就都認為我可以站在使用者角度認為某個功能應該怎麼設計而完全忽略了站在全域性的角度去設計功能。產品經理設計方案其實是在制定規則，而如果像大多數設計師那樣說的從某個使用者出發去設計或者只在某個區域性點上去思考，最終設計出來的產品是個混亂且臃腫的四不像。（有些偏運營驅動的業務產品也會有類似情況，因為很多運營也都是一味的想把所有功能堆在使用者面前，生怕使用者不知道不清楚，或者只要有使用者反饋就認為該上線某個功能）
2. 產品經理要強勢且自信，切勿讓設計師或者運營帶節奏影響你的功能設計 。接上面說的，因為設計師的強勢甚至有些槓精我做了一些退讓，某些功能在出圖過程中被設計更改。但在最終上線後發現使用者使用中存在問題，只能落到下個版本改回來。所以這又再一次提醒我自己雖然性格好但在工作中特別是在設計方案方面只要自己的需求本身沒有問題不管是研發還是設計甚至運營提出異議時都要力排眾議站在使用者立場上堅持自己的方案。
3. 虛擬碼般的需求文件節省你一般的專案跟進時間 。因為這次功能比較大且第一次主導去設計，在寫需求文件過程中要考慮各個頁面的業務邏輯和交叉邏輯，有些地方存在需求不明確或者邏輯細節漏掉的情況。所以導致開發過程中總是要和不同的研發去明確細節，本來應該留給自己思考或者處理其他事情的時間都浪費在了溝通細節上。當產品經理的需求文件寫的足夠完整清晰，在後期專案跟進環節將有更多充足時間去思考下個版本的需求而且還有利於提高有效地工作時間。相反開發中的需求文件如果存在很多細節問題，也會伴隨著大量的溝通時間。
4.溝通要在合適的時間下才是有用的。上面提到的和設計師的溝通分歧其實很難在出圖過程中通過自己去說服別人，因為在她心裡當前的我可能做得方案都是錯的不合理的。最後只能通過我老大和它的老大去說服她，同樣一件事不是我不能把原因說清楚，而是在那個情景下她已經聽不進我說的內容，去找她願意去溝通願意去聽的人效果會更好。專案進入尾聲後我單獨找了一個合適的時間去和她溝通，介紹我們大的專案背景說明每個功能設計背後的目的。最終和我們設計師還是重新回到了很友好的關係，之後的需求出圖環節她遇到分歧點時我們也能很心平氣和的去溝通去試圖說服對方。
效果迴歸
「time：2.27-3.6」
功能上線一週後便需要針對功能效果做迴歸分析。分析本質還是要圍繞著功能目的出發通過資料去看是否接近或者達到目的，目前存在的問題是什麼，接下來的規劃是怎樣的。
總結
這一次的學校體系專案像是午後的瓢潑大雨，雖然短暫卻深刻的洗滌了我。不管是需求分析、產品設計還是專案跟進環節，於我而言都是一場考驗。在這場考驗中充分暴露了自己這三方面中的不足，也讓我自己深刻認識到需求分析環節要從巨集觀的全域性角度去思考去梳理，對需求的把握要更精準；產品設計中還是要站在使用者角度去結合場景設計對應的功能點，絕不是我想讓使用者使用怎樣的功能，走怎樣的流程，而是按照使用者的真實場景和需求出發；專案跟進環節應該更高效處理並推動專案程序。