產品經理作為互聯網中的“撕逼工作者”“需求溝通者”，每天都被大量事務、大量細枝末節包圍著，而這些事務也容易產生大量棘手、難解決的問題，那麼學會“影響分析思維”後，將有效幫助我們從根源解決問題。

01 一些常見的問題

作為互聯網產品經理，是否遇到過以下的場景：

1. 需求文檔寫完了，但是交互設計師的給出的方案和自己想的並不一樣、設計師的畫風跟自己的腦海裡的完全不一樣。
2. PRD和交互原型都輸出了，但在技術評審過程中，程序猿說“這個實現不了”，又或者評了一個超長的時間，然後項目經理說要不還是砍砍需求吧。
3. 新功能完成了開發，但是到測試的時候，測試的同事或者產品經理自己無意間發現，咦，新功能沒問題，怎麼一些老舊的功能突然報錯了？找技術溝通之後發現，原來是那些老舊功能也用了同一個板塊，沒考慮到。結果只能加班加點修復，甚至延遲發版。
4. 新功能上線後，運營反饋說用戶投訴驟然增多，一調研發現，原來是新功能打斷了用戶原來熟悉的必須流程，或者新的字段加重了用戶的工作量，又或者新的功能增加了誤操作的概率等。
5. 新功能上線後，從用戶訪問量看，儘管運營已經很盡力的推廣了，但是新功能的使用量還是很低。

今天我們嘗試用一個新的角度去審視、解決上述問題。

02 影響分析

有一種設計方法叫做FMEA，Failure Mode and Effects Analysis 失敗模式和影響分析，FMEA於20世紀50年代於美國被提出，多用於工業系統設計製造的過程。

FMEA用於在產品設計階段和過程設計階段，對構成產品的子系統、零件，對構成過程的各個工序逐一進行分析，找出所有潛在的失效模式，並分析其可能的後果，從而預先採取必要的措施，以提高產品的質量和可靠性的一種系統化的活動。

FMEA有專業的軟件為那些大型工業製造商去實施，我們這裡就簡單講一下其流程：

1. 整理流程圖
2. 明確流程每個節點的要求
3. 針對每個節點找出可能發生的不良模式及發生原因
4. 對每個節點存在的缺陷進行風險評估
5. 對嚴重的問題進行解決
6. 實施改善後的流程

FMEA用的評估方法叫做PRN，Risk Priority Number，風險優先數/級。主要從以下三個方面對影響進行評估。

PRN=S x O x D

• Severity 嚴重程度
• Occurrence 發生概率
• Detection 可發現性/發現難度/不可偵測性

以下我們將會用FMEA的思維去評估一個新功能上線的流程，但是我們側重點是找出容易產生的影響，並在工作過程中儘可能的避免，而不是遇到了問題後如何去解決。

03 工作流程

上圖是一個經典的互聯網產品產生的流程圖，從一個idea的產生到落地的循環生態。

對於產品經理而言，他們是整個流程的出發點，一個需求經過了交互設計師、視覺設計師、技術開發、測試、運營，最後面向用戶。

用一個不太合適的形容詞，就是“你比劃我來猜接龍”的過程，最初的想法和用戶最終看到的效果，可能會有一定的的差異，而這過程中，一些潛在的問題就顯現、放大，甚至產生不好的影響。

我們將針對每個節點，我們都提前找出可能的影響，比嘗試找出規避或解決影響的方案。

3.1 交互與視覺設計

在功能需求的設計過程中，產品經理應當去思考，功能的操作流程、呈現效果，是否與當前產品的定位、體驗一致，而不是把這個問題完全拋給設計師的去解決。

例如我們的產品定位是簡單，用戶無腦刷就得了，但是某個新功能為了檢測用戶忠誠度，需要用戶在手機上完成一個很複雜的流程或動作，然後能獲得對應的獎勵。

這個複雜的流程可能在你的表達傳達給交互設計師時，就會有一定的偏差，等到交互設計師為了統一整個產品的交互邏輯，完成方案時，效果又會產生一層偏差，先不談這個結果是不是用戶想要的，至少很可能這個結果並不是你想要的。

再例如，需求文檔中欠缺對視覺效果的要求，最後設計師出的圖，可能完全不是產品經理想要的，相信這種事情大家應該見多了。

面對這種情況，在寫PRD的時候不妨多附上一些理想的同類產品的界面圖片、並多視圖描述一下視覺風格傾向，就能把這種偏差減少。

3.2 研發測試

產品：“我想要一個根據手機殼變手機主題顏色的APP

技術：“實現不了”

產品：“怎麼實現我不管，明天就要上線”

於是技術就把產品打了……

這並不是一個“空穴來風”的事情，但是與技術撕逼，可能是產品經理工作中除了寫PRD第二重要的事情了。

瞭解一個功能是如何實現的，在產品經理眼裡和在技術大大們眼裡，可能並不是一回事。

就如上圖所示，一個產品，在產品經理眼裡，整個系統被安排得穩穩妥妥、明明白白。但是在技術眼裡，你甚至可能找不到那些技術上的接口，和產品經理眼裡的功能的關聯。

對於產品經理看來的好幾個功能點及好多個端的區別，有可能在技術層面上是同一個接口處理、同一個數據表保存、只是用不同字段及狀態進行區分展示而已。

於是乎由於產品架構與技術架構的不一致，就容易引發最經典的三個案例：

1. 產品：“明明有類似的功能，為什麼不能複用？”，技術：“功能看似相似，但是寫在不同的項目中，且底層讀的表也不同，差異巨大，還不如重新寫一個。”
2. 產品：“這個看著很容易啊，為什麼實現不了”，技術：“是看著容易，但是現在用的底層技術框架並不帶有這樣的功能/不是為這類需求設計的，所以沒法實現。”
3. 產品：“為什麼一個新功能優化，老是導致原有其他的功能出bug？”，技術：“你PRD也沒寫這個功能在別處也用到了啊！”

以上種種問題很容易影響開發進度，也容易導致在開發過程中需求被迫修改、甚至砍掉。想要避免這些問題，方法也很簡單：

1-2：多提前溝通交流，瞭解一些關於自家產品的技術結構和實現方式。這裡其實並不需要產品經理懂得怎麼看代表，技術架構的東西一樣可以用流程圖、系統藍圖等，大家都看得明白的方式來表達。

3：在寫PRD時，回顧一下產品中其他功能，是否還有其他功能依賴著本功能，或者其他位置會跳到此版塊，又或者是否有其他產品、供應商也對接了此功能，舊版本是否兼容此功能等。把這些依賴關係都梳理出來，能讓技術大大們更好的進行影響分析和兼容性設計，從而潛在的問題。

例如我們要給商品加個“品牌”字段，那麼商品都會在哪些界面顯示出來、商家又都能在哪些終端、通過哪些方式創建商品，平臺後臺又有多少個查看商品信息的地方，是否有對接的供應商需要有在獲取商品信息。

果我們漏了其中任何一點，很可能這個新增的“無關”字段，就會導致一部分商家創建商品的時候報錯、又或者運營在後臺某個位置選擇商品時，發現商品名稱都變成了品牌名稱等等。

我其實寫了挺多篇關於產品經理要懂點技術的文章，類似的技術科普文不少，大家有興趣可以自行百度。

3.3 產品上線

假如一個APP上原生的功能需要更新，那麼iOS需要提交給蘋果的應用商店審核、安卓需要提交給騰訊應用寶/360/小米/華為/百度等應用商店審核。微信小程序功能要更新，也需要提交給微信進行審核。只有審核通過後，用戶通過公開的途徑才能下載使用最新的版本。

不知道是否有產品經理遇到過這樣的問題，測試或技術的同事將應用提交審核後，過了幾個小時或者一兩天，反饋回來卻說，審核失敗了，對方需要提交XXXX資格證、XXXX執照，於是就從產品經理問運營，運營問財務法務，財務法務問老闆……最後發現公司確實沒有這個資質，最後一整個月的功勞都白費了。

還有一種情況，就是應用申請上架後，被駁回的理由是裡面使用了一些對應平臺不允許使用的技術，或者不符合對應平臺的規範。於是技術或測試又來找產品，然後產品就跟領導溝通，找技術、項目重新評估時間，重新開發……

這種影響其實在產品設計的最初階段就應該避免，這裡建議產品經理們閱讀並熟悉以下內容：

1. 微信小程序運營指南，可能是全世界要求與限制最多的平臺之一：https://developers.weixin.qq.com/miniprogram/product

2. 蘋果應用原則與規範，根據蘋果官方數據，蘋果應用商店拒絕的比例達40%：https://developer.apple.com/cn/app-store/review/guidelines/

3. 百度應用商家審核規範，雖然百度應用商店用戶量不多，但是從我的經驗來看，要求算是安卓市場裡面最嚴的：http://app.baidu.com/docs?id=18&frompos=401009

4. 閱讀並熟悉你所在行業的法律法規，例如我國對金融、網約車、醫療器械等行業是有明確的政策要求的。

5. 認同一個常識問題，別人的地盤別人做主：

在微信的公眾號、小程序文檔裡都不會寫，微信裡是不能用支付寶的（雖然反之支付寶裡也不能用微信），微信裡也打不開淘寶、拼多多、抖音、今日頭條，甚至某天也會屏蔽你家的APP。 不過不要因此道德綁架微信，那是人家的地盤，你要有本事也可以不用微信聯登、微信、持微信支付、不開微信公眾號、不開微信小程序的嘛：）

3.4 運營落地

運營落地的影響分為兩部分：

1）運營影響

產品對於運營的影響非常大，畢竟運營只能根據有的功能進行宣傳推廣，巧婦難為無米之炊。一個產品在設計之初，建議跟運營的同事先聊一下，看看競品是否有類似的推廣經驗，是否需要供應商進行配合提供對應商品或服務等，讓運營同事有提前準備，包括宣傳預熱等。

若是等到產品上線後，才讓運營開始著手準備推廣，可能會產生預算經費不足、配套商品或禮品沒準備沒到位、由於沒有前期宣傳導致用戶一臉茫然等後果。

2）用戶體驗

產品設計的初衷，其實想給用戶帶來更好的體驗。但是由於用戶並不只用你一家的產品，而是生活在一個信息爆炸的時代，被很多的主流勢力、還有你家產品原有的功能等培養出了一套“用戶預期”，在用戶眼裡，可能你的產品就應該是怎麼樣的，如果新功能並沒有考慮這個問題，可能不僅不能提高用戶體驗，還會導致用戶出現操作障礙，降低用戶轉換率。

所以在設計需求的過程中，必須考慮功能是否符合“用戶預期”，如果一個功能確實很創新、獨到，那就應該考慮增加一些用戶操作指引等。如果新功能不得不打斷原有的流程，那就應該注意讓這個變化更平滑過渡，而不是突兀的改變。

總的來說就是：運營要準備、用戶要引導。

3.5 項目管理

有些公司可能產品經理自身就要兼任項目經理的職責，對項目進度，尤其是開發進度，還有需要配合的資源進行溝通。

1）時間

需求設計的過程中需要預估設計、開發、上線的大致時間。版本迭代的週期過於頻繁或滯後會對用戶造成不同的影響。

多參加設計、技術評審會，積累經驗瞭解一個功能設計、研發、測試的週期，將有助於產品經理更好的進行版本規劃，讓用戶感知以一個平穩的步伐在進行產品更新，不頻繁更新擾民，也不會堆積了一堆問題、風格陳舊很久才處理一次。

另外應用市場、微信小程序等上線審核是需要時間的，幾個小時到幾天不等。而且逢年過節的時候，國內外應用市場的審核人員也會放假的。這就對於有緊急發版、重大節日前後發版需求的產品來說，必須提前瞭解對應應用市場的時間安排，然後與項目同事一起反推定好好研發deadline。

2）依賴資源

對於有些功能而言，例如查詢快遞、喚起支付寶/微信/銀聯支付、微信/QQ聯合登錄、利用地圖展示某些信息等，都是需要供應商配合對接才能完成的。如需設計對應功能，應事先與項目經理、商務等同事溝通，瞭解對方是否要籤合同和付費、獲得對方的開發者賬號、開發文檔等內容，為進一步技術對接做好準備。

如有能力的話儘可能閱讀一下供應商的開發文檔，瞭解功能是否與我方需求匹配，是否存在一些限制可能會影響未來功能的發展等。

3）對外部系統的影響

如果你的產品是面向商家端或工廠端的，那麼有商家來對接是很常見的事情。他們自有的系統通過我方接口獲取一些信息，我方新的功能調整是否需要他們同步更新，如果需要也要對方提前做好對接工作，預防我方上線後對方系統無法工作等。

四、總結

其實產品經理的工作與交互、視覺、研發與測試、運營、項目他們的工作都息息相關，大家的工作是圍繞著“產品落地”在轉，從一個idea冒出，到最終產品呈現在用戶眼前，不僅僅是公司內部的事情，還與應用市場的規範、相關法規政策、依賴資源供應商、依賴著自己的外部系統等都有關係。

影響分析的最大用處，就是理性對待產品落地過程中各個節點，找出可能存在的問題，並在最開始設計需求的時候，就該規避的規避、該提前準備的進行準備，避免一個需求最後陷入無法實現、落地的僵局中。所謂“磨刀不誤砍柴工”。

影響分析讓產品需求的設計，由“我不要你以為，我要我以為”，變成“不打無準備之仗”，也只有這樣，才能讓一個團隊更好的工作下去，不斷推出對用戶和市場有利的好功能、好產品。

本文由 @iCheer 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

閱讀更多 人人都是產品經理 的文章

關鍵字: 軟件 美好，一直在身邊 設計師