不见可欲

有一位同事和我讨论一个问题，提到作为产品的负责人，想要提高整个产品的开发水平， 应该怎么办。她说她看了我关于《道德经》的描述，理解了无为，求名失道的概念，但知 道概念是知道概念，但总不能干坐着吧，现在整个产品的开发人员开发水平（至少她认为 ）确实也不行啊，那怎么办呢？

《道德经》是个逻辑性很强的论文，从逻辑上来说，开发团队的水平不行，靠产品经理本 身去改变它，这明显是不行的。虽然我们主观上很希望能去改变它，但逻辑上不行的东西 ，你再跳脚，再奋臂高呼：“严守规范，努力学习，以写出世界第一的代码为己任，为中华 之崛起而编程，成为Professional的工程师……”，这都没鸟用。这是逻辑限制的。好比明天 不下雨，你再想它下，你求雨，咒天，拿机枪向天上扫，都没有用。理智的人不做不理智 的事。开发团队现在的水平是怎么样的，不因为你制定开发规范， 不因为你要他们签“开 发者庄严承诺”，不因为你派程序员鼓励师去陪他们，甚至不因为你加工资而发生改变。

一个项目要延期了，不因为你骂项目经理，逼工程师签承诺，就不延期了。你当然可以逼 工程师加班，但加班也就是增加一点工时，就算忽略加班本身的负面效果，这个增加的工 时用完了，该延期还是延期，你强行要求不延期，结果就是被绑架，项目组要不降质量， 要不减功能，骗过你就行。反正你换谁都是一个结果，这是逻辑决定的，谁都改变不了， 你以为你做了什么事情可以改变它，只是掩耳盗铃，自己骗自己而已。一个公司请了你这 样没有理智的产品领导，也算是倒了八辈子的血霉了。

项目需要延期，是因为原来的预估失败，这是个事实，不可逆转。你要接受现实。你就算 惩罚当初预估的人，这个事情也不会更好，因为预估会失败这是个规律。如果不是预估的 人犯了什么明显的错误，你惩罚他也不能“警示后人”，因为换谁来预估都是一样的。你只 是无法接受而已，这是情绪，不是理智。

拔苗不能助长，这是自然决定的（道法自然v2 ），开发团队要提高开发能力，唯 一的方法是增加开发经验，并让有开发能力的工程师指导他们。找培训机构给他们培训， 这可能也有用。此外的手段，都是你自己看得爽，根本就不合逻辑。

如果你觉得“不定点规矩，工程师怎么会听话？”，你就要想想，你为什么不直接从幼儿园 招点小朋友？他们更听话。你找个律师，招个财务，都是因为他们的专业知识，是你听他 们怎么办，而不是你教他们怎么办。怎么到了程序员这里，你就觉得你应该教他们怎么办 的？如果他们连基本的判断能力都没有，你应该辞退他们，而不是用规矩去“教”他们写程 序啊。

增加开发经验，让有开发能力的工程师去指导，培训。这些东西都很慢，但它们是唯一的 办法，至少逻辑上如此。你要挑选“有开发能力的工程师”，唯一的办法是从他过去成功的 项目中来判断。因为“成功项目”是你的地盘，这个东西是你可以正确判断的。而“这个人的 写了几本开发的书”，“他谈架构谈得特好”，这就要加几分怀疑了，“他每天加班加到12点” ，“干了10多年PHP前端了”，这种就更加要怀疑了。而且，他在成功项目，成功离他加入多 远？如果项目做了3年，他加入一个月，这也值得怀疑了。我们判断一个人，用他的“道”来 判断，不用他的“名”来判断。之后，我们就只剩下信任了，反正你是个外行，你想从他每 天的行为来判断他靠不靠谱，你肯定会错判，这毫无意义。

作为产品负责人，你不是不能做什么，但你一定要在做好战略后，放弃去“推动”，去“引导 ”它，因为骗你的感官是特别容易的，你让他们看到你的判断模型，你的团队一定会走捷径 ，这不受他们自己控制，这么大一个团队，每个人都希望获得话语权，获得话语权最快的 方法是取得你的信任，你现了你的“可欲”，这个“可欲”必然是“名”，是简化后的问题，一 旦人们开始追求这个简化后的问题，你的团队就失道了，你的努力就会白费。

特别是程序或者解决问题这种东西，你看我样子，写几行代码多容易，保证这几行代码面 面俱到，不影响其他子系统才是本事，要看表演，都去写程序去了，至于程序破坏了其他 东西——你能看得出来？解决问题也是，你要找人做一个安全解决方案，使用安全库，通讯 使用OpenSSL加密，这有什么难度？但安不安全呢？你也看不出来，你越去检查，就越给你 看这些写代码，使用安全库的“样子”。至于代码本身好不好，安全方案安不安全，谁在乎 ？

领导者要学会“德信”——在调好团队后，在一定的时间内，信者，你也信他，不信者，你也 信他。你们不用玩那么多小九九，你们要什么资源我在我可以的范围内我都满足，但我眼 中只看到我要的结果，你们那些什么CMM，什么敏捷，什么6西格玛的理论，你们玩去，不 用跟我说，我看不见，我很庸俗的，我只看得见钱和产品布局。

你要挑真正做事的人，就把工作交给准备好3年不打算升职加薪的，等有结果再来谈条件的 人，这样食名的乌鸦才会退散，做事的人才会露出来。

评论中有人提到KPI。我觉得KPI这个东西，如果用来定义目标，这是必须的，否则上下级 无法对齐双方的目标，但我不用这个目标“考评”你。你的结果做得怎么样，我看得见，你 不用把它弄成某个指标来糊弄我。我只看得见“道”，我不听你的“名”。我在我熟悉的空间 里面玩我熟悉的游戏，不加入你的空间和你玩我不熟悉的游戏。我更不把你熟悉空间中的 游戏作为KPI来对齐我们的目标。

所以，UT覆盖率，告警清零，编程规范满足度……这种东西不要拿来做KPI。做任何一件事， 都是一个系统工程，包含很多细节的，把眼睛钉在其中几个指标上，一定会导致其他细节 被忽略，整个系统工程就会失衡，造成团队偏离目标，导致你做什么事情都做不成。

有人觉得是自己的KPI指挥了各个山头，其实是种骗自己的错觉。乐与饵，过客止。你指挥 的其实是你手中的鱼饵。你站在鱼池旁边扔鱼饵，鱼是来追逐利益而已，你以为是被你指 挥？你要保证看到鱼帮助你解决问题，不要老想着“指挥”他们。他们根本不受指挥（关键 是你也看不懂鱼的细节）。天下神器，为者败之，执者失之。你能守弱，把思路收回到你 怎么扔鱼饵上，谢天谢地了，不要想着怎么指挥他们。

所以，总的来说，你要做什么都可以，选择信任的人去直接去做那件事，不要让人看到你 的中间评价模型，用你自己的眼睛去看事实发生的道，不要被别人制造的指标蒙蔽了你的 眼睛，使你只看到整个困难中最容易的部分（参考： 架构师和项目经理的基本职责问题 ，真正的栋梁不会让你看到 天天的进步，他们让你看到一个个的坑——但这个事情本身，也不能作为你做评判的标准） ，这是你唯一可以做的，这就叫“不见可欲”。