【正文】 分析能力? 在功能實現(xiàn)上，主要和項目經(jīng)理的溝通，把類結(jié)構(gòu)設(shè)計和代碼向理想情況努力，同時用公司內(nèi)的代碼規(guī)范作為自己的行動準(zhǔn)則? 在日?；顒又?，加強(qiáng)團(tuán)體意識，加強(qiáng)責(zé)任感。 項目分析工作流 參見《項目分析工作規(guī)約》 Beta后質(zhì)量保證工作流 參見《beta 后規(guī)作規(guī)約》 測試組 beta前工作流 項目組基本工作流15 / 26在項目進(jìn)行過程中，要求能夠及時反饋。分部管理問題 無 開發(fā)部經(jīng)理項目經(jīng)理 項目分析和問題確認(rèn) 無 東京負(fù)責(zé)人 結(jié)果物概要需求文檔和問題與回復(fù)整理文檔項目里程碑信息反饋項目開始時間，alfa,beta版本時間和原因，fp 變更及原因無 項目總控人員項目總控助理測試部經(jīng)理組織團(tuán)隊進(jìn)行技術(shù)文檔的書寫和維護(hù)無 測試部經(jīng)理team所有成員文檔列表如下：功能點文檔questionSheetSchedule單體測試用例BugSurvey負(fù)責(zé)人Bugsurvey的調(diào)查修改merge項目總控人員 各級的 bug survey leaderBug survey實施人員 所有的規(guī)則按照bugsurve流程的規(guī)定。 S p e c Q u e s t i o n S h e e t2 . 常規(guī) 信息傳遞基本設(shè)計書H e a r i n g S h e e t詳細(xì)設(shè)計書實現(xiàn)M e r g e測試北京東京1 功能點描述文檔其中反饋機(jī)制的建立最關(guān)鍵。做到各司其職，多勞多得，公平評價，提供機(jī)會給相應(yīng)的人。項目總結(jié)會議和 MD分配方案的確定。? beta后障害 list表，其中包含 bug的簡單描述、bug 的類型確定和各部門關(guān)于bug的總結(jié)。所有的文檔主要包含如下幾種：? HearingSheet：一個簡要的需求，重點在于強(qiáng)調(diào)這個需求的原因（前因后果）? UI文件? 設(shè)計文檔： 東京和北京共同進(jìn)行? FP報價書? QuestionSheet：所有的問題一定要集中在一個文檔內(nèi)? 功能點文檔：一定要融合 questionSheet內(nèi)對應(yīng)答案的所有內(nèi)容? schedule文檔：要包含甘特圖? 項目總結(jié)及 MD分配方案：把項目總結(jié)作為重點進(jìn)行。Fileserver 文檔：通過文檔管理和整理，保證全部職員能夠隨時的了解其他項目的信息和相信內(nèi)容。Bug管理系統(tǒng)：作為質(zhì)量控制過程實際結(jié)果的監(jiān)控。? 項目經(jīng)理可以看自己負(fù)責(zé)項目的基本參數(shù)。? 管理人員去合適目前我們正在進(jìn)行的總量有多少，檢收而為付款的有多少，實施完畢而沒有檢收的有多少。同時，在個人的發(fā)展意向中可以兼顧其它公司內(nèi)的常務(wù)工作。翻譯人員：負(fù)責(zé)中日方文檔的翻譯，要求工作嚴(yán)謹(jǐn)，保證質(zhì)量。程序員：主要是負(fù)責(zé)項目按照分析文檔的實施，同時，在實施過程中優(yōu)化代碼結(jié)構(gòu)，提出合理化建議，其中優(yōu)秀者可以作為 TeamLeader負(fù)責(zé)具體組織工作和分析管理工作。臨時項目經(jīng)理：(DM22)此角色主要是在接受日方外包項目或整體公司產(chǎn)品設(shè)計中，需要臨時成立項目組，而從分析組中或者常務(wù)項目經(jīng)理中抽調(diào)。技術(shù)分析員：(DM21)對日方的需求進(jìn)行概要分析和設(shè)計，并書寫設(shè)計書，F(xiàn)P。常務(wù)項目經(jīng)理：(DM20) 目前 11名各分部內(nèi)程序員的日常管理，整個開發(fā)過程中的控制和日方負(fù)責(zé)人的信息交互，負(fù)責(zé)組內(nèi)程序員的績效考核和問題解決。項目總控助理：(DM13)輔助開發(fā)部的項目管理工作，主要負(fù)責(zé)中日雙方的信息的反饋紀(jì)錄整理，以及 esm和taskschedule信息的維護(hù)工作。在目前的情況下，以靈活為主，臨時性的進(jìn)行 bugSurvey組的組織和 bugSurvey組內(nèi)team leader的指定和管理。BUG Survey總負(fù)責(zé)人(DM12)： 統(tǒng)一管理 package和已經(jīng)提交項目的統(tǒng)籌管理。技術(shù)設(shè)計負(fù)責(zé)人：(DM11) 統(tǒng)一協(xié)調(diào)分析組的工作，在對日項目分析組中，進(jìn)行設(shè)計文檔的統(tǒng)一確認(rèn)，在對中方項目中，承擔(dān)需求的統(tǒng)一把關(guān)處理。做好所有公司要求的標(biāo)準(zhǔn)流程內(nèi)的內(nèi)容。同時，在項目分配上保證三個分部間項目的均衡（一個季度內(nèi)）開發(fā)部部長：(DM10) 在公司統(tǒng)一的規(guī)則范圍內(nèi)，負(fù)責(zé)分部的建設(shè)。進(jìn)行開發(fā)部的整體計劃的制定和實施，保證開發(fā)部的可持續(xù)發(fā)展和利潤率。同時，在技術(shù)討論上，希望能夠把知識點做一個累計，以便新員工能夠進(jìn)行參考和積極發(fā)表意見。2022年 2月啟動，沒有按照規(guī)定進(jìn)行會議，經(jīng)審核后，扣除項目經(jīng)理過程管理 ,忘記登錄的按照統(tǒng)一標(biāo)準(zhǔn)處理。（2） 會議室、洽談室、經(jīng)理室的使用管理目的：主要是在人數(shù)多而會議室相對緊張的狀態(tài)下，解決矛盾的一種方法。第一階段測試開始時間： 必填 測試人員 扣除 MD 第一階段測試完成日期： 必填 測試人員 扣除 MD Alfa版本后的BUG： 必填 測試人員 扣除 MD 回歸測試的開始日期： 必填 測試人員 扣除 MD 回歸測試的結(jié)束日期： 必填 測試人員 扣除 MD Beta版后的 BUG數(shù)：必填 扣除 MD 主要要參考 beta后 bug的整理表確認(rèn)負(fù)責(zé)人 不是必須，主要是與是否進(jìn)行確認(rèn)有關(guān)，如果確認(rèn)其他有信息，確認(rèn)負(fù)責(zé)人必填 扣除 MD （1） 電子打卡系統(tǒng)的使用目的：主要是利用電子打卡，提高效率，能夠及時反映請假和遲到，并且所有的數(shù)據(jù)能夠直接被人事利用。單體測試用例文件名稱及文件路徑必填 項目經(jīng)理 扣除 MD 此文檔為必須文檔，各項目經(jīng)理必須嚴(yán)格控制項目總結(jié)與 MD分配方案文檔及文件路徑必填 項目經(jīng)理 扣除 MD 此文檔為必須文檔，各項目經(jīng)理必須嚴(yán)格控制。同時必須和 MD變更紀(jì)錄一致Schedule文檔名稱及路徑必填 項目經(jīng)理 扣除 MD 可以用 excel或者是 visio，project后兩種要以 HTML輸出以便查閱。項目經(jīng)理（Mail通知）扣除 MD 本 MD伴隨著 MD的變更需要動態(tài)變化Md變更附件名稱 不是必須，但是只要有變更有內(nèi)容，此項目必須要有項目經(jīng)理（Mail通知）扣除 MD 項目最終報價 原則不為空，在特殊情況下為空，在項目備注重必須說明原因。注意事項：? 其中關(guān)于項目中所設(shè)計的文檔，統(tǒng)一放在 fileserver上 2022目錄中。為以后項目的整理和后期處理提供真實的數(shù)據(jù)。（5） 項目信息管理的使用。為每一個程序員根據(jù)個人不同的能力和狀況設(shè)定目標(biāo)，對于圓滿完成目標(biāo)者進(jìn)行鼓勵。在概念上，日報周報為概括說明，而 report則屬于細(xì)節(jié)描述。輸入值為實際值的 10倍（因為數(shù)值型目前只能為整數(shù)）職員的輸入由項目經(jīng)理負(fù)責(zé)項目經(jīng)理的核對由項目總控助理進(jìn)行職員如果不填寫則按照輸入值進(jìn)行績效考核。必須包含內(nèi)容和狀態(tài)兩部分例如：1 內(nèi)容： BS詳細(xì)頁面存在老bug，狀態(tài)：已經(jīng)解決2 內(nèi)容：文檔 ，無法繼續(xù)。見附圖 1 扣除 MD 當(dāng)日工作內(nèi)容和進(jìn)度工作內(nèi)容與進(jìn)度1． 填寫當(dāng)日的模塊名稱（模塊名稱參考2． 中的功能點表）3． 細(xì)度要求功能點填寫監(jiān)督：內(nèi)容監(jiān)督：項目經(jīng)理沒有填寫 1次人民幣 5元工作耗時工作耗時 要求與工資計算工時想對應(yīng)。同時項目總控助理，也要本著實事求是的原則，根據(jù)大家的填寫內(nèi)容向東京證券市場提交《作業(yè)公務(wù)表》 ，所有填寫者一定要保證填寫日報的消耗工時和最后工資結(jié)算時當(dāng)日工時保持嚴(yán)格一致。東京項目負(fù)責(zé)人（2） Report的使用作為上市公司的子公司要求公司正規(guī)化，第一步公司的日報系統(tǒng)的建立和5 / 26審查，所以從本年度起必須建立此系統(tǒng)。無制作下周工作安排表項目總控助理負(fù)責(zé)利用工具【導(dǎo)出下周工作表系統(tǒng)】制作開發(fā)部下周工作計劃表。無待辦事項開發(fā)部全體人員建議填寫，管理者應(yīng)該必須使用。填寫監(jiān)督：項目總控助理內(nèi)容監(jiān)督：部長和項目總控人員沒有按時提交的，管理者扣除 MD 日常活動安排開發(fā)部全體人員建議大家把工作安排填寫，有利于提高自己的計劃能力和規(guī)劃能力。內(nèi)容 負(fù)責(zé)人 填寫要求 監(jiān)督人 違規(guī)處理下周工作安排項目經(jīng)理技術(shù)分析負(fù)責(zé)人測試組經(jīng)理必須每周五 16：00 前填寫完畢。注意事項：1. 必須使用長期類型（哪怕只有一天）保持統(tǒng)一性2 開始時間必須為 22：00 結(jié)束時間為 23：00， （為了區(qū)分其它人填寫的日程安排）3 填寫日程安排時，必須選擇對應(yīng)的 anken，否則不能于系統(tǒng)內(nèi)的項目關(guān)聯(lián)，統(tǒng)計4 / 26軟件失去作用。同時提高整體職員參與公司管理的渠道，適應(yīng)東京上市公司對信息管理的要求。但是，這需要每個人按照規(guī)則把自己應(yīng)該負(fù)責(zé)的那一部分高效完成，只有這樣才能保證整個系統(tǒng)的順暢，同時，如果個人沒有完成自己的指責(zé)和按照規(guī)定填寫內(nèi)容，影響的不單單是自己的工作而是整個系統(tǒng)。 內(nèi)容概述? 開發(fā)部日常工