员工工作量的评估和管理

员工工作量的评估和管理
员工工作量的评估和管理

POLICY NO: 5.6.17 EV ALUATION AND MANAGEMENT OF STAFF WORKLOAD

OBJECTIVE

To ensure that all employees has access and opportunity to liaise with management in relation to their workload if they perceive it to be excessive.

POLICY STATEMENT

The Town acknowledges that excessive workload, whether real or perceived can be a contributing factor in stress related psychological illness.

Date Adopted: 21 December 2004

Date Amended: -

Date Reviewed: -

Date of Next Review: December 2009

GUIDELINES AND POLICY PROCEDURES FOR EVALUATION AND MANAGEMENT OF EMPLOYEE

WORK LOAD – POLICY NO 5.6.17

The Town is committed to affording all employees the opportunity for review of workload on request and will take appropriate action should intervention be required.

Employees are encouraged to discuss workload issues with their line management, but if they are unable to resolve the issues, a formal process will be undertaken.

This action can be initiated by any employee providing they are willing to fully participate in the workload evaluation and subsequent processes.

Those unable to participate in the process for any reason, must submit a written outline of issues pertaining to workload and reasons why they perceive the load excessive. They may also nominate a peer to represent their interests.

Employees may also raise workload issues with their supervisor or Executive Manager, the Occupational Safety and Health representative, or directly with the CEO if they feel unable to address the issue with the above channels.

The Town's Managers and Supervisors will ensure that those who seek workload evaluation will not be victimised or compromised in any way by their actions.

The workload reviews will be supervised by the Manager Human Resources and the results and actions required will be forwarded to the CEO for ratification.

Action will be taken against any level of management who is found to be discouraging or preventing employees from accessing an independent workload review.

As a matter of course, all employee duty statements and workloads will be reviewed annually as part of the performance appraisal process.

Workload Evaluation Process

A review of the Job Purpose, Duties, Key Performance Indicators (KPIs) and Performance Measures will be carried out by a manager or supervisor from a different division, section or team as deemed appropriate and approved by the CEO.

The employee will keep a work diary for two weeks (or longer if deemed appropriate) relating to tasks carried out, phone calls, meetings and customers interfaces. This will be evaluated against the job purpose, KPIs and Duty statements.

An audit of the skills and training required to undertake the identified tasks and actions will be carried out at this stage, including interpersonal skills in dealing with customers and peers.

The resulting review will identify areas that are exceeding expected workload, or other factors that are infringing on effective time and work efficiency.

A strategy will then be devised to assist the employee and their line management to deal appropriately with issues arising. The strategy may include, but is not limited to: ?Work delegation

?Employee training or retraining

?Time management training and support

?Duty statement revision and workload adjustment

?Ongoing support and reviews

Monitoring of the ensuing workload will be carried out at 4 weeks, 3 month and 6 month intervals and a formal review will be carried out at 12 months.

岗位工作量测评分析报告(模板)

岗位工作量测评分析报告 一、目的 为适应汽车产销下滑的行业形势,相应配合上级单位对于合理配置人力资源的总体要求,同时为了解员工的实际工作情况,提高员工工作效率,优化组织架构,合理利用人工成本,特开展此项工作。 二、测评范围 公司职能及辅助岗位。 三、测评时间 *年*月*日-*年*月*日。 四、采用方法 工作量化分析法,即根据各岗位所写的岗位说明书,将职责细化为日常的工作步骤,对工作步骤完成的时间进行统计,与预先设计好的岗位工作判定标准进行对比,结合岗位任职人员的能力素质,对各岗位的工作量进行评估判断。 五、基本情况 1.测评部门 综合管理部(食堂、司机除外)、财务部、采购部、质量部、技术部(行政专员)、制造部(技能岗位除外),测评人员共计52人。 2.结合工作情况,将工作分为日常性、阶段性、突发性工作;年岗位工作量统计,1天按8小时,1周按5天,一年按250天计算,即50周。 3.本月共31天,周六、周日放假合计8天,本月实际出勤天数23天(按标准工作时间计算),共10166H。 六、公司整体数据分析 总体来说,本次员工岗位工作量测评虽有些方面不尽人意,但作为推行的一项管理措施,基本上没遇到较大的抵触,测评人员也算比较配合。 (一)工作日志完成情况 工作内容:通过近半个月的工作日志的核对,工作内容与岗位说明书一致。 (二)岗位工作结构占比 1.职能岗位工作结构 图标 2.辅助岗位工作结构 图标 根据部门评定后的数据可看出职能岗位日工作量饱满度范围为:50%-100%,日常工作量占总工作量比例范围为:48.92%-89.85%;辅助岗位日工作量饱满度范围为:71.25%-133.75%,日常工作量占总工作量比例范围为:55.30%-95.19%;测评岗位主要以日常性工作为主。 (三)工作日志数据、岗位测评填报数据与考勤数据对比

外包管理评估表格模板

1目的 明确本公司的外包过程及其控制方法,通过对外包过程的有效控制,使开发出的系统满足规定的要求。 2适用范围 本文件适用于系统的外包开发。 3职责及权限 1)项目经理负责对系统开发供方(外包方)的调查、评定和选择。 2)项目经理提出外包要求,并组织对外包要求的审核,确定后纳入外包合同。 3) 4 4.1 1) 等 2)由项目经理组织质量控制部、研发部对系统开发供方的质量管理体系、技术水平进行审核,并提出质量审核报告。 4.2合格系统开发供方的选择 1)项目经理提供《系统开发供方调查表》、质量审核报告及有关证明资料,组织有关人员或部门,对系统开发供方进行评定和选择。评定和选择依据是系统开发供方系统开发的能力,包括:开发经验、人员结构、设备资源、技术水平、质量保证能力、顾客满意程度等。 2)根据参加人员的评审意见,由项目经理填写《系统开发供方评定表》,参加者会签。 3)项目经理负责拟制《合格系统开发供方名单》,报主管VP审批。

4)《合格系统开发供方名单》是本公司选择系统开发供方的依据,经批准的《合格系统开发供方名单》为受控文件,由项目配置管理员负责发放并归档管理。 4.3合格系统开发供方的调整 4.3.1重新评定的时机 1)每个外包项目完成时都要对外包系统开发供方进行重新评定。 2)超过一年未合作的合格系统开发供方,有外包项目前重新评定审批。 4.3.2重新评定的方法 1) 《合 2)对一年内无外包项目的合格系统开发供方,当再次合作前,要重新对其进行调查评定审批,评定方法同上文,侧重于对供方调查资料有效性的跟踪和判定。 5外包过程控制 5.1外包项目过程控制 由项目经理按照外包合同的规定,对外包项目过程进行控制。 5.2外包系统验收 由项目经理按照外包合同规定的接收准则和方法,对外包系统进行验收,验收合格后由项目配

工作量评估方法完整版.完整版.docx

关于工作量评估方法 为能清楚阐明论点。先举两个例子。 大家一定都听说过“龟兔赛跑”的故事,故事里乌龟是正面人物,而兔子作为反面人物受人讥讽,其中的寓意教育人们做事要像乌龟一样有坚忍不拔的精神。如果换个角度分析这个故事。则会有不同的结论。兔子在整个赛跑过程中做了两件事,那就是赛跑和睡觉;乌龟则仅做了一件事,就是不停地赛跑。如果我们试把时间延长(即看看它们在赛后又做了什么),可以想象乌龟由于比赛的疲劳,而跑回家呼呼大睡了;兔子呢?由于比赛中同时也保养了精神,赛后可以做其它更多自己想做的事。由此,不难得出整个过程兔子的效率更高。另外,乌龟并不擅长跑步,却安排它去参加这场比赛,其效率必然极低,把这种现象映射到企业管理中去,也颇发人深思。 试看一个说明工作效率与工作饱和相矛盾的例子:某工厂的一位计算机技术人员,现场发生了微机故障,从他的办公室到达故障点的方式有两种选择,其一是步行,需要10分钟;其二是骑自行车,只需2分钟。我们设步行到现场的为甲,骑车到现场的为乙,最后统计:两人去处理同样的一个工作,甲用了30分钟,而乙只用了15分钟,(这里是假设两人故障的修复时间相同,但事实上甲这类人在故障修复中要花更多的时间)。乙在剩下的15分钟又可以做其它更多的事情,单从这点出发,甲与乙在工作成效上就不仅是1:2的差距了,而是1:N(即甲做一件事的时间,乙做了N件事)的差距。但在现实中,甲往往成了“工作量饱满、劳动模范”的象征;而乙却常常恰好相反,这是管理人员认识上的一大误区,长此下去必然带来管理上的一系列问题。 工作效率由员工的自身因素决定,但如何激励员工提高工作效率,目前仍是管理上的问题。首先是工作分配的合理化,它直接影响工作的效率,让乌龟去赛跑,显然是不合理,所以对工作的合理分配是提高效率的首要条件,这与管理人员的工作密不可分,要求管理人员不仅清楚了解管辖范围内的工作内容,而且要对被管理人的基本情况有清楚的认识。 工作分配合理后,那如何主动去提高每个员工的工作效率呢?竞争是个好方法,奖惩也是个好方法,另一种就是让员工自身有好的素质,拥有正确的人生观及世界观,提高效率便成为很自然的事。前两种方法是被动的,也是目前企业管理中普遍采用的方法,而第三种方法突出了“人自身的因素,希望通过发挥主观能动性来提高工作效率。因为当一个人具有一定知识水平(包括综合知识和技能知识),拥有正确的人生观及世界观,那么我们说,从主观上他会自觉主动地提高效率,从效率中求饱和,再从饱和中追求效率。这样看来采用这种方法,不仅仅能提高效率,而且同时无形中也解决了效率与饱和间的矛盾。 由此可见,通过主观能动性来提高效率,关键就是如何提高员工的综合素质问题,这个素质并非仅仅指的员工的技术知识水平,更重要的还包含道德修养、情操和理想等一些深层次东西。目前企业对员工的素质教育,仅仅是偏重于技能知识的教育,认为员工只要有好的技术和熟练的操作,便有了效率,这是远远不够的。因此,素质的提高在于两方面:①个人专业技能及社会知识要丰富,这是效率的基本前提;②同时应丰富其它的各类知识,如自然知识及人文知识等等。企业管理中在对提高员工素质方面应该投人更多,这样可以更快的从被动地提高工作效率转变为主动地提高工作效率。 以上谈了工作效率问题。现在再来看看工作量问题。评价一个人工作饱和度高不高(注意这里是针对同一个工作),答案就只有两种:低效率饱和度高;高效率饱和度低。可见效率与饱和度存在着矛盾。而“工作饱和”的含义应该是指员工的有效工作时间与规定的劳动时间相等或近似相等,这里的工作时问是指有效的工作时间,强调“有效”二字,“有效”就包含效率和成效的意思。这又体现了效率与饱和度有统一的一面。而在现实的管理工作中,管理人员常常忽略“有效”的重要性,虽然这种“忽略”往往并不是有意的,自然也就无法正确评价如何才算是工作饱和,于是便出现了“整天忙个不停的员工就一定是个好员工”的谬论。所以如何科学地去看待工作饱和度其实也是管理上的问题,它要求管理人员自身具有好的素质及高的效率,这样才谈得上被管理的人有好的素质及高的效率。

如何做好岗位工作量调查

如何做好岗位工作量调查 岗位工作量调查,也称为“岗位工作饱满度测试”,它是公司领导和人力资源管理部门了解本单位在岗员工工作状况的主要手段,同时也是各单位进行定岗定编的重要依据,它对各单位的人力资源管理工作具有较强的现实意义。而很多单位在开展这项工作时往往感觉非常棘手,经常因推行困难而不了了之或半途而废。归纳起来,主要有以下几方面的问题:一是缺乏科学有效的操作方法,导致调查结果形式各异,无法比较;二是缺乏明确的衡量标准,对调查结果不能进行有效判别;三是受制于本单位人员能力素质和管理制度的制约,调查结果没有反映岗位真实情况。以上问题如果得不到有效解决,岗位工作量调查就难以达到预期的效果,对人力资源管理的指导意义也就大打折扣。笔者根据以前项目上的经验,总结出一套岗位工作调查的方法,在实际运用中可以较好地应对以上提到的问题,并得到了客户认可,现提出来与大家分享。 这套方法是从工作分析入手,首先明确岗位的具体工作职责,并将职责细化为日常的工作步骤,然后对这些工作步骤的完成时间进行统计,与预先设计好的岗位工作判定标准进行对比,结合岗位任职人员的能力素质,对各岗位的工作量进行评估判断,最后根据本单位实际情况和未来经营目标,对岗位设置合理性进行评判,对相关岗位职责提出调整以及对岗位编制提出建议。在上述步骤中,明确岗位工作职责是属于工作分析的范畴,在很多文章中均有阐述,因此不作为本文讨论的重点,本文是从岗位工作职责明晰以后入手,重点讨论如何进行岗位工作量调查。 一、设定岗位工作量化判定标准 岗位工作量化判定标准从岗位工作量、岗位工作结构和岗位工作强度入手,根据经验数据,确定相应标准,以此作为判断岗位设置依据是否充分以及岗位是否需要调整的依据。如下表所示:

人力资源如何进行岗位工作量调查

如何进行岗位工作量调查 岗位工作量调查,也称为岗位工作饱满度测试,是企业领导和人力资源管理部门了解在岗员工工作状况的主要手段,也是企业进行定岗定编的重要依据。但很多企业在开展这项工作时感觉非常棘手,往往半途而废。归纳起来,主要有以下几方面的原因: 一是缺乏科学有效的操作方法,导致调查结果形式各异,无法比较: 二是缺乏明确的衡量标准,对调查结果不能进行有效判别: 三是受制于本单位人员能力素质和管理制度,调查结果不能反映岗位真实情况。 笔者根据多年的咨询管理经验,总结出一套容易操作的岗位工作量调查方法,能够较好地应对以上问题。这套方法首先是从工作分析入手,明确岗位的具体工作职责,并将职责细化为日常的工作步骤,然后对这些工作步骤的完成时间进行统计,与预先设计好的岗位工作判定标准进行对比,结合岗位任职人员的能力素质,对各岗位的工作量进行评估判断,最后根据本单位实际情况和未来经营目标,对岗位设置合理性进行评判,提出相关岗位职责调整方案以及岗位编制建议。本文重点讨论岗位工作职责明晰以后如何进行岗位工作量调查。 岗位工作量化判定标准 岗位工作量化判定标准是根据岗位工作量、岗位工作结构和岗位工作强度来确定相应标准,以此作为判断岗位设置是否充分以及岗位是否需要调整的依据。岗位工作量化判定标准如下: 1、岗位工作量标准工作量百分比法:工作量饱满度=岗位有效工作时间/平均正常工作时间×100% 统计工作时间一般以日、周、月或年为单位,如岗位年实际工作饱满度=岗位年实际工作日/年有效工作日×100%。一般饱满度达到70%以上时,说明岗位工作量饱满。 岗位工作量饱满度判别标准如下 很饱满:90%以上; 饱满:70%-90%: 基本饱满:50%-70%, 不饱满:50%以下。 2、岗位工作结构标准 按照日常性、阶段性和临时性工作划分,日常性工作是指依据现有组织目标和职能展开的工作,日常性工作量/总工作量×100%,比值在50%以上,说明岗位设置依据充分,一般

软件开发工作量估算和报价

1.软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式: 软件开发价格=开发工作量×开发费用/人·月 开发工作量 软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关: 软件开发工作量=估算工作量经验值×风险系数×复用系数 软什开发工作量的计算,曾有人提出以源代码行或功能点来计算,这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算,国内各软件企业也是采用经验的方式加以估算工作量。 为了更好地规范估算方法,建议可按照国家标准“GB/T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 工作量的计算是按一个开发工作人员在一个月内(日历中的月,即包括国家规定的节假日)能完成的工作量为单位,也就是通常所讲的“人·月”。 特别要提醒的是软件开发过程中既包括了通常所讲的软件开发,也应包括各类软件测试的活动。 估算工作量经验值亦会存在较大风险,造成软件危机的因素很多,这也是一个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉,而且用户又无法或不能完整明白地表达他们的真实的需求,从而造成软件企业需要不断地完善需求获取,修改设计等各项工作。因此:

l≤风险系数≤ 根据我们对软件企业的了解,超过估算工作量经验值的一半,已是不可接受,所以我们确定“”为极限值。当然这既要看企业的能力,也要看用户能接受的程度。 估算工作量经验值是软件企业承担一般项目来估算的,但如果软件企业已经采用“基于构件的开发方法”,并己建立起能够复用的构件库(核心资产库),或者已有一些软件产品,仅作二次开发,从而使软件开发工作量减少。因此: ≤复用系数≤1 根据国内外软件企业在实施基于构件开发方法(软件产品线)的经验数据,提高工作效率达到25%(最高值)。 开发费用/人·月 软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。 开发费用/人·月=(P+Q+R)×S×τ 人头费主要是员工的工资、奖金和国家规定的各项按人计算的费用。其总量在软件企业中的商务成本占70%-80%。 P=B× 国家规定的公积金7%,医疗保险金12%,养老金22%,失业金2%(即通常所说的四金),另外还有按工资总额计征的工伤保证金%,生育保证金%,残疾基金%,工会基金2%,累计为%。B为平均工资,即企业支付给员工的工资、奖金、物质奖励等多项总和,除以企业员工数,分摊到每个月。

工作量考核方案

工作量考核方案 工 作 量 考 核 方 案 (拟定稿) 说明: 一.本包括考核制度和考核量表两部分。. 二.考核量表主要是测评教务处学生助理员的绩效,同时作为教 务处学生助理工作组工资发放的参考依据。 三.附考核流程图如下: 四、本制度每学期期末考试周前接受所有老师和教助意见并及时完 善,制度完善并施行前应专门召开集体会议,公开解释制度具体细节的构建理由和含义。最终解释权归教务处学生助理工作量评估小组。 五、本制度提交华中师范大学教务处学生助理工作组备案。

教务处学生助理考核制度 第一章 第一条总则考核的目的是通过客观评价教务助理的工作能力、态度,优化教务 处助理队伍,并客观合理地安置教务助理,做到人岗匹配,并以考 核结果为参考,发放教助的年终薪酬。 第二条本规定中使用的专业术语定义如下: (一)能力考核---------通过工作行为,观察、分析、评价教助具有的工作能力。 (二)态度考核---------通过对教助的工作努力情况和工作热情进行观察和评 价。 (三)业绩考核---------对教助分担的工作完成情况进行观察、分析和评价。(四)360度考核法----即全视角绩效考核法,通过不同的考核者(老师、同学、 其他教助等)从不同的角度来全方位考核教助工作情况。 (五)KPI法------------即关键业绩指标,选取一些关键的、与教助队伍目标实 现关系比较紧密的工作内容作为考核项目。 (六)考核者-------------老师、同学以及其他教助。 (七)被考核者----------2007-2008学年度教务助理。

(八)考核执行者--------教务助理工作组。 第三条考核原则 (一)考核标准尽可能量化; (二)考核标准的制定以教助管理条例为依据,按照教务 处的标准制定。 第四条每位教务助理一学期工资标准在400元左右浮动,教务助理最后所 得工资根据考评结果而定。 第五条考核方法是360度考核法,由教务助理所在办公室老师,其他办公室 教助(即同事)共同参与,实行打分制,考核表由教务助理所在办公室老师填写,同时参考其他办公室教助(即同事)意见,运用KPI法确定绩效考核标准。 第二章考核流程与实施 第一条教务助理工作组开会讨论确定最终考核制度; 第二条由教助工作量评估小组整理制度材料,交给教务 助理工作组审核, 最后上交教务助理管理老师审批; 第三条制度执行,由各办公室老师对本办公室教助进行 考核; 第四条由教助工作量评估小组进行汇总,按分数列出等级,确定薪酬;

企业如何进行岗位工作量调查

企业如何进行岗位工作量调查 岗位工作量调查,也称为岗位工作饱满度测试,是企业领导和人力资源管理部门了解在岗员工工作状况的主要手段,也是企业进行定岗定编的重要依据。但很多企业在开展这项工作时感觉非常棘手,往往半途而废。归纳起来,主要有以下几方面的原因: 一是缺乏科学有效的操作方法,导致调查结果形式各异,无法比较: 二是缺乏明确的衡量标准,对调查结果不能进行有效判别: 三是受制于本单位人员能力素质和管理制度,调查结果不能反映岗位真实情况。 笔者根据多年的咨询管理经验,总结出一套容易操作的岗位工作量调查方法,能够较好地应对以上问题。这套方法首先是从工作分析入手,明确岗位的具体工作职责,并将职责细化为日常的工作步骤,然后对这些工作步骤的完成时间进行统计,与预先设计好的岗位工作判定标准进行对比,结合岗位任职人员的能力素质,对各岗位的工作量进行评估判断,最后根据本单位实际情况和未来经营目标,对岗位设置合理性进行评判,提出相关岗位职责调整方案以及岗位编制建议。本文重点讨论岗位工作职责明晰以后如何进行岗位工作量调查。 岗位工作量化判定标准 岗位工作量化判定标准是根据岗位工作量、岗位工作结构和岗位工作强度来确定相应标准,以此作为判断岗位设置是否充分以及岗位是否需要调整的依据。岗位工作量化判定标准如下: 1、岗位工作量标准工作量百分比法:工作量饱满度=岗位有效工作时间/平均正常工作时间×100% 统计工作时间一般以日、周、月或年为单位,如岗位年实际工作饱满度=岗位年实际工作日/年有效工作日×100%。一般饱满度达到70%以上时,说明岗位工作量饱满。 岗位工作量饱满度判别标准如下 很饱满:90%以上; 饱满:70%-90%: 基本饱满:50%-70%, 不饱满:50%以下。 2、岗位工作结构标准 按照日常性、阶段性和临时性工作划分,日常性工作是指依据现有组织目标和职能展开的工作,日常性工作量/总工作量×100%,比值在50%以上,说明岗位设置依据充分,一般日常性工作应占总工作量的60%以上。如果日常性工作低于50%,说明岗位工作量不稳定,会出现时而饱满,时而不饱满的情况。 3、岗位工作强度分布标准 如果岗位工作量在一段时间内的总量正常,但主要集中某段时间,造成这段时间工作量出现了波峰(一天工作量达到10小时以上),而其余时间出现了波谷(一天的工作量不足4小时):或者持续每天工作时间在10小时以上,且这样的工作日占全年有效日的30%以上,应认为工作强度分布不均。 进行岗位工作量调查 一般来说,每个岗位的工作可以划分为日常性:工作、阶段性:工作和临时性工作。日常性工作指每天重复做的工作,阶段性工作指每周/月/季/年做的工作,临时性工作指上级单位/领导或相关部门临时安排或突发性的工作。根据岗位工作职责,填写工作调查问卷,将岗位职责细化为日常的工作步骤,对每一工作步骤进行现场观察并统计完成每一步工作所耗费的时间,对照岗位工作量化判定标准,对岗位工作饱满度进行初步判断。以某公司产品调运计划岗为例,如表1所示。

工作量的评估方法

工作量的评估方法 1.软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式: 软件开发价格=开发工作量×开发费用/人·月 1.1开发工作量 软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关: 软件开发工作量=估算工作量经验值×风险系数×复用系数 1.1.1估算工作量经验值(以A来表示) 软什开发工作量的计算,曾有人提出以源代码行或功能点来计算,这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算,国内各软件企业也是采用经验的方式加以估算工作量。 为了更好地规范估算方法,建议可按照国家标准“GB/T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 工作量的计算是按一个开发工作人员在一个月内(日历中的月,即包括国家规定的节假日)能完成的工作量为单位,也就是通常所讲的“人·月”。 特别要提醒的是软件开发过程中既包括了通常所讲的软件开发,也应包括各类软件测试的活动。 1.1.2风险系数(以σ来表示) 估算工作量经验值亦会存在较大风险,造成软件危机的因素很多,这也是一个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉,而且用户又无法或不能完整明白地表达他们的真实的需求,从而造成软件企业需要不断地完善需求获取,修改设计等各项工作。因此: l≤风险系数≤1.5 根据我们对软件企业的了解,超过估算工作量经验值的一半,已是不可接受,所以我们确定“1.5”为极限值。当然这既要看企业的能力,也要看用户能接受的程度。 1.1.3复用系数(以τ来表示) 估算工作量经验值是软件企业承担一般项目来估算的,但如果软件企业已经采用“基于构件的开发方法”,并己建立起能够复用的构件库(核心资产库),或者已有一些软件产品,仅作二次开发,从而使软件开发工作量减少。因此: 0.25≤复用系数≤1 根据国内外软件企业在实施基于构件开发方法(软件产品线)的经验数据,提高工作效率达到25%(最高值)。 1.2开发费用/人·月 软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。 开发费用/人·月=(P+Q+R)×S×τ 1.2.1P(人头费) 人头费主要是员工的工资、奖金和国家规定的各项按人计算的费用。其总量在软件企业中的商务成本占70%-80%。 P=B×1.476 国家规定的公积金7%,医疗保险金12%,养老金22%,失业金2%(即通常所说的四金),另外还有按工资总额计征的工伤保证金0.5%,生育保证金0.5%,残

员工考核细则及考核评分表(20140311)

员工考核细则(试执行) 一、考核目的 1、通过对员工一定时期内工作成绩、工作能力的评价,把握每一位员工的实际工作状况,为 教育培训、工作调动以及提薪、晋升、奖励、表彰等提供客观可靠的依据,更重要的是通过这些评价指导员工有计划地改进工作、保证生产任务顺利完成和提高员工积极性。 二、考核原则 1、考核的目的不是为了制造员工之间的差距,而是实事求是地发现员工的长处、短处、扬长避短,使其有所改进、有所提高。 2、考核成绩是根据员工平常的工作态度、工作业绩、工作技能等因素所评定; 3、考核小组:生产主管、生产经理、行政人事部; 4、考核分为月度/季度考核; 5、考核不掺和任何个人因素,真正做到公平公正公开; 6、考核由各车间主管认真填写考核表,于次月初将上月考核成绩上交人事部,由人事部 对考核结果汇总后公布; 7、考核分为三大部分(工作纪律、工作态度、工作业绩),总分为100分。 8、此考核结果,及相关考核基本数据资料,在每月15号前审核完毕,呈财务计算工资。 9、连续2月总分在最后1名,给予警告处分,第3个月仍没有明显提升者,公司将考虑给 予辞退。 二、适用范围 以下人员不在考核范围内 1、试用期内员工 2、连续请假一个月的员工 3、考核期间入职的员工 三、责任组织 公司人事行政部为绩效考核的归口管理单位,各部门经理负责本部门下属员工工作绩效的考核工作。 五、考核内容 1、个人素质(满分5分) (1)经常保持仪容整洁。 (2)待人接物有礼貌。 (3)品德端正、诚实可信。 (4)乐于助人、平易近人。 (5)见到同事或是领导热情打招呼。 2、工作纪律(满分10分) (1)遵守考勤制度,按时上下班。不迟到、早退,不无故旷工。 (2)衣冠整洁、不赤膊、不穿拖鞋上班。 (3)爱护公共卫生,不随地吐啖,不乱扔垃圾,保持公共场所及个人工作台卫生。 (4)上班时间不吃零食、不玩电话、不打情骂俏、不睡觉、不离岗、不串岗等不做与工作无关的事。 (5)进入工作场所不吸烟。 (6)上班时间,无领班或部门主管批准的不无故外出。

软件开发实施项目工作量评估明细表

项目工作量统计表 项目名称:推进OA系统应用,强化业务整合 一、推进OA流程应用工作量 序号阶段工作内容人员 配备 人·日 1 项目准备现有系统配置情况检查 系统相关模块的基本数据情况检查 制定实施阶段计划,约定每个阶段的时长,准 确划分各阶段时间节点 预定培训实施期间培训日期安排 3 9 2 系统配置建立相关组织结构 建立相关角色 调整全局配置项 建立权限分配方案 2 12 3 流程调研落实需要上线的流程列表,这些流程主要包 括:党委发文流程、纪委发文流程、公司发文 流程、部门发文流程(报告、函、请示、通知)、 公司收文流程,以及:用印申请流程、出差申 请流程、会议管理流程等 培训流程图的标准画法 收集流程图,交流流程信息、修改流程图、流 程图定稿 4 36 4 设定流程建立流程,谁提交,谁批准,谁执行 建立流程表单,及相应说明 建立流程处理签 建立存档管理,配置相关归档目录 建立权限管理 5 85 5 模拟调试对所有流程进行模拟测试,特别是各个重要公 文流程,必须进行遍历测试 根据模拟测试发现的情况,对流程设置进行检 讨和调整 4 72 6 管理员培训对流程管理员进行培训,使其掌握流程异常情 况处理、流程微调技巧 2 8 7 用户培训根据项目实际整理培训资料 落实培训人员、场地、时间安排 三场用户培训,需用户积极配合协调 2 8 8 系统启用建立起与系统运行相适应的管理规章制度 发布正式启用系统的通知 系统检查与实施补充 问题收集、反馈、调整 2 12 9 项目收尾项目回顾 权限收回 2 2 合计244

二、新功能开发工作量 序号阶段工作内容人员 配备 人·日 1 需求调研、分析了解用户业务,获取用户对功能、性能等方面 的需求 4 20 2 需求确认用户方、开发方对需求进行审核确认 这些功能包括:安全认证、电子印章、规章制 度管理、业务整合 2 10 3 总体设计系统初步设计 2 10 4 总体设计评审用户方、开发方对总体设计审核确认 2 2 5 详细设计对系统功能、操作界面、处理逻辑、数据库、 代码体系等进行详细设计 2 20 6 详细设计评审开发组对详细设计方案审核确认 1 3 7 编程、单元测试编写程序、单元测试 系统管理(设置,备份还原) 操作人员管理及权限管理 2 24 安全认证 2 70 电子印章 2 64 规章制度管理 3 81 业务整合(初步) 2 20 业务整合(深入) 4 120 8 集成测试系统集成测试、系统测试,编程与测试可以交 叉进行 4 24 9 安装调试到用户现场安装调试开发好的系统,并与用户 一起试走业务流程,对系统进行功能确认测试 3 21 10 系统初始化将系统初始化;准备业务基础数据并录入系 统; 2 12 11 用户培训对用户操作人员、系统管理人员进行详细培训 1 4 12 项目跟踪与总 结 系统bug控制,操作指导 2 12 合计517 工作量总计:761人·日

如何评估测试工作量

场景一:合同前的工作量估算 场景描述: 软件开发网 (1)没有实施过CMMI2级 (2)合同未签,需要给客户报价 (3)有客户的概要需求,有类似的项目数据可供参考 (4)需要估计整个项目的总工作量,以便于估算总成本,给客户报价 软件开发网 估算步骤: (1)寻找类似的历史项目,进行项目的类比分析,根据历史项目的工作量凭经验估计本项目的总工作量; (2)进行WBS分解,力所能及地将整个项目的任务进行分解; (3)参考类似项目的数据,采用经验法估计WBS中每类活动的工作量; (4)汇总得到项目的总工作量; (5)与第(1)步的结果进行印证分析,根据分析结果,确定估计结果。 场景二:基于详细需求的经验估计 场景描述: (1)只有详细需求,没有历史数据 估算步骤: (1)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。 (2)采用经验法估计每个活动的工作量; (3)汇总得到:每个阶段的工作量、项目的总工作量。 其他说明: 在该场景下,只使用了经验法,无法对结果进行印证,难以判断结果的合理性。 场景三:由编码估算整体 场景描述: (1)有类似项目的历史数据 (2)有编码活动的生产率数据 (3)有详细需求 (4)实施了CMMI2级,但是没有积累历史项目的工作量分布数据软件开发网 估算步骤: (1)产品分解,将系统分为子系统,子系统分解为模块; (2)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要

识别出所有的交付物、项目管理活动、工程活动等。 (3)建立WBS分解中的活动与产品元素的映射关系,识别出WBS中哪些活动可以采用模型法估算; (4)估计产品元素的规模,可以采用代码行法或功能点法,并估计每个产品元素的复杂度、复用率等; (5)根据历史的编码阶段的生产率数据和产品元素的规模估计、复杂度、复用率等采用模型法计算每个产品元素的编码工作量; (6)根据历史的类似项目的数据及估算人的经验估计其他活动的工作量,可以采用经验法。(7)汇总得到:每个阶段的工作量、项目的总工作量。 其他说明: 在该场景下,混合使用了经验法与模型法,这2种方法互相补充,而不是互相印证。 场景四:由总体印证基于WBS的估计 场景描述: (1)有类似项目的历史数据 (2)有类似项目的全生命周期的生产率数据(含管理工作量) (3)有详细需求 (4)实施了CMMI2级,但是没有积累历史项目的工作量分布数据 估算步骤: (1)产品分解,将系统分为子系统,子系统分解为模块; (2)估计产品元素的规模,可以采用代码行法或功能点法; (3)累计出整个产品的总规模,并估计产品总体的复杂度、复用率等; (4)根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量; (5)WBS分解,将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。 (6)根据历史的类似项目的数据及估算人的经验估计所有活动的工作量,可以采用经验法。(7)汇总得到:每个阶段的工作量、项目的总工作量。 (8)与第(4)步得出的工作量进行比较印证,如果偏差不大,则以第(7)步的结果为准,如果偏差比较大,要仔细分析原因,可能的原因举例如下: 类似项目的生产率数据不适合本项目; WBS分解的颗粒度不够详细; 估算专家的经验不适合本项目; 具体任务的估计不合理; 针对原因,对估算的结果进行调整,使其趋向合理。 其他说明: 在该场景下,对于项目的总工作量有2个结果或者多个结果,这些结果可以互相印证,以发现估算过程中的不合理之处,是估计更加合理。

工作量的评估方法

羀工作量的评估方法 肄1.软件开发价格估算方法 袅软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便 于计算,给出一个计算公式: 膂软件开发价格=开发工作量×开发费用/人·月 螇1.1开发工作量 莇软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关: 芄软件开发工作量=估算工作量经验值×风险系数×复用系数 羂1.1.1估算工作量经验值(以A来表示) 螈软什开发工作量的计算,曾有人提出以源代码行或功能点来计算,这些方法 实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算,国内各软件企业也是采用经验的方式加以估算工作量。 蒅为了更好地规范估算方法,建议可按照国家标准“GB/T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 蚄工作量的计算是按一个开发工作人员在一个月内(日历中的月,即包括国家 规定的节假日)能完成的工作量为单位,也就是通常所讲的“人·月”。 蚃特别要提醒的是软件开发过程中既包括了通常所讲的软件开发,也应包括各 类软件测试的活动。 袀1.1.2风险系数(以σ来表示) 袇估算工作量经验值亦会存在较大风险,造成软件危机的因素很多,这也是一 个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟 悉,而且用户又无法或不能完整明白地表达他们的真实的需求,从而造成软件企业需要不断地完善需求获取,修改设计等各项工作。因此: 肃l≤风险系数≤1.5 蒃根据我们对软件企业的了解,超过估算工作量经验值的一半,已是不可接受,所以我们确定“1.5”为极限值。当然这既要看企业的能力,也要看用户能接受 的程度。

常用的工作量评估方法

常用的工作量评估方法在测试项目管理中或编写测试计划时,经常需要对某个测试工作进行工作量的预算,很多时候都是凭个人的工作经验进行估算的,如能结合一些常规的估算方法,有助于估算的精确度。 以下是网上找到的一些常规的估算测试工作量的方法: 1、Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者,一直到用完了预算的经费。这种情况普遍存在于非常不成熟的组织,并且时常有100%的错误差数。 2、开发时间的百分比法Percentage of development time。 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先,开发工作量使用例如LOC或FP方法被估算出来,然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试。?5-7%给组件和集成测试?18-20%给系统测试?10%给接收测试(或回归测试等) 3、类比法(经验值法或历史数据法) 根据以前或相似项目(主要在项目性质,领域,规模上有相似)所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度,因此,用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据:?在设计和实现阶段花费的时间?测试工作的规模,例如用户

需求的数量,页面数,功能点?数据样式,例如实体,字段的数量?屏幕或字段数量?测试对象的规模,例如KLOC 4、WBS(work breakdown structure)估算法 将项目或产品分解为具体的工作,然后分别对各个工作进行时间估算,最终求和得出项目或产品的测试工作量/时间。 5、Delphi法 Delphi法是最流行的专家评估技术,在没有历史数据的情况下,这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术,要求有多种相关经验人的参与,互相说服对方…… Delphi法的步骤是:1、协调人向各专家提供项目规格和估计表格;2、协调人召集小组会各专家讨论与规模相关的因素;3、各专家匿名填写迭代表格; 4、协调人整理出一个估计总结,以迭代表的形式返回专家; 5、协调人召集小组会,讨论较大的估计差异; 6、专家复查估计总结并在迭代表上提交另一个匿名估计; 7、重复4-6,直到达到一个最低和最高估计的一致。 6、PERT估计法 PERT对各个项目活动的完成时间按三种不同情况估计:一个产品的期望规模,一个最低可能估计,一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E,和标准偏差SD 1.软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式:

工厂岗位工作量评估框架

目录第一部分工作量评估概况 一、工作量评估概况及实施过程 二、工作量评估目标 三、评估的定义及有关数据说明 四、评价指标和标准 第二部分各岗位工作量评估汇总 一、各岗位工作量评估结果汇总表 二、基于评估结果的建议 第三部分各岗位工作量评估 一、技术质量部(5人) 1、质量工程师(1人) 2、检验组长(1人) 3、质量管理(1人) 4、技术员(1人) 5、检验员(1人) 二、制造物流(44人) 1、组长(2人) 2、装配副组长(1人) 3、质量工程师(1人) 4、销售管理(1人) 5、质量管理(1人) 6、技术员(1人) 7、检验组长(1人) 8、检验员(1人) 9、班长(3人) 10、模具工(5人) 11、叉车工(1人) 12、机修工(2人) 13、操作工(8人) 14、包装工(14人) 15、清洁工(2人)

第一部分工作量评估概况 一、工作量评估概况及实施过程 岗位工作量评估实施的目的是,通过工作量负荷的评估,掌握各岗位工作量分布状况,合理划分工作流,提高人力资源配置的效率,为公司领导决策提供可信和公平的依据。 工作量评估以7-8月作为旺季的工作负荷率,11-12月作为淡季的工作负荷率,然后进行加权平均作为该岗位的全年平均综合工作负荷率。 二、工作量评估项目的目标 1、辅助工岗位中操作工、叉车工、包装工为将要实行计件计酬的方式,不属本次的评估对象;除此之外,属于本次评估的其他各岗位,有日班、或两班班次的,各个班次均进行评估。 2、针对负荷率未达饱和标准的岗位,着重从工作流程设计、人力资源的充分整合、劳动生产率的提高等方面进行探讨,以期合理分配员工工作负荷,提高班组整体运行效率。 3、为了做到评估结果的全面、准确,尽可能的降低误差率,评估采用员工个人自评、上级主管确认、现场观测相结合的形式,以期能全面、客观、准确的反映员工的日常工作负荷情况。 三、评估的定义及有关数据说明 为便于阅读,现对评估报告中涉及的定义及数据进行说明: 1、岗位工作量负荷率:制度工作时间(8小时)内纯劳动时间所占比率。定义如下: 岗位工作负荷率=纯劳动(规范劳动)时间/制度工作时间

软件开发工作量估算和报价

1.软件开发价格估算方法软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算,给出一个计算公式:软件开发价格=开发工作量×开发费用/人·月 开发工作量 软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关: 软件开发工作量=估算工作量经验值×风险系数×复用系数 软什开发工作量的计算,曾有人提出以源代码行或功能点来计算,这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算,国内各软件企业也是采用经验的方式加以估算工作量。 为了更好地规范估算方法,建议可按照国家标准“GB/T 8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 工作量的计算是按一个开发工作人员在一个月内(日历中的月,即包括国家规定的节假日)能完成的工作量为单位,也就是通常所讲的“人·月”。 特别要提醒的是软件开发过程中既包括了通常所讲的软件开发,也应包括各类软件测试的活动。

估算工作量经验值亦会存在较大风险,造成软件危机的因素很多,这也是一个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉,而且用户又无法或不能完整明白地表达他们的真实的需求,从而造成软件企业需要不断地完善需求获取,修改设计等各项工作。因此: l ≤风险系数≤ 根据我们对软件企业的了解,超过估算工作量经验值的一半,已是不可接受,所以我们确定“”为极限值。当然这既要看企业的能力,也要看用户能接受的程度。 估算工作量经验值是软件企业承担一般项目来估算的,但如果软件企业已经采用“基于构件的开发方法”,并己建立起能够复用的构件库(核心资产库),或者已有一些软件产品,仅作二次开发,从而使软件开发工作量减少。因此: ≤复用系数≤1 根据国内外软件企业在实施基于构件开发方法(软件产品线)的经验数据,提高工作效率达到25%(最高值)。 开发费用/人·月 软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。 开发费用/人·月=(P+Q+R)×S×τ P(人头费)

学校中层管理人员工作量核定办法

学校中层管理人员工作量核定办法 (征求意见稿) 一、中层管理人员范围:副校长、主任、副主任、年级主任、团支部书记、少先队总辅导员、卫生管理人员、后勤管理人员。 二、副校长、主任、副主任工作量分为两块,一为基本工作量为原工作量的1/4,另一块为活动工作量。 三、工作量具体计算方法: 1、制订部门工作计划2分,写好部门工作总结2分。 2、备课作业检查:(备课检查一次十分,作业检查一次十分) (1)、每学期检查三次,备课:每次查全部学科,作业:每次查部分作业。(2)、检查方法:每次一科一位领导和两位老师,采用推磨式检查。 (3)、检查步骤:①、收、订1分。②、检查、记录、写好评价意见3分。 ③统计数据1分。④、反馈2 分⑤、分析总结3分 (4):作业检查包括作业批改记录和学生错题矫正记录。 3、听课: (1)、行政听课,一人参与,一节1.5分,要有听课记录、评课记录、听课教师的签字和被听课教师所在年级组长的签字。 (2)、教研听课(如教师公开课、示范课、评优课等),要组织教研组有关教师共同听课,一节3分。要做到收发表格、统计数据、写好总结、组织评课。 4、辅导(查记录每学期两次每次5分) 步骤:(1)、收发0.5分。(2)、抽调有关人员,安排有关事项0.5分。(3)、检查2分。(4)、统计数据0.5分。(5)、反馈1分。(6)、总结0.5分。 5、考试,每学期进行月考两次,期中、期末各一次。 (1)月考(全校统一时间进行,负责全面工作为12分,参与组织人员一个年级得2分。) 步骤:1、准备试卷;2、准备登分表、试卷分析;3、组织考试;4、组织阅卷; 5、组织登分; 6、进行教学质量分析,写好总结。(同组教师分析,计算 出学生平均分、优生率、及格率、班级进位数等有关数据,写好学校考试 整体分析并向全体教师传达。) (2)期中、期末考试(全校统一时间进行,负责全面工作为24分,参与组织人员一个年级得4分。) 步骤:1、做好考试准备(分班、安排考场、安排监考阅卷人员等)2、分发、装订试卷。 3、组织好考试(铃声、纪律等) 4、组织阅卷、登分。 5、进行教学质量 分析,写好总结。(同组教师分析,计算出学生平均分、优生率、及格率、班级进位数等有关数据,写好学校考试整体分析并向全体教师传达。) 6、教师培训每进行一次2分。 职责:(1)制定培训计划及活动安排(2)准备培训资料 (3)组织培训(要有签到表、活动记录)(4)检查教师学习记录 (5)整理有关资料(6)评估教师学习情况(7)写好培训总结 7、教科研工作每次活动加2分。(活动要有计划、记录、总结等书面材料) 职责:(1)、制定教育教学科研的工作计划

员工工作量评估范文

员工工作量评估范文 今天刚刚进行了一个小软件的工作量评估,总是觉得评估的不够准确,而且难以明确,把心中的困扰跟实际所使用的做法简单说说,工作量评估中,困扰我的问题主要有以下几个 1、需求不清晰,并且会有变化 2、工作量评估在需求规格说明编写的同时就需要进行,一般来说,没有立项,就还不会做详细的需求调研,但这时候就要出工作量评估 3、系统架构及设计没有开始,此时工作量评估往往不准确,比如可以采用一个既有的组件,或者重用一些代码,但是没有详细定义设计时,难以确定准确可以节约多少时间,改造成本 4、不知道自己将面对什么样的开发团队,有人一天,有人要10天才能做完,但你很难有一支你熟悉了解的团队 虽然也了解过各种工作量评估方法,但是实际中总感觉难以使用(应该是不会使用) 自己的做法如下: 1、确定有多少模块,每个模块下有多少页面,针对每个模块列出需求、设计、开发、测试、部署时间,组成这一模块的时间 2、需要多少个公共的类,分别有多复杂 3、加上项目管理时间,大概5个人的团队,需要一个不编码的专门管理,做类似于功能检查,代码review之类的事情 4、加上一定比例的变更时间(根据用户的历史情况而定,或者感觉用户头脑清晰度而定)

5、最后得出的数字乘以一个1.5-3,得出最后时间,这个1.5-3是根据评估人历史的情况,比如,我以前一年里评估的工作量大概都需要乘以2才是最后实际的,就会在新项目评估时(无条件乘以2),这些时间总会被用户有办法用掉,(说到这里,自己很可耻一下,开发过程中很多时间都不知道去哪里了,比如用户说按钮上怎么没有图片啊,之类的,或者说放左边好看啊,这些时间就没了,每次都不可预知,或者服务器上装个什么软件,不知道又出什么问题,有几天不开心,效率低下等等) 虽然一直按以上这种方式做,但是总觉得不是很好,主要有以下几个方面 1、准确性差,从上可以看到,准确率只有50%左右 2、难以解释,说这个页面为什么要这么久,这个功能为什么这么久,完全是凭着脑子里过一下,有几个按钮,大概写多少代码的一个感觉,经不起推敲 3、评估工作量和实际设计完成后的很难对应上,通过设计后,可能有些部分为了通用超出想象得工作量,有些部分公用了,又减少了。 很难理解,到底真正准确率高的工作量评估是怎么做的。 在我看来,设计完成后,工作量才能准确评估。但是为什么工作量评估总是要在前期需求刚刚了解一部分就要出。这是为什么呢,怎么做呢?

相关文档
最新文档