01 收集需求
需求类型：优化，bug，新功能等。
优先级：需求的紧急程度。<br>
功能使用频率：这里也是之前自己遇到了坑，业务提出一个功能优化需求，做好上线以后，发现业务基本就不使用这个功能，导致上线后没有实际意义。因此在需求收集阶段，特别是针对某功能优化，一定要清楚业务对这个功能的使用频率。<br>
需求背景或原因<br>
需求目的/解决什么痛点/实现什么效益<br>
需求详情：对需求的详细描述。
02 思考需求合理性<br>
数据调研：很多需求或项目的提出，在启动之前都需要从现有数据上进行一定程度的分析预估可到达的目标，同时也可看该功能的使用数据情况，考虑其有没有优化价值。
需求内容的适用场景：很多业务会提一些特殊场景的优化或者特殊处理逻辑，产品做功能逻辑尽量能统一化，避免特殊逻辑，后期会不好管理，也容易留坑。
技术架构的影响：有的需求也许看起来很简单，但其实技术实现非常复杂或者现有架构不支持，若遇到这种拿不准的情况可以先和开发聊一下，简单评估一下，这样对项目的定位也会更清晰。比如我遇到一个场景，业务提出希望订单能合并发货，我认为也很合理，可以做，但后来评审发现，我们现在WMS系统架构是很难支持的，如果要做需要全面重整架构，很大的工程量，因此重新评估该项目，就先暂缓了。<br>
是否需要其他系统/部门的支撑：做B端产品，会涉及到大量相互关联的逻辑及流程，比如我做订单系统，会涉及到和商品系统、物流系统、仓储系统的各种对接。因此在该阶段，可以大致思考一下是否需要其他系统支持，若需要可以提前安排沟通，避免后面需要了才临时对接，这也是我自己血的教训。
复盘业务提出的需求内容：根据收集到的业务需求，详细了解业务诉求，核对其真实性及是否有逻辑冲突。
04 需求调研
B端产品的需求调研：访谈+竞品<br>
B端竞品相对比较难获取到，可看一些第三方开发的ERP软
06 产品评审<br>
第一：做完方案后先和业务简单做个评审，确认一下设计的功能及操作流程，能满足业务需求，还有没有什么补充。
第二：确认之后再进行开发测试评审即可，评审通过后，确认开发和测试排期。
07 项目正式立项<br>
包含内容为：项目背景，目的，需求内容，最重要是开发测试排期时间以及上线时间。
若有风险或者关联性特别多的项目建议上线时间可以往后推预留1-3天，为未知风险做预留准备。
08 产品验收<br>
开发和测试完成后，在正式上线前，一般会预留一天左右的时间做产品验收。
主要是看下整体功能以及一些核心逻辑，是否和产品设计一致，若有问题再上线前提前提出和解决。
09 上线通知和培训<br>
项目上线后，需要发送上线通知，一般可通过邮件发送，主要包括上线时间（若有延期说明延期原因），上线安排，操作指南等，若功能比较复杂可安排做操作培训。
10 上线后跟踪
上线后1-2周是非常关键的时间，这段时间主要关注点为：
1、上线后使用跟进：整体功能是否使用正常，bug反馈，业务运转是否通畅等。之前做需求，上线后就以为完事了，后来发现业务根本就没怎么用，没有推起来。假如上线后1-2周业务没有用起来的话，这个功能其实后面也很难再推起来了，所有上线后一定要推动业务使用，做好项目实施工作。
2、上线后数据及功能监控：这里就是说的对上线后监控方案的跟进，是否完成了预期的目标，把数据拿出来看是最有效的，同时也帮助产品做项目复盘及后期不断的迭代。
