管人管项目 - 绩效考核 ¶
作者：KK
发表日期：2016.9.17
- 提示：在这方面我很水，只是目前的个人水平，有更好的意见期望多交流！
介绍 ¶
如果你是新手不清楚什么是绩效考核，那我这里简单说说，表现形式主要为：公司制定一些工作条规要求团队按要求执行，如果执行不到位就扣分，扣分越多则受到越大的惩罚，最典型的就是发工资时会少发一些（从绩效工资里扣除）
通常都要执行 ¶
很简单的一个道理：你生活中，我生活中接触到的朋友、同学、同事并非个个都是优秀的热情工作者，在没有监督机制的情况下放任员工会造成员工的惰性，随之而来的就是工作质量差，效率低，态度不端正等问题
所以通常一个团队里都应该执行监督机制来让员工觉得“糟糕，这件事如果做不好，会受到惩罚的”，而大部分企业都通过绩效考核扣绩效工资的方式来督促员工“希望你干活给力点！”
到手的钱会变少，大家都不愿意，所以通常就会乖乖地按规则去办事，按时完成，按质量管理条规来把任务的各方面质量做好
具体如何设定这个监督机制呢？ ¶
（KPI……KPI……我知道KPI……不过目前没啥兴趣，负面新闻听得多，我也没技术运用KPI考核，所以本文不谈KPI）
我相信一个道理：任何事物都是相对的，不是绝对的，如果一个团队有必要成立监督机制，则这个机制也不是既定的“客观机制”，要针对团队而言
只不过大部分5~20人的团队属于A类情况，20~50人的团队属于B类情况，还有C、D什么的（随便说说），将这些人群归成各大类后再找到这类人群适用的方法，而不是直接瞎套一个别人公司的方案。有时候还要根据自己团队或小组的情况修订
所以总体来说，监督机制的规则设计变得难以固定，虽然很多团队大同，但又很多“小异”
我的思路 ¶
由于我一直管理过的员工在10人以内，并且这10人都是基层，下面没有再细分了，所以要搞绩效管理对我而言其实是变得相对简单了很多
定位问题所在 ¶
我只能以IT开发人员为例，把他们大部分犯的问题整理出来有这些：
无法按时完成开发任务虽然各行业都会有这个问题，但在软件工程中肯定相较于在部分行业出现得频繁，因为看似简单的功能评估了1天但其实有风险会遇到坑点，所以会拖到2天过3天不等
而作为基层员工，肯定不是个个都是干活行云流水的熟手，为了控制成本，肯定大部分是招了0~3年经验的初级工程师，则他们经验不足时，对工作的把控能力就较差，预测不到一些潜在的问题，而碰到时又花很多时间去调试，这就是造成任务超时的原因（实际上开发时最经常做的事情就是调试，调错）
代码质量不好代码质量问题太抽象，纵然有好一部分代码是很客观存在的质量问题，你一说，他也觉得不对就去改
可有的问题也只是你认为是个问题，而程序员又有自己的一套理论
好了且不说谁对谁错，最后反正就是：他的产出物让你觉得质量不达标
相关代码和程序欠缺说明文档和适当的注释我做了3年管理后才深刻体会到：大部分程序员真的是很讨厌写文档的（但我既不喜欢，也不讨厌，该写就会去写）
由于程序员讨厌写文档，你不要求他肯定不去写，你有时候要求了他也不大愿意去写，最后写出来的质量就是潦草的一篇东西，让人感觉写了大部分内容等于没写
至于代码里的注释就更加难以监督，除非所有管辖的程序员提交的代码都看一遍，还要看看代码的逻辑想干什么，有没有必要写注释，这其实是不现实的（至少我没有足够精力查看所有程序员当天提交的所有代码的工作细节，再评估是否要注释）
而当你觉得要写注释时他又说“这很明显就是XXX啊哪要写注释呢”，好了你是老大，最后他服从去写吧，只是这样勉强大家都不幸福而已
所负责的程序对其它部分造成了影响，使之难以运作这就像是修改地基后，上层的各种建筑都会受到影响一样。所以修改底层的东西，要多考虑对上层及其它相关内容的影响性考虑，这种考虑依赖于员工的经验，经验越多，考虑得就越多，执行方案就越成熟
好了其实一个程序员的工作消除了以上4大问题的话，其实也没什么好说他的了，只是往往就是这4种问题“比较难以避免”，我为什么要加个双引号呢？————其实很简单，在一定程度上，我们都能去避免的，但只是大部分人都没有好好地去避免，就造成了一种“这样很难搞的，很难实现的”印象，其实天下无难事
只怕有心人 ¶
我认为只要用心，尽管事情得不到完美的解决，但很大程度上都能解决
无法按时完成开发任务用最简单暴力绩效条规：不完成扣N分
扣了分就有损失，他不想，于是就会想办法完成了
执行过程遇到的问题
原定A任务，评估2天完成，开始做，但做了不到1天就突然来了个B任务也要2天后完成，挤占了时间后最终有一个任务无法完成
分析：如果A任务要占满2天的工作时间，则加了B任务肯定是无法完成A任务的，所以要么B任务往后排期，要么两个任务同时延长评估时间。
但尽可能不要在加了工作量，时间客观不足的情况下还要坚持对A任务作考核：不完成继续扣分
这道理上不合理，员工也不接受，所以有新的工作任务干预原计划时，要考虑原计划的周期如何延长或调整；比如B任务优先，则A任务推后，那就要相应地修改A任务的考核时间点
任务原来评估2天完成，但遇到技术障碍或深坑，还难以预料要多久才能解决
分析：员工应该及时向上级提出问题，自己评估一下需要延长的任务时间，再结合上级的评估，上级最终决定一个延长时间
尽管有些事情看上去“根本不可预料要多久”，但最终我认为不在于评估的时间是否合理，重点在于“大家做了这件事”，这是工作文化的一环，如果这个时间内不能完成，再重新评估就是了，“一次性评估”为无限期延长，不如“分期评估”，这最终效果也是无限期（可能），但体现出来的是：员工会感受到压力，这个时间内继续争取完成。而不是他知道无限期延长了，做得不急不慢的
代码质量不好我会在工作管理规章上附加一份代码规范声明，这是书写上的规范，并且执行代码审核工作，审核到违反代码规范的就要罚抄1~5次不等，效果就是：大家抄过后都不用再抄了，因为抄写过程让他感觉深刻，有印象，不再犯了。（只有一个员工抄过2次）
通过罚抄来改进代码规范问题，既可以避免扣钱的尴尬，又能让员工印象深刻，这是我探索到的方法，并4年来一直如此执行
- 实施注意点：你说他违反了规范，是哪个规范，最好有明文规定，所以就是我说的工作管理规章上的规范声明，要罚人家抄的东西最好都能在规范上注明，有依据，并在入职时引导阅读，以后注意复习
以上也只是解决了代码的书写规范问题，还要再附加一份代码设计约束，约束一些常见的程序应该如何设计，但这是有缺点的：这样就约束了大家要如何写代码，大家就没有了自己的发挥余地
相关代码和程序欠缺说明文档和适当的注释把平时经常开发的程序归类，逐个建立文档样例，让大家能有个参考去写，这样起码把这些基本的内容写了出来，好过他自由发挥导致一些关键需要的内容却没有
注释方面要靠人工审核，但不能太苛刻，首先从变量命名上要合理，不能随意简写，否则最终只会导致新员工上手旧项目维护麻烦
使用UML制作业务关系、扩扑图等让员工对应用结构一目了然，这样其实能省下很多代码阅读工作
所负责的程序对其它部分造成了影响，使之难以运作落实单元测试开发，使用持续集成平台每天自动发现问题
再狠一点就把验收测试也做了，这样更好，如果企图节约测试开发工程师的成本，那这个成本最终会转嫁到员工手动测试的时间浪费上和BUG风险对项目的商业价值影响问题上，而且这个成本代价最后也会越来越大，比开发工程师的成本更大
还没写完 ¶
监督机制的设定我觉得真是一个技术活！甚至有时候觉得不设定直接用主观判断就是最好的设定！可是那样没理没据的话大家有时候会感觉不公平，也会吐槽公司这种管理不好
我还没完完整整地梳理出所有内容和思路，本文章还没写完……
哎还别忘了，这方面那些人事、HR、MBR高才生通常都有更多专业知识，多听课啊~别凭着自己一个技术出身的状态下只管自己摸索自己的也不取取经！因为这个事做好做不好对团队发展的影响挺重要的！