原文链接，作者：谭佳理。
六年前，我曾任微软项目经理一职。工作开始便与上司有一场单独的谈话，最后，她问我是否还有其他疑问。我回答：有的，我们什么时候可以着手削减不必要的功能？
她顿时陷入惶惑之中，想来这样的问题之前从未有人提及，也从未有人关心，所以不知该如何回答。
我知道她的不解，便进一步说明：其实，功能多并不意味着东西好，而是要根据用户的需求来规划，不如着手删减吧。
显然，她被吓坏了，像只初探尘世的雏鸟般呆在那里，于是我便就此打住。再后来，我终于明白为什么她如此困惑，历来项目经理的首要职责便是考虑如何谋划产品功能，弃顺归逆岂不是砸人饭碗？这也令我想到曾经制作过浩繁冗长的功能列表，并辅以 P1 ，P2 ，P0 等标签来区分优先等级，有时还会用到 P-1 。对的，负一，这种用法仿佛使项目经理自觉重要的正序标签又升一级，即便和全正序的排法并没有差别。
如果使用的人不多，移除也无所谓。强留其中只会显得突兀，或者藏于说明书的一角，偶而被人发现。不过这不是我最关注的，因为解决这些问题并不算困难。
软件的日渐臃肿并不全是劣等品充斥在其中，多数情况下这些功能仅能达标。有些还没完成，有些运作错误，反映在实际中，要么用户界面不对，要么内联机制有误，要么未达用户预期。说白了就是自尊心在作祟，是为了不至于落后他人，而令项目经理滋生的那苍白而贫乏的自尊。不仅如此，在作品里还可能掺杂有开发者与测试者为证明自我价值所做的多余努力，最后，整个团队一齐陷入到这股狂热的情绪里。
于是，问题到了无法修复的地步，让人无瑕眷顾，最后就纷纷烂在了那里。如果不想删掉它们，你就得不断修补、再修补。痛苦，而且没有止境。
这本该可以避免的。将精力放在真正重要东西上，凡事宜简，并专精于少数。如果是新公司，别忙着扩充人马，请运用好已有的雇员，特别是，别找一个只会开会和召集会议的项目经理。善于招纳实干与创造的人才，也别忘记保持自身的努力。赋予创新类团队最大的职权，并落到实处。
做的少，有时候可能得到的更多。
22 Comments so far
Leave a comment
Fields in bold are required. Email addresses are never published or distributed.
Some HTML code is allowed:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
URLs must be fully qualified (eg: http://apple4.us),and all tags must be properly closed.
Line breaks and paragraphs are automatically converted.
Please keep comments relevant. Off-topic, offensive or inappropriate comments may be edited or removed.
原来微软早已深得我国企之精华:只能多不能少啊.
例子如下: 这个规定是某某总定的,不能动,那个规定是某某总定的,也动不得, 最要命的是, 有很多很多的规定不知道是好个总定的, 不敢动啊!!!!
文白夹杂不是好的写作风格。
怎么翻译成这样 看的好累
现在windows 7退出一个设备需要点几下鼠标？
此文的文风和主题真是一对莫大的矛盾。
哇，这种译文让我当场就震惊鸟
楼上各位（lyutak 兄好久不见）请细看，Oliver 已经对译文进行了修改。
“谭佳理”是作者 Garry Tan 的原始中文名吗 还是译者给起的？
敢问译者是谁？似乎改动偏大 尽量直译为好吧 而且译文风格似乎不太适合 Apple4.us 的读者
不过这篇文章确实很不错
还有较早先的版本吗。
喜欢第一版的文风。
还好已经改了，第一版的译文疑似穿越文
@Jasper Song
没来得及更新的 Google Reader 可以看到：
六年以前，我曾于微软赴任项目经理一职。工作伊始即与上司有一场单独谈话，末了，她问我是否还有疑问。我答：有的，吾等何日方可削减产品中无必要之功能。
她顿陷入惶惑之中，想必这样的问题此前从未有人提及，也从未有人关心，所以不知如何作答罢。
我知其不解，便进一步阐明：其实，功能多并不意味东西好，而是要根据用户的需求来规划，不如考虑何时开始删减吧。
显然，她被吓坏了，楞像只初探尘世的雏鸟般呆定在了巢里，于是我便就此打住。再后来，我终明白为何她如此困惑，历来项目经理的首要职责便是考虑如何谋划产品功能，弃顺归逆岂不是砸人饭碗？这亦令我想到曾制作过浩繁冗长的功能列表，并辅以 P1 ，P2 ，P0 等标签来区分优先等级，有时还会用到 P-1 。对的，负一，这种用法仿佛使项目经理自觉重要的正序标签又升一级，即便实际上无甚新意。
若是乏人使用，移去它也无妨。强留其中只会显得突兀，或藏于说明文书一隅，偶现天地，以示自己来过世间。不过上述所言并非我之要旨，只因解决此类问题还不算是最困难的一环。
软件的日渐臃肿并非全是劣品充斥其中，多数情况下这些功能仅及达标。有些个尚未完成，有些个运作错误，反映在实际中要么用户界面不对，要么内联机制有误，要么未达用户预期。说白了就是自尊心在作祟，是为了不致落后他人，而令项目经理孳生的那苍白而贫乏的自尊。不仅如此，在作品里还可能掺杂有开发者与测试者为证明自我价值所做的多余努力，最后，整个团队一齐陷入到这般狂热的情绪之中。
于是，问题到了无法除残去秽的地步，亦让人无瑕眷顾，最后就纷纷烂在了那里。若不想删掉它们，你就得不断修补、再修补。痛苦，且无止境。
这本该可以避免的。将精力放在真正重要东西上，凡事宜简，并专精于少数。如果是新公司，别忙着扩充人马，请运用好已有的雇员，特别是，别找一个只会开会和召集会议的项目经理。善于招纳实干之士，创造之士，也别忘记保持你自身的努力。赋予创新类团队最大的职权，并落至实处。
寡言行而多思辨，终将至丰饶之地。
谢谢梁海。
我还以为再也看不到了呢 。 悲观情绪无处不在。
我觉的结尾真的很好。 我想可能是台湾人写的吧。
就像06年的时候看各家写的” stay hungry ,stay foolish ” .
最先在mobile01看到的译文是 “ 求知若饥，虚心若愚 ” 。 然后又陆续看到各种各样的版本， 包括我们大陆的 “ 物有所不足，智有所不明 ” 。
相比之下， 还是那个不知道出自哪位台湾之光的文笔，让我着实感叹与惊讶。
http://blog.yam.com/heuss/article/5166213
寡言行而多思辨，终将至丰饶之地。
旧版还是不错的
看苹果中国官方首页。http://www.apple.com.cn/
iPhone更新。
以上两个版本翻译均是 Oliver C 君一人之手，就我所知，他似乎不是台湾之光……
@Jammy @Jasper Song
但如果和原文 (“Be less. Do less. And you’ll somehow end up with more.”) 比较 确实感觉第一版的最后一句走得太远了
记得在重构还是设计模式上看到过一段话，好的代码不是不用再加什么，而是没有东西能砍。
简练的东西是好东西。
@张亮 ，
那也是一个好笔杆子。 像你一样。
我是围观群众
特别是，别找一个只会开会和召集会议的项目经理。善于招纳实干与创造的人才
=========
以前居然有S13说项目经理可以直接从MBA中找，真是天真无牙
说实话，我觉得这篇文章去掉了必须的背景，而且可能翻译或者原作者有意夸张。ms的产品线非常长，而且多，每个feature都必须有stakeholder，完全不是说你想简化就简化的，要那个提需求的team同意才行。到最后有了feature list，pm要定义出一个cut line，然后一个个跟提出feature的team谈砍掉后的反应，说服别人同意砍掉low priority feature也是pm的一项重要职责。
“显然，她被吓坏了，像只初探尘世的雏鸟般呆在那里”，在我看来，人家是呆住了，潜台词有可能是：我们在这上面工作了这么久，你居然还搞不清楚现在这些feature基本上是必须的了，有话为什么不早点提出来？我极度怀疑这个会影响这位作者的绩效评定
因为80%客户只使用20%的功能，所以软件公司应当尽量精简，只做最好的那些。这个idea对于大软件来讲，已经是一个证伪的命题。joel还是谁好像专门讲到过这个，每个人的20%功能都不一样，而且市场部需要很多东西来做推广，已经不仅仅是技术的问题了
呵呵 今天才看见下面的评论呐。。。我当时看这篇已经是白话文，觉得很不错，第一时间告诉旁边的人，“过来看看，这儿有个台湾女生写的骂微软的文章。”