我们在职场教育中被教育说"永不说不"，但是，在工作中明明有事情做不到，应该怎么去拒绝呢？

• 当你面对做不到的需求时，你不要说这个需求做不到。尤其是，你不要马上说做不到，你要先想一下，这样让别人觉得你是想做的，但是，在认真思考过后，你觉得做不到，并且给出一个你觉得做得到的方案。这里的诀窍是——给出另一个你可以做到的方案，而不是把对方的方案直接回绝掉
• 当你面对过于复杂的需求时，你不要说不。你要反问一下，为什么要这样做？这样做的目的是什么？当了解完目的以后，你可以给出一个自己的方案，或是和对方讨论一个性价比更好的方案。你可以回复说，这个需求好复杂，我们能不能先干这个，再做那个，这样会更经济一些。这里的诀窍是——我不说我不能完全满足你，但我说我可以部分满足你
• 当你面对时间完全不够的需求时，你也不要说不。既然对方把压力给你，你要想办法把这个压力还回去，或是让对方来和你一同分担这个压力。

陈浩老师惯用的招数，三个选择：a. 我可以加班加点完成，但是我不保证好的质量，有 bug 你得认，而且事后你要给我 1 个月的时间还债。b. 我可以加班加点，还能保证质量，但我没办法完成这么多需求，能不能减少一些？c. 我可以保质保量地完成所有的需求，但是，能不能多给我 2 周时间？

这里的诀窍是——我不能说不，但是我要有条件地说是。而且，我要把你给我的压力再反过来还给你，看似我给了需求方选择，实际上，我掌握了主动。

我们都知道时间需要被有效的利用，再这个信息爆炸的时代，还要更多的加一点，利用在更有价值的地方上。我认为：

• 花时间学习基础知识，花时间读文档。在参加工作的这近 20 年来，我发现，很多程序员把时间都浪费在了查错上。究其根本原因就是基础知识不完整，没有好好地把技术相关的用户文档读完整就仓促上手做事。其实只要把基础打扎实，认真读一下文档，你会省出很多很多的时间。系统地学习一门技术是非常关键的，所以这个时间是值得投资的
• 花时间在解放自己生产力的事上。在自动化、可配置、可重用、可扩展上要多花时间。对于软件开发来说，能自动化的事，就算多花点时间也要自动化，因为下次就不用花时间了。让自己的软件模块可以更灵活地配置和扩展，这样如果有需求变更或是有新需求的时候，可以不用改代码，就算要改代码也很容易
• 花时间在让自己成长的事上。注意，晋升并不代表成长，成长不应该只看在一个公司内，而是要看在行业内，在行业内的成长才是真正的成长。所以，把时间花在能让自己成长，能让自己有更强的竞争力，能让自己有更大的视野，能让自己有更多可能性的事情上。这样的时间投资才是有价值的。
• 花时间在建立高效的环境上。我相信你和我会有一样的一个习惯，那就“工欲善其事，必先利其器”。我们程序员在做事之前都喜欢把自己的工作环境整理到自己喜欢的状态下。比如使用趁手的开发工具，使用趁手的设备。

有关工作，做好一个To-Do-List，划分什么事是重要的，什么事是紧急的，什么事重要但不紧急，什么事又重要又紧急。这有利于你划分优先级。

最短作业优先。对于相同优先级的事，我个人喜欢的是“最短作业优先”的调度算法。理由是，先把可以快速做完的事做完，看到 to-do list 上划掉一个任务，看到任何的数据在减少，对于自己也好，对于老板也好。老板可以看到你的工作进度飞快，一方面有利于为后面复杂的工作争取更多的时间（老板只有在你有 Deliver 的时候才愿意给你更多的时间），另一方面，看到任务列表的减少会让你的心态更为积极。

想清楚再做。我发现很多时候，我们没有想清楚就开干了，边干边想，这样的工作方式其实很糟糕。你会发现，如果你没有想清楚，你总是要对已完成的工作进行返工，返工好几次，其实是非常浪费时间的。所以，对于一些没想清楚的事，或是自己不太有信心的事，还是先看看有没有已有的成熟解决方案，或是找更牛的人来给你把把关，帮你出出主意，看看有没有更好、更简单的方式。

关注长期利益规划。要多关注长远可以节省多少时间，而不是当前会花费多少时间。长期成本会比短期成本大得多。所以，宁可在短期延期，也不要透支未来。这里的逻辑是，工作上的事你永远也做不完的，长痛不如短痛。

以上出至 左耳朵耗子

1、对于一个功能提出的思考：

• 为什么要做这个特性，它会给用户带来怎样的价值?
• 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它?
• 达成这个目的是否有其它手段?是不是一定要开发一个系统?
• 这个特性上线之后，怎么衡量它的有效性?

2、思考的原则

• 以终为始 ： 这个功能最后想要以什么样的方式被使用，功能怎么被部署，