拥有技术的你，如何同时拥有商业头脑？参与商业竞争，近而走的更高

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

 

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

 

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

 

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

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

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

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

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

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

……

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

 

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

 

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

 

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

 

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

这是基于我们自身拥有的；下面我们进阶……

理解业务。具体一点讲，明白当前业务的现状，目标和方向，核心KPI是什么，为什么我们要做这个事情，以及做了以后对业务带来的价值是什么？

了解技术实现的细节。当前 的业务产品在系统中是怎么实现的，有哪些能力和局限，与上下游的关系是怎样的。如何能够快速的实现目前的产品需求。很多时候同一个问题可以有多种技术实现，每种实现都有自己的优缺点。优秀的技术同学能够基于对当前业务问题的理解，作出最恰当的选择。

能给到产品有效的输入。对产品设计不合理的地方提出挑战和有建设性的意见。对产品设计遗漏的地方给予补充，对稳定性、安全性，以及资损、舆情、PR等潜在的风险给予意见和建议。

积极的沟通和推动项目落地。帮助产品一起管理好业务的预期。能够换位思考，理解业务面临的压力，管理好项目的风险，保持信息的透明，想尽办法帮助业务实现需求。

 

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

但是这个过程中往往有一些理解和执行的误区，下面我们给出一些意见：

不接受非理性的挑战，这很重要，包括：

 

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

 

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

 

3.技术债务和过度工程

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

 

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

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

 

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

 

 

技术支撑业务。“我觉得用最简单最好的技术解决复杂的业务，提高自身生产力，为客户带来最好的体验和价值，是技术业务合作的最佳状态。”但技术与业务就好比人的两条腿，相互配合才能走的更远，任何一方不足就好比是瘸子走不远走不快。这个是一个需要长期讨论和慢慢沉淀的过程。

 

基于上述要求和意见 ，简而言之技术人员参与商业竞争，产品学习、培养数据意识、深入业务领域、拓展知识边界、补充专业知识等等是不断进军更高阶层的基础。

 

 

文章来源:阿里技术 藩宇《论工程师的商业头脑》 有删改