基于構件技術(shù)的需求過(guò)程與傳統的需求過(guò)程有著(zhù)非常大的區別，在傳統的需求過(guò)程之中，更多的是強調需求溝通技巧，而基于構件技術(shù)的需求過(guò)程則是強調需求復用，很多項目管理人員把滿(mǎn)足客戶(hù)需求與提高客戶(hù)滿(mǎn)意度對等起來(lái)，認為越多的滿(mǎn)足客戶(hù)需求，客戶(hù)滿(mǎn)意度就越高，我不認為是這樣的，原因如下：
客戶(hù)希望項目能夠完成，并且上線(xiàn)，產(chǎn)生一定的效益，如果這個(gè)不能保證，無(wú)限滿(mǎn)足客戶(hù)需求，也不能提高客戶(hù)滿(mǎn)意度。
項目負責人應該在滿(mǎn)足客戶(hù)需求和提高客戶(hù)滿(mǎn)意度這兩個(gè)既對立又統一的目標進(jìn)行平衡，通過(guò)科學(xué)量化的需求管理過(guò)程來(lái)實(shí)現其目標。
關(guān)于上述問(wèn)題我想單獨再提一個(gè)話(huà)題進(jìn)行說(shuō)明，這篇文章主要講的是基于構件技術(shù)的需求過(guò)程，以下則稱(chēng)“框架需求調研”：
框架需求調研的目的是： l 針對客戶(hù)的業(yè)務(wù)領(lǐng)域找到合適的業(yè)務(wù)領(lǐng)域模型。 l 確?？蛻?hù)、最終用戶(hù)和開(kāi)發(fā)人員就項目需求在合同的基礎上進(jìn)一步達成共識。 l 導出支持目標組織業(yè)務(wù)所需的項目需求，并分解成構件，包括已有構件清單、采購構件清單、開(kāi)發(fā)構件清單，另外還包括不屬于構件范疇之內的其它需求，如設計約束、性能需求、標準需求等。 l 與客戶(hù)和其他涉眾在需要開(kāi)發(fā)的構件需求方面達成并保持一致。 l 使系統開(kāi)發(fā)人員能夠更清楚地了解構件需求。 l 為估算開(kāi)發(fā)構件系統和測試集成所需成本和時(shí)間提供基礎。 l 定義新開(kāi)發(fā)構件的用戶(hù)界面，重點(diǎn)是用戶(hù)的需要和目標。 為實(shí)現這些目標，框架需求調工作流程說(shuō)明了如何采用新的業(yè)務(wù)構件來(lái)改變以前傳統的工作模式，并確定該業(yè)務(wù)模型之中所需要的功能（流程）、角色（崗位）、權限（職責范圍），并舉例說(shuō)明采用了信息化的業(yè)務(wù)構件之后的工作流程。 框架需求調研階段的工作流程包括初步需求整理、搭建構件演示環(huán)境、構件需求調研準備工作、展開(kāi)調研工作、調研結果的整理、需求評審、客戶(hù)確認。如下所示： 目的： l 以合同為藍本，對項目需求進(jìn)行深入溝通 l 將客戶(hù)對目標應用系統的框架需求文檔化，便于達成共識； l 分析出已有構件、外協(xié)構件、開(kāi)發(fā)構件，從而評估應用系統規模； l 根據應用系統規模來(lái)評估該應用系統的成本和初步的項目進(jìn)度； 如何配備人員： 團隊負責人需要完成框架需求的整理工作，整理工作的結果是《框架需求說(shuō)明書(shū)》，團隊負責人可以在構件咨詢(xún)員的協(xié)助下完成該項工作，如果項目規模較大，構件咨詢(xún)員可以直接參與并主導該項工作，團隊負責人需要對該客戶(hù)的業(yè)務(wù)領(lǐng)域有較深的理解。 工作指南： 根據構件資源庫以及構件發(fā)布清單來(lái)確定客戶(hù)哪些需求是可以采用構件予以滿(mǎn)足，這部分形成已有構件清單，不能滿(mǎn)足的需求則需要考察構件資源合作伙伴是否有外協(xié)的構件清單，如果沒(méi)有，則需要自行開(kāi)發(fā)新的構件。 針對構件發(fā)布狀態(tài)清單，對于低穩定性的構件應予以?xún)?yōu)先升級。 所有的構件清單分類(lèi)非常清晰之后，團隊負責人應該邀請公司內部有項目經(jīng)驗的人員對該項目予以評審，評審的重點(diǎn)是構件清單選擇是否合適，業(yè)務(wù)需求差異是否大到足夠要開(kāi)發(fā)一個(gè)新的構件，還是在原有的構件上予以升級。 可應用以下技巧示例來(lái)幫助團隊負責人收集正確、相關(guān)的信息： l 集體討論并整理提議 l 制作示意板 l 角色扮演 目的： l 快速構件目標應用系統，爭取市場(chǎng)訂單； l 通過(guò)演示環(huán)境使客戶(hù)快速對目標應用系統有了非常深刻的理解； l 縮短對目標應用系統理解的時(shí)間，客戶(hù)可以直接操作，甚至可以直接部署安裝； 如何配備人員： 構件測試集成人員根據已有構件清單來(lái)搭建該演示環(huán)境，并由團隊負責人組織演示數據。 工作指南： 演示數據應該貼近客戶(hù)實(shí)際情況，如果不了解客戶(hù)實(shí)際情況，則采用通用的演示數據。 如果項目涉及面廣，則可以同步制作PPT，通過(guò)會(huì )議形式進(jìn)行演示，在向客戶(hù)進(jìn)行演示時(shí)應該注重說(shuō)明這是一個(gè)可運行的目標應用系統，而不是說(shuō)明讓客戶(hù)看這還需要哪些改進(jìn)，應該將提意見(jiàn)的重點(diǎn)部分放在新開(kāi)發(fā)的構件或擬定要升級的構件之中。 搭建的目標應用系統如果溝通情況良好，則可以直接組織培訓和運行，需要進(jìn)行新開(kāi)發(fā)的構件則后期通過(guò)構件集成方式進(jìn)行集成到運行環(huán)境之中。 可應用以下技巧示例來(lái)幫助團隊負責人收集正確、相關(guān)的信息： l 進(jìn)行演示會(huì )議 目的： l 為深入了解需求制作調研工具，包括調研表格、原型系統、調研問(wèn)卷； 如何配備人員： 團隊負責人和資深的構件開(kāi)發(fā)人員可以擔當此工作任務(wù)，最好是開(kāi)發(fā)該業(yè)務(wù)構件的開(kāi)發(fā)人員，進(jìn)行需求調研的準備工作人員應該具備項目調研工作經(jīng)驗和新開(kāi)發(fā)或升級構件的業(yè)務(wù)領(lǐng)域知識，懂得如何制定項目調研表格。 工作指南： 根據開(kāi)發(fā)構件業(yè)務(wù)清單和業(yè)務(wù)構件建模文檔來(lái)制定項目所有的新開(kāi)發(fā)/升級構件的調研表格，所有的調研表格必須以最終用戶(hù)進(jìn)行分類(lèi)，不要讓最終用戶(hù)分開(kāi)填多個(gè)調研表格。 團隊負責人協(xié)調美工制作人員進(jìn)行原型系統的設計，原型系統的設計應該遵守《構件設計開(kāi)發(fā)標準》和《構件互操作性及界面標準》。 團隊負責人也可以從公司歷史項目之中找到一些案例，并修改一下界面或在網(wǎng)上找到其它公司的產(chǎn)品進(jìn)行說(shuō)明。 可應用以下技巧示例來(lái)幫助團隊負責人收集正確、相關(guān)的信息： l 集體討論并整理提議 l 魚(yú)刺圖 l Pareto 圖 目的： l 深入了解需求，與客戶(hù)達成一致的需求理解； l 擴大項目在客戶(hù)方的影響； 如何配備人員： 團隊負責人、構件咨詢(xún)員、資深的構件開(kāi)發(fā)人員可以擔當此工作任務(wù)，如果能事先指派構件開(kāi)發(fā)人員，則可以直接委派該開(kāi)發(fā)人員參與調研工作； 工作指南： 項目調研人員應該能充分利用調研工具與客戶(hù)進(jìn)行交流，但每次交流項目調研人員都有非常明確的目的，而不是漫無(wú)目的的交流，比如說(shuō)你們的網(wǎng)絡(luò )結構是什么樣的？目前有什么應用系統，為確保每次交流都是富有成效，所以項目調研人員必須對每次交流做好充分的準備。 調研過(guò)程應該可以采用筆記、錄音等方式，以便于調研完成之后進(jìn)行調研結果的整理； 可應用以下技巧示例來(lái)幫助團隊負責人收集正確、相關(guān)的信息： l 訪(fǎng)談 l 演示會(huì )議 l 需求研討班 目的： l 形成書(shū)面的需求文檔，以便于內部評審以及客戶(hù)達成一致； l 更新業(yè)務(wù)構件建模文檔，為將來(lái)設計業(yè)務(wù)構件做好準備； 如何配備人員： 團隊負責人、構件咨詢(xún)員、資深的構件開(kāi)發(fā)人員可以擔當此工作任務(wù)，如果能事先指派構件開(kāi)發(fā)人員，則可以直接委派該開(kāi)發(fā)人員參與調研結果的整理； 工作指南： 項目調研人員應該立刻記錄下調研的信息，以免長(cháng)時(shí)間調研會(huì )遺漏細節，需求調研以構件為基礎，所以需求文檔應該包括業(yè)務(wù)構件需求和其它需求，業(yè)務(wù)構件需求應該直接引用更新了的業(yè)務(wù)構件建模文檔，其它需求主要是環(huán)境方面的需求，如數據庫環(huán)境、部署范圍等等； 對所有的業(yè)務(wù)構件需求整理完畢之后，應該邀請有經(jīng)驗的人員對該系統進(jìn)行需求評審，以有利于項目商務(wù)工作和業(yè)務(wù)構件的積累。 需求整理完畢之后，應該形成客戶(hù)可以簽署確認的文檔，此份文檔可根據國標或者其它軟件工程方法學(xué)之中的需求文檔編寫(xiě)，但在以下方面應該做調整： 1、 以業(yè)務(wù)構件為基礎的需求文檔； 2、 應該添加客戶(hù)可簽署確認的位置； 目的： l 對需求的充分性、合理性、確切性進(jìn)行全面評審； l 對項目復用程度進(jìn)行評審； l 建立需求變更管理配置環(huán)境 如何配備人員： 團隊負責人提交需求評審申請，公司可組織專(zhuān)家委員會(huì )對其進(jìn)行評審； 工作指南： 每一條需求應該是可以實(shí)現的、確切的，且對客戶(hù)產(chǎn)生了價(jià)值，并具備充分性、合理性。 需求評審的過(guò)程也是對需求難易程度、優(yōu)先級、工作量等指標進(jìn)行排序的過(guò)程。 在公司的構件資產(chǎn)之中找到合適的構件來(lái)滿(mǎn)足項目需求，從而增加項目復用度，加速項目實(shí)施。
聯(lián)系客服
