專案總結應該描述寫些什麼

內容摘自網路

1、專案初期要進行風險的管理探討，專案遠景定義和功能集合的詳細定義。

2.需求
客戶一般對計算機不是很瞭解，和他們交流是用軟體行業的專業俗術語，他們根本就不懂，如果用文件也很難把需求寫得那麼明白，
而且文件很多的話，客戶都看煩了，很不直觀。如果讓客戶一看就可以看出這個就是他們想要的，我認為最好的方式就是做系統原形（介面的功能模擬）。

系統原形應該在需求分析師的指導下完成，當然開發只是介面的功能模擬，沒有底層程式碼的實現。
這樣做的目的有三個好處，
一是客戶很直觀的看到他們的系統是什麼樣子的以及怎麼操作，
二是這些開發的成果是可以二次利用的，
三是可以更好的激發客戶的需求。

注重使用者參與
使用者參與詳細需求的制定，不能靠需求採集人員的猜想，造成系統功能不切合實際，與專案實際需求差距大,執行效果差。
需求調研末期的《軟體開發需求規格說明書》，要跟客戶簽字確認。
這樣既能保證我們所理解的需求就是客戶所要的，也使得專案末期跟客戶驗收時有據可依。

3、集團化以後，專案經理需意識到資訊化核心問題是管理變革問題。
在組織架構、許可權、供應商等方面與力和集團理解不一致，需分別按組織進行區分。
要根據企業業務需求制訂策略,調整軟體組織結構, 詳細設計軟體各組織架構之間的邏輯關係。

4.良好素質能力的開發人員、設計人員、專案經理良好的管理能力
開發人員要接觸實際業務，和客戶溝通，不要害怕客戶提需求，對客戶的需求做深度分析，要理解抓住真正的客戶需求，改進系統功能。
設計人員設計系統結構時不要過於定製，要考慮系統的可擴充套件性，考慮到後期的維護。
當出現問題時，專案經理要根據現階段的狀況重新評價需求分析結果、開發人工數估算、設計結果等。

實行雙專案經理制度：為開發專案設定兩個專案經理崗位，一個負責技術崗位，另一個負責管理崗位。
管理經理做到對專案整體的管控，專案風險管理和控制。技術經理擅長的是技術研發。兩者的配合提升軟體開發專案的管理水平。

技術崗位：負責技術框架的穩定性和可擴充性、質量的保證、風險的預測以及資料庫的設計，模組測試、介面測試、白盒測試等；
對於該專案具體需要多少人員、時間；到底需要什麼層次技能的程式組組長和具體開發人員給出詳細的計劃；
對程式組每週具體的開發目標的進行檢測驗收，保證開發進度。以及其它需要考慮的問題等，如網路速度，伺服器訪問量，資料庫查詢優化，都需要整體考慮。

管理崗位：掌握行業知識、專案的前期調研、需求分析、功能模組架構設計、人員的管理、實施計劃的安排執行和跟蹤。
提交《目標與範圍》和需求調研末期的《軟體開發需求規格說明書》。

一個專案在前期的工作非常重要，就算是一個錯誤的開始話，後面有再強大的開發團隊也是白搭。
人員肯定是從專案實戰中成長起來的

5、合理做專案的進度安排，不要一味的追求快速開發

專案中有個不變的金三角法則，即時間、功能和資源。
我個人的意見是用我們的實際能力按照一個正常的進度去做，一個專案在功能、時間和資源一定的情況下，沒有捷徑可以走的，必須一步一個腳印。

6、分清主次，不要鬍子眉毛一把抓

根據企業不同的發展階段，按照規劃逐步深入，這樣一方面可以避免投資的盲目性，另外一方面在前期的投入收到效果後，
再進行下一階段投入的同時，員工和企業領導也容易接受，軟體人員的壓力也會相對減少。

7、開發結果要做測試

必須做好充分準備的開發計劃，對於該專案具體需要多少人員、時間；到底需要什麼層次技能的程式組組長和具體開發人員給出詳細的計劃。

8、要做專案總結會議，重視專案質量。

每日必須召開專案總結會議，隨時捕獲風險，當日事當日畢。
軟體開發初期的時候，就開始猛抓質量，而不是走“先上線、後優化”的專案常規實施方法。若發現質量不合格的地方，就讓開發人員重新返工。

9、軟體版本釋出週期儘量不要頻繁。
釋出週期要合理，具體看產品要求，在版本更新前，必須做好充分的測試，方可交給客戶使用。

10、重視客戶體驗

公司應該拿出一部分預算，有計劃有規模地組織使用者進行測試，對操作員給出的體驗意見做好詳細的記錄，並給予充分的重視，對其中有用的軟體改進意見給出相應的獎勵。做好足夠的風險應對計劃，抵禦這種影響所帶來的對系統本身的順利實施以及實施人員的信心和工作激情的衝擊。

11、要有資料風險意識。

軟體系統是一個高度整合的系統，一個環節的出錯將可能導致一系列的錯誤，所以，對資料的準確性提出了很高的要求。

12、注重細節。

天下大事，必做於細。1%的錯誤往往會導致100%的失敗。

在此對之前開發過程中一些可以改進的細節列出，進行總結，在今後的開發中將進行改進。

（1）軟體每一個開啟的窗體都應該寫上標題，而不能是預設的標題。
（2）操作按鈕位置、操作順序必須一目瞭然。
（3）軟體的功能都加上快捷鍵，使它適應不同操作習慣的使用者。
（4）每一個窗體都加上“關閉”快捷鍵，當用戶需要關閉窗體時，只需要點“ESC” 鍵就可以退出，

方便使用者的操作。
（5）所有輸入文字框都必須按照使用者的業務要求進行排列，使使用者可以更快更好地輸入資料。
（6）進入系統以及退出系統時，如果程式執行比較耗時的程式碼，應該給出個提醒，而不能讓使用者傻等，最好放到執行緒中處理，不能讓主執行緒出現假死狀態。
（7）使用者登陸的視窗，應該自動幫使用者記住使用者名稱，使用者可以自己確定是否要記住密碼。
（8）複雜的查詢條件，錯誤提示之後，原來的輸入是否都還儲存？如果都沒有了，使用者要再輸入一遍會很煩。
（9）查詢錯誤或無結果，必須有提示。
（10）下拉框中的資料必須有排序。
（11）系統中的各種提示必須要合理，不能有誤導使用者的情況。

當然，還有許多需要注意的技術和非技術的細節問題，往往我們技術人員覺得不重要的東西偏偏是使用者覺得最重要的。我相信，在軟體開發的過程中，你只有琢磨你的使用者是怎麼想的，你才能使我們的軟體更加完美，付出得越多，得到的越多。

13、沒有結果的結束。

我們幾乎聽不到有人出來說專案失敗了，我們聽到的是延期、暫停、取消等等形容詞，但是其實，我們其實應該承認，我們有做了一個失敗的專案。
專案的成敗是變數多多，既有技術的，也有管理的，也有關係的，既有自身的，也有客戶的，但是隻要我們把我們可以控制的做好了，至少這個專案成功了一半。