深度思考比勤奋更重要。天道未必酬勤。
举个例子
理解问题（需求）背后的本质
业务方给 PD提了一个关于梯子的业务诉求。然后呢，PD根据自己的理解 设计好产品了，提需求给技术人员，要求建造一部梯子。
需求好像很明确了，梯子需要使用什么材料建造，长度要求多少，宽度要求多少，需要能承受多少重量。
技术人员拿到这个需求，就开始评估大概需要多少材料，需要多少建造工期和测试工期，然后就开工了。
其实我们应该停一下。“建造一部梯子”是一个解决方案，而不是一个待解的业务问题。
不妨问问产品经理梯子是用来干什么。用来更换屋里中央吊灯的灯泡的。为什么要换灯泡？因为灯泡不够亮，白天屋里太暗了。所以要解决的业务问题是屋里的照明问题。
那不用费劲造梯子了，说不定我们把厚厚的遮光窗帘掀开，屋里就亮堂了。喏，不用浪费时间和财力造梯子了，你happy我happy大家happy。
思维突破才是人演化过程中的核心
人与人之间最大的差别是思维方式。只有思维方式持续不断升级，我们才有可能站得更高走得更远
人类从爬行到直立行走，到火的使用，石器工具的使用，农业革命，工业革命，信息技术革命，互联网浪潮，大数据 + AI 等等的演化，都是人类思维不断突破自我的结果。但是，这个过程通常很漫长。
业务与技术
业务
如何理解业务
很多人认为理解需求就是理解业务了，需求其实是业务经过产品消化后的产物，可能已经经过演绎，或者是其中某个拆解环节，因此需求并不是业务本身。当然了解的需求越多，可以让你更清楚业务的全貌。
那么什么是业务呢？业界对’业务’有多种定义，但是其主要思想基本不变，业务就是一系列人通过一系列活动完成某一任务的过程，因此，业务可大可小，可以无限拆分，对 CBU 的批发业务来说，就是次终端用户通过1688批发商品并转卖给下游的行为，而 CBU 本身又分了很多子业务，如诚信通，是百万商家通过付费方式获取增值服务的业务。数字营销，则是让卖家通过采买流量促进转化的过程，而数字营销中的 CPS 业务，又是让商家为商品设置佣金，渠道推广商品促进成交而获得该佣金的业务，诚信通、实力商家和数字营销，又可以归结为 CBU 的商业化业务。
灵魂 3 问
第一，这个业务的用户是谁？
第二，这个业务解决了什么痛点？
第三，这个业务为什么是你做？
商业模式
流量如何来的？内容如何来的？生态情况怎么样？如何商业化的？再走到宏观上去，看看行业情况怎么样，竞争对手怎么样，最后回到产品和技术，这个业务什么产品在承载，主要对技术的依赖和诉求又是什么。前面摸到一些信息之后，接下来最好还能够有一些洞察和思考，比如你为什么要做这个业务，现在业务发展遇到了什么瓶颈？打算如何破局？基本上把这些摸清楚了，你对这个业务就有个比较清楚的脉络了，也能和业务方做对话了。
但是要达到这种程度是需要下苦功夫的，有些业务比较简单，比如打车，很容易明白业务框架，但是要了解细节不容易，比如你知道出租车与出租车公司的关系和利益是怎样的吗？如果不理解，怎么去颠覆它？对于零售、贸易、制造、跨境、金融等更复杂的业务，就更难了解流程和细节了，需要用各种渠道去补齐信息，比如阅读行业书籍、实地走访、与用户沟通、分析数据等方式，这里我列举了一些方法，分别从易到难，最简单的是唾手可得的东西，比如资料和书籍，其次是学会分析行业或者公司内数据，最后是用户调研和实地走访，并产生自己的洞察。
主动系统性学习
先说资料的阅读，比如为了了解批发市场，探索批发市场的归途，看了一些政府的报告，也看了一些行业的调研：
为了了解商品流通渠道，查了很多与经销商有关的资料，并产生洞察，输出了文章，思考未来商品流通方式，探古索今，阅读研究中国古代贸易的书：
除了书籍以外，还有通过调研报告获取数据和信息，还有就是跟业内牛逼的人，案例交流学习。
分析行业数据或者业务本身数据也是理解业务的一种重要手段。
理解业务与运营
理解业务更多是理解了运营决策背后的原因，理解了网站各个角色的诉求和痛点，理解了自己做的产品和项目对业务的价值和影响，让自己更加有使命感，也能对项目分清轻重缓急，并且有机会产生驱动业务的技术产品。而业务决策通常鲜有从0到1的，大部分是具体的一些运营策略，需要你懂市场，懂卖家和买家，最重要的还是要有执行力，要有聚拢资源的能力。
技术
宗旨
实现客户价值
技术服务于业务
一个技术人员想要走得更远，不能仅局限于技术，需要对自己所从事的业务领域有不断深入和全面的理解。
所谓业务领域，就是大家平常自我介绍，不会仅简单说我是搞C++的，我是搞JAVA的，而是游戏后台C++，广告引擎C++，电商后台JAVA，大数据JAVA，这里面的游戏/广告/电商/大数据，就是大的业务领域，平时我们接触到的，应该是业务领域里面更小更具体的业务。比如说广告，有展示广告，搜索广告，feeds流广告，而且这些业务(领域知识)还在不断变化和演进。
产品经理(产品专家，高级产品专家，资深产品专家，产品总监)不断地思考业务的发展，然后把这些思考转换成一个个需求，然后一般以项目的形式提给技术人员，期望对产品的思考能快速落地实现，并尽快在用户那里得到使用和反馈(以及分析数据)。
对于技术人员而言，可能很多时候都处在接产品需求，分析需求，考虑/撰写技术实现方案，排期，埋头吭哧吭哧干活，赶在deadline前上线，收工，周而复始的这样一个流程中。
久而久之，我们处于这样的循环中而不自知，变成了一个需求实现机。虽然对于技术人员来讲，最重要的还是技术，主要关注点在系统架构、系统稳定性、系统可用性、系统运维、快速迭代能力、流量峰值等方面，但就像我们前面说的，要想走得更远，就需要对业务有更多的理解(和把控)。
要关注需求背后要解决的业务问题，而不是产品经理的需求，不能本末倒置
很多时候产品经理提过来的是解决方案(已经把待解的业务问题做了自己的理解，转换成了自己认为最合适的解决方案)，而不是原始的待解决的业务问题。
技术人员需要自己找到原始的待解决的业务问题，自己去理解和分析问题，从技术的角度考虑，评估产品经理给出的解决方案是否是最合理/最适合的，如果不合理/不合适，那么就给出自己认为最合适的解决方案。
拿到一个需求的时候，一定要自己先做一个基础的判断，接收到的是一个待解的业务问题，还是一个解决方案。
从事技术开发的人要杜绝的，是接收到一个需求(解决方案)，就立即开始评估工作量、排期，然后吭哧吭哧把活干完，上线。然后，下一个(需求)。
技术人员要有业务好奇心
参与到项目后，不能只是评估工作量、排期、kickoff，然后就盯着deadline赶工和快速收工。要对技术方案之外的业务有好奇心，在保证项目按期保质完成的基础上，花时间去了解需求背后的业务问题和业务变化，扩展自己对业务认知的版图，加深自己对业务的理解。很多项目，一般涉及到多个团队/部分，平时难得见到，正是沟通和了解自己所负责工作之外的好时机。
给技术人员一个deadline，他所有的精力/注意力/付出全部都集中在deadline上，整个思维都集中在怎么在deadline前把项目完成上线。
但是人需要克服本能才能获得更多的进步和成长。
一个有趣的现象
做项目的正确姿势
业务先赢是技术第一要务
一个公司是因为先有业务模式，才去招兵买马，组建研发团队的，皮之不存毛将焉附，业务好坏决定了公司的营收和前途，也决定了研发的效益和去留，因此技术人员首要任务是先把业务支持好，在这个前提下，再来讲技术沉淀和技术红利
超出预期
技术团队要解决的是业务问题，业务的发展不是一蹴而就的，任何业务都是从探索一步步做的，这时我们的技术要选择合适的技术而非牛逼的技术。『牛刀杀鸡』，用合适的技术实现业务诉求，而不是显示自己的牛逼。对新技术的敏感度要提高，在埋头做事的时候对外部的变化可能不敏感，对于一个合适的思路可能会迷茫。
作为一个技术团队，如果只是需求-开发-测试，我们永远都在一个黑屋子中，我们永远没办法明白我们在场景中的位置，无法从技术角度反推业务，产生增值价值。我们和业务站在一条线上共同看到客户、客户价值，这样我们的思考才会产生价值。但是技术也有本分，我们要去明白业务，去思考，但是不做业务的决定。
要经常地、更多地思考业务痛点和了解业务策略。
主动思考业务问题。
怎样把业务与技术链接比较好？
遇到不理解的策略要勤问。
对业务未来的思考和判断是什么，哪些地方会变化，业务在演变过程中我们可以更快速适应变化
业务理解力
技术能力
技术领域出结果
技术领域也要做出结果，结果也能说得清楚，技术领域的事情也有技术领域的衡量手段，尽管不能完全量化，比如研发效率提升多少？但是基本可以定性，定性上主要看两个点，一是是否代表先进生产力的发展方向，二看是否代表广大用户的根本利益。定量上，可以看落地场景数目、产品用户、用户满意度等等，比如引入和推广一门技术，能落地到多少场景，bug 数或者线上错误监控又能降低多少，或者用户对此的欢迎程度和满意程度。
研发过程对业务的影响分为6类：
1.按时交付，质量一般，大概就是对外包的要求；
2.技术增值，能够很快而且很爽地完成交付，这种情况下需要磨刀或者升级研发工具，会存在研发效能提升的机会，事实上研发大部分的技术沉淀也会在此，就是升级自己的研发流程和工具，提升自己的交付效率和研发体验。我们听过业务方对我们最多的诉求就是希望快速上线，因此研发效能是技术的生命线。
当然研发效能提升也没那么容易，而且很难量化，因为即使是同一个人，不同时间面对的事情也是不一样的，而同一个事情，在不同阶段的策略和细节也不一样，因此即使你做了一些研发效能提升的事情，也很难说到底对交付效率提升了多少，很多情况下会是研发自己觉得爽了，当然研发自己爽这也很重要，因此对于这类研发效能类工具，研发满意度和用户数是比较重要的评价指标；其他类型的，尽量找定量结果，通常是一些可模式化的工作，比如还原一个视觉稿的速度，客户端发版的速度，编写一个 http 接口的速度，上线一个应用的速度。
3.技术增值，除了按时完成交付之外，还能把产出质量做得很好，比如端的体验（流畅度、性能）、稳定性、接口的速度与数据实时性，安全性等，按理说这些是基本的要求，为何要成为技术的增值价值呢？
因为从软件工程的角度来讲，软件质量是一定有问题的，而且与项目复杂度和周期成正比，而且业界也没有标准，说什么规模、特质的业务应该达到什么样的体验，因此这里更多要依赖于技术人员的工匠精神与技术挖掘能力，而且软件质量看起来对业务没有直接驱动作用，但是在竞争对手足够多而且用户更换成本又低的情况下，软件质量的好坏对用户留存有一定的影响。这是定性，当然大部分研发的困境也就在此，就是如何量化体验提升对用户转换和留存的价值？
如果无法量化，那么在软件体验上应该投入多少呢？ROI 如何衡量呢？当然有一点可以肯定的是，你的质量要做到一定范围的领先，超过同类产品，那么你的增值价值就更能体现，对于技术本身就是业务的公司如云计算公司，技术产品本身的质量对业务的价值则非常明显了。
4.仍然是技术增值，但是这里的技术具有鲜明的业务场景特色，比如 SEO 技术、B 类的大额支付、A 站的弹幕技术、广告的创意技术、店铺装修技术，这里所有的技术沉淀都是围绕业务来的，因此我把它画在中间，属于又有技术沉淀，又能带来业务结果的技术。
5.业务增值，就是做了一些业务方原以为技术不能干、干不好的那些能够直接促进业务发展的事情，这就是所谓的技术驱动业务。当然这里的抓手还是技术，但是，与前面说的区别是，这里的出发点或者说结果，是直接能对业务产生有利增长的，前面很多事情提升的都是一些技术指标，比如交付周期、crash 率、页面或接口性能等等。
技术驱动业务也是大部分工程开发最困惑的一点，也是对业务型开发影响最大的点，在前面的阶段，研发做的事情都是解决技术的事情，这个阶段，你需要去发掘业务痛点或机会，然后用技术力量去改善，当然这里的技术力量可以是有很大厚度的。比如算法与机器学习，也可以是不需要技术厚度，但是需要产品设计和链接的，也可以是老技术，也可以是新技术。总的来说，它更看重业务价值，而不是技术厚度，哪怕是简单的技术解决了业务问题，也是值得喝彩，这就是我经常说的，站在业务视角，技术价值能够被放大。
6.直接参与业务决策的阶段，在云计算公司、技术产品型公司或者业务模式简单的公司，技术参与决策的机会更大，部分高管本身也会是技术出身，也可能是技术高管直接担任业务负责人，在腰部，也会有一些技术主管直接带运营和产品。
但是大部分情况并不是这样，尤其是商业模式复杂，生态复杂的公司，产品、运营和技术，三位一体，角色分明，即使技术可以在一些产品和业务上提供建议或者分析依据，但通常不会成为业务的主要决策力量，是因为整体上，技术对商业的理解比较碎片，或者仅仅是想法而已。运营通常在某一行业深耕许久，接触到的情况，实践过的东西非外行能够快速追赶，当然业务和技术对行业、对市场大局的洞察，以及做事情需要的优秀特质，这一点，并不存在很大的壁垒。
理解业务有助于你做技术决策去驱动业务，有助于你对资源的优先级做判断，而且还有助于提升你的研发效能
业务与技术的关系
举个例子
亚马逊“ 卖书业务 vs 电子商务网站的开发技术
随着网站规模越大，亚马逊发现电商网站可以做成一个平台，接入其他的商家，让大家共享渠道一起卖书。在这个时候，电商平台就成了一种业务，而分层架构、分布式、权限分配、Open API 等就是技术。后来，随着平台和数据中心的壮大，亚马逊发现可以利用富余的软硬件资源来提供数据存储服务，给第三方网站使用。这时候，提供云存储就是业务，而其中业务实现用到的虚拟化、云计算等解决方案就是技术。通过上述例子可以看出，技术和业务其实是一个相对的概念，业务隶属于问题域，技术隶属于解决方案域。通过不同的场景和视角转换，技术也会演变成一项业务。
956
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
