換個姿勢學程式設計(6)——需求分析和評審

需求分析是一個很大的題目，這裡我並不想象軟體工程教科書一樣地講需求分析的定義和常用方法、流程。這些在未來的學習和工作中你自然會遇到，我在這裡提出需求分析是希望你們知道它的重要性。

什麼樣的軟體是好的軟體？為客戶創造價值的軟體。

只要能為客戶創造價值，使用什麼技術，採用什麼設計模式，這都是次要的（某個世界五百強的外企現在還在用一個Foxpro的系統你信麼，我一直忽悠他們用我們公司採用“最先進技術”的產品可是他們怎麼都不上當）。

所以，軟體開發過程中首先要做的就是了解客戶的需求，瞭解軟體系統如何為客戶創造價值，這不是一件容易的事，比寫程式碼難。之所以會這樣是因為客戶不是學計算機的，我們也不懂客戶的專業，所以與客戶的溝通總是存在障礙的。客戶心裡會想：“這麼簡單的東西，還需要我跟你講嗎？”，而軟體開發人員會嘀咕：“這人什麼智商，怎麼說話總也說不清楚”。

軟體工程師要關注、關懷客戶感受，而不是站在自己的角度、用自己的好惡去處理問題，需求調研也不是把客戶的需求簡單複述一遍就算是完成了。要主動學習客戶的業務甚至商業模式，這樣你才能想到客戶前面去，想到客戶心裡去，也可以提前感知到將來可能出現的需求變更，減少專案需求變更的風險。 不要怕學了客戶的業務沒用，真正學好了你就不叫軟體工程師了，叫行業專家！

繼續講故事。

在我大學剛畢業的時候有一個某工程內部銀行的的爛尾專案，老闆讓我接手，我沒有直接買張票跑到客戶那裡去，而是花了半個月看之前留下的文件，然後找某財大的老師請教我不理解的客戶業務，這位老師甩給我一本《財務公司管理》的書，我又在公司啃了半個月。我估計老闆都做好尾款收不回的打算了，所以也沒有催我。有了這些準備，再去與客戶見面，客戶提出來的問題我不用特別費勁就能理解，至少在客戶說“國債回購”、“預期收益率”這些名詞的時候我不至於一頭霧水。當你表現得能輕鬆理解客戶的話的時候，客戶會更願意與你溝通，需求調研也更容易取得成效。

實際上大多數人開發人員並不樂意經常與客戶溝通，他們認為那是浪費繩命的行為，遠遠不如寫程式碼暢快。所以有些技術人員會迴避這個環節或者在需求調研的工作上敷衍了事，他們總是在第一次與客戶交流時就在思考用什麼語言、什麼框架、什麼資料庫來完成客戶的系統，盲目地相信自己能做出客戶滿意的軟體。這種情形下下做出的軟體系統往往南轅北轍，再加上有些殺千刀的銷售人員給客戶承諾了一個根本不可能實現的工期，在多方的壓力下，我們不得不很快進入設計和開發階段，而忽視了最重要的需求調研，這樣，我們就可以成功地做出一個客戶不想要的軟體系統。很遺憾，我們是為客戶服務的，如果我們做不出來客戶想要的東西，還是那句話——拿不到支票，這是很煩惱的。

從另一個方面，需求調研不成功的責任也不全在軟體工程師身上。因為很多時候客戶自己也不明白自己想要什麼，這也很荒謬，但事實如此。在軟體開發領域有一個詞叫做“需求變更”，所有人（除了客戶自己）都很痛恨它卻又無法避免，比如：

“媽，菜裡多放點醬油”

“算了，不要放醬油，多放鹽”

“我想了想，還是醬油吧，鹽吃多了不健康”

“鹽和醬油都不放，放點老乾媽吧”

“媽，再來點蔥不要蔥白”

這個梗來自知乎使用者celeron533關於“如何看待程式設計師因為需求反覆變更而離職？”問題的回答。

所以，理解客戶的需求，幫助客戶找出對軟體系統的需求並確認它，就是軟體開發過程中最重要的一步。

在實際專案中我們會花很長時間來確認需求（

2014年籤的單子我們現在還在天天開會確認需求我會亂說？

），在這個階段幾乎每天都要做的事情就是和客戶開會，開會主要做這些事：

瞭解、理解甚至修改（最佳化）客戶原有的業務流程；

和客戶一起討論他們提出的需求的合理性、可行性和可能的解決方案；

與客戶一起討論是否還有沒有考慮到的合理需求（需求挖掘）；

用文件、圖表來描述客戶需求，必要的時候做系統原型，並且和客戶確認。

這個過程中往往很漫長，有時候需求變更了還得推倒重來。

直到客戶負責人說：“好了，就按這個做，我簽字，我負責。”

呵呵，這是比較好的情況，遇到上面這種願意花時間確認需求肯簽字的客戶你算是燒了高香了。

我們經常會遇到的客戶這麼說：

“我們這個東西很簡單的，你照著**做就可以了”

“不要搞得那麼麻煩，你們先做，做出來我再提意見，你都沒有做我怎麼提意見？！”

“你們到底行不行啊，我哪兒來這麼多時間跟你們開會，你快點把東西做好上線就可以了！”

“不要在意這些細節，馬上就是市場旺季，系統要趕快上線，不然會影響我們的業績。”

相信我，如果你是公司負責人或者將來準備創業開公司，遇到這種給客戶拉*也要離他八丈遠，他們時間有限、預算有限，沒有契約精神，如果系統沒做好責任就全都是你的，你從這樣的客戶這裡很難得到真正的利潤。

如果你是程式設計師或者負責這個專案的人，你又不打算辭職，你就做好天天加班的準備。

在需求調研告一段落後（我可不敢說“需求分析已經做完了”這樣的混賬話），可能會產生下列檔案：

會議紀要

需求規格說明書

業務流程圖

介面設計說明書

系統原型

etc…

可以鬆一口氣的是，小白你是一個剛入門的程式設計師，公司通常不會把這個任務交給你，產品經理或者專案經理，或者其他水平比你高的程式設計師會去做這個工作。但凡事都有例外，如果你所在的公司只有三五個人，那這項工作也有可能讓你來做，不要輕視它。