本文由作者周巧芬授權網易雲社群發布。
網際網路的產品相對傳統it產業而言，需求更富有多樣性。傳統it行業的需求點多是固定且符合驗收條件。但網際網路的產品則更多的從使用者體驗出發，更多的用資料來說話，不管是pv、uv、轉化率、留存等等。很顯然在乙個接著乙個的迭代背後，我們必須要讓需求到資料到改進實現閉環，才能在產品上精益求精。今天就來**下如何從專案經理的角度出發，將這些環節形成閉環，更好的為產品的精益求精服務。
近期，筆者所在的團隊也正在**全流程專案管理的探索。專案經理在理清這些環節之餘，更多的參與其中，想必對行業背景的積累以及產品觀等多有益處。
什麼是閉環？
閉環(閉環結構）也叫反饋控制系統，是將系統輸出量的測量值與所期望的給定值相比較，由此產生乙個偏差訊號，利用此偏差訊號進行調節控制，使輸出值盡量接近於期望值。
顧名思義，要形成乙個閉環，則需要乙個期望值，乙個測量值，並有反饋和調節。對於網際網路產品來說，亦是如此。而對於網際網路產品而言，期望值和測量值往往都是由資料去呈現。因此對於需求—資料—改進的閉環，可分解為以下三點：
l 產品功能互動設計之初，明確方向，設定指標（kpi）。
l 產品開發過程做好埋點，確認資料**，獲取資料。
l 分析資料，並反饋到產品功能互動設計。
下面，分別展開講講每一點在專案中我們應該如何去做。此處只是從專案經理的角度出發我們在專案開展中可以去關注的環節，對於資料驅動創新等更專業的內容建議大家可以閱讀《精益資料分析》。
1. 功能設計之初，制定指標
明確定義：
產品的孵化和各功能模組的設計在最初的時候都有乙個初衷，去解決使用者的痛點。從產品初衷到產品形態，如何去衡量我們做的每乙個功能使用者是買賬的。在最初始階段，我們就需要設定指標來衡量，而其中資料指標是最為量化和直觀的。但在這個過程中，不能僅僅就提出資料指標，更要明確定義每個指標的具體意義以及計算方式。
而每個指標的背後，都應該為產品的方向和目標服務。比如乙個即時通訊的工具，那麼使用者之間的訊息量、好友數也許是我們衡量這個產品健康度的指標，因為這兩個指標和我們的核心功能切合。
通常來說，在產品設計之初，產品經理和策劃就應該根據自己對產品的思考整理出核心指標。核心指標也並不是不變的，在產品mvp驗證探索階段，也許產品的方向都可能發生變化，此時核心指標也會發生相應的轉變。
達成共識：
在定義好核心的指標之後，我們應該針對這樣的指標整個團隊達成共識。這樣的方式可以採取多次的頭腦風暴，以及討論會。在這樣的過程中，其實大家可以更加深入的去挖掘。參與人員包含運營市場產品設計以及開發測試，只有大家共同理解目標，在每個工作環節才能集中精力為這樣的目標去努力奮鬥。同時這樣的乙個過程也建立大家對產品的一種主人翁意識。
2. 鋪平資料**之路
對於資料指標達成一致意見之後，那又如何常規的獲取資料呢？
在產品研發過程中，對於資料獲取的途徑一併考慮，則可以節約很多後期跑取資料的繁複過程。比如資料埋點的接入，核心kpi系統的搭建。都是用來呈現常規資料的手段，隨用隨查，而無需再要開發人員跑取。
在我們日常產品中，通常資料的**有三處，乙個是伺服器資料庫資料、二是日誌資料，三是埋點後收集的資料。伺服器的資料和日誌的資料相對來說比較精準，但很難做使用者使用路徑的分析。而埋點資料，由於受第三方資料分析系統的上傳策略限制，在精確性上存在一定的折損，通常用來做使用者路徑的分析，資料對比，以及日常觀測。
資料埋點：市面上目前有很多種第三方資料分析統計平台，比如ga等，但功能較為完善的通常都需要收費。目前我們使用的是網易杭研新推出的hubble。
對於埋點，會涉及到埋點事件，以及埋點事件的屬性和標籤，結合資料分析平台。產品策劃同樣需要在產品設計過程中，理清楚埋點的需求，提交給開發。而埋點的需求通常會結合分析使用者行為、各維度資料呈現的要求。如下圖就是hubble當前提供的分析功能。以及某產品策劃整理的埋點文件。
圖1 hubble提供的功能列表
圖2 某產品埋點文件示例
同樣埋點需求文件也是需要在產品迭代中不斷的維護更新。因此，也建議大家將埋點需求文件和需求管理結合起來。在整體的開發流程中，關注埋點需求的落實和驗證。在開發工作量上，埋點需求處理起來較為簡單。而驗證的環節可以通過埋點包來完成，也可以直接在第三方後台檢視資料生成的狀況。
所謂工欲善其事必先利其器，想讓資料驅動，那麼這些工作的完備開展會極大的幫助大家的日常工作。
3. 資料指標帶來的反饋
有了資料，我們又應該如何去對待資料從而帶來正向的反饋呢？
對於團隊
資料指標應該定期的反饋給團隊，做到資料資訊透明。這個有很多的方式，比如例行的資料週報傳送，資料平台的許可權開放。另外，也需要培養和調動大家對資料的敏感性。我們以前一直在談如何提高成員的ownership感，而我認為，讓大家更透明的了解自己正在為之奮鬥的產品的狀況則是非常重要的一點。核心資料指標較為健康，整體向上的趨勢，對團隊來說無疑是最好的激勵。而當資料下滑或者出現異常，整個團隊就需要提高危機感，從而共同審視當前的工作，是否可以為了資料上揚而做些力所能及的事情。
對於產品和運營：
上面講了那麼多，其實最終還是要為產品和運營服務。那麼最後一環我們應該怎麼做，才能真正的達到閉環，讓資料真正的被利用起來呢。配合相應案例，希望對大家能有所思考。
l 預警和產品、運營的優化：
資料的異常變動，可能提示著某個異常，舉個例子：某產品在頁面上端做了黃條的訊息提示，用來做日常資訊通知等。但在一次版本改版中，為了便於區分不同的資訊型別，新增了灰條。資料後台則會發現，頂端訊息通知的點選率大幅度的下降，灰色相對黃色，醒目程度大打折扣。後續產品做了緊急調整，棄用灰條。
又比如使用者流失預警系統，下圖則是某產品流失預警中的某個**。很顯然，通過這個**，則可以明顯的發現有一部分使用者流失概率較高。從而可以抽取這部分使用者，對這部分的使用者做一些特徵的挖掘，或者直接通過**訪問等方式來調查使用者流失的原因。從而使得產品在這些方面得到反省和優化。當然，也可以針對高流失概率的使用者做一些運營活動的召回。
圖3 某產品流失預警資料表之一
又比如下圖所示：則是某產品日常資料週報中很常見的一點。我覺得已經無需贅述，大家自然就可以看到在這個過程中，運營策略發生的變化。。
圖4 某產品日常資料運營週報部分截圖
l 驗證設想， a/btest
再舉個例子：在某產品的某個頁面中，對於商品的展示方式如何能帶來更高的點選率，設計了兩個模式。因此需要對這兩種方案設計a/b test。如下圖所示，就是a/b test的資料對比，很顯然，下圖中的d版本明顯點選優於其他版本。最終則考慮所有的頁面全部切到d方案。
圖5 某產品a/b test資料對比圖
綜上幾個案例，我相信大家肯定可以看到資料在產品和運營中的這種反饋作用。而這個過程更多的需要產品策劃和運營具有一定的資料驅動意識，在這個方向上的精進，無疑對工作會帶來很大的益處。
如上，是筆者在日常專案管理過程中，對於需求—資料—改進 閉環形成的看法。對於資料創新驅動業務等課題，已經有很多專業性的文章和書籍做了研究，但筆者想表達的是，在日常工作中，我們關注點點滴滴，踏實做好每一步才是最重要的。
免費領取驗證碼、內容安全、簡訊傳送、直播點播體驗包及雲伺服器等**
從需求到測試
詳盡的需求是系統測試的基礎，反過來只能通過測試來判斷軟體是否滿足了需求。你必 須針對軟體需求規格說明中所記錄的產品的預期行為來測試整個軟體，而不是針對設計或編 碼。基於 的系統測試可以變成 自滿足的預見 self fulfilling prophecy 產品可以正確 呈現基於 的測試用例所描述的所有...
從需求到設計
從需求到設計分為 需求 分析 設計三個步驟。1 需求收集和整理階段 盡量詳盡的收集客戶的需求，把複雜的業務化成業務流程圖。需求整理就是把需求按客戶的業務模組進行整理，分模組把需求按業務邏輯整理一遍，去除雜質 規整業務 履順業務流程。2 需求分析 分析整理好的業務需求，把握業務的資料流，畫出業務流和資...
需求從0到1
軟體是一種工具，是用來輔助人們解決某些問題的 相關的問題，組成問題領域 因此解決問題是軟體存在的價值，所以軟體的價值是符合某個問題領域的需求，從問題領域出發找構建軟體系統的重要性由此而得。充分了解問題領域，能夠幫助你理解需求 涉眾分析報告 通過以上大類，對專案範圍的社眾進行調查和訪談，書寫成涉眾報告...