为什么开发得学会“砍需求”

[chiyan-lin]

砍需求的定义

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

有商业sense的技术同学往往具备开阔的视野、愿意接纳新事物、在模糊业务背景下有自己的思维结构。
1）业务面向用户是谁？用户需求是什么？体量多大？
2）业务增长红利在哪里？
3）业务的困难制约点在哪里？
4）为什么是lazada来做，不是其他对手做？
5）周边的资本动向是什么？
……

商业思考的体现

往往有商业思考的同学，大多数跟PD讨论的是这些内容。他们不仅仅关心技术方案的成本以及工作时长，而是在讨论问题、寻找方案、以及在制定方案的过程中，总是能以赋能业务的角度出发，来思考问题。关注用户体验、商家体验、平台业务健康性和可持续性。

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

有合作精神、有开放的学习态度，以及有共赢精神。对当下和未来的business target 和 步骤可以有清晰拆解和实现；能解决问题，靠谱，能一起担当。

在和这些同学的沟通反馈中，他们提到了

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

砍需求过程中常见的误区

不分理解和执行的误区

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

1. 让专业的人做专业的事。术业有专攻，我们需要相信产品和业务的判断。可以要求有明确的success metrics以及与之相匹配的运营计划。养成项目定期复盘的习惯，避免重复犯错。
2. 用真实的数据来说话。技术同学最擅长的是用技术的手段来解决争端。设计科学的严谨的实验往往是解决问题的最佳途径。在Amazon，几乎所有涉及到用户界面改变的项目都会强制要求A/B Test。强大的实验框架允许业务和产品同时对上百种内容针对不同的人群进行测试，并根据结果自动调节分桶的大小。

技术债和过度开发

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

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

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

过度沟通好过不沟通

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

技术同学怎么看待技术与业务之间的关系

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

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

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

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

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

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