理解客戶業務和客戶需求

標籤：

一、如何理解客戶業務和客戶需求？
　　
　　原則1：由粗到細，從宏觀到微觀。
　　
　　必須先從宏觀上瞭解客戶業務的全貌，再逐步深入細節。因為對於客戶的業務而言，我們是外行，如果從業務細節著手，很容易迷失方向，失去對業務核心的把握。同時要認識到，對於一個外行而言，我們對細節的深入也必定是有限的，不要指望自己能夠無窮的徹底的瞭解每一個細枝末節。一是不可能有無限的時間給你瞭解，二是沒有這個必要。因為未來的系統也不可能完全包辦所有業務的細節，還有很多事情是要靠客戶企業中這些具有專業技能的人來做的。
　　
　　原則2：從不同層次的客戶代表那裡收集不同層次的需求
　　
　　對於企業高層決策者，他會給你描述一個系統的大的功能藍圖，如使企業具有整體報價能力，能更好的服務於高端客戶，能支援企業的重大業務決策等；對於企業各級管理者，他會給你講述他這一層的管理需求，如能更好的進行部門員工的業績考核、產生月度報表，更好的進行業務結算等；對於各級業務操作人員，他可能給你談及很多業務細節和操作細節……
　　
　　在由上到下的逐級訪談中，對未來系統的描述就從一個大黑箱變成多個小黑箱，再變成透明、明確、詳細的系統定義的過程。
　　
　　客戶業務調研和需求分析註定是一個不斷細化的過程，不要指望一次訪談/調研就能窮盡，也不要指望一次開發過程就能得到完全滿足客戶夢中期待的那套系統來。因為事實上很多需求是隱性的，連使用者都不清楚自己的需求。只有經過多次迴圈細化才可能把更多隱性的不斷挖掘、暴露出來。
　　
　　二、如何具體開展需求調研工作？
　　
　　在RUP中定義需求工作流程的工作目的如下：
　　1. 客戶和其他涉眾*在系統的工作內容方面達成並保持一致；
　　2. 使系統開發人員能夠更清楚地瞭解系統需求；
　　3. 定義系統邊界（限定）；
　　4. 為計劃迭代的技術內容提供基礎；
　　5. 為估算開發系統所需成本和時間提供基礎；
　　6. 定義系統的使用者介面，重點是使用者的需要和目標。
　　
　　[涉眾]：英文stakeholder在RUP中的翻譯，在專案管理專著中往往譯為“干係人”，指所有與項目成敗有直接間接利益關係的個人或團體。在軟體項目中，往往包括企業的投資者、各級管理者、系統使用者、公司客戶，甚至包括企業的夥伴和競爭者。
　　
　　首先要做好業務調研。要儘早把已經收集到的業務資料熟悉起來，並在理解的基礎上提煉出問題列表，製成調查問卷。業務調研的要求是一定要沉下去，深入細緻的瞭解客戶的商務程序，而不是急著趕工完成自己的需求工件設計和業務模型的建立。在瞭解各項商務程序的同時，與客戶一同深入分析業務的實現邏輯，並記錄下有關的實現案例資訊，收集好、整理好、分析好有關的參考材料。
　　
　　要把迭代的思想貫穿於從業務調研、需求分析，乃至項目實施的始終。所謂迭代，就是我們老老實實承認我們沒有能力一次就把事情做到盡善盡美。所以我們就先把一大部分有把握的地方做好，再在前面成功的基礎上不斷做好剩餘的部分，最終就能無限接近於成功。設計編碼過程是如此，業務調研和需求分析也是如此。
　　
　　企業系統的設計開發與軟體產品的設計開發有一個最大的不同，就是企業的需求肯定會變化，過去在變、調研的時候會變，系統實施後還會變。而我們要做的就是去適應這種變化。事實上，也正是因為我們採用的是物件導向的方法，才可能做到這一點。因為物件導向的方法認為：對象的基本屬性是客觀的和不會頻繁變化的，而對象間的關係則是可能不斷變化的。所以我們在業務調研和需求分析中也要認識到這一點，把不變的沉澱下來，把可變的靈活性和變化的自主性留給客戶。
　　
　　各位都是做技術的，在業務調研和需求分析中難免會不由自主的考慮一些技術實現的問題。值得強調的是：需求與技術無關。在業務調研的時候要忠實的進行記錄，不要因為你個人對實現的疑慮而對使用者需求進行（過早的）修改和裁減。
　　
　　要善於爭取客戶方各級人員（均是項目干係人，RUP中稱為涉眾）的支援。只有得到未來系統使用者的充分參與，項目才有可能最終取得成功。一套缺乏使用者參與的系統，即使最後做出來也是註定沒有人去用的。
　　
　　一是要利用客戶企業的組織關係，爭取到上層的支援，由上到下進行調研配合；二是要會在調研過程中為目標使用者樹立有針對性的願景，讓他認同願景的同時主動、積極的支援你的調研過程。
　　
　　……
　　
　　（以下內容從略）

理解客戶業務和客戶需求