日常开发方案设计指北

日常开发方案设计指北

互联网公司管理研发流程,常常使用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)业务配置项:通过动态配置项管理的业务规则。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注