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

1、減低開發(fā)過程中的變動依賴項目范圍管理作者：黃紹良來源：希賽網(wǎng)摘要：在上世紀70 年代后期，系統(tǒng)分析師、系統(tǒng)設(shè)計師，和其他從事軟件工程的專業(yè)人員一直爭取希望能夠有一個國際公認的資格，類似會計師、律師、建筑師等專業(yè)的地位，但到了80 年代中期，這個議題已經(jīng)不再存在，主要的原因是軟件工程內(nèi)包含太多專業(yè)，除了軟件和硬件兩大類之外，還漸漸包括網(wǎng)絡(luò)，通信，數(shù)據(jù)庫等多方面。在上世紀70 年代后期，系統(tǒng)分析師、系統(tǒng)設(shè)計師，和其他從事軟件工程的專業(yè)人員一直爭取希望能夠有一個國際公認的資格，類似會計師、律師、建筑師等專業(yè)的地位，但到了80 年代中期，這個議題已經(jīng)不再存在，主要的原因是軟件工程內(nèi)包含太多專業(yè)，除了軟

2、件和硬件兩大類之外，還漸漸包括網(wǎng)絡(luò)，通信，數(shù)據(jù)庫等多方面。計算機從業(yè)人員開始體會及認識到本身的工作與會計師、律師、建筑師等專業(yè)資格可以在考核及認證后授予一定的權(quán)責，和建立一套環(huán)球衡量標準的模式是不一樣的。其實軟件工程比較像藝術(shù)家，大部份的軟件是模仿別人的成果加以個別的應(yīng)用需求進行個性化的結(jié)果，把思維轉(zhuǎn)變成交付成果的一門專業(yè)。過去數(shù)年常聽到一些軟件從業(yè)人員的投訴包括：“他們（客戶）基本上不知道自己的需求，怎么做他們都不滿意，功能不斷增加，如何能夠完成他們的系統(tǒng)建設(shè)？”“他們（客戶）上周說要這個功能，今天說要這個功能，為什么不全告訴我們，讓我們可以不用在開發(fā)過程中不斷更改！”一些類似的投訴只說明我

3、們的軟件從業(yè)人員基本上沒有明白到范圍建設(shè)的重要性，而且未能在項目啟動前把項目范圍建立起來。范圍與功能的分別在“如何把握不存在的需求”一文中，已經(jīng)說明范圍是有效管理需求變更的唯一方法。有明確的項目范圍，我們才能夠?qū)W習及分析范圍內(nèi)的作業(yè)流程，建立系統(tǒng)的功能需求，并在開發(fā)過程中當客戶要求變動的時候有效管理我們的工作范圍，才能夠有機會按照預(yù)算在指定的時間內(nèi)完成項目的交付。軟件開發(fā)項目從開始到今天，一直以來客戶都不能夠告訴我們需要哪些功能，他們只能告訴我們系統(tǒng)需要完成哪些目標?；仡櫋叭绾伟盐詹淮嬖诘男枨蟆币晃闹械牡谝粋€例子，20世紀70 年代的客戶需要把庫存管理進行自動化，收到的指示會像下例：“建立一套

4、庫存管理系統(tǒng)取代目前的人工作業(yè)流程”。這一句指示是唯一任務(wù)說明。系統(tǒng)分析員在接受這個任務(wù)后第一個工作是建立項目的Term of Reference （ToR）。系統(tǒng)分析員會進行初步調(diào)查，通過簡單的訪談，與庫存部門負責人明確理解他們工作的開始點和終結(jié)點，得出的結(jié)果可能像下例：“從貨品（包括原材料，半成品及制成品）進入倉庫開始，到貨品因應(yīng)生產(chǎn)或銷售申領(lǐng)要求離開倉庫為止，其中包括貨品存入量的統(tǒng)計，存放位置記錄，總庫存量統(tǒng)計，申領(lǐng)數(shù)目，檢貨，提取貨品，準備出倉，最后更新貨品存量統(tǒng)計等工作過程”。這是所謂的Term of Reference，也是我們今天所認識的項目范圍。在用戶及管理層認同上述的ToR

5、后，這個項目的負責人便需要估計需要對多少人進行訪談，需要多久時間進行訪談，需要多少時間對訪談結(jié)果進行分析，多少時間建立項目需求，編寫需求說明書，需要多久進行系統(tǒng)設(shè)計，多少程序員及多少時間進行程序編寫，如何進行測試，編寫系統(tǒng)文檔，編寫用戶手冊，什么時候在倉庫安裝終端，如何連接主機，什么時候進行用戶培訓，如何讓系統(tǒng)取代目前的人工作業(yè)等等有關(guān)工作計劃及時間表。在系統(tǒng)分析員完成訪談后，便需要依據(jù)訪談結(jié)果進行分析，理解什么時候知道有貨品進入倉庫，什么時候更新有關(guān)數(shù)據(jù)，如何更新，采用哪些表單，倉庫人員如何決定貨品應(yīng)該存放在哪里，如何記錄有關(guān)信息，如何知道需要檢貨，什么時候進行數(shù)據(jù)更新，如何分別哪些貨品要去

6、生產(chǎn)部門或者直接送到客戶指定地點等等信息。這些信息便成為系統(tǒng)在不同過程中所需的功能需求。從上述的開發(fā)過程說明中可以體現(xiàn)功能需求并不是客戶或用戶提供，是系統(tǒng)分析員在理解目前的人工作業(yè)后分析出來的結(jié)果。在系統(tǒng)移交到倉庫中運行前，倉庫中的工作人員需要對系統(tǒng)的操作進行學習及測試。要知道當時倉庫的工作人員并不是針對系統(tǒng)的功能進行測試，是對系統(tǒng)能否滿足他們的工作過程進行測試?；谶@批工作人員對人于工作業(yè)的過程十分理解，如果系統(tǒng)未能提供一些他們操作過程中的日常工作，他們會要求技術(shù)人員對系統(tǒng)進行修改。這個過程讓我們誤會用戶是對功能需求進行測試，這個誤會一直到今天讓我們把系統(tǒng)開發(fā)的焦點錯誤地放在功能上，而不是系

7、統(tǒng)的最終交付上。而系統(tǒng)的最終交付是否能夠滿足ToR 的要求是當時項目成敗的主要指標。系統(tǒng)集成的范圍及需求20世紀70 年代的項目多以部門單獨運營為主，自動化的目的是提升部門本身的運營效率進行系統(tǒng)建設(shè)。到80 年代，企業(yè)高層開始體會企業(yè)中的數(shù)據(jù)分散在不同的部門或子公司的部門中。哪些數(shù)據(jù)是最新的？哪些是最準確的？應(yīng)該采用哪個部門的數(shù)據(jù)做決定呢？如何整合這些數(shù)據(jù)，如何獲得即時的數(shù)據(jù)，如何利用當時的區(qū)際網(wǎng)絡(luò)（AreaNetwork），客戶/服務(wù)端（Client/Server），遙程存?。≧emoteAccess）數(shù)據(jù)庫（Data Base）等科技來更有效提升企業(yè)的運營效率呢？這些問題提供軟件開發(fā)項目進

8、行系統(tǒng)集成及數(shù)據(jù)分享的工作，最終的目的還是環(huán)繞原來自動化提升企業(yè)（不單是70 年代提升部門）的整體運營效率為主要目標。這個時候，簡單的ToR 已經(jīng)不能夠說明項目的范圍，但可以采用多個ToR 來加以說明。工作說明（Statement of Work）在這個時候誕生，開始取代ToR 成為項目范圍的主要工具。一個項目可能有多個Statement of Work（SOW）才能夠有效說明項目包含的范圍。例如要建立一個 “訂單管理系統(tǒng)（Order Processing System）”的時候，這個系統(tǒng)可能包括銷售部門，庫存管理部門，會計部門，運輸部門，生產(chǎn)部門等，這些部門也可能分布在不同的地區(qū)。項目負責人

9、首要是建立這個“訂單管理系統(tǒng)”的范圍，保證能夠提供訂單管理的的全部工作，所以會首先進行初步調(diào)查，理解一張訂單從不同業(yè)務(wù)點如何把訂單傳送回銷售部門，銷售部門如何把訂單信息轉(zhuǎn)進倉庫，如何結(jié)合現(xiàn)有庫存管理系統(tǒng)，如何通知會計部門有關(guān)銷售，如何通知運輸部門需要送貨，或者如何通知生產(chǎn)部門需要進行生產(chǎn)等內(nèi)容。在與個別部門負責人完成初步訪談后會，理解訂單在各個部門的進入點和輸出點后才建立這個項目的工作說明（SOWs）如下：SOW1： 連接業(yè)務(wù)點各終端到銷售系統(tǒng)，建立當天的銷售記錄。SOW2： 連接銷售系統(tǒng)與庫存管理系統(tǒng)，容許銷售部門查詢倉庫管理系統(tǒng)中有關(guān)貨品庫存量。SOW3： 容許銷售部門在庫存系統(tǒng)中預(yù)訂貨品

10、數(shù)量以便運送到客戶指定地點。SOW4： 容許銷售部門指示庫存工作人員進行檢貨，并通知運輸部門有關(guān)訂單的運送要求。SOW5： 在銷售部門計算有關(guān)訂單的總金額，運送費及保險費用，并生成發(fā)票送交客戶。SOW6： 自動更新倉庫貨品儲存量，如有關(guān)貨品低于最低數(shù)時，建立貨品生產(chǎn)通知單并傳送到生產(chǎn)規(guī)劃部。SOW7： 自動通知業(yè)務(wù)點有關(guān)訂單發(fā)貨日期。SOW8： 有關(guān)發(fā)票內(nèi)容自動轉(zhuǎn)發(fā)會計部門，建立有關(guān)應(yīng)收賬款記錄。SOW 并不是我們所說的系統(tǒng)功能，是在項目完結(jié)后這個系統(tǒng)所應(yīng)該提供的最終目的。以上的SOW 說明了這個項目的范圍，包括的有關(guān)部門及現(xiàn)有系統(tǒng)的連接。在客戶確認后每一個SOW 將當作一個ToR處理，這個T

11、oR 便成為整個系統(tǒng)建設(shè)項目中的一個子項目（也是子項目名稱的起源）。如何才知道我們建立的SOW 已經(jīng)包含整個系統(tǒng)的各個部門，如何保證這個范圍能夠有效地提供一套“訂單管理”的系統(tǒng)，這需要項目負責人對行業(yè)有一定的理解，同時為保證開發(fā)過程中能夠控制范圍的變動，在有關(guān)文檔中明確說明SOW 所包含或不包含那些工作。利用“包含（Inclusive）”和“不包含（Exclusive）”的說明來牢牢地建立一個固定項目范圍。在項目規(guī)劃完成后，系統(tǒng)分析師便按照被分派的SOW 采用ToR 的調(diào)查方式進行深入調(diào)查，對有關(guān)工作進行訪談，理解有關(guān)SOW 的工作流程后對有關(guān)流程進行分析，并找尋初步的解決方案。如何利用科技取

12、代電話咨詢庫存量，利用科技取代傳真把訂單從業(yè)務(wù)部門傳送回銷售部門，或取代傳真送貨通知單到運輸部門，取代內(nèi)部文件傳送發(fā)票副本到會計部門等等工作，什么時候需要進行數(shù)據(jù)收集，需要進行數(shù)據(jù)更新，需要打印發(fā)票或其它有關(guān)報告等工作便成為項目的功能需求。如果在開發(fā)過程中，用戶認為需要貨品在運送完畢后，收貨單應(yīng)該自動確認有關(guān)應(yīng)收賬款的作業(yè)流程，或者需要增加萬一退貨后的訂單處理操作流程時，我們便可以依據(jù)原SOW 來控制項目的范圍變動，因為這兩項操作流程并沒有在項目的SOW 中說明。如果用戶認為一定需要增加這兩個操作流程，那么項目的范圍會變動，帶出額外的工作量，額外的開發(fā)時間，額外的投資預(yù)算，修正系統(tǒng)的架構(gòu)，增加

13、軟件模塊，追加人力資源等等因應(yīng)的后果。有能力的項目負責人會盡量說服客戶把有關(guān)工作在目前的系統(tǒng)建設(shè)完成后才進行處理，避免延誤項目的進度和交付日期。這個系統(tǒng)集成的項目再一次說明如何從項目范圍中建立有關(guān)功能需求。建立功能需求是軟件從業(yè)人員的責任，不是客戶或用戶能夠提供的內(nèi)容。在完成人工操作過程分析訂立系統(tǒng)的功能需求后，更要進一步考慮如何讓科技提升企業(yè)的運營效率。也許在設(shè)計過程中發(fā)現(xiàn)當時的貨品運送流程是從倉庫直接送到銷售部門，再由銷售部門安排貨品連同發(fā)票一起送到客戶的指定地點，設(shè)計師可能考慮是否可以直接從倉庫把貨品運送到客戶指定地點，銷售部門另外把有關(guān)發(fā)票直接送交客戶？這個改變會為企業(yè)帶來多大效率改善

14、？有了確實的構(gòu)思后便需要說服用戶這個系統(tǒng)如何能夠更有效地完成有關(guān)貨品運送的過程，要說服用戶這些功能可以提升貨品運送的效率和客戶滿意度，讓銷售部門和運輸部門可以體會未來的工作流程將有所改變。決定最終解決方案及用戶認可后依據(jù)分析師的建議建立有關(guān)系統(tǒng)的功能，交由系統(tǒng)設(shè)計師對有關(guān)功能進行模塊組合及邏輯設(shè)計。到這里，我們可以清楚知道系統(tǒng)建設(shè)不是依據(jù)客戶的需求而建設(shè)，是依據(jù)如何達到項目最終目的和項目的最終交付而建設(shè)。需求不是客戶或用戶提供，是我們作為一個專業(yè)人員依據(jù)我們要開發(fā)的項目目標（如何達到）和項目的最終交付而制定出來的結(jié)果。沒有項目范圍，我們便不能建立有關(guān)系統(tǒng)的功能。沒有項目范圍，我們便不能控制任務(wù)

15、的工作量，不能預(yù)估完成日期并按時完成。從上述兩個例子中可以看到，功能需求與業(yè)務(wù)流程直接相連的，理解了業(yè)務(wù)流程，便能夠建立有關(guān)的功能需求，利用科技完成有關(guān)工作，提升運營效率，減低業(yè)務(wù)部門有關(guān)工作量和工作人員的需求。軟件工匠和軟件工程師如果我們需要客戶提供有關(guān)功能或需求才能夠完成軟件開發(fā)，那么我們便淪為軟件工匠。一個工匠，如木匠、泥水匠等都是依據(jù)客戶的需求去完成任務(wù)的技術(shù)人員，這個工匠可以把工藝做到很好，很精，很細膩，成為一個很優(yōu)秀的木工或泥水工，但永遠不會成為大師，因為他們沒有創(chuàng)思，沒有溝通能力去說服客戶如何能夠更有效地達到客戶的投資目的。希賽顧問團首席顧問張友生博士認為，一個專業(yè)的技術(shù)人員需要

16、理解本身的專業(yè)能力，理解客戶投資的最終目的，理解如何更有效地達到客戶的最終目標而建議客戶應(yīng)該如何進行建設(shè)或改良，才有可能成為這個行業(yè)的大師。目前我國充斥著很多軟件工匠，如果我們要把自己打造成為一個軟件工程師，我們便需要放棄以前的思維，不用老是抱怨“客戶不明確本身的需求，所以我們不能夠完成項目的交付”。我們需要思考如何才能夠把握項目的最終目標，建立系統(tǒng)的功能需求。從20世紀90 年代中期開始，計算機在企業(yè)中已經(jīng)從自動化的時代進入信息化的時代，從科技的應(yīng)用提升企業(yè)的運營效率，轉(zhuǎn)變成科技應(yīng)用所能帶出來的價值，讓企業(yè)能夠減低運營成本，改善產(chǎn)品，提供增值服務(wù)，開拓市場，增加利潤等成為軟件開發(fā)的主要目標。

17、客戶在決定投資一套軟件系統(tǒng)建設(shè)的項目前，本身很明確知道希望這套系統(tǒng)能夠帶來什么價值，但對于如何能夠利用科技來達到目標則一概不清楚。希望透過軟件工程師的專業(yè)知識來告訴他們?nèi)绾尾拍軌驖M足他們的愿景，客戶希望透過人工智能（AI）去理解顧客的采購習慣，背景，行為和對現(xiàn)有產(chǎn)品的反饋對產(chǎn)品進行改良；他們希望透過企業(yè)資源規(guī)劃（ERP）來減低生產(chǎn)或運營成本，提升資源對企業(yè)的價值；希望透過客戶關(guān)系管理（CRM）軟件的應(yīng)用來保留顧客對企業(yè)品牌的忠誠，增加顧客對企業(yè)的滿意度。這些都是透過科技應(yīng)用所希望帶出來的普遍價值和投資愿景。但技術(shù)人員仍然停留在科技應(yīng)用的層面上，希望客戶能夠告訴他們需要那些功能來達到這個愿景，讓

18、他們能夠利用技術(shù)完成客戶的系統(tǒng)建設(shè)。這些構(gòu)思型或愿景型的項目如何進行交付，是上世紀末期開始對軟件行業(yè)的一大挑戰(zhàn)。在這種情況下，技術(shù)人員如何能夠滿足客戶的愿景，客戶如何能夠告訴技術(shù)人員有關(guān)這個投資項目的功能需求，變成項目在實施過程中不斷進行修改，不斷延誤的主要原因。如何解決這個困境是當時急迫需要處理的難題。所以計算機行業(yè)新增加了一個崗位，叫做業(yè)務(wù)分析師（Business Analyst 或簡稱BA），業(yè)務(wù)分析師應(yīng)該有深厚的行業(yè)知識，透過BA對行業(yè)的理解，對愿景項目進行流程分析及建設(shè)，然后讓技術(shù)人員對有關(guān)流程進行分析，建立功能需求，設(shè)計有關(guān)模塊，為這些構(gòu)思型或愿景型項目提供所需的基本信息。但可惜行

19、業(yè)知識與技術(shù)知識兩者還是有相當大的距離，BA 未能發(fā)揮應(yīng)有的效益。美國PMI 也是在這個時候訂立項目贊助人（Sponsor）及項目干系人（Stakeholders）的角色，在項目開發(fā)過程中，項目贊助人需要確認BA 的流程建議，需要取人系統(tǒng)建設(shè)每一個階段的交付。項目干系人需要確認流程及系統(tǒng)功能不會影響部門的正常操作，兩者要確保整個項目能夠達到預(yù)期的交付愿景和目的。應(yīng)用系統(tǒng)。希賽顧問團需求工程首席專家徐鋒認為，這些工具和方法誤導了這個行業(yè)的技術(shù)人員，讓他們在項目啟動的時候便把重心放在把握功能需求，而不是建立項目范圍，直到今天，很多軟件工匠在項目起動時便盡量希望能夠把握項目的功能需求，一些學者更把如

20、何把握需求當作教育重點來讓我們不斷培育軟件工匠。讓技術(shù)人員忘記了建立范圍的重要性，讓技術(shù)人員未能發(fā)揮本身的智慧，為客戶建立所需的解決方案，讓這些工匠不能夠有效地考慮如何利用科技來提供客戶期盼的價值，發(fā)揮本身的創(chuàng)作力和創(chuàng)思。智能讓技術(shù)人員不斷跟著客戶后追尋那些不存在的項目需求。軟件工程在21 世紀的挑戰(zhàn)在20世紀90 年代中期，互聯(lián)網(wǎng)與Windows開始進入個人及企業(yè)的空間。當時，筆者被任命為澳大利亞墨爾本市的一家百貨公司建立一套網(wǎng)絡(luò)銷售系統(tǒng)。當時我對互聯(lián)網(wǎng)的認識相當膚淺，如何完成這個任務(wù)對我及整個交付團隊是一個考驗。我花費大量精力及時間與客戶溝通，希望理解他們建立這套系統(tǒng)的背后目的，在過程中我們共同建立了一套假設(shè)的業(yè)務(wù)流程，因為雙方都不清楚顧客在網(wǎng)絡(luò)的另一端在過程中會有些什么反應(yīng)，所以我們依據(jù)不同的反應(yīng)建立