七步思考法，解決項目中的問題

獵雲網註：產品經理競爭力上的差別，很大的程度上取決於其能否發現問題和解決問題，也就是是否做正確的事和正確地做事，這才是體現思維能力和思維層次的地方。文章來源：人人都是產品經理（ID：woshipm），作者：霹靂。獵雲網經授權發布，轉載請聯繫人人都是產品經理授權。

互聯網行業發展的這些年，培育了一批又一批產品經理。

起初大家都統稱為「產品經理」，後來進一步分成了app產品經理、網頁產品經理、後端產品經理、桌面軟體產品經理。到了現在，分得就更細了，可以結合類型（如社交、遊戲、電商、金融），可結合模塊（如消息推送、支付、訂單等），也可以結合業務（招聘網站上常常出現XX業務產品經理）。

但是這些都是各個公司根據業務和發展的需求進行的區分，並不能體現出產品經理在能力上本質的差別。

甚至，很多所謂的高級產品經理和產品總監也名不副實——不過是在一家公司的一個崗位上的時間久而已，和同行優秀者相比並不具備競爭力。

那麼，產品經理的競爭力體現在什麼地方呢？

筆者私以為：產品經理競爭力上的差別，很大的程度上取決於其能否發現問題和解決問題，也就是是否做正確的事和正確地做事，這才是體現思維能力和思維層次的地方。

見過不少同行工作了多年還是不具備獨立思考的能力，對於做過的項目還能正常推進，但是一遇到不熟悉的項目就懵逼不知道怎麼入手。

筆者也經歷過這樣的階段，即使到現在也不能保證項目交到手裡、在沒有指導的情況下也能完成。

不過，在經歷過多次磨練後小有心得，形成了自己的方法論。

在此把它概括成七步：

面臨的問題是什麼（只能有一個）？

問題的背景是什麼，利益相關方有哪些？

導致問題出現的原因是什麼？

用什麼方法可以解決問題？

目前欠缺什麼資源和條件？

如何搞定資源？

怎樣進行任務排序，時間規劃如何？

以下結合案例來說明（純屬虛構）。

第一步：思考問題是什麼？

S是活動產品經理，主要對接用戶運營部門，跟進各類活動項目的需求-開發-上線，工作中涉及的系統有運營平台的活動管理模塊及app端的活動banner位。

時間是周五下午3點，S在wiki上寫完周報。雖然為了趕下周上線的排期，RD周六要來公司加班一天，自己作為負責任的PM也要來，但是最近項目進展還比較順利，心情大好。

這時上級T在內部通訊工具里@S讓她過去一趟。

T：老闆剛剛組織了一個電話會議，要求下周一上線一個預約活動，運營部門已經制定好活動規則，現在開始協調庫存。你出一個產品方案，找研發協調人力，明天加班趕一下，下周一晚上就上線。

相信多數PM都有經歷過類似的情況，如果S是菜鳥，可能不問三七二十一就按上級吩咐的做了，畢竟有這張免死金牌也能把項目推起來。

但是結果不一定盡如人意，在研發超負荷工作的上線關鍵階段，突然插進緊急的新需求，將使兩個項目的質量都受到影響。

如果S是老鳥，她可能會這樣思考：為什麼要做這個項目？

今天是周五，雖然老闆不靠譜（員工多少會有這種想法），但是現在人力超負荷的情況他是知道的。

而且開發中的項目也是一個大型活動，早就規劃好了，是不論如何都不能延期的，在這種情況下還有新增一個活動，是出於什麼考慮呢？

運營制定好活動規則一般會先同步給PM，為什麼這次跳過PM直接彙報到老闆那？運營方案才通過就開始協調庫存，這個節奏也不正常，是什麼原因需要做的這麼匆忙？

S：我們做這個項目要達到什麼目的和目標呢？

T：老闆聽說對手Q想要做一個與我們對標的活動，而且有可能先於我們上線，所以緊急批了預算並且找運營新加了預約的活動，目的是狙擊對手和給大型活動預熱，並沒有具體的目標。

到這裡，情況相對比較清晰了，S分析目前的情況：

有一個高優先順序的項目緊急插入；

（不用協調也知道）RD資源不足，可能會顧此失彼；

以現在的資源情況，不能完全開發好活動並且按時上線。

1是問題嗎？

第一感覺好像是，但是類似情況到處都有，而且沒有說明危害性如何，所以這只是問題的表象。

2呢，資源不足是問題嗎？

有道理，但是在互聯網公司資源不足是常態，沒見哪家公司因為這個原因掛掉的。

3才是問題！在項目管理里，時間、質量、成本是「不可能三角」，強行提高其中一個指標都會對其餘兩個指標造成影響。

現在的情況是要在短時間內以有限的資源完成項目，那麼只能犧牲一部分質量。

這樣問題就明確了。

第二步：分析背景和利益相關方

外部背景：

Q是公司的死對頭，在過去幾個月一直打得不分上下，一方有動靜另一方馬上跟進。現在S的公司稍佔上風，目前集中全公司的力量都在設法保證優勢能持續下去。

內部背景：

大家連續幾個星期周六加班，已經有些疲憊，而且早就安排了研發任務，也不可能抽調更多人力投入新任務。

利益相關：

老闆和上級自不用說，這個項目必須要能在他們預期的時間上線；運營方面需要儘快去了解他們的活動規則是什麼，這樣才能出方案；

研發方面，研發leader已經知道情況，表示後端人力都在項目上，前端有一個人力可以支持；既然做活動，肯定需要UI的支持，雖然她們在項目上，但是調整一下優先順序是OK的。

第三步：分析產生問題的原因

這一點上面已經說過，是因為時間和資源沒有什麼調整空間，但是還要盡量保證質量。

第四步：用演繹法列舉出所有可能的解決辦法

用歸納法得出每個解決辦法的優點和缺點。

我們假設S有這三種選擇，而且很清楚地知道每個方案的優缺點。

實際上，任何一個方案都可能是個好方案，也可能是個錯誤，關鍵是需要根據實際的情況進行拿捏，選擇投入小收益大的方案，這裡所說的收益不單是短期的收益而且還是長期的，不單是個人的收益而且是所有利益相關方的。

比如：S可以狐假虎威、威逼利誘讓RD同學加班完成項目，但是這種方案不能常用，特別是這樣做對公司沒有帶來什麼好處的時候，因為這既傷害了長期利益也傷害的別人的利益。

第五步：分析現在還欠缺的資源和條件

假設S和上司、老闆、運營都溝通完畢，確定了選擇第三套方案。現在S需要需求文檔、前端、UI、QA資源，還需要使用公司統一的外部表單賬號，所有這些到現在為止都沒有確定。

第六步：搞定欠缺的資源

需求文檔S自己寫就行，因為是項目組的組織形式，所以前端、UI、QA都掛在一個leader下面，而且他已經得到了新項目的消息，S和這個leader溝通一下方案即可。

表單工具的賬號還未註冊，而註冊表單賬號需要使用公司的對外郵箱，郵箱由項目組內的一位同事負責。

第七步：要做的事情清楚了

S羅列出先後順序（創業公司的節奏）。

這樣整個方案就出來了，之後按照計劃執行即可。

很多情況下，當PM對配合的團隊和流程熟悉後，對於簡單的項目，在無意識中就可以完成思考。

但是對於複雜的情況，特別是涉及面廣、牽扯的團隊多、項目流程長、不可控因素多的時候，是很有必要進行方案拆解的。

拆解的能力非常考驗PM的功力，也是很多招聘者在面試中喜歡考的問題。

而且不止於此，在日常生活中，如果好好培養和運用這一能力，很多問題將迎刃而解，生活效率也將得到提高，這裡就不具體舉例了，讀者感興趣的話可以試試。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！