如何做好一个需求

2020-12-05

作为一名后台开发同学,做需求开发不可避免,无论是产品需求还是技术需求,需求虽然在变,但做事的方法是相同的,这里简单总结下从接到一个需求开始至需求上线的整个过程,以及其中需注意的点,避免后续踩坑

1. 明确需求

以产品需求举例,接到一个需求之后,首先要做的是搞明白这个需求,而不是一上来就是开始撸代码,这样很有可能导致最后上线的功能不符合产品预期

怎样明确一个需求?

  1. 为什么做这件事,收益在哪里,让需求方来即产品经理讲,如果这个都讲不明白,这个需求可以直接拒掉,毕竟做了也没什么收益,这个道理在哪里都说得通
  2. 明白1之后,产品一般都会提出自己的方案,但是这个方案是否合理 也需要我们开发自己来思考,不当工具人,有不合理的地方应该直接提出来和产品讨论
  3. 需求预期上线时间以及验收标准

重点: 产品需求清晰后要追细节,避免一句话需求,凡是方案涉及到的细节点都需要在tapd or 企业微信中同步出来,避免后续返工

2. 开发

需求明确后,一般会开始排期,评估工作量,工作量拍脑门可不行,需方案明确后才能给出相对准确的排期

这里评估工时

  • 工作点拆分的越细,一般评估的工时会更加准确
  • 可以请有经验的同学帮忙评估,自己再留一定buff也可

拆分工作这里建议 写设计文档,之后排期也可以很明确的给出来,下边列下开发中要注意的点

  • 设计文档
    • 需求描述,架构图,细节流程图,监控点,测试点等等,可以参考这里就不展开讲
    • 方案选型和涉及建议要有和业界或者公司内部部门的比较
    • 整体架构和方案指定后需评审,可以找组内小伙伴或者leader或者总监,都可以,查漏补缺
  • 编码
    • 编码阶段注意写单元测试
    • 编码种碰到问题及时反馈出来讨论,技术问题或者产品逻辑问题都可以, 或者写入todo项也可
  • 自测
    • 前提是单元测试已ok
    • 针对接口或者逻辑进行测试,后台开发一般需看日志来确认逻辑正常
    • 需测试到异常分支,这里最容易出问题
  • 联调
    • 需求如果涉及到多方,需和上下游服务进行联调,此时更应该看服务端日志确认自己的逻辑正常才可以
  • 监控
    • 需能看到异常or关键逻辑的监控是否正常
  • debug
    • 需要有debug能力,比如可以针对单个用户染色,接入天机阁,可以很方便看到此用户日志,要不然排查问题成本太高
  • 效果验收
    • 需让需求提出放在测试环境 验收,符合预期后进入下一步
  • 性能验收
    • 压测当前服务,给出QPS,分位耗时等数据
  • CR
    • 强烈建议 代码走读,前置查漏补缺,总比在线上发现问题好

这里要注意

  • owner意识,自己承诺的时间点尽量要达到,如果有插入需求或者编码中碰到问题会影响进度,需及时反馈出来,而不能等到最后一天了才说没完成
  • 追求效率,30min法则,如果一个问题自己google和思考30min还没解决的,及时反馈给导师or高T,再解决不了再向上反馈,不能死撑着
  • 口头沟通基本无效,关键点需同步出来

此时开发侧基本工作已完成,下一步需在正式环境部署服务上线

3. 上线

  • 资源评估
    • 建议前置,我厂资源申请还是比较麻烦的
    • 服务上线需要使用多少资源,cpu,mem,底层存储(redis,dcache)等等 需要前置评估出来
      • 这里根据之前的QPS数据,再结合预估的峰值流量 即可预估出需要部署多少节点
      • 这里要注意线上节点的负载不能过高,需要有一定冗余,线上负载建议在40-50%之间
  • 资源申请
    • 一般是向运维同学申请,需说明需求背景,收益,资源推导公式 便于运维同学审批
  • 资源部署
    • 部署在正式 和 灰度节点即可
  • 压测
    • 之前压测使用的是自己构造的client,req和线上用户是不同的,这里建议使用线上旁路流量指定后端某一个节点进行压测,数据最为准确
  • 发布流程
    • 灰度发布

      • 发布灰度节点,用户量比较小
      • 产品需在此环境验收功能是否正常
      • 开发需在此环境验收逻辑是否正常,通过日志确认
    • 旁路验证

      • 因之前机器资源是根据压测结果推导而来,假如结果不准 会导致线上服务异常,这里建议可以 先旁路线上流量至新服务上,对线上无影响,又可以验证服务性能,提前发现问题 提前解决
    • 正式发布

      • 这里建议使用 白名单+灰度百分比方式放量,风险最小
        • 产品开发先使用白名单体验,通过日志确认,功能正常之后再开始按百分比放量
        • 放量中注意观察服务负载和之前的监控等数据,有异常及时处理

这里多说两句,后台开发需对发布有敬畏之心,发布要灰度上线,逻辑都验证到才可以,切记不可发布完事就完事了,要对自己的发布负责,毕竟我们写的可不是玩具程序,是真的会影响上亿用户的体验的

4. 后续

  1. 功能上线之后,还需关注上线之后效果如何,是否符合预期,可以和产品讨论是否有后续的优化点
  2. 系统是否便于debug,如果不是 这里也是优化的点,毕竟开发同学有大部分时间都是在查case,这里效率一定要提高
  3. 如何处理线上问题,建议看这篇,以恢复线上为第一原则
  4. 开发侧是否为了赶工期 有挖坑,比如有临时的解决方案,该填的坑也得填了
  5. 总结。方案架构设计的对比,思考等等,持续总结才能提高自己的架构设计能力
  6. 项目中使用的上下游组件是否了解其原理,比如使用 redis or kafka 是否真的了解了,都是可以学习的点