回顾之前几次运营活动的需求，以一个H5活动需求为例，看看每一步要注意哪些点。

一、需求发起阶段

这个最开始的阶段一般是运营、市场、发行等具体执行的同事发起，往往是跟时事热点、节假日、产品运营活动结合去弄的需求，而且往往会参考一些比较成功的活动案例来，在最开始的时候必须明确好一些目标、范围、效果，免得实现出来偏差太大。

1、需求的背景和目的。比如，结合国庆节要出一个宣传推广的H5，想要达到的就是结合节日出游，做一个跟游戏相关的“装逼炫耀”分享图片，起到传播、推广、活跃、拉新的效果。

2、需求的实现流程。一定要明确好每一步要实现怎样的操作，有哪些选项，达到怎样的效果。

3、需求的时间排期。明确好上线日期，然后看下开发时间是否充裕，尽量不要做匆忙的需求。（不过一般这个是不可能的，都是说很急、必须做）

4、需求的一些边界范围。比如，这个活动是只在微信里进行，还是需要在QQ、微博等不同平台进行。

5、需求的可妥协度。比如，在某些功能点上不能实现，怎样处理，最低可以接受到怎样的程度。

二、需求评审阶段

如果活动需求是有产品人员在中间协调，就会经历这一步。有些情况是运营同事直接跟开发进行沟通。此处说的需求评审包含产品的需求把控评审，以及与技术的共同评审。

首先，产品人员会重新归纳整理发起人提出的需求，并将通俗的描述输出为更加规范、技术性的描述，如需求原型、需求文档等，自己评估好可行性后，再找技术人员共同评审。

1、需求描述清楚、完整。不是一定要原型、文档有多牛逼，而是把需求说清楚就够了，背景、目的、流程、时间、数据分析等。

2、技术与时间的可行性。技术上是否可行，以及时间上是否充裕时需要跟开发人员必须确定好的事情，同时要预估好风险，大家明确的情况下共同承担，而不是到最后互相甩锅。

3、异常情况的考虑。这一点，经常会漏掉，因为评审描述需求的时候，一般都是按照正常流程来走，会发现没啥问题，结果到了开发阶段，发现漏了很多异常没考虑到，这就要求在需求评审阶段，就要在每一步考虑清楚如果不是正常情况来操作该怎么处理。

4、明确好需求人员职责。如果有产品人员把控，就必须产品人员跟进好需求；如果没有产品人员介入，运营人员要跟技术沟通清楚。必须指定主要负责人，以免最后出现需求不明确推搡责任的情况。

三、设计阶段

需求确定好，原则上不再改动后就开始交付设计了。

1、尺寸与适配。明确好需求页面的尺寸要求，如最小尺寸、最大兼容，是等比例缩放还是居中显示，是否兼容平板、PC等。

2、布局与元素。页面的布局和元素要求，一定要在需求原型或文档中说明清楚，每一处的要放什么元素，有什么作用，是否有参考样式，越具体越好，让设计师能够一眼知道你的意思，但是在具体的设计上不要过多干扰设计师的发挥。

四、重构阶段

设计稿确认无误后，才交付重构，避免返工。

1、页面及元素完整。对照最初的需求流程，看下是否缺少页面、按钮、元素等设计图，要全部处理完整在给到重构师。

2、交互效果说明清楚。在没有专门的交互设计师处理的情况下，必须在设计稿出来以后，就把页面想要的交互效果，说明清楚（应该最好是在需求原型阶段就要给出预期效果），比如按钮的点击、样式的滑动，哪些是图片，哪些是动态文字，页面上每一块区域都要说明清楚，避免重构出错。

五、开发阶段

到此阶段，如果以上流程的问题都注意好了，就是跟进进度、跟开发确定一些遗漏细节的问题了，但同时也要注意以下问题：

1、不要随意变更需求。这个都懂的了，不够实践起来要真的hold的住才行。

2、不要随便提前上线时间。一般情况下，还是留足充裕的时间。

3、不要随意变更设计稿、重构。页面结构的变动，也还是要代码处理，会影响正常功能开发，所以正常情况下也还是不要随便改动。

六、测试阶段

到了最后把关这里也不要掉以轻心，应该一同跟QA把关，而不是完全扔给QA自己就不管了。

1、测试、正式环境与数据的切换。一般上线前都是在测试环境，数据也是假数据，测试切换的时候注意不要搞混。

七、上线阶段

测试无误后，按照正常时间点就可以上线啦~~但是也要一起关注，安排好应急情况处理的方案及人员才行。

总而言之，要做到把需求交代清楚、人员分工及时间安排好、勇于承担，事事上心才能把看似简单的需求做的不简单。