減低開發(fā)過程變動依賴項目范圍管理

申請免費試用、咨詢電話：400-8352-114

　　范圍與功能的分別

　　在“如何把握不存在的需求”一文中，已經說明范圍是有效管理需求變更的唯一方法。有明確的項目范圍，我們才能夠學習及分析范圍內的作業(yè)流程，建立系統(tǒng)的功能需求，并在開發(fā)過程中當客戶要求變動的時候有效管理我們的工作范圍，才能夠有機會按照預算在指定的時間內完成項目的交付。

　　軟件開發(fā)項目從開始到今天，一直以來客戶都不能夠告訴我們需要哪些功能，他們只能告訴我們系統(tǒng)需要完成哪些目標?；仡櫋叭绾伟盐詹淮嬖诘男枨蟆币晃闹械牡谝粋€例子，20世紀70 年代的客戶需要把庫存管理進行自動化，收到的指示會像下例：“建立一套庫存管理系統(tǒng)取代目前的人工作業(yè)流程”。這一句指示是唯一任務說明。系統(tǒng)分析員在接受這個任務后第一個工作是建立項目的Term of Reference (ToR)。系統(tǒng)分析員會進行初步調查，通過簡單的訪談，與庫存部門負責人明確理解他們工作的開始點和終結點，得出的結果可能像下例：“從貨品(包括原材料，半成品及制成品)進入倉庫開始，到貨品因應生產或銷售申領要求離開倉庫為止，其中包括貨品存入量的統(tǒng)計，存放位置記錄，總庫存量統(tǒng)計，申領數目，檢貨，提取貨品，準備出倉，最后更新貨品存量統(tǒng)計等工作過程”。這是所謂的Term of Reference，也是我們今天所認識的項目范圍。

　　在用戶及管理層認同上述的ToR 后，這個項目的負責人便需要估計需要對多少人進行訪談，需要多久時間進行訪談，需要多少時間對訪談結果進行分析，多少時間建立項目需求，編寫需求說明書，需要多久進行系統(tǒng)設計，多少程序員及多少時間進行程序編寫，如何進行測試，編寫系統(tǒng)文檔，編寫用戶手冊，什么時候在倉庫安裝終端，如何連接主機，什么時候進行用戶培訓，如何讓系統(tǒng)取代目前的人工作業(yè)等等有關工作計劃及時間表。

　　在系統(tǒng)分析員完成訪談后，便需要依據訪談結果進行分析，理解什么時候知道有貨品進入倉庫，什么時候更新有關數據，如何更新，采用哪些表單，倉庫人員如何決定貨品應該存放在哪里，如何記錄有關信息，如何知道需要檢貨，什么時候進行數據更新，如何分別哪些貨品要去生產部門或者直接送到客戶指定地點等等信息。這些信息便成為系統(tǒng)在不同過程中所需的功能需求。

　　從上述的開發(fā)過程說明中可以體現功能需求并不是客戶或用戶提供，是系統(tǒng)分析員在理解目前的人工作業(yè)后分析出來的結果。

　　在系統(tǒng)移交到倉庫中運行前，倉庫中的工作人員需要對系統(tǒng)的操作進行學習及測試。要知道當時倉庫的工作人員并不是針對系統(tǒng)的功能進行測試，是對系統(tǒng)能否滿足他們的工作過程進行測試?；谶@批工作人員對人于工作業(yè)的過程十分理解，如果系統(tǒng)未能提供一些他們操作過程中的日常工作，他們會要求技術人員對系統(tǒng)進行修改。這個過程讓我們誤會用戶是對功能需求進行測試，這個誤會一直到今天讓我們把系統(tǒng)開發(fā)的焦點錯誤地放在功能上，而不是系統(tǒng)的最終交付上。而系統(tǒng)的最終交付是否能夠滿足ToR 的要求是當時項目成敗的主要指標。

　　系統(tǒng)集成的范圍及需求

　　20世紀70 年代的項目多以部門單獨運營為主，自動化的目的是提升部門本身的運營效率進行系統(tǒng)建設。到80 年代，企業(yè)高層開始體會企業(yè)中的數據分散在不同的部門或子公司的部門中。哪些數據是最新的?哪些是最準確的?應該采用哪個部門的數據做決定呢?如何整合這些數據，如何獲得即時的數據，如何利用當時的區(qū)際網絡(AreaNetwork)，客戶/服務端(Client/Server)，遙程存取(Remote‐Access)數據庫(Data Base)等科技來更有效提升企業(yè)的運營效率呢?這些問題提供軟件開發(fā)項目進行系統(tǒng)集成及數據分享的工作，最終的目的還是環(huán)繞原來自動化提升企業(yè)(不單是70 年代提升部門)的整體運營效率為主要目標。

　　這個時候，簡單的ToR 已經不能夠說明項目的范圍，但可以采用多個ToR 來加以說明。工作說明(Statement of Work)在這個時候誕生，開始取代ToR 成為項目范圍的主要工具。一個項目可能有多個Statement of Work(SOW)才能夠有效說明項目包含的范圍。例如要建立一個 “訂單管理系統(tǒng)(Order Processing System)”的時候，這個系統(tǒng)可能包括銷售部門，庫存管理部門，會計部門，運輸部門，生產部門等，這些部門也可能分布在不同的地區(qū)。

　　項目負責人首要是建立這個“訂單管理系統(tǒng)”的范圍，保證能夠提供訂單管理的的全部工作，所以會首先進行初步調查，理解一張訂單從不同業(yè)務點如何把訂單傳送回銷售部門，銷售部門如何把訂單信息轉進倉庫，如何結合現有庫存管理系統(tǒng)，如何通知會計部門有關銷售，如何通知運輸部門需要送貨，或者如何通知生產部門需要進行生產等內容。在與個別部門負責人完成初步訪談后會，理解訂單在各個部門的進入點和輸出點后才建立這個項目的工作說明(SOWs)如下：

　　SOW‐1: 連接業(yè)務點各終端到銷售系統(tǒng)，建立當天的銷售記錄。

　　SOW‐2: 連接銷售系統(tǒng)與庫存管理系統(tǒng)，容許銷售部門查詢倉庫管理系統(tǒng)中有關貨品庫存量。

　　SOW‐3: 容許銷售部門在庫存系統(tǒng)中預訂貨品數量以便運送到客戶指定地點。

　　SOW‐4: 容許銷售部門指示庫存工作人員進行檢貨，并通知運輸部門有關訂單的運送要求。

　　SOW‐5: 在銷售部門計算有關訂單的總金額，運送費及保險費用，并生成發(fā)票送交客戶。

　　SOW‐6: 自動更新倉庫貨品儲存量，如有關貨品低于最低數時，建立貨品生產通知單并傳送到生產規(guī)劃部。

　　SOW‐7: 自動通知業(yè)務點有關訂單發(fā)貨日期。

　　SOW‐8: 有關發(fā)票內容自動轉發(fā)會計部門，建立有關應收賬款記錄。

　　SOW 并不是我們所說的系統(tǒng)功能，是在項目完結后這個系統(tǒng)所應該提供的最終目的。以上的SOW 說明了這個項目的范圍，包括的有關部門及現有系統(tǒng)的連接。在客戶確認后每一個SOW 將當作一個ToR處理，這個ToR 便成為整個系統(tǒng)建設項目中的一個子項目(也是子項目名稱的起源)。如何才知道我們建立的SOW 已經包含整個系統(tǒng)的各個部門，如何保證這個范圍能夠有效地提供一套“訂單管理”的系統(tǒng)，這需要項目負責人對行業(yè)有一定的理解，同時為保證開發(fā)過程中能夠控制范圍的變動，在有關文檔中明確說明SOW 所包含或不包含那些工作。利用“包含(Inclusive)”和“不包含(Exclusive)”的說明來牢牢地建立一個固定項目范圍。

　　在項目規(guī)劃完成后，系統(tǒng)分析師便按照被分派的SOW 采用ToR 的調查方式進行深入調查，對有關工作進行訪談，理解有關SOW 的工作流程后對有關流程進行分析，并找尋初步的解決方案。如何利用科技取代電話咨詢庫存量，利用科技取代傳真把訂單從業(yè)務部門傳送回銷售部門，或取代傳真送貨通知單到運輸部門，取代內部文件傳送發(fā)票副本到會計部門等等工作，什么時候需要進行數據收集，需要進行數據更新，需要打印發(fā)票或其它有關報告等工作便成為項目的功能需求。

　　如果在開發(fā)過程中，用戶認為需要貨品在運送完畢后，收貨單應該自動確認有關應收賬款的作業(yè)流程，或者需要增加萬一退貨后的訂單處理操作流程時，我們便可以依據原SOW 來控制項目的范圍變動，因為這兩項操作流程并沒有在項目的SOW 中說明。如果用戶認為一定需要增加這兩個操作流程，那么項目的范圍會變動，帶出額外的工作量，額外的開發(fā)時間，額外的投資預算，修正系統(tǒng)的架構，增加軟件模塊，追加人力資源等等因應的后果。有能力的項目負責人會盡量說服客戶把有關工作在目前的系統(tǒng)建設完成后才進行處理，避免延誤項目的進度和交付日期。

　　這個系統(tǒng)集成的項目再一次說明如何從項目范圍中建立有關功能需求。建立功能需求是軟件從業(yè)人員的責任，不是客戶或用戶能夠提供的內容。在完成人工操作過程分析訂立系統(tǒng)的功能需求后，更要進一步考慮如何讓科技提升企業(yè)的運營效率。也許在設計過程中發(fā)現當時的貨品運送流程是從倉庫直接送到銷售部門，再由銷售部門安排貨品連同發(fā)票一起送到客戶的指定地點，設計師可能考慮是否可以直接從倉庫把貨品運送到客戶指定地點，銷售部門另外把有關發(fā)票直接送交客戶?這個改變會為企業(yè)帶來多大效率改善?有了確實的構思后便需要說服用戶這個系統(tǒng)如何能夠更有效地完成有關貨品運送的過程，要說服用戶這些功能可以提升貨品運送的效率和客戶滿意度，讓銷售部門和運輸部門可以體會未來的工作流程將有所改變。決定最終解決方案及用戶認可后依據分析師的建議建立有關系統(tǒng)的功能，交由系統(tǒng)設計師對有關功能進行模塊組合及邏輯設計。到這里，我們可以清楚知道系統(tǒng)建設不是依據客戶的需求而建設，是依據如何達到項目最終目的和項目的最終交付而建設。需求不是客戶或用戶提供，是我們作為一個專業(yè)人員依據我們要開發(fā)的項目目標(如何達到)和項目的最終交付而制定出來的結果。沒有項目范圍，我們便不能建立有關系統(tǒng)的功能。沒有項目范圍，我們便不能控制任務的工作量，不能預估完成日期并按時完成。
從上述兩個例子中可以看到，功能需求與業(yè)務流程直接相連的，理解了業(yè)務流程，便能夠建立有關的功能需求，利用科技完成有關工作，提升運營效率，減低業(yè)務部門有關工作量和工作人員的需求。