今天被Leader要求，需要给出当前部门研发的生产力评估。
其实这个算是一个老大难问题，毕竟研发工作量一直以来都是一个比较头疼的问题。无论是代码行数还是功能，都不能以一个较为客观的方法进行评估和计算。而当前公司处于所谓的“正规化”过程，这个需求倒也是合情合理。
Leader给出的作法如下：
以`工作量`和`工作难度`为维度，分别进行评分，然后以这两者的乘积作为每个任务/需求的工作量。部门整体工作量以所有工作的累积为准。
这套方法的优点很明显：
- 非常符合直觉；
- 部门负责人可以快速评估与决策，响应时间较短。
这种做法我是旗帜鲜明的反对。主要是有这么几点是无法克服的：
-
工作量和工作难度是一个非常主观的概念，无法量化。两个主观的数据相乘，最有可能的结果就是偏差更大； - 这种评估方法，将部门经理/主管拉到了一个非常重要的位置。所有的工作评估就成了领导一个人的事情，而团队成员参与度直线降低，最后成为单纯的coding工具；
- 虽然算法中没有明确提到，但是有一个隐藏的参数，就是
工作基准。所谓工作基准，就是理想中的工作能力，假设为1.0。但每个人不可能都保持1.0，甚至团队平均值也不可能是1.0，在这种情况下，计算所需工作时长就不得不考虑这种隐藏值，否则时间偏差非常大； - 过分的关注每个人，而不是团队最终交付，非常容易走向KPI那一套，对团队合作有着极大的影响；
- 部门负责人（也就是负责评估的人）权限过大，只手遮天的可能性很大。
我个人的建议是：
采用敏捷的作法，以Story Point的形式，让`团队`来估算每个任务/需求的工作量，然后通过3~4个迭代，获取当前团队每个迭代周期内能处理的最大故事点数。
这种作法的好处是：
- 团队全员参与，投入度更高，更容易引起每个团队成员的责任感；
- 指标比较简单，只有一个用户故事点数作为评估值；
- 以“团队成果”为目的，引导团队成员向着共同目标前进。
缺点也同样比较明显：
- User Story Point是一个团队自定义的参数，前期需要有一个定义的过程；
- 需求工作量评审耗时较长，且全员参与——这点在我看来不是问题，在某些领导看来，程序员不Coding就是不务正业；
- 用户故事点不能拿来跨团队对比——当然，这也是某些领导的想法。
最后说一下结果，结果是Leader直接跟我说，要我用他的方法，我也是内心不爽，满口答应。
Leader的原因比较简单，就是“当前团队不能做敏捷那套”。
所以这最后我再说几点吧：
- “不符合现状”是一个非常通用的理由，最可怕的是，你根本无法拿出任何反驳意见，毕竟“现状”是一个很模糊的概念；
- 敏捷在很大程度上，其实是一种
反直觉的。下午的时候，另一个同事和我说了这样子的话“引入多个维度，可以更准确”。对此我只想说，在不同维度上的两组数据，以乘积的方式得到的结果，怎么可能减小误差？ - 其实Leader在找你的时候，心中就已经有定见了。所谓
说一下你的看法更大程度上可以翻译成说一下你的观点来佐证我的观点； - 变革的来源还真的不一定是压力，有时候为了生存，不排除会采取最稳妥的方式来工作，变革只有在更高层认知完备的情况下，才可以很好的开展。自下而上的变革是很难，甚至是不可能的事情；
- 敏捷是好东西，但是认识并承认的人太少，很多人还是会凭借自身的经验来对新事物进行判断，而不是深入使用来判断。
## ****额外的话
研发生产力，其实是一个非常虚的概念。
研发是一种很辛苦的脑力劳动，与写作、音乐创作其实是同一类型的工作。但是我从来没有看到有人对音乐家或者作家说，你们什么时候一定要把什么什么巨作完成。
为什么呢？
我觉得可能是因为他们自认为不懂音乐和写作，却认为自己能看懂研发。
看懂五线谱，看懂作者的伏笔的确是一个很困难的工作，但这个App我会用啊，这个Web我用的很熟练啊。你不就是改个字体，不就是加一个支付方式，不就是XXX。
很多人完全搞混了会用和会创造这两个概念。
但现在国内，尤其是一些中小型企业，还是很古老的管理方式，他们希望一切的生产成果都可以以一个明确的算法或者数值表现出来，然后需要你一直能保持在这个数值，而不会考虑其他，比如需求合理性、人员状态以及开发难度等。他们所需要的，也就是一个答案“你能干多少活？”这个活是无差别的，无论你是写一个Hello World还是开发可回收的二级火箭，都是一样的。更有甚者，会一句“这个有那么难”。于是就在这个过程中，研发发现自己开始逐渐被数据化，最终成为了一个coding工具，仅此而已。
但！真的是如此么？
一行代码不能解决问题么？一定要100行代码才行？殊涂同归，在研发中并不少见，同样的功能，可以通过不同的实现方法，那么不同的方式之间该如何比较，如何说出好与坏？
这些，恐怕那些认为懂研发的人，完全没有思考过吧？
研发并不苦，相反我知道很多研发还是乐在其中；苦的，是某些对研发的管理方法和态度。
