如何拯救讓我最痛的一個B端專案
痛苦
回憶這麼多年的IT生涯，能讓我想起的有三個最痛苦的時刻：
第一次是剛入IT坑，我還是一個傳說中的程式猿，我負責的系統是個生產系統，一天24小時都在用，經常到了晚上現場打電話過來，系統不能用了，我就馬上爬起來抓bug，改完bug，還要小心翼翼的把我們負責配置管理的小妹妹吵起來給我上線，那時候很痛苦，晚上總睡不好，可剛入IT行，總覺得這些苦都值得，吃了苦才能快速的成長，所以那個時候的苦叫做成長的苦。
第二次是從需求轉售前後，負責的的第一個售前專案，那個時候思維總是轉不過彎，做需求講究細緻的需求分析，要能落地，做售前更注重總結包裝，要能寫出高大上的方案，是否能真的落地卻並沒有那麼高的要求，能把標拿到才是硬道理，那個時候的苦叫做轉行的陣痛。
還有一次就是最近這幾年做了一個錯綜複雜的專案，這個專案我是產品負責人，現場有個專案經理，我幾乎用盡全力才把這個專案交付，現在每次遇到難做的專案，想想這個專案也就沒那麼痛苦了，所以我把這個專案痛苦指數定為五星，這種苦就是傳說中的痛中之痛。
如何拯救這最痛的專案，我總結為以下幾點：
一、方案能力拯救失望的使用者
剛接手這個專案實際上是一個半截子專案，前任專案和產品負責人沒有得到使用者認可，我是臨危受命，所以剛來的時候一臉懵逼，還沒來得及搞清楚情況，就沒銷售忽悠出差，第一次見使用者發現被銷售挖了個大坑。
在我來之前專案已經做了三分之一，剩下的專案需求，以銷售為首的本地團隊，為了把專案盤子做大，忽悠了一個很大的範圍，本想著引導使用者分期實施，沒想到使用者根本不和你談分期，就是要本期全部做完，反正都是你們自己挖的坑。
沒想到剛來就入坑了，而且坑裡還有水，水裡還有釘，銷售笑笑，坑邊還有肉呢，先把坑填了吧。
面對這種一開始就被挖大坑的情況，我剛開始的思路是縮小邊界，並且用最簡單的方案去滿足使用者的要求，按照這個思路寫了一版方案給使用者彙報，結果大敗而歸，還是小看了使用者，還沒等我把方案講完，使用者就說，你這不對啊，原來你們的規劃可不是這麼說的，說完自己拿出我們原來規劃的方案講起來，本以為是我引導使用者，最後變成了使用者給我講方案，你說痛苦不痛苦。
這次溝通之後使用者放了狠話，如果下次彙報方案還是這種水平，就不用給我彙報了，這次溝通使用者講了非常多的訴求，幸虧我當時留了一手做了個錄音，回來反覆研究錄音，最終總結出三點核心需求，圍繞這三個點總結出專案目標，又寫了一版方案，這次總算能和使用者平起平坐了，使用者願意和你平等交流了，而且提了很多中肯的意見。
後來終於迎來了轉機，使用者需要給公司總裁彙報這個系統的建設方案，趁著這個機會，我幾乎用盡畢生所學，週末在賓館裡閉關兩天，寫出可一版方案。
這次方案不只是邏輯架構嚴謹，而且PPT也的做的美美的，更重要的是藉著這個機會把我們想做的功能放大，寫得足夠詳細，足夠亮，不想做的部分淡化或者完全拋棄，並給出了合力的理由，這個方案看起來仍然非常的高大上，絲毫沒有感覺少了很多需求。
經過這次成功的方案彙報，使用者徹底改變了對我本人，甚至是我們團隊的看法，專門指定我需要討論方案可以隨時來找他。
從被使用者牽著鼻子走，到和使用者平起平坐，再到引領使用者，靠的就是提出專業解決方案的能力，這方案的載體就是傳說中的PPT，也就是這三個PPT，讓我們的專案初步從失望中拯救出來 。
二、全新的產品摸著石頭過河
從來沒做過類似的產品，所以做這個專案基本就是摸著石頭過河，對業務的學習、理解的過程是痛並快樂著，開始痛苦，突然開竅找到使用者痛點的那一刻感覺很快樂。
沒有對業務的學習和理解，也就沒辦法寫出那些讓使用者滿意的解決方案，這裡和大家分享一下我的業務學習過程。
先是和使用者溝通，通過和使用者溝通能大概瞭解使用者關心的業務範圍，哪些問題是他們比較關心的，這樣對要學習的業務有個大概的框架。
然後是看收集類的各種管理辦法，實施細則、方案PPT，通過看看這些資料去捕捉使用者關心的問題，豐富對業務的理解，這個時候大概能看到一些問題的解決方案，並且提出一些業務理解的假設。
最後是看相關係統，通過看相關的業務的資料印證自己的假設，這個時候如果能會一些SQL語句，可以直接查詢後臺資料庫的資料，來驗證自己的假設，對業務的理解就能更快。
這三步下來基本上能達到對目標業務的理解，如果這個時候可以找個小夥伴一起探討業務，論證假設就好了，互相討論，對業務的理解能更加深刻。
業務學習能力，對一個B端的產品經理而言非常重要，這是做出好的產品，在專案中征服使用者的必備能力。
很多C端產品經理轉行做B端很不適應，就是因為疏於對業務的理解，覺得把C端那套方法論拿過來就能用，事實上真的不靈。
B端產品經理最核心能力就是通過自己對業務的深刻理解，提出優秀的解決方案，這個方案並非完全是IT層面的方案，而是兼具管理和IT，所以好的B端產品經理是行業專家和IT專家的混合體。
三、敬業的態度決定一切
這是我出差最長的一個專案，有半年左右的時間，因為經常要彙報，經常是週五剛到機場，然後接到客戶電話，下週一又返回去，就這樣馬不停蹄的從家、機場再到客戶現場。
那年我的年終總結是這麼寫的，事實證明，工作和生活是不能平衡的，所以有時間陪伴家人一定要高質量的陪伴。
使用者也知道我的情況，有時候硬把我從北京叫回去，也會感覺不好意思，通過這種奔波，使用者對我比較信賴，也比較欣賞我敬業的態度，知道我和他們是一條船上的人，真的希望把這個專案做好。
“態度決定一切”，這句話前中國男足教練米盧經常說，用到這個專案上也十分合適，通過自己的敬業態度，讓使用者感知到，專案也變得順暢多了。
四、內部鬥爭，自信爭取投資
這個專案有個小插曲，最開始的時候，因為專案比較大，由兩個產品線共同承接了這個專案，另外一個產品線承接的部分，做出來的系統使用者不滿意，基本上要翻盤重做，他們不願意做，後來本地銷售讓我們接，我說接可以，另外一個產品線必須退出，並且把合同額一分不少的給我們。
另外一個產品線的老大覺得自己投入了人力幹了大半年，雖然系統無法驗收，還是希望能分一杯羹，結果互不相讓，只能找總裁仲裁了。
到了總裁那裡，我們把訴求和未來對這個系統建設的方案講得清清楚楚，對方只想要錢，講不出方案的價值，結果幾百萬的合同額，總裁拍給了我們。
這算是一個小小的勝利，雖然是對內的，因為是各部門獨立結算，到了年底算業績的時候，這些錢還是能有些作用。
還是迴歸到使用者價值，你只要能把方案的價值講清楚，能為使用者創造價值，可以保證後續和使用者的繼續良性合作，作為高層領導依然會放心的把這件事交給你去做。
五 、有張有馳，控制好專案的節奏
方案贏得了認可，系統也都順利上線，也逐步開始推廣使用，可專案卻遲遲無法驗收，原因並不是系統不滿足他們的需求，而是使用者明年沒有投資了，如果給我們驗收了，後面還要好多推廣運維的工作，怕我們直接撤了，不驗收硬拖著，作為產品線也沒法一直堅持持續投入。
最後我們選擇的策略是放緩專案節奏，不再主動的推進專案，讓使用者著急找我們，經過幾次試探，使用者發現很多工作推進起來非常困難，也大概明白了我們的意思，大家友好協商，遺留了少許問題，最終還是把專案驗收了。
這個事情也讓我們明白一個道理，專案的節奏把控很重要，當發生一些突發事情的時候，停下來，放緩節奏可能會迎來轉機，一張一弛，文武之道就是這個道理。
最後向因為這個專案變胖的同事們致敬，他們很多都是現場的開發人員，也是從北京出差到現場，經常加班寫程式碼、找bug、上線，吃飯沒規律，一下子都胖了好多，感謝小W、小Z，還有一位女同胞小L，感謝你們，當然也包括我自己，因為這個專案胖了20斤，這大概是讓我最痛的一件事吧。