原文链接，作者：谭佳理。
本文from apple4us
六年以前，我曾于微软赴任项目经理一职。工作伊始即与上司有一场单独谈话，末了，她问我是否还有疑问。我答：有的，吾等何日方可削减产品中无必要之功能。
她顿陷入惶惑之中，想必这样的问题此前从未有人提及，也从未有人关心，所以不知如何作答罢。
我知其不解，便进一步阐明：其实，功能多并不意味东西好，而是要根据用户的需求来规划，不如考虑何时开始删减吧。
显 然，她被吓坏了，楞像只初探尘世的雏鸟般呆定在了巢里，于是我便就此打住。再后来，我终明白为何她如此困惑，历来项目经理的首要职责便是考虑如何谋划产品 功能，弃顺归逆岂不是砸人饭碗？这亦令我想到曾制作过浩繁冗长的功能列表，并辅以 P1 ，P2 ，P0 等标签来区分优先等级，有时还会用到 P-1 。对的，负一，这种用法仿佛使项目经理自觉重要的正序标签又升一级，即便实际上无甚新意。
若是乏人使用，移去它也无妨。强留其中只会显得突兀，或藏于说明文书一隅，偶现天地，以示自己来过世间。不过上述所言并非我之要旨，只因解决此类问题还不算是最困难的一环。
软 件的日渐臃肿并非全是劣品充斥其中，多数情况下这些功能仅及达标。有些个尚未完成，有些个运作错误，反映在实际中要么用户界面不对，要么内联机制有误，要 么未达用户预期。说白了就是自尊心在作祟，是为了不致落后他人，而令项目经理孳生的那苍白而贫乏的自尊。不仅如此，在作品里还可能掺杂有开发者与测试者为 证明自我价值所做的多余努力，最后，整个团队一齐陷入到这般狂热的情绪之中。
于是，问题到了无法除残去秽的地步，亦让人无瑕眷顾，最后就纷纷烂在了那里。若不想删掉它们，你就得不断修补、再修补。痛苦，且无止境。
这本该可以避免的。将精力放在真正重要东西上，凡事宜简，并专精于少数。如果是新公司，别忙着扩充人马，请运用好已有的雇员，特别是，别找一个只会开会和召集会议的项目经理。善于招纳实干之士，创造之士，也别忘记保持你自身的努力。赋予创新类团队最大的职权，并落至实处。
寡言行而多思辨，终将至丰饶之地。