To B 產品的迭代工作總結

本文作者對To B 產品的迭代工作進行了總結，主要分為兩部分，一是形成迭代規劃個人總結的思路；二是執行迭代工作的執行步驟。enjoy~

有機會負責過大型 to B 系統軟體產品迭代設計工作，是物聯網行業產品，該系統產品由終端、PC web端、手機app端組成，可以通過pc web端系統或者手機app來控制終端。增加或者減少一個功能，往往會有牽一髮而動全身的感覺，同時接手時幾乎是沒有任何規範的文檔來記錄背景信息的。（沒有那就一邊開展迭代工作一邊建立對應的規範，然後不斷修改補充。）以下就是一點總結。

產品在開展迭代工作前，得去理解這個產品是如何從0到目前階段的。

方法有：

• 寫產品體驗分析報告；
• 帶著分析報告中遇到的疑問，充分利用公司的資源去了解該產品的相關背景來尋找答案，可以向團隊成員甚至向市場人員、客戶了解，同時也要快速了解這個產品所在的行業涉及到的相關專業知識。比如在系統軟體上看到並不熟悉的專業文案，那不一定是會造成誤解，有可能在行業裡面就是那樣稱呼的，不了解的話還容易鬧笑話。
• 如果想要了解的信息，無法從別人那裡獲取那就只能依據自己的專業能力來判定了。比如從別人那無法得知目前產品所處階段、所在市場、生態形式、目標用戶、驅動力，那可以通過綜合能了解到的信息做出判定。

當對產品有了一定的了解后，就去形成一個迭代規劃，然後執行迭代工作。

Part 1 迭代規劃的思路

to B 產品，一般的商業邏輯是通過向客戶售賣硬體以及配套軟體授權來賺取回報。而當一個toB產品充當一個組織想進入並壟斷某個行業的切入點的角色時，該產品在迭代規劃時所要考慮的維度可能就會更多。

比如一個誕生在一家初創物聯網公司的toB產品，該公司也有遠大目標，迭代計劃要考慮的包括可能還不限於以下維度：

• 該產品目前情況（自身情況，外界情況（競品、行業））
• 產品所處公司目前業務情況（公司所擁有的資源，可採用SWOT分析法）
• 公司目標（更高層級的商業目標）
• 產品目標與市場反饋、客戶目標與客戶反饋、用戶目標與用戶反饋
• 如何更好為另一產品做鋪墊（比如導流）

（可能還有疑問說版本規劃還得考慮團隊成員本身情況，執行迭代過程中確實需要考慮，但是產品版本規劃是不會停的只要這個產品想要發展下去。）

這些維度在實際迭代過程中是需要做出平衡與取捨以及排列優先順序的，如何取捨以及安排優先順序常用的衡量標準是由目標以及價值來決定，當然也會受到各種條件的制約，而且這些維度的狀態、衡量標準以及制約條件是隨著時間而動態變化的，在某些時間段內側重的維度也可能會不同。在版本規劃中還要注意把握時間的節奏點，可參考蘭徹斯特戰略中的市場佔有率原則，別在大家都有機會的情況下錯失時機，讓對手領先牢牢佔據了市場。基於這些維度的思考，大體梳理出適合該產品發展的大方向。在執行迭代規劃的過程中，不要偏離這個大方向。

比如公司要利用該產品達到的目標僅僅利用公司自身的業務發展可能比較漫長，通過與某一方面更有優勢的第三方合作（客戶需求的產生）可以有助於達到該目標，價值很大，那麼在迭代過程中就會插進來客戶的需求，在某一段時間內尤其注重去執行客戶的需求，把產品要達到的目標先暫時放一放。

而當要準備依靠產品自身去打開市場前，就會將迭代計劃集中在產品核心功能的優化上。to B 產品在產品的0到1階段，為了保證安全準確，也會先上核心功能，但是可能實際開發出來后用戶體驗還不是很好，在合適的時候迭代計劃就會注重打磨細節，畢竟toB產品注重穩定性、效率，尤其對於複雜型產品，如果不注意打磨細節認知負荷增大、操作負荷增大，用戶使用產品的效率就達不到好的效果了，產品整體價值也會被降低，何況toB產品的發展趨勢也是越來越注重產品的易用性好用性。尤其當產品推向市場的時候，外界評價產品的維度往往會由核心功能的價值轉變成細節上的問題而使產品推向市場受阻。就比如平時我們購買一個商品，有一些小瑕疵都會放棄購買進而去選擇別的同類商品。所以在合適階段，toB產品也得注重用戶體驗，尤其是要讓產品有一致的良好用戶體驗。

想要更好地理解目標，可以看看《交互設計精髓》相關部分。《交互設計精髓》中將目標劃分為用戶目標與非用戶目標，用戶目標是用戶的動機，成功的產品首先要滿足用戶目標，但是也必須承認並考慮以及解決非用戶目標。而《用戶體驗要素》中所闡述的戰略層包含的產品目標與用戶需求（用戶目標），結合理解會更深刻也會對工作有更足夠的指導。toB產品也是可以運用目標導向這一工具的，在版本迭代規劃中，在時間這個維度上優先實現哪個目標就得結合產品以及公司具體情況具體分析，同時要堅持用發展的眼光看待問題。一個toB產品有本身的發展邏輯，而將其放在具體環境中發展時，就得採取對應策略來保護、推進這個產品的發展，使其實現目標。

迭代規劃中的價值如何去衡量，可能談論最多的就是迭代了這部分內容，哪個回報更大。有沒有一成套的方法，本人也想知道哈。

這一部分涉及到的內容也屬於商業計劃書的內容，有的公司並沒有一個完整的文檔來記錄或者還沒有考慮清楚。無論這部分內容清楚與否，如果產品的核心功能已被市場驗證是對的，在迭代階段同樣得思考並完善這些內容，並依據圍繞這些內容來開展迭代工作。

Part 2 執行迭代工作

心裡對迭代規劃有了底，接下來就得執行迭代工作也是產品經常接觸的工作——需求管理工作。從產品經理視角，本人將需求管理細分為挖掘、管理、分析、確認、執行、跟蹤、完善需求7個小步驟。工作中往往多個需求穿插進行，此種情況下這7個步驟是穿插甚至并行進行的。重點是分析需求與執行需求階段，個人覺得這是核心。

1、挖掘需求

圍繞該產品的用戶目標與非用戶目標去挖掘，用戶目標就是用戶的動機，用戶想要什麼樣的感覺，用戶想做什麼，用戶想要成為什麼樣的人，這個產品如何一步一步做才可以一一解決這些問題進而達到一個一個目標。有各種目標的存在，團隊的其他成員也有義務挖掘需求，身為產品經理就會接收到來自他人的需求。需求就會有主動挖掘和被動接收（別人挖掘）。這樣需求的來源大體有：競品、客戶、用戶、戰略規劃、數據、二手資料。這樣來自客戶的需求就一堆，來自用戶的也有一堆，來自競品的也不少。

比如，條件不允許時，且目標用戶的屬性背景與辦公一族有相似時，往往會讓內部人員甚至團隊開發成員模擬目標用戶去體驗產品，然後提需求。專業一點會運用可用性測試，用戶體驗地圖、任務路徑分析、十秒測試法、視覺評估等方法來挖掘需求。非專業提需求與專業提需求，其實都沒有離開用戶體驗5要素的範圍。所以將戰略層、範圍層、結構層、框架層、表現層作為指導方向再結合具體方法去挖掘需求的，在迭代階段挖掘需求會更明晰。

2、管理需求

面對海量的需求，為了方便查找以及追本溯源，而且有的需求被挖掘出來后一時半會是無法判定是否或者什麼時候排上日程的，這樣把每個需求涉及到的關鍵屬性信息記錄清楚就方便後面的工作。

具體方法有比如需求池。需求池裡面該記錄哪些信息可以根據具體的產品來定。經過簡單評估的需求就會進入需求池，要將其拿去設計開發上線就還得經過分析確認更嚴謹的評估。

3、分析需求

分析需求的目的幾乎是確認該需求是否值得投入到設計開發中去，也是分析該需求是否有價值。5W1H、6W2H分析法等等，如果能運用到位，在需求這個大事情身上就會輕鬆很多，減少考慮不周、反覆修改的情況。

why（基於什麼動機）、what（大體描述什麼樣的）、who（用戶）、where（何地，該需求轉化到產品上時在哪兒）、when（什麼情況下）、how（怎麼做，涉及流程）、how many（有多少用戶會用）、how often、how much等方面提出問題進行思考。

利用以上其中6個方面的關鍵信息可以進行場景還原，再判定：

• 會有多少用戶會用；（how many）
• 頻率如何；（how often）
• 動機是否與馬斯洛需求層次理論或者人性的7宗罪相吻合，強烈程度；（why）
• 是否符合近期的迭代規劃，成本如何。（how much）

經過以上分析，大體能判定該需求的價值。說到價值，價值鏈基本理論中說到真正創造價值的是價值鏈的「戰略環節」，但是只有完成了價值鏈中的最後一個環節，這個產品或服務才是完整的。

產品的價值也是由一些能滿足核心需求的核心功能創造的，但是有的需求不做這個產品就不完整甚至不能很好地跑起來，就不能實現該產品的「大一統」。

在產品需求分析上，有的需求可能真分析不出什麼價值，但是要是是產品不可缺的一部分，是不能輕易就不要的。如果還猶豫不決，也可以運用逆向思維來分析，不做該需求會對產品造成什麼影響。

在迭代階段，分析需求還有以下三點該注意：

• 這個需求與產品這個系統的關係。在複雜尤其還有終端的產品，要去分析這個需求本身是獨立的還是對產品的某一部分造成干擾或者起到協助作用。造成干擾的話，解決方案所需要的成本會不會很大。
• 這個需求的落地環境如何，是否受阻，成本是否很大。
• 這個需求是否會被替代，這個需求比不比要替代的東西要好。

在分析需求過程中，可能why這個是相對較難的，這可以參考《精益創業》中提到「五個為什麼」，經過五個或者兩三個為什麼的追問，往往能夠找到更深層的原因，看到問題的本質。

比如，為什麼用戶反饋登錄頁面太煩了？（1、因為只支持用戶名登錄，2、因為用戶容易忘記用戶名）原因可能有括弧裡面的兩點，然後分別對這兩點展開追問。

（針對第1點的追問）

• 為什麼只支持用戶名登錄？（因為一開始沒有考慮到唯一性的問題，為了填補這個漏洞，轉而只支持用戶名登錄）
• 為什麼會出現上述漏洞的問題？（因為那段時間沒有專門的人負責考慮這方面的事情，匆匆忙忙就投入開發了）
• 為什麼沒有人負責？（因為原來負責的人離職后，還沒有招到人來，也沒有人去負責這些事情，導致容易出錯）

（針對第2點的追問）

• 為什麼用戶容易忘記？（因為用戶擁有的用戶名太多了，記不了那麼多）
• 為什麼記不了那麼多？（因為人的記憶一般適合記住7個片語，互聯網發達階段，一個人擁有的用戶名可以是各種各樣的）

經過一番的追問，往往就看到了問題的本質。

實際上分析需求的過程在挖掘需求時就應該有過粗略的分析了，甚至也有很細的分析才將需求提出來的，而那些經常提需求需求幾乎不通過的情況應該是沒有經過深入的分析就把需求提出來了。

（Ps：n個W +n個H這些分析法，可以靈活運用）

有了分析方法，可是分析到何種程度會最佳，這應該是取決於對需求的認知程度，認知的成熟度往往取決於能接觸到的信息的廣度和深度。所以加油吧……

4、確認需求（需求決策）

分析需求之後，是否要去做該需求以及大體如何做，就得做出決策，這是需要團隊成員以及領導確認的，尤其對於重大一點且比較猶豫不決的需求。如果想要做出正確的決策，除了分析需求的工作要做到位之外，也可以參考《決策與判斷》以及《卓有成效的管理者》中提到的決策5要素，這樣也許可以更深層次地理解決策進而對快速地做決策有一點幫助。

5、執行需求

在這一階段，需要將功能需求定義清楚，輸出原型文檔，原型文檔評審，原型文檔交付ui設計師和開發同事。

需求確認要做之後，就得描述清楚通過什麼辦法來滿足該需求，也就是功能需求定義階段，定義好流程、邏輯規則、功能規則、入口，對於b端複雜產品，邏輯規則特別重要，有的也真的特別複雜，很燒腦。輸出文字描述版本，將文字版本找技術負責人員交流一下（本身對技術很了解就略過），在分析需求以及確認需求階段都是一些比較大體的東西，在執行階段就得做得很細可能會出現一些之前沒有考慮過的東西，所以在輸出功能需求定義文字版本后，最好交流確認一下有疑問的點以免後期反覆修改，沒有很嚴重的疑問后，可以進入畫原型階段了。

進行功能需求定義時，容易出現的問題是考慮不全，甚至沒有實現這個功能的邏輯閉環，以及對於邊界條件定義得不合適。在分析需求的時候就已經在運用wh分析法，一般是大體的分析，在進行功能需求定義時，也同樣可以運用wh分析法，要深入，就可以實現一個功能的邏輯閉環。以下是大體步驟。

• 按照wh分析法，先找到相匹配的解決方案（分析需求時應該已經有了）；
• 思考如果用戶不按照所提供的方案的正常路徑去使用產品，會有哪些異常，也就是異常預估，每一個環節都可能出現異常。這可以從用戶、產品邏輯鏈條去分析每一個環節的異常，對於有些功能是可以一起分析的。
• 針對預估出來的每一個環節的異常，給出對應的解決方案。
• 從以上三點考慮對一個功能需求的定義就會比較全面，綜合信息並且再次思考需求本身以及從產品設計比較通用的原則尤其體驗一致性的原則、成本、公司資源等再去做評估，會減少後期的修改，然後從評估結果中考慮刪減以及排優先順序。（這個事情往往在評審的時候會進行）但是作為產品在評審前心裡最好有個底。

原型畫完成後預約時間就可以進入原型評審階段了。在評審前能對一個功能做較全面的定義以及評估，就不至於在評審時被各方提出的一些問題問得啞口無言。所以盡量形成一個系統的視角層層深入去分析並思考對應的解決方法，這樣評審也不會太難看。

評審結束后，一般情況下還是要修改一些地方，最好對評審會議做一個記錄讓主要負責人員都確認一下，然後提交原型給ui以及開發同事。

6、跟蹤需求

產品提交原型后算是完成一個需求任務，但是還有任務就是要去跟蹤ui設計、開發，及時拿到反饋進而溝通，開發基本完成後要去驗收，等待測試上線。這些按照路程走，前面工作做到位，是不會有太大問題的。若出現了問題，5why分析，哈哈哈~上線之後，還有注意對客戶、用戶反饋信息的跟蹤，留意分析各種數據。

7、完善需求

需求總是源源不斷的，那就想方設法去完善。

以上是個人的總結，可能還有不全面不到位的地方，歡迎交流。

作者：一篇森林，，一枚產品。

本文由 @一篇森林 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pexels，基於 CC0 協議