本文作者對To B 產品的迭代工作進行了總結，主要分為兩部分，一是形成迭代規劃個人總結的思路；二是執行迭代工作的執行步驟。enjoy~
有機會負責過大型 to B 系統軟體產品迭代設計工作，是物聯網行業產品，該系統產品由終端、PC web端、手機app端組成，可以通過pc web端系統或者手機app來控制終端。增加或者減少一個功能，往往會有牽一髮而動全身的感覺，同時接手時幾乎是沒有任何規範的文檔來記錄背景信息的（沒有那就一邊開展迭代工作一邊建立對應的規範，然後不斷修改補充）。
以下就是一點總結：
產品在開展迭代工作前，得去理解這個產品是如何從0到目前階段的。
方法有：
當對產品有了一定的了解後，就去形成一個迭代規劃，然後執行迭代工作。
to B 產品，一般的商業邏輯是通過向客戶售賣硬體以及配套軟體授權來賺取回報。而當一個toB產品充當一個組織想進入並壟斷某個行業的切入點的角色時，該產品在迭代規劃時所要考慮的維度可能就會更多。
比如一個誕生在一家初創物聯網公司的toB產品，該公司也有遠大目標，迭代計劃要考慮的包括可能還不限於以下維度：
（可能還有疑問說版本規劃還得考慮團隊成員本身情況，執行迭代過程中確實需要考慮，但是產品版本規劃是不會停的只要這個產品想要發展下去。）
這些維度在實際迭代過程中是需要做出平衡與取捨以及排列優先級的，如何取捨以及安排優先級常用的衡量標準是由目標以及價值來決定，當然也會受到各種條件的制約，而且這些維度的狀態、衡量標準以及制約條件是隨著時間而動態變化的，在某些時間段內側重的維度也可能會不同。
在版本規劃中還要注意把握時間的節奏點，可參考蘭徹斯特戰略中的市場佔有率原則，別在大家都有機會的情況下錯失時機，讓對手領先牢牢佔據了市場。
基於這些維度的思考，大體梳理出適合該產品發展的大方向；在執行迭代規劃的過程中，不要偏離這個大方向。
比如公司要利用該產品達到的目標僅僅利用公司自身的業務發展可能比較漫長，通過與某一方面更有優勢的第三方合作（客戶需求的產生）可以有助於達到該目標，價值很大，那麼在迭代過程中就會插進來客戶的需求，在某一段時間內尤其注重去執行客戶的需求，把產品要達到的目標先暫時放一放。
而當要準備依靠產品自身去打開市場前，就會將迭代計劃集中在產品核心功能的優化上。
to B 產品在產品的0到1階段，為了保證安全準確，也會先上核心功能，但是可能實際開發出來後用戶體驗還不是很好，在合適的時候迭代計劃就會注重打磨細節，畢竟toB產品注重穩定性、效率，尤其對於複雜型產品。
如果不注意打磨細節認知負荷增大、操作負荷增大，用戶使用產品的效率就達不到好的效果了，產品整體價值也會被降低；何況toB產品的發展趨勢也是越來越注重產品的易用性好用性，尤其當產品推向市場的時候，外界評價產品的維度往往會由核心功能的價值轉變成細節上的問題而使產品推向市場受阻。
就比如：平時我們購買一個商品，有一些小瑕疵都會放棄購買進而去選擇別的同類商品。所以在合適階段，toB產品也得注重用戶體驗，尤其是要讓產品有一致的良好用戶體驗。
想要更好地理解目標，可以看看《互動設計精髓》相關部分。
《互動設計精髓》中將目標劃分為用戶目標與非用戶目標，用戶目標是用戶的動機，成功的產品首先要滿足用戶目標，但是也必須承認並考慮以及解決非用戶目標。而《用戶體驗要素》中所闡述的戰略層包含的產品目標與用戶需求（用戶目標），結合理解會更深刻也會對工作有更足夠的指導。
to B產品也是可以運用目標導向這一工具的，在版本迭代規劃中，在時間這個維度上優先實現哪個目標就得結合產品以及公司具體情況具體分析，同時要堅持用發展的眼光看待問題。
一個toB產品有本身的發展邏輯，而將其放在具體環境中發展時，就得採取對應策略來保護、推進這個產品的發展，使其實現目標。
迭代規劃中的價值如何去衡量，可能談論最多的就是迭代了這部分內容，哪個回報更大。有沒有一成套的方法，本人也想知道哈。
這一部分涉及到的內容也屬於商業計劃書的內容，有的公司並沒有一個完整的文檔來記錄或者還沒有考慮清楚。無論這部分內容清楚與否，如果產品的核心功能已被市場驗證是對的，在迭代階段同樣得思考並完善這些內容，並依據圍繞這些內容來開展迭代工作。
心裡對迭代規劃有了底，接下來就得執行迭代工作也是產品經常接觸的工作——需求管理工作。
從產品經理視角，本人將需求管理細分為挖掘、管理、分析、確認、執行、跟蹤、完善需求7個小步驟。
工作中往往多個需求穿插進行，此種情況下這7個步驟是穿插甚至並行進行的。重點是分析需求與執行需求階段，個人覺得這是核心。
圍繞該產品的用戶目標與非用戶目標去挖掘，用戶目標就是用戶的動機，用戶想要什麼樣的感覺，用戶想做什麼，用戶想要成為什麼樣的人，這個產品如何一步一步做才可以一一解決這些問題進而達到一個一個目標。
有各種目標的存在，團隊的其他成員也有義務挖掘需求，身為產品經理就會接收到來自他人的需求。
需求就會有主動挖掘和被動接收（別人挖掘），這樣需求的來源大體有：競品、客戶、用戶、戰略規劃、數據、二手資料。這樣來自客戶的需求就一堆，來自用戶的也有一堆，來自競品的也不少。
比如，條件不允許時，且目標用戶的屬性背景與辦公一族有相似時，往往會讓內部人員甚至團隊開發成員模擬目標用戶去體驗產品，然後提需求。專業一點會運用可用性測試，用戶體驗地圖、任務路徑分析、十秒測試法、視覺評估等方法來挖掘需求。非專業提需求與專業提需求，其實都沒有離開用戶體驗5要素的範圍。所以將戰略層、範圍層、結構層、框架層、表現層作為指導方向再結合具體方法去挖掘需求的，在迭代階段挖掘需求會更明晰。
面對海量的需求，為了方便查找以及追本溯源，而且有的需求被挖掘出來後一時半會是無法判定是否或者什麼時候排上日程的，這樣把每個需求涉及到的關鍵屬性信息記錄清楚就方便後面的工作。
具體方法有比如需求池。需求池裡面該記錄哪些信息可以根據具體的產品來定。經過簡單評估的需求就會進入需求池，要將其拿去設計開發上線就還得經過分析確認更嚴謹的評估。
分析需求的目的幾乎是確認該需求是否值得投入到設計開發中去，也是分析該需求是否有價值；5W1H、6W2H分析法等等，如果能運用到位，在需求這個大事情身上就會輕鬆很多，減少考慮不周、反覆修改的情況。
等方面提出問題進行思考。
利用以上其中6個方面的關鍵信息可以進行場景還原，再判定：
經過以上分析，大體能判定該需求的價值。說到價值，價值鏈基本理論中說到真正創造價值的是價值鏈的「戰略環節」，但是只有完成了價值鏈中的最後一個環節，這個產品或服務才是完整的。
產品的價值也是由一些能滿足核心需求的核心功能創造的，但是有的需求不做這個產品就不完整甚至不能很好地跑起來，就不能實現該產品的「大一統」。
在產品需求分析上，有的需求可能真分析不出什麼價值，但是要是是產品不可缺的一部分，是不能輕易就不要的。如果還猶豫不決，也可以運用逆向思維來分析，不做該需求會對產品造成什麼影響。
在迭代階段，分析需求還有以下三點該注意：
在分析需求過程中，可能why這個是相對較難的，這可以參考《精益創業》中提到「五個為什麼」，經過五個或者兩三個為什麼的追問，往往能夠找到更深層的原因，看到問題的本質。
比如，為什麼用戶反饋登錄頁面太煩了？（1、因為只支持用戶名登錄，2、因為用戶容易忘記用戶名）原因可能有括號裡面的兩點，然後分別對這兩點展開追問。
（針對第1點的追問）
（針對第2點的追問）
經過一番的追問，往往就看到了問題的本質。
實際上分析需求的過程在挖掘需求時就應該有過粗略的分析了，甚至也有很細的分析才將需求提出來的，而那些經常提需求需求幾乎不通過的情況應該是沒有經過深入的分析就把需求提出來了。
（Ps：n個W +n個H這些分析法，可以靈活運用）
有了分析方法，可是分析到何種程度會最佳，這應該是取決於對需求的認知程度，認知的成熟度往往取決於能接觸到的信息的廣度和深度。所以加油吧……
分析需求之後，是否要去做該需求以及大體如何做，就得做出決策，這是需要團隊成員以及領導確認的，尤其對於重大一點且比較猶豫不決的需求。如果想要做出正確的決策，除了分析需求的工作要做到位之外，也可以參考《決策與判斷》以及《卓有成效的管理者》中提到的決策5要素，這樣也許可以更深層次地理解決策進而對快速地做決策有一點幫助。
在這一階段，需要將功能需求定義清楚，輸出原型文檔，原型文檔評審，原型文檔交付ui設計師和開發同事。
需求確認要做之後，就得描述清楚通過什麼辦法來滿足該需求，也就是功能需求定義階段，定義好流程、邏輯規則、功能規則、入口，對於b端複雜產品，邏輯規則特別重要，有的也真的特別複雜，很燒腦。
輸出文字描述版本，將文字版本找技術負責人員交流一下（本身對技術很了解就略過），在分析需求以及確認需求階段都是一些比較大體的東西，在執行階段就得做得很細可能會出現一些之前沒有考慮過的東西；所以在輸出功能需求定義文字版本後，最好交流確認一下有疑問的點以免後期反覆修改，沒有很嚴重的疑問後，可以進入畫原型階段了。
進行功能需求定義時，容易出現的問題是考慮不全，甚至沒有實現這個功能的邏輯閉環，以及對於邊界條件定義得不合適。在分析需求的時候就已經在運用wh分析法，一般是大體的分析，在進行功能需求定義時，也同樣可以運用wh分析法，要深入，就可以實現一個功能的邏輯閉環。
以下是大體步驟：
原型畫完成後預約時間就可以進入原型評審階段了。在評審前能對一個功能做較全面的定義以及評估，就不至於在評審時被各方提出的一些問題問得啞口無言。所以儘量形成一個系統的視角層層深入去分析並思考對應的解決方法，這樣評審也不會太難看。
評審結束後，一般情況下還是要修改一些地方，最好對評審會議做一個記錄讓主要負責人員都確認一下，然後提交原型給ui以及開發同事。
產品提交原型後算是完成一個需求任務，但是還有任務就是要去跟蹤ui設計、開發，及時拿到反饋進而溝通，開發基本完成後要去驗收，等待測試上線。
這些按照路程走，前面工作做到位，是不會有太大問題的；若出現了問題，5why分析，哈哈哈~
上線之後，還有注意對客戶、用戶反饋信息的跟蹤，留意分析各種數據。
需求總是源源不斷的，那就想方設法去完善。
以上是個人的總結，可能還有不全面不到位的地方，歡迎交流。
作者：粉紅心森林少女，一枚產品。
本文由 @粉紅心森林少女 原創發布於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基於 CC0 協議