一个需求的生命周期

一个需求从诞生到面向用户，需要经历重重锤炼，才能完成其不平凡的一生。

 

需求的来源在《需求从哪里来？》一文中已经进行了总结，在这里主要说拿到需求后面的事儿。先上图，看图说话。

 

往往产品拿到的需求并非“真的”需求，首先需要了解需求的来源和背景，并和提需求的相关人员进行核对，了解用户的真实意图，再结合自己的分析，转化为真实可做、切实可行的需求。

对于产品经理来说，我们更希望提需求的人向我们诉说自己遇到了什么问题，想要解决什么问题，想要达到什么样的效果，而具体怎么解决这个问题，以什么方式解决，产品需要更多更全面的思考；而不是提需求的人一上来，告诉产品经理我就要这样这样做，但是为什么这么做却讲不明白。

 

在对需求进行简单的分析之后，产品经理定下来具体需要做的需求，并针对每个需求输出一个大致的解决方案，如有需要可以将解决方案提供给需求方。这样，需要做的需求，如何去做这个需求都是很清楚的了。需求分析完成之后进入需求设计阶段。

 

需求设计阶段，如果是简单需求，有了思路之后就画原型写文档做就可以了，但如果是复杂需求，忌一开始就一股脑画原型，返工的概率太大了。面对复杂需求，初步的需求分析和解决方案并不能支撑我们流畅的完成整个需求，我们需要做更详细的需求分析和流程设计，我一般会使用流程图或者思维导图进行详细的需求分析和流程设计，设计完成之后再进入具体的原型设计和逻辑设计。先捋清楚，可以事半功倍。

 

产品经理完成需求设计，输出原型和需求文档之后，组织进行需求评审，各方需要就产品经理拿出的Demo进行讨论，指出存在的问题。在需求评审会议上，需要完成两件事情，一件是需求讨论定稿，另一件是需求评估排期。

 

需求评审之后，需求推进到产品研发阶段，此时产品经理已经可以开始准备后续版本的需求了。一般涉及到APP版本的迭代，版本周期在一个月左右；Web或者后台版本的迭代，版本周期则在一个周左右。在研发出方案的同时，UED会出UI，测试会写测试用例，然后进行两到三轮的测试版本迭代，完成本次大版本的开发和测试，测试完成之后就可以评审上线了。

 

版本发布评审的会议上，首先需要评审的是当前版本未解决的BUG是否需要继续解决，影响较小则可以适当进行遗留；其次是版本升级之后对于各方的影响需要各方知晓并在版本上线后出现问题能够有效应对，比如某一功能上线可能会导致流量暴增，那么运维、运营、客服和研发相关人员就需要在上线后做好相关的支持；最后是版本发布的具体时间，一般为了不影响用户体验，版本发布时间多为晚上十二点左右，发布时需要研发和测试都在场，上线后需要进行一轮冒烟测试。

 

很多公司会采取灰度发布的方式，以确保大版本的升级不会出现较大的影响生产环境的问题，将可能发生的负面影响降到最低。放一只“金丝雀”投石问路，不至于出现问题全军覆没造成不可挽回的损失，大大的降低了这种可能性。

灰度没有问题之后，就可以将版本全量发布出去。至此，需求正式上线面向用户，但需求的使命并未就此结束，产品经理需要对上线需求进行持续跟踪，以便于更好的改进产品、服务用户及为企业创造最大的效益。