如何表達需求--CSDN研討會之二

主持人：剛才討論了很長時間，主要圍繞問題焦點就是如何捕獲需求。把需求素材都拿到以后，就進入到下一個階段，就是把這些需求素材整理成文檔，也就涉及到下一個話題，也就是需求表達方式。我想問大家一個問題，在目前各位所在的公司，你們在捕獲需求之后，你們采取什么樣的方式來表達需求。同樣，我這里也有幾個選項：需求列表、用例、數據流程圖、各種實體關系圖、類圖、業務流程圖。就這有幾種表達需求的形式，我們現場做一個調查吧，看你們采取哪種方式來表達你們的獲取需求。

殷志梅：分階段，不同階段采用不同的方式。最開始是列表，然后是流程圖等，如果進一步細化的會有類圖和流程圖。

吳浩剛：這跟產品采用的生命周期模型有關系。

Kristian Persson：我們也是在不同階段用不同的方法。在最開始的時候可能會用到列表或者用例場景，在細節的時候，會用類比圖。

主持人：在我們調查結果中可以看出，列表、用例是比較常用的方法，在不同階段會強調某一種方法。大家分析一下這幾種方法的優缺點？

潘加宇：業務流程圖表達的并不是直接的需求，而是表達現實里的情況，并沒有說我這個軟件要做什么，只是現在是怎么回事，算是捕獲需求的一種工具，但表達的并不是需求。你也可以說把所有功能和用例串起來變為業務流程圖，系統開發以后業務流程圖是什么樣的？從這個角度來看，業務流程圖也可以表達需求，但往往用的業務流程圖是描述現實的，現在公司的工作流程是這樣的。并不是說系統怎么做，應該嚴格來說，是輔助的工具，除非是表達目標業務流程，打算這個系統上馬以后公司流程是這樣的，這樣就表達了需求。需求列表是最通用的。用例組織需求方式用得越來越多，不管是正式還是非正式的。

白慧冬：通過業務流程圖和客戶做交流，獲取的是大的需求列表，我會整理成用例圖，在項目之前我會得到一個小的需求列表，也是和用戶溝通得到的，這小的需求列表是開發人員看的，讓開發人員知道根據這個怎么做實現，應該說這三個是我們經常用的東西。我書里面也是這樣描述的，我這個人是做什么寫什么，不做的就不敢寫。

舉一個例子吧，02年我在中國電信做過調研，我是先找網通負責人，從相關部門獲取了一個大業務的整合，然后找相關人獲取信息，在訪談過程中，我的方式是他說我劃，我劃的是目前業務操作過程，然后我就看，讓他提意見，然后我做修改，直到他滿意，訪談結束以后，我整理為文檔，因為當時中國電信要求出一份全國的工程建設規劃文檔，再過三四天之后，這之間是訪談其他的人，我會再找他一次，往往當時一個人的想法會有一些沖突或者偶然性，甚至對于不同的人訪談同一個流程會得到不同的結果，所以我一般會做二到三次的反饋。

主持人：大家對這個案例有何點評呢？你在“需求定義”的過程中，又有哪些寶貴的經驗可以與大家分享？

于波：按照需求細化也好，或者實現也好，是偏離用戶的需要和需求，競爭力會出來，很多事情就會非常的麻煩。

Kristian Persson：大家要達成協議，比如客戶訪談的目的是大家在同一個協議基礎上提交需求。像剛才白慧冬所說的之所以反復去做，目的是達到大家都認同，不然的話，客戶有很多需求，你成交不了，沒有辦法實現。

殷志梅：我覺得很多需求不一定是好需求，我以前做過一個用戶的需求，用戶的需求比較低，我們沒法說服用戶，結果也沒有辦法，最后按照用戶的方式，有一個合同，希望與計算機界面上的合同做得一模一樣，結果花了一百多萬，用了幾年就扔掉了。我認為對于需求應該以發展眼光來看，因為他們是做外貿的，要隨時發展，很多東西都要變化，他沒有考慮到這些點，說要完全符合這種模式做，結果也失敗了。

于波：Kristian Persson先生用協議，大家共同的理解，我開發商和客戶之間，對需求理解的是一致的，如果是一部分相交就麻煩了，通過互相理解，又有一個承諾就出來了，現在把需求到底是什么，做多深，有一個范圍，這是對后續的管理是很重要的，很多人僅僅關注功能上，沒有關注性能上，也有可能非功能的需求沒有關注到。比如一些法律法規的限制都要考慮進來。再有就是你不僅僅要考慮到客戶的需求，還有領導的需求，還要考慮產品是給誰去使用的，也就是最終用戶的需求，哪些人要用，他們會怎么想。

潘加宇：我認為需求變化是非常復雜的，雖然認為非常簡單的技能能做到，剛才于先生說到需求是一種承諾。在這個前提條件下，按照我里面所說的做，我就能夠保證你到達，這是一種契約或者承諾。剛才殷志梅也說了用戶滿意的不一定就好，比如在臺上表演的人不一定是最重要的人，在臺下第一排看戲的人往往是最重要的人，比如臺上演習，演員也很重要，但真正重要是坐在第一排看戲的人。需求怎么寫，怎么做，這要考慮第一排的口味，第二排的口味，第三排的口味，用戶可能坐在第一、二排，開發人員坐在最后一排，要求性能非常的高，看誰是坐在第一排，誰坐在第二排、第三排，他們對戲有什么要求，這是非常復雜的。

于波：作為開發商也好，作為提供商也好，其實有一個責任教育你的客戶變為前瞻性的，剛才我從另外一個角度已經闡明了這一點，行業的趨勢以及行業規范，比如是貿易性的，要加入WTO或者已經加入了，你肯定要把這部分考慮進來，如果你沒有加入進來，可能之后又有需求的變化。

林治宇：我認為還有一個層面，我們還可以做一個內部的需求，也就是對于未來行業的發展趨勢提供解決方案，對于這個怎么來做這是一方面?？赡芪覀儠堃恍╊I導、專家、用戶坐下來討論，以這種方式和他們交流，從而引導出一些問題和方案，然后再進行改進。

潘加宇：用例這種技術把這些問題都暴露出來了，用例是執行者和用戶者在臺上看戲，比如東方通如果沒有用戶，是給中間件用的，這依然也有演員，照樣有戲上演，照樣臺下有觀眾，東方通公司說我只照顧到開發人員的利益，只要用得方便就可以了，而開發人員就坐在最后一排，最大的受眾是第一排，東方通公司是坐在第二排，所以要把這些利益關系以及對外做的承諾表達出來，這種技術承諾是非常有價值的。用過以后，做用例開發技術指導，往往做下去的話，是很難的。用例技術用到以后，理解了這一點，就覺得非常的妙，臺上有人演戲，臺下有很多人看戲，一旦進入這個階段的話，就會產生很大的利潤。如果大家有興趣的話，可以試一試。

于波：從需求和管理來講，軟件開發企業當中怎樣貼近客戶關系，怎樣使產品更加人性化，更接近它，這可能也要充分的考慮。因為剛開始很多人不懂得電腦，還有一種懼怕感，跟這有一些關系，但不完全是這樣，中國實行ERP系統，很多人說花了巨資沒有用，但也跟后期是否培訓有問題。我認為現在不僅僅是開發，還講究服務，這樣可能會更好。無論需求管理也好，需求開發也好，真正是提高產品能力，提高公司效率，提高客戶滿意度，達到公司真正的經營目的，其他的方法都是以這樣為服務的，而不是圍繞需求做開發。

潘加宇：我舉一個案例，有一個公司做調研的時候，說對于流水線的管理引進計算機管理，但工人說不用，只要手工管理就可以了。廠里面要求嚴格規范，必然帶來工作量的提升。往往有這么幾種方案，我可以搞電腦大獎賽什么的，誰得獎，給你發獎，或者我勒令你一定要學這套系統，否則就下崗。真正的需求公司是平衡這方面的利益，既要規范，又要像手寫那樣方便，把所有的缺陷變為幾十個條碼，這樣比手寫更方便，當然唯一的缺陷就是成本高了一點，要買掃描設備。實際上這也對需求公司提出了很高的要求，看能不能平衡，而不是說要犧牲某一方面的利益，否則這個系統也執行不下去。

觀眾提問：就需求調研這塊，我也做了需求調研逐漸面向用戶的，是否可以這樣理解調研工作，因為是解決兩個目的，或者兩個疑問，第一是用戶要的是什么東西？他完成什么工作，比如在現有工作流程上，提高管理，是要實現什么東西？第二，在開發之前，雙向溝通當中，我們這樣來實現是否能滿足你的要求？是否需求調研起到這樣的作用呢？

白慧冬：一般沒有影響，但要考慮用戶的需求你們公司能不能解決，這是你們要考慮的，但不是需求調研的關鍵問題，需求調研的關鍵問題是用戶需要什么？以及用戶需求了解以后你們到底怎么做。

你用不用原形方法跟用戶沒有關系，用戶關心的是你能不能實現。你所要得到的是用戶需要什么東西，關于實現，是你自己的問題。你用再高的技術和再低的技術，跟用戶沒有關系。

主持人：網上還有網友提問：需求有很多，怎樣收集最有價值的需求呢？
于波：跟開發的周期、開發的方式都是有關系的。最后還是雙方要達成一致的利益，雙方要解決的是什么。

吳浩剛：要確定優先集的需求，以及在哪個階段開發是最有用的，最后做一個比較，找一個雙方更容易接受的方案。

于波：在需求收集或者分析過程當中，我們已經提到這樣的問題，做一個簡單的需求列表要比較，而且相互之間的需求，不管從哪方面來講要有一個綜合的過程，還要談需求實現的優先集的問題。剛才用戶會不斷的提需求，如果需求控制不好的話，就會蔓延增長?，F在這種失敗的案例已經很多了，對于一些非功能的需求、成本呀，時間進度呀，都需要確定。

原文轉自：http://www.anti-gravitydesign.com