在项目中经常被业务方逼得紧不要抱怨，你没有时间被逼得像牲口一样工作，这个时候，你需要的是暂停一下想一想，为什么会像牲口一样？而这正是让你变得聪明的机会。

>  你有没有去Review业务方给你的这么多的需求，哪些是合理的，哪些是不合理的。工程师都要在拿到需求后一定要问——“为什么要做？架构影响度有多大？有多少用户受益？”，回答不清这个问题，没有数据的支持，就不做。

> 需求人员你不但要对用户把握得很好，也会对软件工艺把握得很好。你不但会开出外在的功能性需求，也同样会开出内在的让软件系统更完善的非功能性需求。你不要再迁就用户，而是引导用户。不是拍拍脑袋，听极少数的用户抱怨就要开需求了。这样就不会无限制地加功能，而是把握产品灵魂控制并简化功能。你会为自己要做的和不做东西的感到同样的自豪。”。要明白一个道理***“做一个半成品不如做好半年产品”***（更多这样的观点请参看《Rework摘录和感想》）

> 做事情是要讲效率的。喜欢使用一种叫T-Shirt Size Estimation的评估方法来优先做投入小产出大的“Happy Case”。当一个管理者的智慧无法衡量一支团队的产出的时候，他就会把“工时”当做最后的救命稻草，死死抱住——这是他唯一听得懂的东西了。”靠加班超越对手？！劳动密集型么？认为加班是公司的核心竞争力，或是超越对手的手段，是一种相当 Ridiculous 的想法。这说明管理者们已经想不到自己公司的核心价值了。

> * 条件受限是好事，因为条件受限可以让你小材大用，让你没有办法再用蛮力来完成工作，让你必需去思考使用知识密集型的解决方案来更聪明的解决问题。

> * 工作狂往往不得要领。他们花大把大把的时间去解决问题，他们以为能靠蛮力来弥补思维上的惰性，其结果就是折腾出一堆粗糙无用的解决方案。

> * 就像人肉手动的织布机一样，当面对大量订单的时候，一个简单粗暴的方法就是拼命地加人和拼命地工作来换取更大的生产力。只有你在人手不够或是人力成本太高的情况下，你才会去想是不是可以优化一下工具，制造一个更有效率更有生产力的工具。

> * 在中国，劳动力的成本不高，而管理者们的智力和能力有限，所以，在这个环境下，尤其在KPI和数字的重压下，管理者们是非常非常容易想到需要靠加人或是加班来提高产能的。所以，他们放弃了知识密集型的创新，而采用了劳动密集型的简单粗暴的方式，长期下来，导致了自己再也不会思考，导致了只会使用人肉解决问题。

> 需求总是会变化的，不要抱怨需求变化太快。你应该抱怨的是为什么我们没有把握好方向？老变？这个事就像踢足球一样，你要去的地方是球将要去的地方，而不是球现在的地方。你要知道球要去哪里，你就知道球之前是怎么动的，找到了运动轨迹后，你才知道球要去像何方。如果你都不知道球要去向何方，那你就是一只无头苍蝇一样，东一下西一下。

> 当你忙得跟牲口一样，你应该停下来，问一下自己，自己成为牲口的原因，是不是就是因为自己做事时候像就牲口一样思考？

> * 你得多问问你的需求方，为什么要加这个需求？干这个事到底有多大的价值？能让多少人受益？
> * 你得多问问你的需求方，能不能稍微简化一下需求，这样可以让我付出的努力更少一些？
> * 你得要多去思考一下，你是在干一个建筑队的活呢？还是在干一个装修队的活？
> * 你得要多去思考一下，业务上和用户的最大的痛点是什么？

> * 像乔布斯那样，告诉你的产品经理或是业务方，你现在提的10需求，我只能做3个，会是哪3个？为什么是这3个？有用功的来源不是拼命做需求，而是砍需求。
> * 关于创造价值，我们要干的不是像百度的“竞价排名”那样，把钱从别人口袋里搬运到自己的口袋里，而是要像“英国工业革命”或是“硅谷”那样，把价值真正的创造出来。

> * 你得多问问自己，你有多少时间是在干一些支持性而不是产出性的工作？
> * 你得多问问自己，有没有残酷无情地减少重复劳动的劳动密集型的工作？
> * 你得多问问自己，自己的管理者和员工的能力和素质有没有在降低你的团队执行的成本？

> 有一个很不错的产品经理对我说，他看了南京那两个小女孩被饿死的消息，感到很震惊。与之有关联的每一方都说自己尽力，但是最终结果人还是饿死了，你几乎不敢相信这是真的。

> 所以说，效率不是每个团队各自的效率，而是整个团队对整个产品负责的共同使命，这样才会现整体的效率。没有整体的效率，只有个体的效率，最终也等于没有效率。

> 我希望新入行的同学们对自己的工作有基本的坚持，我知道你们会因为骨感的现实而妥协，但是我希望你们就算在现实中妥协了也要在内心中坚持尽可能高的标准，不要习惯成自然，最后被社会这个大染缸给潜移默化了。因为你至少要对自己负责。