起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識初做產品時，請不要想當然認為可以一蹴而就
那些年我走過的彎路之——一蹴而就
很多產品經理平時工作都非常努力，但產出效率卻并不高，導致產品經理工作事倍功半，產出效率低的原因有很多，其中之一是完美主義，這一點在之前的文章《為什么說完美主義的產品理念背后有個天坑》中已經做過詳細的分析，今天再給大家分享另外一個影響產品經理工作效率的大敵：一蹴而就。
火山算不上一位聰明的產品經理，但的確是一名非常勤奮的產品經理。在創業公司那幾年，在公司里算是典型的勞模。記得當時我們CEO經常掛在嘴邊的一句話，要論敬業程度，在公司里如果說火山排名第二，沒人敢說第一。每當老板這么說起時，我內心都會泛起一絲隱隱地自豪感?，F在想想，自己當初做過的很多項目，其實都是處于事倍功半的狀態，投入了很多的時間和精力，但實際的產出效率并不高。接下來給大家分享一個真實的項目案例——一個我初做產品時曾經犯過的低級錯誤。
我們公司做的是一款基于商旅出行預定的企業商旅管理產品，差不多2年前，火山接到了這樣一個需求：
需求描述：為我們機票產品增加一個審批的功能，保證企業員工的每一次差旅出行都在經過領導審批之后再進行，讓公司的差旅支出更加可控。
審批，這是一個企業級的管理軟件中非常常見的一個功能，我們不妨先暫停一下，假設你是接到這個需求的產品經理，你將怎樣完成這個項目？
思考1分鐘，計時開始……
想必現在你已經有一個大概的思路，那么，火山是怎樣做這個項目的呢？這個需求其實在我剛開始接手產品的時候就一直在提，但是由于種種原因就一直沒做。在正式啟動項目之前，我跟我當時的領導簡單描述了一下我的想法：
審批有兩種做法，即：行前審批和出票審批，前者是出行前先生成一張審批單，審批通過之后再訂票；后者是在訂票的時候生成一張審批單，領導審批通過之后再出票……
如此云云之后，我給領導的建議是以“事前審批單”的方式來做這個審批項目。我的領導當時剛空降到我們公司，大約40來歲，是一個智商奇高同時也比較自負的人，有比較強的技術背景，但沒做過產品，之前從事的并不是這個行業，在大致在聽了我的思路之后，表示這個需求并不復雜，很簡單的，你按照你的想法去做就好了。
由于客戶、銷售、運營、老板各種場合提了很多次，大致的需求我也都了解，所以我也就沒再做需求調研，我直接按照事前審批單的方式上手開始做這個項目。先是花了2天的時間梳理業務流程，然后是花了差不多3個星期的時間畫網站原型，在這中間跟我們開發經理簡單溝通過一些技術方案。在包含了無數交互動畫的網站原型畫完之后，我還是覺得不夠出彩，為了在我的新領導面前表現一下，我又花了1個星期把詳細的PRD寫了出來，試圖一蹴而就，把交付給領導檢驗的項目成果做得更漂亮一點。
終于，一個月之后，到了給領導交付成果的時候了。我叫上了我的領導，召集業務需求方、開發經理一起，開始了第一輪需求評審。首先評審的內容是流程，我打開我的visio，開始講解我的流程：“當用戶選擇好一個航班，點擊“預定”的時候，系統按照用戶所選的行程，生成一張審批單……”
“審批怎么會是從預定是開始 “我話還沒說完，領導直接打斷我的話，說道：“審批應該該是從下單時開始才對呀！”
“沒有，我的做法不太一樣，您先聽我把話說完……” 我解釋道。
“你不用往下說了，你這種做法肯定是錯的！”我領導從座位上站起來，也不正眼看我，拍打著投在墻壁上的投影說。”審批怎么可能是從預定開始的呢，沒有這種做法……”
“我的做法跟您的想法不一樣！”做了一個月的項目，新領導連講完的機會都不給我，還在那么多人面前一通罵，讓我也有一點情緒激動?！澳懿荒芟嚷犖野言捳f完，不要一上來就劈頭蓋臉一通罵……”
“火山，你先別著急，我知道你的意思，你的意思是先做一個審批單，審批通過之后再走后續的預定的流程對吧？那種審批做起來可能比較麻煩一點，但是我們這次只需要做出票審批就可以了?！眳臉I務見氣氛不太對，一邊安撫我的情緒，一邊解釋道。
“在我印象中，審批應該也是從下單開始的?！卑胩鞗]有發言的CTO也發言了。
之后，也不知道是因為賭氣還是因為被大家說服，我慢慢放棄了爭辯，開始閉嘴聽大家的想法……不僅沒有得到新領導的認可，我也沒有得到老領導CTO甚至業務方的認可，對于這樣的結果，雖然從感情的角度來說，我的確很難接受，但是從理智的角度來說，我已經逐漸意識到：無論我的方案是否具備可行性，但毫無疑問的是，從一開始我的方向就已經錯了，我把自己狠狠地坑了一把，因為這個方向性的錯誤，導致我辛辛苦苦花了一個月時間做的整個項目方案都得推翻重做！
什么叫事倍功半？這就是活生生、血淋淋的例子！
為什么會有這樣的結果?火山在這個項目中犯了那些錯？我們不妨再稍作暫停，回想一下，在你的工作過程中是否也有過類似的經歷？我的這段可以作為反面教材的經歷對你是否有一些啟發？
思考1分鐘，計時開始……
火山復盤
這個項目做下來，其實火山犯了很多錯，例如沒有充分地溝通，缺少需求調研等，但如果做項目的方法得當，這些錯誤實際上都是可以在做項目的過程中得以修正的，但是我并沒有修正掉，因為我還犯了另外一個致命的錯誤——妄圖一蹴而就！
一開始，領導可能并沒有給出明確的方向，而我沒有跟領導尋求明確的指示，這可以說我在溝通上犯了明顯的錯誤。但是如果我沒有妄圖一蹴而就，在繪制完流程圖之后把流程圖給領導看一看，請示一下，領導可能在項目一開始就已經給我把問題點指出，那么，我后面花了一個月時間完成的產品方案，也就不必推翻重做了。即便流程沒有能夠第一時間確認，但是如果我在畫完原型圖時不妄圖一蹴而就，先跟領導請示一下，那么我就不用浪費那么多時間為一個錯誤的產品方案撰寫那么詳細的PRD文檔了。如果一開始就糾正了方向，由于做法更簡單，或許我的項目早都可以結項了。
現在再回過頭去看我剛開始做產品那段經歷，這樣的低級錯誤我似乎犯過不止一次。有時是因為希望希望能給人眼前一亮的感覺，也有時是因為想要偷懶而省去需求評審，還有時因為自認為簡單就不需要溝通，我時常都抱著這樣一種一蹴而就的做事方式，說到底無外乎是為了省一些中間環節的溝通時間，殊不知看似相仿的產品功能，產品設計的方式方法可能變化萬千，很多優秀產品都不是生來就在一個正確的軌道上的，而是在設計的過程中根據多方訊息和實際情況逐步修正而成的，也沒有哪個項目是產品經理可以一氣呵成而不需要任何調整的。正所謂與“欲速則不達”，為了省一點溝通的時間而采取一蹴而就的做事方式，往往適得其反，不但時間不會花得更少，反而可能會花2倍、3倍甚至更多的時間。
做得慢，我們還可以通過勤加練習提高工作效率，但是如果方向做錯了，做得越多也就意味著錯的越多，相應的返工的成本也就越高。沒有什么比推翻重來更影響產品經理工作效率的了。小項目可能影響不大，但是對于比較大的項目，因為如果一開始選擇的方向就錯了，那影響就難以估量了。所以，現在你明白為什么說一蹴而就是影響產品經理工作效率的大敵了吧。
那么，我們產品經理在做項目的過程當中，該如何避免出現類似的錯誤，把這種風險降到最低呢？作為一名在這方面給自己挖坑過大坑的過來人，我的建議是：遵循產品設計的必要流程。對于比較大的項目，除了前期充分的需求調研之外，在做項目的過程當中，在一些關鍵性地節點上，還需要與關鍵的需求負責人保持密切的溝通，要盡可能及早的發現并修正方向性的問題，具體的操作細節總結起來就是：
- 需求調研階段——深入調研并確定項目范圍
- 項目啟動階段——與業務需求方、技術負責人、關鍵領導人一起確認主體業務流程
- 產品設計階段——與業務方展開2-3輪需求評審，確定網站原型
- 提交開發階段——與開發、測試進行PRD評審，確認功能細節
創業公司大多主張快速響應，簡化流程乃至于沒有流程的。但是時間長了，團隊規模擴大了，做的項目多了，慢慢地我開始體會到流程的重要性了。
關于產品設計有哪些流程，特別是創業公司需要哪些必要的產品設計流程，我也是頗有心得的，關于這一點，我會在后續的推文中做專門的分享。感興趣的小伙伴可以關注我的微信公眾號”PM火山”的后續推文，敬請期待。
本文由 @火山?原創發布于人人都是產品經理。未經許可，禁止轉載。
?? 還是要保持每個環節和各方面的溝通
溝通幾乎可以算是產品經理日常工作中最重要都軟技能，沒有之一
我不明白，為什么是業務方提的需求，但你調研需求的時候不去找業務方呢？而且，評審的時候應該也是提出需求的業務方做評估吧？
由于客戶、銷售、運營、老板各種場合提了很多次，大致的需求我也都了解，所以我也就沒再做需求調研，我直接按照事前審批單的方式上手開始做這個項目。
評審的時候也有業務方在場的。