不要再纠结那些可要可不要的功能

唯有符合业务目的的代码才能永存。...

有些功能你不一样要实现或马上实现，人的精力是有限的，应该集中在最重要的地方，每少做一件，效率就提高一点。所以，不要再纠结那些可要可不要的功能，不管是谁和你说。

你是不是常常觉得很累？

过去一年多，我仗着自己年轻的身体、对计算机的热情，在工作上多使用蛮力，仿佛一个使用朴素算法实现的程序，吭哧吭哧跑个不停。一开始，朴素算法还能在指定的工作时间内完成任务；后来任务越来越多，工作时间之内肯定没法完成，我开始窃取时间，以更长的时间换取任务的完成。我知道这不是一种科学的工作方式，但是在那种时间压力、任务压力之下，也是无可奈何。

但是无论如何窃取时间，一天总归只有 24 小时。无论如何使用蛮力，也做不到不休不眠。迟早有一天，任务会多到让人感觉厌倦，只是没有想到，这种情况来的这么快。

为什么会这样疲惫？

因为你光顾着低头拉车，忘了时不时抬头看路。

什么是需求？

互联网公司的产品流程一般分为三个基本步骤：产品提出需求分析；设计进行产品形态设计；技术实现功能开发。所谓开发就是根据产品形态，利用技术手段来进行实现需求。需求文档是程序员接触需求的第一媒介。

面对需求文档，你是常常直接跳过背景、目的、范围，跳过业务描述等所有内容，直接找到与自己相关的功能描述，开始干活；还是从背景开始看起，了解行业、业务和用户需求的设计，弄清楚自己到底在干嘛呢？

一份完善的需求不仅会告诉你需要实现什么功能，还会告诉你产品的商业价值、对用户有什么好处、以及视觉表现是怎样的。了解这些背后的需求，你就可以判断用户需求的强烈程度，将需求分成两类：一部分是「一定要有」（has to have）的硬需求，另一部分是「有了也挺好，没有也无所谓」（nice to have）的一般需求。

开发工作和需求是什么关系？

有的程序员可能认为，产品经理给我讲明白需要做什么功能就行了，我对行业了解那么深有什么必要呢？他们不知道的是，需求分析也是分很多层次的，层次越高，需要对业务的理解越深。

简单来说，需求体系可以分为四层：

最顶层是行业需求，包括行业规范，文件，法律法规，潜规则等；
第二层是业务需求，设计业务以满足行业需求中的各种规定；
第三层是用户需求，设计人机交互以满足业务需求；
最后是系统需求，设计系统间/内交互以满足用户需求。

这是一个自上而下的金字塔。上层是下层设计的依据和动机，下层是上层的具体实现。所以，越往下，变化越频繁越剧烈；越往上，变化越缓慢越轻微。

用户需求作为整个需求体系的第三层次，变化常常很大。如果你觉得需求变更没完没了，不厌其烦，常常打破自己的开发安排，那么，你应当向更加高层次的需求探究，寻找用户需求的编制依据。你或许可以发现需求中的错误，疏漏，自相矛盾；你也可以反思自己的编码是否符合业务目的，所谓「唯有符合业务目的的代码才能永存。」

不同人眼中的「需求」

作为一名成熟的程序员，什么样的功能应该优先开发？

一个成熟的程序员知道，与其指望不让需求变化，不如更重视需求与业务的符合度，需求的明确程度，以及完善的需求管理——这三者不仅重要得多，也容易控制得多。这样才能控制需求变更，不能让需求变更随意地影响开发过程。

首先，接需求的时候先多想几个为什么，不能随随便便来一个接一个。

一头扎进去，埋头干你自己认为应该干的事情，这很简单。而要从中抬头起来问问自己为什么要这么做，则难得多。你需要问自己几个重要的事情，以确定你是否在做真正有意义的事情：

为什么要这么做？你在解决什么问题？这真的有用吗？你加上去的东西有价值吗？这种改变真的会起作用吗？这种方法更简单吗？有其他更值得做的事情吗？这样做值吗？

有时候放弃其实是一步好棋，即使你已经为之投入很多努力，也不要继续把大好的时间浪费在不值得做的事情上。

——Jason Fried & David Hansson《重来》

如果遇到奇葩需求，不要愤怒地一口回绝，成熟的程序员会把可能的风险用尽可能准确平实的语言列出来，发邮件请需求方确认，同时抄送相关老板。

其次，程序员的时间和精力有限的，需要自己先确定优先开发的功能：它们是满足最核心的需求，并且是短时间内可以实现的。至于那些看起来简单但是做起来会很复杂、或暂时技术上根本达不到的需求，需要和提出需求的人好好沟通。

好的产品都是一代代优化迭代出来的，没有谁可以在有限的时间内做出一个很完美的产品。在时间和资源有限的情况下，总有一些功能是要暂时舍弃的。

数据显示，70%的Rework是由变动的需求引起的。作为开发人员，最重要的是保持自己稳定的开发节奏，不特意去迎合需求变更，不承诺任何变更能短期兑现，而需要经过架构上的评估。这样才能让有快速变更需求意愿的一方知道变更的代价，促使他们在变更请求之前更加深思熟虑，从而降低产品迭代的噪音，这样不仅对技术团队，对整个项目都有好处。

总之，不重要的事情每少做一件，效率就提高一点。如果你常常感觉被需求赶着跑，你或许该停下来了，你得问问自己，到底什么是需求？自己的开发工作和需求是什么关系？自己到底在干嘛？

想清楚这些问题，你才能集中有限的精力，完成最重要的工作。