產品經理的工作中總不乏各種各樣的問題需要解決，能夠立體化、系統化地解決問題是身為產品人必須具備的能力。
產品經理的工作是什麼？我認為歸根結底就是解決各種問題。
產品經理要定義一個產品，定義產品的關鍵就是定義產品價值，產品的核心價值就是解決用的問題，沒有價值的產品再優秀的研發團隊都是徒勞的。
除了定義產品，產品經理還需要管理產品，甚至關注產品運營，這一切的工作本質上都可以抽象為一個問題，開一次產品需求評審會是要解決這份產品需求能否達標的問題，寫一個產品立項書是為了解決產品研發能否有資源的問題，定義團隊章程，協調成員溝通都是為了解決產品團隊的問題，所以說產品經理的工作就是解決問題一點都不為過。
那麼問題來了，到底什麼是問題呢? 問題本質上就是期望和現狀的差異，因為差異產生痛苦，因而產生問題。
為了更加全面的理解問題，我想從三個方面去論述，讓你對問題的理解更加立體化、系統化。
一、定義問題
問題分類的維度很多，按照二元論，我認為問題分為兩種，一種是看起來是問題的問題，一種是看起來不是問題的問題。
先來第一種，看起來是問題，比如你做產品測試時發現不滿足需求，交互界面易用性不好，產品開發進度未按照預期完成，這些都是第一種問題，一看就是個問題。
還有一類問題看起來不是問題，比如你的上司讓你寫個產品方案，他要給老闆彙報，用戶調研需要寫一個調研提綱，這些看起來更像是個任務，這任務本質也都是為了解決一個問題，你接到老闆讓你方案的任務，實際上是為了解決你的上司如何給老闆彙報的問題，本質上是要解決你的主管領導對於這個產品的認知問題。
問題分類清楚了，接下來要有能力分辨這個問題對我來說到底是不是個真正的問題，聽起來有點拗口，我舉個例子，一個需求人員過來跟我說，研發未完全按照原型設計進行開發，我看了下，研發因為前端技術所限對界面有微小調整，不影響大局，總體來看這個調整是OK的，對我來說這就不是個問題，可對需求人員覺得是個問題。
再舉個例子，一個技術架構組的的重要人員要離職了，這看起來對我而言不是個問題，可實際我們的產品的用到了他開發的技術組件，他的離職很可能會造成我負責產品的進度延遲，這對我來說就變成了一個問題。
所以辨別是否是一個真問題的關鍵，就要看這個問題對我來說到底是不是個問題。
確定了問題，我們再來看如何準確的描述問題，先看下面的例子：
這個PPT寫得太差不合格，聽起來這確實是個問題，但你還是不知道到底問題在哪?是PPT的佈局不夠美觀？還是邏輯結構不夠嚴謹?所以正確的說法是你的這個PPT篇幅太長，要表達的觀點不變，精簡到10頁就可以了。
看到沒，描述問題的關鍵就是現狀和目標，這兩個點說清楚了，問題就描述清楚了。
二、分析問題
分析問題要關注三個方面，問題出現的頻率、問題的關聯性、問題的因果關係。
先看問題的頻率。在ITTL規範裡有事件和問題的概念，假如一個信息化系統發生了故障，在最短的時間內解決故障，恢復服務這叫事件，如果這個故障反覆出現，一個月出現了好幾次，那就要重點關注，把這些重複出現的偶然事件就會定義為問題，技術專家要想辦法給出徹底的解決辦法，解決這個問題。所以分析問題的頻率很關鍵，不同的頻率解決方案也會不同。
再看問題的關聯性，如果我們的信息化系統需要升級一個底層組件，解決一個安全漏洞，看似很簡單，可是真的升級了就解決問題了，他是否會引發新的問題，當前的安全問題是解決了，可是因為有個功能模塊只能適配這個最組件的舊版本，新版本升級了馬上新問題出現了。
最後就是問題的因果關係，我們要學會尋根溯源，打破砂鍋問到底，像剝洋蔥一樣，層層把這個問題分解，透過問題的表面看本質，只有這樣才能根本上的解決問題。
我舉個實際的例子，我有個同事給客戶演示系統，結果演示的效果不好，用戶不太滿意，後來我們覆盤這件事，發現了以下子問題。
演示地點是客戶的辦公室，那一次的辦公室沒有外網環境，這個事先沒有調研清楚，到了現場才發現，只能臨時用的手機熱點聯網，系統的速度顯得比較慢。
另外演示的投影儀連接電腦有些問題，搗鼓了幾分鐘才開始正式演示，這給用戶留下了壞印象。
演示的過程中出現了一次系統bug，而這個bug的出現是演示的準備不足造成，研發知道有這麼個問題，只是暫時來不及解決，如果提前準備充分，這小功能根本不會主動點開。
所以這些問題的疊加最終造成了一次失敗的系統演示。
三、解決問題
只要思想不滑坡，辦法總比問題多，一切問題都是可以解決的。
先說一個點，解決問題一定要以自己擁有的資源為最基礎，否則得不償失，說白了就是看自己手裡有什麼牌，才好出招。
比如一個用戶提出一個系統需求，要真正的實現這個需求，我們現在的技術能力是不具備的，可能需要和別的廠商合作，或者需要付出大量的人力去做技術預研，成本都是非常高的，解決了用戶的問題但是項目賺不到錢，怎麼辦?
問題還是要解決，我們回到問題的定義，問題就是預期和現狀的差異，現狀無法改變，只能降低用戶期望了，通過成本較低的替代方案最終解決用戶的問題。
問題經過分解，出現了很多子任務，這些任務都完成了，問題才算真正的解決，如何排定這些任務的優先級，有兩個很關鍵的因素，一個是外部資源，如果這個任務需要其他人協助解決，這個人是不太可控的，所以這類任務優先級一定是最高的，另外一個就是依賴關係，通過任務的依賴關係明確哪些任務可以並行優先做。
最後問題的任務都分解完了，計劃也定了，也分配到具體負責人了，那是不是就萬事大吉坐等問題解決，顯然並不是這樣的，產品經理要全程追蹤問題的解決過程，有問題及時溝通協調。問題解決後還要驗證。
最近有個項目，我分配給一個現場的工程人員去部署附件服務，要實現多個節點的同步和負載均衡，他幹了一天和我說問題解決了，這比我預期的要快很多，然後我再問他你驗證了嗎？怎麼證明你部署成功了呢？他才曉得原來還有驗證這一步。所以未經驗證解決的問題，都不能算真的解決了。
這裡把角色放的更大一些，你除了是一個產品經理，在家裡你可能是一個父親、一個妻子，在一個讀書會你可能是一個讀書會的會員或是組織者，在醫院裡你是醫生的病人。我們每個角色所作的思考、決策、行為其實都是為了解決問題。
輔導孩子的功課是為解決孩子的成績問題，帶家人旅遊，是為了滿足精神上的釋放，甚至我們每天吃飯、睡覺都是為了解決身體本身的健康問題。
所有一切行為皆是問題，成為問題解決高手，會讓你的工作更加出色，生活更加幸福。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
