原文链接，作者：谭佳理。

六年前，我曾任微软项目经理一职。工作开始便与上司有一场单独的谈话，最后，她问我是否还有其他疑问。我回答：有的，我们什么时候可以着手削减不必要的功能？

她顿时陷入惶惑之中，想来这样的问题之前从未有人提及，也从未有人关心，所以不知该如何回答。

我知道她的不解，便进一步说明：其实，功能多并不意味着东西好，而是要根据用户的需求来规划，不如着手删减吧。

显然，她被吓坏了，像只初探尘世的雏鸟般呆在那里，于是我便就此打住。再后来，我终于明白为什么她如此困惑，历来项目经理的首要职责便是考虑如何谋划产品功能，弃顺归逆岂不是砸人饭碗？这也令我想到曾经制作过浩繁冗长的功能列表，并辅以 P1 ，P2 ，P0 等标签来区分优先等级，有时还会用到 P-1 。对的，负一，这种用法仿佛使项目经理自觉重要的正序标签又升一级，即便和全正序的排法并没有差别。

如果使用的人不多，移除也无所谓。强留其中只会显得突兀，或者藏于说明书的一角，偶而被人发现。不过这不是我最关注的，因为解决这些问题并不算困难。

软件的日渐臃肿并不全是劣等品充斥在其中，多数情况下这些功能仅能达标。有些还没完成，有些运作错误，反映在实际中，要么用户界面不对，要么内联机制有误，要么未达用户预期。说白了就是自尊心在作祟，是为了不至于落后他人，而令项目经理滋生的那苍白而贫乏的自尊。不仅如此，在作品里还可能掺杂有开发者与测试者为证明自我价值所做的多余努力，最后，整个团队一齐陷入到这股狂热的情绪里。

于是，问题到了无法修复的地步，让人无瑕眷顾，最后就纷纷烂在了那里。如果不想删掉它们，你就得不断修补、再修补。痛苦，而且没有止境。

这本该可以避免的。将精力放在真正重要东西上，凡事宜简，并专精于少数。如果是新公司，别忙着扩充人马，请运用好已有的雇员，特别是，别找一个只会开会和召集会议的项目经理。善于招纳实干与创造的人才，也别忘记保持自身的努力。赋予创新类团队最大的职权，并落到实处。

做的少，有时候可能得到的更多。