技术人员，该如何向业务和产品“砍需求”？

导读：“会”砍需求，并不是件容易的事情，这涉及到工程师的商业头脑，要会判断技术和业务的关系。技术与业务好比“两条腿”，相互配合才能走得更远。如何具备business sense就是我们今天的课题。

论工程师的商业头脑

我们常常听到这样的话，“某某同学有很好的business sense”，这通常是评价一个非业务类型的同学，如果这个同学是一个软件工程师，那么他一定很受产品和业务的青睐，因为对他们来讲，这样的技术同学交流起来更顺畅，换句话说，就是更有共同语言。

什么是“business sense”？

Business Sense，更书面的叫法是Business Acumen，套用Wikipedia的解释，is the keenness and quickness in understanding and dealing with a "business situation" (risks and opportunities) in a manner that is likely to lead to a good outcome。商业意识（更喜欢叫做商业头脑，接地气）是指对当前商业形势的敏锐洞察力和快速响应力，通常会导致好的结果。

注意这里对商业形势的判断可能是机遇，但也有可能是风险，或者机遇与风险并存。能够快速的识别出这些要素，并采取正确的行动，从而带来好的结果，这样的人会被称之为具有好的商业头脑。好的商业头脑，加上强大的执行力，以及一点点的运气，走上人生的巅峰便不是难事。

各行各业的商业天才，投资界的沃伦·巴菲特，科技界的史蒂夫·乔布斯，杰夫·贝索斯，拉里·佩奇，保罗·艾伦，等等，都是具有杰出商业头脑的人。不过这些同学离我们的距离稍微远了一点，他们的案例对大多数同学的日常工作不太具备指导意义，我们还是回过头来聚焦在身边的具体工作上，看看什么样的同学会被大家认为是具备好的商业头脑。

最有资格评价我们技术同学是否有商业头脑的，恐怕是与我们相爱相杀的产品同学，我们来听听他们怎么说？

“‘会’砍需求的技术。也就是技术通过PRD评审通过和PD沟通，能够在完整了解业务价值及解决思路的基础上，准确判断出哪些功能，哪些实现瓶颈，其实是nice to have, 而又有哪些是must have。在开发时间紧张的前提下和PD及时沟通砍掉nice to have的，抓紧时间保障完成must have。”

“有商业sense的技术同学往往具备开阔的视野、愿意接纳新事物、在模糊业务背景下有自己的思维结构。

1）业务面向用户是谁？用户需求是什么？体量多大？

2）业务增长红利在哪里？

3）业务的困难制约点在哪里？

4）为什么是lazada来做，不是其他对手做？

5）周边的资本动向是什么？

……

往往有商业思考的同学，大多数跟PD讨论的是这些内容。他们不仅仅关心技术方案的成本以及工作时长。”

“讨论问题、寻找方案、以及在制定方案的过程中，总是能以赋能业务的角度出发，来思考问题。关注用户体验、商家体验、平台业务健康性和可持续性。”

“技术方案严谨：基于对代码熟悉了解+PRD理解的基础上，能够准确的评估近似人日。起码不会在后期开发期间出现重大遗漏未评估环节；上下游链路联动推动以达到要求的交付时间：对跨域的产品需求，能够拉通关联上下游进行技术评估和实现执行，有风险有问题迅速升级讨论；对项目交付的时间有高度的敏感性”

“有合作精神、有开放的学习态度，以及有共赢精神。”

“对当下和未来的business target 和步骤可以有清晰拆解和实现；能解决问题，靠谱，能一起担当”

“In my view ‘business sense’ is the interest in and ability to solve ‘business problems’… So, in order for an engineer to have "business sense" s/he needs to invest the time and energy to understand (a) context, (b) stakeholders, and relative importance of factors for the company or organization when it comes to trade-offs. This would be driven by interest and - equally importantly - actual 'free' time to invest into those investigations. Of course, time is limited and engineers will decide whether to invest their precious 'free' time into developing "business sense" or their technical skills instead, i.e. into learning new frameworks, new programming languages, new technologies, etc.”

限于篇幅，这里只引用了部分同学的反馈，她们都毫无疑问的提到了以下几点：

理解业务。具体一点讲，明白当前业务的现状，目标和方向，核心KPI是什么，为什么我们要做这个事情，以及做了以后对业务带来的价值是什么？
了解技术实现的细节。当前的业务产品在系统中是怎么实现的，有哪些能力和局限，与上下游的关系是怎样的。如何能够快速的实现目前的产品需求。很多时候同一个问题可以有多种技术实现，每种实现都有自己的优缺点。优秀的技术同学能够基于对当前业务问题的理解，作出最恰当的选择。
能给到产品有效的输入。对产品设计不合理的地方提出挑战和有建设性的意见。对产品设计遗漏的地方给予补充，对稳定性、安全性，以及资损、舆情、PR等潜在的风险给予意见和建议。
积极的沟通和推动项目落地。帮助产品一起管理好业务的预期。能够换位思考，理解业务面临的压力，管理好项目的风险，保持信息的透明，想尽办法帮助业务实现需求。

很朴素的要求吧，不需要我们技术同学去学习理解高大上的经济学知识，不需要你去做商业策略的判断，只需要你了解当前负责的领域的业务，最重要的是，这些业务在系统中的实现，并给出建设性的意见，高效地推动方案落地。但是这个过程中往往有一些理解和执行的误区：

1.非理性的挑战

对业务价值的挑战需要建立在客观的数据基础之上，而不是简单的基于自己过去的经验，其他人或者竞争对手的实现，甚至于技术同学自己的技术倾向。在缺乏数据支持的前提下，当我们与产品和业务对项目价值有分歧时，我建议：

1）让专业的人做专业的事。术业有专攻，我们需要相信产品和业务的判断。可以要求有明确的success metrics以及与之相匹配的运营计划。养成项目定期复盘的习惯，避免重复犯错。

2）用真实的数据来说话。技术同学最擅长的是用技术的手段来解决争端。设计科学的严谨的实验往往是解决问题的最佳途径。在Amazon，几乎所有涉及到用户界面改变的项目都会强制要求A/B Test。强大的实验框架允许业务和产品同时对上百种内容针对不同的人群进行测试，并根据结果自动调节分桶的大小。

2.Technical Debt and Over-Engineering

是用正确的实现还是临时方案？在时间压力下，大部分技术同学会选择用临时方案。但是所有人都知道没有所谓的临时方案。一旦上线，临时方案就变成了永久方案，也就是我们的技术债。然后你会用双倍甚至三倍的资源去还债。所以永远不要使用临时方案，除非你的重构计划已经排上日程。过度设计目前看来不是太大的问题。有的时候技术同学往往会偏向选择复杂的技术实现，比如碰到性能瓶颈大家会想到用多级缓存（JVM内存+本地缓存+TAIR），在实现时候的小小纰漏就会导致复杂的数据不一致，排查非常困难。而简单的扩容可能就能解决当前的问题。请记住最简单的实现往往是最有效的解决途径。

3.脱离技术实现的细节空谈业务

任何技术系统都有它的局限性。工程师们最宝贵的财富来自于他们对当前技术系统的深刻理解，这也是产品在PRD评审时最希望得到的输入。优秀的技术同学总是能够给出不同的技术实现方案，并清楚的分析每个方案的Pros & Cons，帮助产品做出最合适的选择。脱离技术的细节空谈业务往往无法帮助产品充分理解技术实现的局限性，无法充分评估其影响，从而不能做出最恰当的选择。

4.Over communication is better than no communication

技术同学最受产品业务诟病的是沟通不充分，风险暴露往往太迟。理科男的特性决定了我们埋头苦干的特质。有风险我们第一时间想的不是如何通报而是默默的去解决。这里我们必须要转变的思路是项目的风险必须第一时间通知到对口的产品，一起想办法去应对和解决。最关键的是，产品需要充分及时的信息去管理业务的预期。我们不是在孤军奋战，产品技术是一体的，产品代表技术对业务发声，技术代表产品向用户负责。

我们再来听听技术同学本身对技术与业务之间的关系是怎么看待的？以及对产品和业务有什么样的诉求？

“技术与业务就好比人的两条腿，相互配合才能走的更远，任何一方不足就好比是瘸子走不远走不快。”

“我觉得用最简单最的技术解决复杂的业务，提高自身生产力，为客户带来最好的体验和价值，是技术业务合作的最佳状态。一个好的business sense的同学应该对于行业有足够了解，对于问题有多种思考和解决思路，同时努力寻找最优的方向或者一些新的尝试。个人感觉这些东西对于技术同学其实见识和思考的还是不够多，对于产品同学来说可能了解的多一些，但是最优解法不一定有。这个是一个需要长期讨论和慢慢沉淀的过程。”

“技术和业务需要相互信任，相互支持和相互理解，在业务初期或业务爆发期，技术团队要么面临基础能力不完善的困难、要么面临平台能力不完善导致业务支持不过来的痛苦，业务团队需要一起想办法，做合适的业务或产品推进节奏，对业务规划或试错需要更加谨慎。反之对于业务遇到困难时技术需要更加主动的了解业务的本质与业务产品运营的详细细节过程，通过细粒度的数据分析来帮助业务更好的看业务。”

“技术TL要懂业务（或者说理解业务），能够和业务产品基于业务逻辑来对话，技术不能只被动的接需求，要了解业务当前的痛点，并有一些实际行动和业务一起想办法解决痛点，如果能做到业务同学在做一个业务规划或者有idea的时候能主动找技术同学来讨论就比较好了。”

“业务不能只把技术作为开发资源，大家是一起为一个共同目标负责的，业务进展或结果要带给技术同学做事情的成就感，需要技术同学理解业务的初衷和价值。”

“不喜欢：

a) 特别在意业务边界问题的PD；

b) 特别喜欢挑刺且不给建议的PD；

c) PRD在开发过程中经常变更的PRD，产品方案不严谨，也没了解清楚业务根本需求；

d) 只提需求不关注产品运行质量与问题的PD，这样锅全是开发的，对产品细节也不会关注，这样的PD基本上就是满足业务的需求,没有产品的独立思考；”

啊哈，不出意外，技术同学对商业头脑的判断和产品同学的预期并没有大的差异，技术同学的诉求集中在以下几点：

1.参与需求的生成

让技术同学真正理解需求的最佳方式是参与到整个需求生成的过程，了解需求是怎么产生的，有直接和业务甚至用户对话的机会。当然在LAZADA这个环境下，很多需求来源于各个国家的一线运营同学，参与每个需求的生成不切实际，但是至少有这样的渠道或者机制存在，让运营和产品能够在产品规划或者脑爆的阶段尽可能的engage技术同学。Amazon每年6月到10月有一次大的业务规划期叫做OP1（Operational Planning Stage I）。在这个期间，产品，业务，技术会在一起脑爆下一财年的要做的事情，产出规划。通过这个过程，技术对做的事情有很强的参与意识，也有更强的主观能动性。

2.产品设计要有全局视野

一个线上的产品往往是跨域的，需要有全局的视野。比如Flash Sale，从招商到商品发布，导购，详情，到购物车，下单，营销的计算，库存，结算，逆向等，贯穿了电商的整个核心链路。我们往往发现某些交易相关的产品设计只考虑了正向交易的流程，对逆向的部分缺乏设计，或者一个退货相关的产品只考虑了物流部分，没有结算的相应流程。这样有缺陷的设计是导致线上问题的根源。

3.既要管生，也要管养

每一个上线的产品都是技术系统不可分割的一部分，不但有开发成本，也有长期的维护成本。我们希望每个产品上线都有周密的运营计划，能够真正发挥出价值。我们允许试错，但是不能容许草率的犯错。而产品的运营往往需要长期的，持续的投入和精细化的运营方案，不能浅尝辄止，轻易放弃。每个产品都是我们的孩子，缺少关注的孩子注定会夭折或者发育不良。LAZADA的拼团，砍车等产品目前看来是失败的典型。

4.用有限的资源做最有价值的事情

资源总是有限的，而需求是无限的。在阿里既要又要还要的文化氛围下，技术常常成为甩锅的对象。技术希望与产品是背靠背的战友，产品能够从纷繁复杂的业务需求中找到真正有价值的目标，技术提供最强大的炮火，一起赢得战役。没有原则的产品不是好产品，不能坚守承诺的技术不是好技术。

技术同学怎么去培养自己的商业头脑呢？下面给出一些简单的建议：

1.产品是我们最好的学习伙伴

要了解业务，最快最有效的途径就是和我们对口的产品同学。多和她们交流，认真的参与每次PRD评审，产品规划，总结分享，多提问，你会逐渐成长为领域的业务专家，至少可以和产品平等对话。商业头脑更多的是一种思维方式和习惯，多与产品讨论业务，业务思考的角度就会自然形成。

2.培养数据意识

阿里的土话是No Data, No BB。学会用数据来说话，首先从业务核心的KPI入手，牢记它，项目的目标是什么？与业务KPI有什么关系？如何埋点，如何追踪，定期复盘。数据如何变化，变化背后的业务含义是什么？用户行为的改变还是推荐算法的升级，或者是系统的故障？建立清晰的业务数据看板。

做到这两点，对大部分一线同学来讲就足够了。要进一步的提高自己的业务能力，你可以尝试：

3.深入了解自己的业务领域

对自己负责的业务领域，有基本的业务框架的认知，了解业务发展的前景，现状和痛点。对业务单元的主要角色，有深入的了解。放在国际化的场景里，就需要对当地国家的业务有一定的认识，比如国家经济发展的状况，电商的成熟度，用户画像，卖家分层等等。

4.拓展自己的知识边界

多学习，多积累。包括日常的财经新闻，评论，重要的商业事件，互联网公司的上市财报，竞争对手的动态，朋友圈的动态等等。

5.补充专业的知识

要想真正成为业务专家，基本的经济学常识，行业知识，商业分析的模型和框架等等，开始变得重要。跨学科的知识往往能够帮助我们拓展思维的方式和思考的深度，带来创新。以色列有如此多的创业公司，其中的一个观察是他们汇聚了非常多跨学科的人才，新产品新科技在思维的撞击中不断诞生。

最后我想分享一些在过去一年里国际化中台技术与LAZADA产品业务一起成长的成功案例：

1.店铺技术与PD合作快一年，就做到了商家装修从0到55%，uv占比17%，承接双十一45%的流量。引导成交占比18%。店铺技术团队自主建立了数据小站，帮助产品数据化定位商业问题，有效的推进了店铺的数次升级迭代。

2.刚刚上线的电子凭证系统,在Lazada业务提出要在2020财年提升Digital Goods业务后，业务中台的技术同学和Lazada PD快速组成项目团队，在短短2个月内，完成东南亚电子凭证业务分析和对焦，上线了一套能够赋能东南亚卖家和市场的电子凭证系统。在上线后1周内，参加了年中大促，为马来西亚的Burger King卖家送去了一份惊喜大礼，一天内在没有做大力宣传的情况下，卖出10000份 Burger King电子劵。

3.LAZADA运费业务诉求：在尽量不影响GMV的情况下，降低平台对运费补贴。针对这个核心诉求，产品技术提出了分阶段实施计划，首先解决业务上运费优惠难以运营的局面。技术层面提供运费优惠工具，使平台和卖家可以自主设置运费优惠，运费的成本和优惠分离；其次由于不同国家业务背景不同，技术上针对印尼（物流基础设施较差，竞争对手大量补贴运费）的大部分卖家进行预加载运费优惠，对不同卖家设置不同的门槛进行补贴，精细化运营；第三阶段针对预加载优惠规则，提供平台工具，支持单个活动支持多个卖家同时不跨店进行优惠补贴；第四阶段提供了运费券运营工具，通过运费券替换平台补贴优惠，进行定向补贴，通过覆盖大部分活跃买家，保证GMV的同时降低平台运费补贴成本。最终实现了在几乎不影响GMV的情况下，每个月节省运营成本1M USD。

技术从支撑业务，到引领业务，到创新业务，这一路走来，我们始终与业务并肩作战，携手奋进。

在 GitHub 更新中，欢迎关注，欢迎star。

直面Java第262期：volatile是如何解决有序性问题的？

深入并发第009期：到底什么是Java内存模型？

- MORE | 更多精彩文章 -

如果你喜欢本文,

请长按二维码，关注 Hollis.

转发至朋友圈，是对我最大的支持。

好文章，我在看❤️

技术人员，该如何向业务和产品“砍需求”？相关推荐

技术人员如何创业《一》—— 产品及想法(转载)
转载自LANCEYAN.COM 不得不说这是个浮躁的社会,人人在这个社会都想暴富或者成名.在这些引诱的驱使下很多人都脱离了原来的稳定工作创业.前几天看了<中国合伙人>,故事讲到了几个大学生 ...
技术人员如何创业《一》- 产品及想法
不得不说这是个浮躁的社会,人人在这个社会都想暴富或者成名.在这些引诱的驱使下很多人都脱离了原来的稳定工作创业.前几天看了<中国合伙人>,故事讲到了几个大学生从校园到工作.再到创办了一个伟大 ...
技术人员如何转型为产品经理
技术人员如何转型为产品经理不知道是不是所有的公司开会都是这样,以时间长短作为衡量会议重要性的标准. 周扬被郭姐姐叫去开会,9点半开始,直到快12点了,他才满脸愁容地回到办公室. 放下笔记本,周扬站到 ...
技术人员近业务，会困死在一条船上吗？
U盘式生存,是著名自媒体人"罗胖"(罗振宇)提出的一个概念,他认为,未来中国人必须适应"U盘化生存",概括起来16个字:"自带信息,不装系统,随时插拔 ...
技术人员如何参与产品设计讨论：激活那一潭死水
http://www.csdn.net/article/2014-05-06/2819643-How-To-Get-To-Participate-In-Product-Design 很多时候,程序员与 ...
深度？广度？浅析技术人员的职业发展之路
深度?广度?浅析技术人员的职业发展之路发表于2015-08-31 16:19| 6104次阅读| 来源CSDN| 3 条评论| 作者蒲婧 CTOCTO俱乐部CTO讲堂职场管理实践职业发展 width ...
通信专业技术人员职业水平考试岗位设置与岗位描述
级别资格名称考核内容岗位描述初级不分专业计算机与通信技术领域的基本知识和技能:现代通信网的基本构成.业务流程和应用模式:通信网的交换.传输和终端的基本技术:通信软件开发技术及流程:通信领域 ...
技术人员如何创业《二》- 合伙人的模式
技术人员如何创业<二>- 合伙人的模式 "合伙人"其实从古到今都有,指一帮人聚集在一起干一件大事情,这个事情必须要借助大家的力量一起完成.比如水浒里的一百单八将.西游记 ...
中台之上（二）：为什么业务架构存在20多年，技术人员还觉得它有点虚？
业务架构这个词大家时常听到,但是能解释得清楚的却不多,撩撩度娘,你就会发现,不少人问及业务架构和应用架构的关系,聊天时,也常有人问起业务架构师和产品经理什么区别?业务架构分析和需求分析什么区别?为了思 ...

技术人员，该如何向业务和产品“砍需求”？

技术人员，该如何向业务和产品“砍需求”？相关推荐

最新文章

热门文章