1        項目過程

根據我們項目出現的問題，我自己的總結的一些經驗以及我在培訓中學習得知識總結下項目中遇到的問題和解決方案。

1.1     簽訂合同

我們項目的合同內主要寫的很模糊，范圍可大可小，致使我們在后期的工作中項目越做越大，但是項目費用是不變的。在國內的合同好像都是在打單時是基本上都承諾，也不會到細節(jié)，在合同簽訂后啟動后才發(fā)現問題。但合同中可以寫明如果需求變更什么級別的怎么樣，多少錢等;簽訂合同也是一個很高的技巧，建議把系統(tǒng)的邊界及功能范圍和解決方案與合同一起簽署，這樣客戶提出的新功能就可以暫且擱置。

1.2        團隊建設

 在立項后盡早確定該項目的負責人及項目經理，這個人員非常關鍵，需要很強的綜合能力，尤其的人格魅力方面。盡最大的努力將客戶的人員加入到我們的項目團隊來，這個人也是我們將來和客戶的統(tǒng)一聯(lián)系人，客戶指定一個人和項目組進行溝通，不能是張領導、王領導都來說幾句，如果他們意見不一致，那你只有得罪領導的選擇了，所以，項目的最初就要定好規(guī)矩，項目組只認一個的意見，有什么要求你們內部先統(tǒng)一再和項目組談，我們不想卷入客戶內部業(yè)務部門之間的矛盾和政治斗爭之中。很多項目經理都沒有自己選擇組員的權利，那么，就盡量發(fā)揮你的影響力去尋找那些你想要的人吧。成員的組成根據項目不同，相差較大，很難有什么具體要求，但是，一定要有精通客戶業(yè)務的人，很多小項目里，這個人就是項目經理本人，大項目里會配備行業(yè)專家（Industry expert），這樣和客戶溝通起來才不會雞同鴨講，雙方才可以相互理解。項目經理需要了解每個組員的情況，用就要用每個員工的特長。軟件行業(yè)是個非常特殊的行業(yè)，從項目的管理以及人員的管理都有它的特殊性。

作為項目經理，其實腦子里就是幾樣東西：做哪些事情、做到什么程度、怎么交貨、手上的資源以及各個事情的優(yōu)先級。所謂多快好省那是人類的夢想，這四個方面都是相互矛盾的，屬于典型的又要馬兒跑，又要馬兒不吃草的類型。考慮問題的輕重緩急方面，往往是把快放在第一位，各方領導都會給你最后期限，所以保進度是第一位的；省是第二位的，企業(yè)的根本目的是盈利，如果收入不能增加的話，至少費用要控制?。缓檬堑谌坏?，沒辦法，誰都想精益求精，但是，沒有強大的資源保障，質量只好先犧牲了；最后是多，客戶的要求源源不斷，如何降低客戶的期望值，讓他們從理想回到現實也是項目經理的分內工作。

1.3     需求調研

在需求調研分析階段，項目組對客戶的整體組織結構、有關人員及其關系、工作職責等沒有足夠了解以致于無法得到完整需求或最終經權威用戶代表確認的需求。由于項目經理和需求分析員的工作問題以及調研工作做的不夠細，客戶參與程度都不高，客戶方相關責任人不明確或對范圍和需求責任心不強，提出的需求具有隨意性，項目前期對需求的確認不夠積極；多個用戶代表各說各話、昨是今非但同時又希望軟件盡早交付；我們的做法主要注重領導的需求，基本上都是領導說什么就是什么，致使開發(fā)出來的功能在實際使用中不是真正的使用人所需要的，項目后期需求變化隨意，造成項目范圍的蔓延，進度的拖延，成本的擴大。同時在我們的認識中是需求調研很關鍵，很多公司只是概念上認為該階段重要，需要投入的時間長，但是實際上很多公司做不到這個，總想很快進入編碼階段。而且為了趕進度總想省做某些工作，少寫某些文檔，使我們無法拿出客戶需求以及后來功能變化和原先功能之間的對比度。

造成上述現象的原因是我們沒有全面了解所有項目干系人的需求以及對需求調研的重視程度不夠。軟件開發(fā)是沒有捷徑可以走的，省掉的工作后面會有更高的代價回報。全面的需求來自所有項目干系人，不同的干系人其愿望和追求的目標往往相差甚遠，因此對項目干系人的愿望進行平衡可能是相當困難的事情。

軟件開發(fā)項目的目的就是實現項目干系人的需求和愿望。如果對項目所有干系人沒有進行足夠的溝通和影響，使其盡可能地參與項目，則可能因為項目開始時項目范圍和一些具體需求不夠完整清晰，也可能因為某個項目干系人后期因為認識的變化而提出新的需求，造成工期的延長，成本的增加，甚至項目的完全失敗。因此，應當從項目的啟動開始，需求分析員及其項目成員就要分清項目干系人包含哪些人和組織，通過溝通協(xié)調對他們施加影響，驅動他們對項目的支持，調查并明確他們的需求和愿望，減小其對項目的阻力，以確保項目獲得成功。以下是一些有效的措施

1、盡快熟悉項目干系人全貌
　　有些項目在做需求調查時，由于受進度要求等客觀因素影響，需求分析員與建設單位的技術部門交流較多，向業(yè)務管理部門和實際使用者調查不夠深入，造成軟件試用后不得不再對需求做較大調整，"從頭再來"的部分比例很高，大大超過進度要求時間。因此，熟悉項目干系人全貌是進行需求調查的第一步，也是需求調查的基礎。在定制開發(fā)項目的項目干系人中，最重要的是建設單位中的人事組織、業(yè)務關系。最好是能夠用組織結構圖畫出相關單位的組織結構；建立調研對象通訊錄以保證調研及分析期間及時的溝通。與此同時要注意項目干系人的主次關系，以便在他們之間的需求出現矛盾時能夠進行合理的取舍。
　　熟悉建設單位內部相關部門的業(yè)務劃分及它們之間的相互關系,為功能分析準備了必要的資料, 同時可以熟悉用戶方的各類人員，并及時進行廣泛、有效的溝通與交流。特別要與客戶方業(yè)務與技術的規(guī)劃者和實際使用者進行深入探討，收集必要的原始資料，保證需求調查的完整性、正確性。
　　建設單位只是項目干系人中的一部分（當然是主要的部分），為了更好地了解項目干系人全貌，還應當在建設單位組織結構圖基礎上全體項目干系人結構圖，以便更好更全面地進行需求調研分析。
　　2、詳細描述各項業(yè)務，以利于讓所有客戶確認
　　盡可能全面詳細地調查并且描述原有系統(tǒng)（這點非常關鍵，需要調查清楚原有系統(tǒng)的不足以及優(yōu)點，以及用戶在這些系統(tǒng)中的操作習慣）和用戶希望將來系統(tǒng)具有的各項業(yè)務的流程，并將這些業(yè)務流程文檔化后與客戶進行討論，對描述錯誤或不準確不精確的進行修改，最終讓客戶進行確認。從個人認為，對業(yè)務處理過程了解的完整性和準確性非常重要。雖然對數據來說都是查增刪改傳，但具體業(yè)務都是分為若干步驟，每個步驟都有其業(yè)務名稱，同一步驟可能對多個數據集進行不同操作，需要調查了解清楚才能設計出適合各流程業(yè)務節(jié)點用戶業(yè)務特點和習慣的軟件，使開發(fā)出來的軟件更受歡迎。當然在進行軟件概要設計時，要盡量排除業(yè)務流程的制約，即把流程中的各項業(yè)務結點工作作為獨立的對象，充分考慮他們與其他各種業(yè)務對象的接口，在流程之間通過業(yè)務對象的相互調用實現其業(yè)務流程，這樣，在業(yè)務流程發(fā)生有限的變化時，就能夠比較方便地修改系統(tǒng)程序而實現新的需求。
　　對于各項業(yè)務的調查可以通過對以下資料的收集整理分析，這些資料來自各種各樣的項目干系人：遵循的標準、組織發(fā)放的工作手冊、作業(yè)流程、有關業(yè)務的上級通知、有關業(yè)務的辦事指南、辦理業(yè)務時需要填寫的登記表、各種相關的統(tǒng)計報表及通過其他途徑收集的類似系統(tǒng)的介紹、技術資料等等。
　　3、可視化需求調研，引導各種客戶挖掘他們的需求
　　很多客戶因為自己缺乏計算機知識，無法提出完整準確、隱含的或潛在的需求。但若這些需求不能滿足將導致用戶的不滿。因此需求調研分析人員應善于想用戶所想，不要害怕用戶的需求多，不但要確定明確的需求，還要善于用啟發(fā)的方式與用戶探討隱含的或潛在的需求，并結合各種調研分析技術挖掘超出客戶期望的令人興奮的需求。這就要求需求調研分析員要盡快完整地熟悉相關業(yè)務，從而能夠站在用戶的立場看待軟件需求，想用戶所想，做好業(yè)務與計算機之間的橋梁。利用可視化需求調研的方法可以很好地啟發(fā)用戶深入挖掘潛在的需求。可視化需求調研就是使用圖表等工具來啟發(fā)引導用戶清楚地敘述需求，并且使需求更加全面完善。
　　對于高層領導，可以提供系統(tǒng)總體框架圖；對于業(yè)務管理人員，可以用業(yè)務流程圖來描述新舊系統(tǒng)的業(yè)務流程；對于客戶中的技術人員，可以用數據流圖、實體關系圖或UML中的各種圖形對系統(tǒng)進行各種角度的描述；而對于業(yè)務管理人員、客戶中的技術人員、以及各層次各流程中的用戶，畫出用戶界面圖來進行需求挖掘，是個比較有效的溝通方式。
　　這里特別說明一下用戶界面的重要性。用戶界面的設計按理來說是軟件設計的責任，當然客戶自己對界面有特別提出要求的除外。但是，如果把它提前到需求調研時（緊接著原有系統(tǒng)調研分析和系統(tǒng)模型完成之后）與客戶進行討論，則可以大大改善需求調研的效果。因為這時客戶對于將來的系統(tǒng)還沒有一個形象上的概念，或者有一個模糊的預想的概念需要表述、驗證、明晰化、完善化。從我們后來的項目先做界面和用戶交流的經驗看（系統(tǒng)原形應該在需求分析的時候開發(fā)人員在分析師的指導下完成真實環(huán)境中的開發(fā)，當然開發(fā)只是界面的功能模擬，沒有底層代碼的實現），畫出用戶界面草圖與客戶進行討論，可以大大激發(fā)他們提供更為準確全面的需求，而且這些界面在后期的開發(fā)中也可以利用。原來收集資料，描述業(yè)務，說明系統(tǒng)模型到了山窮水盡的時候，這種方法可以達到柳暗花明又一村的效果。因此，所謂需求就是“當你按下各種相關按鈕（或輸入各種相關命令）時系統(tǒng)做什么”，所謂設計就是“當你按下各種相關按鈕（或輸入各種相關命令）時系統(tǒng)怎么做”。需求的最終目的實際上是完整準確地描述系統(tǒng)需要的各種接口或“界面”，及它們的相互關系或與外部環(huán)境的關系，如界面中的某個按鈕按下去時，可能產生新的界面、新的按鈕、或者調用其他軟件硬件完成某些功能。自頂向下，把這些界面及涉及到的數據描述清楚，就是一份不錯的需求。
　　4、與其他項目小組成員共同協(xié)作、持續(xù)完善系統(tǒng)需求
　　需求文檔完成之后，并不是萬事大吉，把它扔給后面的設計人員就了事了。作為項目干系人之內的項目組其他成員，對需求的有效性也起到某種程度的驗證作用。雖然軟件項目的生命周期按照各種開發(fā)模型有不同階段的劃分，但每個階段的結束不是簡單地把階段工作成果塞給下一階段的成員就可以了。特別是高科技的軟件開發(fā)項目，上一階段的工作成果往往要通過多次的溝通才能更為清晰地被下一階段成員接受，其有效性、合理性也要被下一階段的工作所檢驗，通過檢驗有時也有必要對上一階段的工作結果進行相應的調整，需求更是如此。因此，無論是同一階段不同人員之間，或是不同階段人員之間都應根據需要相互協(xié)作，相互配合，共同完成軟件開發(fā)任務

5、《功能規(guī)格說明書》，這個是我們項目中最大的失誤，致使后來客戶的改動讓我們很被動?！豆δ芤?guī)格說明書》反映了客戶提出的所有需求功能，我們也是按照《功能規(guī)格說明書》來開發(fā)的。后期客戶的變化都可以和《功能規(guī)格說明書》對比，具體怎么變更按照我們的變更流程來做?！豆δ芤?guī)格說明書》作為產品需求的最終成果必須具有綜合性：必須包括所有的需求。開發(fā)者和客戶不能作任何假設。如果任何所期望的功能或非功能需求未寫入軟件需求規(guī)格說明那么它將不能作為協(xié)議的一部分并且不能在產品中出現。并且注意以下幾點：

(1)完整性

每一項需求都必須將所要實現的功能描述清楚，以使開發(fā)人員獲得設計和實現這些功能所需的所有必要信息。不能遺漏任何必要的需求信息。遺漏需求將很難查出。注重用戶的任務而不是系統(tǒng)的功能將有助于你避免不完整性。如果知道缺少某項信息，用“待確定” 作為標 準標識來標明這項缺漏。在開始開發(fā)之前，必須解決需求中所有的“待確定”項。

(2)正確性

每一項需求都必須準確地陳述其要開發(fā)的功能。做出正確判斷的參考是需求的來源，如用戶或高層的系統(tǒng)需求規(guī)格說明。若軟件需求與對應的系統(tǒng)需求相抵觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用戶的積極參與的原因。沒有用戶參與的需求評審將導致此類說法：“那些毫無意義，這些才很可能是他們所要想的。”其實這完全是評審者憑空猜測。

(3)可行性

每一項需求都必須是在已知系統(tǒng)和環(huán)境的權能和限制范圍內可以實施的。為避免不可行的需求，最好在獲取需求(收集需求)過程中始終有一位軟件工程小組的組員與需求分析人員或考慮市場的人員在一起工作，由他負責檢查技術可行性。

(4)要性

每一項需求都應把客戶真正所需要的和最終系統(tǒng)所需遵從的標準記錄下來。“必要性”也可以理解為每項需求都是用來授權你編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如使用實例或別的來源。

(5)劃分優(yōu)先級

給每項需求、特性或使用實例分配一個實施優(yōu)先級以指明它在特定產品中所占的分量。如果把所有的需求都看作同樣重要，那么項目管理者在開發(fā)或節(jié)省預算或調度中就喪失控制

(6)無二義性

對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。避免二義性的有效方法包括對需求文檔的正規(guī)審查，編寫測試用例，開發(fā)原型以及設計特定的方案腳本。

(7)可驗證性

檢查一下每項需求是否能通過設計測試用例或其它的驗證方法，如用演示、檢測等來確定產品是否確實按需求實現了。如果需求不可驗證，則確定其實施是否正確就成為主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的需求也是不可驗證的。
(8)一致性

一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務）需求不相矛盾。在開發(fā)前必須解決所有需求間的不一致部分。只有進行一番調查研究，才能知道某一項需求是否確實正確。
(9)可修改性
在必要時或為維護每一需求變更歷史記錄時，應該修訂文檔。這就要求每項需求要獨立標出，并與別的需求區(qū)別開來，從而無二義性。每項需求只應在文檔中出現一次。這樣更改時易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明更容易修改。

 (10)可跟蹤性

 應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好的方式編寫并單獨標明，而不是大段大段的敘述。

        其他內容見第二篇