段時間了，一直沒時間真正動手用一用。我看這個項目就不錯，不算太大，就用它試試吧！”。
　　“好主意！”，大家紛紛表示贊同。
　　……
　　“約定時間已經(jīng)過去1個月，現(xiàn)在項目進展到底如何了？什么時候可以交付？”，客戶方CIO質(zhì)問到。
　　分析員小張：“現(xiàn)在主要困擾我們的是一些需求細(xì)節(jié)一直存在變化，開發(fā)團隊又有了一些人離職，所以……”（真正的情況是：由于團隊第一次使用Hibernate，有些數(shù)據(jù)訪問層的問題一直沒有有效解決，導(dǎo)致進展不斷失控。）
　　現(xiàn)在許多名稱中包含“需求分析”、“系統(tǒng)分析”之類的職位，大多是由技術(shù)骨干擔(dān)任的，因此在工作中很少從業(yè)務(wù)角度進行分析，更多還是追求技術(shù)框架、新技術(shù)。對于這種現(xiàn)象，究其根源，關(guān)鍵還在于“技術(shù)能力”對他們的未來發(fā)展更為重要，而“業(yè)務(wù)能力”卻不是那么重要。但為了使需求工作有更好的提高，我會強烈呼吁那些Title上有“分析”之類名稱的人們，加強業(yè)務(wù)分析吧！
　　編程人員：斷章取義
　　對于第4幅圖，可以用一句生動的話來概括：“你要繩子，我給你了；你要木板，我也給你了；你為什么說這不是你想要的呢？”。我想程序員也有類似的問題想問自己的客戶，“你要文本框，我提供了；你要一個表單，我也有了；你為什么說這個程序不是你想要的呢？”。這讓我想起了這樣一幕：
　　案例&場景：
　　叮鈴鈴……，程序員小趙的電話急促地響起。小趙剛接起電話就聽到了對面迫不急待地抱怨聲“倉庫管理員反應(yīng)，入庫模塊沒法使用！你馬上查一下，盡快解決一下！”。
　　小趙放下電話就開始Check out、Builder、Run、Debug……等一系列操作。經(jīng)過一番測試之后，小趙沒好氣地提起電話回復(fù)說：“這些客戶真是笨！這哪有問題，肯定是操作上出了問題！我怎么用都是好的，你們客戶服務(wù)的人也應(yīng)該加強對用戶的培訓(xùn)，別什么事都扔給我們！”。
……
　　可是，問題仍然沒有解決！開發(fā)人員到了現(xiàn)場一看，終于發(fā)現(xiàn)了問題的所在：這是一套基于B/S的倉庫管理系統(tǒng)，在入庫時，倉庫管理員首先需要錄入入庫單，然后填入“驗收情況”，最后點擊“入庫”按鈕。但當(dāng)倉庫管理員錄入完入庫單，逐一驗過入庫貨物之后再回到電腦前時，等待他的卻是一個令其不知所措的問題，Session超期！
　　一肚子氣的小趙一個電話就打到需求分析員小錢那里：“你們的需求是怎么寫的！這么重要的東西也不寫明白，我們怎么知道填完入庫單后要驗貨那么長時間，才填寫驗收情況呀！”。
　　“哦，這也算是需求嗎？如果這也算的話，那我們豈不成了業(yè)務(wù)人員了！”，小錢很強勢地回答到。
　　這是需求嗎？也許很多讀者會有不同的看法！但如果缺乏對業(yè)務(wù)場景的了解，又如何能夠真正理解需求呢？斷了“業(yè)務(wù)場景”之章，必將導(dǎo)致取出的“需求”之義有所偏差呀！ 
作者簡介：中國系統(tǒng)分析員顧問團軟件工程首席顧問，中國軟件技術(shù)大會杰出貢獻專家，資深咨詢顧問。主要研究領(lǐng)域為需求工程、系統(tǒng)分析與設(shè)計、軟件估算，致力于推動軟件工程方法論的落地應(yīng)用。本文節(jié)選（并改編）于筆者新著《軟件需求最佳實踐：SERU過程框架原理與應(yīng)用》（電子工業(yè)出版社博文視點）

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html