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