软件项目策划实施流程

1、某软件项目开发流程修改历史日期作者修改内容003-03-12张京宇新規制作003-5-18张京宇人员职责的变更,内容的变更2003-1-张京宇针对204年度制作最新工作内容下的工作流程2004-1张京宇添加项目经理治理被职员填写下周日程表的规则 TOC12 z HYPERLINK N:整理后1概述 AGERE _To8029 h3HYPERLINK N:整理后1.1目的 PGEEF_Toc6002950 h HYPERLINK N:整理后1.内容概述 AGEEF_Toc608095 h HYPERLIN l _oc68022 2开发部日常治理流程具体实施方案 PAGEREF _oc608025

2、2h 3 HYPRLINK l _To080953 2差不多原则 PERF _Tc080953 h HYPERLINK N:整理后l内容概述 PAGEREF _oc608254 YERLINKl To6802955 23内容详细描述AGEREF _To00295 3HYPERLINK N:整理后l3开发部治理流程具体实施方案 AGERF_Toc608295 h 0 HYPERLINK l _Toc60802957 3内容概述 PAGER _c60802957 h10HYPERLINK N:整理后.2开发部概要流程图 PAGREF_To600295h 1 HPERLI l _o6002959 .

3、3开发部治理人职员作流PAEEF To602959 1HYPRLNK l _00260 3.4Buvy工作流 PAGEREF _oc00260h5HYPERLINK N:整理后l3.5项目分析工作流PAGREF _oc608091h 15HYPERLINK N:整理后36Bet后质量保证工作流PAGEF _Tc68296 h 15HYERLINK l_Toc6080963 37测试组bta前工作流PAGEREF _To60802963 h 15HYPERLINK N:整理后3.8项目组差不多工作流 PAGEREF _oc600296 h5 HPERLINKl oc6080265 39测试部版前

4、流程 PAGEEF _Toc602965 h 1 HYPLINKlToc00296绩效考核实施方案 PAGERF _Tc608296 h21 YPERLIN l _oc606 41总则：PAGREF _Toc8097 2HYPERLINK N:整理后l4.2流程图 PAGEREToc608096 h 21 HYPELINKlToc60269 5开发部激励和过失治理流程 PAGERF _o608269 h 24HYPERLINK N:整理后l5.激励治理系统 PAERE _Toc60870 h24HYPERLINK N:整理后l5.2过失治理系统 AGEREF _Toc600971 24概述目的

5、用标准化的流程来统一治理公司的运作，幸免混乱，提高治理的质量。在远程开发上,结果软件自身的特点,量身定做,解决远程开发上的问题。在实施过程中，所有治理者能够依照此统一的流程,总结经验，提高认识，加强技术水平和治理水平。提高公司级的技术分析能力,为公司储备一支分析队伍，侧重在需求理解和需求分析、框架设计上的能力。保证在04年能够全盘进行中方市场的顺利运作。对人员负责内容上,明确化各自负责的内容，提高工作效率。内容概述开发部日常工作流程开发部治理流程开发部绩效考核流程开发部激励和过失治理流程开发部日常治理流程具体实施方案差不多原则公司开发部力求建立公平公正的评价体系,严谨的工作流程定义和及时的记录

6、与反馈，规范职员活动，形成一个紧张有序的团队。没有一个明晰的流程和高效的反馈体系，就不可能把工作做好。然而,这需要每个人按照规则把自己应该负责的那一部分高效完成,只有如此才能保证整个系统的顺畅，同时，假如个人没有完成自己的指责和按照规定填写内容,阻碍的不单单是自己的工作而是整个系统。内容概述Em使用规则目的注意是为了提高开发部整体的打算能力，反馈能力和治理者的操纵能力。同时提高整体职员参与公司治理的渠道，适应东京上市公司对信息治理的要求。日常活动的方法提供开发部工作流程外的突发事件的解决方法内容详细描述Em使用规则chde的使用加强全体人员的打算能力，做到我每天要做什么？今天项目经理给我的安排

7、是什么?对应项目经理和部长要明白每个人在做什么?只有如此,才能保证操纵人员能够宏观调控，而个人也可不能不知所措。注意事项：1.必须使用长期类型(哪怕只有一天）保持统一性2 开始时刻必须为22：00 结束时刻为3：00, （为了区分其它人填写的日程安排)3 填写日程安排时,必须选择对应的ankn,否则不能于系统内的项目关联，统计软件失去作用。 日程安排的主题要修改，规则为项目号（中文版项目为北京内部项目编号），临时没有编号能够写项目名称。内容负责人填写要求监督人违规处理下周工作安排项目经理技术分析负责人测试组经理必须每周五1:00前填写完毕。同时类型统一用长期进行定义，为每一个人员安排下周工作打

8、算。填写监督:项目总控助理内容监督：部长和项目总控人员没有按时提交的,治理者扣除D 0.2日常活动安排开发部全体人员建议大伙儿把工作安排填写,有利于提高自己的打算能力和规划能力。同时能保证情况可不能不记得。无待办事项开发部全体人员建议填写，治理者应该必须使用。要紧是把事务治理的井井有条。无制作下周工作安排表项目总控助理负责利用工具【导出下周工作表系统】制作开发部下周工作打算表。每周五下班前发送东京。东京项目负责人Report的使用作为上市公司的子公司要求公司正规化,第一步公司的日报系统的建立和审查，因此从本年度起必须建立此系统。同时，在治理上解决口头汇报，不客观而事后而无据可查的弊端，为及时了

9、解问题并解决问题,提供第一手的素材。同时项目总控助理，也要本着实事求是的原则,依照大伙儿的填写内容向东京证券市场提交作业公务表，所有填写者一定要保证填写日报的消耗工时和最后工资结算时当日工时保持严格一致。内容对应m的名称填写要求监督人违规处理项目选择项目直接选择自己对应的项目,假如工作对象不是项目本身则需要选择以下项目:(顾客名称为200年过程治理专用）公司会议公司培训公司治理其它注意:只有部长以上才填写以上项目(公司培训除外),部长以下全部选择对应项目。见附图1扣除D 0.1当日工作内容和进度工作内容与进度填写当日的模块名称（模块名称参考中的功能点表）细度要求功能点填写监督:内容监督：项目经

10、理没有填写1次人民币5元工作耗时工作耗时要求与工资计算工时想对应。(m中数据库的数字和工时统计必须对应,此为东京证券的要求)数字核对:数字不对者，按照一次扣除0.MD问题反馈问题反馈把当天所遇到的问题按照条目化排列。必须包含内容和状态两部分例如:1内容：BS详细页面存在老bug，状态：差不多解决 内容：文档.3出现问题，无法接着。状态：等待解决内容监督:项目经理不付责任的乱填或不填，一个日报扣除1MD(假如在专门情况下无问题，也要写无)MD输入订货（预定)金额必须在项目总结会议结束之后，同时要通过项目经理的审核。输入值为实际值的倍(因为数值型目前只能为整数）职员的输入由项目经理负责项目经理的核

11、对由项目总控助理进行职员假如不填写则按照输入值进行绩效考核。假如职员输入的MD与分配时不符合项目经理扣除0.5MD附图：周报(WeeReort）日报（al ept)的使用要紧是使用对象为治理者,要紧是适用于向治理者汇报整体问题。在概念上，日报周报为概括讲明，而report则属于细节描述。内容负责人填写要求监督人违规处理日报项目经理部长部长项目进展状况：不能解决的问题反馈建议或提议突发问题必须反馈项目总控人员假如由于没有汇报造成问题，按一次扣除5D周报项目经理部长部长项目总控项目进展整体状况:不能解决的问题反馈建议或提议必须填写项目总控助理周报不写,按一次扣除02MD目标功能的使用由于分部内有单

12、独的激励费用,因此建议分部内建立目不考核体系。为每一个程序员依照个人不同的能力和状况设定目标,关于圆满完成目标者进行鼓舞。同时，保证公司的开发效果在可操纵范围内。项目信息治理的使用。本治理系统在年开始实行,要紧目前是记录公司所有项目的里程碑信息。为以后项目的整理和后期处理提供真实的数据。同时,维护公司的项目信息数据库。注意事项:其中关于项目中所设计的文档,统一放在fileervr上2004目录中。关于文档名称和路径的书写方法如下,保证能够尽快打开文档：/ileerve/projc/04/428/测试用例/4258tscase.xls00年1月号起,东京新项目项目要求对应负责人出错处理方法备注项

13、目名称必填,同时应有对应的项目号扣除M 0.1北京项目编号必填扣除D.1添加时一定要注意唯一性，与项目类型不能为空，目前类型有RsecNormlCofrmergethers扣除D .1目前的规则为小于5md的均为REARCH项目项目名称必填扣除MD 0项目的名称应包含项目的ID，关于项目D的生成方法,参考日方对应文档客户方负责人必填扣除M0.1分析负责人北京分析项目,为必填项目东京设计,为非必填部长(然而必须制定具体负责人）扣除MD .1项目负责人必填项目部长扣除MD.1项目负责人应该是直接负责人(不是最先指定的部长）本公司负责人不能为空初始必填的人员为项目总控人员及助理、对应部长、测试部经理

14、,公司技术负责人(马俊)项目负责人扣除MD 01假如没有项目负责人,与联系分析开始时刻必填对应该项目的分析员扣除MD0.1公司技术负责人在分析项目开始时应把对应分析员加到项目列表中概要设计完成时刻必填对应该项目的分析员扣除M 0.1详细设计完成时刻必填对应该项目的分析员扣除MD 0.1P文档完成时刻必填对应该项目的分析员扣除M 0分析完毕时刻必填对应该项目的分析员扣除D .项目接收时刻必填扣除MD 01项目最终对应MD原则不为空，在专门情况下为空，在项目备注重必须讲明缘故。项目经理（ail通知）扣除MD 0.1本MD伴随着MD的变更需要动态变化Md变更附件名称不是必须，然而只要有变更有内容，此

15、项目必须要有项目经理（ail通知）扣除D.1项目最终报价原则不为空，在专门情况下为空,在项目备注重必须讲明缘故。扣除MD .1必须与对应*11000差不多一致。同时必须和MD变更纪录一致Schedule文档名称及路径必填项目经理扣除M02能够用cel或者是vio,pojc后两种要以HTML输出以便查阅。客户方deadine要求假如提供必填扣除MD 0.1Alfa版时刻必填项目经理(ail通知)扣除D 0.1Bta版时刻必填项目经理（Mail通知)扣除MD 0.1Alfa变更纪录最后一次记录变更的时刻必须和对应的ala版时刻和beta版时刻一致项目经理(Mai通知）扣除MD0.1项目开始时刻必填

16、项目经理（Mil通知）扣除MD 0.1CV分支号必填项目经理扣除MD 0.1此分支号为开发分支号功能点文档文件名及文件路径（FilServr 服务器）必填项目经理扣除MD0.1此文档为必须文档,各项目经理必须严格操纵。单体测试用例文件名称及文件路径必填项目经理扣除MD0.1此文档为必须文档,各项目经理必须严格操纵项目总结与M分配方案文档及文件路径必填项目经理扣除MD 0此文档为必须文档,各项目经理必须严格操纵。测试负责人必填扣除MD 0.1测试用例对应文件名称及路径必填扣除MD0.1此文档为必须文档，各项目经理必须严格操纵。第一时期测试开始时刻: 必填测试人员扣除MD .1第一时期测试完成日期

17、: 必填测试人员扣除MD .lfa版本后的BU：必填测试人员扣除MD .1回归测试的开始日期： 必填测试人员扣除M .1回归测试的结束日期: 必填测试人员扣除MD .1Bet版后的BUG数:必填扣除M 01要紧要参考bet后的整理表确认负责人不是必须，要紧是与是否进行确认有关，假如确认其他有信息，确认负责人必填扣除MD 0.系统的使用电子打卡系统的使用目的：要紧是利用电子打卡，提高效率,能够及时反映请假和迟到，同时所有的数据能够直接被人事利用。要求：2004年2月开始启用,2月为试用期，然而要求每人必须严格填写,假如不填写并结合打卡,不记得填写扣除过程治理M 0计算。会议室、洽谈室、经理室的使

18、用治理目的：要紧是在人数多而会议室相对紧张的状态下，解决矛盾的一种方法。同时审核各项目组是否及时安排公司规定的两次会议。004年月启动,没有按照规定进行会议，经审核后,扣除项目经理过程治理M02,不记得登录的按照统一标准处理。公司内部论坛的使用要紧是要有利于公司内部开发一块公司能够自由发表言论的地点。同时，在技术讨论上,希望能够把知识点做一个累计,以便新职员能够进行参考和积极发表意见。开发部治理流程具体实施方案内容概述开发部从流程上要紧分为以下几方面：开发部治理人职员作流BUG urvey 工作流项目分析工作流Beta后质量保证工作流测试组ba前工作流项目组运行差不多工作流开发部从实施人员角色

19、划分如下：开发部经理:（DM01)统筹解决公司开发部的全部事宜。进行开发部的整体打算的制定和实施，保证开发部的可持续进展和利润率。项目总控人员:(DM0) 对公司级的资源进行调配,同时，直接了解日方的战略安排,为北京方的战略安排提供的第一手的资料。同时,在项目分配上保证三个分部间项目的均衡(一个季度内)开发部部长:(DM10) 在公司统一的规则范围内,负责分部的建设。协调各开发组的问题,处理解决分部内发生的问题。做好所有公司要求的标准流程内的内容。同时,在许可范围内,能够进行单独的治理方法的尝试和分部内激励的分配。技术设计负责人：(DM1)统一协调分析组的工作，在对日项目分析组中，进行设计文档

20、的统一确认，在对中方项目中,承担需求的统一把关处理。同时负责分析组的日常工作安排的统筹。UG Suve总负责人(DM1): 统一治理packag和差不多提交项目的统筹治理。组织形式上,倾向于单独的组织模式。在目前的情况下,以灵活为主，临时性的进行bugurvy组的组织和ugSuey组内team lader的指定和治理。在间隙时期，直接进入分析组进行项目分析工作。项目总控助理：（D1)辅助开发部的项目治理工作，要紧负责中日双方的信息的反馈纪录整理,以及es和kschedue信息的维护工作。负责公司级项目文档,过程参数的监督,同时向日本总部汇报各种参数和报表。常务项目经理：(DM) 目前11名各分

21、部内程序员的日常治理,整个开发过程中的操纵和日方负责人的信息交互，负责组内程序员的绩效考核和问题解决。测试部经理和翻译部经理包含在内。技术分析员:(DM21)对日方的需求进行概要分析和设计，并书写设计书，FP。对中方的项目中,负责需求的整理和各种设计文档的实施，同时，负责和项目经理和测试部经理的沟通。临时项目经理:(DM2）此角色要紧是在同意日方外包项目或整体公司产品设计中，需要临时成立项目组，而从分析组中或者常务项目经理中抽调。临时项目经理需要全权负责此项目的实施,同时需要和公司签订项目负责保证书，以保证项目的进行和最后单独项目激励的兑现。程序员：要紧是负责项目按照分析文档的实施,同时，在实

22、施过程中优化代码结构，提出合理化建议，其中优秀者能够作为TeamLder负责具体组织工作和分析治理工作。测试员:负责公司测试流程的具体实施，要求掌握测试的技术，提出合理化建议，并保证整个软件的可靠度。翻译人员:负责中日方文档的翻译,要求工作严谨，保证质量。在同日方交流中，负责接待和沟通。同时，在个人的进展意向中能够兼顾其它公司内的常务工作。开发部概要流程图开发部治理人职员作流软件开发治理体系构成参与人员：项目总控人员(项目总控助理）+部长+（技术设计负责人+ugSurvey负责人）+各级项目经理治理主线:（1）工具类askscheue表：要紧目的是增加远程开发的打算和规划性。治理人员去合适目前

23、我们正在进行的总量有多少，检收而为付款的有多少，实施完毕而没有检收的有多少。治理人员去看我们下周能够同意的项目有多少，以便在每周五能够制定下周的工作打算。项目经理能够看自己负责项目的差不多参数。sm系统: 通过esm系统详细的记录开发过程中的每个里程碑参数,保证在治理上能够提高治理细度,以便于及时发觉并改正问题和错误。Bu治理系统:作为质量操纵过程实际结果的监控。以便总结质量的问题,进行反馈。Filerver 文档：通过文档治理和整理，保证全部职员能够随时的了解其他项目的信息和相信内容。同时,统一化文档治理,为以后的进展提供素材。所有的文档要紧包含如下几种：Haringhet：一个简要的需求,

24、重点在于强调那个需求的缘故（前因后果)UI文件设计文档：东京和北京共同进行FP报价书QesionSheet:所有的问题一定要集中在一个文档内功能点文档：一定要融合uesinShe内对应答案的所有内容chele文档:要包含甘特图项目总结及MD分配方案：把项目总结作为重点进行。单体测试用例；条数最少为*2,按照模板进行测试组测试用例: 要保证最后的测试结果确认测试用例: 一般为东京发送bea版后障害书：项目确认者发送,按照同一格式进行书写和填写。bt后障害li表，其中包含bg的简单描述、bug的类型确定和各部门关于bu的总结。（2)过程治理类一个项目两次会议：项目启动会议和项目总结会议项目启动会议

25、要紧是讲述项目的功能点,并据具体问题,进行严格的定义，讲明本项目所必须遵守的专门规则，子功能间的前后顺序,统一的接口定义,和每个人在项目实施中应该注意的问题。项目总结会议和D分配方案的确定。要紧是依照项目实施的结果，进行集中的讨论和谐而公平的团队：公司其他方面的治理,确实是为了加强治理,提倡量化。做到各司其职，多劳多得,公平评价,提供机会给相应的人。治理示意图治理人员注意事项其中反馈机制的建立最关键。其中治理必须遵守以下规则：对象流程编号工作内容上流方下流方备注项目总控人员分配项目东京项目发包人员(纪秀玲）部长项目总控助理解决人力矛盾部长Bgurvey负责人技术设计负责人部长BSurvey负责

26、人技术设计负责人下流方人员负责把结果反馈给东京担当者开发部经理公司治理问题部长项目经理各级负责人职员全体职员一定要给问题提出者答复，成为制度后颁布部长分配项目项目总控人员项目总控助理对应分部项目经理项目总控助理Em项目负责人加入，修改负责人为此项目经理项目人力调节无项目总控人员假如出现空闲同时反馈。分部治理问题无开发部经理项目经理项目分析和问题确认无东京负责人结果物概要需求文档和问题与回复整理文档项目里程碑信息反馈项目开始时刻,afa,beta版本时刻和缘故,fp 变更及缘故无项目总控人员项目总控助理测试部经理组织团队进行技术文档的书写和维护无测试部经理team所有成员文档列表如下：功能点文档

27、qustohtShedul单体测试用例gSrvey负责人Bgsury的调查修改mg项目总控人员各级的bg srvelederBg surve实施人员 所有的规则按照buue流程的规定。项目总控助理监督esm的执行情况程序员项目经理部长项目总控监督过程治理参数部长项目经理项目总控整理所有项目文档项目经理项目总控对日汇报表系统数据项目总控绩效考核提供过程情况汇总系统数据项目总控月度过程治理处理表测试部经理组织书写测试用例项目经理(功能点文档)东京整理汇总bea版后bu分析表项目经理(提供的完整的后障害书)所有治理者其中的技术分析和治理分析及对东京的建议应由项目负责人进行填写操纵测试的结果Bgsur

28、工作流参见bugSvey工作规约。项目分析工作流 参见项目分析工作规约Bet后质量保证工作流 参见bta后规作规约测试组bea前工作流项目组差不多工作流概述在项目进行过程中，要求能够及时反馈。做好打算安排,并调整那个人力的配比，以达到最好的效果。对程序员的要求尤其在分析组成立前期，对分析组的设计书,尽可能提出建设性意见和设计的问题,有利于提高项目分析能力在功能实现上，要紧和项目经理的沟通，把类结构设计和代码向理想情况努力,同时用公司内的代码规范作为自己的行动准则在日常活动中，加强团体意识,加强责任感。对项目经理的要求要紧职责为：类设计的严格操纵。保证整个软件包的可维护性项目过程治理。能够紧密的

29、操纵整个项目的进程,发觉项目中的各种风险因素,尽早地把风险在项目中消除。硬性要求如下：每个项目(大于10MD正常项目）必须提供的文档为功能点文档，quesinShe,单体测试用例，项目总结及最终分配方案文档每个项目(大于0MD正常项目）必须召开两次会议：项目启动会议要紧为了统一项目的内容规则和要求，同时把整体逻辑和框架做简要讲明。项目总结会议:要紧是评价每个成员的表现和项目完整的状况和质量，总结失败的经验教训。同时依照评论的结果进行最后的D的分配。在esm必须登陆必要的过程参数，以便团队成员和公司的治理者能够及时的把我目前项目状态。整个团队的建设和公司的治理工作。在项目治理中发觉问题,把反映给

30、公司。以备在公司级不对整个流程和各个环节进行调整。流程图项目组文档治理原则:所有文档必须都放在filservr上，进行统一治理。同时，负责人在本地应保留一份同样的备份。04年开始接收到的项目必须放在2004中，针对每个项目必须按照下图进行文档治理。细节描述项目内容备注pec设计讲明书uestinSheet设计讲明书的补充讲明设计讲明书的各个版本设计讲明书一览表设计讲明书一览表要记录所有文档变更的情况,并指明最后项目实施与文档之间的关系Ts case项目组书写的单体测试用例测试组书写的测试用例东京发送的conrm测试用例Schedule针对项目实施的日程安排对东京进行进度汇报的每个报表Funci

31、nPoints功能点文档All BugSpeBeta后障害书针对此项目的ba后bug类型确定和经验汇总。完毕后,应及时发送测试组项目经理。Utml Doring het联系分析组，假如有应该直接coyF SpeF seet不同版本FPchne 表FP讲明，记录所有FP变更历史，以备后期确认的方便。项目ec的中文版需要打印,此工作由项目总控助理执行。同时，对文档进行归档和密封。测试部版前流程相关人员测试部经理：测试组成员: 测试人员的要求一定要注意配合。因为,在此环节，一种好的描述方式和沟通方式将会直接阻碍工作效率和工作质量。因此，首先大伙儿要注意bug 治理系统的使用方法和规则，同时,尽量采纳

32、统一的属于进行描述,假如需要图形辅助，也能够进行贴图。加强需求理解能力。能够尽快的理解文档和功能测试用例。在工作中细致、耐心、有条理。同时对应e系统需要测试部填写的过程参数必须严格按照规定填写。工作流程图注意事项Bug治理系统中的状态一定要维护,并通过此系统来保证ala bg修改的进行情况,即在提交bea版前，所有的la ug的状态都应该在DO上。假如没有在此状态中,应该积极和项目组联系,测试组有权监督其完成。测试组要验证项目组提交的sript和resorce文件,假如有问题，测试组有权通知项目立即修改,同时能够作为alfa bu登录在bug治理系统中。测试组要保证测试用例的质量,尽一切可能减

33、少beta后bu的数量。并严格的按照bet后bu处理规约进行。绩效考核实施方案总则:所有职员的所有工作都应该以量化计算，假如不能,则当事者能够提出异议,而对绩效考核方法进行改进。例如所有北京项目必须有，翻译组翻译工作量能够通过翻译的字数进行调整，测试组同样对工作内容进行分类核算D。量化治理要紧包含几个主题方向:工作时刻：是人事部门公布的每个月的工时统计的结果。实际上，它代表了自己的实际消耗时刻。东京M:是实际为公司所制造的价值。北京M:要紧包含正规作的北京内部项目或者实际工作而作的的补充MD。已达到考核的公平合理。质量扣除D:是指由于代码的bg而造成的损失,因为实际的贡献是要扣除损失的。关于测

34、试部确实是东京对北京确认产生的beta后故障的扣除。过程治理扣除M：除了实际的工作量，确实是为个建立一个稳固高效的团队而每个人应该承担的过程治理义务,假如没有做好，实际上不仅仅是你自己绩效不高，而是你阻碍了整个团队的利益。而这部分的值反映了你对团队的阻碍。过程治理奖励MD：在项目实施过程中,个人在突发事件上的处理或者对项目整体乃至公司的利益上作出突出贡献,能够作为绩效奖励。在整个分类上,差不多上是划分为治理者，程序员，分析员，翻译人员,测试人员几个子系统。然而所有系统的价值标准统一。在时刻上，每个月的第五个工作日公布绩效考核结果。绩效考核的结果直接反映在近期和长期的激励系统中。具体内容能够参见

35、流程图翻译组MD核算流程测试组核算流程项目组MD核算流程分析组MD核算流程事项内容注意负责人备注测试组绩效要紧依照测试的工作量和工作结果来进行MD的度量强调质量，会加大质量阻碍的力度。测试部经理要按项目进行分配，多退少补。测试组质量考核要紧是依照be后bug进行，假如出现bet后bu同时被确认为实施ug，对应测试人员应该承担质量责任,按一个实施bug扣除0.1MD计算要注意参看beta后bug汇总表。测试组最关键的问题是依照后的bug情况做分析总结,可向公司申请b分析内部文档,通过后可按北京项目补充MD测试组工作量百分比目前是测试工作本身项目D10测试用例的书写是项目D10目前的测试用例由因此

36、初步书写。因此仅限于第一月项目总控人员第一月后依照测试用例书写的实际工时和状况重新审核此百分比项目分析工作量项目分析指拿到文档后,进行的需求详细分析,提出问题,完毕questionSeet文档和功能电文档原则上项目经理直接进行，同时也能够托付组内具有分析能力的程序员进行,然而必须是项目经理负责制项目经理MD分配时谁分析谁拿走对应的10的MD项目组质量考核严格按照alf版后的ug进行，一个bug扣除01MDAlfa版的bug登录在u治理系统中,项目经理要维护此系统的Pan栏目，程序员要负责其中的D栏目。假如不填写直接作为过程治理扣除MD进行,一次0.1MD测试部经理项目经理Ala版质量扣除MD的

37、汇总表测试部经理负责。Af版过程治理扣除MD汇总表由测试部经理负责。项目总控助理负责审核测试部经理的工作，假如出现纰漏，按过程治理扣除计算,一次0.md项目组单体测试用例工作量核算单体测试用例的条数必须大于D2,核算项目经理直接指定此工作包含在实施70的范围内。项目经理项目经理和全体治理者自身绩效评定全体team（包含自身在内）的平均值因此项目经理要提高整个团队的绩效为目标项目经理由项目总控助理进行监控。出现问题按过失进行处理。年底绩效评定标准直接利用进行评价其中包含东京M和北京MD项目总控人员年底绩效加权系数确定项目经理加权1.分析组加权.1翻译组加权50字/进行折算项目总控人员伴随业务和过

38、程的改变，假如系数有一定的偏差,由项目总控人员对此系数进行调整，反映在文档改版中，并通知全体人员开发部激励和过失治理流程激励治理系统激励的定义和类不定义:激励指职员对公司作出贡献的对应回报。旨在体现公司公平的原则，客观的对个人的能力和价值进行认可。类不与处理方法：类不名称描述实施方式适用范围备注特不MD奖励在项目中作为突出贡献,对公司的利益产生重大阻碍。可由部长提出申请，项目总控人员进行批示。特不奖励单全体职员特不奖金奖励在项目中作为突出贡献，对公司的利益产生重大阻碍。可由治理者直接提议，部长会议进行讨论决定。特不奖励单全体职员部门内项目奖金部长负责制,按季度抽取项目的激励奖金。内容是骨干人员

39、，突出贡献者和分部内的个不活动。（同时,适用测试部和分析组）金额为：2东京D质量扣除MD财务拨款通知单项目奖金分配明细表开发部内全体职员公司资助培训治理者提议,部长会议审议。针对公司的要求和个人情况,提议确定人选和额度。培训通知书突出贡献者或特不岗位升职参考绩效表，考察个人能力,并征求个人意见后,进行职位调整。以给有技术或治理能力的人充分的空间。升职通知书治理者考察通过人员加薪参考绩效表,考察个人能力（技术等级表)，于每年月和月启动调整薪金调查程序，对应该薪金的人进行处理薪金调整单治理者考察通过人员年终奖金年终奖金额度由东京董事会依照北京利益情况进行直接确定奖金分配采纳同一职能部门公开化,计算方法,严格按照个人MD(贡献MD-扣除M）的百分比进行直接计算。年终奖金分配表全体职员过失治理系统定义:过失泛指