仓库源文

:Authors: Kenneth Lee :Version: 1.1

不见可欲

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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