探究需求管理的本質(1)

2019-11-17 04:47:30

字體：大中小

來源：轉載

供稿：網友

概要

需求治理恰如裁縫的量體裁衣，它直接關系到最終產品的成型。僅從字面出發，假如一個產品滿足了客戶需求，那它無疑就是成功的。需求治理的過程，從需求分析開始貫穿整個項目始終，力圖實現最終產品同需求性的最佳結合（參見Figure 1）。通過對需求治理在項目進程中實施的不同任務進行分析，我們可以看出需求治理所起的作用。需求治理能夠確證： ●我們確知客戶的需求是什么（質量）； ●滿足客戶需求的最佳解決辦法（統一性）；探究需求治理的本質(1)（圖一）

聞名學者Crosby對于質量的定義是"同需求保持統一"。從這個意義上說，需求治理正是從質量出發以確定需求。每個人都應當始終明白他們所做的具體任務其意義何在。然而，在一個產品的生命周期里，其需求性是能動的，是處于變化之中的。對于系統工程沒有嚴格統一的定義，因此很難找到足夠的數據以說明系統工程所起的作用。有些致力于研究需求分析的組織認為，一項開發計劃應當至少將8-15%的資源投入到系統工程方面。假如低于這一標準，將很可能導致無法對客戶群做出準確把握。假如該項開發計劃含有許多創新或實驗的成分，那么這一百分比還應當適度提高。 需求治理所要完成的任務

可以說需求是一種模型，是產品的早期雛形，通過進行需求分析，我們可以對最終產品做出優化。需要始終保持注重的是，需求性是始終處于變化之中的。需求治理需要完成的任務包括： ●明確需求并達成共識； ●建立關聯； ●根據不同需求設計相應解決辦法； ●進行系統優化； ●提出設計方案； ●監控和解決可能出現的問題以及需要做出的改變； ●控制不同開發任務的開展； ●對最終產品做出評測； ●監控可能出現的重復開發； ●提出項目實施時間表； ●確定最終用戶界面。有時侯我們所進行的需求分析只停留于分析本身，而沒有進一步去思考我們為什么要進行需求分析。需求性是項目開發的源頭，只有進行認真的需求分析，我們才能做到對癥下藥、量體裁衣，才能才設計開發中去偽存真，不斷改進。"需求之需求"正是強調了貫穿始終的需求分析的重要。離開了能動的、變化的系統進程而空談需求治理，無異于紙上談兵。需求治理所產生的效益或許并不明顯，或許要日后才能體現，但是無序的，沒有經過精心策劃的需求治理是不可能產生效益的。以下篇幅分別介紹需求治理在系統工程中的不同應用。 需求共識：

首先，用戶需求通過非術語的形式進行表述，這種表述應當使每一位開發者明確自己的職責所在，并且清楚知道不同開發工作之間的關聯。這里的"用戶"泛指在實際應用環境中每一位可能使用最終產品的人。假如一個產品不能滿足客戶所需，那么設計方案再出色也無濟于事，許多方案有很高的技術設計水準卻最終不能獲得成功，其原因正在于此。可以把產品功能說得天花亂墜，但卻無法改變用戶需求決定最終產品基本模式的事實。探究需求治理的本質(1)（圖二）

需求治理的首要任務在于使開發人員和用戶雙方對于需求都有一個明確的熟悉。因此用來進行需求分析的語言組織應當使所有相關人員，包括用戶，都能夠理解，都能夠進而對整個項目有一個整體把握，并明確每一個人在項目中所起的作用。因而需求治理需要解決的第一位也是最基本的任務就是明確需求，并使所有相關人員達成共識。 根據需求設計解決辦法：

我們在進行系統設計時，應當首先建立一個需求模型，但不能是為了建模而建模，需求模型實際是最終產品的抽象化表現。需求模型的建立使我們在明確需求的基礎上更進一步，使我們知道我們將要生產何種產品，該產品都具有那些功能。同時，創建需求模型的過程也使開發者明確自己的工作如何同整個項目有機地結合在一起。建立需求模型應當充分研究不同類型、不同架構建模方式的可行性，切忌主觀武斷。 系統優化：

任何設計都應以考慮用戶需求為優先，用戶需求的滿足程度即成為衡量設計優劣的標準。在一個項目設計周期中，開發人員經常會面臨選擇，以提煉需求，決定開發的優先次序，并在不同的實施方案中作出選擇。這些選擇必須考慮到收益與付出地平衡比例，這種選擇的重要性尤其在建立需求模型的后期凸現出來。基本需求在這時都已明確，而實施方案還未敲定，為了使用戶的基本需求得到落實，一定程度的開銷用于搭建不同構架的需求模式是合理的。假使我們已經有了一套翔實的需求分析，我們甚至不必將每一套方案都付諸實行，就可以成功地對系統設計進行優化。探究需求治理的本質(1)（圖三）

面對不同的可行性而需要作出選擇時，我們也必須參照收益與付出的比例關系。例如，在被要求提供計劃書時（Request for PRoposal），我們應當盡量做到每一份計劃書的提供都物有所值。 方案設計：

明確需求后，開發人員就可以進行方案設計。通過對用戶需求和設計方案之間所存在關聯性進行分析比較，我們就能夠對設計方案進行評估。 必要的修改：

方案的設計不可能是一成不變的，經常會有方案設計同需求相悖的情況。假如我們無法準確把握用戶需求同方案設計之間的關系，我們就無法在需要對方案進行必要修改時正確判定。優秀的需求分析應當非常精確細致地對用戶需求作出描述，同時也應該最大程度地給予方案設計者充分發揮的余地。

任務劃分：

一個大的開發項目可能涉及20-30組不同的開發隊伍，人員包括技術工程師、軟件工程師以及具體項目主管等等，而每一個模塊都有它自己的開發工具和開發語言。

主持一個大項目的開發并不是件輕易的事，總體項目主管的首要任務是對開發項目進行任務劃分，將整體開發任務細化為多個子模塊，從而使這些子模塊能夠平行開發而無需太多的干預。總體項目主管可以將細化的不同模塊的需求分析交給不同的開發隊伍，對于開發進程的監控只需參照需求的解決情況，對于具體的開發細節則不必過問太多。
不同的開發隊伍會使用不同的開發語言和開發工具，會使用不同的符號和標記。相反，作為總體項目主管所使用的語言、符號和標記等則必須簡單易懂，以使所有的開發人員都等理解。換言之，總體項目主管應當使用自然語言，或只涉及少量的，簡單的術語和專用詞匯。 產品測試：

需求的滿足情況是決定最終產品成敗的判定基礎，對最終產品的測試評估必須以產品所試圖解決的需求為標準。下圖標示了不同的開發階段所對應的測試需求。

這里有一個需求、產品和測試系統之間的關系問題，確定需要進行的測試屬于總體開發主管的工作范疇，雖然具體工作并非都要由開發主管來親自完成。 重復開發：

對于總體開發主管而言，針對方案設計的修改是一項經常性的工作（因為修改而造成的影響則應當盡可能減小）。在進行項目開發時，隨著開發進程的深入，各種修改的建議和問題的報告是屢見不鮮的，每解決一個問題，就是將產品同其需求性的結合又完善了一步。存在問題正是需求性尚未滿足的表現。方案設計的完善和需求性的滿足是同步的，因此真正的用戶對于產品的評價和建議尤其具有重要意義。在那些一步到位的產品設計中，真正用戶無法左右開發進程；但在一個能夠進行重復設計、重復開發的產品生命期中，開發人員應當及時搜集用戶對于產品的反饋信息，并將這些信息結合到下一步的開發工作中去。如下圖所示，用戶反饋同產品開發是統一的。 QQRead.com 推出數據恢復指南教程數據恢復指南教程數據恢復故障解析常用數據恢復方案硬盤數據恢復教程數據保護方法數據恢復軟件專業數據恢復服務指南概要

需求治理恰如裁縫的量體裁衣，它直接關系到最終產品的成型。僅從字面出發，假如一個產品滿足了客戶需求，那它無疑就是成功的。需求治理的過程，從需求分析開始貫穿整個項目始終，力圖實現最終產品同需求性的最佳結合（參見Figure 1）。通過對需求治理在項目進程中實施的不同任務進行分析，我們可以看出需求治理所起的作用。需求治理能夠確證： ●我們確知客戶的需求是什么（質量）； ●滿足客戶需求的最佳解決辦法（統一性）；探究需求治理的本質(1)（圖一）

需求治理的首要任務在于使開發人員和用戶雙方對于需求都有一個明確的熟悉。因此用來進行需求分析的語言組織應當使所有相關人員，包括用戶，都能夠理解，都能夠進而對整個項目有一個整體把握，并明確每一個人在項目中所起的作用。因而需求治理需要解決的第一位也是最基本的任務就是明確需求，并使所有相關人員達成共識。 根據需求設計解決辦法：

我們在進行系統設計時，應當首先建立一個需求模型，但不能是為了建模而建模，需求模型實際是最終產品的抽象化表現。需求模型的建立使我們在明確需求的基礎上更進一步，使我們知道我們將要生產何種產品，該產品都具有那些功能。同時，創建需求模型的過程也使開發者明確自己的工作如何同整個項目有機地結合在一起。建立需求模型應當充分研究不同類型、不同架構建模方式的可行性，切忌主觀武斷。
系統優化：

任何設計都應以考慮用戶需求為優先，用戶需求的滿足程度即成為衡量設計優劣的標準。在一個項目設計周期中，開發人員經常會面臨選擇，以提煉需求，決定開發的優先次序，并在不同的實施方案中作出選擇。這些選擇必須考慮到收益與付出地平衡比例，這種選擇的重要性尤其在建立需求模型的后期凸現出來。基本需求在這時都已明確，而實施方案還未敲定，為了使用戶的基本需求得到落實，一定程度的開銷用于搭建不同構架的需求模式是合理的。假使我們已經有了一套翔實的需求分析，我們甚至不必將每一套方案都付諸實行，就可以成功地對系統設計進行優化。探究需求治理的本質(1)（圖三）

面對不同的可行性而需要作出選擇時，我們也必須參照收益與付出的比例關系。例如，在被要求提供計劃書時（Request for Proposal），我們應當盡量做到每一份計劃書的提供都物有所值。 方案設計：

明確需求后，開發人員就可以進行方案設計。通過對用戶需求和設計方案之間所存在關聯性進行分析比較，我們就能夠對設計方案進行評估。 必要的修改：

方案的設計不可能是一成不變的，經常會有方案設計同需求相悖的情況。假如我們無法準確把握用戶需求同方案設計之間的關系，我們就無法在需要對方案進行必要修改時正確判定。優秀的需求分析應當非常精確細致地對用戶需求作出描述，同時也應該最大程度地給予方案設計者充分發揮的余地。

任務劃分：

一個大的開發項目可能涉及20-30組不同的開發隊伍，人員包括技術工程師、軟件工程師以及具體項目主管等等，而每一個模塊都有它自己的開發工具和開發語言。

主持一個大項目的開發并不是件輕易的事，總體項目主管的首要任務是對開發項目進行任務劃分，將整體開發任務細化為多個子模塊，從而使這些子模塊能夠平行開發而無需太多的干預。總體項目主管可以將細化的不同模塊的需求分析交給不同的開發隊伍，對于開發進程的監控只需參照需求的解決情況，對于具體的開發細節則不必過問太多。不同的開發隊伍會使用不同的開發語言和開發工具，會使用不同的符號和標記。相反，作為總體項目主管所使用的語言、符號和標記等則必須簡單易懂，以使所有的開發人員都等理解。換言之，總體項目主管應當使用自然語言，或只涉及少量的，簡單的術語和專用詞匯。 產品測試：

需求的滿足情況是決定最終產品成敗的判定基礎，對最終產品的測試評估必須以產品所試圖解決的需求為標準。下圖標示了不同的開發階段所對應的測試需求。

這里有一個需求、產品和測試系統之間的關系問題，確定需要進行的測試屬于總體開發主管的工作范疇，雖然具體工作并非都要由開發主管來親自完成。 重復開發：

對于總體開發主管而言，針對方案設計的修改是一項經常性的工作（因為修改而造成的影響則應當盡可能減小）。在進行項目開發時，隨著開發進程的深入，各種修改的建議和問題的報告是屢見不鮮的，每解決一個問題，就是將產品同其需求性的結合又完善了一步。存在問題正是需求性尚未滿足的表現。方案設計的完善和需求性的滿足是同步的，因此真正的用戶對于產品的評價和建議尤其具有重要意義。在那些一步到位的產品設計中，真正用戶無法左右開發進程；但在一個能夠進行重復設計、重復開發的產品生命期中，開發人員應當及時搜集用戶對于產品的反饋信息，并將這些信息結合到下一步的開發工作中去。如下圖所示，用戶反饋同產品開發是統一的。

上一篇：利用數據綁定和模板創建Atlas應用程序

下一篇：BEA和Siebel聯合提供CRM軟件