起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識你被潛規則了嗎？追溯軟件項目失敗的根源
長年混跡在軟件場的老鳥們，哪個沒品嘗過失敗的痛苦，當我們的日日夜夜的加班及辛苦的勞動換來的只是失敗的結果時，不知道你有何感想。每當我完成一個項目時，都有著虛脫的放松感。虛脫是累的，放松是一種解脫，不論項目成敗，心里的感覺就是—個——終于解脫了。
在軟件行業這些年里，生活就如同上了發條，不允許有一絲的松懈，就是希望自己負責的項目能夠成功，得到公司和客戶的認可。但現實呢？相信所有人都一樣，都會遇到這樣或那樣的問題，“理想很豐滿、現實很骨感”。
老吳今天要說的是軟件項目失敗的根源到底在哪？
幸福都是一樣的，但不幸卻各有各的不幸。
當我們接一個項目，在初期需求調研時，感覺客戶確實要的不多，功能也不太復雜。但隨著項目的深入，你會發現客戶的需求會不段的蹦出來，而且客戶談的需求也很合理，應該有，不加上功能確實不完整。但是，一切已經遠超你最初的控制了。當初只是10萬的一個網站，后來變成你根本控制不住成本，變成了賠本連吆喝都沒賺到，客戶還不滿意。說你：“太垃圾了，這么簡單的產品都做不出來”。你，苦啊……
案例分析：
前兩年我受公司委托，以產品經理身份參與了某房產信息平臺的建設，從項目談判、需求調研、設計、開發、上線，整個過程都全程參與。在談這個平臺規劃時，感覺確實是一個有前景的房地產信息平臺：平臺目標是為了能夠打通買方、賣方、經紀人、中介公司、建委等多方的信息瓶頸，讓信息通過平臺變得透明，讓交易變得公平而公正，買方能夠通過平臺直接聯系賣方，實現自行交易，如果能夠真正實現自行交易，將會打破整個房產市場結構。
如在網絡上實現交易，買、賣雙方因為信息不對稱而存在不信任問題。如何解決呢？買方，通過向平臺提供個人相關資料信息，平臺利用買方提供的資料信息進行購房資格和身份的核驗，保證買方為有資格的有效購房人；賣方，平臺與北京建委實現合作，提供賣方的房產信息真實性校驗，保證賣方人與房源的真實性。解決了這兩個瓶頸，就有了自行成交的前提。
當時與對方溝通過多次，客戶對我方公司資格和能力也比較認可，就要求報價和簽約，當時通過初步的溝通對需求有一個大致的了解，當然細節都還要不斷的溝通、確認，我們也出過幾版效果圖，在雙方會上多次溝通過。但商務合作已經到了報價階段，不會等大家需求全談明白了再進行，然后重點就轉向談商務，多少錢、多長時間、多少人力？估算吧，整理列出大模塊，自行成交、經紀成交、用戶管理、建委等外部接口、權限管理、交易管理、平臺后臺管理、網站前端。各模塊列出大致功能及報價。下一步再經過幾輪的砍價，達到意向，簽約。
當項目正式啟動后，再與客戶談需求時發現有著一種莫名的無力感，雖然大方向大家都是認可的，但客戶方每個領導的想法及實現細節都不太相同，對這款產品將來的意識形態描述有區別。有的領導提出要有大宗資產，房產交易過程中提供的服務是不太掙錢的，從掙錢效益看大宗資產的交易才應該是平臺的核心。
有的領導提出房產數據才是重點，在房產平臺剛上線時，買、賣雙方、房產都是空白的，沒有房產資源如何做交易并帶動平臺良性發展。有的領導提出，真實性交易是核心，如果想打造良性的發展平臺并被大眾所認可，真實房源、真實交易是重點，保證真實性就要與建委等政府平臺對接，打通平臺與建委之間的信息鴻溝，以保證房源真實性及購房人購房資格，才能取信與民，平臺才能真正的占領市場并打破當前的經紀人壟斷行情。還有領導提出，與經紀公司合作，利用經紀公司的經紀人資源，讓平臺的用戶交易可落地，有了經紀人也能盤活平臺，以引入更多房源。還有領導說，現在PC版的網站平臺已經落后了，我們也要做手機端，需要手機端與網站端相結合，打造移動互聯平臺……
大家看到了吧，情況很復雜，問題很嚴重。老吳來給大家梳理下有可能導致項目失敗的幾個致命傷。
問題一：需求不明確
客戶方各執一詞，思想不統一。在思想不統一前提下，我們做什么都會是錯誤的，做多錯多。你說我們應該跟誰談？如這個問題不解決最后死的就是你。有的產品負責人為了讓客戶滿意，盡量去滿足客戶要求，完成客戶需求。導致的結果就是，開發人員累得要死，項目需求控制不住，需求間矛盾沖突，各執一詞。而且成本上升導致公司賠錢，公司領導不滿意。你就變成了人民公敵，項目結束后你也該走人了。
問題二：需求蔓延
大家說的都有道理，但有的需求與我們最開始談的已經不太一致了，最開始談的合同內容里并沒有大宗資產交易，也沒有手機端功能。哪怎么辦？相信你們都遇到過吧，感覺是個坑啊。
問題三：沒有指定接口人
誰都跟我們提需求，而客戶內部都沒有達到思想統一，我們到底應該聽誰的？讓我們無從下手啊。你得指定一名對接人才行啊，從他哪出來的我們才能認為是真正的需求，不要誰都跟我說需求，誰都說需求，就是沒有需求，最后的結果是客戶方沒有代碼，出問題時誰都可以不負責，哪時你可慘了，連個替你說話的人你都找不到。
問題四：用戶期望不實際
在要房源沒房源、要用戶沒用戶、要數據沒數據的前期過程中，就把平臺想的過分完美化，想通過一個平臺的建立就實現鷹擊長空的目標還是有點要求過高?；ヂ摼W市場一直強調的是小步快跑、快速迭代。這種互聯網+房產交易的平臺，還需要O2O的線上與線下結合，用線下業務的開展來推動線上業務，用線上業務再來推動線下業務的開展。剛開始起步時，一窮二白，資源還都沒有，一下子做個大而全的產品，合適嗎？ 想通過一款軟件就一統江湖，可能嗎？
好接著往下講這個故事。
為了解決以上問題，我也是很頭痛，即要讓客戶滿意，又想得到公司支持。但老好人在復雜的項目環境下是沒法生存了。大家好才是真的好——是錯的。首先，先得跟自己公司領導溝通好，讓公司領導知道目前的項目情況，爭取得到領導的支持和幫助。其次，要與客戶針對項目情況達成一致意見，我們得有一個指定的需求對接人，避免需求入口過多問題。要讓需求回歸理性，不能讓需求偏差太大吧，拿合同來約束需求。讓對方思想不要太過信馬由韁，通過溝通來解決需求蔓延的問題，讓思想回歸理性。同時也要讓用戶知道，太發散的需求，最后會導致需求無法控制，無法落地，無法執行的尷尬，項目的失敗是雙方的，要讓對方知道，我們是一根繩上的，一條船上的，我們是真心的與客戶溝通，認真的幫助他分析，不要出現對立、不要出現你們我們這種界限，真誠的付出會得到對方的尊重。
之前老吳寫過一篇文章“如何控制需求蔓延”，有興趣的朋友可以看下。
故事繼續下去，經過努力，雙方達成共識，客戶方有一位負責人專門負責此平臺的建設，我們只需要針對這一位領導就可以了。另外，經過公司領導的幫助，把需求拉回了合理的范圍?？此坪唵蔚膯栴}，實際是需要多方努力的，一方面客戶態度非常積極，而且對方負責人是一個比較勇于擔當的人，針對此項目專門成立了一個業務組。另一方面公司與自己的團隊也都愿意付出，領導也多次出面與我一同承擔責任，共同與客戶探討、溝通。經過了一翻努力，看似開始走向正軌了。
接下來，當去除了項目雜音后，當大方向確定后，就開始一起討論需求細節了。細節如何確定呢？對方公司不是一個軟件公司，是一個業務型公司，對房產業務非常精通，但對軟件要如何做，不清楚；做成什么樣，不清楚。在需求細節不明確的時候，我們團隊打算先出原型，用原型來獲取對方需求，接下來就是一起坐來來討論需求，討論原型的階段。經過一翻努力，原型最后確定下來了，需求也就確定下來了。開工吧，因前期討論需求所花的時間比較多，項目工期開始變得緊張了，只好從外面再請一支外包團隊進來，開始封閉開發。
因時間緊，我們采用兩手準備原因，一方面開發人員開始搭建環境、了解業務、進行設計。另一支UI隊伍開始出效果圖，出完效果圖再與客戶溝通。確定了展示效果并對數據庫設計、功能設計完成后，團隊開工建設，之后就是從早起一直干到晚上11點的循環日子。因當時是年末，臨近春節時，團隊全員蒙頭垢面的走出賓館后，當看到第一縷陽光后，心情是苦樂摻半，技術人員、設計人員全部回家過年了。我與外包公司的項目經理一同回到客戶公司，進行匯報演示，演示結果還算可以，但客戶也提出了許多意見。當時提的意見還是有些空泛，因為提出的多數意見都是方向性問題，實際這時候再提方向性問題確實有些不合適了，生米都快煮成熟飯了。
問題五：需求細節沒想透徹
因當時要求上線時間比較緊，中國項目都是短、平、快的要求，不允許給你大量的時間去整理、分析需求。團隊為了趕工期，許多細節地方還是沒有想的太通透，尤其是后臺的管理部分，與客戶溝通的主要是在溝通業務前臺部分，買方、賣方、經紀人之間的交易，如何實現房源的驗證部分，在后臺上許多設計不合理。
問題六：多團隊作戰，思想難統一
客戶方、我方、外包公司，三方聯合作業，每一方都需要溝通好，每方都有自己的想法及打算。這回出問題的是外包公司，我方要求對方至少出10名開發人員，剛進來的人都是我面試的，后來項目緊，又進來的人我也沒再把關，直接讓對方的外包公司帶隊的項目經理把關了。在封閉期間，因有的功能實現太慢，我就找到負責這塊的技術人員看著他如何實現的，才發現，這哥們是個菜鳥，還是大菜鳥。這就是問題了，外包團隊為了節省成本、湊夠人數找了些成本低的人濫竽充數，打著自己的小算盤。當時找了對方項目經理說明情況要求換人，但因為是年底了，他們也以很難找到水平好的人進來為由，就托了下來。再說后臺，我與客戶一直在討論前臺功能，后臺功能有所疏忽，我就讓外包公司項目經理帶人負責設計、開發，當我忙完其它工作后，想要看下設計的后臺效果時，卻以正在開發，快出來了，遲遲沒有給我看效果。原因就是他們想盡快做完，怕我看后再提出其它要求，先把生米下鍋了，最后看你拿我怎么辦？因為利益不同，導致各方思想不統一，給項目也帶來了諸多麻煩。
問題七：項目時間緊，經費少
以前，我做過對日外包項目，那里也經常加班，但日方給的需求、設計的時間都是比較充足的，他們對需求、設計看的非常重，可能也是因為客戶方在日本的原因吧，不在現場，需求不好把控，就盡量把文檔整理的特別細致。設計能達到什么程度呢？你看到詳細設計文檔都可以直接編碼，都不用你細想了，基本上就是偽代碼程度。中國軟件行業的特點就是快，客戶多半是對軟件開發過程不了解，認為可以一個月就出一個產品。談合作時基本上就是談完需求后，再談的就是兩件事，多少錢、多長時間。錢報高了不行，有比你出的更低的，一些小公司不計成本的接項目，惡性競爭嚴重；時間報長了不行，客戶們要不不做，要做就得馬上出來，給的時間就幾個月，你要說半年、一年的，你都不好意思說，非挨嘴巴不可，這就是中國軟件的現狀。
案例繼續，年后，帶著團隊回來，與客戶溝通，新問題出現了，我們做的房產剛上線時不能沒房源數據吧，得找資源啊。于是，項目暫停下，先與外包公司協商，技術人員先回，當項目再啟動時，人員再過來。因為客戶沒有太懂IT的技術人員。我呢職責就變成，給客戶做技術支持，我們一起去找房產數據公司談合作。還有，房子的價格與地理位置關系比較大，為了更直觀的展示地理位置信息，我們得有地圖啊，于是，我開始幫助客戶協調地圖公司。另外，房子要想網上銷售，得盡可能的讓買方多了解房子內部信息吧，于是，又協調三方公司是否可以引進360度房子內部的全景展示。
這段時間做的事情基本上是，協調資源、評估可行性、出各種報告及文檔。經過集體的力量，項目又向良性發展了，房源數據和地圖信息都搞定了。有人要說了，地圖還用搞定啊，百度地圖都是免費的。我們的房產平臺是要引進政策資源的，有相應國企背景的，最好還是與同樣是政府背景的平臺合作比較好。這就如同要跟政府采購一批辦公軟件，能采購OFFICE嗎？不能吧，得用金山辦公軟件吧，當然買回來用不用是另外的事情。
資源協調完了，房源數據有了，地圖數據有了。360室內展示因采集工作復雜，工作量大，沒有做。人拉回來繼續做吧，新的問題來了。一個問題是，年后，有兩個骨干外包人員離職了，還有的外包人員被他們派到其它項目了，調不回來了。另一個問題是，我們的項目已經根據之前討論的需求做了設計、開發，程序都是根據自己設計的數據庫開發的，新買的房源數據的數據庫與我們的數據庫結構完全不同，結構不同，我們如何解決房源數據對接問題？而且，對方數據庫數據表就有300多張，對方只提供數據和每個表的字段說明，表關系完全沒有，買回來的只是一堆數據。這就相當于，中國改革開放初期，從國外買回一批高端車床，本想大干一場，卻發現，我們沒人懂啊，說明書全是英文的，沒人詳細講解，原來我們買回的只是一個美麗的花瓶。但我們的客戶并沒有認識到問題的嚴重性，他們以為有了房源數據就可以了，還想著將來做房產的數據分析呢，做個大數據啥的，沒有表結構、表關系，能分析啥啊，看都看不懂，300多張表，怎么分析，一地散落的珠子，沒有線頭啊。
其實，在談數據公司時我已經出過報告，并解釋過，但確實沒有其它家再能提供這么全面的房源數據了，別無選擇。另一個是，客戶與數據提供商相互間還是有著一定的信任關系，本身愿意一起合作的。做為開發公司有什么辦法呢，我們也只是建議，不能因為困難不做吧，還得繼續。想辦法吧，原則是我們的表結構不能動，要動以前開發的程序都白做了。另外，我們要把所有的房源數據導到我們表里，得研究提供商的與房源有關的表結構。還有個問題是，數據公司在合同規定時間內會把新采集的房源數據繼續生成給我們，新生成的數據我們也得轉過來啊。想辦法吧，具體辦法就不細說了，此處省略一萬字……
問題八：先干了再說，沒有全局考慮
客戶把一個項目包出去后，他們不太管你是怎么做的，我只要結果。希望你趕緊做出來東西，讓我看到，至于今后可能出現的問題，出現了再說，反正我不太懂，出問題了你得給我解決。就像這個案例中，第三方房源數據公司的出現，打破了現有的平衡，為項目帶來了大量的額外工作量。有的時候，我們很被動，你不能說讓客戶都萬事具備了，你再來談合作吧，因為哪樣的話，項目就不會再是你的了。你不能說，你別接其它房源三方數據了，你讓人用我們的系統錄數據吧。怎么可能，近10年的房源數據，數據量得有上千萬條。干吧，說多了都是淚。
問題九：人員變動
人做為項目資源，有著他的流動性，年后人員的離職，及原人員被分配到其它項目組，給項目帶來了額外的不確定性。外包公司考慮的是人員的成本，他不會因為你項目原因，把人給你留著，一有機會馬上就會把人分配出去，到時候抓狂的只有你。只能再花高價錢找人補充進來吧。
問題十：項目經理的控制力問題
當多位骨干人員離開后，項目開始變得難以控制了，之前雖然有大量文檔和原型，但在緊張的開發周期內，是沒有太多時間讓人細細理解，細細分析。有問題的話直接問，有的人離開了，只能看代碼，為了推動項目開展，團隊成員只能硬往前推動。代碼開始不好管理，雖然之前做了各種版本管理，隨著系統的變大，人員的變化，讓文檔、代碼、數據的管理也變得復雜。
寫的比較多了，故事就不再往下講了，后面還發生過其它問題，就不細說了。對于導致項目進行中的各種困難還有好多，嚴重的還有可能導致項目失敗。只是在這個項目中沒有出現，我繼續整理下，在其它項目中經常遇到的一些常見問題。
問題十一：需求變更頻繁
在很多項目中，客戶經常修改需求，經常遇到的情況是，你接觸的客戶代表并不是拍板人，當你們一起討論、開發的功能出來后，領導一看，不對啊，得改，然后就是你的幾個沒日沒夜的加班。這還是好的，有的功能全做完后，客戶提出來，方向錯了，然后呢？然后你瘋了……
問題十二：溝通不順暢
有時候，當你們與客戶溝通后，整理需求、出設計，想要再與客戶溝通以確定是否正確時，客戶出差了，那怎么辦，等吧，兩個星期后回來了，再溝通，再確定。修改完不一致內容后，再找客戶，他說，你等等吧，告訴你：“最近有領導檢查，沒時間弄這事”，然后再等吧……
我想追逐到末路 與你白頭到入土
不到地老天荒不認輸
等半夏葉落地
花開花落人離兮
我知道在你心里沒痕跡
當我初次遇見你的時候天空下著雨
而你高傲臉龐映入眼里侵入我的心
人群中蕭瑟的身影總是那么的清晰
我的眼睛不離不棄跟緊你的背影
再也找不到退路
問題十三：信息傳遞過程失真
記得有個真人秀節目，一個中國人說一個中國的成語，一個外國人聽后再告訴給另一個中國人，然后再告訴給另一個外國人，經過6個人后，你已經不知道第一個人說的是什么了。
經過這些流程后，你猜最后理解的人與客戶最初說的還是一回事嗎？
實際溝通存在兩個維度的問題，一個維度是客戶層現，另一個維度是公司內部層面?？蛻粢彩怯胁煌块T、不同領導的，每個人想要的、想做的都是一樣的嗎？信息傳遞給你，你接收的、你理解的就是真正的需求嗎？然后這個不一定正確的需求就一道道的傳遞下去，到了最后會變成什么樣呢。
問題十三：需求被放大或縮小
需求是一個很難被正確衡量的東西，于是我們就開始寫文檔、做原型，試圖把它立體化，豐滿起來的需求，就更加真實而直觀了。但許多產品經理或需求人員經常愛炫一些小技巧，加些特效或功能，讓它更能?？?。這還是好的，有的你根本就沒弄懂需求，以為的并不是真正你以為的，需求就這樣被你放大了或縮小了，在沒有被很好的確認后，就產生了一連串錯誤。最后的結果是什么呢？你，被一群程序猿、設計師們圍毆?！?20嗎？快，這里有一個傷者，需要急救。什么，怎么搞的——被人打的，太慘了，快來吧?。。 ?/p>
問題十四：利益紛爭
我們經?？垂曹娕c國軍戰斗的場面，共軍團隊攻打國軍，國軍將領在炮轟紛飛的戰場搖著話機喊：“我頂不住了，快給我增員啊。什么，你也沒人，你們有命令，不許離開陣地一步？他媽的，都這時候了，你還不增員，這是要老子死啊？”然后，電話被炮火炸斷了，只留下一個人在陣地上罵娘。在客戶方也好、在自己公司也好，當公司規模到一定程序，都要出現派系之爭和利益之爭，互相爭搶資源，寧肯自己人剩下，也不愿意幫助其它團隊。最后不幸的是，你躺槍了——哥，醒醒，快跟領導要點資源啊，再沒人支持我們就要廢了。你也不看看，誰還能幫咱？我們被潛規則了?。?！
“人在世上漂，哪有不挨刀?！表椖渴菑碗s的，悲歡離合，喜憂摻半，以上的問題你遇到過嗎？遇到幾個？你要沒遇到過，說明你還是新手，我們這些老鳥們已經練成金剛不壞之身了。兵來將擋，你總能夠通過自己的智慧化解這一個個難題，任何問題也都有解決方案，以后老吳慢慢給你道來，如何在產品和項目的烈火中永生……
對了，你問我，最后房產的平臺怎么樣了，上線了，還不錯，現在運行也挺好的，經過努力困難也被一一化解，最后成功上線。兄弟們的付出沒有白費，每個人都是從一個個項目中慢慢成長起來的，全都是一帆風順，怎么會撥云見彩虹。
本文由 @產品人老吳(微信公眾號：ChanPinLaoWu) 原創發布于人人都是產品經理?，未經許可，禁止轉載。
每次產品 每次項目幾乎都把上面的經歷一遍，如果沒有一個扛得住的領導 這事兒真是控制不了啊
寫的好棒，80%的問題都是我正在經歷的，需求蔓延真的很讓人頭大。