俗话说，计划赶不上变化快，无论需求文档做得如何细致，考虑得如何周全，总会有些难以预料的需求变更在每天困扰着我们。开发人员苦恼，产品运营人员更苦恼，毕竟谁也不愿意捂着脸一遍一遍地求人改需求。

但是，虽然世界充满未知的变化，但是有一些大的方向还是可以把握的，无论是产品运营还是开发人员，都可以在需求确立以及需求评审时多多考虑一下小鸡君说的这些方面，相信一定可以减少一些后期的变更成本。

下面这些内容主要是从开发人员的视角考虑的，多数基于小鸡君的个人经验，难免有失偏颇，不当之处还望指正。当然，如不嫌弃，感兴趣的产品和运营人员也可以稍作参考。

1. 细节变更需求

在项目初期，如果产品人员没有想清楚需求的细节，那么细节的变更可以说是无法避免的。那么作为开发人员唯一能做的就是，在设计程序结构和逻辑的时 候，尽量预留出可扩展的能力。比如模块的增删，字段的增减，页面样式的微调等，除此之外也没什么好办法了。别灰心，这都不是事儿。

2. 跨平台需求

跨平台需求有时候来的非常隐蔽，往往最初规划的时候感觉可以先在一个平台尝试一下，比如先规划了 PC 端，但是 PC 端的某些功能又会忽然很急促的想移植到移动端。

而需求人员往往会想当然的认为，功能差不多，只要挪一下就可以了(平移过去/拼过去)。或者是，页面长的差不多，就改成移动端的大小就可以了(缩一下)。殊不知各个平台无论在架构部署，还是操作体验上都有着天壤之别，如果不提前规划好，那必然是个大坑。

3. 扩展需求

无论是什么样的业务，随着业务量的增长，以及产品运营人员欲望的膨胀，都会催生出各种扩展需求。任何固定数量的，都会增加。任何单一需要的，都会变成多个。

比如页面上设计了三个商品推荐位，就要预留出变成六个、九个，甚至分页的能力。一个接口是给某个业务专用的，某天就可能变成通用的。一个简单的静态页面，某天就可能变成附带管理后台的复杂系统。对于扩展性需求，要反复确认，不必过度优化，但也要留出合理的扩展空间。

4. 异常流需求

异常流需求往往容易被忽略，或者多有疏漏。常见的异常流有图片数据加载不出，图片不存在，接口挂掉，网速慢，未登录，登录态丢失，查询出错，查询无数据，内容溢出，用户输入溢出，用户输入非法，视觉遮挡不可用等等等等。

那么，对应这些异常流情况，就要有配套的前端提示给用户，引导用户进行其他操作。这些异常流往往会在设计稿和文档中遗漏掉，比如各种异常提示浮层，需要登录态的操作，结果登录态丢失等等，都需要有对应的引导。

5. 内容运营需求

所有静态的内容，都可能变成运营需求。静态广告位可能变成轮播广告位，轮播广告位可能变成需要运营后台填写数据，而不是直接写死在页面里。或者某一天可能变成从另外一个自动数据源拉取数据。

关于内容运营需求，评审初期可以确认好运营频次，如果是个把月才改一次的，几乎不耗人力的，那也没必要都搞工具。但是如果每天改一次，或者感觉运营内容的时间已经影响到正常的工作，或者远远大于写个工具的时间，那还是老老实实开发个运营工具吧。

6. 内容校验需求

上面既然说到运营工具了，那么作为运营工具一定是由运营人员自己来填写。既然是非技术人员填写，操作就难免要傻瓜一点，或者说非技术一点，尽量操作简洁，并且可以校验输入。如果因为运营人员多打了个空格，活着多写了个英文逗号系统就挂了，那应该算谁不尽责呢？

还有，能分别运营的字段要分别运营，因为有的时候虽然内容看上去是合在一起的，但是经常会有部分修改的需求，不如分开两个字段。比如广告位链接和埋点 tag，链接可能经常换，但固定位置的 tag 值就不会换，所以分开运营会好一些。

7. 内容复用需求

运营同学的工作是很辛苦的，设想一下每天一边开着 excel ，一边开着你的运营系统一个字段一个字段填写的时候，就知道画面有多美了。所以，运营填写的数据一定是有复用需求的。比如 h5 页面上运营的数据，有可能还需要给原生 app 使用，甚至给 pc 端也用一套数据。一个广告图片和链接，可能被插入到多个页面的顶部或底部，一起更新。多多沟通复用需求，可以随手拯救一大波运营妹子。

21/212>