Do thing right? NO! Do right thing.

——谁说的

程序员提高效能的第一个问题是找到正确的目标。

大部分无效的时间都是因为错误的目标。比如，在一个时间要求很紧的项目中应用团队不熟悉的技术（我经常如此:( ）。原因不仅仅是低估技术的复杂度，还包括高估自己对于技术的学习能力。明确工作目标是第一位的。要解决什么问题，时间多长，可用的技术及解决方案是什么？是否满足需求？要采用新技术吗？有验证和学习时间吗？如果时间不足，是否需要调整目标？

这些问题在我看来，按照其来源不同，分为5个领域，分别是：

业务域：这是来自于用户最直接需求的问题域，其重点是用户需要什么，而不是提供什么。关注要什么，是什么，而不是如何实现。简言之，即便脱离软件系统，需求依然存在。这是超越实现方式的。

产品域：这是跨越需求和需求满足的实现方案的集合。重点是如何满足需求。在需求范围上小于业务域，在实现范围上包含了运营域、运维域和技术域。

运营域：有的产品本质上是一种持续的服务，则需要定义提供服务的持续能力和范围。在特定的产品范围，运营还包含市场、内容、服务等多方面的范畴。

运维域：当产品本身是服务时，或提供面向企业的软件产品时，则需要相应的软件运维支持，以确保软件系统能够正常持续运行。

技术域：具体的软件实现范畴。包含各类软件开发技术、软件包等等。

前四个可以统称为需求域。技术域是为需求域服务的。

其中，业务域是最核心和最首要的问题域，脱离业务域的范畴就没有软件开发的必要。需求域决定了和限制了技术域的问题，而不是相反。需求域没有厘清的问题，技术域一定解决不了。即没有提出正确的问题，则不会有正确的答案。

通常情况下，受限于资源约束，技术域只能解决需求域的部分问题，而不是全部问题。换言之，技术域所能实现的问题解决方案不应超过问题域的约束，一旦超过，要么是需求域的问题定义出现偏差，要么是程序员无意识或有意识的偏离目标。

每一个域的识别和定义都是需要特定的专业知识和技能的。不能指望一个人能够解决所有的这些问题。比如，一个好的程序员就不一定是一个好的产品经理（实际上，肯定不是。任何领域都需要专业知识、技能和经验，随随便便就安排一个程序员做产品、项目管理，就是瞎扯）。他或她可能能够很快地编出一段代码，实现一个功能，但这段代码是否符合业务，是否具备良好的产品交互，这就不是程序员能够解决的了。

程序员需要具备的能力和知识，首先是技术域的范畴，不能混淆问题的边界。实际上，在现实的项目中，由于把所有问题混淆在一起，往往是造成项目失控的首要原因。比如，一个有关业务流程的功能，如果连业务流程的定义、角色的划分都没搞清楚，就指望程序员能够“自动”地实现，这完全是痴人说梦。

大部分的程序员，都不具备超越技术域的技能，这是一个客观现实。因此，才需要产品经理、项目经理、售前人员的介入，他们在不同的项目中，扮演着业务专家和产品专家的角色，定义业务域、产品域的问题边界，从而为技术域提供有效输入。很多公司由于各种原因，忽略了这些前导需求的角色，造成开发效率低效。

软件外包或定制化的业务之所以具备较大难度，就是因为软件企业很难具备“所有”的业务域和产品域资源积累，没有对应的业务专家、产品专家，那么，每一个新的软件项目都需要从头学习业务域、产品域的知识，而这种学习本身是极耗资源的。但今天大部分软件项目都面临着剧烈的市场竞争，客户一般不会提供足够的项目费用用以软件企业进行业务学习。相反，在竞争条件下，软件企业还需要以低廉的项目报价中标，这样，传统的软件外包业务利润微薄就可想而知了。所以，在软件外包领域一定是行业专业化，或者在软件外包之前有专业的咨询商，如IBM、埃森哲等。

蝉游记的@纯银V 曾经在他的微博提到“我花半天时间画原型，设计师得花半周，工程师得花两周，我还完全不能保证这个版本的需求能达到预期效果。……”这大致就是产品域到技术域的转换效率，1比20（0.5个工作日VS10个工作日）。所以，无论是公司的什么人，特别是程序员自己，怎么能不从一开始就搞清楚自己要解决的问题呢？一个在产品域犯下的错误，将来需要技术花至少20倍的代价去调整。我想不出，还有什么理由可以做出轻率的决定。

我刚入行的时候，听我的上司说“Do thing right”，还是“Do right thing”，当时自己内心还是不以为然的。究其根本，是在内心深处不敢也不愿意承认方向正确才能做对事，因为这个正确的方向却往往是最难找到的。而作为程序员，最喜欢的感受是学习了最潮的编程技术，似乎这些“花活”让自己很了不起。但是，衡量一个程序员是否成功的标志，却是你做的程序是否为他人、用户带来了价值。如果没有这一点，那么，即便你用了新潮的技术、机巧的设计，又有什么意义呢？