百度公司的产品程序员的年终考核
发布网友
共3个回答
热心网友
我认为绩效考核对程序员或者对整个公司都是重中之重，但是对程序员怎么绩效考核？难道看敲得代码数量吗？绩效考核的先决条件是工作可测量。
从这个角度讲，有两种方式可以综合使用：
1.代码量。
每天下班进行工作提交时，统计今日修改，新增的代码行数，业界基本水平大约是200行。
2.进行任务细化分割和管理。
MantisBT可以实现这个功能。开发的整个流程，都可以在mantis上加以体现。分析人员逐级分割任务，并将最终可实现的子任务分割给程序员，程序员可以通过统计其任务完成量来估算其工作量。其实，我觉得BOSS的焦虑在于无法“可视化”的观察项目的进度，这个任务可以通过使用MantisBT，合理设置里程碑来实现。当BOSS看到里程碑相关的任务完成度不断上升的时候，他的焦虑感就会显著降低了。
我的经验中主要是这么几个方面：
1. 质量。
这里的质量指交付物契合需求的程度或按需求交付的准确程度，具体来说就是从理解需求开始到最后产出的交付物过程中的沟通、理解、设计、实现、验证的总体质量，这个质量可以最后以“Bug密度”这一度量项衡量，对于一般的程序员来说主要是代码质量。
2. 沟通和团队协作。
和项目团队各个角色之间的沟通以及协作意愿和能力。软件开发基于个体能力但绝不止于个体能力，尤其是现在复杂的功能软件，都需要通过多角色合作分工完成，这里个体关注项目和团队整体目标的大局观和价值观是很重要的项目成功保障。
如果你做到了上面这些, 好恭喜你,你们公司非常正规了,如果这个程序猿工作不努力,干活不认真,产出效率低,那么问题一定不是处在程序猿身上,而是HR工作有问题.
热心网友
我干过这事儿，来抛砖引玉吧。
第一是要想保持团队士气不因为死板的绩效考核让自己和团队里的人陷入难堪的境地，我提高了招聘的标准。
实际团队的成员水平是有层次的，初中高都应该有，有一段时间因为项目的关系，也招过不太满意的人，虽然是极少数，但还是觉得这个成本太大，找一个不像样的进来跟自己扯淡然后利用制度来开掉他，不如找一个标准高的，然后狠狠奖励他。
我见过这样的公司，招聘放水，不对全局负责，看重短期性价比，结果成为中层的一块心病，把他们推向管理的下限，做过面试官的都知道;
在程序员这个行业，平庸的人数都数不过来，标准稍微一降的结果，是任何绩效考核都应付不过来的。
第二是强调个体责任，减少项目调度尽量让每个程序员有一块自己的领域，是某一个业务或者技术部分的专家，比如A做mobile端的开发，就会尽量让他把mobile+app做过瘾了为止，
没有特殊情况，不轻易他随机调到别的部分。如果每个人的中长期权责是清楚的，那么绩效考核也会是清楚的;
每个人能说出自己工作的纵向成果，比如A前六个月对mobile+app完成了关键性的重构，使用了更新更快的技术，核心代码的效率有了大幅提升，用户体验有明显改善。
这些东西他不说你也知道，因为分工的明确，你自己也很好跟踪，peer之间也对对方干了什么取得了什么成果十分清楚，这样就为考核系统的透明化提供了基础，透明意味着公平与效率。
总结：
互联网中的程序员是一个公司的重心，而怎么去考核他们又成为了一个大点，希望这些可以给到你一定帮助
热心网友
关于程序员的绩效考核问题，相信是很多软件公司致力追求却一直无法做到量化的目标。很多考核标准都只是一个框架，但却无法具体细致下去，从而引发了很多劳资方面的纠纷，到最后都是无果而终，无法坚持下去。但还是有很多人，特别是不懂得技术之人，乐此不疲，希望以此种方法来作为程序员报酬的衡量标准。
最突出的就是“任务量”问题。软件编程行业的任务，懂点编程的人都知道，这个行业是一个创造性、思维性的行业。一个任务的工作量多与少是没有一个衡量标准的，原因就是软件功能的实现结果，根本就没有一个最好的标准。
有的人就以工作时数来进行衡量。真的可以吗？举个例子：相同的任务且相同实力的程序员，有的程序员花了一天就完成。也有的程序员花了两天完成，还有的花了三天，四天，五天完成的。花一天完成的程序员做了功能上的实现，它是完成的，针对绩效考核来说，是满分的。但是，比他花多得多时间的程序员呢？他们除了花在功能实现上，还花了很多时间在代码优化以及界面操作设计上。那么，从绩效考核来讲，也仅仅是满分。花一天与花几天的程序员的工作量真的可以相等吗？谁都知道不可能的。再打个比方，两个工作任务，有可能在任务量上它真的就一样。但是，在任务安排上，一个项目组由于技术力量及时间*上较为宽裕，在一个月内宽松地完成了，而另一个项目组由于在人力资 源以及时间*上，加班加点，用了十天就完成。以此相比，是哪个项目组的任务量更大一点呢？
所以，绩效考核的框架是死的，而程序员的任务是活的，用一个死的框架套住一个活的思想，程序员只为绩效的要求而实现，久而久之，一个软件项目根本就毫无创造性可言，就是一个生产线生产出来的一个标准化产品而已。
所以，我觉得，程序员的生产，就是个研发，而研发就是创造，不是生产工具，不能以简简单单的任务量来衡量，更不能成为技术层面之外的人简简单单的薪酬衡量标准。用简单思想框架来束缚程序员的思维创造性，这是拖累研究，极易打击程序员的研究主动性。
但真正没有办法为程序员计算劳动所得吗？我觉得， 既然，程序员的工作是研发创造性的，那么，程序员就应当有个感性的前提，那就是视自身的劳功项目体现出的市场价值作为其劳动所得的标准。所以，我觉得，在这方面上，项目奖比起冷冰冰的绩效考核温暖得多，它直接反映的是程序员的创造性结果。在项目组内部的评比，则需要靠他们的直接带领人来衡量贡献的突出性，一是针对项目的技术贡献以及任务完成的质量贡献。
