日常开发方案设计指北

2年前 (2022) 程序员胖胖胖虎阿

255 0 0

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

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

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

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

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

2.如何评审需求

2.1 三连追问

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

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

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

2.2 需求拆分

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

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

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

3.如何设计技术方案

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

3.1 适应变化

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