如何做好一个需求分析

目录

1. 明确需求

2. 开发
   设计文档
   编码
   自测
   联调
   监控
   debug
   效果验收
   性能验收
   CR

3. 上线
   资源评估
   资源申请
   资源部署
   压测
   发布流程

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

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

怎样明确一个需求？

为什么做这件事，收益在哪里，让需求方来即产品经理讲，如果这个都讲不明白，这个需求可以直接拒掉，毕竟做了也没什么收益，这个道理在哪里都说得通
明白1之后，产品一般都会提出自己的方案，但是这个方案是否合理 也需要我们开发自己来思考，不当工具人，有不合理的地方应该直接提出来和产品讨论
需求预期上线时间以及验收标准
重点： 产品需求清晰后要追细节，避免一句话需求，凡是方案涉及到的细节点都需要在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. 后续
   功能上线之后，还需关注上线之后效果如何，是否符合预期，可以和产品讨论是否有后续的优化点
   系统是否便于debug，如果不是 这里也是优化的点，毕竟开发同学有大部分时间都是在查case，这里效率一定要提高
   如何处理线上问题，建议看这篇，以恢复线上为第一原则
   开发侧是否为了赶工期 有挖坑，比如有临时的解决方案，该填的坑也得填了
   总结。方案架构设计的对比，思考等等，持续总结才能提高自己的架构设计能力
   项目中使用的上下游组件是否了解其原理，比如使用 redis or kafka 是否真的了解了，都是可以学习的点
   欢迎大家一起交流学习：
   qq：564790073
   github：https://github.com/hashyong