这是一个创建于 4123 天前的主题，其中的信息可能已经有所发展或是发生改变。
在我离开我的上一家雇主的之前，公司开始试着推行 BUG 率与 KPI 挂钩。人在面对权威的时候总是会忍不住怀疑自己的判断是不是因为见识短浅，后来经过慎重的考虑，我最终确认这是一件极其傻逼的事情。
之所以这样说是因为对于一个团队而言，我想不出什么东西比目标一致更重要了。当测试跟开发开始为了孩子的奶粉钱，自己的团队成员相互扯皮的时候，能维系这个团队的实际上就只剩下那点工资了。
如果说非要给员工加一个 KPI 这道金箍的话，那就只能是产品本身。一个项目团队所有成员，无论角色，都应该是同样的考核内容，不然必然会导致利益冲突。而对于一个做产品的团队来说，还有什么比做出一个好产品更适合作为考核标准的呢？
“真理往往都是废话”，这话精辟的跟二十几个国家领导人说过一样。
这么个浅显到当众说出来都怕被人扔烂西红柿的道理，摊子大了就不容易看透了。火星妹子横看竖看地球都是圆的，可你我身在其中，就是觉得天圆地方。工程师理直气壮的玩架构，测试大姐理直气壮的要求充分回归，设计 MM 理直气壮的要求像素级还原。最终，我们大家理直气壮的做出了一个烂产品。
之前我总是喜欢问一个问题：为什么要这么做？
有次把跟我搭伙的工程师哥们问火了，说你管那么多干嘛？产品让这么做就这么做呗！
其实这也难怪，每天问二十几遍为什么除了让产品恼火外对自己一点好处也没有，反倒有可能在需求方评价的时候荣获一枚恶评。当然，各方大佬开会的时候总是嚷嚷着，“鼓励大家质疑，鼓励大家讨论，对事不对人嘛！”。你若仔细想想，就知道这话还没男人骗女人上床前的海誓山盟靠谱。缺乏制度上的激励，一面喊口号，一面又以另一套考核标准来要求员工，这种挂羊头卖狗肉的事情你我除了阳奉阴违外就只能... 大家都是混口饭吃嘛，女人何苦为难女人。
程序员，实际上团队里的任何一个角色，从运营到设计，都理应保持对产品的质疑。这不单单是一个弥补产品有可能的设计缺陷的契机，更大的意义在于尽量避免语言沟通的非精确性带来的产品理解上的误差。
我一直坚持认为，判断一个程序员是否优秀的标准只有一个，那就是是否做出了优秀的产品。是的，对于产品的关注决不应该只是产品经理的事情，而应该是整个团队成员的共同目标。这并非是说关注产品就是忽视单纯的技术创新，但在一个实时通信项目组里，一个把精力倾注在新一代数据库上的架构师显然称不上一个优秀的项目成员。
这就像种菜一样，菜种不好，锄头磨的再闪亮，菜籽码放的再整齐，又有什么价值呢？
EOF
F2E前端社区接受各位程序猿投稿。本文特别感谢黄笑宜（微博@黄笑宜）供稿，期待各位贡献更多的好文章，或心得、或闲聊、或技术，能带来思考和共鸣就是价值。
欢迎关注F2E社区公共帐号：
 |
1
iscraft 2013-08-13 15:42:00 +08:00
菜有市场就行.锄头牛逼不牛逼无所谓.种不好菜的农夫就不是好菜农?!你也有主动权.
|
 |
2
buru 2013-08-13 15:59:42 +08:00
什么样的激励制度可以让员工都关注产品，多提质疑呢？而不是产品经理说什么，员工就做什么。
提建议被采纳有奖金？还是？ |
 |
3
xunyu 2013-08-14 16:39:54 +08:00
意见太多对产品不一定是好事，还要看领导的判断力和团队的执行力
|
 |
4
fox 2013-08-14 17:13:09 +08:00
一看标题还以为是说我英语单词狗的……
|
 |
5
Epsil0n9 2013-08-14 20:32:59 +08:00
国内讲究“维稳”，注重表面上的“没问题”；员工"shut up",领导就是对的。
在这种氛围下，其实很多人根本就不会在意产品是否会真的好。 只要让上头满意就行，能稳定拿工资。提建议不但有背锅风险，还可能会让负责人不爽。 |
 |
6
gladiator 2013-08-14 21:10:13 +08:00
BUG 率与 KPI 挂钩 这tmd纯粹是做表面工程，根本就是把下面的人当码农看待
|
Select Language