技术服务于业务。
一个技术人员想要走得更远，不能仅局限于技术，需要对自己所从事的业务领域有不断深入和全面的理解。
所谓业务领域，就是大家平常自我介绍，不会仅简单说我是搞C++的，我是搞JAVA的，而是游戏后台C++，广告引擎C++，电商后台JAVA，大数据JAVA，这里面的游戏/广告/电商/大数据，就是大的业务领域，平时我们接触到的，应该是业务领域里面更小更具体的业务。比如说广告，有展示广告，搜索广告，feeds流广告，而且这些业务(领域知识)还在不断变化和演进。
产品经理(产品专家，高级产品专家，资深产品专家，产品总监)不断地思考业务的发展，然后把这些思考转换成一个个需求，然后一般以项目的形式提给技术人员，期望对产品的思考能快速落地实现，并尽快在用户那里得到使用和反馈(以及分析数据)。
对于技术人员而言，可能很多时候都处在接产品需求，分析需求，考虑/撰写技术实现方案，排期，埋头吭哧吭哧干活，赶在deadline前上线，收工，周而复始的这样一个流程中。
久而久之，我们处于这样的循环中而不自知，变成了一个需求实现机。虽然对于技术人员来讲，最重要的还是技术，主要关注点在系统架构、系统稳定性、系统可用性、系统运维、快速迭代能力、流量峰值等方面，但就像我们前面说的，要想走得更远，就需要对业务有更多的理解(和把控)。
最近对于技术人员怎样提升业务sense(加深对业务的理解)有了一些输入和思考，在这里分享给大家。
一、关注需求背后要解决的业务问题，而不是产品经理的需求
很多时候产品经理提过来的是解决方案(已经把待解的业务问题做了自己的理解，转换成了自己认为最合适的解决方案)，而不是原始的待解决的业务问题。
技术人员需要自己找到原始的待解决的业务问题，自己去理解和分析问题，从技术的角度考虑，评估产品经理给出的解决方案是否是最合理/最适合的，如果不合理/不合适，那么就给出自己认为最合适的解决方案。
拿到一个需求的时候，一定要自己先做一个基础的判断，接收到的是一个待解的业务问题，还是一个解决方案。
从事技术开发的人要杜绝的，是接收到一个需求(解决方案)，就立即开始评估工作量、排期，然后吭哧吭哧把活干完，上线。然后，下一个(需求)。
举个例子。
产品经理提了个需求给技术人员，要求建造一部梯子。需求很明确了，梯子需要使用什么材料建造，长度要求多少，宽度要求多少，需要能承受多少重量。
技术人员拿到这个需求，就开始评估大概需要多少材料，需要多少建造工期和测试工期，然后就开工了。
其实我们应该停一下。“建造一部梯子”是一个解决方案，而不是一个待解的业务问题。
不妨问问产品经理梯子是用来干什么。用来更换屋里中央吊灯的灯泡的。为什么要换灯泡？因为灯泡不够亮，白天屋里太暗了。所以要解决的业务问题是屋里的照明问题。
那不用费劲造梯子了，说不定我们把厚厚的遮光窗帘掀开，屋里就亮堂了。喏，不用浪费时间和财力造梯子了，你happy我happy大家happy。
二、技术人员要有业务好奇心
最近听到一个有关技术人员的观点，觉得很有意思，因为我一下子就被说中了：给技术人员一个deadline，他所有的精力/注意力/付出全部都集中在deadline上，整个思维都集中在怎么在deadline前把项目完成上线。
我自己脑补了下：一条狗，不论它之前在做什么，你只要让它注意到你手里的肉骨头，它的眼神和精力就会集中在这个肉骨头上，不论你是把肉骨头高举，还是把它扔出去。deadline就是技术人员关注的肉骨头。
全力关注肉骨头好像是一种本能，但是人需要克服本能才能获得更多的进步和成长。
参与到项目后，不能只是评估工作量、排期、kickoff，然后就盯着deadline赶工和快速收工。要对技术方案之外的业务有好奇心，在保证项目按期保质完成的基础上，花时间去了解需求背后的业务问题和业务变化，扩展自己对业务认知的版图，加深自己对业务的理解。很多项目，一般涉及到多个团队/部分，平时难得见到，正是沟通和了解自己所负责工作之外的好时机。
人与人之间最大的差别是思维方式。只有思维方式持续不断升级，我们才有可能站得更高走得更远，与诸君共勉。