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

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

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

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

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

5、。主要是把事務(wù)管事員理的井井有條。項制項目總負責(zé)利用工具【導(dǎo)出下周東京項作控助理工作表系統(tǒng)】制作開發(fā)部目負責(zé)下下周工作計劃表。每周五人周下班前發(fā)送東京。工作安排表(2) Report的使用作為上市公司的子公司要求公司正規(guī)化，第一步公司的日報系統(tǒng)的建立和審查，所以從本年度起必須建立此系統(tǒng)。同時，在管理上解決口頭匯報，不客觀而事后而無據(jù)可查的弊端，為及時了解問題并解決問題，提供第一手的素材。同時項目總控助理，也要本著實事求是的原則，根據(jù)大家的填寫內(nèi)容向東京證券市場提交作業(yè)公務(wù)表，所有填寫者一定要保證填寫日報的消耗工時和最后工資結(jié)算時當日工時保持嚴格一內(nèi)容對應(yīng)esm填寫要求的名稱監(jiān)督人違規(guī)處理項目項

6、目直接選擇自己對應(yīng)的項xx扣除MD0.1選擇當日工作內(nèi)工作容與進內(nèi)容度和進目，如果工作對象不是項目本身則需要選擇以下項目：（顧客名稱為2004年過程管理專用）公司會議公司培訓(xùn)公司管理其它注意：只有部長以上才填寫以上項目（公司培訓(xùn)除外），部長以下全部選擇對應(yīng)項目。見附圖11. 填寫當日的模塊名稱（模塊名稱參考2. 中的功能點表）3. 細度要求功能點填寫監(jiān)沒有填寫1督：XX次人民幣5內(nèi)容監(jiān)元督：項目度經(jīng)理工作工作耗要求與工資計算工時想數(shù)字核耗時時對應(yīng)。（esm中數(shù)據(jù)庫的對：XX數(shù)字和工時統(tǒng)計必須對應(yīng)，此為東京證券的要求）問題問題反把當天所遇到的問題按內(nèi)容監(jiān)反饋饋照條目化羅列。必須包含督：項目內(nèi)容和

7、狀態(tài)兩部分例如：1內(nèi)容：BS詳細頁面存在老bug,狀態(tài)：已經(jīng)解決2內(nèi)容：文檔2.3出現(xiàn)問題，無法繼續(xù)。狀態(tài)：等待解決經(jīng)理MD輸訂貨（預(yù)必須在項目總結(jié)會議結(jié)職員的輸入定）金額束之后，同時要經(jīng)過項目入由項目經(jīng)理的審核。經(jīng)理負責(zé)輸入值為實際值的10倍項目經(jīng)理（因為數(shù)值型目前只能的核對由為整數(shù)）項目總控助理進行數(shù)字不對者，按照一次扣除0.1MD不付責(zé)任的亂填或不填，一個日報扣除0.1MD（如果在特殊情況下無問題，也要寫無）職員如果不填寫則按照輸入值進行績效考核。如果職員輸入的MD與分配時不符合項目經(jīng)理扣除0.5MD附圖1:(3)周報(WeekReport)日報(DailyReport)的使用主要是使用

8、對象為管理者，主要是適用于向管理者匯報整體問題。在概念上，日報周報為概括說明，而report則屬于細節(jié)描述。內(nèi)容負責(zé)人填寫要求監(jiān)督人違規(guī)處理日報項目經(jīng)理部項目進展狀況:項目總控人如果由于沒有匯長部長不能解決的問題報造成問題，按反饋次扣除0.5MD建議或提議突發(fā)問題必須反周報項目經(jīng)理項目進展整體狀項目總控助周報不寫，按一次-»部長況:扣除0.2MD部長項不能解決的問題反饋目總控建議或提議必須填寫(4)目標功能的使用由于分部內(nèi)有單獨的激勵費用,所以建議分部內(nèi)建立目別考核體系。為每一個程序員根據(jù)個人不同的能力和狀況設(shè)定目標，對于圓滿完成目標者進行鼓勵。同時，保證公司的開發(fā)效果在可控制范圍內(nèi)

9、。(5)項目信息管理的使用。本管理系統(tǒng)在2003年開始實行，主要目前是記錄公司所有項目的里程碑信息。為以后項目的整理和后期處理提供真實的數(shù)據(jù)。同時，維護公司的項目信息數(shù)據(jù)庫。注意事項：其中關(guān)于項目中所設(shè)計的文檔，統(tǒng)一放在fileserver上2004目錄中。關(guān)于文檔名稱和路徑的書寫方法如下，保證能夠盡快打開文檔：/fileserver/project/2004/14258/測試用例/14258_testcase.xls2004年1月1號起,東京新項目項目要求對應(yīng)負責(zé)人出錯處理方法備注項目名稱必填，同時應(yīng)有對應(yīng)的項目號XX扣除MD0.1北京項目編號必填XX扣除MD0.1添加時一定要注意唯一性，與

10、項目類型不能為空，目前類型有ResearchNormalConfirmMergeOthersXX扣除MD0.1目前的規(guī)則為小于5md的均為RESEARCH目項目名稱必填XX扣除MD0.1項目的名稱應(yīng)包含項目的ID,關(guān)于項目ID的生成方法，參考日方對應(yīng)文檔客戶方負責(zé)人必填XX扣除MD0.1分析負責(zé)人北京分析項目，為必填項目東京設(shè)計，為非必部長（但是必須制定具體負責(zé)人）扣除MD0.1填項目負責(zé)人必填項目部長扣除MD0.1項目負責(zé)人應(yīng)該是直接負責(zé)人（不是最先指定的部長）本公司負責(zé)人不能為空XX扣除MD0.1如果沒有項目負責(zé)初始必填的人員為項目負責(zé)人人，與xx聯(lián)系項目總控人員及助理、對應(yīng)部長、測試部經(jīng)

11、理，公司技術(shù)負責(zé)人（馬?。┓治鲩_始時間必填對應(yīng)該項目的分析扣除MD0.1公司技術(shù)負責(zé)人在員分析項目開始時應(yīng)把對應(yīng)分析員加到項目列表中概要設(shè)計完成時間必填對應(yīng)該項目的分析扣除MD0.1員詳細設(shè)計完成時間必填對應(yīng)該項目的分析扣除MD0.1員FP文檔完成時間必填對應(yīng)該項目的分析扣除MD0.1員分析完畢時間必填對應(yīng)該項目的分析扣除MD0.1員項目接收時間必填XX扣除MD0.1項目最終對應(yīng)MD原則不為空，在特XX扣除MD0.1本MD半隨著MD的殊情況下為空，在項目經(jīng)理（Mail通變更需要動態(tài)變化項目備注重必須說知）明原因。Md變更附件名稱不是必須，但是只XX扣除MD0.1要有變更有內(nèi)容，項目經(jīng)理（Mai

12、l通此項目必須要有知）項目最終報價原則不為空，在特XX扣除MD0.1必須與對應(yīng)殊情況下為空，在MD*11000基本一項目備注重必須說致。同時必須和MD明原因。變更紀錄一致Schedule文檔名稱必填項目經(jīng)理扣除MD0.2可以用excel或者及路徑是visio,project后兩種要以HTM輸出以便查閱?？蛻舴絛eadline如果提供必填XX扣除MD0.1要求Alfa版時間必填XX扣除MD0.1項目經(jīng)理（Mail通知）Beta版時間必填XX扣除MD0.1項目經(jīng)理(Mail通知）Alfa變更紀錄最后一次記錄變更XX扣除MD0.1的時間必須和對應(yīng)項目經(jīng)理(Mail通的alfa版時間和矢口）beta版

13、時間一致項目開始時間必填XX項目經(jīng)理（Mail通知）扣除MD0.1CSV支號必填項目經(jīng)理扣除MD0.1此分支號為開發(fā)分支號功能點文檔文件名及文件路徑（FileServer服務(wù)器）必填項目經(jīng)理扣除MD0.1此文檔為必須文檔，各項目經(jīng)理必須嚴格控制。單體測試用例文件名稱及文件路徑必填項目經(jīng)理扣除MD0.1此文檔為必須文檔，各項目經(jīng)理必須嚴格控制項目總結(jié)與MD分配方案文檔及文件路徑測試負責(zé)人測試用例對應(yīng)文件名稱及路徑第一階段測試開始時間：第一階段測試完成日期：Alfa版本后的BUG回歸測試的開始日期：回歸測試的結(jié)束日期：必填必填必填必填必填必填必填必填項目經(jīng)理XXXX測試人員測試人員測試人員測試人員

14、測試人員扣除扣除扣除扣除扣除扣除扣除扣除MD0.1此文檔為必須文檔，各項目經(jīng)理必須嚴格控制。MD0.1MD0.1此文檔為必須文檔，各項目經(jīng)理必須嚴格控制。MD0.1MD0.1MD0.1MD0.1MD0.1Beta版后的BUG數(shù)：必填XX扣除MD0.1主要要參考beta后bug的整理表確認負責(zé)人不是必須，主要是xx與是否進行確認有關(guān)，如果確認其他有信息，確認負責(zé)扣除MD0.1人必填2.3.2 系統(tǒng)的使用(1)電子打卡系統(tǒng)的使用目的：主要是利用電子打卡，提高效率，能夠及時反映請假和遲到，并且所有的數(shù)據(jù)能夠直接被人事利用。要求：2004年2月開始啟用，2月為試用期，但是要求每人必須嚴格填寫，如果不填

15、寫并結(jié)合打卡，忘記填寫扣除過程管理MD0.1計算。(2)會議室、洽談室、經(jīng)理室的使用管理目的：主要是在人數(shù)多而會議室相對緊張的狀態(tài)下，解決矛盾的一種方法。同時審核各項目組是否及時安排公司規(guī)定的兩次會議。2004年2月啟動，沒有按照規(guī)定進行會議，經(jīng)審核后，扣除項目經(jīng)理過程管理MD0.2，忘記登錄的按照統(tǒng)一標準處理。2.3.3公司內(nèi)部論壇的使用主要是要有利于公司內(nèi)部開辟一塊公司可以自由發(fā)表言論的地方。同時，在技術(shù)討論上，希望能夠把知識點做一個累計，以便新員工能夠進行參考和積極發(fā)表意見。3開發(fā)部管理流程具體實施方案3.1 內(nèi)容概述開發(fā)部從流程上主要分為以下幾方面：(1)開發(fā)部管理人員工作流(2)BU

16、GSurvey工作流(3)項目分析工作流(4)Beta后質(zhì)量保證工作流(5)測試組beta前工作流(6)項目組運行基本工作流開發(fā)部從實施人員角色劃分如下：開發(fā)部經(jīng)理：(DM0)統(tǒng)籌解決公司開發(fā)部的全部事宜。進行開發(fā)部的整體計劃的制定和實施，保證開發(fā)部的可持續(xù)發(fā)展和利潤率。項目總控人員：(DM02)對公司級的資源進行調(diào)配，同時，直接了解日方的戰(zhàn)略安排，為北京方的戰(zhàn)略安排提供的第一手的資料。同時，在項目分配上保證三個分部間項目的均衡(一個季度內(nèi))開發(fā)部部長：(DM10)在公司統(tǒng)一的規(guī)則范圍內(nèi)，負責(zé)分部的建設(shè)。協(xié)調(diào)各開發(fā)組的問題，處理解決分部內(nèi)發(fā)生的問題。做好所有公司要求的標準流程內(nèi)的內(nèi)容同時，在許

17、可范圍內(nèi)，可以進行單獨的管理方法的嘗試和分部內(nèi)激勵的分配。技術(shù)設(shè)計負責(zé)人：(DM11)統(tǒng)一協(xié)調(diào)分析組的工作，在對日項目分析組中，進行設(shè)計文檔的統(tǒng)一確認，在對中方項目中，承擔需求的統(tǒng)一把關(guān)處理。同時負責(zé)分析組的日常工作安排的統(tǒng)籌。BUGSurvey總負責(zé)人（DM12）:統(tǒng)一管理package和已經(jīng)提交項目的統(tǒng)籌管理。組織形式上，傾向于單獨的組織模式。在目前的情況下，以靈活為主，臨時性的進行bugSurvey組的組織和bugSurvey組內(nèi)teamleader的指定和管理。在間隙階段，直接進入分析組進行項目分析工作。項目總控助理：xx（DM13）輔助開發(fā)部的項目管理工作，主要負責(zé)中日雙方的信息的反

18、饋紀錄整理，以及esm和taskschedule信息的維護工作。負責(zé)公司級項目文檔，過程參數(shù)的監(jiān)督，同時向日本總部匯報各種參數(shù)和報表。常務(wù)項目經(jīng)理：（DM20）目前11名各分部內(nèi)程序員的日常管理，整個開發(fā)過程中的控制和日方負責(zé)人的信息交互，負責(zé)組內(nèi)程序員的績效考核和問題解決。測試部經(jīng)理和翻譯部經(jīng)理包含在內(nèi)。技術(shù)分析員：（DM21）對日方的需求進行概要分析和設(shè)計，并書寫設(shè)計書，F(xiàn)R對中方的項目中，負責(zé)需求的整理和各種設(shè)計文檔的實施，同時，負責(zé)和項目經(jīng)理和測試部經(jīng)理的溝通。臨時項目經(jīng)理：（DM22）此角色主要是在接受日方外包項目或整體公司產(chǎn)品設(shè)計中，需要臨時成立項目組，而從分析組中或者常務(wù)項目經(jīng)理

19、中抽調(diào)。臨時項目經(jīng)理需要全權(quán)負責(zé)此項目的實施，同時需要和公司簽訂項目負責(zé)保證書，以保證項目的進行和最后單獨項目激勵的兌現(xiàn)。程序員：主要是負責(zé)項目按照分析文檔的實施，同時，在實施過程中優(yōu)化代碼結(jié)構(gòu)，提出合理化建議，其中優(yōu)秀者可以作為TeamLeader負責(zé)具體組織工作和分析管理工作。測試員：負責(zé)公司測試流程的具體實施，要求掌握測試的技術(shù)，提出合理化建議，并保證整個軟件的可靠度。翻譯人員：負責(zé)中日方文檔的翻譯，要求工作嚴謹，保證質(zhì)量。在同日方交流中，負責(zé)接待和溝通。同時，在個人的發(fā)展意向中可以兼顧其它公司內(nèi)的常務(wù)工作。3.2 開發(fā)部概要流程圖3.3 開發(fā)部管理人員工作流3.3.1 軟件開發(fā)管理體系

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

21、進行反饋。Fileserver文檔：通過文檔管理和整理，保證全部職員能夠隨時的了解其他項目的信息和相信內(nèi)容。同時，統(tǒng)一化文檔管理，為以后的發(fā)展提供素材。所有的文檔主要包含如下幾種：HearingSheet:一個簡要的需求，重點在于強調(diào)這個需求的原因（前因后果）UI文件設(shè)計文檔：東京和北京共同進行FP報價書QuestionSheet:所有的問題一定要集中在一個文檔內(nèi)功能點文檔：一定要融合questionSheet內(nèi)對應(yīng)答案的所有內(nèi)容schedule文檔：要包含甘特圖項目總結(jié)及M防配方案：把項目總結(jié)作為重點進行。單體測試用例；條數(shù)最少為MD*2,按照模板進行測試組測試用例：要保證最后的測試結(jié)果確認

22、測試用例：一般為東京發(fā)送beta版后障害書：項目確認者發(fā)送，按照同一格式進行書寫和填寫。beta后障害list表，其中包含bug的簡單描述、bug的類型確定和各部門關(guān)于bug的總結(jié)。(2)過程管理類一個項目兩次會議：項目啟動會議和項目總結(jié)會議項目啟動會議主要是講述項目的功能點，并據(jù)具體問題，進行嚴格的定義，說明本項目所必須遵守的特殊規(guī)則，子功能間的前后順序，統(tǒng)一的接口定義，和每個人在項目實施中應(yīng)該注意的問題。項目總結(jié)會議和M汾配方案的確定。主要是根據(jù)項目實施的結(jié)果，進行集中的討論和諧而公平的團隊：公司其他方面的管理，就是為了加強管理，提倡量化。做到各司其職，多勞多得，公平評價，提供機會給相應(yīng)的

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

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

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

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

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

28、在fileserver上，進行統(tǒng)一管理。同時，負責(zé)人在本地應(yīng)保留一份同樣的備份2004年開始接收到的項目必須放在2004中，針對每個項目必須按照下圖進行文檔管理。X日02004WB11111_Samplproj&Spec匕Jt«stc»«國|_AllBugSpecSQFFSpecS匕Ifundi.onpointips.chtdultfunction.points,HNeetinsE-ecordE|_jwehedule田SpecAllBugSp«cA囹凸in國亡|BackUp+coffnmon匕|createSqlijy1*_dbscriptpH&

29、#171;aringhetJM«stingRecordp_Sptc細節(jié)描述項目內(nèi)容備注Spec設(shè)計說明書QuestionSheet設(shè)計說明書的補充說明設(shè)計說明書的各個版本設(shè)計說明書一覽表設(shè)計說明書一覽表要記錄所有文檔變更的情況，并指明最后項目實施與文檔之間的關(guān)系Testcase項目組書寫的單體測試用例測試組書寫的測試用例東京發(fā)送的confirm測試用例Schedule針對項目實施的日程安排對東京進行進度匯報的每個報表Function功能點文檔PointsAllBugSpecBeta后障害書針對此項目的beta后bug類型確定和經(jīng)驗匯總。完畢后，應(yīng)及時發(fā)送測試組項目經(jīng)理。UIHtmlD

30、emoHearing聯(lián)系分析組，如果有應(yīng)該直接copySheetFPSpecFPsheet不同版本FPchange表FP說明，記錄所有FP變更歷史，以備后期確認的方便。項目spec的中文版需要打印，此工作由項目總控助理執(zhí)行。同時，對文檔進行歸檔和密封。3.9測試部3版前流程3.9.1 相關(guān)人員測試部經(jīng)理：XX測試組成員：3.9.2 測試人員的要求一定要注意配合。因為，在此環(huán)節(jié)，一種好的描述方式和溝通方式將會直接影響工作效率和工作質(zhì)量。所以，首先大家要注意bug管理系統(tǒng)的使用方法和規(guī)則，同時，盡量采用統(tǒng)一的屬于進行描述，如果需要圖形輔助，也可以進行貼圖。加強需求理解能力。能夠盡快的理解文檔和功能

31、測試用例。在工作中細致、耐心、有條理。同時對應(yīng)esm系統(tǒng)需要測試部填寫的過程參數(shù)必須嚴格按照規(guī)定填寫。3.9.3 工作流程圖3.9.4 注意事項Bug管理系統(tǒng)中的狀態(tài)一定要維護，并通過此系統(tǒng)來保證alfabug修改的進行情況，即在提交beta版前，所有的alfabug的狀態(tài)都應(yīng)該在DO上。如果沒有在此狀態(tài)中，應(yīng)該積極和項目組聯(lián)系，測試組有權(quán)監(jiān)督其完成。測試組要驗證項目組提交的script和resoruce文件，如果有問題，測試組有權(quán)通知項目立即修改，同時可以作為alfabug登錄在bug管理系統(tǒng)中。測試組要保證測試用例的質(zhì)量，盡一切可能減少beta后bug的數(shù)量。并嚴格的按照beta后bug處

32、理規(guī)約進行。4 績效考核實施方案4.1 總則：所有職員的所有工作都應(yīng)該以量化計算，如果不能，則當事者可以提出異議，而對績效考核方法進行改進。例如所有北京項目必須有MD翻譯組翻譯工作量可以通過翻譯的字數(shù)進行調(diào)整，測試組同樣對工作內(nèi)容進行分類核算MD量化管理主要包含幾個主題方向：工作時間：是人事部門公布的每個月的工時統(tǒng)計的結(jié)果。實際上，它代表了自己的實際消耗時間。東京MD是實際為公司所創(chuàng)造的價值北京MD主要包含正規(guī)作的北京內(nèi)部項目或者實際工作而作的的補充MD已達到考核的公平合理。質(zhì)量扣除MD是指由于代碼的bug而造成的損失，因為實際的貢獻是要扣除損失的。對于測試部就是東京對北京確認產(chǎn)生的beta后

33、故障的扣除。過程管理扣除MD除了實際的工作量，就是為個建立一個穩(wěn)固高效的團隊而每個人應(yīng)該承擔的過程管理義務(wù)，如果沒有做好，實際上不僅僅是你自己績效不高，而是你影響了整個團隊的利益。而這部分的值反映了你對團隊的影響。過程管理獎勵MD在項目實施過程中，個人在突發(fā)事件上的處理或者對項目整體乃至公司的利益上作出突出貢獻，可以作為績效獎勵。在整個分類上，基本上是劃分為管理者，程序員，分析員，翻譯人員，測試人員幾個子系統(tǒng)。但是所有系統(tǒng)的價值標準統(tǒng)一。在時間上，每個月的第五個工作日公布績效考核結(jié)果?？冃Э己说慕Y(jié)果直接反映在近期和長期的激勵系統(tǒng)中。具體內(nèi)容可以參見開發(fā)部激勵和過失管理流程4.2 流程圖翻譯組M

34、DK算流程測試組MDK算流程測試組接收4|書寫測試用u能點文檔通J1按,WD1冊Alfa®知驗證測試用例項目組MDK算流程分析組M啜算流程內(nèi)容汪息負責(zé)人備注測試組績效主要根據(jù)測試的工作量和工作結(jié)果來進行MD勺度量強調(diào)質(zhì)量，會加大質(zhì)量影響的力度。測試部經(jīng)理要按項目進行分配，多退少補。測試組質(zhì)量考核主要是根據(jù)beta后bug進行，如果出現(xiàn)beta后bug同時被確認為實施bug,對應(yīng)測試人員應(yīng)該承擔質(zhì)量責(zé)任，按一個實施bug扣除0.1MD計算要注意參看beta后bug匯總表。測試組最關(guān)鍵的問題是根據(jù)0后的bug情況做分析總結(jié)，可向公司申請bug分析內(nèi)部文檔，通過后可按北京項目補充MD測試組

35、工作量百目前是測試工作本身項目前的測試用例項目總控人員第一月后根據(jù)測試用例分比目MDX10%測試用例的書寫是項目MDX10%由于是初步書寫。所以僅限于第一月書寫的實際工時和狀況重新審核此百分比項目分析工作量項目分析指拿到文檔后，進行的需求詳細分析，提出問題，完畢questionSheet文檔和功能電文檔原則上項目經(jīng)理直接進行，同時也可以委托組內(nèi)具有分析能力的程序員進行，但是必須是項目經(jīng)理負責(zé)制項目經(jīng)理MD分配時誰分析誰拿走對應(yīng)的10%的MD項目組質(zhì)量考核嚴格按照alfa版后的Alfa版的bug登測試部經(jīng)理Alfa版質(zhì)量扣除MD勺匯bug進行，一個bug扣除0.1MD錄在bug管理系統(tǒng)中，項目經(jīng)

36、理要維護此系統(tǒng)的Plan欄目，程序員要負責(zé)其中的DO欄目。如果不填寫直接作為過程管理扣除MD進行，一次0.1MD項目經(jīng)理總表測試部經(jīng)理負責(zé)。Alfa版過程管理扣除MD匯總表由測試部經(jīng)理負責(zé)。項目總控助理負責(zé)審核測試部經(jīng)理的工作，如果出現(xiàn)細漏，按過程管理扣除MD計算，一次0.1md項目組單體測試用例工作量核算單體測試用例的條數(shù)必須大于MDX2,核算項目經(jīng)理直接指定此工作包含在實施70%的范圍內(nèi)。項目經(jīng)理項目經(jīng)理和全體全體team（包含自身在所以項目經(jīng)理要項目經(jīng)理由項目總控助理進行監(jiān)管理者自身績效評定內(nèi)）的平均值提高整個團隊的績效為目標控。出現(xiàn)問題按過失進行處理。年底績效評定標準直接利用MD3行評

37、價其中包含東京M麗北京MD項目總控人員年底績效加權(quán)系項目經(jīng)理加權(quán)1.25項目總控人員伴隨業(yè)務(wù)和過程的改數(shù)確定分析組加權(quán)1.1變，如果系數(shù)有一定的翻譯組加權(quán)8500字/MD偏差，由項目總控人員進行折算對此系數(shù)進行調(diào)整，反映在文檔改版中，并通知全體人員5 開發(fā)部激勵和過失管理流程5.1 激勵管理系統(tǒng)5.1.1 激勵的定義和類別定義：激勵指職員對公司作出貢獻的對應(yīng)回報。旨在體現(xiàn)公司公平的原則,客觀的對個人的能力和價值進行認可。類別與處理方法：類別名稱描述實施方式適用范備注圍特別MD在項目中作為突出貢獻，對公特別獎全體員獎勵司的利益產(chǎn)生重大影響。可由部長提出申請，項目總控人員進行批示。勵單工特別獎金在

38、項目中作為突出貢獻，對公特別獎全體員獎勵司的利益產(chǎn)生重大影響?？捎晒芾碚咧苯犹嶙h，部長會議進行討論決定。勵單工部門內(nèi)項部長負責(zé)制，按季度抽取項目財務(wù)撥開發(fā)部目獎金的激勵獎金。內(nèi)容是骨干人員，突出貢獻者和分部內(nèi)的個款通知單內(nèi)全體員工公司資助培訓(xùn)升職加薪年終獎金別活動。（同時，適用測試部項目獎和分析組）金分配金額為：2X東京Md質(zhì)量扣明細表除MD管理者提議，部長會議審議。培訓(xùn)通針對公司的要求和個人情況，知書提議確定人選和額度。參考績效表，考察個人能力，升職通并征求個人意見后，進行職位知書調(diào)整。以給有技術(shù)或管理能力的人充分的空間。參考績效表，考察個人能力薪金調(diào)（技術(shù)等級表），于每年8月整單和1月啟動調(diào)整薪金調(diào)查程序，對應(yīng)該薪金的人進行處理年終獎金額度由東京董事會年終獎根據(jù)北京利益情況進行直接金分配確定表獎金分配采用同一職能部門公開化，計算方法，嚴格按照突出貢 獻者或 特別崗 位管理者 考察通 過人員管理者 考察通 過人員全體員 工個人MD（貢獻MD-扣除MD的百分比進行直接計算。5.2 過失管理系統(tǒng)5.2.1 定義:過失泛指由于本人的失誤和錯誤，對公司的利益或潛在利益造成比較大的