前端业务开发的通用经验 - 需求评审

本文主要总结关于“怎么评需求以及如何更好完成需求评审以利于后续工作有效开展”的一些经验。首先要说明，本文所述的需求，有时候指一群人在一段时间将要完成的一件事，接近【项目】这个概念，有时候就是指需求文档，还有时候指用户的需求，请根据上下文区分。由于这个话题过于宽泛和抽象，只能是根据我个人的有限经历讲一点局部看法，尽量满足通用性，必然会有片面性。后续边工作边补充、调整。

前置分析

抓核心

每个需求要解决的核心问题/要实现的核心目标是有限的，通常是 1 个核心目标（可能会有多个子目标），也最好是只有 1 个核心目标。

抓核心就是回答：要解决什么问题？要解决谁的问题？要解决成什么样（实现什么目标/获得什么结果）？

注意，核心并不包括怎么做的问题，因为怎么做只是手段，手段可以是多种多样的。

合格的需求文档，应该在一开始就清晰的回答上述三个问题。最好是有背景描述或者具体的用户场景案例。一般来说，C 端产品的用户场景比较好理解，因为我们自己就是用户，但 B 端产品的用户场景就没那么容易理解了，比如一件商品的定价经历了怎样的过程，要是不知道线下运营人员的具体工作，就不可能真正理解需求。

对开发而言，很多时候“要解决谁的问题”是一个即使被忽略也没啥问题的问题，因为基本不会搞错，以致于通常就是被忽略的。但有时候真要搞错了，后续的方案设计就可能发生方向性的错误。比如我做过一个 CRM 项目，主要用于记录客户信息和商务洽谈进度信息，一开始大家都以为做这个是给商务用的，方便他们做工作记录和客户管理，但实际上这个工具是做给老板用的，方便老板跟踪项目进展、管理商务的业绩。商务本身没有任何动力与需求，去 CRM 上填那些信息，人家随便拿个小本本就能记，为啥要用这个系统，外面出差还得连 vpn 才能访问内网应用，多麻烦。所以这个系统不是什么商务助手，而是一个管理工具，在系统设计上就应该做好角色划分（老板/商务，老板角色还得分两层，总经理和区域经理），如果搞成“每个用户只能看自己编辑的内容”，那就彻底完蛋了。

评估必要性

搞清楚需求要干什么，立马问为什么。

失去思考能力的一个标志，就是过于容易把事情视作理所当然，仿佛送到眼前的，天然就是合理的，只需要去理解、吸收、领会，而不需要去质疑、重想、乃至推翻。

做任何事情的基本前提，是必要性。这个问题有没有必要解决？为啥要干这个事？先思考原因，而不是先思考实现。如果理由不成立或不充分，完全可以拒绝执行。

策略上可以用“抬杠”式思维：

• 每当要做个什么事，你就问：如果不做又怎么了嘛？
• 每当要搞什么优化，你就问：保持现状有啥问题咩？

评估合理性

合理性分两面，一是目标的合理性，二是解决方案的合理性。其中目标合理性是方案合理性的前提。

必要性是确认“这的确是个问题，这个问题的确有必要解决”，而目标是说“要解决成什么样”。

目标的合理性并不仅仅来自其本身，还来自于许多外部因素，比如组织能力和环境条件。不过我们日常做的需求，基本不会考虑“会不会做、愿不愿做”的问题，也不会关注类似“市场条件不成熟、受经济发展水平制约”这样的条件问题，外部因素里我们主要关注程序合理性，对程序不合法的需求需要产生警觉，比如没有需求文档的一句话需求、非产品角色提的需求、绕开你的 leader 单独提的需求等。

目标本身的合理性，大方向来自与阶段或长期大目标的拟合程度，小方向来自投入回报比。大方向上没跑偏，小方向上有收益，就是合理。

合理的目标追求事前可证明，事后可度量。要么能够从产品架构逻辑上确认该功能必须有，要么给出衡量结果的指标与标准。功能类的需求主要看前者，体验类和运营类的需求主要看后者。逻辑上没那么肯定的需求，可度量就会格外重要，特别是探索试验性需求（业务发展初期或创新类业务中较常见），肯定得有指标来支持或验证当初的预想。

“和友商对齐”可以是需求的动机，但不是需求成立的理由。

“需求是老板提的”，这个需求成立不需要理由。

方案的合理性分析后面再说。

“Battle 环节”

谁来做

搞清楚谁来做的基本前提，是明确职责范围，每个团队的责任边界需要厘清。某些特定时期这个边界往往不那么清晰，比如大厂里业务狂飙突进热火朝天的阶段。

对干活的人来说，绝大部分情况下落到自己身上的事，都是需要自个儿完成的，这就导致缺乏足够的样本训练以形成“谁来做”的问题意识。事实上并非所有的事情都需要自己做，举个例子：

某个依赖的公共服务升级了，前端需要配合升级，参照文档升级过程中发现，原先有个接收通知的逻辑，而服务升级后不再向前端提供通知，只给后端提供通知，导致已有功能失效。服务方给出的原因是安全组认为原来用 cookie 给前端发通知的方式有风险。目前有三种方案：第一，从代码逻辑上前端可以自己换一种方式实现通知的效果，有一定改动量；第二，让后端介入，提供接口；第三，经咨询，服务方的开发提供了一种不能在文档上公开的类似后门的通知方法。请问该怎么办？

不同风格的前端，可能会有不同的倾向：

• 老实巴交 + 没责任心 => 方案三
• 老实巴交 + 有责任心 + 对自己技术能力有信心 => 方案一
• 老实巴交 + 有责任心 + 对自己技术能力没信心 => 方案二

但我们重新捋一捋这个事情，解决思路就会发生变化：公共服务升级，发生了 breaking change，而服务方既没有明确说明，又没有给预备方案，显然责任方在公共服务侧。从另一个角度看，不可能让 10 个依赖方，都各自去处理这种情况。所以正确的做法是推动服务方去做兼容，个人推不动，就拉上产品一起推。

如果一个事情涉及多个团队，怎么分工往往会是个问题，毕竟如果不是有明显收益的活儿，一般没人会争着干，而你少干一点我就要多干一点。最常见的，就是前后端在边界问题上的纷争。这种事情如果不能协商解决，往往需要一个有权威的“独裁者”来最终拍板。如果大家都尽职尽责，原则上大家肯定能达成“按正确的做法办”的共识，不过由于立场问题，对于什么叫正确，还是很可能会产生分歧，更何况并非所有人都尽职尽责（甚至对尽职尽责的理解和标准也不一样）。这就需要决策者以事为本想清楚什么是最正确的做法，这样才有说服力，确保公平。

不过老板也常说，不要有边界感和领域意识，那是不是说计较谁来做的问题就显得很狭隘而且有推脱的嫌疑呢？其实不是，因为搞清楚谁来做，实质是要搞清楚什么是【正确的做法】。

为什么现在做

所有产品都希望需求立马上线，但现实是资源永远是有限的，所以要排优先级。如果你发现某段时间所有的需求都是最高等级，那么基本可以判断产品内部的需求管理已经完全失序了。所以很多时候也需要友好协商。

小结

技术人员容易犯的方向性错误是一开始就陷在需求的具体解决方案中，甚至于一边看文档，一边就开始想技术的方案设计了。这么做的问题在于默认需求有必要做、需要我做、需要现在做、目标也合理，而这些个前提其实不一定总是成立。只不过当需求分配到具体的人头上时，已经被管理者评估和筛选过了，所以作为执行者只关心怎么做一般也没问题。但是，如果前置评估环节任由管理者代替思考，意味着主动放弃了相应的锻炼机会。

对管理者而言，因为涉及到资源分配的问题，就不得不关注需求的优先级，也就不得不对需求的目标、ROE 进行评估，最终得出重要性和紧急性的判断，而要得出正确的判断，需要对业务的目标、策略有准确而深刻的把握。所以相比单纯干活的人，更容易锻炼出对业务的一整套分析能力和更好的理解能力。

仔细观察就会发现，管理者的做事思维的一个突出特征，就是目标导向，具体的说，是问题意识驱动下的目标结果导向型思维。管理者、领导者一定是强目标结果导向的人，因为目标和结果才是首要的，手段是次要的。特别是老板，他甚至只关心要做啥，然后提供资源找对的人去做，不到迫不得已根本不介入【how】的领域，或者说他只会介入别人干不了或干不好只能由他干的【how】。

对干活的人而言，【how】非常重要，但也应该首先关注【what】和【why】。否则目标感往往会比较差，一个突出表现，就是很容易把目标和手段混为一谈。举个例子，“完成表单抽象方案设计并投入使用”，这是目标吗？这不是目标，是手段。“提高 B 端开发效率”才是目标，更具体的，还要说清楚在什么时间点达到什么状态/指标。

方案分析

方案的合理性，建立于多个维度。能“预见”的问题越多，就越能体现评需求的能力。

通用性

方案的通用性，依赖于抽象能力和对未来变化的预判。不通用，往往意味着每次变化都需要投入成本去实现。方案的通用性做得好，可以节省大量人力。举个例子，前端常见的一种业务场景，就是配置各种静态数据，比如各种公告、各种说明、各种 banner、各种引导提示等等，而这些静态信息往往是在某个条件下才展示，例如指定时间段展示、没有展示过或只展示过 x 次才展示；还有区分不同的对象展示不同的内容，例如区分 app 类型、区分城市、区分新老客、甚至接入用户画像系统做细粒度区分。请问如何设计一个系统，一劳永逸的解决类似的配置需求？

复杂性

如果一个方案显得很复杂，尤其是当问题看起来没那么复杂，收益和目标也没那么大的时候，复杂方案就显得很可疑。因为成本过高，就不划算了嘛。

复杂度有可能是过度设计导致的：为了追求通用性，提前兼容未来可能发生的各种变动。衡量是否设计过度的基本方法是：看未来的变动可能性有多大，以及发生以后的处理成本。

对比

有两种对比方法，一是“如果是我，我会怎么设计”，二是“横向对比看同类产品是怎么做的”，本质上都是找替代方案做对比。永远不要默认产品的方案就是最优解，毕竟一个人的想法总是有局限性，如果一来就聚焦到产品的方案本身，有可能会掉到圈套里，因为错误的方案也会有“正确”的设计。最好是按照方法一重新想一遍，争取能从技术角度补充改进方案，乃至给出更优解。

有效的经验

有效的经验来自对需求的分类与建模，当遇到同类需求，就容易看出问题。前端业务开发究竟有哪些类型的需求？每一类需要注意什么？举个简单的例子，凡是列表展示，必然要考虑：loading 状态、数据为空状态、异常状态、分页加载、上拉/下拉刷新、已加载所有信息提示、排序规则、筛选机制，可能还有分组、删除、回到顶部等功能。

全链路逻辑推演

要发现深层次的问题，一个方法是做全流程的细粒度逻辑推演。在各种条件下，按照需求的方案设计，一步一步从头走到尾，会不会遇到不明确的、遗漏的、无效的甚至有矛盾、有冲突的业务逻辑。这个要求略显过高，因为多数时候都是在具体开发到某处逻辑时，才能由技术实现的困境反向暴露出需求方案的问题。这个事情其实比较适合 QA 写用例的时候做，写用例既要考虑整体功能与核心流程，也要考虑极端条件和边缘场景，理论上可以提前排雷，当然实操还是得看人。

进度预期

进度失控会产生大小不同的后果，一般互联网行业敏捷开发小步迭代的模式，通常不会出大幅的失控，而小幅的失控影响面通常有限。但像手机制造这种事情，进度失控的后果就可能是致命的，比如产能跟不上，供货延期，等同于把本该赚到的钱拱手让给友商。

宏观的进度管理，是做整个系统的协调安排，比如一款手机的研发生产过程管理。本文只涉及微观的、具体到最小项目单元（比如一个需求）的进度管理。

微观的进度管理，可以转化为这样一个问题：在给定参数条件下，如何预判后续事项演化过程，以对各阶段成果的如期实现获得稳定预期？

举个例子，给定如下参数：新手负主责 + 老鸟辅助 + 陌生系统 + 简单需求 + 有 Deadline 的重要项目，请问这件事有延期风险吗？有经验的人或许能看出来，这里面的关键变量，是老鸟的责任心。

多数干活的人通常不怎么关心项目进度的问题，毕竟啥时候上线跟“我”有啥关系？只要“我”按时交工即可。不过有时候确实有关系，比如作为前端，你先完成了开发等着后端联调，但是由于种种原因后端一直没有资源介入开发，拖着拖着这个需求就废弃了，那不就白干了吗。再比如后端很晚才上线，你是不是得跟着等到半夜，毕竟多数时候后端上完线，前端才能上，上完还得回归一下。

就算不关心项目的进度风险，个人排期也需要关注进度风险。

通常风险点来自依赖方，像电子设备制造商最大的难点之一就是供应链管理，要不为啥让库克当苹果 CEO 呐。一般自己对己方（包括熟悉的合作方）的能力范围是比较了解的，因而预期比较稳定，而对第三方服务和不熟悉的合作方，因为存在信息不对称以及各种难以控制的风险，导致很难获得一个稳定的进度预期。

举个例子，有这么个需求，某个模块需要请求其它部门的一个线上接口，看起来很简单，应该没啥问题吧，毕竟线上接口肯定是稳定运行的，但事实上有可能相当多的时间会消耗在这个第三方接口上，各种问题会连绵不绝的涌现出来：有没有接口文档？没有的话从哪里去看这个接口的参数与返回数据？有接口文档是不是最新的？如果不是最新的，遇到问题能不能找到人咨询？找到后这个人是否能及时看？看的时候会不会看漏？接口是否支持跨域？不支持的话能不能找到人及时支持跨域配置？找到后这个人会不会配置跨域？配上后能否赶在我方上线之前上线？我方上线后预计会新增多少流量？会不会影响到对方的服务器？假设出问题了找谁解决？

如果不能搞清楚所有的依赖，以及这些依赖是否可用、是否能及时就位，那么排期就是不可靠的。很可能有大量时间耗在技术调研或者与合作方的调试中。

对于不紧急的需求，某些风格特异的开发可能会有这种想法：顺手就能完成的小事，不用催，肯定能搞定，没必要给时间点，没必要专门排期，为了这点点事还专门要排期是否显得大题小做太不相信人了？这种做事风格很容易导致时间安排失控，一是容易招引各种顺手小需求前来加塞，二是不明确约定时间点，实质是规避了延期责任，结果反而容易拖延。

所以明确时间必不可少，就算暂时无法明确，也要给出一个能够给出明确时间的时间。