歷盡千辛萬苦，終于簽署合同，IT供應商拿到了用戶提供的幾頁“需求書”;然后就憑借自己的理解立即投入開發(fā)，等生米熬成粥才發(fā)現滿足不了用戶需求，接下來就是艱難、反復地修改，最后開發(fā)人員厭倦了，用戶也厭倦了，當然項目款也遙遙無期。這樣的案例可謂比比皆是!
比起不成功的項目，一個成功的項目在開發(fā)者和客戶之間往往采取了更多交流方式;IT供應商不僅與終端用戶或潛在用戶群交流，而且對用戶感性、樸素的認識進行抽象，提取出潛在邏輯關系，準確把握客戶的真正需求，然后才進行軟件開發(fā)。
作為項目開發(fā)者和最終用戶之間的“橋梁”，CIO如何推進開發(fā)人員和終端用戶的“對接”?如何從用戶籠統(tǒng)、感性的描述中抽象出潛在邏輯關系?
1、撥開需求“迷霧”
業(yè)務部門的主管甚至CIO經常試圖代替終端用戶說話，但通常又無法準確說明“用戶需求”。用戶需求來自產品的真正使用者，必須讓實際用戶參與到收集需求的過程中;否則，產品很可能會因缺乏足夠的信息而遺留不少隱患。
需求分析是軟件開發(fā)和項目管理的基礎，但業(yè)務部門經常三言五語就把開發(fā)人員“打發(fā)”了，業(yè)務人員籠統(tǒng)、感性的描述對開發(fā)人員來說就像“霧里看花”，一些開發(fā)人員只好按照自己的理解去寫CODE。要撥開需求分析的“迷霧”，就要先了解需求分析的“程序”。
需求分析包括業(yè)務需求、用戶需求、功能需求、非功能性需求和需求分析報告等。業(yè)務需求反映了組織機構或客戶對系統(tǒng)、產品高層次的目標要求，通常在項目定義與范圍文檔中予以說明;用戶需求描述了用戶使用產品必須要完成的任務，應在使用實例或方案腳本中予以說明;功能需求定義了開發(fā)人員必須實現的軟件功能，使用戶利用系統(tǒng)能夠完成他們的任務，從而滿足業(yè)務需求;非功能性的需求描述了系統(tǒng)展現給用戶的行為和執(zhí)行的操作等，它包括產品必須遵從的標準、規(guī)范和約束，操作界面的具體細節(jié)和構造上的限制等;需求分析報告所說明的功能需求充分描述了軟件系統(tǒng)所應具有的外部行為，在開發(fā)、測試、質量保證、項目管理以及相關項目功能中起著重要作用。
業(yè)務部門的主管通常闡明“業(yè)務需求”，即產品的高層次概念和主要業(yè)務內容，為后繼工作建立指導性框架;但“業(yè)務需求”并不能為開發(fā)人員提供開發(fā)所需的許多細節(jié)說明?！坝脩粜枨蟆北仨氄蚁到y(tǒng)的最終使用者，他們最清楚要使用該產品完成什么任務和一些非功能性的特性需求，如程序的易用性、健壯性和可靠性等，而這些特性將會使用戶很好地接受具有該特點的軟件產品。業(yè)務部門的主管甚至CIO經常試圖代替終端用戶說話，但通常又無法準確說明“用戶需求”。用戶需求來自產品的真正使用者，必須讓實際用戶參與到收集需求的過程中;否則，產品很可能會因缺乏足夠的信息而遺留不少隱患。
在實際需求分析過程中，由于業(yè)務部門工作很忙，經常沒有時間或者覺得沒有必要與IT人員討論需求分析，有時甚至希望IT人員無須討論和編寫需求說明就能說出用戶的需求。除非遇到的需求極為簡單;否則千萬不能這樣做。
優(yōu)秀的軟件產品建立在優(yōu)秀的需求分析基礎上，而優(yōu)秀的需求分析又源于客戶與開發(fā)人員之間有效的交流和合作。只有雙方參與者都明白自己需要什么、成功的合作需要什么時，才能建立起一種良好的合作關系。
2、十項基本法則
如果CIO嘗試著問一些愚蠢問題，例如：“以我的理解，你們收到訂單后，會……”。業(yè)務人員立刻就會指出你的錯誤，并開始滔滔不絕談論業(yè)務，這一招就叫“拋磚引玉”。
開發(fā)人員與業(yè)務部門的交流需要好的方法。下