互联网公司管理研发流程，常常使用TAPD一类的敏捷工具。一个需求从提出到上线要经历至少七个流程：

• 1）需求评审：产品经理给出需求文档，邀请技术参与需求评审，目的是扫清需求疑点，排除无法实现的需求。
• 2）技术评审：技术人员内部评审需求，确定详细的技术方案。
• 3）开发排期：技术人员根据技术方案拆解任务，输出开发排期文档，并告知产品和测试，以便他们协调测试时间。
• 4）开发阶段：技术人员用代码实现需求，如果有需求疑点，继续找产品核实。在开发尾声，技术团队内部审查代码。
• 5）测试用例评审：测试人员根据需求文档拆分测试用例，并给出测试工作排期，确定需求最终上线日期。
• 6）测试阶段：测试人员根据测试用例分别在测试、预发布、灰度、生产环境测试。
• 7）产品验收：测试人员确认测试通过，邀请产品人员验收。

初级工程师往往做不好需求评审工作。要么被产品经理牵着鼻子走，让干什么就干什么；要么预估不到隐藏的工作量，在开发排期阶段给出不合理的排期，导致开发时间紧张，最后加班应付测试。

以下探讨的需求评审和技术方案设计等内容，都用电商的需求《优惠券管理平台》来举例说明。

需求标题：优惠券管理平台
需求背景：当前用户下单结算不支持任何优惠折扣活动，营销人员无法采用多样化的手段留存和获客。
需求内容：规划优惠券管理平台，运营人员申请营销预算，批量生成优惠券，赠送优惠券给不同画像的用户。购物车支持用户下单时使用优惠券。后台管理增加两大模块：1.营销预算管理；2.优惠券管理（配置优惠券模版、生成优惠券、赠送优惠券）。
详细设计：篇幅过长，略。

2.如何评审需求

2.1 三连追问

我们常常说研发人员也要有产品思维，并不是产品思维多么宝贵，而是没有产品思维，就不知道怎么拒绝产品经理的需求。面对任意一个需求，都要发起对产品经理的三连追问：

• 需求的价值是什么？
• 需求的后续规划是什么？
• 这个需求是必须的吗？

十个产品九个抄，很多产品经理的需求缺乏后续规划。他们没有完成产品的闭环思考，先抄袭别人的创意试试水。产品需求文档里面可能会出现前后逻辑矛盾，研发人员要抓住这些矛盾，给予重重的嘲讽，帮助他们改善工作。

2.2 需求拆分

如果一个需求的目的，无法用简短的话说清楚，就是不内聚的，要拆分需求后再分析。研发人员可以将需求拆分为3类：

• 必须实现：需求中价值最高的部分，上线后明显提升体验、提升获客能力或者增加客单量。
• 延迟实现：需求中价值低的部分，比如界面微调、表单校验等。在开发时间不充裕的情况下，尽可能延迟到下一版本中。
• 可以驳回：与本次需求没有关联、修复上个版本的BUG等等，考虑驳回。需求中参杂了没关联的功能，常常会增加沟通成本、代码审查的复杂度。

产品需要技术实现产品，研发需要产品展示价值，两者的利益是一致的。研发人员在质疑需求合理性时，措辞上要处在“为了产品更好”的基调上。如果需求被驳回，部分产品经理会抬出上一级领导压人，比如“这是李总要做的，你能怎么着”。如果需求确实荒谬，要上升到管理层去决定，否则产品经理会玩成惯性。

3.如何设计技术方案

拿到一个需求，尤其是周期长、功能多的需求，要考虑多个方面来设计技术方案，做到低成本、高性能、可维护。

3.1 适应变化

没有一劳永逸的方案，适应一定阶段的变化即可。要与产品经理沟通，基本确定未来几个月的变与不变。在《优惠券管理平台》里面，优惠券的产生、使用、核销三个状态的流转是确定的，而使用规则可能会变化，一开始可能随便用，后来演变成按商品分类、品牌划分。针对变的部分要考虑可扩展性，比如数据库字段类型采用JSON，或者设计规则扩展表。

3.2 避免耦合

以业务领域为界限，规划每个微服务工程的职责。在《优惠券管理平台》里面，优惠券是新业务，至少需要一个新微服务。营销预算与优惠券不是强关联的，未来可能赠送礼品卡或者实物纪念品，营销预算的代码不能写在优惠券的微服务里面。

3.3 估算资源消耗

根据接口访问次数或者前端埋点统计，预估业务产生的数据量，估值越具体越好。例如: 双十一活动中，预估发放优惠券100万个，购物车结算页面查询优惠券接口达到1000QPS。根据这些结论，才能更好的规划数据库表的分片设计、查询接口的性能设计。

3.4 安全问题

• 1）数据安全

避免泄漏用户数据，将敏感信息如手机号、银行卡明文显示在页面中；暴露的链接是否包含敏感参数，比如营销短信内容的推广链接包含用户ID。

• 2）接口安全

给前端使用的接口是否防刷；访问外部接口要设置访问超时时间。

3.5 输出文档

编写技术方案文档有两个作用，一是用于技术评审，二是方便接盘侠参考。文档至少包括6个要点：

• 1）详细需求：把产品经理的需求文档搬过来。
• 2）系统流程图：通常是业务流程图、系统泳道图、微服务调用图。
• 3）数据表设计：涉及到新表的设计、旧表的改动。
• 4）改造点清单：所有要改动的旧模块的Class等等。
• 5）灰度计划：如果需求只针对符合规则的部分用户展现新的产品流程，必须注明灰度计划。
• 6）业务配置项：通过动态配置项管理的业务规则。

本文链接：https://www.codingbrick.com/archives/850.html
特别声明：除特别标注，本站文章均为原创，转载请注明作者和出处倾城架构，请勿用于任何商业用途。