項目結(jié)項總結(jié)報告模板(it項目總結(jié)報告模板)

項目結(jié)項總結(jié)報告模板

項目結(jié)項總結(jié)報告模板

在經(jīng)濟飛速發(fā)展的今天，報告與我們愈發(fā)關(guān)系密切，報告根據(jù)用途的不同也有著不同的類型。那么一般報告是怎么寫的呢？下面是小編精心整理的項目結(jié)項總結(jié)報告模板，希望對大家有所幫助。

篇一：結(jié)項總結(jié)報告

1. 項目背景

{可參考原項目方案建議書中的項目背景描述。}

2. 項目信息

項目實施周期： 項目參與人：

產(chǎn)品實現(xiàn)的主要功能：

｛主要功能中需要說明針對立項范圍對比：注明全部實現(xiàn)，沒有實現(xiàn)部分以及新增實現(xiàn)部分｝

3. 主要成果

{工作成果可以是產(chǎn)品、文檔或者某方面經(jīng)驗的成功應用，并在描述中對其進行介紹。

文檔或產(chǎn)品可以描述其版本、主要內(nèi)容，工作經(jīng)驗則描述主要應用與應用效果。結(jié)合總體計劃中2.3項目交付成果描述，工作成果中可以在組織級復用或推廣使用的，請在描述中說明}

4. 計劃與實際情況對比

{以下數(shù)據(jù)項可根據(jù)項目情況做出調(diào)整，給出各數(shù)據(jù)項的計劃、實際情況的數(shù)據(jù)，以及比較后的情況說明。數(shù)據(jù)MA004_項目測量數(shù)據(jù)表、測試工作階段報告;如存在計劃變}

5. 開發(fā)工作評價

{以下開發(fā)類項目工作的評價，結(jié)合《MA004_項目測量表》中測量指標給予量化評價。}

5.1. 對生產(chǎn)效率的評價

{給出實際生產(chǎn)效率，并與公司平均水平或計劃數(shù)據(jù)作為對比，分析原因。數(shù)據(jù)，項目測量表}

5.2. 對產(chǎn)品質(zhì)量的評價

{說明在測試中檢查出來的錯誤發(fā)生率（缺陷密度），與目標值對比，分析原因。數(shù)據(jù)測試工作階段報告}

5.3. 對過程符合性的評價

{說明在軟件過程符合性，與公司平均水平或目標值對比，分析原因。數(shù)據(jù)QA工作報告}

5.4. 對技術(shù)方法的評價

{給出對在開發(fā)中所使用的技術(shù)、方法、工具、手段的評價。如存在技術(shù)問題，注明解決部門；對于可以列入公司公用構(gòu)件庫的構(gòu)件，請說明}

5.5. 問題的分析

{針對項目管理進行統(tǒng)計分析以及根本原因分析。數(shù)據(jù)PMC007_問題跟蹤表}

6. 經(jīng)驗與教訓

{描述項目實施中來自產(chǎn)品實現(xiàn)、項目管理、關(guān)系處理、成本控制等各個方面經(jīng)驗與教訓,對后續(xù)開發(fā)工作的建議以及對項目定義過程的評價。在結(jié)項評估中進行分析總結(jié)，納入組織財富庫}

7. 知識產(chǎn)權(quán)（可選）

{描述產(chǎn)品知識產(chǎn)品的申報情況。}

8. 項目維護建議

{產(chǎn)品開發(fā)類項目、維護開發(fā)類項目和合同開發(fā)類項目必須填寫。

描述項目進入維護期開發(fā)工作主要內(nèi)容，對維護工作量的估算和人力資源計劃，建議本項目開發(fā)維護人員的人選和工作安排。}

9. 申請結(jié)項理由

{說明結(jié)項理由：正常結(jié)項和異常結(jié)項。異常結(jié)項必須說明結(jié)項原因。}

篇二：結(jié)項總結(jié)報告

摘要：和諧社會建設(shè)離不開社會道德問題的解決，最為其中翹楚的讓座糾紛問題尚未從參與者心理層面進行研究。本文針對傳統(tǒng)問題分析方式的種種不足，從讓座者、座位需求者以及旁觀者等角度去進行調(diào)查（問卷及訪談）以反思現(xiàn)狀。并根據(jù)調(diào)查到的數(shù)據(jù)與資料哦分析出相應的對策，對讓座糾紛問題解決的有效性進行研究，從而探討出優(yōu)化現(xiàn)行群眾及官方糾紛解決的措施。從14年五月到15年九月我們課題組成員做出了大量富有成效的研究工作，并取得了一定的成果。

關(guān)鍵詞：讓座糾紛 心理 引導

一、引言

近年來關(guān)于公共交通的座位之爭相關(guān)的新聞數(shù)不勝數(shù)，其作為社會道德問題的一個現(xiàn)實反映，卻被稱作新聞領(lǐng)域的“月經(jīng)帖”，屢見不鮮，調(diào)侃的背后透露出幾分無奈幾分悲哀。隨著網(wǎng)絡普及，各種媒體曝光，讓座糾紛問題日趨嚴重。在此本課題具體研究較為普遍的讓座糾紛問題——公交車讓座糾紛。

隨著目前公共交通發(fā)展的日益成熟，公交車成為了較多人的出行選擇，然而公交車作為最為普遍的一種大眾運輸工具，應該是最安全最快捷的，現(xiàn)在卻成為一個危險的區(qū)域，還有生命之虞，不能不說是時代的悲哀。

然而公交車作為一種公共交通工具，必然不可能做到讓每一個需要座位的人都得到滿足，在這種情況下，讓座糾紛看似無法避免，然而目前對于讓座糾紛的研究，大多關(guān)注于公交設(shè)施資源問題、新時期道德體系建設(shè)問題等，因此研究公交車讓座糾紛產(chǎn)生的心理因素有利于從另一個視角來看待此問題，也有利于幫助問題的解決。

二、研究方法

（一）文獻研究法

文獻研究法指對文獻進行查閱、分析、整理，從而了解研究對象的一種研究

方法。本文主要通過搜索中國知網(wǎng)、維普中文期刊數(shù)據(jù)庫、萬方數(shù)據(jù)等中文數(shù)據(jù)庫進行查閱，搜集有關(guān)大學生志愿服務活動的相關(guān)資料，全面了解學者對大學生志愿服務的研究，為本課題提供理論支持。

（二）調(diào)查研究法

（1）問卷調(diào)查法

本課題的研究總體范圍較廣，于是采用偶遇抽樣法來選取研究對象。在蘭州大學榆中校區(qū)采用隨機抽樣的預調(diào)查，后期將問卷分年齡層次隨機發(fā)放。總計回收有效問卷紙質(zhì)版67份，電子版146份，共計213份。有效問卷回收率為80％.調(diào)查中男女比例大體相同。

（2）半結(jié)構(gòu)式訪談

問卷以選擇題為主，對于不同年齡層次的不同群體設(shè)計針對性、選擇性的問題。對于實地發(fā)放回收的問卷，我們挑選了一些參與者進行了簡短的提問并記錄。將此類同時填答問卷并參與微訪談的參與者單獨分組。在研究后期對于此組資料進行較為深入的分析。同時，對于一些不能詳細地出現(xiàn)在問卷上、需要進行深度交流的問題，進行了隨機訪談。

三、研究過程和做法

讓座糾紛的產(chǎn)生對象不僅僅局限于糾紛雙方，其實在場所有乘客及司機都可以參與其中，所以研究不應局限于對參與過讓座糾紛的人群，為了保證課題的全面性與實施的條理性，我們將研究分為以下幾個階段

（一）準備階段

1.訂立課題

2.選定研究人群

做好研究的信息搜集：根據(jù)小組分析的讓座糾紛產(chǎn)生的可能情況，擬定調(diào)查問卷，對不同人群分發(fā)相同問卷，并按統(tǒng)一標準進行統(tǒng)計分析。

（二）實施階段

實施階段是完成本課題研究的.重要階段，我們對不同人群分發(fā)問卷，收集并統(tǒng)計不同人群的數(shù)據(jù)資料。

（1）問卷擬定及預調(diào)查階段

讓座糾紛的產(chǎn)生原因不能簡單歸結(jié)為單方面的不道德，糾紛的產(chǎn)生可能有多方面原因，不能一概而論。

小組擬定問卷后，對此問卷進行了預調(diào)查與效度分析，刪改了一些問卷內(nèi)容。

（2）問卷定稿及發(fā)放回收階段

由于第一次實地問卷回收并不理想，小組第二次發(fā)放問卷選擇實地發(fā)放與網(wǎng)絡調(diào)查同步進行。

在進行網(wǎng)絡調(diào)查時，我們將同一份問卷分兩個網(wǎng)頁進行填答，較為成功通過分離不同網(wǎng)頁的填答年齡層將兩組問卷大致分為青年組與中老年組。從而減少了后期統(tǒng)計分析的工作量。

對于實地發(fā)放回收的問卷，我們挑選了一些對于“您是否參與過讓座糾紛”這項問題填答“參加過”選項的參與者進行了簡短的提問并記錄。將此類同時填答問卷并參與微訪談的參與者分為A組。在研究后期對于A組資料進行較為深入的分析。

（3）數(shù)據(jù)整理與分析階段

通過對參與問卷調(diào)查的人進行年齡段的分類，本研究假定青年人群鮮有對座位的需求，故不將青年人群作為座位需求者加以考慮。在基本信息采集部分年齡屬于青年的共有101份（電子問卷59份，紙質(zhì)問卷42份）。在此群體中填答表示參與過讓座糾紛的共有14名，僅旁觀未參與過讓座糾紛的共有37名。

青年群體作為讓座的主要人群，大部分在讓座糾紛中屬于讓座方。

中老年群體作為座位的主要需求群體，大部分在讓座糾紛中屬于座位需求者。 通過如上的分類方式，課題組成員通過對不同年齡層次的分析來進行數(shù)據(jù)的整合與處理。

四、結(jié)果與分析

1、青年群體選擇讓座的主要原因分析

對于讓座糾紛中的讓座方（多數(shù)為青年人）極少數(shù)會因為外界壓力或道德綁架而讓座，他們的讓座行為多數(shù)出于自己的個人選擇（認為他人比自己更需要幫助）或是自身價值觀（助人為樂）引導所致。

2、青年群體選擇不讓座的原因分析

對于在一些情況下不選擇讓座的人，他們的緣由較多為個人不愿意讓座，多數(shù)認為自己對座位的需求要高于需求座位的人。

同時，責任分散效應也對讓座行為產(chǎn)生較大影響，一些填答問卷者表示，在一些情況下自己會覺得坐在靠車前方一點的人將會讓座或是坐在愛心專坐上的青年人將會讓座，自己雖然有讓座之意但也輪不到自己，從而造成個人做出不讓座的選擇。

由此看來，在讓座糾紛中讓座方拒絕讓座并不是個人道德層次不高，在很多情況下是由于自身對座位較為需求，或沒意識到身邊的人有對座位的需求而導致的。

五、青年群體選擇不讓座時的一般表現(xiàn)分析

多數(shù)青年人在已經(jīng)做出不想讓座的選擇之后，他們用以避免讓座的方式多為坐在角落或忙自己的事（比如玩手機之類）。然而在一些較為沖動的座位需求者（或是圍觀群眾）看來，青年人這樣的行為無疑是不禮貌的，與他們心中的傳統(tǒng)價值觀與道德行為相悖，從而輕者惡語相向，重則推搡怒罵。又因為現(xiàn)在青年人逆來順受之輩甚少，又對道德綁架之類嗤之以鼻，座位需求者（或是圍觀群眾）的壓力反而會激發(fā)起他們的逆反心理，更加拒絕讓座，從而導致糾紛。

篇三：結(jié)項總結(jié)報告

一、緒論

說明：在緒論中簡要說明設(shè)計工作的目的、意義、研究設(shè)想、方法等。應當言簡意賅。有關(guān)歷史回顧和前人工作的，可以適當綜合評述。

1. 概述

介紹項目設(shè)計的背景，目的、意義，項目的設(shè)計環(huán)境，項目的應用范圍，項目的研究方法等。

2. 國內(nèi)外現(xiàn)狀

說明項目所用技術(shù)國內(nèi)外發(fā)展的現(xiàn)狀和實際應用的產(chǎn)品等。

二、關(guān)鍵技術(shù)介紹

說明：對報告所涉及到的關(guān)鍵技術(shù)和所用的專有名詞進行簡要的介紹，在報告的其它部分一般不再敘述通用技術(shù)。

1. 專有名詞介紹

對于報告中出現(xiàn)的專有名詞進行介紹，例如SRAM，F(xiàn)PGA，狀態(tài)機等。

2. 關(guān)鍵技術(shù)介紹

對于項目中用到的關(guān)鍵技術(shù)進行介紹，例如IP核復用，March C-算法等技術(shù)。

三、系統(tǒng)分析

說明：在本部分中分析項目所作測試電路應實現(xiàn)的功能，項目的可行性分析，待測的SRAM IP核的結(jié)構(gòu)框圖及功能說明，測試電路所采用的算法以及項目的流程圖等部分。

1. 項目的功能描述 2. 項目的可行性分析 3. 待測目標SRAM 分析 4. 測試算法分析 5. 測試電路系統(tǒng)流程圖

四、系統(tǒng)設(shè)計

說明：可分為模塊初步劃分和模塊詳細劃分，分別說明每個模塊的整體功能，端口界定，以及端口功能的詳細描述，并且給出這幾個模塊端口之間的相互關(guān)系圖和關(guān)系的說明等。

1. 初步劃分

把整個項目初步劃分成幾個模塊，分別說明每個模塊的整體功能，端口界定，以及端口功能的詳細描述，并且給出這幾個模塊端口之間的相互關(guān)系圖（可從EDA工具中截取，或者用visio軟件畫出），然后對模塊之間的相互關(guān)系進行說明。

例如本設(shè)計可分為Data_Path和Controller兩個模塊。分別說明。

2. 詳細劃分

對初步劃分的模塊進行詳細的劃分，每個模塊又可劃分成若干個小模塊，詳細說明每個小模塊的功能，進行端口的界定，并對端口信號進行簡單描述，然后給出模塊之間的關(guān)系圖。

it項目總結(jié)報告模板

it項目總結(jié)報告模板

it項目總結(jié)報告模板【1】

I　引言

1.1編寫目的

說明編寫這份項目開發(fā)總結(jié)報告的目的，指出預期的閱讀范圍。

1.2背景

說明：

a.本項目的名稱和所開發(fā)出來的軟件系統(tǒng)的名稱;

b.此軟件的任務提出者、開發(fā)者、用戶及安裝此軟件的計算中心。

I.3定義

列出本文件中用到的專門術(shù)語的定義和外文首字母組詞的原詞組。

1.4參考資料

列出要用到的參考資料，如：

a.本項目的已核準的計劃任務書或合同、上級機關(guān)的批文;

b.屬于本項目的其他已發(fā)表的文件;

c.本文件中各處所引用的文件、資料，包括所要用到的軟件開發(fā)標準。

列出這些文件的標題、文件編號、發(fā)表日期和出版單位，說明能夠得到這些文件資料的來源。

2　實際開發(fā)結(jié)果

2.1產(chǎn)品

說明最終制成的產(chǎn)品，包括：

a.程序系統(tǒng)中各個程序的名字，它們之間的層次關(guān)系，以千字節(jié)為單位的各個程序的程序量、存儲媒體的形式和數(shù)量;

b.程序系統(tǒng)共有哪幾個版本，各自的版本號及它們之間的區(qū)別;

c.每個文件的名稱;

d.所建立的每個數(shù)據(jù)庫。

如果開發(fā)中制訂過配置管理計劃，要同這個計劃相比較。

2.2主要功能和性能

逐項列出本軟件產(chǎn)品所實際具有的主要功能和性能，對照可行性研究報告、項目開發(fā)計劃、功能需 .求說明書的有關(guān)內(nèi)容，說明原定的開發(fā)目標是達到了、未完全達到、或超過了。

2.3基本流程

用圖給出本程序系統(tǒng)的實際的基本的處理流程。

2.4進度

列出原定計劃進度與實際進度的對比，明確說明，實際進度是提前了、還是延遲了，分析主要原因。

2.5費用

列出原定計劃費用與實際支出費用的對比，包括：

a.工時，以人月為單位，并按不同級別統(tǒng)計;

b.計算機的使用時間，區(qū)別CPU時間及其他設(shè)備時間;

c.物料消耗、出差費等其他支出。

明確說明，經(jīng)費是超出了、還是節(jié)余了，分析其主要原因。

3　開發(fā)工作評價

3.1對生產(chǎn)效率的評價

給出實際生產(chǎn)效率，包括：

a.程序的平均生產(chǎn)效率，即每人月生產(chǎn)的行數(shù);

b.文件的平均生產(chǎn)效率，即每人月生產(chǎn)的千字數(shù);

并列出原訂計劃數(shù)作為對比。

3.2對產(chǎn)品質(zhì)量的評價

說明在測試中檢查出來的程序編制中的錯誤發(fā)生率，即每干條指令(或語句)中的錯誤指令數(shù)(或語句數(shù))。

如果開發(fā)中制訂過質(zhì)量保證計劃或配置管理計劃，要同這些計劃相比較。

3.3對技術(shù)方法的評價

給出對在開發(fā)中所使用的技術(shù)、方法、工具、手段的評價。

3.4出錯原因的分析

給出對于開發(fā)中出現(xiàn)的錯誤的原因分析。

4　經(jīng)驗與教訓

列出從這項開發(fā)工作中所得到的最主要的經(jīng)驗與教訓及對今后的項目開發(fā)工作的.建議。

軟件項目總結(jié)報告范文【2】

1 引言

1.1 編寫目的

XXX公司業(yè)務管理系統(tǒng)的開發(fā)已經(jīng)基本完成。

寫此項目開發(fā)總結(jié)報告，以方便我們在以后的項目開發(fā)中來更好的實施項目的訂制開發(fā); 讓我在今后的項目開發(fā)中有更多的有據(jù)的資料來規(guī)范我們的開發(fā)過程和提高我們的開發(fā)效率，從而創(chuàng)造更多公司效益。

1.2 背景

項目名稱：XXX業(yè)務管理系統(tǒng)

軟件名稱：XXX業(yè)務系統(tǒng)

客戶：XXX

用戶：XXX員工

1.3 參考資料

項目開發(fā)文檔：

(1)軟件開發(fā)數(shù)據(jù)模型：PDM_OperationSystem20070831.pdm

(2)數(shù)據(jù)庫開發(fā)文檔： XXX業(yè)務管理系統(tǒng)數(shù)據(jù)庫設(shè)計說明書2.0.doc

(3)軟件業(yè)務流程參考：XXX業(yè)務管理系統(tǒng)流程說明.doc

(4)軟件使用手冊參考：XXX業(yè)務管理系統(tǒng)功能說明3.0.doc

(5)軟件業(yè)務流程參考：XXX業(yè)務管理系統(tǒng)流程說明.doc

(6)軟件中使用到的第三方控件：ComponentArt Web.UI 2006.1252 for asp.net2.0.rar

(7)軟件中使用的安全Ikey驅(qū)動：Ikey Driver.rar

以上參考資料是截止2007-08-31是最新的資料文檔。

如有修改，即使修改此處的參考文檔名稱。

2 開發(fā)工作評價

2.1 對生產(chǎn)效率的評價

(1)系統(tǒng)開發(fā)已歷時快1年的時間了

(2)開發(fā)的反復性比較多。

(3)對客戶的需求理解不是很透徹。

綜合以上，此項目的開發(fā)效率不是很高，相反有相當一定時間的浪費。

2.2 對產(chǎn)品功能的評價

經(jīng)過我們公司各位同事的共同努力協(xié)作，XXX業(yè)務管理系統(tǒng)已經(jīng)很好的完成了客戶的業(yè)務流需求。

經(jīng)過對客戶使用過程的觀察，此項目開發(fā)的還是比較成功，但是還是存在著一些問題，造成這些問題的原因是多方面的。

如：前期系統(tǒng)數(shù)據(jù)庫的設(shè)計缺陷和部分代碼的構(gòu)建缺陷、客戶需求的理解上也存在一定問題，這就需要我們用一定的時間來維護客戶使用過程中提出的新問題和存在的debug。

總的來說，此系統(tǒng)的功能開發(fā)還是一個比較成功的案例。

2.3 對技術(shù)方法的總結(jié)

在此項目中使用到技術(shù)和工具：

(1)使用代碼生成器：使用代碼生成器 [動軟.Net代碼自動生成器]，此工具在很大程度上提高了編碼效率，從而加快了項目的開發(fā)進程。

在以后的項目中，我們要盡量的來使用一些類似的工具來在最短的時間內(nèi)完成工作。

在今后的項目開發(fā)中，我們最好是能開發(fā)出適合自己的代碼生成工具，更大限度的節(jié)省開發(fā)周期和開發(fā)費用。

(2)使用數(shù)據(jù)庫建模工具：PowerDesigner 工具來建立系統(tǒng)數(shù)據(jù)庫模型，以方便程序員很好的理解業(yè)務流和掌握系統(tǒng)架構(gòu)者的架構(gòu)思想，更好的滿足客戶的功能需求。

在今后的項目開發(fā)中，我們要更好的來完成系統(tǒng)的前期數(shù)據(jù)庫模型的建立，最大的來優(yōu)化系統(tǒng)功能。

(3)使用第三方控件：此系統(tǒng)中使用了ComponentArt Web.UI 第三方控件。

此控件在很大程度上滿足了客戶對軟件界面的需求，從而也給軟件的操作帶來了方便。

本項目中只使用了ComponentArt Web.UI一種第三方控件，在今后的項目開發(fā)過程中，要繼續(xù)使用第三方的控件。

這樣以來，無論是針對軟件界面的美觀性、友好性來說、易操作性而言，還是針對系統(tǒng)開發(fā)效率而言，這都是很好途徑。

但需要注意的是：在使用第三方控件時，要謹慎的選擇一些網(wǎng)絡中的比較常見的第三方控件。

(4)使用自定義控件：此系統(tǒng)中使用了自定義控件(GhdGridView)，此自定義控件可以很好的統(tǒng)一系統(tǒng)中的所有信息顯示表格樣式。

如客戶對數(shù)據(jù)顯示樣式有什么新的意見，我就不需要修改每一個頁面的表格樣式，我們只需要修改GhdGridView控件的樣式，系統(tǒng)中的所有繼承自GhdGridView的表格樣式都可以改變。

(5)系統(tǒng)開發(fā)框架：此系統(tǒng)的框架使用的是簡單三層結(jié)構(gòu)，此框架在開發(fā)一些中小軟件是比較實用的。

但是我們要是可以開發(fā)出自己的框架，把一些通用的功能開發(fā)到框架中。

這樣以來，在以后的系統(tǒng)開發(fā)中，針對系統(tǒng)中一些通用的功能就不需要再開發(fā)，從而也可以很好的提高我們的開發(fā)效率;減少很多維護費用。

使我們的技術(shù)不斷的更加成熟。

(6)系統(tǒng)安全加密：此系統(tǒng)中針對客戶提出的系統(tǒng)安全問題，我們采用了Ikey加密硬件鑰匙來驗證客戶端登陸客戶的合法性，此Ikey鑰匙可以綁定到一個系統(tǒng)使用用戶，也可以讓多個用戶來使用一個加密鑰匙來驗證登陸系統(tǒng)的合法性。

這樣以來，即使用戶的密碼不慎丟失，或者被不法人員取得(不法人員他也是無法登陸到我們的系統(tǒng)中來)，這樣就最大的提高了我們系統(tǒng)的安全性。

Ikey加密鑰匙是很好的加密B/S架構(gòu)軟件的硬件工具，在以后的軟件安全方面可以借鑒。

3 項目經(jīng)驗總結(jié)

3.1 簽定合同

一個項目的開發(fā)成敗或者說項目開發(fā)帶來效益的大小，在很大程度上是受項目合同簽定的影響的。

往往，很多一部分公司與客戶簽定的項目合同都是很模糊的，也很難簽定的比較清楚，這樣以來就會導致在項目的開發(fā)后期，工作量會越來越大，影響項目的竣工周期;而且，項目的開發(fā)費用一般是不會變的。

這樣以來，我們就大大的降低了我們的開發(fā)效益。

雖然需求范圍很難簽定的明確，但是我們在簽定合同時，要盡量的去把合同功能邊界和添加新功能的條件簽定。

3.2 開發(fā)團隊

在項目確立后，要盡快的建立起項目開發(fā)團隊。

項目團隊成員的團結(jié)合作、相互溝通是非常重要的，團隊成員之間要相互學習彼此的優(yōu)點和技術(shù)，使團隊的能力不斷的提高。

這樣，在項目的開發(fā)過程中，團隊才不會被難題困住不動。

另外，團隊中要有一個項目負責人，這個人無論是在與客戶的溝通上，還是在技術(shù)上都要是很出眾的人，此項目負責人要能很好的溝通客戶與開發(fā)成員之間，以此來更好的理解客戶的功能需求。

人的記憶力總是有限的，所以就要求開發(fā)團隊成員要盡量的書寫一些開發(fā)文檔，這些文檔往往是我們在項目開發(fā)后期要用到的可尋資料。

項目團隊士氣是項目成功的一個因素,我們需要不斷的來培養(yǎng)我們的團隊氣勢，使我們的團隊不斷的壯大。

3.3 需求的調(diào)研

在項目確立后，就到了需求調(diào)研分析階段。

(1)項目組對客戶的整體組織結(jié)構(gòu)、公司有關(guān)人員的關(guān)系、職責等如果沒有一個很好、足夠的了解掌握，這樣項目組就無法很好的完整的整理到客戶的需求、或者說客戶真實的功能需求，如此以來我們就為自己埋下了地雷，影響項目的開發(fā)周期，這就要求我們要與客戶搞好無論是工作上的還是生活上的朋友關(guān)系，要深入的去了解客戶需求。

(2)我們要盡量的讓客戶也參與到項目的開發(fā)團隊中來，也就是說我們要使客戶把自己也納入到項目的開發(fā)團隊中來，如此一來，我們掌握客戶需求的真實性、可靠性就會大大的提高，也就不會為項目的后期功能開發(fā)埋下陷阱。

(3)在需求調(diào)研過程中，如果缺乏足夠用戶參與，這樣的需求調(diào)研也是失敗的。

很多程序員不愿參與到客戶的需求調(diào)研中去，為什么呢?很簡單，與客戶溝通不如與代碼溝通容易有意思。

盡管這樣，我們還是必須用足夠多的時間去和客戶進行溝通，了解他們真實的需求。

很多用戶也是如此，他們自己也不愿意參與到項目的需求調(diào)研中來，為什么呢?需求調(diào)研有出去和朋友一塊爛漫嗎?!雖然現(xiàn)狀如此，我們還是要努力的使客戶參與到需求的調(diào)研中來。

(4)模糊需求，也就是模棱兩可是需求規(guī)格說明中最為可怕的問題。

一是指諸多客戶對需求說明產(chǎn)生了不同的理解;一是指單個讀者能用不止一個方式來解釋某個需求說明。

針對對這種情況，就要求我們的調(diào)研人員要能夠從多個角度來分析客戶的不同需求，整理出最終的需求與客戶確認，定出最終真實可靠的需求，我們絕不能憑借我們自己的單面理解來定立客戶的最終需求。

(5)在一個項目的開發(fā)中，文檔的書寫是極為重要的一項工作。

因為，某些文檔就是我們在開發(fā)后期與客戶溝通的可尋依據(jù)、也是我們程序員在編碼過程中要用到的重要文檔。

我們絕對不能認為，憑借我們的大腦來記錄所有的開發(fā)需求。

即使，你說你是天才，你要用你那顆愛因斯坦的大腦來記錄所有的開發(fā)需求，那也是不可能的，人的精力總是有限的。

這就要求我們在需求調(diào)研中做好需求文檔的記錄和整理。

(6)需求調(diào)研工具選擇，客戶一般對圖形還是比較感興趣的，所以我們在調(diào)研過程中，我要盡量的采用圖形化界面來和客戶溝通需求。

比如可以采用Rose工具，把客戶的意思轉(zhuǎn)換為用例圖、時序圖、協(xié)作圖、狀態(tài)圖、類圖等，使表達的意思更加直觀。

這樣客戶會更快的進行問題的實質(zhì)。

3.4 做好開發(fā)計劃

在項目確立后，我們就需要做好項目開發(fā)計劃，需求調(diào)研用時，開發(fā)用時，測試用時，實施用時，維護用時。

在我們做好了計劃后，我們要隨時的跟蹤計劃任務的完成進度，從而使我們的項目進度掌控在我們的開發(fā)周期范圍之內(nèi)，今日計劃、行動，明日成功。

3.5 很好的溝通

在其他行業(yè)中，人與人的之間的溝通是很重要的。

項目開發(fā)也不例外，很好的溝通能夠加快項目的進度，這就要求我們每一個開發(fā)人員要學會和善于溝通于客戶和同事之間。

在一個項目的開發(fā)過程中，我們與客戶的溝通是一個不斷交流和溝通的過程。

在開發(fā)到一定的階段，我們就需要和客戶溝通已有功能，盡量的去避免一些隱藏的問題，及時的發(fā)現(xiàn)問題，解決問題，從而按時或者提前完成項目的開發(fā)。

3.6 做好工作總結(jié)

在項目進行的過程中，我們要不斷去整理自己的工作情況和做好總結(jié)，這樣以來，無論是在自己的技術(shù)還是其它方面，都會對我們有很大的提高，在長期的積累后，無論是我們個人能力，還是我們的團隊能力都會有很大的提高。