菜种不好，锄头再牛逼也不是好农夫

在我离开我的上一家雇主的之前，公司开始试着推行 BUG 率与 KPI 挂钩。人在面对权威的时候总是会忍不住怀疑自己的判断是不是因为见识短浅，后来经过慎重的考虑，我最终确认这是一件极其傻逼的事情。

之所以这样说是因为对于一个团队而言，我想不出什么东西比目标一致更重要了。当测试跟开发开始为了孩子的奶粉钱，自己的团队成员相互扯皮的时候，能维系这个团队的实际上就只剩下那点工资了。

如果说非要给员工加一个 KPI 这道金箍的话，那就只能是产品本身。一个项目团队所有成员，无论角色，都应该是同样的考核内容，不然必然会导致利益冲突。而对于一个做产品的团队来说，还有什么比做出一个好产品更适合作为考核标准的呢？

“真理往往都是废话”，这话精辟的跟二十几个国家领导人说过一样。

这么个浅显到当众说出来都怕被人扔烂西红柿的道理，摊子大了就不容易看透了。火星妹子横看竖看地球都是圆的，可你我身在其中，就是觉得天圆地方。工程师理直气壮的玩架构，测试大姐理直气壮的要求充分回归，设计 MM 理直气壮的要求像素级还原。最终，我们大家理直气壮的做出了一个烂产品。

之前我总是喜欢问一个问题：为什么要这么做？

有次把跟我搭伙的工程师哥们问火了，说你管那么多干嘛？产品让这么做就这么做呗！

其实这也难怪，每天问二十几遍为什么除了让产品恼火外对自己一点好处也没有，反倒有可能在需求方评价的时候荣获一枚恶评。当然，各方大佬开会的时候总是嚷嚷着，“鼓励大家质疑，鼓励大家讨论，对事不对人嘛！”。你若仔细想想，就知道这话还没男人骗女人上床前的海誓山盟靠谱。缺乏制度上的激励，一面喊口号，一面又以另一套考核标准来要求员工，这种挂羊头卖狗肉的事情你我除了阳奉阴违外就只能... 大家都是混口饭吃嘛，女人何苦为难女人。

程序员，实际上团队里的任何一个角色，从运营到设计，都理应保持对产品的质疑。这不单单是一个弥补产品有可能的设计缺陷的契机，更大的意义在于尽量避免语言沟通的非精确性带来的产品理解上的误差。

我一直坚持认为，判断一个程序员是否优秀的标准只有一个，那就是是否做出了优秀的产品。是的，对于产品的关注决不应该只是产品经理的事情，而应该是整个团队成员的共同目标。这并非是说关注产品就是忽视单纯的技术创新，但在一个实时通信项目组里，一个把精力倾注在新一代数据库上的架构师显然称不上一个优秀的项目成员。

这就像种菜一样，菜种不好，锄头磨的再闪亮，菜籽码放的再整齐，又有什么价值呢？

EOF

F2E前端社区接受各位程序猿投稿。本文特别感谢黄笑宜（微博@黄笑宜）供稿，期待各位贡献更多的好文章，或心得、或闲聊、或技术，能带来思考和共鸣就是价值。

欢迎关注F2E社区公共帐号：