员工工作量评估
员工工作量评估今天刚刚进行了一个小软件的工作量评估，总是觉得评估的不够准确，而且难以明确，把心中的困扰跟实际所使用的做法简单说说，
工作量评估中，困扰我的问题主要有以下几个
1、需求不清晰，并且会有变化
2、工作量评估在需求规格说明编写的同时就需要进行，一般来说，没有立项，就还不会做详细的需求调研，但这时候就要出工作量评估
3、系统架构及设计没有开始，此时工作量评估往往不准确，比如可以采用一个既有的组件，或者重用一些代码，但是没有详细定义设计时，难以确定准确可以节约多少时间，改造成本
4、不知道自己将面对什么样的开发团队，有人一天，有人要10天才能做完，但你很难有一支你熟悉了解的团队
虽然也了解过各种工作量评估方法，但是实际中总感觉难以使用（应该是不会使用）
自己的做法如下：
1、确定有多少模块，每个模块下有多少页面，针对每个模块列出需求、设计、开发、测试、部署时间，组成这一模块的时间
2、需要多少个公共的类，分别有多复杂
3、加上项目管理时间，大概5个人的团队，需要一个不编码的专门管理，做类似于功能检查，代码review之类的事情
4、加上一定比例的变更时间（根据用户的历史情况而定，或者感觉用户头脑清晰度而定）
5、最后得出的数字乘以一个1.5-3，得出最后时间，这个1.5-3是根据评估人历史的情况，比如，我以前一年里评估的工作量大概都需要乘以2才是最后实际的，就会在新项目评估时（无条件乘以2），这些时间总会被用户有办法用掉，（说到这里，自己很可耻一下，开发过程中很多时间都不知道去哪里了，比如用户说按钮上怎么没有图片啊，之类的，或者说放左边好看啊，这些时间就没了，每次都不可预知，或者服务器上装个什么软件，不知道又出什么问题，有几天不开心，效率低下等等）
虽然一直按以上这种方式做，但是总觉得不是很好，主要有以下几个方面
1、准确性差，从上可以看到，准确率只有50%左右
2、难以解释，说这个页面为什么要这么久，这个功能为什么这么久，完全是凭着脑子里过一下，有几个按钮，大概写多少代码的一个感觉，经不起推敲
3、评估工作量和实际设计完成后的很难对应上，通过设计后，可能有些部分为了通用超出想象得工作量，有些部分公用了，又减少了。
很难理解，到底真正准确率高的工作量评估是怎么做的。
在我看来，设计完成后，工作量才能准确评估。但是为什么工作量评估总是要在前期需求刚刚了解一部分就要出。这是为什么呢，怎么做呢？
特别值得一提的是，根据大概会产生多少代码行进行评估，我特别难以理解，有人能听客户说了一天需求，就大概估算出代码行数，真是神人啊。
欢迎告诉我您的工作量评估方法，让我也学习一下。
1. 根据测试范围和测试方法来估计工作量：
a）制定测试计划以前，明确测试范围：
不同的测试范围，对测试量的评估起到至关重要的因素，比如说测试一个模块或测试多个模块或测试整个系统等等，都属于测试范围不一样，明显工作量也不同，差别也挺大的。还有测试范围还包括功能性测试范围或非功能性测试范围等等，在做测试工作量评估的时候，都必须考虑。
b）确定合理、有效的测试方法：
比如说你要考虑测试某个项目，你必须考虑测试方法是否合理。比如说某个模块的功能测试，你可以采用QTP做自动化功能测试，还是手工做功能测试，工作量就不一样，做测试计划以前必须考虑清楚。要不然，估算的工作量肯定不准。
2. 根据测试任务来评估工作量：
a）质量需求和项目背景决定工作量：
不同的项目背景，不同的质量要求，决定不同的测试工作量。如果我们测试的是一个银行系统，涉及到每个人的经济利益，我们测试时必然会对性能测试或安全测试放到第一位，设计较多的异常测试用例，这样一做，必然增加我们的工作量。如果是一般的系统，我们可以只执行一般的功能测试通过就可以了，没有必要去做其他的异常、安全测试。如果系统的质量需求要求高，也许就要进行更深层次的测试，回归测试的力度必然要加大，工作量自然就上去了。
b）尽可能详细的罗列出项目测试内容：
一般来说，测试工作量的评估工作都是交给测试经理或项目组成员协助共同来完成的。准确评估项目测试的工作量，必须要求测试Leader明确详细的测试内容，只有知道测试什么？哪些需要测试？详细分析需求规格说明书，明确测试任务以后，评估才会有依据，所以
尽可能详细的罗列出项目测试内容非常必要。
c）把测试任务细化到每个测试功能点：
我们在估算测试时间的时候，可以把测试任务细化到每个测试的功能点，比如说“新增”、“修改”、“删除”、“暂停”、“恢复”等等都记成一个功能点，在预算的时候，同时把编写测试用例和执行测试用例的时间都要计算进去。例如：编写一个测试用例或执行一个功能测试各需要一个小时，如果我们有100个功能点，我们就知道大约要200个小时。这样估算出来的时间比较精确一点，比较符合实际。
d）预估业务测试或模块交叉测试的`复杂容易程度：
很多时候，我们测试初期，对业务了解不是很多，忽视了对业务方面或交叉模块测试的评估，等到了测试后期，大量的业务测试没有测试，测试时间特别紧，所以在测试初期预估测试的复杂容易程度，在评估工作量方面至关重要。
3. 根据开发阶段来评估工作量：
不同的开发阶段，测试时间估算也不太相同。比如说，开发的系统是第一个版本，相对以后的测试工作来说，可能安排的时间要多一点。大多数情况下是这样的，也许后面的版本增加很多新功能，测试工作量还大于第一个版本也是常有的事情。作为测试负责人，对于使用测试阶段来评估工作量，必须根据实际情况来定，不能盲目给出数字，应付了事。
4. 根据测试经验的积累来评估工作量：
我们可以借鉴类似项目的测试经验，比如说被测试的系统，我们做过类似的产品，就可以把相关的测试文档，修改一下，复用以前的测试用例，这时候测试工作量就减少了很多。如果没有，我们只能重来。还有就是借鉴以前项目编写测试用例或执行测试的时间，对测试工作量的准确评估，也具有一定的参考价值。
5. 根据测试风险来评估工作量：
a）测试人员变动带来的风险：
在一般的软件公司，测试人员的流动是常有的事情，所以估计测试工作量的时候，我们一定要把它计算在里面，留有一定的余地，以防不测。比如说：以前安排了一个做过类似项目，对类似项目熟悉的测试人员，也许给他安排了一天的工作量。如果他不在了，其它的人去做这个测试也许就2天，甚至3、5天都不一定能够搞定。测试人员带了的风险还是特别高的。
b）系统测试环境的风险：
系统测试环境带来的风险，一般来说比较小，发生的可能性很小，如果一旦发生了，也相当可怕。最可怕的就是硬件故障，在经济实力允许的情况下，我们一般的方法是准备两套测试环境，一套测试环境出现问题，我们立马切换到另外一个测试环境中去继续测试，避免影响正常的测试进度。但是大部分的公司都不愿意花血本，来购买昂贵的硬件，而是以牺牲时间来付出代价。
c）、开发人员版本发布延迟风险：
不做好版本配置管理或没有正规的测试规范的公司，大部分情况下很难估计工作量，他们基本上都是边改边开发边测试，如果一旦开发出现异常，整个测试就立马终止，这对测试的相互制约作用也会更大，这样对我们估算的工作量也不准确。
d）、项目变更带了的风险：
一个项目做到中途，由于客户对技术不断深入的了解，很多时候不是“需求变更”，就是“设计变更”，弄得我们测试人员特别郁闷，不断修改测试文档。如果相关部门没有正规的变更管理，变更引起的工作量更没办法估算。很多测试后期出现工作量加大，测试延期的问题，都是对项目风险估算不足造成的。
【员工工作量评估】相关文章：
1.员工工作量考核
2.员工工作评估
3.教师工作量
5.员工工作能力评估
7.工作量统计报表
8.初中教师工作量