如何聊聊洞悉了解性需求的15招 ！

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

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

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

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

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

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

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

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

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

5. 内容运营需求

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

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

标签： 需求运营人员变成