软件开发评估工作量 软件开发评估工作量是多一点好还是少一点好
大家好，今天小编关注到一个比较有意思的话题，就是关于软件开发评估工作量的问题，于是小编就整理了1个相关介绍软件开发评估工作量的解答，让我们一起看看吧。
如何评价领导要用代码行数衡量每个人的工作量？
创造性的思维很难定义工作量，思维的跨越也不是面上能看到的。我不知道你的具体工作内容，普通的思维架构自然是能参照数量的，但你看微信那是时间的问题吗？是积累逼进的思维跨越。
你们领导不懂专业还是不懂思维？脑力劳动确实不能以数量为标准来参照工作量，这也是我说绩效管理对注重教育和思维的工作没有用处的原因。这种操作很容易陷入体制僵化和创新思维的困境。
有些领导之所以要求代码行数，大概有几个可能：
- 出于所谓“量化考核”的要求，没办法。现在很多公司都讲绩效讲量化，而程序员这种工作可以量化的部分甚少，除了代码行数就是坐班时间，用哪个指标做量化？再就是很多这样的考核标准并非技术领导制定，而可能是行政或者人事部门制定的，多理解吧。
- 有些领导可能认为基层程序员做的都是些不怎么需要“创意”的工作，大致跟体力活差不多，所以如果搬砖可以计件，那写代码大概也可以“计件”吧，也许在他看起来代码行数就等于砖头块数吧。当然，也有些领导认为所有程序员的工作都等同搬砖，那就全员都得数行数了。
- 为了某些其他任务的要求，比如有的项目里的评审专家或者甲方专家要求统计代码行数，这时候通常领导会先统计个大致行数，然后按照一定比较比例注水（或者叫做适当调整）后上报。有些时候则是为了填表需要，有些公司不知道哪里弄来的一些管理表格，要是有行数这一栏空着也不行，领导也难啊。
- 有的中层领导可能不懂技术或者不懂技术管理，想当然地或者从别人那里讨教来这么一套管理办法，至于有没有用这个就各有见地了。说白了，中层领导在上级领导面前，总要想办法表示自己做了很多很多工作，多刷存在感，有时候明知代码行数不说明什么问题，但几十万行的数字往那儿一摆，谁也不方便说啥不是，还是那句话，多理解吧。
至于这种管理方式有没有用，这个说起来也有点复杂，不能简单的说是有用或者无用，但当年我做程序员时是很讨厌数行数和写工作日志的。
我认为用代码行数来衡量程序员的工作量，说明领导根本不懂技术，外行指导内行。
如果要用代码的行数来判定我的绩效，那我有很多种办法获得“优秀”：
在不影响代码正确性的前提下，多换行；方法参数有几个，都可以换几行；
每个方法，都写上几十行的注释，循循善诱，娓娓道来；
多写无用的类和方法，其中包含大量的代码，但是没有其他地方调用它们；
终极大法，把第三方框架的源码拿出来引入到项目中，分分钟几万行代码。
可以说，代码行数不能作为衡量程序员工作好坏的标准，一个大神程序员可能花费大量的时间在思考和设计，之后写出寥寥数十行代码，达到的效果比一个程序员几百上千代码好的多。如果非要用代码行数作为考核标准，程序员为了增加代码数量而忽视质量，废代码增多，弊大于利。
绩效考核是企业对每一个部门和员工工作数量与质量的一种评估。各种工作岗位都有其特殊性，考核工作必须对各项工作都建立适用的量化标准。
从程序员的工作特性看，生产代码行数是考核他们工作最适合的量化标准。虽然这个标准还不足以考量每个程序员的工作质量，但程序员的工作质量并不是他们自己可以控制的，他们只能保证自己输入的代码是严格按照架构师制定的语句原则和变量算法原则输入的，而在输入时保证没有输入错误，起码要保证在关键语句输入时不出错。只要能做到这些，程序员代码输入量达到规定的行数或超额，就可以判定其绩效考核成绩合格或优秀。
绩效考核工作最大的难度就是岗位量化原则的制定，有些岗位是无法用工作量来进行考核的，比如公关部门。对于这样的部门只能通过在考核周期内，计算其目标工作任务的完好程度比，比例高于预定的值则为合格，低于这个值则为不合格或较差。
绩效考核工作是对HR部门的挑战，很多公司就是因为制定标准出了问题，而使绩效考核工作流于形式，这是非常危险的一种现象。这将严重影响整个公司的工作效率，甚至严重削弱公司的核心竞争力，因为核心竞争力除了品牌固有的市场引导力和辨识度外，还包括企业文化战略和人力资源战略的有效性！
到此，以上就是小编对于软件开发评估工作量的问题就介绍到这了，希望介绍关于软件开发评估工作量的1点解答对大家有用。