無論是身處學校還是步入社會,，大家都嘗試過寫作吧，借助寫作也可以提高我們的語言組織能力,。那么我們該如何寫一篇較為完美的范文呢？以下是小編為大家收集的優(yōu)秀范文，歡迎大家分享閱讀,。

IT項目經(jīng)理崗位職責篇一

1,、項目經(jīng)理為整個項目的第一責任人。

2,、項目經(jīng)理對《質量檢查報告》中的所有細則負首要責任,。

3、項目經(jīng)理必須有效掌控項目開發(fā)的各個環(huán)節(jié),，協(xié)助,、指導項目組成員的工作，及時發(fā)現(xiàn)并處理項目中存在的問題,，并對項目組成員的工作進行合理的評價,。

4、負責管理和控制項目全過程的質量,、進度,。分析偏差，采取糾正措施,。如果發(fā)現(xiàn)項目實際進展顯著偏離計劃,，則及時采取糾正措施。

5,、根據(jù)項目規(guī)范建立項目組內部管理和溝通機制,。

6、可根據(jù)需要調配組內人員等資源,。

7,、有權對項目組成員提出獎懲建議。

8,、項目經(jīng)理負責組織需求分析工作,，并組織對需求文檔和需求變更文檔進行復審。

9,、分配系統(tǒng)設計任務,，包括體系結構設計、模塊設計,、用戶界面設計,、數(shù)據(jù)庫設計等,。

10、組織對體系結構設計,、模塊設計,、用戶界面設計、數(shù)據(jù)庫設計進行評審,。

11,、負責組織項目開發(fā)小組會議并編寫會議紀要。開發(fā)小組會議每周至少舉行一次（可與項目例會合并）,，對難點,、疑點問題進行分析、解決,，保證小組內成員充分溝通,。

12、負責每周對開發(fā)人員的代碼進行檢查,。

13,、負責提交測試版本、搭建符合實際的集成測試環(huán)境,，每個項目只能有一個測試環(huán)境,，開發(fā)環(huán)境不可與測試環(huán)境混合。

14,、所需提交文檔：

? 立項后制定《項目計劃》并保證該計劃的合理性和現(xiàn)實性,。組織項目組內對《項目計劃》進行評審，《項目計劃》制定或變更后必須發(fā)郵件通知部門經(jīng)理,、測試部及項目相關人員,。

? 每周五下班前提交項目的《項目周報》至tfs上項目相關目錄。

? 協(xié)助設計人員編寫《體系結構設計報告》,、《模塊設計報告》,、《用戶界面設計報告》、《數(shù)據(jù)庫設計報告》

? 提交《內部驗收表》,。項目成果交付用戶前項目經(jīng)理必須組織內部驗收,，并簽字生效。

? 結項前向項目管理部門提交《結項申請書》,。

? 負責組織開發(fā)設計人員,、需求分析人員、測試人員,，根據(jù)《用戶需求說明書》提交各類技術文檔,，并保證該文檔的及時有效性和準確性。

二,、項目管理faq

1,、項目計劃如何編寫,？

項目計劃按文檔模板的提示完成各項內容，統(tǒng)一使用project工具制定并跟蹤,。

2,、項目計劃編寫好后怎么提交？

項目計劃編寫完畢后,，需將初稿提交給項目管理部門進行初審,，并由其組織項目管理部門成員及項目組成員進行開會評審。

3,、怎樣進行項目計劃變更？

在項目過程中,，需根據(jù)實際情況對《項目計劃》進行變更,，須提交項目管理部門進行評估，如對項目有重大影響,，項目經(jīng)理須填寫《項目計劃變更申請表》并提交項目管理部門進行審核,。

4、需求分析文檔編寫有哪些要求,？

項目的需求分析文檔是開發(fā)的依據(jù),，在編寫中每項功能的描述必須思路清晰，要求有輸入,、輸出項和操作步驟,、業(yè)務流程等信息，并能對功能畫出示意圖,、流程圖等,。需求分析文檔編寫完成后需將初稿提交項目管理部門進行初審，再由其組織項目組成員并邀請相關人員進行會議評審,。

5,、整個項目實施過程中，各類角色周期性需要提交什么文檔,？

項目經(jīng)理：每周五舉行項目例會,，并提交《項目周報》的“項目進度”部分。開發(fā)人員：每周五提交《項目周報》的“實際完成任務”和“問題匯總”,。測 試 員：每周五提交《項目周報》的“質量保證報告”,。

6、項目經(jīng)理的主要任務是什么,？

在立項申請評審會議中指定項目經(jīng)理后,，項目經(jīng)理需提供項目組開發(fā)人員的建議名單，包括體系結構設計員,、界面設計員,、數(shù)據(jù)庫設計員及模塊設計員,。

制定完《項目計劃》后，項目經(jīng)理應按《項目計劃》要求制定《開發(fā)計劃》,。項目經(jīng)理負責對各系統(tǒng)設計員所提交的設計文檔進行初審,。

項目經(jīng)理應經(jīng)常對開發(fā)人員的模塊設計或源碼進行抽查，確保軟件開發(fā)質量,，并符合設計要求,，并在每周五提交的《項目周報》中的“源碼檢查情況”記錄相關信息。

7,、如何使用bug管理系統(tǒng),？

項目立項后，測試部將會在bug管理系統(tǒng)創(chuàng)建該項目,，并設置項目組成員及各成員的角色,。

項目組內任何人發(fā)現(xiàn)項目缺陷都應該登錄bug管理系統(tǒng)中進行記錄，若非項目組成員發(fā)現(xiàn)錯誤應及時反映給測試人員,。

提交缺陷時,，根據(jù)缺陷的嚴重性選擇類別，并選擇“嚴重級別”能讓開發(fā)人員及時獲取信息進行修改,。標題應該簡要說明缺陷內容,，以便進行相關查詢和統(tǒng)計，不能以“錯誤”,、“測試結果”等無意義的詞作為標題,。

8、怎樣進行驗收,、升級,、安裝？

所有項目在提交客戶前,，必須通過測試部和項目經(jīng)理組織的內部驗收,，并填寫《內部驗收表》。

內部驗收通過后,，項目經(jīng)理制定《客戶驗收計劃》并組織客戶及項目相關人員進行驗收,，編寫《客戶驗收報告》。

項目組/開發(fā)人員負責提供需要驗收的軟件和建立驗收環(huán)境,。并編寫安裝,、升級腳本。安裝,、升級前應先在測試服務器上搭建與正式服務器相同的環(huán)境,，執(zhí)行安裝、升級腳本,，確保腳本執(zhí)行無誤,，然后再驗證程序的正確性,。

測試服務器上安裝、升級無誤后,，項目經(jīng)理指定開發(fā)人員進行正式系統(tǒng)的安裝,、升級，安裝,、升級人員填寫《升級（安裝）記錄表》,。

9、如何結項,？

所有交付給用戶使用的系統(tǒng),，必須在交付驗收的同時，提交經(jīng)項目經(jīng)理和質保員審核的操作手冊,、軟件系統(tǒng)管理手冊,、系統(tǒng)安裝、配置和維護手冊等驗收所需文檔,。所有驗收文檔提交齊全后，由項目經(jīng)理撰寫《結項申請書》,，申請結項,。《結項申請書》應附上經(jīng)項目經(jīng)理審核的項目竣工文檔清單,，并對項目進行全程回顧,，總結項目中的經(jīng)驗教訓，對項目組成員的工作質量,、責任心和效率等進行評估,。

項目管理部門對《結項申請書》進行評審，決定是否同意結項,，并提交《結項評審報告》,。

10、操作手冊等驗收文檔由誰來寫,？

驗收所需文檔均由項目經(jīng)理指定項目組內成員完成,，項目經(jīng)理和測試員負責審核。

11,、結項后又有新需求或需求變更怎么辦,？

根據(jù)需要重新考慮立新項目。

12,、對于細小需求頻繁變更,，時間要求又緊張的需求變更如何應變？

對于較小的需求變更,，經(jīng)過需求分析人員和開發(fā)人員的溝通,，記錄在需求文檔的歷史記錄中,，并由項目經(jīng)理簽字確認；重大需求的變更,，則必須按照需求變更流程進行控制,，提交《需求變更申請書》，并進行項目組內的需求評審,。如果質保員在測試時才發(fā)現(xiàn)需求有重大變更但未形成文檔且未經(jīng)評審,，則嚴肅處理。

三,、項目風險控制

1,、合同風險

簽訂的合同不科學、不嚴謹,，項目邊界和各方面責任界定不清等是影響項目成敗的重大因素之一,。

預防這種風險的辦法是項目建設之初項目經(jīng)理就需要全面準確地了解合同各條款的內容、盡早和合同各方就模糊或不明確的條款簽訂補充協(xié)議,。

2,、需求變更風險

需求變更是軟件項目經(jīng)常發(fā)生的事情。一個看似很有“錢途”的軟件項目,，往往由于無限度的需求變更而讓項目承建方苦不堪言,，甚至最終虧損（實際上項目建設方也面臨巨大的風險）。

預防這種風險的辦法是項目建設之初就和用戶書面約定好需求變更控制流程,、記錄并歸檔用戶的需求變更申請,。

3、溝通不良風險

項目組與項目各干系方溝通不良是影響項目順利進展的一個非常重要的因素,。預防這種風險的辦法是項目建設之初就和項目各干系方約定好溝通的渠道和方式,、項目建設過程中多和項目各干系方交流和溝通、注意培養(yǎng)和鍛煉自身的溝通技巧,。

4,、缺乏領導支持風險

上層領導的支持是項目獲得資源（包括人力資源、財力資源和物料資源等）的有效保障,，也是項目遇到困難時項目組最強有力的“后臺支撐”,。

預防這種風險的辦法是主動爭取領導對項目的重視、確保和領導的溝通渠道暢通,、經(jīng)常向領導匯報工作進展,。

5、進度風險

有些項目對進度要求非?？量蹋ㄟM度要求不高的項目,，我們同樣要考慮該風險），項目進度的延遲意味著違約或市場機會的錯失。

預防這種風險的辦法一般是分階段交付產(chǎn)品,、增加項目監(jiān)控的頻度和力度,、多運用可行的辦法保證工作質量避免返工。

6,、質量風險 有些項目,，用戶對軟件質量有很高的要求，如果項目組成員同類型項目的開發(fā)經(jīng)驗不足,，則需要密切關注項目的質量風險,。

預防這種風險的辦法一般是經(jīng)常和用戶交流工作成果、品牌管理采用符合要求的開發(fā)流程,、認真組織對產(chǎn)出物的檢查和評審,、計劃和組織嚴格的獨立測試等。

7,、系統(tǒng)性能風險

有些軟件項目屬于多用戶并發(fā)的應用系統(tǒng),，系統(tǒng)對性能要求很高，這時項目組就需要關注項目的性能風險,。

預防這種風險的辦法一般是在進行項目開發(fā)之前先設計和搭建出系統(tǒng)的基礎架構并進行性能測試,，確保架構符合性能指標后再進行后續(xù)工作。

8,、工具風險

軟件項目開發(fā)和實施過程,，所必須用到的管理工具、開發(fā)工具,、測試工具等是否能及時到位、到位的工具版本是否符合項目要求等,，是項目組需要考慮的風險因素,。預防這種風險的辦法一般是在項目的啟動階段就落實好各項工具的來源或可能的替代工具，在這些工具需要使用之前（一般需要提前一個月左右）跟蹤并落實工具的到位事宜,。

9,、技術風險

在軟件項目開發(fā)和建設的過程中，戰(zhàn)略管理技術因素是一個非常重要的因素,。項目組一定要本著項目的實際要求,，選用合適、成熟的技術,，千萬不要無視項目的實際情況而選用一些雖然先進但并非項目所必須且自己又不熟悉的技術,。如果項目所要求的技術項目成員不具備或掌握不夠，則需要重點關注該風險因素,。

預防這種風險的辦法是選用項目所必須的技術,、在技術應用之前，針對相關人員開展好技術培訓工作,。

10,、團隊成員能力和素質風險

團隊成員的能力（包括業(yè)務能力和技術能力）和素質,，對項目的進展、項目的質量具有很大的影響,，項目經(jīng)理在項目的建設過程需要實時關注該因素,。

預防這種風險的辦法是在用人之前先選對人、開展有針對性的培訓,、將合適的人安排到合適的崗位上,。

11、團隊成員協(xié)作風險

團隊成員是否能齊心協(xié)力為項目的共同目標服務,，生產(chǎn)管理是影響進度和質量的關鍵因素,。預防這種風險的辦法是項目在建設之初項目經(jīng)理就需要將項目目標、工作任務等和項目成員溝通清楚,，采用公平,、公正、公開的績效考評制度,，倡導團結互助的工作風尚等,。

12、人員流動風險

項目成員特別是核心成員的流動給項目造成的影響是非?？膳碌娜肆Y源,。人員的流動輕則影響項目進度，重則導致項目無法繼續(xù)甚至被迫夭折,。

預防這種風險的辦法是盡可能將項目的核心工作分派給多人（而不要集中在個別人身上）,、加強同類型人才的培養(yǎng)和儲備。

13,、工作環(huán)境風險

工作環(huán)境（包括辦公環(huán)境和人文環(huán)境）的好壞直接影響項目成員的工作情緒和工作效率,。預防這種風險的辦法是在項目建設之前就選擇和建設好適合項目特點財務管理和滿足項目成員期望的辦公環(huán)境、在項目的建設過程中不斷培育和調整出和諧的人文環(huán)境,。

14,、系統(tǒng)運行環(huán)境風險

目前，大部分項目系統(tǒng)集成和軟件開發(fā)是分開進行的（甚至由不同公司承接）,。因此,，軟件系統(tǒng)賴以運行的硬件環(huán)境和網(wǎng)絡環(huán)境的建設進度對軟件系統(tǒng)是否能順利實施具有相當大的影響。

預防這種風險的辦法是和用戶簽定相關的協(xié)議,、跟進系統(tǒng)集成部分的實施進度,、及時提醒用戶等。

15,、分包商風險

有些項目管理可能會涉及到將系統(tǒng)的部分功能分包出去,，這時項目組就需要關注項目的分包商風險。

預防這種風險的辦法一般是指定分包經(jīng)理全程監(jiān)控分包商活動、讓分包商采用經(jīng)認可的開發(fā)流程,、督促分包商及時提交和匯報工作成果,、及時審計分包商工作成果等。

IT項目經(jīng)理崗位職責篇二

it項目助理崗位職責

【篇1：項目助理 崗位職責說明書】

項目助理 崗位說明書

【篇2：it助理崗位說明書】

【篇3：項目經(jīng)理助理崗位職責】

項目經(jīng)理助理崗位職責

在總經(jīng)理領導下負責辦公室的全面工作,，努力作好總經(jīng)理的參謀助手,，起到承上啟下的作用，認真做到全方位服務,。項目經(jīng)理助理在項目經(jīng)理的領導下,，負責組織服務中心人員做好接待、回訪,、收費,、社區(qū)文化宣傳、檔案資料的保管及客戶資源庫的建立與梳理等工作,，對項目經(jīng)理負責,。主要工作如下

1.協(xié)助項目經(jīng)理對所管轄的區(qū)域客戶進行信息跟蹤、分析及報告,，并定期進行更新,。

2.協(xié)助項目經(jīng)理對所管轄的區(qū)域客戶的產(chǎn)品開發(fā)進行項目管理，滿足用戶需求,。

3.經(jīng)常與客戶進行溝通,、與客戶保持親密聯(lián)系，定期走訪,、了解產(chǎn)品的質量等情況,。

4.協(xié)助完成客戶報價工作，即時解答客戶的商務問題,。

5.在總經(jīng)理領導下負責企業(yè)具體管理工作的布置,、實施、檢查,、督促、落實執(zhí)行情況,。

6.協(xié)助總經(jīng)理作好經(jīng)營服務各項管理并督促,、檢查落實貫徹執(zhí)行情況。

7.負責各類文件的分類呈送,，請集團領導閱批并轉有關部門處理,。 8.協(xié)助總經(jīng)理調查研究、了解公司經(jīng)營管理情況并提出處理意見或建議,，供總經(jīng)理決策,。

9.做好總經(jīng)理辦公會議和其他會議的組織工作和會議紀錄。做好決議、決定等文件的起草,、發(fā)布,。

10.做好企業(yè)內外文件的發(fā)放、登記,、傳遞,、催辦、立卷,、歸檔工作,。 11.負責保管使用企業(yè)圖章和介紹信。

12.負責企業(yè)內外的公文辦理,，解決來信,、來訪事宜，及時處理,、匯報,。

13.負責上級領導機關或兄弟單位領導的接待、參觀工作,。

1.負責物業(yè)管理中心職責范圍內工作的策劃,、指導、監(jiān)督,、把關,； 2.負責每月向項目經(jīng)理提交工作計劃及工作

總結

3.負責對項目員工進行各類考核,； 4.向項目經(jīng)理提交各崗位用人計劃；

5.堅守崗位,，按時上下班,，著裝整齊，持證上崗,，熱情接待住戶和來訪客戶,，對住戶的投訴耐心解釋，及時處理,；監(jiān)督項目回訪率100%,，服務質量投訴率為零；

6.熟悉與物業(yè)管理行業(yè)相關的法律,、法規(guī),，樓宇結構和使用功能、單元數(shù),、戶數(shù)及業(yè)主基本情況,，各工種工作及考核標準,，各類設備、器材布置及其控制范圍,；督促本中心工作人員及時收繳各項費用,，收繳率達預定目標； 7.負責處理本項目內業(yè)主違章,、違法,、行為；懂得火警,、電梯困人,、治安案件時的緊急處理辦法，并且能夠有效及時地組織,、安排處理,；

8.每日檢查管理中心日常工作情況，發(fā)現(xiàn)存在及潛在問題及時安排處理并改進有關工作,，監(jiān)督其他部門主管的日檢情況,，跟進處理結果；

9.負責指導,、監(jiān)督建立健全檔案管理制度,，定期查詢檔案情況，如有檔案不全或丟失情況,，應及時組織補全,；并通過客戶檔案資料的梳理，實現(xiàn)客戶資源再生,；

10.定期召開業(yè)主座談會,，定期走訪業(yè)主，定期向項目經(jīng)理匯報,； 11.監(jiān)督本項目各部門對標準作業(yè)規(guī)程的執(zhí)行情況,，協(xié)助項目經(jīng)理組織項目自我核查、自我分析,。完成項目經(jīng)理交辦的其它任務,。

協(xié)助上級組織管理項目經(jīng)營成本控制工作，對與項目有關的各部門資源利用,、合同費用支出的合理性提出意見和建議,；

測算開發(fā)項目的經(jīng)營成本并進行日常管理，組織,、配合公司各部門完成開發(fā)項目的可行性研究報告、項目開發(fā)建設計劃的編制工作,；

根據(jù)公司業(yè)務需要及公司各部門的業(yè)務計劃,，編制項目投資經(jīng)營計劃及管理組織項目開發(fā)全過程的經(jīng)營控制工作,；

協(xié)助上級組織好對開發(fā)項目施工過程的工程、材料,、設備款項撥付的審核工作,； 完成上級交辦的其他任務。

◆具有項目管理理論與經(jīng)驗,；

◆熟悉項目管理方法和管理工具,； ◆熟悉立項流程，熟知項目申報程序,； ◆有一定的英語閱讀水平,；

◆熟練使用辦公軟件。態(tài) 度：

◆踏實嚴謹,，誠實敬業(yè),，積極主動，靈活應變,；◆溝通協(xié)調能力強,，有團隊精神；

◆工作態(tài)度認真,，能在較大的壓力下保持良好工作狀態(tài),。

IT項目經(jīng)理崗位職責篇三

軟件開發(fā)管理體會

從畢業(yè)至今，大小的項目做了一些,，有不少成功的喜悅,，也有很多失敗的教訓。今年由于工作需要,，我以軟件項目負責人的身份參加了接入網(wǎng)統(tǒng)一網(wǎng)管系統(tǒng)開發(fā)的整個過程,。從中學到了不少知識，有許多體會,想將自己的感受寫出來,，與大家共勉,。

軟件項目管理是一個龐大而復雜的系統(tǒng)工程，當前業(yè)界對于軟件開發(fā)流程有不少規(guī)范和定義,，如cmm和iso9000,。在該管理體系的管理下是可以開發(fā)出高質量的軟件產(chǎn)品。但是由于該體系較適合于大型而且復雜項目的團隊開發(fā),，真正實施尚需要時間和過程,。而我們當前執(zhí)行的項目，一般只有10個人左右,，要實施軟件工程難度更大,。我認為：雖然項目大小不一，但管理方法是相通的,，要做好軟件開發(fā)工作,，就必須加強有效管理,。

大家知道，“軟件危機”起源于一些大型項目的不斷延遲甚至失敗,。與大項目相比,，小項目具有以下特點:

· 項目功能相對較少 ；

· 開發(fā)人員較少,；

· 開發(fā)周期較短,。

小項目看起來比較簡單，比較容易成功,，人們往往容易忽視小項目的管理,，其實這是一種誤解。

據(jù)我了解,，小項目開發(fā)中容易出現(xiàn)以下問題：:

1,、開發(fā)之前沒有認真地進行項目可行性和工作量的估計。

往往由于項目較小,，便很草率地制定一個開發(fā)日程表,，沒有認真地估計項目難度，結果實際完成時間與估計完成時間往往有較大差距,。

2,、沒有真正的設計過程 。

開發(fā)人員少,，不同人員的程序之間交互,、接口相對少一些。開發(fā)周期短往往是幾個人從頭到尾負責一個項目,，幾個人碰一下頭,，討論一下最基本的數(shù)據(jù)結構、函數(shù)接口便分頭去做自己的工作了,，沒有一份較正式的文檔來規(guī)范各自職責和項目細節(jié),。

這種做法潛在的危險之一是有人可能會對所討論的接口、結構理解有偏差,，可能會造成以后的返工,。

另一個潛在的危險是由于討論時忽略了某些情況，等大家都按時完成分工任務后,，才發(fā)現(xiàn)各個模塊組合起來卻無法形成一個完整的系統(tǒng),。其根源在于沒有一個負責協(xié)調的人員不斷監(jiān)控整個開發(fā)過程。

第三個潛在的危險是一旦有人中途退出開發(fā)隊伍,，其他人加入時,，難以理解以前別人做好的代碼，又要從頭做起,。另外,，沒有文檔的程序,，日后維護和版本升級都比較困難。

3,、不經(jīng)過單元測試而直接進入系統(tǒng)測試 。

造成這一現(xiàn)象的原因是每個模塊相對比較簡單,，但是為了測試一個模塊需要建立一些測試環(huán)境,。例如，為了測試一個函數(shù)是否正確,，應該用一些測試數(shù)據(jù)去調用該函數(shù),，需要編寫一些測試數(shù)據(jù)。但很多開發(fā)人員嫌麻煩,，覺得反正其他模塊也很快出來了,，直接用真正的數(shù)據(jù)來運行幾次就行了。

針對以上問題,，我認為在開發(fā)過程中必須處理好四個關鍵問題,，嚴格把關，可以大大提高軟件的質量,。

這四個關鍵問題為：人員,、規(guī)范、測試,、時間控制,。

一、合理配置人員

首先軟件開發(fā)是一項長期艱苦的工作,，所以一個團結,、協(xié)作的團體才能在規(guī)定的時間內完成一個質量上乘的軟件項目。團隊中的每個人必須積極融入到整個集體中,，不能互相推諉,，更不能互相埋怨和指責，正確的態(tài)度是大家在充分信任的基礎上團結協(xié)作,，互相幫助,，主動承擔任務, 利用集體的智慧獲得成功。整個團隊就是一部機器,，只有每一個齒輪都能正常運作,，才能生產(chǎn)出優(yōu)質的產(chǎn)品。

合理配備人員是成功完成軟件開發(fā)項目的切實保證,。所謂合理配備人員應包括按不同階段適時運用人員,，恰當掌握用人標準。一般來說,，軟件項目不同階段,、不同層次技術人員的參與情況是不一樣的,。圖一是典型的軟件開發(fā)人員參與情況與實際人員需求差異曲線圖。

如人員配置不當,，很容易造成人力資源的浪費,，并延誤工期。特別是采用恒定人員配備方案時,，在項目的開始和最后都會出現(xiàn)人力過剩,，而在中期又會出現(xiàn)人力不足的情況。

為開發(fā)人員創(chuàng)造出一個人盡其才的環(huán)境也是項目成功的重要環(huán)節(jié),，讓他們能得心應手的施展自己的才華,，特別在工作安排上要煞費苦心，針對每個人不同的特長,，根據(jù)項目的具體環(huán)境和條件來合理安排人員在恰當?shù)膷徫簧稀?/p>

項目負責人是一個團隊的核心,，其綜合素質直接影響項目的成敗。合格的項目負責人具有高超的領導才能和強烈的科技意識和較強的業(yè)務處理能力,；具有敏銳的洞察力,，能瞄準目標，實事求是,，精心組織,，堅決果斷，靈活應變,，享有信譽,；善于制定計劃，解決問題,，溝通信息,；具有良好的市場意識和交際能力。當然同時滿足這些條件比較困難,，但是他應該具有實現(xiàn)這些素質的條件,，并注重經(jīng)驗的積累、素質的提高,、能力的培養(yǎng),。并能從以下幾方面嚴格要求和培養(yǎng)自己：

以身作則：只有身先士卒，各方面以身作則,，才能得到廣大開發(fā)人員的認可和信任,，才能樹立較高的威信。

果斷抉擇：負責人的重要任務是決策,，特別是有多種選擇的情況下,，一個正確的選擇往往事半功倍。

善于交際：他必須積極對外聯(lián)絡，充分利用外部資源,，例如其他部門做過類似項目者,，可以向他們取經(jīng)甚至直接獲得源碼。這對一個項目爭取時間,，避免重復工作很重要,。

善于協(xié)調：協(xié)調幾個人的工作比自己完成一段編碼更重要。由于協(xié)調不力,，將影響開發(fā),。所以項目負責人除完成自己的編程任務外，必須隨時監(jiān)控各開發(fā)人員的工作,，包括內容是否與要求發(fā)生偏差，進度是否滯后等等,。

善于制定計劃：在開發(fā)前,，可將明確的開發(fā)任務通過文檔傳遞給每個開發(fā)人員，讓大家都熟悉設計模型,，都清楚自己所做的工作在整個系統(tǒng)中處于什么地位,，這樣有時侯可能會發(fā)現(xiàn)設計模型中的漏洞，避免了各人的代碼編寫完畢之后又要修改的后果,。

溝通問題：團隊溝通不是技術問題,，但卻是一個最能影響工作效率的問題。溝通及時,、集思廣益,、步調一致，才能取得勝利,。

二,、嚴格執(zhí)行軟件開發(fā)規(guī)范

軟件開發(fā)需要嚴格按照軟件規(guī)范實施。用手工作坊式的方式來開發(fā)軟件,，其結果必然失敗,。從項目的用戶需求分析、系統(tǒng)分析,、編碼,、調試、測試,、發(fā)布都需要一步一步完成,，不能輕視或忽略任何一步驟。前部分沒有完成好,，不要貿(mào)然進行下一步,。越是項目起步階段，越是要注意按照規(guī)范進行。

如前所述,，因為開發(fā)軟件項目規(guī)模較小,，很容易忽視規(guī)范化，而隨心所欲,，沒有計劃,，想到哪做到哪，其最終的結果是失去控制,。其實項目小正是實現(xiàn)軟件規(guī)范化管理的好時機,，規(guī)模

小，涉及的管理方面有限,，管理實施起來比較容易,。cmm等規(guī)范標準不是輕而易舉就能實現(xiàn)的，但是可以借鑒它的思想和方法,，先在小項目上實現(xiàn)規(guī)范化管理,，培養(yǎng)人員的規(guī)范和意識，為以后實現(xiàn)大項目的cmm等規(guī)范打下良好的基礎,。

特別需要重視軟件開發(fā)中文檔管理,。那種認為只要產(chǎn)品做出來可以運行，何必花費許多精力去做文檔的觀點是錯誤的,。經(jīng)過實踐,，我深刻體會到，沒有文檔會帶來很多問題,。用文檔去引導開發(fā)過程,，拋棄隨心所欲的開發(fā)模式。就象工廠工人師傅按照圖紙生產(chǎn)零件一樣,，否則很可能會得到次品甚至是廢品,，給后來開發(fā)者留下一堆沒有意義的“垃圾”產(chǎn)品。我認為文檔應該是開發(fā)中階段（ｍilestone）結束的標志,，每個階段后,，都需要提交相應的文檔，而且要確保文檔的質量,。

確保文檔質量的最有效方法就是評審,，提交文檔后，項目負責人組織相關人員對該文檔進行審核,，在充分討論的基礎上進行文檔的重新修改和審核直到滿足項目要求,。文檔應該是貫穿整個過程的主線，在不同的階段,，需要不停地對文檔進行完善,，使之真正成為全體項目人員的智慧結晶,。

三、

測試是軟件開發(fā)中容易忽視的問題,，許多人認為開發(fā)的主要工作是編碼,，其實不然，在沒有嚴格執(zhí)行開發(fā)流程的開發(fā)活動中,，測試可能是唯一能確保軟件質量的方法和手段,。而越是松散的項目越輕視測試活動，它既沒有固定的測試組織,，又沒有程序員間的交叉測試,，更沒有考慮過有效的測試流程和方法，他們的軟件質量完全建立在對程序員能力信任的基礎上,，這是很不安全的,。

測試是對軟件產(chǎn)品質量的檢驗和評價。它一方面檢查軟件中存在的質量問題,，同時對產(chǎn)品質量進行客觀的評價,。

我們一般把發(fā)現(xiàn)的錯誤bug(我們也稱為缺陷defect)按嚴重性分為四類：死機(系統(tǒng)崩潰或掛起)、致命(使系統(tǒng)不穩(wěn)定,、或破壞數(shù)據(jù)、或產(chǎn)生錯誤結果,，而且是常規(guī)操作中經(jīng)常發(fā)生或非常規(guī)操作中不可避免的),、嚴重(系統(tǒng)性能或響應時間變慢、產(chǎn)生錯誤的中間結果但不影響最終結果,，如：顯示不正確但輸出正確),、一般(界面拼寫錯誤或用戶使用不方便)。

我們也把發(fā)現(xiàn)的錯誤按優(yōu)先級分為三種：高,、中,、低。一般是某錯誤對用戶接受或使用影響越大其優(yōu)先級越高,。

要完成嚴格的測試,，就必須建立規(guī)范的系統(tǒng)測試流程，有專人負責執(zhí)行,，而且開發(fā)人員要積極配合,，不要認為測試人員是在給自己找麻煩，測試人員查找的錯誤可能是程序員無法發(fā)現(xiàn)的錯誤,。

一般的測試流程應該是：

1,、項目組提交系統(tǒng)測試申請給測試中心指定帳號。由專人檢查文檔格式和完備性,。

2,、檢查合格后交給該產(chǎn)品對應方向的研究人員，評價其內容的有效性和真實性。

3,、檢查合格后由測試中心主任審查并通過,，成立測試組，指定測試組長(可暫時沒有組員),。

4,、測試組長根據(jù)該產(chǎn)品的申請報告、測試設計和以往測試數(shù)據(jù),，制定測試方案,。

5、測試中心主任審核通過測試方案后,，根據(jù)測試方案指定測試組成員,，并由支持組完成其他支持任務(如：設備的配備、測試數(shù)據(jù)庫的建立,、網(wǎng)絡權限的修改??),。

6、測試期間測試組根據(jù)測試方案進行實際測試,，記錄并跟蹤測試缺陷報告,，填寫測試記錄。測試組長與項目組(測試經(jīng)理)經(jīng)常溝通,，并獲取產(chǎn)品的更新版本,。同時，測試組長審查,、修改并提交所有缺陷報告,，保證隨時掌握產(chǎn)品的質量情況，并監(jiān)督測試進度,。

7,、產(chǎn)品進行到一定階段后(標志是測試缺陷報告庫中所有的報告處于歸檔狀態(tài))，由項目組和測試組長共同決定產(chǎn)品進入穩(wěn)定期測試,。穩(wěn)定期測試版本之前的版本必須在顯著位置標明為測試版字樣,。

8、穩(wěn)定期測試期間所發(fā)現(xiàn)的缺陷報告也需要記錄在測試缺陷報告庫中,，并在穩(wěn)定期結束后由雙方(有時可能也有市場方面的意見)共同決定對這些缺陷的處理方式,。如果需要改動產(chǎn)品，則重新開始穩(wěn)定期,，否則通過穩(wěn)定期測試,。

9、測試組長對于通過穩(wěn)定期測試的產(chǎn)品填寫綜合測試報告,，測試中心依此發(fā)布產(chǎn)品發(fā)行通知,。

10,、測試組對整個測試過程和產(chǎn)品質量進行總結和評價，形成文檔并備案,。同時,，將測試過程中對測試設計的改動納入基線（是已經(jīng)通過正式復審核批準的某規(guī)約或產(chǎn)品，是軟件開發(fā)中的里程碑）,。最后,，組長整理并在指定地點保存相關測試數(shù)據(jù)和測試樣張。

11,、測試中心解散測試小組,。

另外，在系統(tǒng)測試階段,，我們要求測試小組要進行一些常規(guī)內容測試(如：y2k測試,，病毒檢查、裸機測試,、加密檢查,、說明書檢查??)，并要求寫入測試方案中,。

測試應該在現(xiàn)實的環(huán)境中進行,。所謂現(xiàn)實環(huán)境就是與用戶實際使用的環(huán)境相同或相近，因為開發(fā)環(huán)境和用戶使用環(huán)境有很大區(qū)別的,，而開發(fā)的產(chǎn)品最終是要交給用戶使用的,。如果沒有辦法模擬用戶環(huán)境，則程序員可能必須自己開發(fā)一些模擬程序來模擬現(xiàn)實環(huán)境,。特別是與硬件配合的項目，因為在程序調試時硬件可能沒有完全完成,，這時就必須開發(fā)模擬硬件的程序,，否則開發(fā)的進度可能無法保證。

四,、時間控制

開發(fā)人員最擔心 “領導不斷催促,，可系統(tǒng)提交日期一拖再拖”，項目負責人對此一籌莫展,，束手無策,。開發(fā)活動如同一個黑箱子，資金扔進去了,，人員扔進去了,，設備資源扔進去了，但不知道什么時候會出來結果,，更沒有把握出來的東西是否是用戶所要的東西,。為避免人力,、物力、財力浪費,，要做好項目計劃,，進行有效的時間控制。

軟件項目管理過程開始于項目的計劃,，在做項目計劃時,，第一項活動是估算。現(xiàn)在已經(jīng)使用的技術是時間和工作量的估算,。因為估算是其他項目計劃活動的基石,，而且項目計劃又為軟件工程過程提供了工作方向，所以我們不能沒有計劃就著手開發(fā),，否則就會陷入誤區(qū),。軟件項目的進度安排主要是考慮軟件交付用戶使用的這一段開發(fā)時間的安排。進度安排的準確程度可能比成本估計的準確程度更重要,。軟件產(chǎn)品可以靠重新定價或者靠大量的銷售來彌補成本的增加,，但進度安排的落空會導致市場機會的喪失或者用戶不滿意，而且也會導致成本的增加,。因此在考慮進度安排時要把人員的工作量與花費的時間聯(lián)系起來,，合理分配工作量，利用進度安排的有效分析方法嚴密監(jiān)視軟件開發(fā)的進展情況,，以使得軟件開發(fā)的進度不至于被拖延,。

在作進度安排時要考慮的一個主要問題是任務的并行性問題。當參加項目的人數(shù)不止一人時,，軟件開發(fā)工作就會出現(xiàn)并行情況,。因為并行任務是同時發(fā)生的，所以進度計劃表必須決定任務之間的從屬關系,，確定各個任務的先后次序和銜接,，確定各個任務完成的持續(xù)時間。另外還應注意關鍵路徑的任務,，這樣可以確定在進度安排中應保證的重點,。常用的進度安排方法有兩種，即甘特圖（gantt chart）法和工程網(wǎng)絡法,。

項目怎么樣才能算做好了,，也是各有各的看法，我對項目成功的定義為,，“三贏”的項目,，才算是真正成功的項目。三贏包括,，用戶滿意,；公司滿意,；項目參與人員滿意。

為用戶服務,、讓用戶滿意：用戶指提供資金并且最終使用項目結果的所有人員,，項目的開發(fā)過程和最終結果，要讓用戶認可,、使用,，并讓用戶說好。此為一贏,。

讓公司滿意：項目開發(fā)要按時保質保量地完成,，并為公司積累項目經(jīng)驗、知識儲備,，包括項目,、人才、技術,、市場等各方面的儲備,。此為二贏。

讓項目參與人員滿意：要讓開發(fā)人員在項目中專注地完成任務,，免受項目之外的因素干擾,。正常、優(yōu)秀地完成項目,，對開發(fā)人員本身也是一種巨大的鼓勵,。還要讓供應商深知其設備、軟件的使用情況,，讓項目的成功成為供應商的成功,，為下一次的更好合作打下基礎。

初為開發(fā)負責人,，需要不斷積累經(jīng)驗,，我書寫此文目的在于拋磚引玉，爭取和大家一同將我們的項目做得更完美,。歡迎各位指教,。