【正文】 。26 / 26? “避免過失的方法“，由評審組統(tǒng)一討論填寫，這是整個過失管理的主題。從大處著眼，以認識問題為主，這也是公司處理的根本，而非處罰某人。同時，在處理意見上要寫清楚。凡是有意庇護或回避意見，可以取消評審組資格，同時考慮其過失行為。原則為相關事件的相關人員，責任人的直接上司。25 / 26過 失 管 理 流 程 評 審 組 本 人管 理 者根 據(jù) 客 戶 反 饋 或 工 作效 益 ， 就 具 體 責 任 人提 出 過 失 處 理 提 議 通 知 責 任 當 事 人 ， 準備 資 料 和 申 辯 材 料組 織 評 審 組 ， 至 少3人 ， 確 定 3個 代 表 接 收 到 評 審 組 通 知 后準 備 資 料過 失 評 審 ， 表 決通 過填 寫 過 失 單是過 失 單 發(fā) 送 人 事 部抄 送 管 理 者 和 績 效考 核 人 員績 效 管 理 上 處 理總 結(jié) 自 己 的 行 為 是否 有 連 帶 責 任否總 結(jié) 提 出 提 議 的時 機 和 方 式 方 法 ，向 當 事 人 道 歉 解 釋 否解 釋 相 關 內(nèi) 容 和 過程提 出 調(diào) 查：? 首先過失和特別獎勵的數(shù)目在總體上要把握，原則上不能超過月度 3事件（一個事件可能牽涉多個責任人） ，同時，要把握時機，基本上要在事件后 34天處理，保證其情緒化和調(diào)查不詳細的影響。降薪 過失影響很巨大，同時，過失人沒有改正的傾向。在數(shù)額分50/100/150/200，共 4個等級。罰金 根據(jù)影響度和后果，進行度量。適用范圍為固定 MD的項目和業(yè)務過失或項目管理過失。重點強調(diào)避免辦法Md的補充處理 根據(jù)影響的程度和過失的程度來確定。公司全體員工對應此項，要加強審核制度，避免主觀化：過失處理可以采取并罰制度。如果，在指定職責范圍內(nèi)，出現(xiàn)重大失誤。如果此問題是由于工作態(tài)度或缺乏責任心引起的，加大處理力度。公司全體職員技術實現(xiàn)過失 由于在具體實現(xiàn)上，出現(xiàn)失誤，造成損失或嚴重影響。管理者和中層管理層既是直接責任人為某個人，也要主體負責違反公司規(guī)章過失沒有遵守公司的規(guī)章制度，經(jīng)規(guī)勸后無效果的。管理者和中層管理層24 / 26運作管理過失 沒有貫徹成文或討論會議上的決議，在運作上自己決定，在結(jié)果上造成損失或嚴重影響。年終獎金分配表全體員工 過失管理系統(tǒng)：過失泛指由于本人的失誤和錯誤，對公司的利益或潛在利益造成比較大的影響和比較大的損失的行為，稱作過失。以給有技術或管理能力的人充分的空間。針對公司的要求和個人情況，提議確定人選和額度。內(nèi)容是骨干人員，突出貢獻者和分部內(nèi)的個別活動?？捎晒芾碚咧苯犹嶙h，部長會議進行討論決定。可由部長提出申請，項目總控人員進行批示。旨在體現(xiàn)公司公平的原則，客觀的對個人的能力和價值進行認可。出現(xiàn)問題按過失進行處理。項目總控助理負責審核測試部經(jīng)理的工作，如果出現(xiàn)紕漏，按過程管理扣除 MD計算，一次項目組單體測試用例工作量核算單體測試用例的條數(shù)必須大于 MD2，核算項目經(jīng)理直接指定此工作包含在實施 70％的范圍內(nèi)。如果不填寫直接作為過程管理扣除 MD進行，一次 測試部經(jīng)理項目經(jīng)理Alfa版質(zhì)量扣除 MD的匯總表測試部經(jīng)理負責。測試組最關鍵的問題是根據(jù) β 后的 bug情況做分析總結(jié)，可向公司申請 bug分析內(nèi)部文檔，通過后可按北京項目補充 MD測試組工作量百分比目前是測試工作本身項目 MD10％測試用例的書寫是項目MD10％目前的測試用例由于是初步書寫。22 / 26的度量 度。 項目組可以支配的額度為 9 0％（ 扣除測試部的 1 0 ％）2 剩余 9 0 ％ 的分配額如下 ： 項目分析控制 ： 1 0 ％ 機動 M D ： 1 0 ％ 項目實施及單體測試 ： 7 0 ％項目總結(jié)會議上 ， 對初期計劃不合理的地方進行調(diào)整 。? 績效考核的結(jié)果直接反映在近期和長期的激勵系統(tǒng)中。但是所有系統(tǒng)的價值標準統(tǒng)一。過程管理獎勵 MD：在項目實施過程中，個人在突發(fā)事件上的處理或者對項目整體乃至公司的利益上作出突出貢獻，可以作為績效獎勵。過程管理扣除 MD：除了實際的工作量，就是為個建立一個穩(wěn)固高效的團隊而每個人應該承擔的過程管理義務，如果沒有做好，實際上不僅僅是你自己績效不高，而是你影響了整個團隊的利益。質(zhì)量扣除 MD:是指由于代碼的 bug而造成的損失，因為實際的貢獻是要扣除損失的。北京 MD：主要包含正規(guī)作的北京內(nèi)部項目或者實際工作而作的的補充 MD。實際上，它代表了自己的實際消耗時間。例如所有北京項目必須有 MD，翻譯組翻譯工作量可以通過翻譯的字數(shù)進行調(diào)整，測試組同樣對工作內(nèi)容進行分類核算 MD。并嚴格的按照 beta 后 bug 處理規(guī)約進行。? 測試組要驗證項目組提交的 script 和 resoruce 文件，如果有問題，測試組有權通知項目立即修改，同時可以作為 alfa bug 登錄在 bug 管理系統(tǒng)中。19 / 26接收到項目經(jīng)理的A l f a / B e t a 版通知并參考 e s m 上的項目信息項目測試安排e s m 登錄測試負責人接到項目組提交的A f l a 版通知后按照功能測試用例 ， 開始測試確認連接在測試數(shù)據(jù)庫上確認已經(jīng)執(zhí)行 D B s c r i t p t 和r e s o u r c e 修改e s m 登錄第一階段測試開始時間第一階段測試結(jié)束第一階段測試 B U G 管理系統(tǒng)登錄 A l f a 測試 B U GE S M 系統(tǒng)中登錄第一階段完成時間e s m 中登錄 A l f a 版本后的 b u g 數(shù)測試依據(jù) ： 測試組所整理的測試用例回歸測試測試完畢 ， e s m 登錄回歸測試結(jié)束時間提交 B e t a 版F T P 上傳 D B s c r i p t 和 R e s o u r c e 修改到東京服務器向日方 ： 中山幸子 、 初宏偉 、 項目負責人 ， 正式發(fā)布 B e t a 通知接收到 B e t a 后b u g啟動 b e t a 版后流程規(guī)約接收到功能點文檔書寫測試用例e s m 登錄測試組測試用例文件名稱及路徑核查以下條件 ：1 是否已經(jīng)發(fā)送測試組 D B s c r i p t 和 R e s o u r c e 改動 ， 并驗證正確性2 單體測試用例是否全部填入單體測試結(jié)果M A I L 通知項目負責人 ， 同時確認 b u g 管理系統(tǒng)中 a l f a b u g 的類型和個數(shù)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 對應項目目錄下條件不具備 ， 不能進行測試 ， 同時發(fā)通知給對應負責人? Bug 管理系統(tǒng)中的狀態(tài)一定要維護，并通過此系統(tǒng)來保證 alfa bug 修改的進行情況，即在提交 beta 版前，所有的 alfa bug 的狀態(tài)都應該在 DO 上。? 在工作中細致、耐心、有條理。? 加強需求理解能力。因為，在此環(huán)節(jié)，一種好的描述方式和溝通方式將會直接影響工作效率和工作質(zhì)量。同時，對文檔進行歸檔和密封。UI Html DemoHearing Sheet聯(lián)系分析組，如果有應該直接 copyFP Spec FP sheet 不同版本FP change 表FP 說明，記錄所有 FP變更歷史，以備后期確認的方便。? 細節(jié)描述項目 內(nèi)容 備注Spec 設計說明書QuestionSheet設計說明書的補充說明設計說明書的各個版本設計說明書一覽表設計說明書一覽表要記錄所有文檔變更的情況，并指明最后項目實施與文檔之間的關系Test case 項目組書寫的單體測試用例測試組書寫的測試用例東京發(fā)送的 confirm測試用例Schedule 針對項目實施的日程安排對東京進行進度匯報的每個報表Function Points功能點文檔All Bug Spec Beta后障害書針對此項目的 beta后 bug類型確定和經(jīng)驗匯總。同時，負責人在本地應保留一份同樣的備份。以備在公司級別對整個流程和各個環(huán)節(jié)進行調(diào)整。? 整個團隊的建設和公司的管理工作。同時根據(jù)評論的結(jié)果進行最后的 MD的分配。硬性要求如下：（1） 每個項目（大于 10MD正常項目）必須提供的文檔為功能點文檔，questionSheet，單體測試用例，項目總結(jié)及 MD最終分配方案文檔（2） 每個項目（大于 10MD正常項目）必須召開兩次會議：項目啟動會議主要為了統(tǒng)一項目的內(nèi)容規(guī)則和要求，同時把整體邏輯和框架做簡要說明。保證整個軟件包的可維護性? 項目過程管理。? 尤其在分析組成立前期，對分析組的設計書，盡可能提出建設性意見和設計的問題，有利于提高項目