起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何落地一個中型產品項目？
一個中型產品項目該如何落地？作者結合自身工作經驗，與大家談談做這個項目的思路以及框架，希望對你有所幫助。
7月份的文章還沒有發，思來想去準備寫之前在《聊聊數據中臺》中有提到過的數據建模，但由于它的專業性較強，不夠接地氣，決定還是寫一篇自己是如何做一個中型的項目。招聘系統的內部推薦模塊是我去年做的一個真實項目，所以很細節的設計圖或數據就沒辦法給大家展示，主要看一下做這個項目的思路以及框架。
一、項目背景目標價值
1. 背景
一般一個項目的背景可能會有很多原因，如：
1. 市場環境發生改變，用戶的習慣（需求）發生改變。
2. 新技術的出現，打破原有的局限，使得降本增效更加明顯。
3. 來自競爭對手的壓力，需要提升產品在市場中的競爭力
4. 商業版圖拓展，讓外部看起來很牛逼，吸引到更多的資源。
問題來源于背景，目標是用來度量問題是否被解決。而價值則是目標完成后賦予的意義。
在早些時候，企業或政府招兵買馬，依托的是員工身邊的親戚朋友介紹，給介紹人一點好處，但這種方式受限于一個人的親朋好友的數量。在如今數字化時代，各種社交工具的誕生，極大地擴寬我們人脈關系，并且提升信息傳播的效率，企業需要一個數字化工具來管理和運營內部員工推薦的這一渠道。
（1）定義問題
假設我們做內部推薦這個項目的背景是1和3，你得到的問題一：市場需要，客戶有訴求，如何解決客戶這一訴求？
問題二：和你切分同一塊蛋糕的競爭對手有這一渠道而你沒有，導致在客戶選擇上更傾向于你的競爭對手，如何解決這個問題？
你覺得以上兩個問題，是真實的問題嗎？就可以開始去做了嘛？不是的，你可能還要去驗證問題的真偽。
問題一市場有需求，客戶有需要，市場的需求量有多大？80%的企業都需要？客戶的訴求有多強烈？沒有就不用或不買？
問題二一般是銷售或者老板那邊反饋過來的，那你就要問有多少客戶有這一訴求？是否全部因為這一渠道沒有丟了單子？競爭對手做到什么程度？
搞清以上問題才是決定做與不做，在企業不同的階段的針對上述問題或訴求的處理方式不一樣，所以并不是所有的項目或者問題都要立馬去做去解決。
（2）目標
假設你已經做了充分的市場調研和競品分析，以及評估目前公司所處階段是有余力去做這件事，那么問題一和問題二其實都是指向同一個目標，就是你們得有內部推薦這么一個渠道。
那么目標二應該是做了這個渠道工具之后，會有多少客戶愿意使用（付費）或者說能帶來多少的新增客戶？
目標三：內推這一渠道的增加，可以給招聘提效多少（崗位招聘周期縮短多少）？招聘質量提升多少（簡歷通過率、面試通過率、員工轉正率等）？
（3）價值
問題和目標清晰之后，價值也會變得更加清晰。
從客戶側：幫助客戶解決公司的人力資源業務問題，拓展內部推薦渠道，使得招聘的效率和質量都得到很大的提升。
公司側：降低外部壓力，獲客增多，營收增加。
2. 業務流程梳理
核心場景的梳理可通過調研客戶的業務場景和流程，將客戶業務場景通過泳道圖表達出來，使得對整個需求場景有一個更全面的理解。
（1）角色
內部內推涉及的角色有哪些？候選人、員工、HR、HR管理者，首先要分析這個產品會有哪些角色參與？他們的分工是怎樣的？上下游的流轉是怎么樣的？有哪些前置條件？和其他功能模塊的關系是怎樣的？
（2）核心場景
1. HR在職位發布/管理的時候可以設置哪些職位是屬于內推職位以及創建內推項目的時候可選擇哪些職位進入這次的內推項目中來。
2. HR可以進行多個內推項目的創建，適用于分公司或不同的時期。不同部門或不同崗位可獨立配置職位的獎勵規則。
3. 內推活動創建后，可在哪些地方展示？可通過哪些方式分享出去？哪些人可以分享？通過什么方式知道投遞的候選人是某個員工分享職位帶來的？
4. 內推投遞的候選人在哪些地方查看？候選人是否可以查看自己被內推的進度？員工在哪里查看自己內推的人選進度和狀態，以及獎勵情況？
5. 內推的效果如何？內推職位和非內推職位的招聘周期是否有變化？內推的成本如何？內推獎勵如何發放？不同職位和不同部門員工的內推情況如何？
3. 商業模式和運營策略
（1）商業模式
B端產品的商業模式主要分為兩種：一種是按賬號收費的訂閱模式；一種是買斷制的私有模式；
訂閱模式一般也就是我們常說的“SaaS模式”，可以按照不同功能或同一功能的不同限制包裝成一個個套餐進行售賣，也有按照不同模塊功能包進行售賣（對于一些企業用不到該功能包可以降低他們的成本），直接買斷的客戶很少。
回到內部推薦這個項目，如果是你來負責，你會如何思考它的商業模式？商業模式的設計直接關系到最終這個項目能否為公司帶來價值，間接關系到你的結果。
（2）運營策略
B端的運營策略和C端大同小異：活動運營、客戶（用戶）運營、產品運營。
內部推薦這個項目主要是從產品上如何進行運營？
1. 產品設計上
a. 功能上線后在菜單入口增加一個“New”小圖標，吸引用戶點擊，讓用戶更快發現新功能。
b. 增加指引或新手任務，讓用戶可以更快上手使用，降低學習成本。
c. 內部推薦是需要員工將職位分享出去的，那么就可以在分享的“海報和鏈接”頁面底部增加“Power by XXX”字樣，相當于在給公司打廣告。
d. 生成季度或者年度的員工內推報告，如這一年你推薦多少人，有多少人入職，為公司節省多少招聘成本等等，總的就是設計讓員工有分享欲的數據。分享的海報帶上公司的品牌“Power by XXX”。
2. 渠道運營：公眾號、官微、官網、系統公告的關于內部推薦的介紹等等。
4. 產品設計
（1）產品規劃
產品規劃一般是在確定要做的情況下，并且已經確定大概的產品方向，分步進行到達目標就需要對產品進行規劃，規劃每一個版本要做哪些事情。
還是以內部推薦為例，之前有提到內推是企業的一個非常重要的招聘渠道，不僅僅是內部員工的推薦，如果說希望能夠更快的招聘到候選人，還需要外部的推薦，那么這個時候社交化招聘就誕生了。所以在進行內部推薦規劃的時候，可以根據推薦角色的不同分為：內推+外推，一階段先滿足企業內部員工的推薦，第二階段再去做外部推薦。因為外部推薦涉及到權限、多重分享、獎金分配計算、提現等等復雜業務場景，也是相對難度更大的一件事。
回到內部推薦，又可以根據業務流程拆分為：配置——分享/推薦——入庫——查看/統計——獎勵發放，從配置到入庫已經是一個最小閉環，也就是我們通常說到的MVP版本。
所以總結下來產品規劃要做的事情就是從產品的全局角度，對產品大致方向進行近中長期的規劃。關于MVP版本的規劃可根據業務流程的最小閉環和滿足kano模型中基本型需求，進行校驗。
（2）產品架構
產品架構是對現階段產品上下游關系的解構，包含詳細的產品功能，可以幫助我們更好的理解產品之間的關系，了解產品大致的功能內容。
如內部推薦，他上游對接的職位管理、員工組織模塊，下游對接的候選人管理、數據分析、招聘官網、薪酬等等。以及內部推薦自身又需要拆分出來幾個大的子功能模塊，如內推設置、C端展示/分享/查看、數據統計等。
（3）用戶故事
用戶故事是基于用戶真實場景遇到的問題，希望得到的解決方案，目的是一方面幫助產品研發團隊更好的理解用戶需求和業務，另一方面也可以根據用戶故事進行優先級的判斷，確定高優先級的需求，從而在最短時間內完成最小可行性產品。
用戶故事一般可從4個方面進行撰寫：用戶角色（ WHO）、遇到了什么問題（WHY）、希望怎么解決（WHAT）、優先級。例如：
（4）原型設計
根據前面的業務流程梳理、產品架構、用戶故事，我們腦子里面對這個產品已經越來越清晰了，接下來就是把腦子里面的畫面用圖進行展示出來。
原型設計需要我們平時對一些優秀的交互、組件有一定的積累，設計起來會非?？?。并且B端的頁面相對都非常的固定（表單配置、列表展示、按鈕彈窗等），重要的是我們對于用戶需求的理解，重要和非重要的信息如何放置，這個操作是否高頻，我們希望引導用戶如何操作、新用戶和老用戶是否有差異、操作有沒有異常情況并如何處理等等。
這里舉一個內部推薦的交互設計例子，內推的職位其實是拿的職位管理模塊中的職位，職位都是有狀態的（招聘中、已暫停、已關閉和已刪除等），在選擇內推職位的時候是不是只展示“招聘中”的職位，需要對選中職位進行C端展示排序（緊急在前面、技術崗位在前面），這個交互就比較復雜（當時我記得和研發爭論點在于：在選擇職位彈窗中進行排序還是選擇完了之后在職位列表頁面進行排序？在選擇彈窗中進行排序研發成本會比較大，在選擇之后在列表中排序整個流程比較冗余），所以產品經理就需要對用戶需求理解較深，是否在選擇彈窗中就有對職位排序的需求以及概率是多少，從而進行取舍，決定如何做。
異常場景的處理：如果說某個內推職位被關閉了，那內推的職位是不是也要跟著關閉，那這些內推職位是否還要展示和在后臺內推職位列表中如何展示，以及分享出去的職位和進入流程中的候選人如何處理等等。
這里還想再補充一點，交互設計直接影響到產品的使用體驗，尤其在用戶被一些優秀的C端產品教育之后，對于B端產品的用戶體驗也會有一定的要求，用戶口碑很多時候就是用戶對于產品使用感受的傳播，所以B端產品的用戶體驗同樣重要。
（5）權限設計
權限設計是產品設計非常重要的一部分，關系到數據權限和功能權限，特別是一些敏感數據不該一些人看到，一些重要的操作不該所有人都能操作，被泄露和誤操作的影響是非常重大的。
權限設計最熟悉的是RBAC模型，即：用戶、角色和權限，簡單的理解其理念就是將“角色”這個概念賦予用戶，在系統中用戶與權限之間通過角色進行關聯，以這樣的方法來實現靈活配置。RBAC其實是一種分析模型，主要分為：基本模型RBAC0、角色分層模型RBAC1、角色限制模型RBAC2和統一模型RBAC3。感興趣可以去了解下它們的區別。
內部推薦涉及到的一些權限，無非就是內推配置的「增、刪、改、查」，權限跟著角色走，默認管理員可操作，其他角色的權限由管理員分配。
（6）數據埋點
B端數據埋點的目的主要有兩點：一是分析產品功能的使用情況，二是分析業務情況。
分析產品功能使用情況有助于我們了解這個功能上線之后，客戶對于該功能的需要程度（用的越多說明越重要，后續做更多的迭代優化）。分析業務需要是客戶對于自身業務運轉情況的了解，針對性解決業務中的問題（如渠道分析，分析不同渠道的貢獻度，資源投入也會向貢獻度高的渠道傾斜，以及是否要拓展其他渠道）
內部推薦這里的埋點也分為：功能埋點和業務埋點。功能埋點如“內推使用客戶數”，業務埋點內容就有很多，更多的是一些統計分析表如“內推職位招聘周期分析、內推渠道分析、內推員工分析等”。
5. 項目中后期的一些事
（1）需求評審
需求評審我覺得沒什么好寫的，只要按照前面的流程把要做的產品想清楚了，基本不會有什么問題，只說三點建議：
1. 需求評審不要讓參加評審的人打斷你，可以先告知說有問題先記下來，等你快速講完再提問，否則非常影響你的節奏。
2. 需求評審中不確定的內容，請在評審之前就解決掉，在評審中大家再探討很浪費時間，有可能你還需要大改產品方案，這是最難受的。
3. 需求評審中需要研發或者測試注意的點，提前標注好或者記好，專門在會上著重提醒一下，節省后續的溝通成本或犯錯成本。
驗收和培訓項目的驗收和培訓，各個公司的流程有所差異，也沒什么可說的。驗收的時候重要的功能和流程多測幾遍，上線后再驗證一次。根據培訓的對象不同，培訓的內容側重點也會有所不同，如果是面對銷售和市場部門，要講清楚產品的價值、亮點/友商差異化以及使用場景。
（2）驗證和復盤
項目在上線后，進行數據的觀測和復盤是非常有必要的，這可能直接關系到你的晉升。項目復盤的方法有很多，比較常用的STAR原則，即“背景、任務、行動、結果”。我在此基礎上增加了一個“plan”，下一步的計劃。
SITUATION:?情境，即描述背景，你在當時所處的環境或者面臨的挑戰。比如你當時要做一個從來沒有接觸過的項目，公司沒有成功的先例可以參考；或者在一次團隊合作中與同事出現了意見分歧等等…盡量與工作相關，描述的盡可能詳細。
TASK:?任務，指描述你當時的任務，或在當時環境下你所承擔的職責。比如你是這個項目的組織者、策劃者，需要帶領團隊探索未知。或者你需要解決與同事之間的分歧，試圖說服他聽取你的意見等；或者是達成銷售目標…
ACTION:?行動，即表述你和你的團隊做了什么事情，如何克服挑戰。
RESULT:?結果，解釋所采取的行動產生了什么結果，對比目標是否有實現，從中學到了什么。
PLAN：計劃，講述下一階段的計劃和可能達成的目標。
總結
總結一下：拿到一個項目，不要直接開始就干，首先搞清楚為什么要做，不做會怎么樣，做的價值在哪里，如何驗證項目是否做的成功；其次再去思考，看看市場上其他人是怎么做的，不同行業客戶的訴求是怎么樣的，我們做的話別人為什么會選擇我們；最后才是動手去做。在做的過程中要時刻思考用戶的真實需求是什么，把用戶體驗做好，要考慮到異常場景以及權限如何設計。
至此整個《如何落地一個中型項目》全部完結，也是我這幾年做產品的一些積累和探索，只是為了完成某個項目和認真的去做某個項目，帶來的收益（公司/個人）是完全不一樣的，不管項目大小，按照我這個框架去思考，一定會讓你收獲頗多！希望對大家有所幫助～
本文由 @Glee 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
根據項目規劃，開始進行產品設計、編碼和測試等開發工作，在開發完成后，需要進行集成和測試，確保產品的穩定性和可靠性，消費者信的過很關鍵。