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

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

一、簡述

對于一個新項目，從可行性研究到產品交貨整個生存階段將經(jīng)歷如下十大流程：

1、項目可行性研究階段2、立項階段

3、需求分析階段4、開發(fā)策劃階段5、設計階段

6、編碼實現(xiàn)階段7、測試階段8、驗收階段

9、產品交付使用10、維護階段

二、項目組基本組成及崗位職責

新項目立項時會成立項目組，不同的項目組成員有不同的職責，一個項目組成員也可以身兼多職，但不可身兼全職。

a項目負責人：負責項目的管理、組織、對技術、進度、質量全面負責。b質量保證人員：負責質量保證工作計劃的落實和軟件的質量保證。

C配管理人員：負責本項目的配管理工作，對本項目的文檔、程序是否符合規(guī)程文件的要求進行形式化的檢查。

D分析人員：主要負責本項目的需求分析工作。E設計人員：主要負責本項目的設計工作。

F程序員：按設計要求和有關標準進行編程工作。

G測試人員：負責單元測試、組合測試和總裝測試工作。H文檔人員：負責本項目有關文檔的編寫工作。

I產品經(jīng)理：協(xié)助進行產品研制計劃制定、產品發(fā)布與產品推廣等,在產品開發(fā)中，充分代表用戶的利益，提供建議,負責在產品功能與出品日期二者之間的權衡;負責產品市場營銷、產品銷售和市場推廣過程。（通常由營銷部門或中試部門人員擔任）

三、軟件開發(fā)流程

3．1可行性研究階段

如果是公司自主開發(fā)項目，可行性研究通常是由公司技術負責人根據(jù)公司產品規(guī)劃和市場需求，在要開展新項目前通過部門負責人指定人員進行的前期調研工作，可行性研究負責人員對產品的市場需求、技術發(fā)展、市場定位、功能需求、經(jīng)濟效益、進度需求、風險分析等進行可行性研究，提供產品立項建議，擬制可行性研究報告，由部門負責人指定營銷部門配合可行性分析人員，技術負責人協(xié)助安排�？尚行苑治鐾戤吅笥煽偣まk組織對可行性研究報告進行評審，評審通過后，總工辦組織進行立項工作。

如果是系統(tǒng)集成部外接的系統(tǒng)集成項目，在系統(tǒng)集成部與客戶簽訂合同之前，均應對將簽項目進行資源、技術、市場的可行性分析，可行性分析通過后、簽訂合同前由總工辦組織相關人員對合同條款進行評審，評審通過后，總工辦組織進行立項工作。

本階段提交的文檔：項目可行性研究任務書（技術負責人或部門負責人下達）項目可行性研究報告（可行性研究人員編寫）系統(tǒng)集成項目合同質量記錄：可行性分析評審報告3．2立項階段

可行性分析評審通過后，由開發(fā)部門經(jīng)理下達立項任務，指定相關人員填寫立項申請報告報批。報批通過后，由部門經(jīng)理與技術負責人協(xié)商，下達開發(fā)任務書，經(jīng)技術負責人審核確認后，報公司批準。批準立項后項目進度應以立項申請報告中的階段進度為準，如果進度要調整，需填寫進度調整申請報告報批。本階段提交的文檔：項目立項申請報告

開發(fā)任務書

3．3需求分析階段

承辦單位根據(jù)交辦單位提出的技術要求和相應的軟件任務書以及其它有關文件，與交辦單位協(xié)作，確定詳細的軟件需求，該階段完成的軟件需求規(guī)格說明經(jīng)審定和批準后將作為整個軟件開發(fā)工作的基礎列入配管理的基線，在本階段可利用快速原型法使比較含糊的具有不確定性的軟件需求（主要是功能）明確化。能給本公司開發(fā)的軟件的“需求基線”確定提供一個討論、進一步完善的基礎。在本階段，由產品經(jīng)理負責，其他人員配合，編寫產品規(guī)格說明書，此說明書面向最終用戶和領導，主要描繪產品的形狀以及功能、性能、功能特性、性能特性。由項目經(jīng)理負責編寫系統(tǒng)技術方案書，描述公司初次使用的技術的詳細解決方案。本階段完畢后對需求分析進行評審，出具需求分析評審報告。本階段提交的文檔：軟件需求規(guī)格說明書。原型分析說明書產品規(guī)格說明書

系統(tǒng)技術方案書

質量記錄：需求分析評審報告

提交的軟件：產品的原型（注：如果時間有限，可以只編寫原型分析說明書而不作原型）

3．4開發(fā)策化階段根據(jù)項目要求和軟件需求，由配人員配合項目經(jīng)理編寫本項目的質量保證計劃、

配管理計劃和項目綜合計劃。在配管理計劃中，應列明本項目需提交的各階段文檔的名稱，在項目各階段完成后，項目組需列表說明要移交的文檔，將此表與各文檔一并向總工辦移交。在制定計劃時，應為計劃、設計、測試、改錯、再測試、變更、以及編制文檔留出足夠的時間。不應使用突擊的辦法來完成項目。

本階段涉及的文檔：軟件質量保證計劃

配管理計劃項目綜合計劃

3．5設計階段3．5．1概要設計

根據(jù)軟件需求規(guī)格說明建立軟件總體結構和模塊間的關系，確定各模塊功能，定義各功能模塊的接口，設計全局數(shù)據(jù)庫和數(shù)據(jù)結構，在概要設計明確后，可以對綜合計劃進一步細化，填寫項目進度預計。概要設計需經(jīng)過評審。本階段涉及的文檔：產品概要設計說明書數(shù)據(jù)庫設計說明項目進度預計質量記錄：評審報告3．5．2詳細設計

對概要設計中產生的功能模塊進行過程描述設計，設計功能模塊的內部細節(jié)，包括算法和數(shù)據(jù)結構，為編寫源代碼提供必要的說明。詳細設計需要經(jīng)過評審。本階段涉及的文檔：軟件詳細設計說明書測試計劃質量記錄：評審報告3．6編碼實現(xiàn)階段

根據(jù)軟件詳細設計說明、對各程序模塊進行編碼、調試、靜態(tài)分析和單元測試，驗證程序單元與設計說明的一致性。本階段涉及的文檔：項目進度月報

項目周計劃和周總結

項目開發(fā)人員周計劃工作日志

每周例會記錄

配項更改申請單3．6測試階段

3．6．1軟件單元測試

按詳細設計的結構，根據(jù)軟件單元測試計劃，依照將經(jīng)過單元測試的底層程序單元逐步組裝成子項目直到開發(fā)項目的過程，對軟件進行測試。本階段涉及的文檔：測試計劃

測試設計

測試問題報告單參考文檔：北京世紀科怡軟件開發(fā)操作指導書中的“測試階段操作指導書”

3．6．2組裝測試

根據(jù)軟件需求規(guī)格說明書中定義的全部功能和性能要求及組裝測試計劃，對軟件進行組裝測試，以確定整個軟件是否滿足軟件需求，是否可以提交總裝測試。

軟件組裝測試計劃（含測試用例設計）的編制工作和軟件組裝測試環(huán)境的研制、組建工作，應從軟件需求分析階段起與軟件開發(fā)同步展開。本階段涉及的文檔：測試計劃測試設計

測試問題報告單

3．7中試階段

項目組開發(fā)的軟件產品經(jīng)中試部驗收后提交中試部中試，中試部根據(jù)需求分析報告,從用戶的角度出發(fā)對產品的功能、性能進行中試。本階段涉及的文檔：中試計劃

中試問題報告單

3．7驗收交付

對完成中試的軟件進行檢查、審查和評審，確定軟件是否達到了軟件任務書的要求。驗收通過的軟件可以向軟件交辦單位交付。項目經(jīng)理及項目組人員應在此階段完成項目總結，項目經(jīng)理提交項目開發(fā)總結報告，項目組成員提交個人工作總結報告。

本階段涉及的文檔：驗收報告

項目開發(fā)總結報告?zhèn)�人工作總結報告

3．8軟件維護

對軟件的維護包括針對軟件運行過程中發(fā)現(xiàn)的問題而進行的改正性維護，針對不同任務對軟件提出不需求而進行的改善性維護，以及可能出現(xiàn)的由于軟件運行環(huán)境的改變而進行的適應性維護。本階段涉及的文檔：軟件問題匯總表維護報告四、項目開發(fā)文件的審批

可行性研究報告及立項申請、項目開發(fā)計劃及項目開發(fā)總結、確認計劃及確

認報告、驗收計劃及驗收報告由技術負責人審批。項目組人員編寫的其他文件由項目經(jīng)理審批。

五、各階段共同的任務要求5．1編寫文檔

在軟件開發(fā)過程的各個階段，都要求完成相應的文檔編寫工作。本文檔的前面部分已給出了在軟件自上而下周期各個階段中的文檔編制情況。軟件文檔從形式上來看，大致可分為兩類：a．開發(fā)過程中填寫的各種圖表，稱為工作表格；b．應編制的技術資料或技術管理資料，稱為文檔或文件。按照文檔產生和使用的范圍，軟件文檔大致可分為三類：a．開發(fā)文檔：這類文檔是在軟件開發(fā)過程中，作為軟件開發(fā)人員前一階段工作成果的體現(xiàn)和后一階段工作依據(jù)的文檔。包括軟件需求說明書、數(shù)據(jù)庫設計說明書、概要設計說明書、詳細設計說明書、可行性研究報告、項目開發(fā)計劃。b．管理文檔：這類文檔是在軟件開發(fā)過程中，由軟件開發(fā)人員制定的需提交人員的一些工作計劃或工作報告。使管理人員能夠通過這些文檔了解軟件開發(fā)項目安排、進度、資源使用和成果等。包括項目開發(fā)計劃、測試計劃、測試報告、開發(fā)進度月報、項目周計劃周總結及項目開發(fā)總結等。c．用戶文檔：這類文檔是軟件開發(fā)人員為用戶準備的有關該軟件使用、操作、維護的資料。包括用戶手冊、操作手冊、維護修改建議、軟件需求說明書。

項目各階段完畢后需把本階段相關文檔列表向總工辦移交。

5．2驗證與評審

軟件評審是保證軟件產品質量的重要手段，必須納入軟件開發(fā)過程，并把評審通過作為一個軟件階段完成的標志，進而轉入下一個開發(fā)階段。軟件評審包括有正式評審(即評審)、內部評審兩種形式。正式評審是軟件項目組上級技術主管主持的評審。內部評審以由項目負責人組織、開發(fā)人員相互檢查為基本方式。

就整個軟件開發(fā)過程而言，至少要進行可行性分析、軟件需求評審、設計評審、軟件驗證和確認評審、管理評審等五個方面的評審和檢查工作。

擴展閱讀：軟件項目開發(fā)流程

＃＃文檔

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

修改歷史日期201*-03-12201*-5-18201*-12-4201*-1-14

作者修改內容新制作人員職責的變更，內容的變更針對201*年度制作最新工作內容下的工作流程添加項目經(jīng)理管理被職員填寫下周日程表的規(guī)則1

＃＃文檔

1

概述........................................................................31.11.22

目的......................................................................3內容概述..................................................................3

開發(fā)部日常管理流程具體實施方案...............................................32.12.22.3

基本原則..................................................................3內容概述..................................................................3內容詳細描述..............................................................3

3開發(fā)部管理流程具體實施方案..................................................103.13.23.33.43.53.63.73.83.9

內容概述.................................................................10開發(fā)部概要流程圖.........................................................12開發(fā)部管理人員工作流.....................................................12BUGSURVEY工作流............................................................15項目分析工作流...........................................................15BETA后質量保證工作流......................................................15測試組BETA前工作流.......................................................15項目組基本工作流.........................................................15測試部Β版前流程..........................................................19

4績效考核實施方案...........................................................214.14.2

總則：...................................................................21流程圖...................................................................21

5開發(fā)部激勵和過失管理流程....................................................245.15.2

激勵管理系統(tǒng).............................................................24過失管理系統(tǒng).............................................................24

2

＃＃文檔

1概述

1.1目的

用標準化的流程來統(tǒng)一管理公司的運作，避免混亂，提高管理的質量。在遠程開發(fā)上，結果××軟件自身的特點，量身定做，解決遠程開發(fā)上的問題。在實施過程中，所有管理者能夠根據(jù)此統(tǒng)一的流程，總結經(jīng)驗，提高認識，加強

技術水平和管理水平。

提高公司級的技術分析能力，為公司儲備一支分析隊伍，側重在需求理解和需求

分析、框架設計上的能力。保證在201*年能夠全盤進行中方市場的順利運作。對人員負責內容上，明確化各自負責的內容，提高工作效率。

1.2內容概述

開發(fā)部日常工作流程開發(fā)部管理流程開發(fā)部績效考核流程開發(fā)部激勵和過失管理流程

2開發(fā)部日常管理流程具體實施方案

2.1基本原則

公司開發(fā)部力求建立公平公正的評價體系，嚴謹?shù)墓ぷ髁鞒潭�義和及時的記錄與反饋，規(guī)范職員活動，形成一個緊張有序的團隊。

沒有一個明晰的流程和高效的反饋體系，就不可能把工作做好。但是，這需要每個人按照規(guī)則把自己應該負責的那一部分高效完成，只有這樣才能保證整個系統(tǒng)的順暢，同時，如果個人沒有完成自己的指責和按照規(guī)定填寫內容，影響的不單單是自己的工作而是整個系統(tǒng)。

2.2內容概述

Esm使用規(guī)則

目的注意是為了提高開發(fā)部整體的計劃能力，反饋能力和管理者的控制能力。同時提高整體職員參與公司管理的渠道，適應東京上市公司對信息管理的要求。日�；顒拥姆椒�

提供開發(fā)部工作流程外的突發(fā)事件的解決方法

2.3內容詳細描述

2.3.1Esm使用規(guī)則（1）schedule的使用

3

＃＃文檔

加強全體人員的計劃能力，做到我每天要做什么？今天項目經(jīng)理給我的安排是什么？對應項目經(jīng)理和部長要知道每個人在做什么？只有這樣，才能保證控制人員可以宏觀調控，而個人也不會不知所措。

注意事項：

1.必須使用長期類型（哪怕只有一天）保持統(tǒng)一性

2開始時間必須為22：00結束時間為23：00，（為了區(qū)分其它人填寫的日程安排）

3填寫日程安排時，必須選擇對應的anken，否則不能于系統(tǒng)內的項目關聯(lián)，統(tǒng)計軟件失去作用。

4日程安排的主題要修改，規(guī)則為項目號（中文版項目為北京內部項目編號），暫時沒有編號可以寫項目名稱。內容下周工作安排負責人項目經(jīng)理技術分析負責人測試組經(jīng)理開發(fā)部全體人員開發(fā)部全體人員項目總控助理填寫要求必須每周五16：00前填寫完畢。同時類型統(tǒng)一用長期進行定義，為每一個人員安排下周工作計劃。監(jiān)督人填寫監(jiān)督：項目總控助理內容監(jiān)督：部長和項目總控人員無違規(guī)處理沒有按時提交的，管理者扣除MD0.2日�；顒影才糯�辦事項制作下周工作安排表

建議大家把工作安排填寫，有利于提高自己的計劃能力和規(guī)劃能力。同時能保證事情不會忘記。建議填寫，管理者應該必須使用。主要是把事務管理的井井有條。負責利用工具【導出下周工作表系統(tǒng)】制作開發(fā)部下周工作計劃表。每周五下班前發(fā)送東京。無東京項目負責人4

＃＃文檔

（2）Report的使用

作為上市公司的子公司要求公司正規(guī)化，第一步公司的日報系統(tǒng)的建立

和審查，所以從本年度起必須建立此系統(tǒng)。同時，在管理上解決口頭匯報，不客觀而事后而無據(jù)可查的弊端，為及時了解問題并解決問題，提供第一手的素材。

同時項目總控助理，也要本著實事求是的原則，根據(jù)大家的填寫內容向

東京證券市場提交《作業(yè)公務表》，所有填寫者一定要保證填寫日報的消耗工時和最后工資結算時當日工時保持嚴格一致。

內容項目選擇對應esm的名稱項目填寫要求直接選擇自己對應的項目,如果工作對象不是項目本身則需要選擇以下項目:(顧客名稱為201*年過程管理專用)公司會議公司培訓公司管理其它注意:只有部長以上才填寫以上項目(公司培訓除外),部長以下全部選擇對應項目。見附圖1監(jiān)督人××違規(guī)處理扣除MD0.15

＃＃文檔

當日工作內容和進度工作內容與進度1．填寫當日的模塊名稱（模塊名稱參考2．中的功能點表）3．細度要求功能點要求與工資計算工時想對應。（esm中數(shù)據(jù)庫的數(shù)字和工時統(tǒng)計必須對應，此為東京證券的要求）把當天所遇到的問題按照條目化羅列。必須包含內容和狀態(tài)兩部分例如：1內容：BS詳細頁面存在老bug，狀態(tài)：已經(jīng)解決2內容：文檔2.3出現(xiàn)問題，無法繼續(xù)。狀態(tài)：等待解決填寫監(jiān)督：××內容監(jiān)督：項目經(jīng)理數(shù)字核對：××沒有填寫1次人民幣5元工作耗時工作耗時數(shù)字不對者，按照一次扣除0.1MD不付責任的亂填或不填，一個日報扣除0.1MD(如果在特殊情況下無問題，也要寫無)職員如果不填寫則按照輸入值進行績效考核。如果職員輸入的MD與分配時不符合項目經(jīng)理扣除0.5MD問題反饋問題反饋內容監(jiān)督：項目經(jīng)理MD輸入訂貨（預定）金額必須在項目總結會議結束之后，同時要經(jīng)過項目經(jīng)理的審核。輸入值為實際值的10倍（因為數(shù)值型目前只能為整數(shù)）職員的輸入由項目經(jīng)理負責項目經(jīng)理的核對由項目總控助理進行附圖1：

（3）周報（WeekReport）日報（DailyReport）的使用

主要是使用對象為管理者，主要是適用于向管理者匯報整體問題。在概念上，日

6

＃＃文檔

報周報為概括說明，而report則屬于細節(jié)描述。

內容日報負責人項目經(jīng)理部長－》部長填寫要求項目進展狀況：不能解決的問題反饋建議或提議突發(fā)問題必須反饋項目進展整體狀況：不能解決的問題反饋建議或提議必須填寫監(jiān)督人項目總控人員違規(guī)處理如果由于沒有匯報造成問題，按一次扣除0.5MD周報不寫，按一次扣除0.2MD周報項目經(jīng)理－》部長部長－》項目總控

項目總控助理（4）目標功能的使用

由于分部內有單獨的激勵費用，所以建議分部內建立目別考核體系。為每一個程序員根據(jù)個人不同的能力和狀況設定目標，對于圓滿完成目標者進行鼓勵。同時，保證公司的開發(fā)效果在可控制范圍內。

（5）項目信息管理的使用。

本管理系統(tǒng)在201*年開始實行，主要目前是記錄公司所有項目的里程碑信息。為以后項目的整理和后期處理提供真實的數(shù)據(jù)。同時，維護公司的項目信息數(shù)據(jù)庫。注意事項：

其中關于項目中所設計的文檔，統(tǒng)一放在fileserver上201*目錄中。關于文檔名稱和路徑的書寫方法如下,保證能夠盡快打開文檔：

//fileserver/project/201*/14258/測試用例/14258_testcase.xls201*年1月1號起,東京新項目項目項目名稱北京項目編號項目類型要求必填，同時應有對應的項目號必填不能為空，目前類型有ResearchNormalConfirmMerge對應負責人××××××出錯處理方法扣除MD0.1扣除MD0.1扣除MD0.1備注添加時一定要注意唯一性，與目前的規(guī)則為小于5md的均為RESEARCH項目7

＃＃文檔

Others必填項目名稱××扣除MD0.1客戶方負責人分析負責人項目負責人必填北京分析項目，為必填項目東京設計，為非必填必填項目××部長（但是必須制定具體負責人）扣除MD0.1扣除MD0.1項目的名稱應包含項目的ID，關于項目ID的生成方法，參考日方對應文檔部長扣除MD0.1本公司負責人分析開始時間不能為空××初始必填的人員為項目負責人項目總控人員及助理、對應部長、測試部經(jīng)理,公司技術負責人（馬�。┍靥顚�應該項目的分析員扣除MD0.1項目負責人應該是直接負責人（不是最先指定的部長）如果沒有項目負責人，與××聯(lián)系扣除MD0.1概要設計完成時間必填詳細設計完成時間必填FP文檔完成時間分析完畢時間項目接收時間項目最終對應MD必填必填必填原則不為空，在特殊情況下為空，在項目備注重必須說明原因。不是必須，但是只要有變更有內容，此項目必須要有原則不為空，在特殊情況下為空，在項目備注重必須說明原因。必填對應該項目的分析員對應該項目的分析員對應該項目的分析員對應該項目的分析員××××項目經(jīng)理（Mail通知）××項目經(jīng)理（Mail通知）××扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1公司技術負責人在分析項目開始時應把對應分析員加到項目列表中本MD伴隨著MD的變更需要動態(tài)變化Md變更附件名稱扣除MD0.1項目最終報價扣除MD0.1Schedule文檔名稱及路徑項目經(jīng)理扣除MD0.2客戶方deadline要求Alfa版時間如果提供必填必填××××項目經(jīng)理（Mail通知）××項目經(jīng)理（Mail通扣除MD0.1扣除MD0.1必須與對應MD*11000基本一致。同時必須和MD變更紀錄一致可以用excel或者是visio，project后兩種要以HTML輸出以便查閱。Beta版時間必填扣除MD0.18

＃＃文檔

知）××項目經(jīng)理（Mail通知）××項目經(jīng)理（Mail通知）項目經(jīng)理項目經(jīng)理Alfa變更紀錄項目開始時間最后一次記錄變更的時間必須和對應的alfa版時間和beta版時間一致必填扣除MD0.1扣除MD0.1CSV分支號功能點文檔文件名及文件路徑（FileServer服務器）單體測試用例文件名稱及文件路徑項目總結與MD分配方案文檔及文件路徑測試負責人必填必填扣除MD0.1扣除MD0.1此分支號為開發(fā)分支號此文檔為必須文檔，各項目經(jīng)理必須嚴格控制。此文檔為必須文檔，各項目經(jīng)理必須嚴格控制此文檔為必須文檔，各項目經(jīng)理必須嚴格控制。此文檔為必須文檔，各項目經(jīng)理必須嚴格控制。主要要參考beta后bug的整理表必填項目經(jīng)理扣除MD0.1必填項目經(jīng)理扣除MD0.1測試用例對應文件名稱及路徑必填必填××××扣除MD0.1扣除MD0.1第一階段測試開必填始時間：第一階段測試完必填成日期：Alfa版本后的必填BUG：回歸測試的開始必填日期：回歸測試的結束必填日期：Beta版后的BUG必填數(shù)：確認負責人不是必須，主要是與是否進行確認有關，如果確認其他有信息，確認負責人必填測試人員測試人員測試人員測試人員測試人員××××扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1扣除MD0.1

2.3.2系統(tǒng)的使用（1）電子打卡系統(tǒng)的使用

目的：主要是利用電子打卡，提高效率，能夠及時反映請假和遲到，并且所有的數(shù)據(jù)能夠直接被人事利用。要求：

9

＃＃文檔

201*年2月開始啟用，2月為試用期，但是要求每人必須嚴格填寫，如果不填寫并結合打卡，忘記填寫扣除過程管理MD0.1計算。

（2）會議室、洽談室、經(jīng)理室的使用管理

目的：主要是在人數(shù)多而會議室相對緊張的狀態(tài)下，解決矛盾的一種方法。同時審核各項目組是否及時安排公司規(guī)定的兩次會議。

201*年2月啟動，沒有按照規(guī)定進行會議，經(jīng)審核后，扣除項目經(jīng)理過程管理MD0.2,忘記登錄的按照統(tǒng)一標準處理。2.3.3公司內部論壇的使用

主要是要有利于公司內部開辟一塊公司可以自由發(fā)表言論的地方。同時，在技術討論上，希望能夠把知識點做一個累計，以便新員工能夠進行參考和積極發(fā)表意見。

3開發(fā)部管理流程具體實施方案

3.1內容概述

開發(fā)部從流程上主要分為以下幾方面：（1）開發(fā)部管理人員工作流（2）BUGSurvey工作流（3）項目分析工作流（4）Beta后質量保證工作流（5）測試組beta前工作流（6）項目組運行基本工作流開發(fā)部從實施人員角色劃分如下：開發(fā)部經(jīng)理：（DM01）

統(tǒng)籌解決公司開發(fā)部的全部事宜。進行開發(fā)部的整體計劃的制定和實施，保證開發(fā)部的可持續(xù)發(fā)展和利潤率。

項目總控人員：(DM02)

對公司級的資源進行調配，同時，直接了解日方的戰(zhàn)略安排，為北京方的戰(zhàn)略安排提供的第一手的資料。同時，在項目分配上保證三個分部間項目的均衡（一個季度內）

開發(fā)部部長：(DM10)

在公司統(tǒng)一的規(guī)則范圍內，負責分部的建設。協(xié)調各開發(fā)組的問題，處理解決分部內發(fā)生的問題。做好所有公司要求的標準流程內的內容。同時，在許可范圍內，可以進行單獨的管理方法的嘗試和分部內激勵的分配。

10

＃＃文檔

技術設計負責人：(DM11)

統(tǒng)一協(xié)調分析組的工作，在對日項目分析組中，進行設計文檔的統(tǒng)一確認，在對中方項目中，承擔需求的統(tǒng)一把關處理。同時負責分析組的日常工作安排的統(tǒng)籌。

BUGSurvey總負責人(DM12)：

統(tǒng)一管理package和已經(jīng)提交項目的統(tǒng)籌管理。組織形式上，傾向于單獨的組織模式。在目前的情況下，以靈活為主，臨時性的進行bugSurvey組的組織和bugSurvey組內teamleader的指定和管理。在間隙階段，直接進入分析組進行項目分析工作。

項目總控助理：××(DM13)

輔助開發(fā)部的項目管理工作，主要負責中日雙方的信息的反饋紀錄整理，以及esm和taskschedule信息的維護工作。

負責公司級項目文檔，過程參數(shù)的監(jiān)督，同時向日本總部匯報各種參數(shù)和報表。

常務項目經(jīng)理：(DM20)目前11名

各分部內程序員的日常管理，整個開發(fā)過程中的控制和日方負責人的信息交互，負責組內程序員的績效考核和問題解決。測試部經(jīng)理和翻譯部經(jīng)理包含在內。

技術分析員：(DM21)

對日方的需求進行概要分析和設計，并書寫設計書，F(xiàn)P。對中方的項目中，負責需求的整理和各種設計文檔的實施，同時，負責和項目經(jīng)理和測試部經(jīng)理的溝通。

臨時項目經(jīng)理：(DM22)

此角色主要是在接受日方外包項目或整體公司產品設計中，需要臨時成立項目組，而從分析組中或者常務項目經(jīng)理中抽調。臨時項目經(jīng)理需要全權負責此項目的實施，同時需要和公司簽訂項目負責保證書，以保證項目的進行和最后單獨項目激勵的兌現(xiàn)。程序員：

主要是負責項目按照分析文檔的實施，同時，在實施過程中優(yōu)化代碼結構，提出合理化建議，其中優(yōu)秀者可以作為TeamLeader負責具體組織工作和分析管理工作。測試員：

負責公司測試流程的具體實施，要求掌握測試的技術，提出合理化建議，并保證整個軟件的可靠度。

翻譯人員：

11

＃＃文檔

負責中日方文檔的翻譯，要求工作嚴謹，保證質量。在同日方交流中，負責接待和溝通。同時，在個人的發(fā)展意向中可以兼顧其它公司內的常務工作。

3.2開發(fā)部概要流程圖

軟腦軟件開發(fā)部整體概要流程圖出現(xiàn)bug,進行回歸處理日方委托開發(fā)基本設計書（含DB),Fp表項目總控人員--〉部長--〉常務項目經(jīng)理項目實施，提交alfa版本測試部進行軟件測試，提交beta版本東京項目負責人項目總控助理進行項目信息管理日方委托研發(fā)實施東京方或顧客提出需求北京分析人員進行需求整理書寫hearingsheet制作demo書寫FP表書寫基本設計書（含DB),測試用例Tokyo確認中方項目和顧客進行需求獲取整理UseCase圖分析組實施數(shù)據(jù)庫設計分析組實施項目整體計劃demo和設計文檔類似委托開發(fā)流程

3.3開發(fā)部管理人員工作流

3.3.1軟件開發(fā)管理體系構成參與人員：

項目總控人員（項目總控助理）+部長+（技術設計負責人+BugSurvey負責人）+各級項目經(jīng)理

管理主線：（1）工具類

taskschedule表：主要目的是增加遠程開發(fā)的計劃和規(guī)劃性。

管理人員去合適目前我們正在進行的總量有多少，檢收而為付款的有多少，

實施完畢而沒有檢收的有多少。

12

＃＃文檔

管理人員去看我們下周能夠接受的項目有多少，以便在每周五可以制定下周

的工作計劃。

項目經(jīng)理可以看自己負責項目的基本參數(shù)。

Esm系統(tǒng)：通過esm系統(tǒng)詳細的記錄開發(fā)過程中的每個里程碑參數(shù)，保證在管理上能夠提高管理細度，以便于及時發(fā)現(xiàn)并改正問題和錯誤。

Bug管理系統(tǒng)：作為質量控制過程實際結果的監(jiān)控。以便總結質量的問題，進行反饋。

Fileserver文檔：通過文檔管理和整理，保證全部職員能夠隨時的了解其他項目的信息和相信內容。同時，統(tǒng)一化文檔管理，為以后的發(fā)展提供素材。所有的文檔主要包含如下幾種：

HearingSheet：一個簡要的需求，重點在于強調這個需求的原因（前因后果）UI文件

設計文檔：東京和北京共同進行FP報價書

QuestionSheet：所有的問題一定要集中在一個文檔內

功能點文檔：一定要融合questionSheet內對應答案的所有內容schedule文檔：要包含甘特圖

項目總結及MD分配方案：把項目總結作為重點進行。單體測試用例；條數(shù)最少為MD*2,按照模板進行測試組測試用例:要保證最后的測試結果確認測試用例：一般為東京發(fā)送

beta版后障害書：項目確認者發(fā)送，按照同一格式進行書寫和填寫。beta后障害list表，其中包含bug的簡單描述、bug的類型確定和各部門關

于bug的總結。

（2）過程管理類

一個項目兩次會議：項目啟動會議和項目總結會議

項目啟動會議主要是講述項目的功能點，并據(jù)具體問題，進行嚴格的定義，說明本項目所必須遵守的特殊規(guī)則，子功能間的前后順序，統(tǒng)一的接口定義，和每個人在項目實施中應該注意的問題。

項目總結會議和MD分配方案的確定。主要是根據(jù)項目實施的結果，進行集中的討論

和諧而公平的團隊：公司其他方面的管理，就是為了加強管理，提倡量化。做到各司其職，多勞多得，公平評價，提供機會給相應的人。

13

＃＃文檔

3.3.2管理示意圖

東京客戶需求東京項目總控人員1，開發(fā)內容的規(guī)則及MD確認方案2年度發(fā)展計劃3月度項目工作量規(guī)劃4突發(fā)事件的處理北京北京項目總控人員基本設計書HearingSheet詳細設計書設計文檔審核確認項目控制專員1taskSchedule2下周工作安排項目控制專員（付歆瑋）實現(xiàn)分支管理與統(tǒng)籌安排1功能點描述文檔Merge1。SpecQuestionSheet2.常規(guī)信息傳遞項目質量檢測東京擔當者北京擔當者測試

3.3.3管理人員注意事項

其中反饋機制的建立最關鍵。其中管理必須遵守以下規(guī)則：

對象項目總控人員流程工作內容編號分配項目解決人力矛盾上流方東京項目發(fā)包人員（紀秀玲）部長BugSurvey負責人技術設計負責人部長項目經(jīng)理各級負責人職員項目總控人員下流方部長項目總控助理部長BugSurvey負責人技術設計負責人全體職員備注下流方人員負責把結果反饋給東京擔當者開發(fā)部經(jīng)理公司管理問題一定要給問題提出者答復，成為制度后頒布部長分配項目對應分部項目Esm項目負責人加入，修14

＃＃文檔

項目總控助理項目經(jīng)理項目人力調節(jié)分部管理問題項目分析和問題確認項目里程碑信息反饋項目開始時間，alfa,beta版本時間和原因，fp變更及原因組織團隊進行技術文檔的書寫和維護無無無無經(jīng)理項目總控助理項目總控人員開發(fā)部經(jīng)理東京負責人項目總控人員項目總控助理測試部經(jīng)理改負責人為此項目經(jīng)理如果出現(xiàn)空閑同時反饋。結果物概要需求文檔和問題與回復整理文檔無BugSurvey負責人Bugsurvey的調查修改merge項目總控人員項目總控助理監(jiān)督esm的執(zhí)行情況測試部經(jīng)理監(jiān)督過程管理參數(shù)整理所有項目文檔對日匯報表績效考核提供過程情況匯總組織書寫測試用例整理匯總beta版后bug分析表控制測試的結果程序員項目經(jīng)理部長部長項目經(jīng)理項目經(jīng)理系統(tǒng)數(shù)據(jù)系統(tǒng)數(shù)據(jù)項目經(jīng)理（功能點文檔）項目經(jīng)理（提供的完整的β后障害書）測試部經(jīng)理文檔列表如下：team所有成員功能點文檔questionSheetSchedule單體測試用例各級的bug所有的規(guī)則按照surveyleaderbugsurve流程的規(guī)定。Bugsurvey實施人員項目總控項目總控項目總控項目總控項目總控東京所有管理者月度過程管理處理表其中的技術分析和管理分析及對東京的建議應由項目負責人進行填寫

3.4Bugsurvey工作流

參見《bugSurvey工作規(guī)約》。

3.5項目分析工作流

參見《項目分析工作規(guī)約》

3.6Beta后質量保證工作流

參見《beta后規(guī)作規(guī)約》

3.7測試組beta前工作流3.8項目組基本工作流

3.8.1概述

在項目進行過程中，要求能夠及時反饋。做好計劃安排，并調整這個人力的配比，以達到最好的效果。

15

＃＃文檔

3.8.2對程序員的要求

尤其在分析組成立前期，對分析組的設計書，盡可能提出建設性意見和設計

的問題，有利于提高項目分析能力

在功能實現(xiàn)上，主要和項目經(jīng)理的溝通，把類結構設計和代碼向理想情況努

力，同時用公司內的代碼規(guī)范作為自己的行動準則在日�；顒又校�加強團體意識，加強責任感。

3.8.3對項目經(jīng)理的要求主要職責為：

類設計的嚴格控制。保證整個軟件包的可維護性

項目過程管理。能夠緊密的控制整個項目的進程，發(fā)現(xiàn)項目中的各種風險因

素，盡早地把風險在項目中消除。硬性要求如下：

（1）每個項目（大于10MD正常項目）必須提供的文檔為功能點文檔，

questionSheet，單體測試用例，項目總結及MD最終分配方案文檔

（2）每個項目（大于10MD正常項目）必須召開兩次會議：

項目啟動會議主要為了統(tǒng)一項目的內容規(guī)則和要求，同時把整體邏輯和框架做簡要說明。

項目總結會議：主要是評價每個成員的表現(xiàn)和項目完整的狀況和質量，總結失敗的經(jīng)驗教訓。同時根據(jù)評論的結果進行最后的MD的分配。

（3）在esm必須登陸必要的過程參數(shù)，以便團隊成員和公司的管理者能夠

及時的把我目前項目狀態(tài)。

整個團隊的建設和公司的管理工作。在項目管理中發(fā)現(xiàn)問題，把反映給公司。

以備在公司級別對整個流程和各個環(huán)節(jié)進行調整。3.8.4流程圖

16

＃＃文檔

接收到來自項目總控人員的項目通知關注項目的分析進程并作初步計劃1功能點文檔2uestionSheetEsm系統(tǒng)登錄功能點文檔名稱及服務路徑QuestionSheet文檔名稱及路徑Mail通知測試部經(jīng)理，項目總控助理接收到來自分析組概要設計第一版的通知對概要設計做初步的審核工作確定Alfa/Beta版本郵件通知項目總控助理、測試組負責人必須同時包含：項目開始時間，alfa時間，β版時間esm中登錄項目開始時間esm登錄Alfa/Beta版時間接收到來自分析組詳細設計第一版的通知或者東京發(fā)注結合項目組的情況進行計劃調整制作項目安排文檔（visio或者project）Esm系統(tǒng)登錄項目安排文檔名稱及路徑項目啟動會議，功能點及MD概要分配項目的類結構設計（項目經(jīng)理或程序員進行）項目經(jīng)理審批編碼要遵守編碼規(guī)則和類結構方案，注意討論，切記盲目編碼項目中出現(xiàn)新的問題Mail反饋給文檔作者，并通知部長以上人員，按照反饋機制進行項目組內代碼檢查提交項目經(jīng)理esm輸入代碼檢查開始日期和代碼檢查完成日期BUG管理系統(tǒng)中加入代碼檢查的結果書寫單元測試用例制作單元測試文檔（參考單元測試模板）esm輸入單元測試用例文檔的名稱和對應地址單員測試提交項目經(jīng)理項目經(jīng)理郵件通知測試部經(jīng)理，項目總控助理把單元測試的結果反映到單元測試用例文檔中郵件通知項目總控助理和測試部經(jīng)理發(fā)送測試組DBscript和resource修改文件提交alfa版本項目總結會議，功能點及MD概要分配制作項目總結文檔，以及MD分配方案Esm系統(tǒng)登錄項目總結文檔的名稱及路徑17

＃＃文檔

3.8.5項目組文檔管理

原則：

所有文檔必須都放在fileserver上，進行統(tǒng)一管理。同時，負責人在本地

應保留一份同樣的備份。

201*年開始接收到的項目必須放在201*中，針對每個項目必須按照下圖進

行文檔管理。

細節(jié)描述

項目

Spec

內容

設計說明書QuestionSheet

設計說明書的補充說明設計說明書的各個版本設計說明書一覽表

項目組書寫的單體測試用例測試組書寫的測試用例

東京發(fā)送的confirm測試用例針對項目實施的日程安排

對東京進行進度匯報的每個報表

功能點文檔

備注

設計說明書一覽表要記錄所有文檔變更的情況，并指明最后項目實施與文檔之間的關系

Testcase

Schedule

FunctionPoints

AllBugSpecBeta后障害書

針對此項目的beta后bug類型確定和經(jīng)驗匯總。完畢后，應及時發(fā)送測試組項目經(jīng)理。

UIHtmlDemoHearing聯(lián)系分析組，如果有應該直接copySheetFPSpecFPsheet不同版本

FPchange表FP說明，記錄所有FP變更歷史，以備后期確認的方便。

項目spec的中文版需要打印，此工作由項目總控助理執(zhí)行。同時，對文檔

18

＃＃文檔

進行歸檔和密封。

3.9測試部β版前流程

3.9.1相關人員測試部經(jīng)理：××測試組成員：

3.9.2測試人員的要求

一定要注意配合。因為，在此環(huán)節(jié)，一種好的描述方式和溝通方式將會直接

影響工作效率和工作質量。所以，首先大家要注意bug管理系統(tǒng)的使用方法和規(guī)則，同時，盡量采用統(tǒng)一的屬于進行描述，如果需要圖形輔助，也可以進行貼圖。

加強需求理解能力。能夠盡快的理解文檔和功能測試用例。在工作中細致、耐心、有條理。

同時對應esm系統(tǒng)需要測試部填寫的過程參數(shù)必須嚴格按照規(guī)定填寫。

3.9.3工作流程圖

19

＃＃文檔

接收到功能點文檔書寫測試用例esm登錄測試組測試用例文件名稱及路徑接收到項目經(jīng)理的Alfa/Beta版通知并參考esm上的項目信息項目測試安排esm登錄測試負責人核查以下條件：1是否已經(jīng)發(fā)送測試組DBscript和Resource改動，并驗證正確性2單體測試用例是否全部填入單體測試結果接到項目組提交的Afla版通知后按照功能測試用例，開始測試條件不具備，不能進行測試，同時發(fā)通知給對應負責人確認連接在測試數(shù)據(jù)庫上確認已經(jīng)執(zhí)行DBscritpt和resource修改esm登錄第一階段測試開始時間第一階段測試測試依據(jù)：測試組所整理的測試用例BUG管理系統(tǒng)登錄Alfa測試BUG第一階段測試結束MAIL通知項目負責人，同時確認bug管理系統(tǒng)中alfabug的類型和個數(shù)ESM系統(tǒng)中登錄第一階段完成時間esm中登錄Alfa版本后的bug數(shù)回歸測試測試完畢，esm登錄回歸測試結束時間提交Beta版DBscript和Resource修改放在fileserver對應項目目錄下FTP上傳DBscript和Resource修改到東京服務器向日方：中山幸子、初宏偉、項目負責人，正式發(fā)布Beta通知接收到Beta后bug啟動beta版后流程規(guī)約

3.9.4注意事項

Bug管理系統(tǒng)中的狀態(tài)一定要維護，并通過此系統(tǒng)來保證alfabug修改的進

行情況，即在提交beta版前，所有的alfabug的狀態(tài)都應該在DO上。如果沒有在此狀態(tài)中，應該積極和項目組聯(lián)系，測試組有權監(jiān)督其完成。測試組要驗證項目組提交的script和resoruce文件，如果有問題，測試組

20

＃＃文檔

有權通知項目立即修改，同時可以作為alfabug登錄在bug管理系統(tǒng)中。測試組要保證測試用例的質量，盡一切可能減少beta后bug的數(shù)量。并嚴格

的按照beta后bug處理規(guī)約進行。

4績效考核實施方案

4.1總則：

所有職員的所有工作都應該以量化計算，如果不能，則當事者可以提出異議，

而對績效考核方法進行改進。

例如所有北京項目必須有MD，翻譯組翻譯工作量可以通過翻譯的字數(shù)進行調整，測試組同樣對工作內容進行分類核算MD。量化管理主要包含幾個主題方向：

工作時間：是人事部門公布的每個月的工時統(tǒng)計的結果。實際上，它代表了自己的實際消耗時間。

東京MD：是實際為公司所創(chuàng)造的價值。

北京MD：主要包含正規(guī)作的北京內部項目或者實際工作而作的的補充MD。已達到考核的公平合理。

質量扣除MD:是指由于代碼的bug而造成的損失，因為實際的貢獻是要扣除損失的。對于測試部就是東京對北京確認產生的beta后故障的扣除。

過程管理扣除MD：除了實際的工作量，就是為個建立一個穩(wěn)固高效的團隊而每個人應該承擔的過程管理義務，如果沒有做好，實際上不僅僅是你自己績效不高，而是你影響了整個團隊的利益。而這部分的值反映了你對團隊的影響。

過程管理獎勵MD：在項目實施過程中，個人在突發(fā)事件上的處理或者對項目整體乃至公司的利益上作出突出貢獻，可以作為績效獎勵。

在整個分類上，基本上是劃分為管理者，程序員，分析員，翻譯人員，測試人

員幾個子系統(tǒng)。但是所有系統(tǒng)的價值標準統(tǒng)一。在時間上，每個月的第五個工作日公布績效考核結果。

績效考核的結果直接反映在近期和長期的激勵系統(tǒng)中。具體內容可以參見

4.2流程圖

翻譯組MD核算流程

21

＃＃文檔

翻譯組安排記錄算有翻譯的字數(shù)月度績效考核年度按照8500字/MD進行核算測試組MD核算流程

測試組接收功能點文檔通知書寫測試用例按照MD10％Alfa通知驗證測試用例測試實施按照MD10％提交beta版接到東京通知后，填寫beta后bug歸總表月度績效報表，根據(jù)beta后bug進行質量扣除計算項目組MD核算流程

分配原則：1。項目組可以支配的額度為90％（扣除測試部的10％）2剩余90％的分配額如下：項目分析控制：10％機動MD：10％項目實施及單體測試：70％程序員最后確定的MD登陸esm項目經(jīng)理確認項目經(jīng)理整理MD分配表存檔接收tokyo的order根據(jù)FP確認方案，和對方擔當者進行協(xié)商參看schedule文檔和功能點文檔進行MD的初期分配項目總結會議上，對初期計劃不合理的地方進行調整。項目總結會議上，對10％的機動MD進行分配，鼓勵

分析組MD核算流程

22

＃＃文檔

分析組項目分析開發(fā)規(guī)約進行核算MDMD有異議，書面提交說明給馬俊馬俊和項目總控人員進行協(xié)商，確定后回復擔當者北京自我研發(fā)項目也按照日本發(fā)包要求進行事項

測試組績效

內容

主要根據(jù)測試的工作量和工作結果來進行MD的度量

主要是根據(jù)beta后bug進行，如果出現(xiàn)beta后bug同時被確認為實施bug，對應測試人員應該承擔質量責任，按一個實施bug扣除0.1MD計算

目前是測試工作本身項目MD×10％

測試用例的書寫是項目MD×10％

項目分析指拿到文檔后，進行的需求詳細分析，提出問題，完畢questionSheet文檔和功能電文檔

注意

強調質量，會加大質量影響的力度。

要注意參看beta后bug匯總表。

負責人

測試部經(jīng)理

備注

要按項目進行分配，多退少補。

測試組最關鍵的問題是根據(jù)β后的bug情況做分析總結，可向公司申請bug分析內部文檔，通過后可按北京項目補充MD

第一月后根據(jù)測試用例書寫的實際工時和狀況重新審核此百分比MD分配時誰分析誰拿走對應的10％的MD

測試組質量考核

測試組工作量百分比

項目分析工作量

項目組質量考核

嚴格按照alfa版后的bug進行，一個bug扣除0.1MD

目前的測試用例由于是初步書寫。所以僅限于第一月

原則上項目經(jīng)理直接進行，同時也可以委托組內具有分析能力的程序員進行，但是必須是項目經(jīng)理負責制

Alfa版的bug登錄在bug管理系統(tǒng)中，項目經(jīng)理要維護此系統(tǒng)的Plan欄目，程序員要負責其中的DO欄目。如果不填寫直接作為過程管理扣除MD進行，一次0.1MD

此工作包含在實施70％的范圍內。

所以項目經(jīng)理要

項目總控人員

項目經(jīng)理

測試部經(jīng)理項目經(jīng)理

項目組單體測試用例工作量核算項目經(jīng)理和全體單體測試用例的條數(shù)必須大于MD×2，核算項目經(jīng)理直接指定

全體team（包含自身在

項目經(jīng)理

Alfa版質量扣除MD的匯總表測試部經(jīng)理負責。

Alfa版過程管理扣除MD匯總表由測試部經(jīng)理負責。

項目總控助理負責審核測試部經(jīng)理的工作，如果出現(xiàn)紕漏，按過程管理扣除MD計算，一次0.1md

項目經(jīng)理由項目總控助理進行監(jiān)

23

＃＃文檔

管理者自身績效評定年底績效評定標準年底績效加權系數(shù)確定內）的平均值直接利用MD進行評價項目經(jīng)理加權1.25分析組加權1.1翻譯組加權8500字/MD進行折算提高整個團隊的績效為目標其中包含東京MD和北京MD控。出現(xiàn)問題按過失進行處理。伴隨業(yè)務和過程的改變，如果系數(shù)有一定的偏差，由項目總控人員對此系數(shù)進行調整，反映在文檔改版中，并通知全體人員項目總控人員項目總控人員5開發(fā)部激勵和過失管理流程

5.1激勵管理系統(tǒng)

5.1.1定義：

激勵指職員對公司作出貢獻的對應回報。旨在體現(xiàn)公司公平的原則，客觀的對個人的能力和價值進行認可。類別與處理方法：

類別名稱描述特別MD獎勵在項目中作為突出貢獻，對公司的利益產生重大影響�？捎刹块L提出申請，項目總控人員進行批示。特別獎金獎在項目中作為突出貢獻，對公司的利益勵產生重大影響。可由管理者直接提議，部長會議進行討論決定。部門內項目部長負責制，按季度抽取項目的激勵獎獎金金。內容是骨干人員，突出貢獻者和分部內的個別活動。（同時，適用測試部和分析組）金額為：2×[東京MD－質量扣除MD]公司資助培管理者提議，部長會議審議。針對公司訓的要求和個人情況，提議確定人選和額度。升職參考績效表，考察個人能力，并征求個人意見后，進行職位調整。以給有技術或管理能力的人充分的空間。加薪參考績效表，考察個人能力（技術等級表），于每年8月和1月啟動調整薪金調查程序，對應該薪金的人進行處理年終獎金年終獎金額度由東京董事會根據(jù)北京利益情況進行直接確定獎金分配采用同一職能部門公開化，計算方法，嚴格按照個人MD（貢獻MD－扣除MD）的百分比進行直接計算。

實施方式特別獎勵單特別獎勵單財務撥款通知單項目獎金分配明細表培訓通知書升職通知書薪金調整單年終獎金分配表適用范圍全體員工備注激勵的定義和類別

全體員工開發(fā)部內全體員工突出貢獻者或特別崗位管理者考察通過人員管理者考察通過人員全體員工5.2過失管理系統(tǒng)

5.2.1定義：

24

＃＃文檔

過失泛指由于本人的失誤和錯誤，對公司的利益或潛在利益造成比較大的影響和比較大的損失的行為，稱作過失。

5.2.2類別：（過失單的類別部分必須從下面列表中取得）

類別名稱決策過失描述在公司級的問題上，由于考慮問題不周，或沒有廣泛討論或沒有上級的同意而匆忙下確定，在結果上造成損失或嚴重影響。沒有貫徹成文或討論會議上的決議，在運作上自己決定，在結果上造成損失或嚴重影響。在技術過程管理上，中層領導應全盤負責技術處理的決定和整個開發(fā)過程的督導，如果在實現(xiàn)上漏掉其中的過程或沒有督導，在結果上造成損失或嚴重影響。沒有遵守公司的規(guī)章制度，經(jīng)規(guī)勸后無效果的。同時，在公司范圍內造成較大影響的。由于在具體實現(xiàn)上，出現(xiàn)失誤，造成損失或嚴重影響。但是必須經(jīng)過評審組的詳細調查和本人同意。如果此問題是由于工作態(tài)度或缺乏責任心引起的，加大處理力度。公司針對管理責任化的原則，制定具體的人承擔特定的職責。如果，在指定職責范圍內，出現(xiàn)重大失誤。適用范圍管理者和中層管理層管理者和中層管理層管理者和中層管理層備注運作管理過失技術過程管理過失既是直接責任人為某個人，也要主體負責違反公司規(guī)章過失技術實現(xiàn)過失公司全體職員開發(fā)部全體職員特別職責過失特別職責負責人其他過失伴隨著新的要求和管理的變化而產生的新的類型的過失。公司全體員工如果在特別職責范圍內表現(xiàn)突出，可以優(yōu)先考慮特別獎勵制度對應此項，要加強審核制度，避免主觀化5.2.3過失處理的種類：

過失處理可以采取并罰制度。類別名稱公司通報描述在月度會議（結合績效總結會議）上，進行通報。Md的補充處理根據(jù)影響的程度和過失的程度來確定。MD計入當月的績效考核，MD的類型為北京MD。適用范圍為固定MD的項目和業(yè)務過失或項目管理過失。罰金根據(jù)影響度和后果，進行度量�？紤]到解決問題為本，警示為主的原則。在數(shù)額分50/100/150/200，共4個等級。備注重點強調避免辦法同時，要客觀尊重實際MD,但是此處理要直接影響月度考評和年底考評。此種類型的處罰，不得在季度績效考核中取得特別獎勵。25

＃＃文檔

降薪過失影響很巨大，同時，過失人沒有改正的傾向。工作態(tài)度或工作結果在長時間沒有進展，不符合本身的業(yè)務標準或薪資標準。

5.2.4制度實施流程

過失管理流程管理者根據(jù)客戶反饋或工作效益，就具體責任人提出過失處理提議評審組本人解釋相關內容和過程提出調查組織評審組，至少3人，確定3個代表通知責任當事人，準備資料和申辯材料接收到評審組通知后準備資料過失評審，表決總結提出提議的時機和方式方法，向當事人道歉解釋否通過否總結自己的行為是否有連帶責任是填寫過失單過失單發(fā)送人事部抄送管理者和績效考核人員績效管理上處理5.2.5幾點補充說明：

26

＃＃文檔

首先過失和特別獎勵的數(shù)目在總體上要把握，原則上不能超過月度3事件（一個

事件可能牽涉多個責任人），同時，要把握時機，基本上要在事件后3-4天處理，保證其情緒化和調查不詳細的影響。

評審組的成立。原則為相關事件的相關人員，責任人的直接上司。不能低于三人，

要求評審組在當事人面前，進行所有的活動。凡是有意庇護或回避意見，可以取消評審組資格，同時考慮其過失行為。

與績效相關部分的處理，解釋權歸公司，任何當事人有權利詢問任何處理影響。

同時，在處理意見上要寫清楚。

所有當事人，都要本著把事情處理好，并把以后的工作做得更好的原則去進行。

從大處著眼，以認識問題為主，這也是公司處理的根本，而非處罰某人。所有的處理決定，都要本人書寫意見，如果本人不同意，任何人沒有權利強行實

施。

“避免過失的方法“，由評審組統(tǒng)一討論填寫，這是整個過失管理的主題。評審

組不能對此項進行簡略或應付，同時，需要得到當事人的認可。

27

友情提示：本文中關于《軟件項目開發(fā)工作流程》給出的范例僅供您參考拓展思維使用，軟件項目開發(fā)工作流程：該篇文章建議您自主創(chuàng)作。

來源：網(wǎng)絡整理 免責聲明：本文僅限學習分享，如產生版權問題，請聯(lián)系我們及時刪除。

《軟件項目開發(fā)工作流程》由互聯(lián)網(wǎng)用戶整理提供,轉載分享請保留原作者信息,謝謝!
鏈接地址：http://m.taixiivf.com/gongwen/722204.html

• 上一篇：個人體驗~軟件開發(fā)中的項目管理
• 下一篇：如何做好商業(yè)銀行的客服