hello，大家好！我是小婧。今天是國慶假期的第一天，不知道你有怎樣美好的計劃。我們的共讀活動從今天開始啦，希望大家能和小婧一起完成共讀的任務(wù)。建議的方式是，你先自己讀完《軟件需求最佳實踐》這本書的第一章，然后再來看小婧寫的下面的內(nèi)容，最后記得將你的所想以留言的方式寫在下面哦。祝大家假期愉快，閱讀愉快！

2016-10-01 《軟件需求最佳實踐》徐鋒著

第1章 需求實踐現(xiàn)狀分析

本章從分析軟件失敗的根源入手，對問題現(xiàn)象進(jìn)行了描述，緊接著對問題進(jìn)行了分析，最后提出了解決方案。

1.軟件項目失敗的根源

通過權(quán)威的報告，我們可以看出：
“軟件項目十大敗因”中，有五項是與軟件需求直接相關(guān)的。
A 不完整的需求
什么樣的需求才是完整的呢？這點顯然需要由用戶代表來做評定。而因為以下的原因，阻礙了用戶代表進(jìn)行需求完整性的判定：

• a“軟件需求規(guī)格說明書”寫的太多技術(shù)化，用戶代表看不懂。
• b 驗證變成了確認(rèn)。
• c 試圖讓一個人看完整個“軟件需求規(guī)格說明書”，并且指出錯誤。

*小婧：這點其實在我工作的領(lǐng)域非常常見，我們一般在做完需求規(guī)格后會經(jīng)歷評審，其實是一種轉(zhuǎn)階段的標(biāo)志，也就是說客戶代表簽字確認(rèn)，我們這個階段算是結(jié)束。但是客戶代表是否能真正代表所有客戶，我們并不能確定，就連客戶也不能確定。所以很少有客戶能在這個階段指出我們需求規(guī)格中的錯誤。另外，更加明顯的是，客戶能看得懂我們需求規(guī)格的內(nèi)容很少，最多能看懂業(yè)務(wù)流程圖，對于我們進(jìn)行的其他技術(shù)化的描述，完全看不懂。如果我們再不進(jìn)行解說，只是丟給用戶代表去看，成效其實非常低，只是走個過場，簽個字罷了。

B缺乏用戶參與

• a事不關(guān)己高高掛起
• b逃離無趣區(qū)
• c被你趕走

C不切實際的用戶期望
D需求變更頻繁

• a需求變更分析不到位
• b用戶并未察覺變更的代價
  E提供了不再需要的

*小婧：哪些功能需要，哪些功能不需要，這點到底由誰說了算？曾經(jīng)遇到過開發(fā)說，用戶肯定不會這么做的，是個正常人就肯定不會這么操作。但是事實上，用戶還真就這么操作了。有的時候我們花費了很大的精力去完成一項功能，但是并不知道這個功能用戶到底試用的情況是怎樣的。大家都聽說過二八原則：系統(tǒng)中20%的功能被80%的用戶使用，另外20%的功能可能一次都不會被用到。那么我們?nèi)绻盐覀?0%的精力都花在這20%的功能的改進(jìn)上，是不是會更有效率呢？如何統(tǒng)計是個問題，但是研發(fā)同事肯定有辦法，不論是記錄日志，還是暗藏計數(shù)器，或者統(tǒng)計某個webservice調(diào)用次數(shù)，都是辦法。定期的收集這些數(shù)據(jù)，為我們的產(chǎn)品做改進(jìn)是非常有目的性和效率的。

2.透過表象，分析本質(zhì)

A需求變更頻繁
雖然同樣是需求變更，其誘因也是不同的，有的是對原有需求的背離，有的是原有需求的遺漏，有的是業(yè)務(wù)流程變化引起的……針對不同的病癥有不同的原因，要用不同的藥。

*小婧：其實我覺得每個軟件產(chǎn)品、軟件項目的性質(zhì)不同，其需求變更的種類也會不一樣。不需要很教條的按照書上的分類方法去進(jìn)行分類。但是，肯定是要分類的，特別是對一些經(jīng)常發(fā)生的類型進(jìn)行細(xì)分，即劃分子類。只有統(tǒng)計、分析后，我們才能更好的去解決這個問題。而不是變更了，也不找原因，下次接著變。我以前遇到一個事例，原先我們產(chǎn)品的表單有一個選項“其他”，后來客戶說應(yīng)該叫“其它”，讓我們改。我們改了后，月底統(tǒng)計分析時出問題了，統(tǒng)計出了兩個QITA。這就是變更沒做好分析。解決方法其實應(yīng)該用相同的code進(jìn)行統(tǒng)計，而不是直接取值。

B上線阻力大

• a利益沖突

*小婧：我覺得這部分問題發(fā)生的原因就是干系人分析做的不到位。

• b工作量增大

*小婧：這個問題在項目實施中非常常見，比如以前請假就打個電話或者發(fā)個郵件說一聲，現(xiàn)在要上OA走提交申請單走流程。這個部分我覺得“洗腦”很重要，我們要向用戶闡明，從整個企業(yè)的層面來說，這樣做的好處。

• c運行效果差

*小婧：這在傳統(tǒng)軟件行業(yè)非常普遍，就是故事編的挺好，牛皮吹的挺大，真正實施后卻用不起來。也就是方案無法落地。

• d完全崩潰

*小婧：對非功能需求的忽視，往往會導(dǎo)致這樣的問題。而需求人員在進(jìn)行非功能需求的分析時總是采取“定性”的方式：高可靠性，高靈活性……這類無法測試，無法驗證的等于沒說。最好是制定全系統(tǒng)通用的非功能性指標(biāo)，進(jìn)行量化。

3.方法論與需求工作

A.計算模式

*小婧：我剛工作的時候，C/S架構(gòu)大行其道，很多用戶用C/S用習(xí)慣了，總是以C/S的標(biāo)準(zhǔn)要求我們B/S的系統(tǒng)，于是我們要設(shè)計出“暫存”的功能……但是隨著現(xiàn)在互聯(lián)網(wǎng)時代的開啟和到來，這種現(xiàn)象已經(jīng)好很多了。

B.軟件工程方法論

*小婧：關(guān)于傳統(tǒng)的“瀑布”和迭代的“敏捷”之爭，我已經(jīng)不想多說什么了。我想說的是，一切不做重構(gòu)的敏捷就是耍流氓。別總想著為不寫文檔找借口。

C.開發(fā)思想

• a.成熟度
• b.溯源
• c.了解局限性

*小婧：不知道別的團隊怎么樣，我們的團隊在這個方面很謹(jǐn)慎。一般要對一項新的技術(shù)進(jìn)行充分的預(yù)研、論證、demo、測試后，再找需求、開發(fā)團隊、測試團隊進(jìn)行評審評估是否可以使用，再小面積的從邊緣的模塊開始嘗試。新技術(shù)的學(xué)習(xí)成本太高，如果公司沒有那個時間和人力的投入去研究，那么還是對已經(jīng)比較成熟的技術(shù)進(jìn)行評估和應(yīng)用比較好。

小婧是一名行走在產(chǎn)品路上的資深業(yè)務(wù)分析師（BA），如果想與小婧同行就請關(guān)注我吧！