某軟件項(xiàng)目開發(fā)流程

1、某軟件項(xiàng)目開發(fā)流程修改歷史日期作者修改內(nèi)容2003-03-12張京宇新規(guī)制作2003-5-18張京宇人員職責(zé)的變更，內(nèi)容的變更2003-12-4張京宇針對2004年度制作最新工作內(nèi)容下的工作流程2004-1-14張京宇添加項(xiàng)目經(jīng)理管理被職員填寫卜.周日程表的規(guī)則1 概述1.1 目的用標(biāo)準(zhǔn)化的流程來統(tǒng)一管理公司的運(yùn)作，避免混亂，提高管理的質(zhì)量。在遠(yuǎn)程開發(fā)上，結(jié)果XX軟件自身的特點(diǎn)，量身定做，解決遠(yuǎn)程開發(fā)上的問題。在實(shí)施過程中，所有管理者能夠根據(jù)此統(tǒng)一的流程，總結(jié)經(jīng)驗(yàn)，提高認(rèn)識，加強(qiáng)技術(shù) 水平和管理水平。提高公司級的技術(shù)分析能力，為公司儲備一支分析隊(duì)伍，側(cè)重在需求理解和需求分析、框架設(shè)計(jì)上的能力。

2、保證在2004年能夠全盤進(jìn)行中方市場的順利運(yùn)作。對人員負(fù)責(zé)內(nèi)容上，明確化各自負(fù)責(zé)的內(nèi)容，提高工作效率。1.2 內(nèi)容概述開發(fā)部日常工作流程開發(fā)部管理流程開發(fā)部績效考核流程開發(fā)部激勵(lì)和過失管理流程2 開發(fā)部日常管理流程具體實(shí)施方案2.1 基本原則公司開發(fā)部力求建立公平公正的評價(jià)體系，嚴(yán)謹(jǐn)?shù)墓ぷ髁鞒潭x和及時(shí)的記錄與反饋,規(guī)范職員活動(dòng)，形成一個(gè)緊張有序的團(tuán)隊(duì)。沒有一個(gè)明晰的流程和高效的反饋體系，就不可能把工作做好。但是，這需要每個(gè)人 按照規(guī)則把自己應(yīng)該負(fù)責(zé)的那一部分高效完成，只有這樣才能保證整個(gè)系統(tǒng)的順暢， 同時(shí)，如果個(gè)人沒有完成自己的指責(zé)和按照規(guī)定填寫內(nèi)容，影響的不單單是自己的工 作而是整個(gè)系統(tǒng)。

3、2.2 內(nèi)容概述Esm使用規(guī)則目的注意是為了提高開發(fā)部整體的計(jì)劃能力，反饋能力和管理者的控制能力。同時(shí)提 高整體職員參與公司管理的渠道，適應(yīng)東京上市公司對信息管理的要求。日常活動(dòng)的方法提供開發(fā)部工作流程外的突發(fā)事件的解決方法2.3 內(nèi)容詳細(xì)描述2.3.1 Esm使用規(guī)則(1) schedule 的使用加強(qiáng)全體人員的計(jì)劃能力，做到我每天要做什么？今天項(xiàng)目經(jīng)理給我的安排是什么？ 對應(yīng)項(xiàng)目經(jīng)理和部長要知道每個(gè)人在做什么？只有這樣，才能保證控制人員可以宏觀 調(diào)控，而個(gè)人也不會(huì)不知所措。注意事項(xiàng)：1 .必須使用長期類型(哪怕只有一天)保持統(tǒng)一性2開始時(shí)間必須為22: 00結(jié)束時(shí)間為23: 00,（為了區(qū)

4、分其它人填寫的日程安排）3填寫日程安排時(shí)，必須選擇對應(yīng)的 anken,否則不能于系統(tǒng)內(nèi)的項(xiàng)目關(guān)聯(lián)，統(tǒng)計(jì)軟 件失去作用。4日程安排的主題要修改，規(guī)則為項(xiàng)目號（中文版項(xiàng)目為北京內(nèi)部項(xiàng)目編號），暫時(shí)沒有編號可以寫項(xiàng)目名稱。內(nèi)容負(fù)責(zé)人填寫要求監(jiān)督人違規(guī)處理下周 工作 安排項(xiàng)目經(jīng)理 技術(shù)分析 負(fù)責(zé)人 測試組經(jīng) 理必須每周五16: 00前填寫完畢。 同時(shí)類型統(tǒng)一用長期進(jìn)行定義， 為每一個(gè)人員安排下周工作計(jì) 戈|J。填寫監(jiān)督： 項(xiàng)目總控助 理內(nèi)容監(jiān)督： 部長和項(xiàng)目 總控人員沒有按時(shí)提交的，管理者扣除MD 0.2日常 活動(dòng) 安排開發(fā)部全 體人員建議大家把工作安排填寫，有利 于提高自己的計(jì)劃能力和規(guī)劃能 力。同

5、時(shí)能保證事情小會(huì)忘記。無待辦 事項(xiàng)開發(fā)部全 體人員建議填寫，管理者應(yīng)該必須使用。 主要是把事務(wù)管理的井井有條。無制作 下周 工作 安排 表項(xiàng)目總控 助理負(fù)責(zé)利用工具【導(dǎo)出下周工作表 系統(tǒng)】制作開發(fā)部下周工作計(jì)劃 表。每周五卜班前發(fā)送東京。東京項(xiàng)目負(fù) 責(zé)人（2）Report的使用作為上市公司的子公司要求公司正規(guī)化，第一步公司的日報(bào)系統(tǒng)的建立和審 查，所以從本年度起必須建立此系統(tǒng)。同時(shí)，在管理上解決口頭匯報(bào)，不客觀而事后而無據(jù)可查的弊端，為及時(shí)了解問題并解決問題，提供第一手的素材。同時(shí)項(xiàng)目總控助理，也要本著實(shí)事求是的原則，根據(jù)大家的填寫內(nèi)容向東京 證券市場提交作業(yè)公務(wù)表，所有填寫者一定要保證填寫日

6、報(bào)的消耗工時(shí)和最后工資 結(jié)算時(shí)當(dāng)日工時(shí)保持嚴(yán)格一致 。內(nèi)容對應(yīng)esm的名稱填寫要求監(jiān)督人違規(guī)處理項(xiàng)目選 擇項(xiàng)目直接選擇自己對應(yīng)的項(xiàng)目，如果工作對象不是項(xiàng)目本身則需要選 擇以下項(xiàng)目：（顧客名稱為 2004 年過程管理專用） 公司會(huì)議 公司培訓(xùn)公司管理其它注意：只有部長以上才填寫以上 項(xiàng)目（公司培訓(xùn)除外，部長以下 全部選擇對應(yīng)項(xiàng)目。見附圖1X X扣除MD 0.1當(dāng)日工工作內(nèi)容1.填寫當(dāng)日的模塊名稱（模塊填寫監(jiān)督：沒有填寫1次人作內(nèi)容 和進(jìn)度與進(jìn)度名稱參考2 .中的功能點(diǎn)表）3 .細(xì)度要求功能點(diǎn)X X內(nèi)容監(jiān)督： 項(xiàng)目經(jīng)理民幣5元工作耗 時(shí)工作耗時(shí)要求與工資計(jì)算工時(shí)想對應(yīng)。（esm中數(shù)據(jù)庫的數(shù)字和工時(shí)

7、統(tǒng) 計(jì)必須對應(yīng)，此為東京證券的要 求）數(shù)字核對：X X數(shù)字不對者，按 照一次扣除0.1MD問題反 饋問題反饋把當(dāng)天所遇到的問題按照條目化羅列。必須包含內(nèi)容和狀態(tài)兩部分例如：1內(nèi)容：BS詳細(xì)頁面存在老bug,狀態(tài)：已經(jīng)解決2內(nèi)容：文檔2.3出現(xiàn)問題，無法繼續(xù)。 狀態(tài)：等待解決內(nèi)容監(jiān)督： 項(xiàng)目經(jīng)理不付責(zé)任的亂填 或小填，一個(gè)日 報(bào)扣除0.1MD（如 果在特殊情況下 無問題，也要寫 無）MD俞入訂貨（預(yù) 定）金額必須在項(xiàng)目總結(jié)會(huì)議結(jié)束之后，同時(shí)要經(jīng)過項(xiàng)目經(jīng)理的審核。輸入值為實(shí)際值的10倍（因?yàn)閿?shù) 值型目前只能為整數(shù)）職員的輸入 由項(xiàng)目經(jīng)理項(xiàng)目經(jīng)理的 核對由項(xiàng)目 總控助理進(jìn) 行職員如果不填寫 則按照輸

8、入值進(jìn) 行績效考核。如果職員輸入的 MD與分配時(shí)不符 合項(xiàng)目經(jīng)理扣除0.5MD附圖1:（3） 周報(bào)(Week Report)日報(bào)(Daily Report )的使用主要是使用對象為管理者，主要是適用于向管理者匯報(bào)整體問題。在概念上，日報(bào)周 報(bào)為概括說明，而report則屬于細(xì)節(jié)描述。內(nèi)容負(fù)責(zé)人填寫要求監(jiān)督人違規(guī)處理日報(bào)項(xiàng)目經(jīng)理部長 一部長項(xiàng)目進(jìn)展?fàn)顩r：不能解決的問題反饋建議或提議突發(fā)問題必須反饋項(xiàng)目總控人員如果由于沒有匯報(bào)造成 問題，按一次扣除0.5MD周報(bào)項(xiàng)目經(jīng)理部長部長項(xiàng)目總 控項(xiàng)目進(jìn)展整體狀況： 不能解決的問題反饋 建議或提議必須填寫項(xiàng)目總控助理周報(bào)不寫，按一次扣除0.2MD（4） 目標(biāo)

9、功能的使用由于分部內(nèi)有單獨(dú)的激勵(lì)費(fèi)用，所以建議分部內(nèi)建立目別考核體系。為每一個(gè)程序員 根據(jù)個(gè)人不同的能力和狀況設(shè)定目標(biāo)，對于圓滿完成目標(biāo)者進(jìn)行鼓勵(lì)。同時(shí)，保證公 司的開發(fā)效果在可控制范圍內(nèi)。（5） 項(xiàng)目信息管理的使用。本管理系統(tǒng)在2003年開始實(shí)行，主要目前是記錄公司所有項(xiàng)目的里程碑信息。為以后 項(xiàng)目的整理和后期處理提供真實(shí)的數(shù)據(jù)。同時(shí)，維護(hù)公司的項(xiàng)目信息數(shù)據(jù)庫。注意事項(xiàng)：其中關(guān)于項(xiàng)目中所設(shè)計(jì)的文檔，統(tǒng)一放在fileserver 上2004目錄中。關(guān)于文檔名稱和路徑的書寫方法如下，保證能夠盡快打開文檔：/fileserver/project/2004/14258/測試用例 /14258_tes

10、tcase.xls2004年1月1號起，東京新項(xiàng)目項(xiàng)目要求對應(yīng)負(fù)責(zé)人出錯(cuò)處理方法備注項(xiàng)目名稱必填，同時(shí)應(yīng)有對 應(yīng)的項(xiàng)目號X X扣除MD 0.1北京項(xiàng)目編號必填X X扣除MD 0.1添加時(shí)一定要注意 唯一性，與項(xiàng)目類型不能為空，目前類型有ResearchNormalConfirmMergeOthersX X扣除MD 0.1目前的規(guī)則為小于5md 的均 為RESEARCH 目項(xiàng)目名稱必填X X扣除MD 0.1項(xiàng)目的名稱應(yīng)包含 項(xiàng)目的ID,關(guān)于項(xiàng) 目ID的生成方法， 參考日方對應(yīng)文檔客戶方負(fù)責(zé)人必填X X扣除MD 0.1分析負(fù)責(zé)人北京分析項(xiàng)目，為必填項(xiàng)目東京設(shè)計(jì)，為非必 填部長（但是必須制 定具體負(fù)

11、責(zé)人）扣除MD 0.1項(xiàng)目負(fù)責(zé)人必填項(xiàng)目部長扣除MD 0.1項(xiàng)目負(fù)責(zé)人應(yīng)該是 直接負(fù)責(zé)人（不是 最先指定的部長）本公司負(fù)責(zé)人不能為空初始必填的人員為 項(xiàng)目總控人員及助 理、對應(yīng)部長、測 試部經(jīng)理，公司技 術(shù)負(fù)責(zé)人（馬俊）X X項(xiàng)目負(fù)責(zé)人扣除MD 0.1如果沒有項(xiàng)目負(fù)責(zé) 人，與xx聯(lián)系分析開始時(shí)間必填對應(yīng)該項(xiàng)目的分析員扣除MD 0.1公司技術(shù)負(fù)責(zé)人在 分析項(xiàng)目開始時(shí)應(yīng) 把對應(yīng)分析員加到 項(xiàng)目列表中概要設(shè)計(jì)完成時(shí)間必填對應(yīng)該項(xiàng)目的分析員扣除MD 0.1詳細(xì)設(shè)計(jì)完成時(shí)間必填對應(yīng)該項(xiàng)目的分析 員扣除MD 0.1FP文檔完成時(shí)間必填對應(yīng)該項(xiàng)目的分析 員扣除MD 0.1分析完畢時(shí)間必填對應(yīng)該項(xiàng)目的分析 員

12、扣除MD 0.1項(xiàng)目接收時(shí)間必填X X扣除MD 0.1項(xiàng)目最終對應(yīng)MD原則不為空，在特 殊情況下為空，在 項(xiàng)目備注重必須說 明原因。X X項(xiàng)目經(jīng)理（Mail通知）扣除MD 0.1本MD半隨著MD的 變更需要?jiǎng)討B(tài)變化Md變更附件名稱不是必須，但是只 要有變更有內(nèi)容， 此項(xiàng)目必須要有X X項(xiàng)目經(jīng)理（Mail通知）扣除MD 0.1項(xiàng)目最終報(bào)價(jià)原則不為空，在特 殊情況下為空，在 項(xiàng)目備注重必須說 明原因。X X扣除MD 0.1必須與對應(yīng)MD*11000 基本一致。同時(shí)必須和 MD 變更紀(jì)錄一致Schedule文檔名稱及路徑必填項(xiàng)目經(jīng)理扣除MD 0.2可以用excel或者 是 visio , proje

13、ct 后兩種要以HTM的 出以便查閱?？蛻舴絛eadline要求如果提供必填X X扣除MD 0.1Alfa版時(shí)間必填X X項(xiàng)目經(jīng)理（Mail通 知）扣除MD 0.1Beta版時(shí)間必填X X項(xiàng)目經(jīng)理（Mail通 知）扣除MD 0.1Alfa變更紀(jì)錄最后一次記錄變更 的時(shí)間必須和對應(yīng) 的alfa版時(shí)間和 beta版時(shí)間一致X X項(xiàng)目經(jīng)理（Mail通 知）扣除MD 0.1項(xiàng)目開始時(shí)間必填X X項(xiàng)目經(jīng)理（Mail通知）扣除MD 0.1CSV支號必填項(xiàng)目經(jīng)理扣除MD 0.1此分支號為開發(fā)分支號功能點(diǎn)文檔文件名及文件路徑（FileServer 服務(wù)器）必填項(xiàng)目經(jīng)理扣除MD 0.1此文檔為必須文 檔，各項(xiàng)目

14、經(jīng)理必 須嚴(yán)格控制。單體測試用例文件 名稱及文件路徑必填項(xiàng)目經(jīng)理扣除MD 0.1此文檔為必須文 檔，各項(xiàng)目經(jīng)理必 須嚴(yán)格控制項(xiàng)目總結(jié)與 MD分必填項(xiàng)目經(jīng)理扣除MD 0.1此文檔為必須文配方案文檔及文件 路徑檔，各項(xiàng)目經(jīng)理必 須嚴(yán)格控制。測試負(fù)責(zé)人必填X X扣除MD 0.1測試用例對應(yīng)文 件名稱及路徑必填X X扣除MD 0.1此文檔為必須文 檔，各項(xiàng)目經(jīng)理必 須嚴(yán)格控制。第一階段測試開 始時(shí)間：必填測試人員扣除MD 0.1第一階段測試完 成日期：必填測試人員扣除MD 0.1Alfa版本后的BUG必填測試人員扣除MD 0.1回歸測試的開始 日期：必填測試人員扣除MD 0.1回歸測試的結(jié)束 日期：必

15、填測試人員扣除MD 0.1Beta版后的BUG數(shù)：必填X X扣除MD 0.1主要要參考beta后 bug的整理表確認(rèn)負(fù)責(zé)人不是必須，主要是 與是否進(jìn)行確認(rèn)有 關(guān)，如果確認(rèn)其他 有信息，確認(rèn)負(fù)責(zé) 人必填X X扣除MD 0.12.3.2系統(tǒng)的使用(1) 電子打卡系統(tǒng)的使用目的：主要是利用電子打卡，提高效率，能夠及時(shí)反映請假和遲到，并且所有的數(shù)據(jù)能夠直接被人事利用。要求：2004年2月開始啟用，2月為試用期，但是要求每人必須嚴(yán)格填寫，如果不填寫并結(jié)合打卡， 忘記填寫扣除過程管理 MD 0.1計(jì)算。(2) 會(huì)議室、洽談室、經(jīng)理室的使用管理目的：主要是在人數(shù)多而會(huì)議室相對緊張的狀態(tài)下，解決矛盾的一種方法

16、。同時(shí)審核各項(xiàng)目組是否及時(shí)安排公司規(guī)定的兩次會(huì)議。2004年2月啟動(dòng)，沒有按照規(guī)定進(jìn)行會(huì)議，經(jīng)審核后，扣除項(xiàng)目經(jīng)理過程管理MD0.2,忘記登錄的按照統(tǒng)一標(biāo)準(zhǔn)處理。2.3.3公司內(nèi)部論壇的使用主要是要有利于公司內(nèi)部開辟一塊公司可以自由發(fā)表言論的地方。同時(shí)，在技術(shù)討論上，希望能夠把知識點(diǎn)做一個(gè)累計(jì)，以便新員工能夠進(jìn)行參 考和積極發(fā)表意見。3 開發(fā)部管理流程具體實(shí)施方案3.1 內(nèi)容概述開發(fā)部從流程上主要分為以下幾方面：(1) 開發(fā)部管理人員工作流(2) BUGSurvey工作流(3) 項(xiàng)目分析工作流(4) Beta后質(zhì)量保證工作流(5) 測試組beta前工作流(6) 項(xiàng)目組運(yùn)行基本工作流開發(fā)部從實(shí)施

17、人員角色劃分如下：開發(fā)部經(jīng)理：( DM01)統(tǒng)籌解決公司開發(fā)部的全部事宜。進(jìn)行開發(fā)部的整體計(jì)劃的制定和實(shí)施，保證開發(fā)部的可持續(xù)發(fā)展和利潤率。項(xiàng)目總控人員：(DM02)對公司級的資源進(jìn)行調(diào)配，同時(shí)，直接了解日方的戰(zhàn)略安排，為北京方的戰(zhàn)略安排提供的第一手的資料。同時(shí)，在項(xiàng)目分配上保證三個(gè)分部間項(xiàng)目的均衡(一個(gè)季度內(nèi))開發(fā)部部長：(DM10)在公司統(tǒng)一的規(guī)則范圍內(nèi)，負(fù)責(zé)分部的建設(shè)。協(xié)調(diào)各開發(fā)組的問題，處理解決分部內(nèi)發(fā)生的問題。做好所有公司要求的標(biāo)準(zhǔn)流程內(nèi)的內(nèi)容。同時(shí)，在許可范圍內(nèi)，可以進(jìn)行單獨(dú)的管理方法的嘗試和分部內(nèi)激勵(lì)的分配。技術(shù)設(shè)計(jì)負(fù)責(zé)人：(DM11)統(tǒng)一協(xié)調(diào)分析組的工作，在對日項(xiàng)目分析組中，進(jìn)

18、行設(shè)計(jì)文檔的統(tǒng)一確認(rèn)，在對中方項(xiàng)目中，承擔(dān)需求的統(tǒng)一把關(guān)處理。同時(shí)負(fù)責(zé)分析組的日常工作安排的統(tǒng)籌。BUG Survey 總負(fù)責(zé)人(DM12)：統(tǒng)一管理package 和已經(jīng)提交項(xiàng)目的統(tǒng)籌管理。組織形式上，傾向于單獨(dú)的組織模式。在目前的情況下，以靈活為主，臨時(shí)性的進(jìn)行bugSurvey 組的組織和bugSurvey 組內(nèi) teamleader 的指定和管理。在間隙階段，直接進(jìn)入分析組進(jìn)行項(xiàng)目分析工作。項(xiàng)目總控助理：XX (DM13)輔助開發(fā)部的項(xiàng)目管理工作，主要負(fù)責(zé)中日雙方的信息的反饋紀(jì)錄整理，以及esm 和taskschedule 信息的維護(hù)工作。負(fù)責(zé)公司級項(xiàng)目文檔，過程參數(shù)的監(jiān)督，同時(shí)向日本

19、總部匯報(bào)各種參數(shù)和報(bào)表。常務(wù)項(xiàng)目經(jīng)理：(DM20) 目前 11 名各分部內(nèi)程序員的日常管理，整個(gè)開發(fā)過程中的控制和日方負(fù)責(zé)人的信息交互，負(fù)責(zé)組內(nèi)程序員的績效考核和問題解決。測試部經(jīng)理和翻譯部經(jīng)理包含在內(nèi)。技術(shù)分析員：(DM21)對日方的需求進(jìn)行概要分析和設(shè)計(jì)，并書寫設(shè)計(jì)書，F(xiàn)P。對中方的項(xiàng)目中，負(fù)責(zé)需求的整理和各種設(shè)計(jì)文檔的實(shí)施，同時(shí)，負(fù)責(zé)和項(xiàng)目經(jīng)理和測試部經(jīng)理的溝通。臨時(shí)項(xiàng)目經(jīng)理：(DM22)此角色主要是在接受日方外包項(xiàng)目或整體公司產(chǎn)品設(shè)計(jì)中，需要臨時(shí)成立項(xiàng)目組，而從分析組中或者常務(wù)項(xiàng)目經(jīng)理中抽調(diào)。臨時(shí)項(xiàng)目經(jīng)理需要全權(quán)負(fù)責(zé)此項(xiàng)目的實(shí)施，同時(shí)需要和公司簽訂項(xiàng)目負(fù)責(zé)保證書，以保證項(xiàng)目的進(jìn)行和最后

20、單獨(dú)項(xiàng)目激勵(lì)的兌現(xiàn)。程序員：主要是負(fù)責(zé)項(xiàng)目按照分析文檔的實(shí)施，同時(shí)，在實(shí)施過程中優(yōu)化代碼結(jié)構(gòu)，提出合理化建議，其中優(yōu)秀者可以作為TeamLeader負(fù)責(zé)具體組織工作和分析管理工作。測試員：負(fù)責(zé)公司測試流程的具體實(shí)施，要求掌握測試的技術(shù)，提出合理化建議，并保證整個(gè)軟件的可靠度。翻譯人員：負(fù)責(zé)中日方文檔的翻譯，要求工作嚴(yán)謹(jǐn)，保證質(zhì)量。在同日方交流中，負(fù)責(zé)接待和溝通。同時(shí)，在個(gè)人的發(fā)展意向中可以兼顧其它公司內(nèi)的常務(wù)工作。1.2 開發(fā)部概要流程圖1.3 開發(fā)部管理人員工作流1.3.1 軟件開發(fā)管理體系構(gòu)成參與人員：項(xiàng)目總控人員（項(xiàng)目總控助理）+部長+（技術(shù)設(shè)計(jì)負(fù)責(zé)人+BugSurvey 負(fù)責(zé)人）+各級

21、項(xiàng)目經(jīng)理管理主線：（ 1）工具類taskschedule 表 ：主要目的是增加遠(yuǎn)程開發(fā)的計(jì)劃和規(guī)劃性。管理人員去合適目前我們正在進(jìn)行的總量有多少，檢收而為付款的有多少，實(shí)施完畢而沒有檢收的有多少。管理人員去看我們下周能夠接受的項(xiàng)目有多少，以便在每周五可以制定下周的工作計(jì)劃。項(xiàng)目經(jīng)理可以看自己負(fù)責(zé)項(xiàng)目的基本參數(shù)。Esm系統(tǒng)：通過esm系統(tǒng)詳細(xì)的記錄開發(fā)過程中的每個(gè)里程碑參數(shù)，保證在管理上能夠提高管理細(xì)度，以便于及時(shí)發(fā)現(xiàn)并改正問題和錯(cuò)誤。Bug管理系統(tǒng)：作為質(zhì)量控制過程實(shí)際結(jié)果的監(jiān)控。以便總結(jié)質(zhì)量的問題，進(jìn)行反饋。Fileserver 文檔 ：通過文檔管理和整理，保證全部職員能夠隨時(shí)的了解其他項(xiàng)目

22、的信息和相信內(nèi)容。同時(shí)，統(tǒng)一化文檔管理，為以后的發(fā)展提供素材。所有的文檔主要包含如下幾種：HearingSheet ：一個(gè)簡要的需求，重點(diǎn)在于強(qiáng)調(diào)這個(gè)需求的原因（前因后果）UI 文件設(shè)計(jì)文檔：東京和北京共同進(jìn)行FP報(bào)價(jià)書QuestionSheet ：所有的問題一定要集中在一個(gè)文檔內(nèi)功能點(diǎn)文檔：一定要融合questionSheet 內(nèi)對應(yīng)答案的所有內(nèi)容schedule 文檔：要包含甘特圖項(xiàng)目總結(jié)及M防配方案：把項(xiàng)目總結(jié)作為重點(diǎn)進(jìn)行。單體測試用例；條數(shù)最少為MD*2,按照模板進(jìn)行測試組測試用例: 要保證最后的測試結(jié)果確認(rèn)測試用例：一般為東京發(fā)送beta 版后障害書：項(xiàng)目確認(rèn)者發(fā)送，按照同一格式進(jìn)行

23、書寫和填寫。beta 后障害 list 表， 其中包含bug 的簡單描述、bug 的類型確定和各部門關(guān)于bug的總結(jié)。（ 2）過程管理類一個(gè)項(xiàng)目兩次會(huì)議：項(xiàng)目啟動(dòng)會(huì)議和項(xiàng)目總結(jié)會(huì)議項(xiàng)目啟動(dòng)會(huì)議主要是講述項(xiàng)目的功能點(diǎn)，并據(jù)具體問題，進(jìn)行嚴(yán)格的定義，說明本項(xiàng)目所必須遵守的特殊規(guī)則，子功能間的前后順序，統(tǒng)一的接口定義，和每個(gè)人在項(xiàng)目實(shí)施中應(yīng)該注意的問題。項(xiàng)目總結(jié)會(huì)議和 M防配方案的確定。主要是根據(jù)項(xiàng)目實(shí)施的結(jié)果，進(jìn)行集中的討論和諧而公平的團(tuán)隊(duì)：公司其他方面的管理，就是為了加強(qiáng)管理，提倡量化。做到各司其職，多勞多得，公平評價(jià)，提供機(jī)會(huì)給相應(yīng)的人。1.3.2 管理示意圖1.3.3 管理人員注意事項(xiàng)其中反

24、饋機(jī)制的建立最關(guān)鍵。其中管理必須遵守以下規(guī)則:對象流程編R工作內(nèi)容上流力下流方備注項(xiàng)目總控人員分配項(xiàng)目東京項(xiàng)目發(fā)包人員（紀(jì)秀玲）部長項(xiàng)目總控助理解決人力矛盾部長BugSurvey 負(fù)責(zé)人技術(shù)設(shè)計(jì)負(fù)責(zé)人部長BugSurvey 負(fù)責(zé)人技術(shù)設(shè)計(jì)負(fù)責(zé) 人下流方人員負(fù)責(zé)把結(jié)果 反饋給東京擔(dān)當(dāng)者開發(fā)部經(jīng)理公司管理問題部長項(xiàng)目經(jīng)理 各級負(fù)責(zé)人職員全體職員一定要給問題提出者答 復(fù)，成為制度后頒布部長分配項(xiàng)目項(xiàng)目總控人員 項(xiàng)目總控助理對應(yīng)分部項(xiàng)目經(jīng)理項(xiàng)目總控助理Esm項(xiàng)目負(fù)責(zé)人加入，修 改負(fù)責(zé)人為此項(xiàng)目經(jīng)理項(xiàng)目人力調(diào)節(jié)無項(xiàng)目總控人員如果出現(xiàn)空閑同時(shí)反 饋。分部管理問題無開發(fā)部經(jīng)理項(xiàng)目經(jīng)理項(xiàng)目分析和問題確認(rèn)無東京

25、負(fù)責(zé)人結(jié)果物概要需求文檔和 問題與回復(fù)整理文檔項(xiàng)目里程碑信息反饋項(xiàng)目開始時(shí)間，alfa,beta版本時(shí)間和原因，fp變更及原因無項(xiàng)目總控人員 項(xiàng)目總控助理 測試部經(jīng)理組織團(tuán)隊(duì)進(jìn)行技術(shù)文檔 的書寫和維護(hù)無測試部經(jīng)理team所有成員文檔列表如下： 功能點(diǎn)文檔 questionSheetSchedule單體測試用例BugSurvey 負(fù)責(zé)人Bugsurvey 的調(diào)查修改 merge項(xiàng)目總控人員各級的 bug survey leader Bug survey 實(shí) 施人員所有的規(guī)則按照bugsurve流程的規(guī)定。項(xiàng)目總控助理監(jiān)督esm的執(zhí)行情況程序員項(xiàng)目經(jīng)理 部長項(xiàng)目總控監(jiān)督過程管理參數(shù)部長項(xiàng)目經(jīng)理項(xiàng)目

26、總控整理所有項(xiàng)目文檔項(xiàng)目經(jīng)理項(xiàng)目總控對日匯報(bào)表系統(tǒng)數(shù)據(jù)項(xiàng)目總控績效考核提供過程情況 匯總系統(tǒng)數(shù)據(jù)項(xiàng)目總控月度過程管理處理表測試部經(jīng)理組織書寫測試用例項(xiàng)目經(jīng)理(功能 點(diǎn)文檔)東京整理匯總beta版后bug分析表項(xiàng)目經(jīng)理(提供 的完整的B后障 害書)所有管理者其中的技術(shù)分析和管理 分析及對東京的建議應(yīng) 由項(xiàng)目負(fù)責(zé)人進(jìn)行填寫控制測試的結(jié)果1.4 Bugsurvey 工作流參見bugSurvey工作規(guī)約。1.5 項(xiàng)目分析工作流參見項(xiàng)目分析工作規(guī)約1.6 Beta后質(zhì)量保證工作流參見beta后規(guī)作規(guī)約1.7 測試組beta前工作流1.8 項(xiàng)目組基本工作流1.8.1 概述在項(xiàng)目進(jìn)行過程中，要求能夠及時(shí)反饋

27、。做好計(jì)劃安排，并調(diào)整這個(gè)人力的配比，以 達(dá)到最好的效果。1.8.2 對程序員的要求尤其在分析組成立前期，對分析組的設(shè)計(jì)書，盡可能提出建設(shè)性意見和設(shè)計(jì)的問 題，有利于提高項(xiàng)目分析能力在功能實(shí)現(xiàn)上，主要和項(xiàng)目經(jīng)理的溝通，把類結(jié)構(gòu)設(shè)計(jì)和代碼向理想情況努力，同時(shí)用公司內(nèi)的代碼規(guī)范作為自己的行動(dòng)準(zhǔn)則在日常活動(dòng)中，加強(qiáng)團(tuán)體意識，加強(qiáng)責(zé)任感。1.8.3 對項(xiàng)目經(jīng)理的要求主要職責(zé)為：類設(shè)計(jì)的嚴(yán)格控制。保證整個(gè)軟件包的可維護(hù)性項(xiàng)目過程管理。能夠緊密的控制整個(gè)項(xiàng)目的進(jìn)程，發(fā)現(xiàn)項(xiàng)目中的各種風(fēng)險(xiǎn)因素，盡早地把風(fēng)險(xiǎn)在項(xiàng)目中消除。硬性要求如下：(1) 每個(gè)項(xiàng)目(大于10MD正常項(xiàng)目)必須提供的文檔為功能點(diǎn)文檔，ques

28、tionSheet ,單體測試用例，項(xiàng)目總結(jié)及MDM終分配方案文檔(2) 每個(gè)項(xiàng)目(大于10MD正常項(xiàng)目)必須召開兩次會(huì)議：(3) 項(xiàng)目啟動(dòng)會(huì)議主要為了統(tǒng)一項(xiàng)目的內(nèi)容規(guī)則和要求，同時(shí)把整體邏輯和框 架做簡要說明。(4) 項(xiàng)目總結(jié)會(huì)議：主要是評價(jià)每個(gè)成員的表現(xiàn)和項(xiàng)目完整的狀況和質(zhì)量，總 結(jié)失敗的經(jīng)驗(yàn)教訓(xùn)。同時(shí)根據(jù)評論的結(jié)果進(jìn)行最后的MD勺分配。(5) 在esm必須登陸必要的過程參數(shù)，以便團(tuán)隊(duì)成員和公司的管理者能夠及時(shí) 的把我目前項(xiàng)目狀態(tài)。整個(gè)團(tuán)隊(duì)的建設(shè)和公司的管理工作。在項(xiàng)目管理中發(fā)現(xiàn)問題，把反映給公司。以 備在公司級別對整個(gè)流程和各個(gè)環(huán)節(jié)進(jìn)行調(diào)整。1.8.4 流程圖原則:3.8.5項(xiàng)目組文檔管

29、理所有文檔必須都放在fileserver上，進(jìn)行統(tǒng)一管理。同時(shí)，負(fù)責(zé)人在本地應(yīng)保留一份同樣的備份。2004年開始接收到的項(xiàng)目必須放在2004中，針對每個(gè)項(xiàng)目必須按照下圖進(jìn)行文檔管理。三 g 2004S 11 H l.Sample prj act All Bug Sp&c FF Sp»c function points H*ar ingShnt Me«tiag Rteord 工chadul電 Sp«c t*節(jié)t c寫史 UISEEEEEEEES 亡I BacklFpS 亡I comman 亡j creftt&SqlrjyS 亡j db5eript a

30、 dmp_fil細(xì)節(jié)描述All Bug SpecIf Spec! lR I f test caseL-JI fimeti*n pointsA/Record項(xiàng)目內(nèi)容備注Spec設(shè)計(jì)說明書QuestionSheet設(shè)計(jì)說明書的補(bǔ)充說明 設(shè)計(jì)說明書的各個(gè)版本 設(shè)計(jì)說明書一覽表設(shè)計(jì)說明書一覽表要記錄所有文檔 變更的情況，并指明最后項(xiàng)目實(shí)施 與文檔之間的關(guān)系Test case項(xiàng)目組書寫的單體測試用例測試組書寫的測試用例東京發(fā)送的confirm測試用例Schedule針對項(xiàng)目實(shí)施的日程安排對東京進(jìn)行進(jìn)度匯報(bào)的每個(gè)報(bào)表FunctionPoints功能點(diǎn)文檔All Bug SpecBeta后障害書針對此項(xiàng)目的

31、beta后bug類型確定和經(jīng)驗(yàn)匯總。完 畢后，應(yīng)及時(shí)發(fā)送測試組項(xiàng)目經(jīng)理。UIHtml DemoHearingSheet聯(lián)系分析組，如果有應(yīng)該直接 copyFP SpecFP sheet不同版本FP change 表FP說明，記錄所有FP變更歷史，以備后期確認(rèn)的方便。項(xiàng)目spec的中文版需要打印，此工作由項(xiàng)目總控助理執(zhí)行。同時(shí)，對文檔進(jìn)行歸 檔和密封。1.9 測試部3版前流程1.9.1 相關(guān)人員測試部經(jīng)理：XX測試組成員：1.9.2 測試人員的要求一定要注意配合。因?yàn)?，在此環(huán)節(jié)，一種好的描述方式和溝通方式將會(huì)直接影響工作效率和工作質(zhì)量。所以，首先大家要注意bug管理系統(tǒng)的使用方法和規(guī)則，同時(shí)，盡

32、量采用統(tǒng)一的屬于進(jìn)行描述，如果需要圖形輔助，也可以進(jìn)行貼圖。加強(qiáng)需求理解能力。能夠盡快的理解文檔和功能測試用例。在工作中細(xì)致、耐心、有條理。同時(shí)對應(yīng)esm系統(tǒng)需要測試部填寫的過程參數(shù)必須嚴(yán)格按照規(guī)定填寫。1.9.3 工作流程圖1.9.4 注意事項(xiàng)Bug管理系統(tǒng)中的狀態(tài)一定要維護(hù)，并通過此系統(tǒng)來保證alfa bug修改的進(jìn)行情況，即在提交beta版前，所有的alfa bug的狀態(tài)都應(yīng)該在 DO上。如果沒有在此狀態(tài)中， 應(yīng)該積極和項(xiàng)目組聯(lián)系，測試組有權(quán)監(jiān)督其完成。測試組要驗(yàn)證項(xiàng)目組提交的script和resoruce文件，如果有問題，測試組有權(quán)通知項(xiàng)目立即修改，同時(shí)可以作為alfa bug登錄在b

33、ug管理系統(tǒng)中。測試組要保證測試用例的質(zhì)量，盡一切可能減少beta后bug的數(shù)量。并嚴(yán)格的按照beta后bug處理規(guī)約進(jìn)行。4 績效考核實(shí)施方案4.1 總則：所有職員的所有工作都應(yīng)該以量化計(jì)算，如果不能，則當(dāng)事者可以提出異議，而對績效考核方法進(jìn)行改進(jìn)。例如所有北京項(xiàng)目必須有MD翻譯組翻譯工作量可以通過翻譯的字?jǐn)?shù)進(jìn)行調(diào)整，測試組同樣對工作內(nèi)容進(jìn)行分類核算MD量化管理主要包含幾個(gè)主題方向：工作時(shí)間：是人事部門公布的每個(gè)月的工時(shí)統(tǒng)計(jì)的結(jié)果。實(shí)際上，它代表了自己的實(shí)際消耗時(shí)間。東京MD是實(shí)際為公司所創(chuàng)造的價(jià)值。北京MD主要包含正規(guī)作的北京內(nèi)部項(xiàng)目或者實(shí)際工作而作的的補(bǔ)充MD已達(dá)到考核的公平合理。質(zhì)量扣

34、除MD是指由于代碼的bug而造成的損失，因?yàn)閷?shí)際的貢獻(xiàn)是要扣除損失的。對于測試部就是東京對北京確認(rèn)產(chǎn)生的beta后故障的扣除。過程管理扣除 MD除了實(shí)際的工作量，就是為個(gè)建立一個(gè)穩(wěn)固高效的團(tuán)隊(duì)而每個(gè)人 應(yīng)該承擔(dān)的過程管理義務(wù)，如果沒有做好，實(shí)際上不僅僅是你自己績效不高，而是你 影響了整個(gè)團(tuán)隊(duì)的利益。而這部分的值反映了你對團(tuán)隊(duì)的影響。過程管理獎(jiǎng)勵(lì) MD在項(xiàng)目實(shí)施過程中，個(gè)人在突發(fā)事件上的處理或者對項(xiàng)目整體乃至公司的利益上作出突出貢獻(xiàn)，可以作為績效獎(jiǎng)勵(lì)。在整個(gè)分類上，基本上是劃分為管理者，程序員，分析員，翻譯人員，測試人員幾個(gè)子系統(tǒng)。但是所有系統(tǒng)的價(jià)值標(biāo)準(zhǔn)統(tǒng)一。在時(shí)間上，每個(gè)月的第五個(gè)工作日公布績

35、效考核結(jié)果?？冃Э己说慕Y(jié)果直接反映在近期和長期的?t勵(lì)系統(tǒng)中。具體內(nèi)容可以參見開發(fā)部激勵(lì)和過失管理流程4.2 流程圖翻譯組M冰算流程測試組M冰算流程測試組接收取書寫測試用快能點(diǎn)文檔通知卜按WD1冊Alfa® 知驗(yàn)證測試用例測試實(shí)施按,WD1毓提丸et版接到東京通關(guān) 后，填寫et后bugm總表卜月度績效報(bào)表，根 據(jù)betaibu進(jìn)行質(zhì)量扣除計(jì)算項(xiàng)目組M冰算流程 分析組M冰算流程事項(xiàng)內(nèi)容注思負(fù)責(zé)人備注測試組績效主要根據(jù)測試的工作量 和工作結(jié)果來進(jìn)行MD的 度量強(qiáng)調(diào)質(zhì)量，會(huì)加 大質(zhì)量影響的力 度。測試部經(jīng)理要按項(xiàng)目進(jìn)行分配，多退少補(bǔ)。測試組質(zhì)量考核主要是根據(jù)beta后bug 進(jìn)行，如果出現(xiàn)

36、beta后 bug同時(shí)被確認(rèn)為實(shí)施 bug,對應(yīng)測試人員應(yīng)該 承擔(dān)質(zhì)量責(zé)任，按一個(gè) 實(shí)施bug扣除0.1MD計(jì) 算要注意參看 beta后bug匯總 表。測試組最關(guān)鍵的問題是 根據(jù)0后的bug情況做 分析總結(jié)，可向公司申 請bug分析內(nèi)部文檔， 通過后可按北京項(xiàng)目補(bǔ)充MD測試組工作量百 分比目前是測試工作本身項(xiàng)目 MDX 10%測試用例的書寫是項(xiàng)目MDX 10%目前的測試用例 由于是初步書 寫。所以僅限于 第一月項(xiàng)目總控人員第一月后根據(jù)測試用例 書寫的實(shí)際工時(shí)和狀況 重新審核此百分比項(xiàng)目分析工作量項(xiàng)目分析指拿到文檔 后，進(jìn)行的需求詳細(xì)分 析，提出問題，完畢 questionSheet 文檔 和

37、功能電文檔原則上項(xiàng)目經(jīng)理 直接進(jìn)行，同時(shí) 也可以委托組內(nèi) 具有分析能力的 程序員進(jìn)行，但項(xiàng)目經(jīng)理MD分配時(shí)誰分析誰拿走 對應(yīng)的10%的MD是必須是項(xiàng)目經(jīng)理負(fù)責(zé)制項(xiàng)目組質(zhì)量考核嚴(yán)格按照 alfa版后的bug進(jìn)行，一個(gè)bug扣除0.1MDAlfa版的bug登 錄在bug管理系 統(tǒng)中，項(xiàng)目經(jīng)理 要維護(hù)此系統(tǒng)的 Plan欄目，程序 員要負(fù)責(zé)其中的 DO欄目。如果不 填寫直接作為過 程管理扣除MD進(jìn)行，一次 0.1MD測試部經(jīng)理 項(xiàng)目經(jīng)理Alfa版質(zhì)量扣除MD的匯 總表測試部經(jīng)理負(fù)責(zé)。Alfa版過程管理扣除MD 匯總表由測試部經(jīng)理負(fù) 責(zé)。項(xiàng)目總控助理負(fù)責(zé)審核 測試部經(jīng)理的工作，如 果出現(xiàn)細(xì)漏，按過程管

38、理扣除MD計(jì)算，一次0.1md項(xiàng)目組單體測試 用例工作量核算單體測試用例的條數(shù)必須大于MDX 2,核算項(xiàng)目 經(jīng)理直接指定此工作包含在實(shí) 施70 %的范圍 內(nèi)。項(xiàng)目經(jīng)理項(xiàng)目經(jīng)理和全體 管理者自身績效 評定全體team （包含自身在 內(nèi)）的平均值所以項(xiàng)目經(jīng)理要 提高整個(gè)團(tuán)隊(duì)的 績效為目標(biāo)項(xiàng)目經(jīng)理由項(xiàng)目總控助理進(jìn)行監(jiān) 控。出現(xiàn)問題按過失進(jìn) 行處理。年底績效評定標(biāo)準(zhǔn)直接利用MD進(jìn)行評價(jià)其中包含東京M麗北京MD項(xiàng)目總控人員年底績效加權(quán)系 數(shù)確定項(xiàng)目經(jīng)理加權(quán)1.25分析組加權(quán)1.1翻譯組加權(quán) 8500字/MD進(jìn)行折算項(xiàng)目總控人員伴隨業(yè)務(wù)和過程的改 變，如果系數(shù)有一定的 偏差，由項(xiàng)目總控人員 對此系數(shù)進(jìn)行調(diào)

39、整，反 映在文檔改版中，并通 知全體人員5 開發(fā)部激勵(lì)和過失管理流程5.1 激勵(lì)管理系統(tǒng)5.1.1 激勵(lì)的定義和類別定義：激勵(lì)指職員對公司作出貢獻(xiàn)的對應(yīng)回報(bào)。旨在體現(xiàn)公司公平的原則，客觀的對個(gè)人的 能力和價(jià)值進(jìn)行認(rèn)可。類別與處理方法：類別名稱描述實(shí)施方式適用范圍備注特別MM勵(lì)在項(xiàng)目中作為突出貢獻(xiàn)，對公司的利益 產(chǎn)生重大影響?？捎刹块L提出申請，項(xiàng) 目總控人員進(jìn)行批示。特別獎(jiǎng)勵(lì) 單全體員工特別獎(jiǎng)金獎(jiǎng) 勵(lì)在項(xiàng)目中作為突出貢獻(xiàn)，對公司的利益 產(chǎn)生重大影響?？捎晒芾碚咧苯犹嶙h， 部長會(huì)議進(jìn)行討論決定。特別獎(jiǎng)勵(lì) 單全體員工部門內(nèi)項(xiàng)目 獎(jiǎng)金部長負(fù)責(zé)制，按季度抽取項(xiàng)目的激勵(lì)獎(jiǎng) 金。內(nèi)容是骨干人員，突出貢獻(xiàn)者和

40、分財(cái)務(wù)撥款 通知單開發(fā)部內(nèi)全體員工部內(nèi)的個(gè)別活動(dòng)。（同時(shí)，適用測試部和 分析組）金額為：2X 東京MD-質(zhì)量扣除MD項(xiàng)目獎(jiǎng)金 分配明細(xì) 表公司資助培 訓(xùn)管理者提議，部長會(huì)議審議。針對公司 的要求和個(gè)人情況，提議確定人選和額 度。培訓(xùn)通知 書突出貢獻(xiàn) 者或特別 崗位升職參考績效表，考察個(gè)人能力，并征求個(gè) 人意見后，進(jìn)行職位調(diào)整。以給有技術(shù) 或管理能力的人充分的空間。升職通知 書管理者考 察通過人 員加薪參考績效表，考察個(gè)人能力（技術(shù)等級 表），于每年8月和1月啟動(dòng)調(diào)整薪金 調(diào)查程序，對應(yīng)該薪金的人進(jìn)行處理薪金調(diào)整單管理者考 察通過人員年終獎(jiǎng)金年終獎(jiǎng)金額度由東京董事會(huì)根據(jù)北京利益情況進(jìn)行直接確定獎(jiǎng)金分配采用同一職能部門公開化，計(jì) 算方法，嚴(yán)格按照個(gè)人 MD（貢獻(xiàn)MD-扣 除MD的百分比進(jìn)行直接計(jì)算。年終獎(jiǎng)金 分配表全體員工5.2過失管理系統(tǒng)5.2.1定義：過失泛指由于本人的失誤和錯(cuò)誤，對公司的利益或潛在利益造成比較