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