从Object Setting到Performance Review
by Robin Lu on Mar.16, 2006, about management
在三个不同的外企呆了一共快六年的时间，有一个共同点就是每年年初都要做Object Setting，年终要做Performance Review。不知道是这个做法本身有问题还是在中国没执行好，每年到这个时候面对一堆的表格我不知道要添什么，也不知道别人想要我添什么。其实说来简单，Object Setting无非是定一个目标，为这个目标制定一个计划，最后给一个衡量标准，怎么才算目标达到。Performance Review的时候就拿出你当年添的东西一一对照，哪达到了哪没达到。就象自己先下个套，然后钻。怎么看怎么别扭的一个过程。至今我仍然搞不清楚作为一个程序员该如何设定目标，我曾经这样制定过：我的代码（包括bug fix和新feature）产生的P1的bug不超过xxx个，P2不超过xxx个。第二年，为了表示进步，我需要这样制定：P1 bug减少5%，P2 bug减少10%。听上去和扯淡差不多。或者写今年我要做三个features，修100个bugs。更离谱。目标定高了是和自己过不去，定低了是和老板过不去，定实了到年终全变样，定虚了又没法衡量。大多外企的现状也使得Performance Review的作用落不到实处，高了不会升你低了不会抄你。每年两次轰轰烈烈运动的主要作用就是浪费时间。如果还有什么比着更无聊的，可能就是再加一个中期review了。
March 17th, 2006 on 5:06 pm
哈哈，没办法，现在外企这样，外商投资的国内企业也这样了，形式主义大家都很烦，但最上面的人是要通过这个来检查工作，他们不可能去看我们工作的每个细节，工作时间是多少，结果对他们最重要，同情你老兄:-) 更支持你！
March 17th, 2006 on 10:27 pm
有同感，不过现在到哪儿都这样，跟外企不外企没什么太大关系
March 18th, 2006 on 11:59 pm
是，不光外企这样。很多想学习先进经验的国内公司也这样，不过变成了一个“陷阱”经验
March 19th, 2006 on 5:25 am
量化工作也是职业化的一种吧。尽管我个人对此并无赞同或者反对。不过如果特别是说程序员做Object Setting，我有一点经验，不知道有用没有：最重要的当然是需要完成的项目。每个项目都会有roadmap吧？roadmap上的milestone就可以作为一个时间上比较靠谱的参考。然后开发时候，陆续把所有的任务都敲碎放到bugzilla里去。到项目结束/年度结束，考察工作其实就是review bugzilla。再不懂技术的老板，看到通过解决的所有的可预见的问题和中途修改好的bug报表（所以要用bugzilla，因为它能自动生成报表），也都会对一年的工作有数了。至于说performance，这个东西应该是相对的，而且最好是这一年度的bug报表对于上一年度的比较。说真的，这东西确实没有什么实际用处，谁会因为多写了一年程序就真的提高了多少performance，这种循序渐进的东西确实无法量化。
对目标的制定也许会很让人迷惑，我的不一定有用的经验就是写的越具体越好。百分比应该用在对项目完成度的衡量上。但是如果有百分比，就一定指出来那些没有包括进来的百分比是留在下一年了，还是有团队的其它人来完成。这对于项目管理者来说也会有帮助的。
定期review工作的好处是，可以及时发现blocking bug，并且对此做出相应的调整。但是管理者不见得能够实践后一条，这可能也不说明review工作真的没有用，只是管理者本身执行得不够好。
都是比较机械化的经验，不过我个人觉得机械化的基础工作可以维持工作热情，这也是为什么有很多老程序员能够一直在这个行业里坚持。而尚年轻的时候却总觉得有时候仿佛即将失去耐心。
都是个人浅薄经验。有感而发。其实刚才仔细一看，还有一句”定实了到年底全变样”，这可能才是问题关键吧。不过这恐怕和管理者的决心有很大关系。不多嘴了。