文檔 1 軟件項目開發流程 修改歷史 日期 作者 修改內容 2003京宇 新規制作 2003京宇 人員職責的變更，內容的變更 2003京宇 針對 2004 年度制作最新工作內容下的工作流程 2004京宇 添加項目經理管理被職員填寫下周日程表的規則 文檔 2 1 概述 . 3 的 .容概述 . 開發部日常管理流程具體實施方案 . 3 本原 則 .容概述 .容 詳細 描述 . 開發部管理流程具體實施方案 . 10 容概述 .發 部概要流程 圖 .發 部管理人 員 工作流 . 目分析工作流 . 質 量保 證 工作流 .試組 工作流 . 目 組 基本工作流 .試 部 版前流程 . 績效考核實施方 案 . 21 則 ： .程 圖 . 開發部激勵和過失管理流程 . 24 勵管理系 統 . 失管理系 統 . 文檔 3 1 概述 的 用標準化的流程來統一管理公司的運作，避免混亂，提高管理的質量。 在遠程開發上，結果 軟件自身的特點，量身定做，解決遠程開發上的問題。 在實施過程中，所有管理者能夠根據此統一的流程 ，總結經驗，提高認識，加強技術水平和管理水平。 提高公司級的技術分析能力，為公司儲備一支分析隊伍，側重在需求理解和需求分析、框架設計上的能力。保證在 2004 年能夠全盤進行中方市場的順利運作。 對人員負責內容上，明確化各自負責的內容，提高工作效率。 容概述 開發部日常工作流程 開發部管理流程 開發部績效考核流程 開發部激勵和過失管理流程 2 開發部日常管理流程具體實施方案 本原則 公司開發部力求建立公平公正的評價體系，嚴謹的工作流程定義和及時的記錄與反饋，規范職員活動，形成一個緊張有序的團隊。 沒有一個明 晰的流程和高效的反饋體系，就不可能把工作做好。但是，這需要每個人按照規則把自己應該負責的那一部分高效完成，只有這樣才能保證整個系統的順暢，同時，如果個人沒有完成自己的指責和按照規定填寫內容，影響的不單單是自己的工作而是整個系統。 容概述 用規則 目的注意是為了提高開發部整體的計劃能力，反饋能力和管理者的控制能力。同時提高整體職員參與公司管理的渠道，適應東京上市公司對信息管理的要求。 日常活動的方法 提供開發部工作流程外的突發事件的解決方法 容詳細描述 用規則 （ 1） 使用 文檔 4 加強全體人員的計劃能力，做到我每天要做什么？今天項目經理給我的安排是什么？對應項目經理和部長要知道每個人在做什么？只有這樣，才能保證控制人員可以宏觀調控，而個人也不會不知所措。 注意事項： 1. 必須使用長期類型（哪怕只有一天）保持統一性 2 開始時間必須為 22： 00 結束時間為 23： 00， （為了區分其它人填寫的日程安排） 3 填寫日程安排時，必須選擇對應的 則不能于系統內的項目關聯，統計軟件失去作用。 4 日程安排的主題要修改，規則為項目號（中文版項目為北京內部項目編號），暫時沒有 編號可以寫項目名稱。 內容 負責人 填寫要求 監督人 違規處理 下周工作安排 項目經理 技術分析負責人 測試組經理 必須每周五 16： 00 前填寫完畢。同時類型統一用長期進行定義，為每一個人員安排下周工作計劃。 填寫監督：項目總控助理 內容監督：部長和項目總控人員 沒有按時提交的，管理者扣除 常活動安排 開發部全體人員 建議大家把工作安排填寫，有利于提高自己的計劃能力和規劃能力。同時能保證事情不會忘記。 無 待辦事項 開發部全體人員 建議填寫，管理者應該必須使用。主要是把事務管理的井井有 條。 無 制作下周工作安排表 項目總控助理 負責利用工具【導出下周工作表系統】制作開發部下周工作計劃表。每周五下班前發送東京。 東京項目負責人 文檔 5 （ 2） 使用 作為上市公司的子公司要求公司正規化，第一步公司的日報系統的建立和審查，所以從本年度起必須建立此系統。同時，在管理上解決口頭匯報，不客觀而事后而無據可查的弊端，為及時了解問題并解決問題，提供第一手的素材。 同時項目總控助理，也要本著實事求是的原則，根據大家的填寫內容向東京證券市場提交作業公務表， 所有填寫者一定要保證填寫日報的 消耗工時和最后工資結算時當日工時保持嚴格一致 。 內容 對應 填寫要求 監督人 違規處理 項目選擇 項目 直接選擇自己對應的項目 ,如果工作對象不是項目本身則需要選擇以下項目 :(顧客名稱為 2004年過程管理專用 ) 公司會議 公司培訓 公司管理 其它 注意 :只有部長以上才填寫以上項目 (公司培訓除外 ),部長以下全部選擇對應項目。見附圖 1 扣除 文檔 6 當日工作內容和進度 工作內容與進度 1 填寫當日的模塊名稱（模塊名稱參考 2 中的功能點表） 3 細度要求功能點 填寫監督： 內容監督：項目經理 沒有填寫 1 次人民幣 5 元 工作耗時 工作耗時 要求與工資計算工時想對應。（ 數據庫的數字和工時統計必須對應，此為東京證券的要求） 數字核對： 數字不對者，題反饋 問題反饋 把當天所遇到的問題按照條目化羅列。 必須包含內容和狀態兩部分 例如： 1 內容： 態：已經解決 2 內容：文檔 現問題，無法繼續。狀態：等待解決 內容監督：項目經理 不付責任的亂填或不填，一個日報扣除 果在特殊情況下無問題，也要寫無 ) 入 訂貨（預定）金額 必須在項目總結會議結束之后，同時要經過項目經理的審核。 輸入值為實際值的 10 倍（因為數值型目前只能為整數） 職員的輸入由項目經理負責 項目經理的核對由項目總控助理進行 職員如果不填寫則按照輸入值進行績效考核。 如果職員輸入的圖 1： （ 3） 周報（ 報（ 使用 主要是使用對象為管理者，主要是適用于向管理者匯報整體問題。在概念上，日 文檔 7 報周報為概括說明，而 屬于細節描述。 內容 負責人 填寫 要求 監督人 違規處理 日報 項 目 經 理 部 長部長 項目進展狀況： 不能解決的問題反饋 建議或提議 突發問題必須反饋 項目總控人員 如果由于沒有匯報造成問 題 ， 按 一 次 扣 報 項目經理部長 部長項目總控 項目進展整體狀況： 不能解決的問題反饋 建議或提議 必須填寫 項目總控助理 周報不寫， 4） 目標功能的使用 由于分部內有單獨的激勵費用，所以建議分部內建立目別考核體系。為每一個程序員根據個人不同的能力和狀況設定目標，對于圓滿完成目標者進行鼓勵。同時，保證公司的開發效 果在可控制范圍內。 （ 5） 項目信息管理的使用。 本管理系統在 2003 年開始實行，主要目前是記錄公司所有項目的里程碑信息。為以后項目的整理和后期處理提供真實的數據。同時，維護公司的項目信息數據庫。 注意事項 ： 其中關于項目中所設計的文檔，統一放在 2004 目錄中。 關于文檔名稱和路徑的書寫方法如下 ,保證能夠盡快打開文檔：/004/14258/測試用例 / 2004 年 1 月 1 號起 ,東京新項目 項目 要求 對應負責人 出錯處理方法 備注 項目名稱 必填，同時應有對應的項目號 扣除 北京項目編號 必填 扣除 加時一定要注意唯一性，與 項目類型 不能為空，目前類型有 扣除 前的規則為小于5均為目 文檔 8 目名稱 必填 扣除 目的名稱應包含項目的 于項目 生成方法，參考日方對應文檔 客戶方負責人 必填 扣除 分析負 責人 北京分析項目，為必填項目 東京設計，為非必填 部長（但是必須制定具體負責人） 扣除 項目負責人 必填項目 部長 扣除 目負責人應該是直接負責人（不是最先指定的部長） 本公司負責人 不能為空 初始必填的人員為項目總控人員及助理、對應部長、測試部經理 ,公司技術負責人（馬俊） 項目負責人 扣除 果沒有項目負責人，與 聯系 分析開始時間 必填 對應該項目的分析員 扣除 司技術負責人在分析項目開始時應把對應分析員加到項目列表中 概要設計完 成時間 必填 對應該項目的分析員 扣除 詳細設計完成時間 必填 對應該項目的分析員 扣除 檔完成時間 必填 對應該項目的分析員 扣除 分析完畢時間 必填 對應該項目的分析員 扣除 項目接收時間 必填 扣除 項目最終對應 則不為空，在特殊情況下為空，在項目備注重必須說明原因。 項目經理（ 知） 扣除 隨著 變更需要動態變化 更附件名稱 不是必須，但是只要有變更有內容，此項目必須要有 項目經理（ 知） 扣除 項目最終報價 原則不為空，在特殊情況下為空，在項目備注重必須說明原因。 扣除 須與對應1000 基本一致。同時必須和 必填 項目經理 扣除 以用 者是 客戶方 如果提供必填 扣除 時間 必填 項目經理（ 知） 扣除 時間 必填 項目經理（ 扣除 文檔 9 知） 更紀錄 最后一次記錄變更的時間必須和對應的 時間和時間一致 項目經理（ 知） 扣除 項目開始時間 必填 項目經理（ 知） 扣除 支號 必填 項目經理 扣除 分支號為開發分支號 功能點文檔文件名及 文 件 路 徑（ 務器） 必填 項目經理 扣除 文 檔為 必 須 文檔，各項目經理必須嚴格控 制。 單體測試用例文件名稱及文件路徑 必填 項目經理 扣除 文 檔為 必 須 文檔，各項目經理必須嚴格控制 項目總結與 配方案文檔及文件路徑 必填 項目經理 扣除 文 檔為 必 須 文檔，各項目經理必須嚴格控制。 測試負責人 必填 扣除 測試用例對應文件名稱 及路徑 必填 扣除 文 檔為 必 須 文檔，各項目經理必須嚴格控制。 第一 階 段 測試開始 時間 ： 必填 測試人員 扣除 第一 階 段 測試 完成日期： 必填 測試人員 扣除 本后的 必填 測試人員 扣除 回 歸測試 的 開 始日期： 必填 測試人員 扣除 回 歸測試 的 結 束日期： 必填 測試人員 扣除 后的 必填 扣除 要要參考 整理表 確認負責人 不是必須， 主要是與是否進行確認有關，如果確認其他有信息，確認負責人必填 扣除 統 的使用 （ 1） 電子打卡系統的使用 目的：主要是利用電子打卡，提高效率，能夠及時反映請假和遲到，并且所有的數據能 夠直接被人事利用。 要求： 文檔 10 2004 年 2 月開始啟用， 2 月為試用期，但是要求每人必須嚴格填寫，如果不填寫并結合打卡， 忘記填寫扣除過程管理 算。 （ 2） 會議室、洽談室、經理室的使用管理 目的：主要是在人數多而會議室相對緊張的狀態下，解決矛盾的一種方法。同時審核各項目組是否及時安排公司規定的兩次會議。 2004 年 2 月啟動，沒有按照規定進行會議，經審核后， 扣除項目經理過程管理 記登錄的按照統一標準處理。 司內部論壇的使用 主要是要有利于公司內部開辟一塊公司可以自由發表言論的地方。 同時，在技術討 論上，希望能夠把知識點做一個累計，以便新員工能夠進行參考和積極發表意見。 3 開發部管理流程具體實施方案 容概述 開發部從流程上主要分為以下幾方面： （ 1） 開發部管理人員工作流 （ 2） 作流 （ 3） 項目分析工作流 （ 4） 質量保證工作流 （ 5） 測試組 工作流 （ 6） 項目組運行基本工作流 開發部從實施人員角色劃分如下： 開發部經理：（ 統籌解決公司開發部的全部事宜。進行開發部的整體計劃的制定和實施，保證開發部的可持續發展和利潤率。 項目總控人員： ( 對公司級的資源進行調配，同時，直 接了解日方的戰略安排，為北京方的戰略安排提供的第一手的資料。同時，在項目分配上保證三個分部間項目的均衡（一個季度內） 開發部部長： ( 在公司統一的規則范圍內，負責分部的建設。協調各開發組的問題，處理解決分部內發生的問題。做好所有公司要求的標準流程內的內容。同時，在許可范圍內，可以進行單獨的管理方法的嘗試和分部內激勵的分配。 文檔 11 技術設計負責人： ( 統一協調分析組的工作，在對日項目分析組中，進行設計文檔的統一確認，在對中方項目中，承擔需求的統一把關處理。同時負責分析組的日常工作安排的統 籌。 負責人 ( 統一管理 已經提交項目的統籌管理。組織形式上，傾向于單獨的組織模式。在目前的情況下，以靈活為主，臨時性的進行 的組織和 內指定和管理。在間隙階段，直接進入分析組進行項目分析工作。 項目總控助理： (輔助開發部的項目管理工作，主要負責中日雙方的信息的反饋紀錄整理，以及 息的維護工作。 負責公司級項目文檔，過程參數的監督，同時向日本總部匯 報各種參數和報表。 常務項目經理： (目前 11名 各分部內程序員的日常管理，整個開發過程中的控制和日方負責人的信息交互，負責組內程序員的績效考核和問題解決。測試部經理和翻譯部經理包含在內。 技術分析員： (對日方的需求進行概要分析和設計，并書寫設計書， 中方的項目中，負責需求的整理和各種設計文檔的實施，同時，負責和項目經理和測試部經理的溝通。 臨時項目經理： (此角色主要是在接受日方外包項目或整體公司產品設計中，需要臨時成立項目組，而從分析組中或者常務項目經理中抽調 。臨時項目經理需要全權負責此項目的實施，同時需要和公司簽訂項目負責保證書，以保證項目的進行和最后單獨項目激勵的兌現。 程序員： 主要是負責項目按照分析文檔的實施，同時，在實施過程中優化代碼結構，提出合理化建議，其中優秀者可以作為 責具體組織工作和分析管理工作。 測試員： 負責公司測試流程的具體實施，要求掌握測試的技術，提出合理化建議，并保證整個軟件的可靠度。 翻譯人員： 文檔 12 負責中日方文檔的翻譯，要求工作嚴謹，保證質量。在同日方交流中，負責接待和溝通。同時，在個人的發展意向中可以兼顧其它公司內的常務工作。 發部概要流程圖 軟腦軟件開發部整體概要流程圖日方委托研發實施中方項目日方委托開發基本設計書（ 含項目總控人員 部 長 常 務項目經理，項 目 實 施 提交 本項目總控助理進行項目信息管理測試部進行軟，件 測 試 提 交本東京項目負責人出現 進行回歸處理東京方或顧客提出需求北京分析人員進行需求整理書寫 認制作 寫 書寫基本設計（書 含 測試用例和顧客進行需求獲取整理分析組實施數據庫設計分析組實施項目整體計劃發部管理人員工作流 件開發管理體系構成 參與人員 ： 項目總控人員（項目總控助理） +部長 +（技術設計負責人 +責人） +各級項目經理 管理主線： （ 1）工具類 ：主要目的是增加遠程開發的計劃和規劃性。 管理人員去合適目前我們正在進行的總量有多少，檢收而為 付款的有多少，實施完畢而沒有檢收的有多少。 文檔 13 管理人員去看我們下周能夠接受的項目有多少，以便在每周五可以制定下周的工作計劃。 項目經理可以看自己負責項目的基本參數。 統 ： 通過 統詳細的記錄開發過程中的每個里程碑參數，保證在管理上能夠提高管理細度，以便于及時發現并改正問題和錯誤。 理系統： 作為質量控制過程實際結果的監控。以便總結質量的問題，進行反饋。 檔 ：通過文檔管理和整理，保證全部職員能夠隨時的了解其他項目的信息和相信內容。同時，統一化文檔管理，為以后的發展 提供素材。所有的文檔主要包含如下幾種： 個簡要的需求，重點在于強調這個需求的原因（前因后果） 件 設計文檔： 東京和北京共同進行 價書 有的問題一定要集中在一個文檔內 功能點文檔：一定要融合 對應答案的所有內容 檔：要包含甘特圖 項目總結及 配方案：把項目總結作為重點進行。 單體測試用例；條數最少為 ,按照模板進行 測試組測試用例 : 要保證最后的測試結果 確認測試用例： 一般為東京發送 后障害書：項目確認者發送，按照同一格式進行書寫和填寫。 障害 ，其中包含 簡單描述、 類型確定和各部門關于 總結。 （ 2）過程管理類 一個項目兩次會議：項目啟動會議和項目總結會議 項目啟動會議主要是講述項目的功能點，并據具體問題，進行嚴格的定義，說明本項目所必須遵守的特殊規則，子功能間的前后順序，統一的接口定義，和每個人在項目實施中應該注意的問題。 項目總結會議和 配方案的確定。主要是根據項目實施的結果，進行集中的討論 和諧而公平的團隊 ：公司其他方面的管 理，就是為了加強管理，提倡量化。做到各司其職，多勞多得，公平評價，提供機會給相應的人。 文檔 14 理示意圖 客 戶 需 求分 支 管 理 與 統 籌 安排東 京 項 目總 控 人 員東 京 擔 當者項 目 控 制專 員 （ 付歆 瑋 ）北 京 項 目總 控 人 員北 京 擔 當者設 計 文 檔 審 核 確 認項 目 質 量 檢 測1 t a s k S c h e d u l 下 周 工 作 安 排項 目 控 制專 員1 ， 開 發 內 容 的 規則 及 M D 確 認 方 案2 年 度 發 展 計 劃3 月 度 項 目 工 作 量規 劃4 突 發 事 件 的 處 理1 。 S p e c Q u e s t i o n S h e e 常 規 信 息 傳 遞基 本 設 計 書H e a r i n g S h e e 設 計 書實 現M e r g 北 京東 京1 功 能 點 描 述 文 理人員注意事項 其中反饋機制的建立最關鍵。其中管理必須遵守以下規則： 對象 流程編號 工作內容 上流方 下流方 備注 項目總控人員 分配項目 東京項目發包人員（紀秀玲） 部長 項目總控助理 解決人力矛盾 部長 責人 技術設計負責人 部長 責人 技術設計負責人 下流方人員負責把結果反饋給東京擔當者 開發部經理 公司管理問題 部長 項目經理 各級負責人 職員 全體職員 一定要給問題提出者答復，成為制度后頒布 部長 分配項目 項目總控人員 對應分部項目 目負責人加入，修 文檔 15 項目總控助理 經理 項目總控助理 改負責人為此項目經理 項目人力調節 無 項目總控人員 如果出現空閑同時反饋。 分部管理問題 無 開發部經理 項目經理 項目分析和問題確認 無 東京負責人 結果物概要需求文檔和問題與回復整理文檔 項目里程碑信息反饋 項目開始時間，本時間和原因， 更及原因 無 項目總控人員 項目總控助理 測試部經理 組織團隊進行技術文檔的書寫和維護 無 測試部經理 有成員 文檔列表如下： 功能點文檔 體測試用例 責人 調查修改目總控人員 各級的 ug 施人員 所有的規則按照程的規定。 項目總控助理 監督 執行情況 程序員 項目經理 部長 項目總控 監督過程 管理參數 部長 項目經理 項目總控 整理所有項目文檔 項目經理 項目總控 對日匯報表 系統數據 項目總控 績效考核提供過程情況匯總 系統數據 項目總控 月度過程管理處理表 測試部經理 組織書寫測試用例 項目經理（功能點文檔） 東京 整理匯總 后 項目經理（提供的完整的后障害書） 所有管理者 其中的技術分析和管理分析及對東京的建議應由項目負責人進行填寫 控制測試的結果 作流 參見 作規約。 目分析工作流 參見項目分析工作規約 參見 規作規約 試組 工作流 目組基本工作流 述 在項目進行過程中，要求能夠及時反饋。做好計劃安排，并調整這個人力的配比，以達到最好的效果。 文檔 16 程序員的要求 尤其在分析 組 成立前期， 對 分析 組 的 設計書 ，盡可能提出建 設 性意 見 和 設計的 問題 ，有利于提高 項 目分析能力 在功能 實現 上，主要和 項 目 經 理的溝通，把 類結 構 設計 和代 碼 向理想情況努力，同 時 用公司內的代 碼規 范作 為 自己的行 動 準 則 在日常活 動中，加強團體意識，加強責任感。 項目經理的要求 主要職責為： 類設計的嚴格控制。保證整個軟件包的可維護性 項目過程管理。能夠緊密的控制整個項目的進程，發現項目中的各種風險因素，盡早地把風險在項目中消除。 硬性要求如下： （ 1） 每個項目（大于 10常項目）必須提供的文檔為功能點文檔，體測試用例，項目總結及 終分配方案文檔 （ 2） 每個項目（大于 10常項目）必須召開兩次會議： 項目啟動會議主要為了統一項目的內容規則和要求，同時把整體邏輯和框架做簡要說明。 項目總結會議：主要是評 價每個成員的表現和項目完整的狀況和質量，總結失敗的經驗教訓。同時根據評論的結果進行最后的 分配。 （ 3） 在 須登陸必要的過程參數，以便團隊成員和公司的管理者能夠及時的把我目前項目狀態。 整個團隊的建設和公司的管理工作。在項目管理中發現問題，把反映給公司。以備在公司級別對整個流程和各個環節進行調整。 程圖 文檔 17 接 收 到 來 自 項目 總 控 人 員 的項 目 通 知關 注 項 目 的 分 析 進程 并 作 初 步 計 劃接 收 到 來 自 分析 組 概 要 設 計第 一 版 的 通 知對 概 要 設 計 做 初 步的 審 核 工 作接 收 到 來 自 分 析 組 詳細 設 計 第 一 版 的 通 知或 者 東 京 發 注結 合 項 目 組 的 情 況進 行 計 劃 調 整項 目 的 類 結 構 設 計 （ 項 目經 理 或 程 序 員 進 行 ）項 目 經 理 審 批編 碼項 目 組 內 代 碼檢 查單 員 測 試提 交 項 目 經 理e s m 輸 入 代 碼 檢 查 開 始 日期 和 代 碼 檢 查 完 成 日 期B U G 管 理 系 統 中 加入 代 碼 檢 查 的 結 果提 交 項 目 經 理提 交 a l f a 版 本確 定 A l f a / B e t e s m 中 登 錄 項 目 開 始 時 間e s m 登 錄 A l f a / B e t a 版 時 間項 目 中 出 現 新的 問 題項 目 啟 動 會 議 ，功 能 點 及 M D 概要 分 配發 送 測 試 組 D B s c r i p t 和 r e s o u r c e 修 改 文 件E s m 系 統 登 錄功 能 點 文 檔 名 稱 及 服 務 路 徑Q u e s t i o n S h e e t 文 檔 名 稱 及 路 徑E s m 系 統 登 錄 項 目 安 排文 檔 名 稱 及 路 徑書 寫 單 元 測 試用 例e s m 輸 入 單 元 測 試 用 例 文檔 的 名 稱 和 對 應 地 址把 單 元 測 試 的 結 果 反 映 到單 元 測 試 用 例 文 檔 中1 功 能 點 文 檔2 u e s t i o n S h e e 項 目 安 排 文 檔（ v i s i o 或 者 p r o j e c t ）要 遵 守 編 碼 規 則 和 類 結 構 方 案 ，注 意 討 論 ， 切 記 盲 目 編 碼制 作 單 元 測 試 文 檔 （ 參考 單 元 測 試 模 板 ）M a i l 通 知 測 試 部 經理 ， 項 目 總 控 助 理郵 件 通 知 項 目 總 控 助 理 、 測 試 組 負 責 人必 須 同 時 包 含 ： 項 目 開 始 時 間 ， a l f a 時間 ， 版 時 間M a i l 反 饋 給 文 檔 作 者 ， 并 通 知 部長 以 上 人 員 ， 按 照 反 饋 機 制 進 行項 目 經 理 郵 件 通 知測 試 部 經 理 ， 項 目總 控 助 理郵 件 通 知 項 目 總 控 助 理和 測 試 部 經 理項 目 總 結 會 議 ，功 能 點 及 M D 概要 分 配制 作 項 目 總 結 文 檔 ，以 及 M D 分 配 方 案E s m 系 統 登 錄 項 目 總 結文 檔 的 名 稱 及 路 徑 文檔 18 目組文檔管理 原則： 所有文檔必須都放在 ，進行統一管理。同時，負責人在本地應保留一份同樣的備份。 2004 年開始接 收到的項目必須放在 2004中，針對每個項目必須按照下圖進行文檔管理。 細節描述 項目 內容 備注 計說明書 計說明書的補充說明 設計說明書的各個版本 設計說明書一覽表 設計說明書一覽表要記錄所有文檔變更的情況，并指明最后項目實施與文檔之間的關系 目組書寫的單體測試用例 測試組書寫的測試用例 東京發送的 試用例 對項目實施的日程安排 對東京進行進度匯報的每個報表 能點文檔 障害書 針對此項目的 型確定和經驗匯總。完畢后，應及時發送測試組項目經理。 系分析組，如果有應該直接 P 同版本 FP 明，記錄所有 更歷史，以備后期確認的方便。 項目 中文版需要打印，此工作由項目總控助理執行。同時，對文檔 文檔 19 進行歸檔和密封。 試部版前流程 關人員 測試部經理： 測 試組成員： 試人員的要求 一定要注意配合。因為，在此環節，一種好的描述方式和溝通方式將會直接影響工作效率和工作質量。所以，首先大家要注意 理系統的使用方法和規則，同時，盡量采用統一的屬于進行描述，如果需要圖形輔助，也可以進行貼圖。 加強需求理解能力。能夠盡快的理解文檔和功能測試用例。 在工作中細致、耐心、有條理。 同時對應 統需要測試部填寫的過程參數必須嚴格按照規定填寫。 作流程圖 文檔 20 接 收 到 項 目 經 理 的A l f a / B e t a 版 通 知 并 參考 e s m 上 的 項 目 信 息項 目 測 試 安 排e s m 登 錄 測 試 負 責人接 到 項 目 組 提 交 的A f l a 版 通 知 后按 照 功 能 測 試 用例 ， 開 始 測 試確 認 連 接 在 測 試 數 據 庫 上確 認 已 經 執 行 D B s c r i t p t 和r e s o u r c e 修 改e s m 登 錄 第 一 階 段 測 試 開 始 時 間第 一 階 段 測 試結 束第 一 階 段 測 試 B U G 管 理 系 統 登 錄 A l f a 測 試 B U M 系 統 中 登 錄 第 一階 段 完 成 時 間e s m 中 登 錄 A l f a 版 本 后 的 b u g 數測 試 依 據 ： 測 試 組 所 整 理 的測 試 用 例回 歸 測 試測 試 完 畢 ， e s m 登 錄 回 歸 測試 結 束 時 間提 交 B e t a 版F T P 上 傳 D B s c r i p t 和 R e s o u r c e 修 改 到 東 京 服 務 器向 日 方 ： 中 山 幸 子 、 初 宏 偉 、 項 目負 責 人 ， 正 式 發 布 B e t a 通 知接 收 到 B e t a 后b u b e t a 版 后 流 程 規 約接 收 到 功 能 點文 檔書 寫 測 試 用 例e s m 登 錄 測 試 組 測 試 用 例 文件 名 稱 及 路 徑核 查 以 下 條 件 ：1 是 否 已 經 發 送 測 試 組 D B s c r i p t 和 R e s o u r c e 改 動 ， 并 驗 證 正 確 性2 單 體 測 試 用 例 是 否 全 部 填 入 單體 測 試 結 果M A I L 通 知 項 目 負 責人 ， 同 時 確 認 b u g 管 理系 統 中 a l f a b u g 的 類 型 和個 數D B s c r i p t 和 R e s o u r c e 修 改 放在 f i l e s e r v e r 對 應 項 目 目 錄 下條 件 不 具 備 ， 不 能 進 行測 試 ， 同 時 發 通 知 給 對應 負 責 意事項 理系統中的狀態一定要維護，并 通過此系統來保證 改的進行情況，即在提交 前，所有的 狀態都應該在 。如果沒有在此狀態中，應該積極和項目組聯系，測試組有權監督其完成。 測試組要驗證項目組提交的 件，如果有問題，測試組 文檔 21 有權通知項目立即修改，同時可以作為 錄在 理系統中。 測試組要保證測試用例的質量，盡一切可能減少 數量。并嚴格的按照 理規約進行。 4 績效考核實施方案 則： 所有職員的所有工作都應該以量化計算， 如果不能，則當事者可以提出異議，而對績效考核方法進行改進。 例如所有北京項目必須有 譯組翻譯工作量可以通過翻譯的字數進行調整，測試組同樣對工作內容進行分類核算 量化管理主要包含幾個主題方向： 工作時間： 是人事部門公布的每個月的工時統計的結果。實際上，它代表了自己的實際消耗時間。 東京 是實際為公司所創造的價值。 北京 主要包含正規作的北京內部項目或者實際工作而作的的補充 達到考核的公平合理。 質量扣除 指由于代碼的 造成的損失，因為實際的貢獻是要扣除損失的。對于測 試部就是東京對北京確認產生的 故障的扣除。 過程管理扣除 了實際的工作量，就是為個建立一個穩固高效的團隊而每個人應該承擔的過程管理義務，如果沒有做好，實際上不僅僅是你自己績效不高，而是你影響了整個團隊的利益。而這部分的值反映了你對團隊的影響。 過程管理獎勵 項目實施過程中，個人在突發事件上的處理或者對項目整體乃至公司的利益上作出突出貢獻，可以作為績效獎勵。 在整個分類上，基本上是劃分為管理者，程序員，分析員，翻譯人員，測試人員幾個子系統。但是所有系統的價值標準統一。 在時間上，每個 月的第五個工作日公布績效考核結果。 績效考核的結果直接反映在近期和長期的激勵系統中。具體內容可以參見 程圖 翻譯組 算流程 文檔 22 翻 譯 組 安 排記 錄 算 有 翻 譯的 字 數月 度 績 效 考 核年 度 按 照 8 5 0 0字 / M D 進 行 核算 測試組 算流程 測 試 組 接 收 功能 點 文 檔 通 知書 寫 測 試 用 例按 照 M D 1 0 測 試 實 施按 照 M D 1 0 A l f a 通 知 驗 證 測 試 用 例 提 交 b e t a 版接 到 東 京 通 知后 ， 填 寫 b e t a 后b u g 歸 總 表月 度 績 效 報 表 ， 根據 b e t a 后 b u g 進 行 質量 扣 除 計 算項目組 算流程 接 收 t o k y o 的o r d e F P 確 認 方案 ， 和 對 方 擔當 者 進 行 協 商參 看 s c h e d u l e 文檔 和 功 能 點 文檔 進 行 M D 的 初期 分 配分 配 原 則 ：1 。 項 目 組 可 以 支 配 的 額 度 為 9 0 （ 扣 除 測 試 部 的 1 0 ）2 剩 余 9 0 的 分 配 額 如 下 ：項 目 分 析 控 制 ： 1 0 機 動 M D ： 1 0 項 目 實 施 及 單 體 測 試 ： 7 0 項 目 總 結 會 議 上 ， 對 初 期 計 劃 不 合 理的 地 方 進 行 調 整 。程 序 員 最 后 確 定 的M D 登 陸 e s 經 理 整 理M D 分 配 表 存 檔項 目 總 結 會 議上 ， 對 1 0 的 機動 M D 進 行 分 配 ，鼓 勵項 目 經 理 確認分析組 算流程 文檔 23 分 析 組項 目 分 析 開 發規 約 進 行 核 算M 有 異 議 ， 書 面提 交 說 明 給 馬 俊馬 俊 和 項 目 總 控 人 員 進 行協 商 ， 確 定 后 回 復 擔 當 者北 京 自 我 研 發 項 目也 按 照 日 本 發 包 要求 進 行事項 內容 注意 負責人 備注 測試組績效 主要根 據測試的工作量和工作結果來進行 度量 強調質量，會加大質量影響的力度。 測試部經理 要按項目進行分配， 多退少補 。 測試組質量考核 主要是根據 果出現 時被確認為實施應測試人員應該承擔質量責任，按一個實施 除 算 要注意參看 測試組最關鍵的問題是根據后的 況做分析總結，可向公司申請 析內部文檔，通過后可按北京項目補充 試組工作量百分比 目前是測試工作本身項目 10 測試用例的書寫是項目10 目前的測試用例由 于 是初 步 書寫。所以僅限于第一月 項目總控人員 第一月后根據測試用例書寫的實際工時和狀況重新審核此百分比 項目分析工作量 項目分析指拿到 文檔后，進行的需求詳細分析，提出問題， 完畢檔和功能電文檔 原則上項目經理直接進行，同時也可以委托組內具有分析能力的程序員進行，但是必須是項目經理負責制 項目經理 配時誰分析誰拿走對應的 10的 目組質量考核 嚴格按照 后的行，一個 理系統中，項目經理要維護此系統的目，程序員要負責其中的目。如果不填寫直接作為過程管理扣除 試部經理 項目經理 過程管理扣除 項目總控助理負責審核測試部經理的工作，如果出現紕漏，按過程管理扣除 算，目組單體測試用例工作量核算 單體測試用例的條數必須大于 2，核算項目經理直接指定 此工作包含在實施 70的范圍內。 項目經理 項目經理和全體 全體 含自身在 所以項目經理要 項目經理 由項目總控助理進行監 文檔 24 管理者自身績效評定 內）的平均值 提高整個團隊的績效為目標 控。出現問題按過失進行處理。 年底績效評定標準 直接