如何進行需求開發？如何培養勝任需求開發的人員？
高級質保經理：（1）如何有效地進行需求開發？（2）如何培養能有效勝任需求開發的人？（3）需求定義的產物：《需求規格說明書》，如何保證它的質量？（即同時滿足客戶與項目組的需求？）
備注：客戶方認識到需求是軟件工程源頭性的工作，結合實際工作中的慘痛教訓，公司提出對需求的相關活動進行改進，目標是首先確保項目組“做正確的事情”，然后才是“如何正確的做事情”。
感謝您的來信*，關于“需求及需求管理”實在是一個過于龐大的主題，這次的回答首先試圖回答我們應該如何理解“需求”或“系統需求”。關于怎么做以及如何實施是相當關鍵的問題，但是只有首先理解了“做什么”，我們才能確保展開正確的行動。
本回答只是試圖開啟一扇窗戶，關于如何培養相關的團隊成員，工作與控制應該如何設定才能使得需求工作變得更加優秀，我們可以在其后的月刊中作為連載。
什么是本企業客戶的真實需求？
對需求及其管理的一個重大的誤解是我們以為企業內部的人員可能知道需求，但是需求只可能來源于外部，來源于客戶，所以我們只能向一類人了解信息，即“客戶及最終用戶”。當我們去真心誠意的理解客戶及最終用戶的需求及需要時，我們就會發現對于客戶及最終用戶來說的需求與我們自己定義的需求大相徑庭。
其實大多數的 IT 服務供應商都忽略了這樣一個問題：即對接受 IT 產品及服務的典型客戶及最終用戶來說，接受服務的過程往往也是一次（重大）改革的過程。這樣的例子層出不窮，對于每一個下決心實施 ERP 的企業來說，采購哪家的軟件系統從來都不是重點，重點是誰能為我提供過程及管理改進。對于采購一整套自動化系統的公司來說，是否必須實施自動化是一次重大事件，并且可能直接與某個競爭戰略掛鉤；也許面對終端消費者的互聯網企業并不那么認為，但是只要問一問已經習慣了在實體環境里購物的顧客如何徹底改變消費習慣——使之保證每一件商品都在網上購買，是多么困難的一件事情，我們就知道這必然也是一次變革的過程，是客戶及最終用戶重新認識自我的工作（或活動）及其背后價值的一次大膽嘗試！
換句話說，客戶到底是在購買一個系統，還是采購了一次改革？這樣的問題回答直接將顛覆我們對于客戶需求的認識，并且理解許多的需求及需求變更是從何而來，又為何組織不了也預見不了。這也意味著，我們可能并不十分清楚，對于自己的企業客戶，什么才是他們的真實需求。
對需求及管理的難點
項目，是一件事情、一項獨一無二的任務，也可理解為是在一定的時間和一定的預算內所要達到的預期目的。從定義中我們不難看出“項目”具有的最大特征就是“不確定性”，無論我們已經完成過多少次樓宇設計，下一次的樓宇設計對我們來說依然需要重頭開始；同樣的，無論我們曾經設計過多少款財務軟件，為下一個客戶提供的定制必定充滿未知。目前絕大多數的IT工作皆以項目的形式出現，而對項目的各種管理，包括需求管理，本質上對就是對“不確定性”的管理。
只有重新認識了我們的客戶及客戶的需求，我們才能夠去深入思考“在自己的工作中什么關鍵因素造成了最大的不確定性，同時這種不確定性對需求工作的麻煩也最大”這個問題。限于篇幅，這里只列出幾個我們認為最重要的因素，供各位作為思考的起點：
產品及服務的根本價值
還有什么比這個問題更容易回答呢？MS Office 提供辦公自動化，財務軟件提供自動化的財務數據處理及信息流轉，OA 帶來辦公信息的共享，諸如此類。但可惜這并不是事實，需求工程師們現在都已經知道，被調研者口中說出的需求并不一定是發起一次解決方案服務的根本動機，比如財務經理是口述財務軟件應該做成什么樣的人，但是財務報表的最終受益者卻可能是公司的總經理或股東們，而他們卻并不是操作系統的人，甚至他們都不接觸系統，但是某個財務軟件的發起又很有可能是一次股東大會上某個股東提出的一系列財務制度改革的重要組成部分。那么對這家公司來說，財務軟件多么自動化的解決了繁瑣的財務工作并不是服務的重點，重點是新的財務流程及相關制度。讓我們來看看另一個案例：在同一市場競爭的兩家物流公司都需要一套信息管理系統，并且90%的功能都幾乎雷同，但是對于第一家物流公司，其背后真正的需要是通過一套信息系統真實改善企業經營流程，期望通過降低成本從而提高日益激烈的市場競爭力；而第二家公司則完全是為在第二年推出電子商務的需要做出考慮，他們需要整合服務信息從而率先在市場上獨家推出基于互聯網的電子商務（IT 服務），從而徹底改革公司的經營服務內容。對于第一家公司，他們實際采購的是一次運營管理改革，而對第二家公司他們根本是要采購一次公司戰略改革。一次服務背后的價值大小，直接決定了此次服務中變更的可能性、發生的時間及其變更的內容重點，背后價值越大的，其變更的可能性就越大，但發生變更的時間點卻恰恰較為靠前，原因是由于客戶的重視，在整個服務過程中客戶都會不斷去思索和提出新的問題。但是變更的數量卻并不是由這個關鍵點所控制的，無論是做一個有價值的系統還是做一個沒有價值的系統，需求的變更數量都是差不多的，差別在于變更的內容。當系統的價值很大時，對于業務及非功能性的需求變更就顯得較多（因為這些與最終的變革密切相關）。但若系統本身價值不大，則發生變更的部分就顯得比較瑣碎，包括界面的操作、數據的定義、一些支持性功能等等。
市場中的客戶及最終用戶對于服務的認識及成熟度
零售或制造商們現在都是十分理解一點，那就是一件商（產）品的成熟度越高，與顧客的溝通就越容易。今天，沒有人會懷疑電話的作用，但若放在 50 年前，人們會懷疑既然我們已經擁有了那么便宜和方便的電報系統，人們為什么還要去花錢購買一臺電話？快遞業務一經推出就受到了市場的廣泛質疑，當時的人們找不到任何理由去接受一個價格遠遠高于郵政服務的業務，但是事實證明所有嘲笑快遞業務是嘩眾取寵的人自己卻成了這個笑話的主題。同樣的例子也發生在了惠普、IBM、埃森哲身上，總之事實證明在一個新生事物被普遍接受之前，不受待見屬于常態而不是特例。IT服務是這樣一個充滿溝通與協作的過程，是一個共同創造的過程，作為需求的源頭，客戶及最終用戶對于此事的理解直接決定了工作的效果與效率。但十分可惜，包括客戶在內的絕大多數參與者都并不十分清楚最終的產出目標是什么，這就注定了越是重大的變革，就越是只有模糊的期望，而不是明確的目標。同時，客戶及最終用戶對于產品及服務的認識，也直接決定了變更的數量。一種產品及服務推出的時間越長，接受客戶檢驗的機會越多，其功能就越穩定，其特征就越是可以被標準化，在目前 IT 的各個行業中，系統集成各行業所推出的解決方案標準化是最多的，這絕非偶然！
IT 專業人士對于客戶業務的熟悉程度
截止到目前，只有在為某個特定領域服務超過 5-8 年的工程師和經理人才會對于 IT 專業人士給予認可，無論你是編寫代碼還是做測試，無論你是一位前線的銷售人員，還是后臺的實施人員，技術能力都只是工作的基礎，業務知識才是工作的核心。如果客戶對于產品及服務的熟悉程度決定了“表達”—— 信息的正確輸出，那么IT供應商對于自己所提供服務的本質及客戶業務的熟悉程度就決定了“理解” —— 信息的有效輸入，同時也決定了對于無法被量化或標準化的抽象概念的控制程度。就像代碼走查，最優秀的代碼走查人員能夠通過觀察代碼找出潛在的 BUG；同樣，最優秀的 IT 專業人士，能通過觀察各種中間產出物（無論是閱讀代碼、測試用例還是需求書）來找出潛在的業務缺陷（而不是技術BUG）。換言之，我們就掌握了一種能力，在工作的各個階段我們都是邊工作邊驗證，邊摸索邊前進。和上述兩種客觀造成需求變更的原因不同，供應商對于業務的理解程度較低會主觀上直接造就變更，對客戶隱藏著的需要的錯誤理解將直接產生虛假的變更。這些虛假的變更與真正的變更混淆在一起會造成與客戶的溝通更加困難，并且往往得不到客戶的認可。所以這些變更是真正的質量問題，是值得去努力提升并解決的重要研發問題。
上述一系列的問題只是開啟了一扇窗戶，看到了一些風景，市場、公司及人力資源等客觀環境的不同會造就不同的對變更的影響，甚至許多是組合影響。理解這些內容實際上并不需要花費經理人過多的時間，但是只有組織上下真正理解了變更的原因，才有可能嘗試去控制變更或正確應對變更。
雖然，造成麻煩的因素多種多樣，但不同的企業并不是要針對所有的因素做出處理，也不可能解決所有的問題，那是不經濟的。對于一家企業的某個階段，導致嚴重問題的真正重要的因素往往不會超過3個。接下來的問題必然是我們需要做什么？
首當其沖的必然是明確企業的環境，并且列出本企業需求工作的不確定性特征。
其次，企業必須就變更的因素進行重要性分析，篩選出至多不超過3項關鍵因素。
接著，企業必須為這些因素分別確定一個重要特征——控制力。比如之前的第一項因素是企業根本無法控制的因素，價值只取決于客戶及最終用戶，供應商僅有選擇客戶的權利。一旦選擇了市場及相關客戶，就決定了企業必須堅定不移的滿足客戶的需求，所以控制力是最弱的；第二項因素中，雖然我們無法控制客戶，但是至少我們能夠循序漸進的影響客戶，我們至少有機會“教育客戶”，但是“教育客戶”必然是一個長期的過程，而且十分依賴客戶本身的能力和態度，所以對于企業，我們傾向于將其定義為一個較難控制的因素；第三項顯然是我們可以通過努力去控制和改善的，我們對于第三因素具有較強的控制力。
再次，我們必須將這些因素放入項目管理中，針對不同的特征進行管理與控制。比如，對于完全無法控制的因素，我們所要做的是必須將其作為獨立的決策項盡早發現與提出，越早理解這些內容我們就能將問題的損失控制的越小，反之對計劃的變更所造成的影響也就越大且毫無討價還價的余地。項目經理針對這樣的因素，只能將其視為約束項考慮，即這是無可避免的，所要采取的策略也毋庸置疑，即我們必須在計劃中留出空余來應對必然產生的變更；而對于需要經過長期不懈的努力才能解決的變更因素，我們必須采取完全不同的態度，敏捷方法論的提出恰恰是為了解決這個層面的問題，將產品交付的生命周期分割成小模塊的最大好處就是可以盡早的發現變更與問題，并不斷與客戶產生溝通與理解。從而將變更的影響力控制在最小的范圍內。
最后，誠如 IBM 的廣告——我們提供的是隨需應變的解決方案，如果我們意識到 IT 服務的本質就是應對變化，其工作的核心內容不是生產而是設計，那么我們就最終理解了諸如持續改進的意義所在了。對于生產性工作，我們是在工作內容穩定的假設上展開的工作；而對于設計性工作，恰恰是建立在工作內容未知的假設上展開的工作。面對這樣的工作，我們能從什么地方獲得靈感與借鑒呢？真正了解 ERP 或即時生產（或精益）歷史的管理者會得到這樣一個啟示，這些管理方法和工具的產生的背景是這樣一種環境，生產工作本身是相對穩定的，但是對于生產多少、采購多少、何時運送、投入資源等環節卻是因市場環境變化而發生劇烈變化的。即時生產所要求的，恰恰是充分利用現有資源，在需要的時刻生產出適當數量的產品。這就要求：
a. 保證信息及溝通的暢通；
b. 保證各種資源渠道的暢通；
c. 保持一個從市場到最終服務的完整生命周期的計劃鏈；
d. 同時這種計劃鏈又必須十分靈活，易于調整；
e. 持續不斷的改進自己的服務，以保證不要受到質量約束的影響。
對于我們，上述案例所給出的啟發是從市場第一次接觸一個客戶開始就當作一個項目的起始，而不是等到合同的簽署或簽署前；即使是最特殊的市場，項目和項目之間也必定存在較大共性，持續不斷的提取出這種共性，并且保持特性的靈活；樹型的組織結構已經極大的妨礙了工作的靈活有效和即時工作，企業需要更靈活的組織結構以保持工作溝通的順暢。
以上僅僅是窺視了需求及其管理的冰山一角，更談不上十分系統的闡述了某種方法論，因為一成不變的方法是不存在的，解決方案必須在充分理解具體環境的基礎上被制定出來。但是至少我們可以有了一個開始，真正了解需求，以及用嚴謹的態度去應對需求工作中的困難。
