軟體外包，需求分析由誰來做？

01-05

是外包公司做還是甲方？如果要求甲方人員按照軟體工程的規則寫需求分析是否現實？

如果你是以客戶（甲方）的身份在看這個回答，那答案是肯定的。連需求文檔都不想寫還想讓別人做好你的項目？我只能負責任的猛喊一聲：「醒醒，大哥，別做夢了！」

雖然你貴為甲方，是我們這些項目團隊的衣食父母，對我們的能力深表信任，我們對此也表示感謝，但作為項目實施者一方，我們只是負責把你明確的需求落地，你到底怎麼想的我們真的無法預知呀，畢竟我們沒有洪荒之力呀！

如果你的想法不落到紙面上，項目團隊怎麼能get到你的點，做出的項目和你的預期有巨大差距也是板上釘釘的事情了。

我們在做項目過程中遇到過很多喜歡口頭表達自己想法的客戶，說起自己的想法神采飛揚、手舞足蹈。遇到思維清晰的還算好，遇到表達能力差的那簡直給我們造成幾萬點的暴擊傷害，根本就get不到點，最後客戶還不忘悠悠補一刀：「說的很清楚了吧，可以做計劃實施了吧……」

遇到這樣的客戶，作為項目執行方的我們除了狂吐血之外，真的生無可戀！

事實上，這些客戶一旦把他們想法落地到紙面上，他們自己就會發現邏輯上有很多值得商榷的地方，更不要說產品細節了。

項目如果只靠嘴說的話，那對客戶、對項目執行者來說都是災難，因為口頭說產生的歧義太多了。

比如客戶A說：「我要做個聊天室，大家可以在裡面聊天」。A以為把自己的需求說出來了：你看需求很明確了，就是能聊天嘛，這有什麼難以理解的，直接開始做就成了。

但對，對於開發團隊來講，他們會想到：這個聊天室是一個能容納多少人的聊天室？聊天室里聊天是語音聊天、文本聊天還是視頻聊天？除了聊天功能還有沒有別的功能等等。

所以，你想只憑口頭一句話把需求講明白是不可能的。

同時，從商務角度來說，需求文檔是評估工作量最直接的數據來源，沒有需求文檔，項目做到最後該花多少錢都說不清楚。

總結一下，我覺得如果作為客戶不想寫需求文檔或者寫不出需求文檔，那就是沒有把自己的產品想清楚，沒有深入的去思考自己的產品。你都不知道自己想要什麼，怎麼要求別人去給你實施？畢竟項目需求不是你一句去太空給我摘個星星那麼簡單易懂的。

厘米腳印-小而美的互聯網諮詢公司，致力於用技術創新提升效率的 geek 團隊，提供互聯網產品諮詢和研發服務，訪問 http://limijiaoyin.com了解更多。

需求分析，我們公司是這麼做的：

對於需求不明確的客戶，如果他有能力自己梳理清楚需求，那就自己梳理清楚需求，製作出需求文檔再來平台開發也可以。

更多的情況是，大多數客戶自己不會，手下也沒有產品經理，需求不明確又不能進入開發，怎麼辦？要我們分析需求，時間和人力成本怎麼辦？

後來我們推出了一款服務，1980元16個工作時梳理需求，提供腦圖，業務流程圖和包括功能拆解圖在內的產品文檔。

1980元，費用不算高，客戶也能接受的了。產品經理花費的時間也得到了相應的報酬。可以說是雙贏！

1980梳理需求爆款服務-程序員客棧

看完這篇文章你就知道了：

無數的教訓，為什麼要做一個好的甲方？

作者：張海龍，CODING CEO，技術創業者。CMU計算機碩士，原 Oracle 高級軟體工程師。2010年回國創業，曾聯合創辦開源中國社區，2014年創辦 CODING。
Coding.net 是國內最大的一站式雲端開發平台提供包括代碼託管，項目管理，產品演示，WebIDE 等工具，幫助軟體開發者提高生產效率，並實現「Coding anytime anywhere」的願景。Coding.net 目前已經積累了15萬開發者，20萬項目，並且獲得了 IDG 和光速的兩輪投資共計 1200 萬美元。
2015年8月，CODING 推出碼市，旨在通過雲端眾包的方式提高軟體交付的效率，幫助軟體開發行業實現高效的資源匹配。

這個世界上有很多的甲方也有很多的乙方，我們在生活和工作中，不是充當甲方角色就是充當乙方角色，往往兩個角色交替著來。看起來，甲方給錢，在交易中應該是主導地位，那為啥軟體外包領域的甲方經常在項目交付的過程中狼狽不堪？

我平時常常充當第三方，看了形形色色的甲方和乙方，也算是看透了：軟體開發項目要成功，更多的取決於甲方，取決於甲方的能力，態度，還有期望。項目換乙方不難，但是換甲方，基本就死了。我們常見，公司換一任領導，之前沒完工的項目黃掉的可能性極高。所以，做一個好的甲方很重要，我們來談談為什麼，以及如何做一個好的甲方。

沒有人知道你在想什麼

這個世界之所以有那麼多矛盾，就是因為我們的思想是不透明的（是不是想起了三體人？），沒有人知道你在想什麼！你找人幫你做軟體開發，你得明確的告訴乙方你想做什麼，軟體的使用場景是什麼，解決什麼問題。你在你的領域混了很多年，你覺得有些問題很顯然，但是乙方沒有。你覺得理所當然的問題，乙方可能完全沒有聽說過。所以，作為甲方，你應該不厭其煩，儘可能詳細的說明白你的需求。很多軟體項目做出來效果不理想，追根究底都是甲方一開始沒說清楚。你不能覺得你的需求很常見，很簡單，所以乙方應該理所當然的做出你想要的東西。如果你要的軟體真的這麼常見，那你就不用定製開發了，直接買現成的。每個需求都是獨特的，所以請不要用這樣的語言來描述需求「做一個跟 xxx 軟體差不多的就行了」。你說你想要一輛車，乙方好不容易做出來了，結果你說其實你想要的是四驅的，座椅加熱的，還得是敞篷的。這樣的結局只有一個，就是加錢，延期，否則乙方不幹，但是你不爽，埋下了不歡而散的種子。

由於國內的甲方大部分不夠成熟，所以很多國內的開發者和外包團隊都傾向於接國外的單子，包括香港和台灣的。我參與的海外項目，無一例外，都是非常詳細的需求文檔，並且對接的人非常耐心的跟乙方解釋業務邏輯。更重要的是，甲方非常清楚，他的責任在哪裡。在出現問題的時候，他會判斷這個問題是誰的原因，不會把所有責任往乙方身上推。這是我們值得學習的地方，也是我經常跟甲方講的需要改進的地方。

一分價錢，一分貨

大家都知道買東西是一分錢一分貨，憑啥到了軟體開發就不是了呢？憑啥要求乙方給你免費幹活呢？有些甲方意識不到軟體的價值，因為看不見摸不著。所以才有一些廠商把軟體裝到伺服器內再賣高價的情況，因為伺服器是實實在在存在的，掏錢就很樂意。顯然，這是不對的。定製開發軟體的價值就是人工，雖然很多時候計費是按項目收，但實際上也是按人工時間算的，跟裝修一樣。刷牆看起來是按平米收費的，但實際上也是折算成刷這麼多面積的人工來算的。所以你裝修的時候刷牆刷完了發現顏色不滿意，重刷，不得再給錢么？任何功能的開發，調整都是有成本的，你想在有限的預算內做很多的功能，那你必須接受的事實就是做的比較粗糙，或者你得接受周期拉長，等乙方安排空閑時間幫你慢慢做。

我記得有一個理論是餐館理論「好吃，便宜，服務好」這三點不可兼得。很有道理，幾乎所有的餐館都不可能兼顧這三點，假如有，那一定會很多人去吃，排隊排死，自然服務也就不好了。這條理論放到其他行業也一樣，你怎麼可能要求軟體開發做到「質量好，便宜，交付快」呢？

我是甲方，我是爺？

現實中的交易有時候會存在一種情況，給錢之前甲方是爺，給錢以後乙方是爺，所以才有了所謂的第三方。軟體開發由於不是實體產品，很多時候的定義無法完全明確，這樣的情況尤其明顯。但是，一個成功的軟體項目，往往甲乙雙方都不是爺，就是純粹的甲方和乙方，各有各的責任，各有各的義務。乙方作為收錢的一方，對甲方態度好點，耐心一點是應該的，但是特別要強調的是：甲方並不凌駕於乙方之上。先來說點不正規的，還拿裝修說事兒。21世紀都進入第二個十年了，然而我們在裝修的時候不還是得給裝修師傅送香煙么？這是為什麼呢？明明給你裝修費用了，為啥還得買煙？這是一種態度，師傅你工作辛苦了。結果是，師傅高興了，活兒乾的也快了，質量也好了，橫平豎直，保證不偷工減料。有的地方看的見，有的地方看不見。軟體開發也是一樣，你對乙方尊重，乙方自然會有體會，別的不說，同樣的功能，我可以把代碼寫寫好，注釋多寫點以便後期維護。

再來說點正規的。軟體開發項目如果完全按照合同來，估計甲方也有很多小尾巴，大家誰都不讓誰事情就很難辦。所以把關係處好是有必要的。還有，軟體項目總有小修小改，如果嚴格按照產品定義來，乙方完全可以不做這些修改，或者要求加錢。但是如果大家相處的好，這些小改動就順手做了。這些都是很現實的狀況。畢竟，軟體開發還算是門手藝活兒。

這篇文章是寫給甲方看的，所以乙方的問題就不詳細討論了。說一個結論：如果你覺得乙方不靠譜，或者你給了錢就的聽他的，請儘快更換乙方，後面的錢不要再支付了。雖然前期的投入會讓更換乙方的成本很高，但畢竟比項目爛尾要好。而且多次實踐經驗表明，如果乙方前期不靠譜，後期變的靠譜的可能性為零。除非你願意忍辱負重，湊活把項目做了，否則儘快終止交易，換人。

糾結還是交付？

所有程序員都知道，程序不可能沒有 Bug，而且 Bug 往往越修越多，然而這在很多甲方那裡是不能理解的。我經常跟甲方講的是要看主要功能，主要流程是否能走通。除非一些特殊領域的軟體，例如金融，工業控制等等，其他的軟體，特別是互聯網領域的，都應該是先上線，然後再完善。我看到的幾乎所有互聯網產品都是這個路子。所以，在絕大多數情況下，我們應該選擇儘快交付上線，而不是糾結於一些小問題。一般的軟體項目都有質保期的，所以這些小問題可以在質保期慢慢修。這有幾個好處，首先是不用趕時間，做的質量會好一些。其次，上線以後有了實際的用戶和運營數據，可以更加準確的定位一些問題。

另外就是從心理上來講，大家做一個軟體一般都好幾個月，如果一直拖著不上線勢必會影響士氣。雖然，理論上乙方只是幫你開發而已，是否上線跟他關係不大，但成就感多少還是有一點的。上線以後，大家修 Bug 的情緒都會不一樣，而且大家都知道已經上線了，有問題得及時修。總而言之，我建議甲方在交付階段不要糾結，先交付，然後利用質保期完善。

在軟體開發這件事情上，你可能是甲方，但在你工作的領域你可能是乙方，換位思考一下會讓你成為一個更好的甲方。

最後，如何判斷你是不是一個好的甲方呢？很簡單：乙方是否下次願意降價 10% 跟你繼續合作。

（完）

*註：所有配圖來源於互聯網

這個還是得分具體情況討論，首先得看甲方人員與外包公司的能力與經驗。

如果甲方都是業務人員，沒有多少IT背景，甭說按軟體工程要求寫用戶需求說明書或規格說明書，能讓他們提出明確的需求都謝天謝地了；
如果甲方本身就是IT公司，那就需要考慮成本預算、風險因素與進度控制等因素了。理想的情況下，甲方自己做需求分析應該更好一些，項目溝通要通暢、成本估算更準確，成果驗收也非常明確。

我認為需求只能是甲方的責任，乙方參與進去只是自討苦吃；想辦法讓甲方說出清晰的想法，乙方能做的是建模和確認。做需求做得臉都綠了。。。。

需求分析，甲方固然重要，但最重要的是需求架構和需求管理的那個人。。。沒那個人，怎麼做都是越做越死。。。不過，推薦的方式是：大甲方（業務）+小甲方（需求管理）對應乙方的架構師，同時監管乙方的測試人員（或者是甲方的測試人員），這樣驗收的時候會順暢一些。

如果項目要做好的話，最好是甲方給到開發需求文檔，越詳細越好，乙方給做的話，來來回回是很坑的，甲方的需求變化又快。

先說結論

按國情來看，無論處於對客戶負責還是保護自己，開發團隊做比較好。

在國外或者一些跨國企業，或者是成熟公司成熟的採購，方甲方很少直接找到「開發公司」。通常由整案諮詢公司／代理公司來為甲方提案，提出需求、溝通、ppt、ppt、ppt、ppt、ppt、開會、開會、開會、開會、修改、修改、修改、修改、我再考慮、考慮、考慮、考慮、便宜一點？不行啊老闆！便宜一點？不行啊老闆！便宜一點？不行啊老闆！時間來不及了！方案通過。

諮詢公司／代理公司對行業理解和客戶認知都比較全面和接地氣又能把握客戶老大的尿性和口味，因此需求控制相對穩妥些，他們再將需求轉交她們管理得供應商，提需求，做項目管理，促成交付。這些整案公司也因此盈大頭利（當然品牌、客戶資源和銷售能力是他們更深層次盈利的原因了）。

但是對於很多小企業而言，不會邀請這樣的代理公司而是直接找到開發團隊，這樣整理需求的責任往往落到了團隊手裡，無論處於對客戶負責還是對自己的保護，一定一定一定一定要做好需求分析和需求報告。

一般來說，一個項目由10%的產品規劃、s+10%前端開發+10%後端開發+70%的撕逼組成，

但是如果花個15%的時間來寫清楚需求分析和需求報告並且通過郵件確認給客戶感性+理性認知之後項目就可以80%的時間用來精心打磨產品，測試完善，交付給甲方爸爸，不用撕逼長皺紋了。

當然，報價單里就要有需求梳理這一行了。因為這真是個苦活累活技術活啊！

血的教訓。連這個icon叫啥都要寫清楚！

很明顯，是在外包公司。

本人就是一個外包公司的產品經理，客戶接觸越多，我就越想跳槽去做自己產品的公司。

還是雙方一起做比較好，做好需求調研，和甲方人員一起做，並多做確認

若甲方有產品、技術團隊，一般需求都比較明確且有成型需求文檔，這種情況主要是找技術團隊來實現。大部分甲方的需求只是個概念，具體需要去挖掘和梳理他們需求並整理成需求文檔，這種情況服務商算是全程參與了。

同意樓上的意見，最近碰到一個項目，也是這個情況，不光要做需求分析，而且詳細設計都需要做一部分，給外包的只是編碼部分